Как увидеть общую картину всех процессов и отследить результативность команды?

Вячеслав Фомичев пишет:

Олег Катасонов пишет:
При этом система должна уметь сама списывать часы в зависимости от обеспечения задачи ресурсами, в том числе разумеется и информационными. Нельзя такое важное задание как списание часов поручать исполнителю или еще хуже - тому кто задачу ставит. Иначе получится какая то капустянщина.

Ничего не понял. "Списывание часов", это что???

Списывать можно домашние задания в школе. Или материальные затраты в бухучете.

Рабочее время учитывают. В том числе время выполнения определенных операций, заданий, а также время потерь рабочего времени. Есть еще планирование рабочего времени, выдача сменного наряда(задания), в соответсвие с нормативами времени/выработки.

Самофотографию рабочего времени, тоже никто не отменял, - вполне себе законный и допустимый инструмент учета. Контроль конечно же нужен, но опять не понятно, что конкретно имеет ввиду Олег. Но интуиция мне подсказывает, что его мысли резко противоречат требованиям Трудового Кодекса РФ.

(Возлагать учет рабочего времени на тупую программу не разрешено, это должен делать специально назначенный человек, пользуясь измерительными инструментами. Максимум что может делать автоматизированная программа- фиксировать точное время входа и выхода работника на территорию организации, но что делает он на рабочем месте, определяется людьми, а не компьютерами. В случае каких-либо разногласий, все делегирования учета времени на ПО, будут признаны ничтожными, а руководителю организации, может грозить дисквалификация по решению суда)

Научитесь уж разговаривать с нормальными людьми на нормальном литературном языке, с применением общеупотребимых терминов, а не каком то птичьем, распространенном в каком-то полуподвале, между какими-то маргиналами. 

И еще один совет:

в целях рекламы, консультанту желательно проявлять именно экспертизу, а никак не безграмотность, и неумение понятно изьясняться.

хм.

Списывать рабочее время - этому выражению лет сто. Когда работы нет, задания нет, но нужно отчитаться за проработанное время, начальство требует, закзачик требует, по договору мы обязаны. Когда оплата почасовая. Это очень распространено и сейчас, очень сильно бесит это, когда с тебя требуют ежедневный отчёт о работе, но задач нет, или ты всё уже сделал. И начинаешь сочинять про "тестирование нового функционала" и списываешь на это часы.

Явление безобразное и распространённое. Именно поэтому мало кто любит эти инструменты учёта времени. И часто все эти канбаны сводятся именно к списанию часов.

А вот "самофотографию" я впервые слышу. Поясните, пожалуйста.

Анатолий Курочкин пишет:
Списывать рабочее время - этому выражению лет сто.

Никогда не слышал.  А между прочим, я всю жизнь занимаюсь вопросами заработной платы, вознаграждением за труд, и поработал по всей стране, во многих организациях. Наверное, какие-то отраслевые (консалтинг) жаргонизмы)))

С консалтенговыми жаргонизмами, признаю, я не очень знаком.

Термин "списывать" чаще применяется к фактическим долгам (безнадежным). Когда признаешь, что это уже не дебиторка, а явный убыток.

Анатолий Курочкин пишет:
Когда работы нет, задания нет, но нужно отчитаться за проработанное время,

По научному, это называется простоем.

"Проработанным временем" простои называть некорректно, раз ничего не сделано. Отчитываться тоже не надо, надо прямо назвать время простоем, и составить акт на простой. Простои оплачиваются в размере 2/3 от оклада или тарифной ставки. Но только с момента информирования руководителя или организации о начале простоя. В таком случае, организация или непосредственный руководитель обязан выдать задание или перевести на другую работу, возможно с изменением трудовой функции (исключение, когда разрешается заставить работать не по должностной инструкции).

Если вовремя не сообщить о простое, то оплата простоя не производится. В таком случае, вместо отчета, нужно писать обьяснительную: я такой-то сякой-то, не сообщил своевременно о начале простоя, потому что был сильно занят (уточнить чем:  чтением художественной литературы, просмотром порнухи, личными разговорами по телефону, общением в форумах и чатах, настольными играми или видеоиграми, распитием горячительных напитков с другими тунеядцами, и т.д.)

А попытки выдать простои за рабочее время, - назывались у нас:  приписки, подтасовки, "фуфельной работой". По сути, - воровство. Совсем недавно, в другой ветке, прозвучало "попо-часы".

Явление практикуется только там, где нет контроля, и где руководство по какой-то причине готово  закрывать на это глаза, потому что проверяется все на раз.

Анатолий Курочкин пишет:
А вот "самофотографию" я впервые слышу. Поясните, пожалуйста.

Самотчет. Что делал, когда, сколько времени. Вот пример:

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
Списывать рабочее время - этому выражению лет сто.

Никогда не слышал.  А между прочим, я всю жизнь занимаюсь вопросами заработной платы, вознаграждением за труд, и поработал по всей стране, во многих организациях. Наверное, какие-то отраслевые заморочки)))

Термин "списывать" чаще применяется к фактическим долгам (безнадежным). Когда признаешь, что это уже не дебиторка, а явный убыток.

 

Анатолий Курочкин пишет:
Когда работы нет, задания нет, но нужно отчитаться за проработанное время,

По научному, это называется простоем.

Благодарю! 

У "списания", вы верно пишете, много значений. Списать - скопировать, списать - удалить из учёта. и так далее. 

