Здравствуйте.
Работаю в одной фирме. Учет рабочего времени разработчика ведется через jira. На каждую задачу создаются таски. Проблема в том, что на каждый таск есть какое-то заложенное время и очень часто уложиться, в заданное время, просто нереально. Перед началом работы, нужно оценить - за сколько ты ее сделаешь, это можно сделать приблизительно, но часто возникают непредвиденные грабли и даже заложенное время, для маневра, не помогает. Много заложить запаса тоже не получится - т.к. столько времени просто не захотят оплачивать - что там можно столько делать. Можно, конечно, записать больше заложенного времени, но потом возникают вопросы - почему так долго делал и т.п. В итоге - часто бывает так, что рабочий день 8 часов, проработал 10, а записал 5. Зарплата основывается на отработанных часах и получается так, что за неделю, допустим, ты отработал 30 из 40 часов, а на деле работал 45, как вариант. И получишь тоже за 30. Складывается ощущение, что работодатель просто хитро экономит. Много рабочего времени уходит на поиски и оценку выполненных работ, а потом еще и на "выбивание" таска, чтобы туда внести отработанное время.
Что делать? Как у вас происходит учет рабочего времени и что можете посоветовать?
Что делать?Безусловно, нужно честно пообщаться с человеком, который ставит Вам задачи.
Подойдите к нему с предложением посоветоваться и объясните ситуацию.
Если задачи типичны и есть коллеги, которые справляются с ними в установленное время, то Вам придется поднять свою эффективность. Главное не относитесь к этому негативно, ведь это в целом повышает Ваши навыки и ценность как эксперта. Отнеситесь к этому как к вызову.
Если же задачи уникальны, то нужно проговорить это и предложить увеличить количество времени по выполнению таких задач. Предложите со своей стороны шкалу сложности задач, чтобы Вы ориентировали руководителя о том сколько реально необходимо времени на закрытие задачи.
В идеале начните собирать объективную статистику, самостоятельно фиксируйте сколько времени потратили на конкретную задачу. Через 2 недели - покажите эти цифры руководителю, сядете вместе и переоцените постановку времени для одного типа задач и для другого.
"самостоятельно фиксируйте сколько времени потратили на конкретную задачу. Через 2 недели - покажите эти цифры руководителю"
что-то мне подсказывает что ему будет параллельно, одну и ту же задачу можно 3 часа делать можно 5, а можно и пару дней.
если в компании ктото аналогичные таски делает быстрее того что предлагаете - то ничего не доказать.
если вы единственный и незаменимый, то так есть смысл делать.
Юрий: все верно. Сам факт выхода за рамки тайминга нужно сначала обсудить с человеком, который ставит такой тайминг. Забыл еще написать про то, что существует такое понятие как "поле искажение реальности", о нем я узнал из биографии Стива Джобса (автор Уолтер Айзиксен). Суть примерно следующая: можно выпустить новую версию mac за 1 год, а можно выпустить ее за 6 месяцев. Разница лишь в постановке задачи, время на которую сознательно искажается. Стив Джобс создавал такие вызовы, что программисты и инженеры Apple преодолевали не неадекватность Стива и сложность задачи, а преодолевали себя. В книги упоминаются их воспоминания об этом и они говорили, что тогда это был ад, но спустя годы и десятилетия мы поняли, что тот личный прогресс, который мы совершили над собой тогда лег не просто в наши биографии, а в основу становления всей отрасли. Это было исторично, но на грани предела возможностей.
Я это все написал, потому что, возможно, Вы попали в "поле искажение реальности" своего руководителя. Возможно, такова его стратегия - ускорять процесс, а значит ускорять Вас. Об этом Вы тоже можете с ним поговорить. Вообще, разговоры - это один из самых полезных способов разрушить догадки и подозрения. Не бойтесь открыться с другой стороны. Конечно же при условии, что руководитель в целом ведет себя адекватно и идет на диалог.
Согласен с Андрей Ермаков . Дополню лишь, что не нужно бояться указывать фактическое время выполнения задач. Если вы делаете медленнее чем другие - это еще не означает, что менее качественно. Если же другие разработчики просто более квалифицированы - это наверняка отражается в уровне их оплаты. Вы делаете меньше в единицу времени, но и получаете за это меньше.
Еще полезно почитать самому и дать почитать начальнику вот это: https://habrahabr.ru/company/ruswizards/blog/151029/
Практика показывает, что если данный подход вас устраивает все хорошо, если нет , то стоит искать новую фирму. Поменять что то можно только, если это вы у руля. В другом случае, сведут к тому, что вы плохой программист.
У нас на оценку для разработчиков ставятся отдельные задачи. Далее зависит от менеджера и от проекта, это время может пойти либо в расходы менеджера либо будет перенесно в в задачи по проекту. Т.е. для разработчика оценка это нормальная работа, она оплачивается.
С размытыми описаниями всегда проблемы. Тут надо наставивать, либо дайте мне точное описание задачи со всеми ответами на мои вопросы, либо за оценку не ручаюсь. Точного описания задачи я еще ни разу в жизни не видел, по крайней мере когда речь идет о крупных задачах. В этом случае надо дать понять менеджеру и заказчику, что какая задача, такая и оценка.
Если в процессе работы выясняются какие-то подводные камни почему задача оказалось более сложной чем изначально оценивалась, то надо разговаривать с менджером, говрить так и так, это оценили правильнл, а это оценить не могли по таким-то приичнам, а эту штуку оценивали реализовать способом таким, но заказчик хочет другое.
Ответа на ваш вопрос нет. Способность оценить время это навык, который приходит с практикой, вот и все. А пока этот навык не пришел - угадывайте. Правда стоит упомянуть, что если вы работаете с развивающимися технологиями, то вам практически всегда придется угадывать, увы.
Считаю, что scrum подход в 99% случаев трата времени впустую, но возможно Ваш случай как раз попадает в 1%. Есть в скраме такая штука как покер. Предложите для оценки задач использовать игру в покер. Заключается игра в следующем. Собираются разработчики и заказчик (начальник, клиент, короче тот, кто ставит задачу). Заказчик описывает задачу (в удаленном виде - скидывает таск). Разработчики читают и пишут время, за которое смогут реализовать (желательно не видя результаты друг друга). Заказчик смотрит на цифры и если они совпадают, то назначает указанное время. Если не совпадают, то выбросы обсуждаются (самое маленькое и самое большое время): почему так долго\быстро, как видится подход и т.п. После обсуждения проводится новый этап голосования и так пока цифры не станут +\- совпадать. После этого таску назначается время выполнения. Но для того, чтобы убедить начальство в использовании такого подхода Вам надо во-первых убедить команду (т.е. проблема должна быть не только у Вас), а во-вторых убедить начальство (сделать это, к примеру, если Вы новый человек в команде и решили что-то менять будет почти невозможно - начальник справедливо откажет, так как "остальные ведь работают")
То что фактическое выполнения отличается от реального - это нормально, при оценке задачи учитывается ее трудоемкость то есть в идеале вы садитесь и не отрываясь программируете отведенное время. На практике часто возникают факторы задача не до конца проработана, сходил в туалет, загуглить что нибудь, чай налить, отвлекли с вопросом и наконец с утра в голову ничего не лезет, вы же не машина. Как правило из 8 рабочих часов можно выполнять 4-5 часовую. Мы обычно фиксируем фактическое выполнение но без учета внешних факторов, для ее анализа и обсуждения проблем в оценке повлиявших на увеличения времени.
Допустим - у вас есть задача, рассчитанная на 4,5 часа, вы ее делали чистого времени 5 часов, зафиксировали 5, остальные 3 часа времени рабочего времени ушло на отвлекания, монолог с гуглом и прочее. На деле заплатят за 5 часов. За чаепития, отвлекания никто не заплатит, нету таска такого :D
За месяц непродуктивного времени накапливается где-то 60 часов из 160, как вариант. Зарплату получите за остаток от 160 рабочих часов в месяц минус непродуктивное время.
С одной стороны - вроде справедливо, сколько наработал - столько получил. Но на работе ты не в контактике сидел, а работал 8 или более часов, с перерывами на поесть/передохнуть.
При проекторной работе, на начальном этапе идет оценка трудозатрат. Если все не успевают укладываться то нужно вводить дополнительные коэффициенты.
У на в компании это делают через трекинг задач, путем интеграции c Jirа, это позволит вести точный учет времени по задачам. Затем идет процесс согласования трудозатрат с согласующими.
Тут отличная подборка систем учета рабочего времени с трекерами: https://software-audit.ru/
Средний
