Комментарии 13
НЛО прилетело и опубликовало эту надпись здесь
Меня самого подбешивала иногда необходимость трекать время в конце дня. С точки зрения разработчика это скорее зло. С другой стороны, трекинг все-таки способ, хоть и слабый, держать фокусировку. Второй плюс трегинга для разработчика возникает тогда, когда случаются разборки — а что это мы тут 3 месяца делали, и ничего не сделали? Залез в трекер и сразу видно — вот совещались, еще совещались, сервер падал, требования менялись… Все ходы записаны. А от пристального внимания эффективного менеджера никто не застрахован…
Что же касается менеджерского взгляда (не эффективного), то трекер позволяет решать гораздо большее число задач. Во-первых, трекер позволяет действительно работать по задачам. Если каждый сотрудник записывает время, то это стимулирует заводить задачи в трекере. Во-вторых, оптимизация непроизводительных затрат времени. Те же самые совещания. Взгляд на совещания совершенно меняется, когда возникает понимание того, сколько на них убивается времени. В одной из компаний РП любили брать с собой на совещания к заказчику по 2 аналитика. На совещания по любым темам. На мой вопрос — «зачем»?, ответ был простым — а вдруг заказчик какой-нибудь вопрос задаст… Изменить ситуацию помог трекер, когда топы увидели сколько такие совещания стоят компании. В-третьих, немного лучшая предсказуемость. Если при списании времени указывать оставшиеся, можно увидеть, где мы находимся.
По совокупности, плюсы трекинга времени, на мой взгляд, перевешивают минусы. В среднем. Для зрелых сильно мотивированных команд может быть обратная ситуация.
И еще важный поинт. Трекинг времени это, главным образом, не о слежке и стоянии за спиной. Если мы хотим иметь объективную картину, нельзя трекинг использовать с карательной целью
Что же касается менеджерского взгляда (не эффективного), то трекер позволяет решать гораздо большее число задач. Во-первых, трекер позволяет действительно работать по задачам. Если каждый сотрудник записывает время, то это стимулирует заводить задачи в трекере. Во-вторых, оптимизация непроизводительных затрат времени. Те же самые совещания. Взгляд на совещания совершенно меняется, когда возникает понимание того, сколько на них убивается времени. В одной из компаний РП любили брать с собой на совещания к заказчику по 2 аналитика. На совещания по любым темам. На мой вопрос — «зачем»?, ответ был простым — а вдруг заказчик какой-нибудь вопрос задаст… Изменить ситуацию помог трекер, когда топы увидели сколько такие совещания стоят компании. В-третьих, немного лучшая предсказуемость. Если при списании времени указывать оставшиеся, можно увидеть, где мы находимся.
По совокупности, плюсы трекинга времени, на мой взгляд, перевешивают минусы. В среднем. Для зрелых сильно мотивированных команд может быть обратная ситуация.
И еще важный поинт. Трекинг времени это, главным образом, не о слежке и стоянии за спиной. Если мы хотим иметь объективную картину, нельзя трекинг использовать с карательной целью
НЛО прилетело и опубликовало эту надпись здесь
Часики в таймщитах рисовать, действительно не занимает много времени. Только, в большинстве случаев, там будут приписки и прочие манипуляции. Более того, программистам становятся выгодны большие таски и становится невыгодно разбивать задачи на подзадачи. И под прикрытием одной большой задачи идёт куча мелких фиксов и рефакторингов, зато можно наделю в такую задачу "восьмёрочки" рисовать.
Запретите такие активности без отдельных задач? Тогда у вас не будет ни задач не мелкофиксов.
Ежедневный отчёт в формате рассказа коллегам о том над чем работал и что изменилось — намного более эффективный способ коммуникации и мотивации, чем рисование восьмёрочек. А если эти отчёты постить в канал слака, то по ним можно искать.
Проблема работы на удалёнке не решается злобной отчётностью.
Удалённая работа требует более высокой культуры труда, например, умение обсуждать проблемы письменно. И решается через обучение, а не через таймтрекинг.
Согласен, поле для манипуляций огромное. Ответил на предыдущий комментарий о целях трекинга. Отчетность не должна быть злобной) В принципе, чем отличается постинг отчетов в канал слака от учета времени в трекере?
Поддерживаю: тайм трекинг — это очень хороший способ прикрыть себя, когда дела на проекте идут плохо и дело пахнет поиском козла отпущения. Только лучше на таких проектах не работать.
Отчёты в слаке пишутся для коллег, чтобы держать их в курсе дела.
Таймщит заполняют для менеджера, чтобы он видел восмёрочки и сороковочки и не ел мозг.
По опыту могу прокомментировать, что ежедневный отчёт в том или ином виде хорошо работает. Отчёт по времени тоже работает, но пользы от него меньше и как верно заметили выше существует огромный потенциал для манипуляций. Самое главное внедрять эти вещи очень нежно, мягко, но и настойчиво, при этом не жестить с бюррократией/контролем, в таком случае велики шансы получить положительные эффекты и оставить волосы разработчиков мягкими и шелковистыми.
Плохая система отчётов хуже чем вообще никакой.
Думается, что умного лентяя отчёты не поменяют, а у нормальных работников только время отнимут.
Менеджерам, конечно, без отчётов никуда.
Везде где я работал по таймтрекингу часы писал «как надо».
Чтобы выходило 40 часов в неделю.
Особо не напрягало, но толку не было никакого.
Точнее толк был только, что по этому времени начисляли ЗП.
На продуктивность и решение задач никакого влияния не оказывало.
Чтобы выходило 40 часов в неделю.
Особо не напрягало, но толку не было никакого.
Точнее толк был только, что по этому времени начисляли ЗП.
На продуктивность и решение задач никакого влияния не оказывало.
Далеко не всегда понятна эффективность трекинга времени по часам при разработке.
Лично я не приверженец трекинга по часам по следующим причинам:
1) Нужны лишние телодвижения, что бы вбить время. Не всем это нравится или просто забывается.
2) Иногда это давит, и кажется, что ты в заложниках какой-то бюрократической системы.
3) Трекинг никак не защищает от обмана. Разработчик может проставить 8 часов, но на деле работать 5 часов. Такое даже путать лидов может.
4) Трекинг времени в разработке не подходит для аналитики выполнения конкретных задач. Во первых, в следующий раз разработчик сделает туже задачу быстрее или даже скопипастит готовые участки. Во вторых, новые задачи нельзя оценивать с расчетом на прошлый трекинг времени, так как задача другая, проблемы неизвестны и так далее. Менеджеров собьет с толку, а разработчик все равно поставит эстимейт основываясь на личном опыте.
На мой взгляд лучше трекать спринты, эпики, релизы и т.п., выявляя слабые стороны разработчиков на среднесроке и долгосроке. Понимать, где эстимейты и сроки были упущены, по каким причинам и так далее. Так же среднесрочный трекинг времени позволяет лучше планировать риски. Например планировать возможность заболевания разработчика или же запас времени на баги не получится при краткосрочном планировании. Только при планировании на чуть большие куски работы.
При этом есть минус. Лиду или ПМу нужно тратить отдельно время на анализ спринтов и релизов.
А вот трекинг времени по часам для всяких художников, UI дизайнеров и прочим людям, чья задача может различаться, но процесс и время выполнения примерно одно и тоже. Например задизайнить окошко длится 10 часов. При этом не важно, что за окошко, оно всегда у человека выходит +- 10 часов. ПМу тогда не нужно уже спрашивать, сколько это займет, он сам может спланировать 10 часов на будущие окошки.
В остальном я не понимаю цель трекинга по часам. Считаю это каким-то пережитком прошлого.
Лично я не приверженец трекинга по часам по следующим причинам:
1) Нужны лишние телодвижения, что бы вбить время. Не всем это нравится или просто забывается.
2) Иногда это давит, и кажется, что ты в заложниках какой-то бюрократической системы.
3) Трекинг никак не защищает от обмана. Разработчик может проставить 8 часов, но на деле работать 5 часов. Такое даже путать лидов может.
4) Трекинг времени в разработке не подходит для аналитики выполнения конкретных задач. Во первых, в следующий раз разработчик сделает туже задачу быстрее или даже скопипастит готовые участки. Во вторых, новые задачи нельзя оценивать с расчетом на прошлый трекинг времени, так как задача другая, проблемы неизвестны и так далее. Менеджеров собьет с толку, а разработчик все равно поставит эстимейт основываясь на личном опыте.
На мой взгляд лучше трекать спринты, эпики, релизы и т.п., выявляя слабые стороны разработчиков на среднесроке и долгосроке. Понимать, где эстимейты и сроки были упущены, по каким причинам и так далее. Так же среднесрочный трекинг времени позволяет лучше планировать риски. Например планировать возможность заболевания разработчика или же запас времени на баги не получится при краткосрочном планировании. Только при планировании на чуть большие куски работы.
При этом есть минус. Лиду или ПМу нужно тратить отдельно время на анализ спринтов и релизов.
А вот трекинг времени по часам для всяких художников, UI дизайнеров и прочим людям, чья задача может различаться, но процесс и время выполнения примерно одно и тоже. Например задизайнить окошко длится 10 часов. При этом не важно, что за окошко, оно всегда у человека выходит +- 10 часов. ПМу тогда не нужно уже спрашивать, сколько это займет, он сам может спланировать 10 часов на будущие окошки.
В остальном я не понимаю цель трекинга по часам. Считаю это каким-то пережитком прошлого.
Flakky, спасибо за комментарий и аргументы! Трекинг времени очень неоднозначная процедура, поэтому разные позиции и взгляды придают вопросу объем и глубину. По Вашим пунктам 1 и 2, с одной стороны да, все так. Но с другой стороны — человек сидит на удаленке и он физически оторван от команды и компании, где работает. Необходимость «не забыть» внести время и элемент формальности процесса, в какой-то мере создают официальную рамку взаимоотношений между сотрудником и компанией. Где есть какие-то обязательства компании и обязательства сотрудника. Это мягкий способ напомнить о формальной стороне отношений, о том что «я сотрудник этой компании». Ежедневный отчет по времени, в дополнение к другим своим функциям, является в некотором смысле ритуалом. Если же посмотреть еще глубже, то любое руководство строится на основе ритуалов, привычек и поведенческих шаблонов.
По 3-му пункту тоже интересно. Если рассматривать разработчика изначально как зловреда, который хочет обмануть компанию, то да — отчет по времени никак его на чистую воду не выведет. Я же придерживаюсь мнения, что люди без необходимости не врут. Т.е. если создать культуру не карательного использования отчетов по времени, то можно получить более-менее объективную картину. А объективная картина происходящего для менеджера очень и очень ценна. Меня не очень сильно беспокоит, если кто-то в отдельный день запишет 8 часов вместо 5. Если такие отклонения статистически малы, то и… В магазинах тоже же есть норма по воровству товаров с полок. Для измерения же эффективности и прогнозирования будущего тайм трекинг инструмент негодный, есть другие.
Если же говорить об аналитике, то объективный тайм трекинг позволяет понять, на что ушло время. И сделать, при необходимости, управленческие выводы, чтобы в будущем уменьшить ненужные его расходы. Мы же все прекрасно знаем, что в той же разработке, очень много времени пропадает впустую — совещания, инфраструктура, неверные требования и т.д. В каждом проекте будут свои боли. С ними руководитель и должен работать в порядке приоритетности. Тайм трекинг позволяет определить, на что больше всего теряется времени, а значит именно эти дыры нужно затыкать
Учет времен — инструмент руководителя. Применять его нужно осмысленно. Является ли он пережитком прошлого? Возможно. Сейчас активно двигается идея дебоссинга, т.е. работы без руководителя. В этом случае применимость такого рода инструментов, действительно, под большим вопросом. Самоорганизующейся команде трекинг скорее не нужен. Практика же показывает, что дебоссинг пока достаточно нишевое явление с неоднозначной эффективностью. Но это другая история)
По 3-му пункту тоже интересно. Если рассматривать разработчика изначально как зловреда, который хочет обмануть компанию, то да — отчет по времени никак его на чистую воду не выведет. Я же придерживаюсь мнения, что люди без необходимости не врут. Т.е. если создать культуру не карательного использования отчетов по времени, то можно получить более-менее объективную картину. А объективная картина происходящего для менеджера очень и очень ценна. Меня не очень сильно беспокоит, если кто-то в отдельный день запишет 8 часов вместо 5. Если такие отклонения статистически малы, то и… В магазинах тоже же есть норма по воровству товаров с полок. Для измерения же эффективности и прогнозирования будущего тайм трекинг инструмент негодный, есть другие.
Если же говорить об аналитике, то объективный тайм трекинг позволяет понять, на что ушло время. И сделать, при необходимости, управленческие выводы, чтобы в будущем уменьшить ненужные его расходы. Мы же все прекрасно знаем, что в той же разработке, очень много времени пропадает впустую — совещания, инфраструктура, неверные требования и т.д. В каждом проекте будут свои боли. С ними руководитель и должен работать в порядке приоритетности. Тайм трекинг позволяет определить, на что больше всего теряется времени, а значит именно эти дыры нужно затыкать
Учет времен — инструмент руководителя. Применять его нужно осмысленно. Является ли он пережитком прошлого? Возможно. Сейчас активно двигается идея дебоссинга, т.е. работы без руководителя. В этом случае применимость такого рода инструментов, действительно, под большим вопросом. Самоорганизующейся команде трекинг скорее не нужен. Практика же показывает, что дебоссинг пока достаточно нишевое явление с неоднозначной эффективностью. Но это другая история)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удаленка. Работающие принципы управления