В проектах, по краней мере в айтишных проектах, всё не так. Есть проект, за результаты кторого заказчик оплачивает, есть задачи, которые вытекают из проекта. Там же сроки и временные затраты. Заказчик, как правило, требует отчётности по временным затратам. Он не будет вам оплачивать простой, никогда не пойдёт на фиксацию простоя ни гендиректор, ни работники. И это не приписки, проект будет выполнен в срок, причины отсутствия задач могут быть самые разные, например типичная рассинхронизация.

И не очень умные начальники начинают требовать, чтоб время работы списывалось только на те задачи, которые оплачивает заказчик. 

Это очень распространено . Именно это многим не нравится в системах управления проектами.

Именно это и имеется в виду в данном случае - часы списываются не на те работы, которые вы исполняли. Например, никто и никогда из закзачиков не будет вам оплачивать профилактику компьютера. И вы будете списывать это на какое-yb.elm совещание с контрагентом.

Анатолий Курочкин пишет:
В проектах, по краней мере в айтишных проектах, всё не так.

Анатолий Курочкин пишет:
И не очень умные начальники начинают требовать, чтоб время работы списывалось только на те задачи, которые оплачивает заказчик.

Я по ходу, догадался, о чем идет речь.

Анатолий Курочкин пишет:
Заказчик, как правило, требует отчётности по временным затратам.

Тут надо сначала определить область применения. Есть два разных варианта, и они сильно отличаются.

1. Проекты, исполняемые внутренними командами (штатными работниками организации).

2. Проекты, выполняемые сторонними (внешними) организациями, исполнителями (в том числе по договорам ГПХ).

В первом случае, учет времени работ, и оплата регулируется Трудовым Кодексом РФ (начисляется заработная плата), а во втором, - Гражданским Кодексом (оплачивается выполненный объем работ). 

В обоих случаях, надо осознавать, что искажение трудозатрат, - это факт налогового правонарушения. Но в первом случае, правонарушителем является Организация -Заказчик, во втором - Исполнитель. И есть риск того, что налоговая прицепится, начнет копать, и насчитает кучу штрафов, как для Аль Капоне в Америке,))) Как говорится, наказывают не за то, что украл, а за то, что попался.

Я работал в организациях, где был сильно развит проектный подход для штатных работников (1 вариант). В таких случаях, простои фиксировать обязательно, иначе себестоимость взлетит в космос, а организация обанкротится. Какие проекты, итишные или строительные, тут без разницы. 

Иногда может показаться, что если с работникон заключен договор на оплату за выполнение определенной работы (задачи), то завышение трудоемкости работ некритично, но это не так. Во первых, производится искажение производительности труда (занижение), во вторых - появляется возможность для необоснованного раздутия штата, для найма лишних исполнителей. (трудоемкость задач - основа для планирования штатной численности).

Если же простои происходят у стороних исполнителей, то да эти простои никого не интересуют - чужие сотрудники, ими управлять нельзя. Но обосновать расходы нужно, потому и требование заказчика. 

Анатолий Курочкин пишет:
Есть проект, за результаты кторого заказчик оплачивает, есть задачи, которые вытекают из проекта. Там же сроки и временные затраты.

Это не простой, это подзадачи. Если исполнитель "декомпелирует" задачу на подзадачи, а заказчик говорит "к черту подробности", то почему бы не пойти ему на встречу? В данном случае, надо просто не нудеть, и не засирать другим мозг. Нудят обычно чтобы поторговаться, получить какие-то преферанции, или повысить цену проекта. Если такой цели нет, то не надо вводить людей в заблуждение.

Это в отличие от ситуации, когда действительно, никто ничего не делал. Бывает, что заказчику предоставляют промежуточный результат с вопросом, по какому варианту двигаться дальше, или просто для одобрения на начало работ следующего этапа (например, проект приказа по утверждению нормативной документации). Если заказчик вместо быстрого решения вопроса жует сопли и тянет время, - то это чистый простой по вине заказчика.  Если он согласен его оплатить как рабочее время, - то почему бы и нет?.

Анатолий Курочкин пишет:
Он не будет вам оплачивать простой, никогда не пойдёт на фиксацию простоя ни гендиректор, ни работники.

Опять же зависит от ситуации. Если простой связан с операционной деятельностью заказчика, то тут могут быть очень разные варианты. Я в предыдущем сообщении, приводил пример учета рабочего времени при выполнении работ на скважинах. Такой учет производится в актах выполненных работ, подписываемых заказчиком. Для того, чтобы контролировать выполнение работ в оговоренный срок. Частный случай: если заказанный обьем работ длительный, а по технологии работ надо сделать перерыв (например, спуск-подъем труб НКТ), то возникает простой отряда исполнителя. Оплата таких простоев, регламентируется договором. Например, может быть установлено, что оплачивается не более 7 часов простоя в сутки, если простой не по вине исполнителя заказанных работ. Если же возникает нештатная ситуация, и исполнитель не укладывается в нормативные рамки, то уже заказчик может выставить исполнителю акт на оплату простоя буровой бригады (весьма впечатлительный, кстати!)

Но этот Топик явно про управление штатными сотрудниками, именно по первому варианту идет обсуждение, а проблемы взаимоотношений со сторонними подрядчиками тут явно не к месту.

Вячеслав Фомичев пишет:

Я по ходу, догадался, о чем идет речь.

Анатолий Курочкин пишет:
Заказчик, как правило, требует отчётности по временным затратам.

Тут надо сначала определить область применения. Есть два разных варианта, и они сильно отличаются.

1. Проекты, исполняемые внутренними командами (штатными работниками организации).

