Разработчик недисциплинированно трекает время. Что делать?

Здравствуйте!

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

Меня , как менеджера, такое положение вещей не устраивает - меня интересуют правдивые метрики и я не хочу тратить время на ручное управление

Чтобы решить эту проблему, я рассмотрел ее возможные причины:
  1. неудобный трекер
  2. боязнь "не набрать нужное количество часов"
  3. боязнь "выйти за оценку"
  4. микроменеджмент
  5. форма оплаты


И что у меня получилось

Неудобный трекер
С проблемами логгирования времени я сталкивался и в проектах, где были объективно неудобные инструменты (Битрикс, самописные CRM), так и более привычные инструменты (Redmine, Jira, Tempo). Поэтому эту причину я отклонил.

Боязнь "не набрать нужное количество часов" и боязнь "выйти за оценку"
Для разработчиков я установил планку в закрытие задач, оцененных на 4 часа в течение 8-часового дня. При этом разработчик может логгировать больше времени на задачу, чем было оценено, если возникли какие-то трудности. Я считаю, что такие условия должны убирать эти фобии, поэтому эти причины я отклонил

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

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

Как итог я понял, что я не знаю как выстроить этот процесс и не знаю, как добиться того, чтобы все разработчики во время трэкали свое время без лишниз напоминаний

Мне бы хотелось услышать ваши советы по тому, как можно улучшить этот процесс.
  • Вопрос задан
  • 11675 просмотров
Решения вопроса 1
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
А зачем вообще трекать время? Уложился в дедлайн - молодец. Не уложился - разбор полётов. Хронически не укладывается - понижение грейда или увольнение.
Ответ написан
Пригласить эксперта
Ответы на вопрос 36
Xuxicheta
@Xuxicheta
инженер
Не выносить мозги разработчику своим трекингом и дать ему спокойно работать.
Не справляется - увольняйте.
Ответ написан
php666
@php666
PHP-макака
Упаси бог работать в столь токсичной среде.
Сидеть и отчитываться за каждую минуту/час.
Идеальный информационный концлагерь.
Ответ написан
BasiC2k
@BasiC2k
.NET developer (open to job offers)
Вы рассмотрели возможные причины "со своей колокольни" и сами дали на них ответ. Что показывает Ваш авторитарный (директивный) стиль управления.
Постарайтесь быть ближе к подчинённым, разговаривайте с ними, вникайте в их проблемы. Тогда они сами расскажут - почему они не трекают, а Вы поймёте как это решить.
Сейчас у Вас нет обратной связи.
Ответ написан
Комментировать
Sanes
@Sanes
Фигня все эти трекеры. Если вы друг-другу не доверяете, то уже ничего не поможет.
Разработчику тоже не упало постоянно страдать с этими трекерами. Ему проще в конце дня примерно затраченное время записать.
Редко бывает, когда линейно работаешь. Постоянно дергаешься от одной задачи к другой. Если это не так, то и трекер не нужен.
Ответ написан
Robur
@Robur
Знаю больше чем это необходимо
основные вопросы на которые надо найти ответ:

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

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

В общем, я считаю, что у Вас на корню подход не правильный. Ваше собственное нежелание изучать детально людей при приёме на работу и привело к недоверию в момент работы.
Ответ написан
Комментировать
nki
@nki
bezkart.ru готовая система лояльности
Поэтому эту причину я отклонил.

Я считаю, что такие условия должны убирать эти фобии, поэтому эти причины я отклонил

поэтому эту причину я тоже отклонил

А поговорить с разработчиками не пробовали? Может вы о чем-то даже не подозреваете?

не знаю, как добиться того, чтобы все разработчики во время трэкали свое время без лишниз напоминаний

Оплачивайте задачи по данным из трекера.
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
Как итог я понял, что я не знаю как выстроить этот процесс и не знаю, как добиться того, чтобы все разработчики во время трэкали свое время без лишниз напоминаний


это стоит больших денег
без шуток
примерно вашу годовую зарплату

