Кто работал в аутсорсе, прекрасно знают, что такое отчет о потраченных часах. Вроде логично, клиент платит за часы, вот вам точная цифра. Надо оценить работу сотрудника – легко: 168 – хорошо, 188 – ай-яй, перерабатывать нельзя без разрешения, 160 – придется отработать. До какого маразма это иногда доходит, аудитория и сама знает.
Почему это становится проблемой для разработчика?
По теории, разработчик ежедневно логирует часы. Т.е. он в конце дня все задачи помнит и для него это раз плюнуть.
В реальности все не так просто:
1) Надо придумывать название таска. Это не всегда так тривиально как кажется.
2) Есть задачи, которые длятся 1, 5, 10 минут и логировать их невозможно.
3) В команде, в которой идет активная разработка или суппорт в 18:00 рабочий день частенько не заканчивается. Т.е. если проекту, ПМу или клиенту удалось действительно заинтересовать команду в работе, начинает страдать отчетность, и, несмотря на результаты, в отчетах все плохо и программист все равно сделал опять что-то не так.
В результате, с опытом, разработчик осваивает умение смело обощать задачи и округлять время в большую сторону, а потом так же уверено отстаивать запощенное время, если клиент решил просмотреть цифирки в отчете. Так, а какой тогда в этом смысл?
Что нас спасет?
На помощь приходит планирование. В идеале все заранее спланировано, задачи задокументированы и эстимейты проставлены надолго вперед, но это встречается все реже и реже в реальной жизни, да и зачастую не оправдано или восем не реализуемо. В аутсорсе же сейчас очень популярно слово Agile. Умные головы придумали иттеаративный подход разработки, планирование иттерация и ежедневные статусы. Такое планирование значительно проще. От этого выигрывают многие, в том числе и разработчик. У него появляется большее понимание задач и личные планы.
Там где одновременно есть иттеративное планирование и логирование часов, команда один раз в отчетный период делает бестолковую работу по перекладыванию планов в отчет о потраченных часах в виде тасков и часов. Уже легче, но все также бессмысленно. Опять же приходится округлять и подгонять под ответ. Да и работает не везде, иногда клиент смотрит отчеты по результатам недели, а иногда и чаще.
А что если забыть про часы, к которым мы так привыкли и сфокусироваться на задачах и их выполнении? Команда планирует работу на период, на этом этапе все стороны приходят в согласие, что надо сделать и в какие сроки. В процессе работы над итерацией менеджер мониторит состояние дел по статусу задач (открыта, в прогрессе, выполнено, и т.д.). По окончании периода так же легко можно проверить, что все что запланировали - сделано или нет. Тут и время можно логировать при необходимости, ведь все становится ясно и понятно: есть таски, есть планы, есть эстимейты, - остается только в нужном месте заполнить время. Но если цель достигнута, то можно этот отчет и сгенерировать для клиента. Неужели он будет против?
В заключение, сразу отвечу тем, кто напишет, что это я тут говорю про идеальный мир. Например, в фазе активной разработки одно, в тестировании другое, а у дизайнеров или проектировщиков совсем иная ситуация. Это да, идеального мира не бывает, но если не забывать нашей основной цели: выполнить задачу, и не отступать от принципа: работу необходимо планировать, то в любой среде этот подход можно адаптировать и применить.
16 лет dev.by — «дефолтный» источник информации о беларусском ИТ
В нашей компании используется трекер (TMetric) для учета рабочих часов, чтобы потом можно было легко создать отчеты о потраченном времени на тот или иной проект, а также и для точных выплат.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
В нашей компании используется трекер (TMetric) для учета рабочих часов, чтобы потом можно было легко создать отчеты о потраченном времени на тот или иной проект, а также и для точных выплат.