2. Проекты, выполняемые сторонними (внешними) организациями, исполнителями (в том числе по договорам ГПХ).

В первом случае, учет времени работ, и оплата регулируется Трудовым Кодексом РФ (начисляется заработная плата), а во втором, - Гражданским Кодексом (оплачивается выполненный объем работ). 

В обоих случаях, надо осознавать, что искажение трудозатрат, - это факт налогового правонарушения. Но в первом случае, правонарушителем является Организация -Заказчик, во втором - Исполнитель. И есть риск того, что налоговая прицепится, начнет копать, и насчитает кучу штрафов, как для Аль Капоне в Америке,))) Как говорится, наказывают не за то, что украл, а за то, что попался.

Не вижу никакого искажения трудозатрат с точки зрения исполнителя. Есть заказчик, есть договор, сроки и стоимость. Исполнитель, кроме непосредственной работы по разработке и внедрению исполняет и другие работы, кторые являются обязательными, но не касающиеся непосредственно проекта, ну как пример, профилактика компьютера и сотня других. И другое дело, что заказчик не готов оплачивать эти не касающиеся продукта работы. Вся организация работ лежит на исполнителе, все риски он сам страхует. Нет никакого налогового правонарушения. Это пока ещё личные деньги исполнителя.

Но убираю за скобки вариант, когда гензаказчик сидит на бюджетныйх деньгах.

Вячеслав Фомичев пишет:

Я работал в организациях, где был сильно развит проектный подход для штатных работников (1 вариант). В таких случаях, простои фиксировать обязательно, иначе себестоимость взлетит в космос, а организация обанкротится. Какие проекты, итишные или строительные, тут без разницы. 

...

Но этот Топик явно про управление штатными сотрудниками, именно по первому варианту идет обсуждение, а проблемы взаимоотношений со сторонними подрядчиками тут явно не к месту.

Соглашусь с последним абзацем, раньше я задал вопрос автору топика - что он называет проектом.

Но разница между строительным проектом и проектом ИТ есть, и она огромна. При этом часто исполняются проекты между строительством и ИТ, например, строительство Дата-центра. И тогда эта разница просто бросается в глаза, найти общий язык между строителями и айтишниками очень непросто. В строительстве есть измеряемые параметры - глубина котлована, объём  и прочее. Прадва там добавляется, например, прохождение госэкспертизы, результаты которой по срокам почти невозможно предсказать. И да, исполнитель в этом случае может учитывать простои своих работников для сдвижения сроков вправо. Но у строителей, само собой, не бывает опытной эксплуатации. Есть просто сдача объекта. У нас и ОЭ, и ПМИ, которые уменьшают риски внедрения, но они есть всегда.

И кстати, обратил внимание на ваши слова, что "Я работал в организациях, где был сильно развит проектный подход для штатных работников (1 вариант). В таких случаях, простои фиксировать обязательно, иначе себестоимость взлетит в космос". Да,так! И именно это следует учитывать руководителям проектов, кторые хотят внедрить систему управления проектами. Именно это мы уже как-то обсуждали на форуме - вместо оптимального распределения ресурсов систему управления проектами становится очередной отчётно системой для руководителей и пользователи руками и ногами начинают отбрыкиваться от неё. Вести работы простому исполнител.ю, работкниу и руководителю проекта - большое искусство.

Анатолий Курочкин пишет:
Исполнитель, кроме непосредственной работы по разработке и внедрению исполняет и другие работы, кторые являются обязательными, но не касающиеся непосредственно проекта, ну как пример, профилактика компьютера и сотня других. И другое дело, что заказчик не готов оплачивать эти не касающиеся продукта работы. Вся организация работ лежит на исполнителе, все риски он сам страхует. Нет никакого налогового правонарушения. Это пока ещё личные деньги исполнителя.

Я уже ответил (уточнил мысль) в предыдущем посте на эту тему :

Вячеслав Фомичев пишет:
Это не простой, это подзадачи. Если исполнитель "декомпелирует" задачу на подзадачи, а заказчик говорит "к черту подробности", то почему бы не пойти ему на встречу?

Нужно не забывать нормировать работы, и описывать их диаграммой Ганта и сетевым графиком. Вы заблуждаетесь, когда указанные работы называете "не касающимися проекта". Ошибка в неправильной классификации работ (подзадач), неумении указать их подчиненность в составе основной работы.  

Профилактика компьютера, в частности - это подготовительно заключительные работы. Они всюду есть, это как в цеху - подготовка рабочего места (чистка, получение сменного задания, получение на складе материалов, инструмента и оснастки, разложение их по местам)

Еще есть транспортно-заготовительные и накладные расходы (управление, обеспечение, координация, и пр, в т.ч. бухгалтерский учет), как правило, они учитывается в смете проекта в процентах к основным работам (например 35% ТЗР и 20% накладные).

Запланировать эти работы и затраты в смете чохом-процентовкой, а потом их второй раз вспомнить и поименно перечислить, - за это следует как следует уши накрутить, ))) Вот и у заказчика появляются вопросы Это ЧТО? 

Другой случай, если ТЗР и Накладные в смету не включили(не верю!), - тогда надо ставить вопрос: "а по Хуану ли сомбреро", - не мазохист ли исполнитель, за свой счет эти затраты компенсировать?

Анатолий Курочкин пишет:
Но разница между строительным проектом и проектом ИТ есть, и она огромна. При этом часто исполняются проекты между строительством и ИТ, например, строительство Дата-центра. И тогда эта разница просто бросается в глаза, найти общий язык между строителями и айтишниками очень непросто.