поэтому не опускайте руки - быстро добиться не получится
Ответ написан
@zakirovdamir
Ооооо, да у нас тут менеджер с претензиями))) нужно принимать результат, а не контролировать процесс и заниматься прочим мозголюбством а если не знаешь, сколько примерно времени нужно выделять разрабу на ту или иную задачу, чтобы не трястись с секундомером за его спиной — то это не его проблема, а твой косяк
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Если оценка превышает запланированную более на 30 процентов

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

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

Если же хотите математику - готовьтесь к тому, что у вас будет большая текучка, пока вы не сможете укомплектоваться молодцами, одинаковыми с лица, то есть примерно одинаковыми. Но это займет уйму времени (то есть денег). Собственно одна из работ менеджера состоит в том, чтобы правильно распределиться ресурсами, а это в том числе и людьми.
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
Как на счет того чтоб выкинуть из рабочего процесса всю чепуху, которая не способствует созданию продукта?
Но если уж так хочется, почему бы самому тогда не трекать, по факту сдачи задач. Трекайте просто перфоманс разработчика в целом (сколько тасок сдал за неделю/месяц).
Разрабам этим трекинг объективно не нужен, он ни о чем не говорит и ни на что не влияет.
Ответ написан
@dplsoft
вы, если вы хороший менеджер, вы должны, наверное, понимать, что недоверие и чрезмерный контроль - становятся слишком накладными в плане трудозатрат. почитайте почему в китае работает практика "ту-ань-ши" кажется, когда в громадной компании всего 3 уроня управления - и у каждого менеджера по 40 замов, и почему этого нет в американо-европейской практике, где 1-2-3 зама - это "норма", и в итоге управленческий аппарат раздувается на множество слоев.

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

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

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

вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
почему вас не устраивает скажем 10% погрешность в этих значениях?

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

и более того - это как раз и есть ваша работа как менеджера - следить за этим.
если бы все люди сами все делали автоматически и честно - тот же фрилансер всегда сам правдиво, точно и по расписанию все заполнял - вы стали бы ненужной прослойкой.
Ответ написан
Из-за подобных подходов к менеджменту разваливаются команды.
Ответ написан
@SODINNER
У нас компания достаточно маленькая, но что сделал мой начальник: Он написал простой сайт, куда мы записываем имя компании и потраченное время + проведённую работу. Выполнил задание - добавил на сайт и клиент получает счёт на эти часы. Оплату мы берём за единицы по 15 минут, то есть 3 часа работы это 12 единиц по определённому прайсу, в данном приложении вписываем собственно кол-во единиц.
Ну и в принципе всё, тут люди говорят что это всё дело на менеджерах, а не на кодерах и нужно дать причину кодерам трекать своё время, но меня с самого начала приучили делать это и я принял это как должное, как одну из обязанностей работы. Но тут всё таки нужно верить каждому на слово, если есть недоверие - этот метод не подойдет. Но он самый простой и легкий, написать такой сайтик вообще труда не составит.
Но допустим даже работник чуть приувеличил кол-во часов, вписал вместо 4 часа - 5 часов, это разве страшно? Вы же не платите почасово разработчику деньги за проделанную работу, а наоборот, платят вам клиенты. Как дело они не разбираются и такая практика применяется везде, у кого-то меньше, у кого-то больше, но в основном везде. А так в ИТ очень сложно определённо сказать сколько времени займет та или инная задача, ибо уровень квалификации у каждого человека разный, да и мало ли какое рабочее пространство, то никто не будет спорить 4 там часа или 5 часов надо оплатить. Ну это глупость.
Всё зависит от вашей компании, у нас работает такой метод и весьма успешно.
Я лично знаю какой прайс выставляется клиентам и когда проделываю работу на определённое кол-во единиц, сразу понимаю что я как минимум заработал для компании больше, чем мне выплатят за этот день и уже могу спокойно выполнять другие задачи, не загоняя себя.
Ответ написан
Комментировать
@Mirtopir
Все упирается в деньги.
Хорошо бы с заказчика взять за 10 часов, а чтобы прогер закрыл задачу за 1 час ну и трекнул, что все, харе мне платить. Вот на эти 2 % и живем. Правильно?
Вам не нужно время. Вам нужны деньги! И что самое интересное, исполнителям тоже нужны деньги. Сдельщина за задачи, а не за часы.
Да, вы получите тяжело поддерживаемый код, но вы же сами этого хотели!
Ответ написан
Комментировать
@0x131315
Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.

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

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

Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

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

