Учёт временных затрат и выполненных работ для программиста — польза или вред?
Привет, уважаемые форумчане!
Один мой знакомый - руководитель небольшой фирмы,
занимающейся разработкой софта,
очень увлёкся такой темой, как учёт выполненных работ и затраченного времени на разработку (используя известный корпоративный софт на букву "Б").
В общем энергия и энтузиазм у руководителя есть, но сам он ни разу не разработчик и творческую деятельность программиста представляет себе очень смутно.
Хочу ему втолковать, что методы учёта, пригодные для плановых работ (типа "копать от забора и до обеда") вряд ли можно применять для оценки творческой деятельности и от внедрения таких практик может быть больше вреда, чем пользы.
Руководитель честно признал, что пока не знает, какой результат дадут ему данные о временных затратах, но сказал, что хочет посмотреть к чему это приведёт (употребил фразу "хочу собрать аналитику").
Если у вас есть ссылки на статьи или книги (на русском языке), раскрывающие суть данной темы,
прошу вас поделиться.
Ссылок и статей нет, но есть жизненный опыт. А приведёт это к тому, что проекты будут сдаваться с меньшими отклонениями по стоимости и времени (так как будет более качественно происходить планирование) и удешевлению производства (когда произойдёт большая специализация и задачи типа ,как вы выразились, НИОКРбудут сначала уходить на проектировщиков, а потом на программистов, при этом стоимость программистов упадёт).
Не понимаю, где в программировании творческая составляющая? При правильной организации труда это обычная работа.
Про софт на букву Б не уверен, но есть примеры успешных компаний, которые используют трекеры времени, и те, которые не используют их.
Для чего используют это, я не знаю.
Пример одной из компаний, которые следят за временем - Jetbrains.
В принципе не вижу ничего вредного в самом факте трекинга времени, главное чтобы руководитель понимал, что разработчик пишет код не 100% своего времени.
Я хотел бы внести уточнение. Руководителю нужен не трекинг времени (во сколько пришёл, во сколько ушёл - это уже и так имеется и работает), а знать, какое количество времени заняла та или иная поставленная задача. Но так как большинство задач имеют характер опытно-конструкторской разработки, а также исследовательской деятельности, и во многом уникальны и не похожи на предыдущие задачи, то мы имеем большое количество неопределённостей, и тут вообще не ясно как их учитывать и сравнивать друг с другом.
Если вы знаете статью, которая показывает всю бесполезность временного учёта творческой работы, то прошу вас поделиться ссылкой.
а знать, какое количество времени заняла та или иная поставленная задача
Это я и имел в виду. На одной из прошлых работ мы тоже так делали - Сначала записывали примерный эстимейт, сколько времени задачу будешь делать, а потом в конце дня от этого естимейта убавляли часы, сколько ты над этой задачей работал.
Из этого можно было делать выводы о загрузке команды.
Но так как большинство задач имеют характер опытно-конструкторской разработки, а также исследовательской деятельности, и во многом уникальны и не похожи на предыдущие задачи, то мы имеем большое количество неопределённостей, и тут вообще не ясно как их учитывать и сравнивать друг с другом.
Если всё действительно так (а я не верю в это), то тогда да - в вашем случае отслеживание времени плохо подходит.
В любом случае - можно выделить этап исследования/проработки/декомпозиции задачи в отдельный этап и получить уже набор типовых и нетиповых задач.
Ну и опятьже - эстимейт заполняет разработчик и он уже сам прикидывает, сколько времени у него всё займёт.
Ну а бесполезность в вашем случае - это отсутствие пользы.
Я бы реально попробовал бы командой пару недель поработать с этим - если пользы не найдёте, то выкидывайте эту идею.
Буду краток, поскольку стучу по смартфоне.
Свежее и доступное лекарство для лечения вашей боли размещено на странице 5 корпоративной еженедельной газеты "Вести КАМАЗА" #2(4024) от 29.01.2021.
А подобных на заданную тему с десяток.
Не благодарите, поскольку заточен на данный вектор, как ваш знакомый босс:-)⁹