Это от разной нормативной базы. СНиПы разрабатывали при СССР, а ИТ выделилось отдельно после его развала, и его по большому счету никто не нормировал. ИТишники от того занимаются шаманством (немотивированным усложнением ситуации), задирают нос и раздувают щеки.

Но если как следует проанализировать процесс, пронормировать и квалифицировать работы, то ситуация станет прозрачной и понятной.

Чтобы найти общий язык между строителями и айтишниками, всего лишь надо устранить противоречия между ними, и обьеденить общей целью. Тогда они сами договорятся (Особенности национальной охоты вспомнил, как Петрович с Финном заговорили,)))

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
Но разница между строительным проектом и проектом ИТ есть, и она огромна. При этом часто исполняются проекты между строительством и ИТ, например, строительство Дата-центра. И тогда эта разница просто бросается в глаза, найти общий язык между строителями и айтишниками очень непросто.

Это от разной нормативной базы. СНиПы разрабатывали при СССР, а ИТ выделилось отдельно после его развала, и его по большому счету никто не нормировал. ИТишники от того занимаются шаманством (немотивированным усложнением ситуации), задирают нос и раздувают щеки.

Но если как следует проанализировать процесс, пронормировать и квалифицировать работы, то ситуация станет прозрачной и понятной.

Чтобы найти общий язык между строителями и айтишниками, всего лишь надо устранить противоречия между ними, и обьеденить общей целью. Тогда они сами договорятся (Особенности национальной охоты вспомнил, как Петрович с Финном заговорили,)))

Нет, совсем не так.

СНиПы и сейчас разрабатываются и СП (Своды правил), они все вполне действующие. Итишники используют всю прелесть ГОСТов 19, 2, 34, 24 (отчасти), плюсь совершенно новые ГОСТы серии Р. ГОСТы серии информационные технологии существую с 60-х годов, некторые из них действуют до сих пор. Кроме  этого ПУЭ, ПТЭЭПЭЭ и пр и др.

Строители, опираясь в целом на ЕСКД используют 21 серию. И плюс к этому кучу уточняющих и важных постановлений правительства, например, всем известное и избитое 87. Плюс (из важных) 145 постановление по госэкспертизе.

Так что дело не в том, что айтишники "занимаются шаманством (немотивированным усложнением ситуации), задирают нос и раздувают щеки".

Да, строители и айтишники договариваются. Например,чтоб совместить несовместимый ГОСТ 21 и ГОСТ 34, хотя у них и общий корень - ЕСКД,  они придумали такую штуку, как "технорабочий проект",чтоб угодить и строителям и айтишникам.

Вячеслав Фомичев пишет:
Нужно не забывать нормировать работы, и описывать их диаграммой Ганта и сетевым графиком. Вы заблуждаетесь, когда указанные работы называете "не касающимися проекта". Ошибка в неправильной классификации работ (подзадач), неумении указать их подчиненность в составе основной работы.  

Частично соглашусь с этим. Заблуждаюсь не я,заблуждаются заказчики. Вполне допускаю, что их мелочи и правда не интересуют. Интересуют сроки. Надеятся на их "к чёрту подробности" можно только до первого конфликата с заказчиком. Ни разу не видел, чтоб в подобных проектах, а  у меня их было много, кто-то прописывал такое, про что вы пишете:

Профилактика компьютера, в частности - это подготовительно заключительные работы. Они всюду есть, это как в цеху - подготовка рабочего места (чистка, получение сменного задания, получение на складе материалов, инструмента и оснастки, разложение их по местам)

Еще есть транспортно-заготовительные и накладные расходы (управление, обеспечение, координация, и пр, в т.ч. бухгалтерский учет), как правило, они учитывается в смете проекта в процентах к основным работам (например 35% ТЗР и 20% накладные).

Мы же говорим о системах управления проектом. Допускаю,что в идельном варианте вы правы. Только ведь каждый работник (программист) не видит смету, не следит за её соблюдением, не знает, что там по бухучёту проходит в учёте часов. У него своих задач десятки. За сметой следит руководитель проекта, вот он и делает так,как ему закзачик дикутет, в том чсиле и через соблюдение сметных цифр. 

Ну учтёшь накладные работы в процентах. И что? А если компьютер не ломается, если ему не нужна профилактика? Вот таким образом и списываются часы - то, с чего мы начали. Или один из разработчиков уже сделал свою работу и ждёт, когда ему с бэкенда дадут результат. 

Всё-таки мы немного не о том говорим. Или я не о том. Вы ведь реально просто подтвержадете мою мысль, что неумелое использование таких систем управления проектами и приводит просто к отчётности и для показа руководителям. а не для управления задачами.

Тем не менее, благодарю за беседу.

Анатолий Курочкин пишет:
Всё-таки мы немного не о том говорим. Или я не о том. Вы ведь реально просто подтвержадете мою мысль, что неумелое использование таких систем управления проектами и приводит просто к отчётности и для показа руководителям. а не для управления задачами.

Анатолий Курочкин пишет:
Только ведь каждый работник (программист) не видит смету, не следит за её соблюдением, не знает, что там по бухучёту проходит в учёте часов. У него своих задач десятки. За сметой следит руководитель проекта, вот он и делает так,как ему закзачик дикутет, в том чсиле и через соблюдение сметных цифр. 

По моему мнению, здесь все начинается с договора на берегу. Недосказонности при подписании сметы выливаются в проблемы при сдаче проекта.