Советы, если это вам реально надо:
- автоматизируйте максимально, лучше всего ориентируясь на статусы задач в джире, обеспечив их достоверность (не допускать отсутствие активных задач, не допускать несколько активных задач одновременно, не допускать работу над "чужими" задачами и т. п.). Можно какого-то чат бота завести, который раз в час будет спрашивать "над какой задачей работаешь? "
- не просто объясните зачем это вам надо, а регулярно показывайте, что вы это используете для заявленных целей и заявленную пользу приносит, например на дэйли митингах разбирайте сколько часов команда отработала за прошедший день и выявляйте причины отклонений от плана
Ответ написан
samodum
@samodum
Какой вопрос - такой и ответ
На удалёнке забудьте про трекинг времени. Людям зачастую неудобно работать по обычному "рабочему" графику работы и поэтому они выбирают наиболее удобные для себя часы времени: кому-то удобно днём, а кому-то вечером-ночью-утром, когда дети с женой спят и отвлекающих факторов минимум. Тогда они могут отработать более 12 часов. Нужны ли вам эти переработки?
С другой стороны, некоторые разрабы пренебрегают удалёнкой и откровенно халявят, прокрастинируя по максимуму. Таким нужно ставить срок выполнения задачи - 2-3-5 дней, в зависимости от сложности. Не управился - минус. Набрал критическую массу неудовольства - кандидат на выбывание. Благо, безработных сейчас масса и рабочие руки найдёте быстро.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Задача дедлайна (а не разработчика!) - трэкать производительность и исполнительность разработчика.
Задача ПМ - трэкать проценты исполнения (этапы) по текущим работам в текущей вехе проекта (и планировать следующую). В случае каких-либо задержек - быстро выявлять конкретную проблему и решать её без срыва сроков реализации всего проекта (или вехи).

Просить кого-то трэкать время каждый час вручную (или ставить софт) - это крайне глупо!

lahomie93, встречный вопрос: за что именно я получаю деньги:
1. За потраченные часы?
2. За выполненные задачи?
3. И как и кто именно оценивает их сложность?

UPD: в моём блоге (линк под ником) этот вопрос и ответ на него подробно освещён.
Ответ написан
Jump
@Jump
Системный администратор со стажем.
Вообще не понимаю людей которые используют трекеры. Ну как животные.
Как можно так работать? И какое собачье дело работодателю может быть до времени работы.

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

теперь совет вам

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

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

p.s. если уж очень хочется учитывать время - автоматизируйте этот процесс.
Ответ написан
@Lord_Dantes
Всех кидаете в один канал по трекингу времени. Время от времени пишете в канал чтобы все трекнули время. Те кто хорошо справляется можете убирать чтобы не мешать им, других же принудительно заставлять - нет штраф и тд.
Это не шутки, вы платите деньги за работу, а не за время с воздуха.
Ответ написан
@Camill
Если трекать время действительно необходимо кровь из носа, то можно не принимать (в смысле не закрывать) задачи, в которых нет затреканного времени.

Но вы, кажется, к проблеме подошли не с того конца. Главное - объяснить людям, зачем ИМ это нужно. Если объяснить не получается - может, проблема не в том, что они ленивые.
Ответ написан
@strelok011
Хм. Как же яростно народ отстаивает свое желание не сидеть на поводке :)

