Accounting for working hours. Is it the right approach?

Question

JIRA

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

Answer 1

Есть три версии происхождения проблемы:

1. Тайминг ставится не совсем корректно;
   
2. Вы не эффективно закрываете задачи;
   
3. И то и то.
   

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

• If the tasks are typical and there are colleagues who cope with them at the set time, then you will have to increase your efficiency. The main thing is not to take it negatively, because it generally increases your skills and value as an expert. Treat this as a challenge.
  
• If the tasks are unique, then you need to say it and offer to increase the amount of time to complete such tasks. For your part, offer a scale of task complexity so that you guide the manager about how much time is really needed to complete the task.
  
• Ideally, start collecting objective statistics, independently record how much time you spent on a specific task. After 2 weeks - show these numbers to the manager, sit down together and reevaluate the time setting for one type of task and for another.
  

Be honest, be a team.

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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