Есть этап согласования сметной стоимости работ. Смета, - по сути план работ по срокам и стоимости. Очевидно, что указав сроки, в смету не включили трудоемкость работ. Ну так надо заранее согласовать и саму трудоемкость этапа, не только стоимость, тогда нужно будет всего лишь показывать одинаковые цифирки в столбиках план-факт.

Если план-факт совпадает, то откуда возьмется смысл спорить с заказчиком о каких-то работах, "входящих или не входящих в проект"?

Когда речь идет о проекте, то мы имеем вместо номенклатуры работ с их количеством при процессной деятельности, перечень этапов проекта. И расчет стоимости этапа проекта должен производиться, как все возможные расходам плюс норма прибыли (например, затраты с налогами  + 15%). Для наглядности, при работе проектной организации на единственного заказчика, смета по проекту должна совпадать с данными бухгалтерского баланса в тютельку (а иначе в такой ситуации быть и не может, потому что работы по проекту - первичное, а бух-баланс - вторичное, на основе первичной документации проекта).

Абсолютно все затраты, и даже прибыль, формируются только за счет оплаты заказчиком выполненых обьемов работ. Нет никаких работ, не существует в природе, которые не оплачивались бы заказчиком. Все, абсолютно все, что делает организация, прямо или косвенно закладывается в стоимость этапов проекта. Для этого существует нормативная база - руководства по определению сметной стоимости работ, и надо строго следовать ей.

Чтобы уменьшить до нуля разногласия с заказчиком, надо на момент согласования, подготовить пакет документации - формы актов приемки этапов проекта.

Основная таблица в этом акте может иметь следующие столбцы:

1. Идентификатор/номер этапа;

2. Наименование этапа проекта/работы;

3. Трудоемкость в часах;

4. Максимальный срок (дедлайн) исполнения;

5. Стоимость.

6. Ответственный исполнитель.

7. Комментарий (критерии оценки выполнения этапа, ограничения, штрафы и премии).

Ну а далее, по каждому этапу, надо просто строку расписать по факту исполнения. Если расхождений с планом нет, то и проблем нет, не надо ничего выдумывать, нет нужды грузить заказчика какими то проблемами, и работами, оплата которых не предусмотрена сметой/договором. И необходимость махинаций с отработанным временем, тоже не возникнет

Если расхождения с планом есть, - то надо проанализировать внутри организации, причины такового:

1 - не предусмотрели сразу - повесить долг на виновного в заниженном расчете сметы, заказчику об этом ничего не сообщать;

2- согласились на уступку при переговорах, - дать пенделей тому кто об этом забыл и воду мутит сейчас, заказчика беспокоить не надо;

3 - повысились расходы из-за роста цен, или по требованию заказчика добавлены работы не предусмотренные сметой- надо согласовывать с заказчиком изменение сметной стоимости).

Анатолий Курочкин пишет:
Итишники используют всю прелесть ГОСТов 19, 2, 34, 24 (отчасти), плюсь совершенно новые ГОСТы серии Р. ГОСТы серии информационные технологии существую с 60-х годов, некторые из них действуют до сих пор. Кроме  этого ПУЭ, ПТЭЭПЭЭ и пр и др.

Не совсем понимаю, как можно применять то, что совсем не соответсвует современным организационно- техническим условиям труда. Все эти Госты формировались тогда, когда персональных компьютеров и в помине не было(вообще-то они существовали, но в виде экзотики, несколько экземпляров на город, в организациях уж точно не применялись), а я еще застал времена, когда носителями информации были перфоленты и перфокарты (середина 80-х). Нужно было сначала, например, программу на фортране вручную писать шариковой ручкой на клетчатых портянках формата А2, затем эти портянки относить в отдельный кабинет, где программу переносили на перфокарту/перфоленту, потом нужно было получить этот носитель, и отнести оператору, который загрузит носитель в ЭВМ серии ЕС (и все это в порядке очереди, как на почту сходить), потом получить результат... И каждый шаг, - через несколько дней. Ну и как сейчас работать с такими нормативами, перечнем работ, и описанием стандартов по этим работам...

Впрочем, я про нормативы времени на основные виды работ в основном говорю, это совсем иное, чем Госты.

Анатолий Курочкин пишет:
Только ведь каждый работник (программист) не видит смету, не следит за её соблюдением, не знает, что там по бухучёту проходит в учёте часов. У него своих задач десятки. За сметой следит руководитель проекта, вот он и делает так,как ему закзачик дикутет, в том чсиле и через соблюдение сметных цифр. 

Вот тут как раз и зарыт корень зла. Всю отчетную документацию по проекту должен вести в учетной системе не каждый работник, а всего единственный, специально назначенный человек, роль которого в команде называется - Администратор проекта. Он собирает с каждого исполнителя отчеты, сверяет их с проектной документацией, разбирается с несоответсвиями, и вносит в систему. Роль администратора может выполнять/совмещать руководитель проекта. Также оба этих лица должны в обязательном порядке быть ознакомлены, или принимать участие в расчете сметной стоимости работ.

Анатолий Курочкин пишет:
если компьютер не ломается, если ему не нужна профилактика? Вот таким образом и списываются часы - то, с чего мы начали.

А это уже знакомая проблема. Но профилактика - по моему мнению, это не устранение неисправностей сломанного компьютера, а планово-предупредительный ремонт, регламентное обслуживание. Которую надо делать вне зависимости по графику: прошел год, - надо снять крышку корпуса, почистить от пыли, осмотреть состояние комплектующих, произвести тестовые замеры температуры, производительности. Таким же образом перед каждым выездом автомобиль надо подготовить, а предполетная подготовка с частичным разбором авиатехники составляет от трех до шести часов. План ППР составляется на любую технику. 

Но теперь я полностью погрузился в проблему, и могу привести сам удачный пример. Это когда работы выполняются цепочкой на разных обьектах, находящихся в одном месте, или рядом, а условием договора оговорена оплата проезда/провоза от места нахождения организации до места работ и обратно. Тогда по факту пробег автомобиля составляет например 200 км, а по актам выполненных работ, - 400, 600, 800, (сколько отдельных работ заактировано). тут то и возникают и неотработанные часы, и неизрасходованные ГСМ . Да, по факту это приписки, но отказываться от оплаты этих работ, никто не собирается, ни заказчик, ни исполнитель, особенно, когда работы выполняются от одного исполнителя на разных заказчиков. В нашей организации, для устранения несоответсвий, приходилось отдельно от официальной документации для заказчика, делать внутреннюю документацию для управленческого учета (чтобы в сутках не было у работников по 40-60 отработанных часов).

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
если компьютер не ломается, если ему не нужна профилактика? Вот таким образом и списываются часы - то, с чего мы начали.

А это уже знакомая проблема. Но профилактика - по моему мнению, это не устранение неисправностей сломанного компьютера, а планово-предупредительный ремонт, регламентное обслуживание. Которую надо делать вне зависимости по графику: прошел год, - надо снять крышку корпуса, почистить от пыли, осмотреть состояние комплектующих, произвести тестовые замеры температуры, производительности. Таким же образом перед каждым выездом автомобиль надо подготовить, а предполетная подготовка с частичным разбором авиатехники составляет от трех до шести часов. План ППР составляется на любую технику. 

Но теперь я полностью погрузился в проблему, и могу привести сам удачный пример. Это когда работы выполняются цепочкой на разных обьектах, находящихся в одном месте, или рядом, а условием договора оговорена оплата проезда/провоза от места нахождения организации до места работ и обратно. Тогда по факту пробег автомобиля составляет например 200 км, а по актам выполненных работ, - 400, 600, 800, (сколько отдельных работ заактировано). тут то и возникают и неотработанные часы, и неизрасходованные ГСМ . Да, по факту это приписки, но отказываться от оплаты этих работ, никто не собирается, ни заказчик, ни исполнитель, особенно, когда работы выполняются от одного исполнителя на разных заказчиков. В нашей организации, для устранения несоответсвий, приходилось отдельно от официальной документации для заказчика, делать внутреннюю документацию для управленческого учета (чтобы в сутках не было у работников по 40-60 отработанных часов).

Увы, вы не смогли погрузится в проблему. Я ж про профилактику сказал просто в качестве простейшего примера. Видимо пример неудачный. Давным-давно никто плановую профилактику на ПК не делает. Ну какие планы ППР! Все ваши замечания и аргументы вполне, допускаю, подходят для нефтегазовой отрасли, для капитального стрительства, где все можно, или плочти всё, предусмотреть, занести в табличку, а дальше - кирпич на кирпич, неси, бабка, магарыч.

Непредусмотренных проблем и задач в ИТ проектах ежедневно возникает огромное количество. Зарезервируешь время, как вы пишете (и это максимально возможно делается, у нас тоже есть сметчики), например на апдейт систем, библиотек, фреймворков, а обновление не произошло и разработчик сидит и "списывает часы". Зависло облако и ты сидишь. Неожиданно вышел релиз прекрасной библиотеки - у тебя прорыв. А если вознилка несовместимость API? А если релиз программы Х перестал работать с релизом программы У? Самое простое - ну не работает код, хоть тресни! Сыплются баги и никто не может понять откуда. И ты можешь расписать план-факт, потребовать хоть ежесуточной отчётности (что и делают самые  тупые руководители), но вы не подобьёте бухгалтерсикй баланс в расчётах времени работы программиста. Нормировка работы времени програмиста - тема настолько старая и избитая, что и начинать не хочется. Было в этом мире всё - и подсчёт количества строк кода, и попытка навязать программстам план, и попытка отчёта в ежечасной картотеке.   А самые тупые начальники ставят системы учёт движения мышки, системы слежения за разработчиками. И миллионы попыток учесть время работы в интернете. И были попытки требовать отчёт о том, что искал программист на сайте www.aaaabhbbcccddd.com

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
Итишники используют всю прелесть ГОСТов 19, 2, 34, 24 (отчасти), плюсь совершенно новые ГОСТы серии Р. ГОСТы серии информационные технологии существую с 60-х годов, некторые из них действуют до сих пор. Кроме  этого ПУЭ, ПТЭЭПЭЭ и пр и др.

Не совсем понимаю, как можно применять то, что совсем не соответсвует современным организационно- техническим условиям труда. Все эти Госты формировались тогда, когда персональных компьютеров и в помине не было(вообще-то они существовали, но в виде экзотики, несколько экземпляров на город, в организациях уж точно не применялись), а я еще застал времена, когда носителями информации были перфоленты и перфокарты (середина 80-х).

Ну что вы! ГОСТы свежайшие, включающие электронную модель изделия, ГОСТ 21.101-2025, ГОСТ Р2.105.2019 - последние цифры - это год. И так далее. Они регулярно обновляются. Методики новейшие, взять тот же Agile, плюс каскадная модель и прочее, и прочее.