Опишу работу на галерах:
есть счетчик типа апворка (их хватает), трекает время с скриншотами. Разработчик меняет таски в трекере,
каждые 2 часа меняет мемо (комментарий в трекере), в трелло/жире меняет активную таску по мере выполнения. Одновременно в работе не более одной, внутри таски чекпойнты, требуемые для реализации для более четкого понимания.
Работа по аджайлу, скрам. Требуется планирование задач на спринт, примерная оценка в часах или условных единицах. Спринт - неделя или две. Каждый день стендап на 5 мин по итогам предыдущего дня и планинг следующего.
Каждый вечер письменный отчет о выполненных задачах и план на следующий день.
Менеджер проекта следит за прогрессом, если просадка по скорости - вовремя обращает на это внимание, с командой пробует найти решение проблемы либо оповестить заказчика о возникших трудностях.
Оплата - зарплата фикс за работу из расчета 8ч в день по счетчику. Овертаймы - отдельная такса.

Для чего - контора работает на выполнение заказной разработки. Предварительно идет оценка трудоемкости, исходя из планируемых часов выкатывается стоимость заказчику. Соответственно - контроль использованного на задачи времени важен и нужен для оценки менеджером и бухгалтерией - идет работа по плану или начинаем работать в убыток.
Эффективность методики - контора за 5 лет попала в топ 50 рейтинга ИТ по РФ, постоянный рост как проектов так и штата.
Работа не простая, либо становишься эффективным специалистом, либо гуляешь.

В компании тимлиды присматривают за подопечными, если возникают проблемы, ищут возможное решение, помогают.

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

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

Тут пишут 'успел в дедлайн' и прочую чепуху. Вопрос - кто устанавливает дедлайн в ваших конторах? Аджайл подразумевает самоуправление команд разработчиков. Цифры берутся не с потолка. Методики позволяют оценить скорость работы команды, на ретро делают обзор прошедших спринтов, найти решение каких либо проблем, выяснить, успеваем или нет. Все давно придумано, бери и пользуйся.
Если сотрудник не видит необходимости в отчетности, ему не важно, придет ли следующий заказчик, работает на отвали - что он тогда тут делает? Отчетность важна для прогнозируемого результата. Для нормальной работы необходимо сформулировать базовые ценности компании, которые ей позволят выжить и быть эффективной. Нет цели - четыре негра станцуют заупокой.
Ответ написан
Jeer
@Jeer
уверенный пользователь
Очень много интересного почерпнул в этом треде.
Казалось бы, автор задаёт один простой вопрос "почему люди не отмечают затраченное время?". И столько пустой болтовни, ненужных советов, не относящихся к этому вопросу. Размусоливаний каких-то ситуаций, которые у них на работе, но, опять же, абсолютно не относящихся к данному вопросу. Или переход к другой теме, например, много было про оценку задач, да, это интересные всё темы, но это опять же не относится к теме данного поста.
Автор меня приятно удивил, пытаясь вначале отвечать всем и по существу, но уже устал к концу, хотя верные ответы находятся не на самых залайканных ответах.
Одно время я поработал в компании, где после каждой задачи надо было писать отчёт, прикладывая листинг кода! так как реально вообще другой отдел занимался сдачей отчётности (по списанным часам из таких отчётов выставлялся счёт заказчикам) и они даже не в курсе были, чем занимаются программисты. Большего маразма я в жизни не встречал. И когда я стал работать в других компаниях, где надо просто списать затраченное время, я понял, что это прям намного проще и понимаю, зачем это надо менеджменту.
Но тут встретил людей, которые этого не понимают. То есть, в текущей конторе не было такого, что надо списывать время. Многие (из старичков) откровенно саботировали этот процесс, сопротивление просто громадное, одно из лидирующих мнений было, примерно, следующее: "я раньше не списывал время и сейчас не собираюсь, потому что мне это не надо". Понятное дело, что в такой ситуации весь менеджмент и планирование в полной жопе. Ну, мне понятно. И тут возникает главная загвоздка и ответ на этот тред. Вам необходимо, во-первых, правильно объяснить, зачем это надо. Во-вторых, сделать учёт времени неотъемлемой частью процесса.
Аргументов по первому пункту тут уже приводилось много и варианты для конкретного человека могут быть довольно специфичные. Что если сотрудник будет просто списывать время, то уже будет видна его загрузка и можно меньше задач ставить в спринт. Или другой пример, один сотрудник сидит на каком-то проекте и ни холодно ни жарко другим людям списывает он время или нет, но появляется какая-то задача, надо ему сделать апи для другого сотрудника. И эта задача блокирующая, но он её не делает. Отговариваясь на митингах, что занимался другим. "Дружок, я не вижу, чем ты занимаешься, если нет списанного времени, я могу считать, что ты ничем не занимаешься, но при этом блокирующая задача перенесена в другой спринт" - разбор полётов и обоснование для списания времени.
Есть такой тип людей, где-то тут тоже мелькало "я забиваю на списанное время и в конце недели просто рисую цифры с потолка, чтобы отстали". Такое тоже присутствует. Это низкая культура и низкая дисциплина. И с этим тоже можно работать (это относится ко второму пункту). Так же в этом треде предлогались решения, кто-то сказал, что тимлид сказал списывать время в конце дня, как закончил работать. Ну, запретите на программном уровне списывать время за предыдущие дни. Справедливости ради стоит отметить, что иногда вечером не всегда успеваешь это делать, то есть, можно сделать так, что списывать время можно предыдущий день можно до дейли митинга (до 10 утра, к примеру). Если это не происходит, то в присутствии всей команды уточнять, чем человек занимался вчера и напирать на то, что вместо того, чтобы быстренько занести своё время теперь этот человек крадёт время всей команды.
Резюмируя, первое, надо доходчиво объяснить, зачем это нужно работнику (не вам, а ему), второе, необходимо сделать списание времени частью рабочего процесса
Ответ написан
@AMenschikov
Такая же проблема была, но тимлид контролировал и спрашивал ежедневно и все привыкли. Мы это не из за дисциплины делаем, а для улучшения планирования, корректировки коэффициентов и подсчёта стоимостей фичей, ну и непродуктивные задачи типа митингов режем
Ответ написан
Комментировать
@scherbakovmike
У меня были проблемы, что разрабы не чекают время по задачам. Запретил чекать задним числом, и проблема решена. Всё вовремя. Нет времени - нет денег.
Ответ написан
@SlimHouse
Сквозь тернии к звездам
Пока что пришел к тому, что самое эффективное, хотя и не 100% решение - это настроить трекер таким образом, чтобы при переводе в определенные статусы трекер требовал отметить время.

