Comments 8
Статью стоило назвать - "Как превратить разработчиков в рабов в кандалах тайм трекера", "Практикуем галерный подход к организации работы разработчиков","Как заставить разработчика писать код под бой барабаны менеджера" и т.д.
Можно проще
Для чего нужен тайм-трекер
Не нужен. Расходимся.
В целом, да, контроль рабочего времени, особенно в крупных компаниях, можно воспринимать и как галерный подход, недоверие к сотрудникам и тд, особенно если есть требование с отправкой скриншотов, я вполне могу понять такое отношение, с другой стороны, если Вы работаете в команде вовлеченных людей, сами вовлечены в проект и хотите, что бы менеджер управлял задачами грамотно, без нервотрёпок и горящих дедлайнов, то Вы должны понимать, что без точной статистики по затратам времени на задачи, сложно построить burnup и burndown, что влечет за собой существенное ухудшение качества планирования, потому что эстимейты начинают выдаваться не эмпирически, путём расчета по этим самым графикам, а пальцем в небо, а когда вы выдаёте желаемое за действительное, а не рассчитываете прогнозирование по конусу неопределённости между пессимистичным и оптимистичным трендами, вот тогда здравствуйте горящие дедлайны, переносы сроков, переполнение спринтов, рост техдолга, пыль в глаза заказчикам, вместо реальных оценок сложности и сроков, нервы, демотивация, падение качества рабочего процесса для всех и каждого на проекте. Если Ваш менеджер не объяснил Вам, зачем нужен таймтреккинг, то он либо реально относится к нему так же как и Вы "что бы Вас, рабов несчастных, контролировать!!!" )) и тогда меняйте менеджера, или валите из такой компании, либо он у Вас правильный менеджер и просто надеется на то, что Вам, как вовлеченному в проект интеллектуалу, понимающему важность инженерного подхода к планированию, прогнозированию и управлению проектами, не надо объяснять такие вещи.
Просто удивительно, как много этой пакости. Едва ли не больше, чем IDE или редакторов изображений...
А адепты этого дела никак не могут понять, что если они ничего не могут, кроме как трекать время, то ничего и не получат, кроме треков времени. Если вы не в состоянии оценить количество и качество выполнение исполнителем задач с точки зрения нанесения пользы, то и трекеры очевидно не помогут. Снова хочется процитировать Лаврова...
"Адепты этого дела", поверьте, вполне себе могут пилить качественный код в очень комфортном режиме, с эмпирическим прогнозированием, без переработок, с честными оценками сроков и сложности перед заказчиком, потому что рассчитываемыми на основе статистики, а не выдуманными, с возможностью разработки реально крупных и сложных проектов довольно большими командами программистов и всё это в атмосфере на столько гибкого графика, когда члены команды работают как им вздумается, тратят времени, сколько посчитают нужным, могут при необходимости редактировать свой трекинг, ощущая себя свободными от какого либо контроля, делая это, потому что понимают, зачем это необходимо на самом деле. Да, есть конечно и те, кто не шарит и использует этот софт как надзирателя за нерадивыми сотрудниками, или у которых на менеджмент времени уходит больше, чем на "нанесение пользы", как Вы выразились, но это не понимающие суть профессионального управления проектами команды, которые чаще всего пилят мёртворожденные проекты, выпускают на рынок быстрые, в стиле ХХП (культурно если, то Хоп-Хоп и Продакшн) поделки, что бы взлететь на хайпе, скамануться и мать его так, либо "я сделяль" продукты и тд.
Хотите сделать большой, сложный, качественный продукт профессионально? вот Вам вводная: https://www.youtube.com/watch?v=mIVRFYjIZ5A
Там про таймтреккинг, конечно, на прямую ничего не говорится, но из контекста думаю поймёте, где он подразумевается.
ничего не могут, кроме как трекать время,
Запуск треккера - это 1 секунда (клик в трее), потом 4 часа кодинга, потом 1 секунда стоп, кофеёк там, пара видосиков, чатик с друзьями, ... О! идея! 4 часа кодинга, о блин, не затрекал, 1 минута, добавить треккинг вручную
Так что не надо тут из мухи слона делать, это просто Вы не можете осознать, что треккинг - это не потому что Вам не доверяют, или контролировать хотят, а для того, что бы Вам не пришлось в какой т о момент в будущем фигачить сутками в диком овертайме, потому что сроки были выставлены гаданием на кофейной гущи, а не инженерными расчетами.
Эк вас зацепило-то... Через полгода, и такая простыня.
И вы почему-то пишете с позиции разраба:
>"Адепты этого дела", поверьте, вполне себе могут пилить качественный код
>Запуск треккера - это 1 секунда
в то время как я про тех, кто насаждает внедрение этого дела, код не пишет, и трекеры не запускает, а заставляет запускать. Какое-то странное, на мой взгляд, недопонимание...
В подавляющем большинстве случаев, с которыми я сталкивался лично или опосредованно, руководство, внедрявшее или пытавшееся внедрить трекеры, не было в состоянии оценить работу своих подчиненных иначе, как по совершенно нерелевантным параметрам: жопо-часам, количеству нажатий на клавишу в час и тому подобному мусору. При этом они (будучи не в состоянии понять суть работы) именно что не доверяли исполнителям. К тому же измеримые параметры работы, такие, как время и пробег мыши, можно использовать для манипуляций (совсем недавно я работал на предприятии, где за опоздание на 1 секунду надо было совершить ряд телодвижений для возможности вообще попасть на рабочее место, а потом писать объяснительную или брать отгул на час-другой задним числом).
Использование тайм-трекеров для оценки прогнозируемого времени разработки я не встречал ни разу даже в разговорах. Но допустим, это бывает. Тогда:
А) на какого <cenzored> в куче этих трекеров заодно скриншоты и вебкам, а также активность клавы, если я половину работы делаю пером в блокноте?
Б) Что же вы не трекаете кофеек и чатик, если они нехило способствуют приходу в голову упомянутой идеи?
В) в процессе работы над действительно серьезной и интересной задачей я не прекращаю фоновую работу над ней даже в ванной, на горшке, в койке засыпая, в бассейне плавая и все такое. Как учитывать?
Г) как учет времени на разработку, скажем, имитатора сигнала радиолокатора поможет вам спрогнозировать время на разработку, скажем, системы управления манипулятором? Или у вас исключительно однотипные задачи?
Короче, по моему опыту трекеры не помогали ни разу, где их использовали без ума - они только мешали, а где с умом - можно было обойтись без них.
И вдогонку - оценка времени прекрасно выполняется по системе контроля версий. Вот там честно появляется выполненная [под]задача не раньше, чем она действительно сделана, с учетом всех кофе-брейков, чатов, раздумий на горшке и последовательности всех ранее выполенных [под]задач. Если есть система управления проектами, к которой подключен, скажем, гитлаб, то все поставленные задачи отлично трекаются от момента постановки через появление в репе и до пасс-тестирования. Это было великолепно, но к сожалению, лишь раз в моей практике. И таки да, в той компании был тайм-трекер. Но он был формальностью (больше как бы для бухгалтерского учета) на него никто не смотрел, по нему никто никаких решений не принимал. Похоже, это был рудимент...
промахнулся
ТОП-20 тайм-трекеров, которые сделают работу вашей команды продуктивнее