Простите, не могу столько времени уделять чтению огромных комментариев. Всё гораздо сложнее, у вас какой-то бухгалтерский подход, когда человеку кажется, что всё можно учесть в табличках по нормативам. Уж больно это затоптанная тема. Я ж тоже многое помню, например, когджа бухгалтерия запрещала менять видеокарту в компьютере, потому что их "дербанили" по их мнению и меняли остаточную стоимость. Поэтому вас и возмутило слово "списать часы". Так и происходит, а вы удивились.

Ну какие таблички? Давным-давно существует целый парк сметных программ. 

Анатолий Курочкин пишет:
Ну какие таблички? Давным-давно существует целый парк сметных программ.

Может, я недостаточно ясно выразился, но на "парке сметных программ", нет возможности поставить подпись заказчика.  Табличка - часть бумажного документа, содержащая важные юридически значимые факты. Нельзя в случае судебного спора принести на заседание сметную программу, и доказать судье в ней обязательства заказчика.

Анатолий Курочкин пишет:
у вас какой-то бухгалтерский подход,

Я не бухгалтер, но очень плотно с работал с бухгалтерией. С бухгалтерией просто взаимодействовать, если понять простую вещь: им на всякое действие, нужен документ, подписанный уполномоченным лицом. Нет документа, или в нем ошибки/нарушения, или нет подписи/не та подпись - бухгалтерия говорит: мы ничего не будем делать.

Анатолий Курочкин пишет:
когджа бухгалтерия запрещала менять видеокарту в компьютере, потому что их "дербанили" по их мнению и меняли остаточную стоимость.

Если бухгалтерия жаловалась на то, что замена видеокарты не сопровождалась предоставлением дефектной ведомости, то она была вправе. Если все документы были предоставлены, то мнение бухгалтерии никого не интересует. 

Анатолий Курочкин пишет:
Все ваши замечания и аргументы вполне, допускаю, подходят для нефтегазовой отрасли, для капитального стрительства, где все можно, или плочти всё, предусмотреть, занести в табличку, а дальше - кирпич на кирпич, неси, бабка, магарыч.

Да нет же! нет ничего уникального в ИТ-сфере. Есть своя специфика, но с точки зрения логики, процессы все можно классифицировать и нормировать. ИТ, - это частный случай НИОКР. И в нефтегазе, и в строительстве, и в транспорте, - во всех отраслях, точно так-же есть куча своих заморочек.

Например, всякие аварии, ЧП, и т.п. Даже у токаря буквально, если в цехе электричество вырубило, или металл с внутреннем браком попался, - все, кранты всем плановым показателям. А еще у токаря, или программиста, может внезапно случиться жизненная драма, и он начнет гнать брак из-за психофизического состояния. Это все называется нормальным производственным риском. 

Но по общему принципу, брак - не планируется. План верстается на условиях нормального прогноза деятельности. А нормативы - исходя из средней продолжительности работ. При этом каждый отдельный человек, работаетс разной интенсивностью, кто-то быстрее, кто-то медленнее.

Все проблемы в том, что у нас даже должностные инструкции неправильно для руководителей написаны, вот и результат на лицо, бардак начинается с головы.

Вот что написано в трудовых функциях руководителя? Три страницы того - сего вперемешку, как бык поссал. А что надо? Надо всего лишь детально конкретизировать 4 основных функции руководителя: 1. Анализ; 2. Планирование; 3. Организация; 4. Контроль.

Если функции руководителя из ДИ проклассифицировать и  просчитать в часах по факту, что что мы увидим? 30% времени, - Организация, 25% времени, -Контроль, 1% времени, - Планирование, остальное - непроизводительные потери. Анализ и планирование, - вот что надо улучшить для устранения бардака.

Анатолий Курочкин пишет:
Было в этом мире всё - и подсчёт количества строк кода, и попытка навязать программстам план, и попытка отчёта в ежечасной картотеке.   А самые тупые начальники ставят системы учёт движения мышки, системы слежения за разработчиками. И миллионы попыток учесть время работы в интернете. И были попытки требовать отчёт о том, что искал программист на сайте

Вот. Это как раз и есть результат отсутсвия анализа и затрат всего 1% времени на планирование. Каков процесс, таков и результат. Все должно делаться в меру.

Не получается нормировать - надо применять договорные обязательства, не зависящие от конкретного времени. Это например, когда у тебя неурожай, а у всех остальных - урожай. Твои убытки, смирись, твою картошку никто не будет покупать по цене в три раза выше рынка. Надо просто понимать, что беда случается, но случается она не часто.

А если беда в 90% случаях, то это уже не беда, а система. Значит, надо искать виноватых, и менять их на нормальных.

Анатолий Курочкин пишет:
ГОСТы свежайшие, включающие электронную модель изделия, ГОСТ 21.101-2025, ГОСТ Р2.105.2019 - последние цифры - это год. И так далее. Они регулярно обновляются. Методики новейшие, взять тот же Agile, плюс каскадная модель и прочее, и прочее.

Все таки мы говорим о разном. указанные ГОСТЫ - это общие требования к оформлению конструкторской документации. Кроме общих требований, существуют еще ичастные, отражающие специфику конкретной организации, вот о них я и говорю.

В общих требованиях говорится как оформлять документ, но не оговаривается само содержание этого документа, т.е. перечень конкретных работ исполнителя.

И разногласия строителей и айтишников, я уверен, возникают не из-за того, КАК оформлять документацию, а из-за того, ЧТО оформлять.