Также нужно на стэндапах/митингах/планерках доносить важность этого, если это действительно важно, и напоминать забывающим перед всей командой.

p.s. был один неизлечимый случай, и этого человека перевел на почасовую оплату (правда были ещё причины для этого). Проблем с трекингом времени теперь нет.
Ответ написан
Комментировать
SerzN1
@SerzN1
Challenge me!
тут уже сказано и не раз - распределение задач и нагрузки является прямой задачей менеджмента, не вижу смысла расписывать остальные вещи

человек приходя на работу подписывается на ЗП в большинстве случаев и ему неважно что он делает а важна лишь мотивация - что тоже задача менеджмента как не странно звучит (ну или самого разработчика если он хочет больше)

ответ прост - инженерам это не надо - это интелектуальный труд, но можно их а) замотивировать/продать и б) автоматизировать процесс (это лучшее решение)

и при этом не имеется ввиду "Я ХОЧУ, Я РЕШИЛ, Я..."
Ответ написан
Комментировать
CellycoMobiles
@CellycoMobiles
indi developer @CellycoMobiles
Была такая проблема. Первый вариант. Был трекер ТаргетПроцесс. Пожалуй худший трекер в мире. Написали хук. Расписывалии задачи по спринту по часам. ПМ контролировал, раз в неделю, чтобы каждый заполнял время.
Ответ написан
Комментировать
nykakdelishki
@nykakdelishki
Системный аналитик
Можно разделить команду на два отряда
1)Получают больше за то что трекают
2)Получают как обычно за то что не трекают
Вот и мотивация
Ответ написан
lukoie
@lukoie
у нас в аутсорснице та же беда есть. Причем есть трекер свой, и есть упорковский. При этом у программиста есть своя виртуалка под каждый проект(ой, не спрашивайте зачем), и программист трекает по двум трекерам. Менеджер в конце недели еще и сводит время, потому что могут быть где-то разница. Программисты получают деньги по двум ставкам - одна по трекеру, вторая по бенчу. Итого, если он не трекал - то его ЗП будет на это время считаться по тарифу бенча.
Но тут есть и другая лажа, когда программисты просто крутят трекер.
А потом их зазывает софтсерв, и показывает что трекеров у них нет - то программисты с радостью туда, потому что отчеты в конце каждого дня писать не надо, трекер крутить не надо, сиди и делай как тебе удобно и когда удобно, главное чтоб был результат.
Короче, платите им по двум ставкам, и у них будет стимул крутить трекер.
Мне, кстати, Toggl нравится. Но у нас и свой есть, своя разработка внутрикорпоративная.
Ответ написан
Комментировать
firedragon
@firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
В разработке есть задачи. Эстимейтите их, назначайте время. При закрытии таска, например при коммите вы автоматически получаете данные. Разработчик если не уложился, редактирует задачу, добавляя время.

