Учет рабочего времени. Правильный ли подход?
==============================================

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

Работаю в одной фирме. Учет рабочего времени разработчика ведется через jira. На каждую задачу создаются таски. Проблема в том, что на каждый таск есть какое-то заложенное время и очень часто уложиться, в заданное время, просто нереально. Перед началом работы, нужно оценить - за сколько ты ее сделаешь, это можно сделать приблизительно, но часто возникают непредвиденные грабли и даже заложенное время, для маневра, не помогает. Много заложить запаса тоже не получится - т.к. столько времени просто не захотят оплачивать - что там можно столько делать. Можно, конечно, записать больше заложенного времени, но потом возникают вопросы - почему так долго делал и т.п. В итоге - часто бывает так, что рабочий день 8 часов, проработал 10, а записал 5. Зарплата основывается на отработанных часах и получается так, что за неделю, допустим, ты отработал 30 из 40 часов, а на деле работал 45, как вариант. И получишь тоже за 30. Складывается ощущение, что работодатель просто хитро экономит. Много рабочего времени уходит на поиски и оценку выполненных работ, а потом еще и на "выбивание" таска, чтобы туда внести отработанное время.  
  

Что делать? Как у вас происходит учет рабочего времени и что можете посоветовать? 

**Есть три версии происхождения проблемы:**1. Тайминг ставится не совсем корректно;
2. Вы не эффективно закрываете задачи;
3. И то и то.

**Что делать?** *Безусловно, нужно честно пообщаться с человеком, который ставит Вам задачи.  

Подойдите к нему с предложением посоветоваться и объясните ситуацию.*  
* Если задачи типичны и есть коллеги, которые справляются с ними в установленное время, то Вам придется поднять свою эффективность. Главное не относитесь к этому негативно, ведь это в целом повышает Ваши навыки и ценность как эксперта. Отнеситесь к этому как к вызову.
* Если же задачи уникальны, то нужно проговорить это и предложить увеличить количество времени по выполнению таких задач. Предложите со своей стороны шкалу сложности задач, чтобы Вы ориентировали руководителя о том сколько реально необходимо времени на закрытие задачи.
* В идеале начните собирать объективную статистику, самостоятельно фиксируйте сколько времени потратили на конкретную задачу. Через 2 недели - покажите эти цифры руководителю, сядете вместе и переоцените постановку времени для одного типа задач и для другого.

**Будьте честными, будьте командой.** 

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

**Если вас это устраивает** - не понятно в чем вопрос.  
**Если вас это не устраивает** - не понятно почему вы еще там работаете. 

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

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

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

 Ответа на ваш вопрос нет. Способность оценить время это навык, который приходит с практикой, вот и все. А пока этот навык не пришел - угадывайте. Правда стоит упомянуть, что если вы работаете с развивающимися технологиями, то вам практически всегда придется угадывать, увы. 

> Как у вас происходит учет рабочего времени и что можете посоветовать?

  

<https://www.worksnaps.net/www/> , работаю через этот сервис, его и советую. 

> рабочий день 8 часов, проработал 10, а записал 5

  

Вот тут непонятно. Так почему 5? Если проработал 10 то почему хотя бы 8 написать нельзя? 

 Считаю, что scrum подход в 99% случаев трата времени впустую, но возможно Ваш случай как раз попадает в 1%. Есть в скраме такая штука как покер. Предложите для оценки задач использовать игру в покер. Заключается игра в следующем. Собираются разработчики и заказчик (начальник, клиент, короче тот, кто ставит задачу). Заказчик описывает задачу (в удаленном виде - скидывает таск). Разработчики читают и пишут время, за которое смогут реализовать (желательно не видя результаты друг друга). Заказчик смотрит на цифры и если они совпадают, то назначает указанное время. Если не совпадают, то выбросы обсуждаются (самое маленькое и самое большое время): почему так долго\быстро, как видится подход и т.п. После обсуждения проводится новый этап голосования и так пока цифры не станут +\- совпадать. После этого таску назначается время выполнения. Но для того, чтобы убедить начальство в использовании такого подхода Вам надо во-первых убедить команду (т.е. проблема должна быть не только у Вас), а во-вторых убедить начальство (сделать это, к примеру, если Вы новый человек в команде и решили что-то менять будет почти невозможно - начальник справедливо откажет, так как "остальные ведь работают") 

 То что фактическое выполнения отличается от реального - это нормально, при оценке задачи учитывается ее трудоемкость то есть в идеале вы садитесь и не отрываясь программируете отведенное время. На практике часто возникают факторы задача не до конца проработана, сходил в туалет, загуглить что нибудь, чай налить, отвлекли с вопросом и наконец с утра в голову ничего не лезет, вы же не машина. Как правило из 8 рабочих часов можно выполнять 4-5 часовую. Мы обычно фиксируем фактическое выполнение но без учета внешних факторов, для ее анализа и обсуждения проблем в оценке повлиявших на увеличения времени.