А я под нормативной базой как раз и подразумеваю, перечень работ исполнителя и нормы времени на их исполнение. Вот они то и не обновляются, и отсутсвуют.

"Как друзья вы не садитесь, но в музыканты, - не годитесь" (ц), басня Крылова.

ГОСТ применительно к басне - это правила рассадки музыкантов на сцене, образно говоря. В этих правилах есть требования к инструментам, но нет требований к самим музыкантам, и согласованного репертуара, что им играть и петь. 

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
Ну какие таблички? Давным-давно существует целый парк сметных программ.

Может, я недостаточно ясно выразился, но на "парке сметных программ", нет возможности поставить подпись заказчика.  Табличка - часть бумажного документа, содержащая важные юридически значимые факты. Нельзя в случае судебного спора принести на заседание сметную программу, и доказать судье в ней обязательства заказчика.

В идеале табличку скинуть на почту и получить ответным письмом согласование. В крайнем случае - можно фото экрана скинуть в WhatsApp и согласовать все там. Не лучший вариант - да, но суды такое принимают. В процессе трехлетней давности удалось приложить скрин WhatsApp с отметками дат о доставке и прочтении сообщений, а также другой перепиской. Обе инстанции претензии поддержали, деньги с должника были взысканы по исполнительным листам, а на заказчика при том работала "коллегия" из трех юристов.

Хоть и медленно, но российская правовая система идет по пути улучшений. А пока лучшее, что можно предложить в этом отношении - через OBS писать все переговоры с заказчиком (в контракте нужно это отдельно прописать): так все демонстрируемые таблицы автоматически попадают в состав согласованных работ. В случае "разночтений" транскрибированный текст и оригинал записи могут сильно помочь.

Антон Соболев пишет:
В идеале табличку скинуть на почту и получить ответным письмом согласование. В крайнем случае - можно фото экрана скинуть в WhatsApp и согласовать все там. Не лучший вариант - да, но суды такое принимают. В процессе трехлетней давности удалось приложить скрин WhatsApp с отметками дат о доставке и прочтении сообщений, а также другой перепиской. Обе инстанции претензии поддержали, деньги с должника были взысканы по исполнительным листам, а на заказчика при том работала "коллегия" из трех юристов.

Изначально составлен бумажный документ и подписан, или электронный документ подписан электронной подписью, а потом распечатан, это не имеет большой разницы. 

Главное, что есть согласованный документ с подписями уполномоченных лиц. 

Согласованный документ не является обезличенной строкой базы данных сметной программы, вот в чем главное отличие двух мнений.

Вячеслав Фомичев пишет:

Антон Соболев пишет:
В идеале табличку скинуть на почту и получить ответным письмом согласование. В крайнем случае - можно фото экрана скинуть в WhatsApp и согласовать все там. Не лучший вариант - да, но суды такое принимают. В процессе трехлетней давности удалось приложить скрин WhatsApp с отметками дат о доставке и прочтении сообщений, а также другой перепиской. Обе инстанции претензии поддержали, деньги с должника были взысканы по исполнительным листам, а на заказчика при том работала "коллегия" из трех юристов.

Изначально составлен бумажный документ и подписан, или электронный документ подписан электронной подписью, а потом распечатан, это не имеет большой разницы. 

Главное, что есть согласованный документ с подписями уполномоченных лиц. 

Согласованный документ не является обезличенной строкой базы данных сметной программы, вот в чем главное отличие двух мнений.

При наличии "живой" подписи или электронной все сильно проще. Я говорил про ситуации, когда вообще отсутствует подпись. В таком случае простое согласование уже может выступить (и на практике выступает) доказательной базой.

Анатолий Курочкин пишет:
Простите, не могу столько времени уделять чтению огромных комментариев.

В очередной раз, Анатолий, удивляюсь Вашей выдержке. Чувствуется огромный опыт проектной работы. Жаль бывает, что вот такой "эксперт" говорун вцепится как клещ в какое нибудь не понятное только ему слово и вытянет из проектировщиков всю кровь и украдет все время обсуждения действительно важных вещей.

Вячеслав Фомичев пишет:

Анатолий Курочкин пишет:
ГОСТы свежайшие, включающие электронную модель изделия, ГОСТ 21.101-2025, ГОСТ Р2.105.2019 - последние цифры - это год. И так далее. Они регулярно обновляются. Методики новейшие, взять тот же Agile, плюс каскадная модель и прочее, и прочее.

Все таки мы говорим о разном. указанные ГОСТЫ - это общие требования к оформлению конструкторской документации. Кроме общих требований, существуют еще ичастные, отражающие специфику конкретной организации, вот о них я и говорю.

В общих требованиях говорится как оформлять документ, но не оговаривается само содержание этого документа, т.е. перечень конкретных работ исполнителя.

Наверное вы давно не читали ГОСТы, СанПины, СП. Да и актуальнеы правительственные постановления. Требования к оформлению - это очень маленькая часть стандартов. Ну ЕСКД, 7 серия, ГСИ. А дальше - требования к содержанию, технические условия, методики, рекомендации, почасовое нормирование, требования к специалистам.

Вот довольно простой пример: ГОСТ Р 72023-2025, Инженерные сети зданий и сооружений внутренние. Стационарные системы электрического отопления в жилых зданиях. Монтажные и пусконаладочные работы. Правила и контроль выполнения работ.

Вот РД-0115 - там почасовые нормы выполнеия работ нормоконтрля. Есть огромные спаволчники для сметчиков, где указаны все нормы времени.