Вы имеете список задач, связанный с ТЗ и время на его реализацию. Плюс можете оценивать оценки и фактическое время.

Время контроля от недели до 2 недель. В понедельник проводите совещание, подводите итоги и распределяйте задачи. Для людей на окладе тикет система. Там контролируйте среднюю загрузку в районе 60%.

В общем то сдельщик заинтересован в этом списке, платят ему именно по часам. Да и сам заказчик хочет видеть не эфимерный трек "Работал над подсистемой поиска" в течении 2 недель, а целую кучу подзадач которые видно по логу.
Ответ написан
Комментировать
@spspsp1
Рассчет, сколько разработчик заработал компании выдает в авторе большой опыт в продажах, где разумно оценивать продавца по объему продаж и выполнению плана в деньгах. При отличной работе разработчиков и недоработках аналитиков, отдела продаж, саппорте, дизайнеров, маркетологов компания легко может заработать 0.
Ответ написан
nozd
@nozd
C#
У нас все разрабы, аналитики и тестеровщики регулярно трекают время: или в конце рабочего дня, или в начале следующего рабочего дня. Если тебе сказали трекать - то почему не трекать? Переломишься от этого или что? Разработчик хочет работать, чтобы ему никто не мешал. Так почему не пойти навстречу другому участнику рабочего процесса и, в данном случае, начать регулярно списывать время.
Ответ написан
Комментировать
@denis_s_isaev
Менеджер проектов.
Привет. Это обычное дело в коммерческой разработке. И если хочешь получить нужные метрики, придется за ними побегать. Отлично спасает чат с напоминаниями. Ну и конечно, разговоры. Коммуникации решают все в нашей работе. Разработчики должны понимать, что вы с ними команда, и это часть вашей работы, которая зависит от них. Необходимо много разговаривать, напоминать, прежде чем это войдет в привычку и станет нормой. Я редко встречаю разработчиков, которые не готовы помогать менеджеру. Потому поговорив, объяснив, что это и зачем - все решается. Если человек совсем не идет на контакт, то зачем он нужен команде, частью которой он не хочет быть? Часть корабля - часть команды.
Еще, возможно разработчик не списывает время, потому что не понимает, что конкретно списывать. Иногда считают что надо списывать чистое время по задаче, кодинг. Но это не так. Я рекомендую использовать таймер. Открыл задачу, включил его, думаешь, читаешь, изучаешь, это все работа по задаче. Трекай это время, и честно пиши, что изучал бэк... Если сотрудник не может описать чем занимался в течении дня, это звоночек, он может быть плохо организован, а это автоматом говорит что в оценки он не попадет, и сроки поедут. Или обманывать, а такой нам совсем не нужен.
Ну и встает вопрос авторитета на проекте, менеджер основное ответственное лицо на проекте, и если разработчики его не слушают, либо он сам что то делает не так, либо культура в компании такая, и это необходимо эскалировать.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы