Как расчитать время на реализацию task-а?

Question

[acabun]

Я full-stack разработчик.
Почти год тружусь в компании где PHP-программисты это редкость. А точнее я один.
Команда формируется из: 1 ПМ(project manager), 1 QA, 1 Full-stack, ... .
PM в кодинге ноль. Его задача только общение с клиентом и командой. Скорее всего на его плечах и другие важные задачи, но мне не известно.

У меня постоянно возникает проблема с estimate-ами. Так как, для анализа времени выделяется очень мало времени, и приходиться на глаз прикидывать.

Причины просрочки сроков бывают различные. К примеру:
- - Неправильно подобранные плагины. Из-за чего тратится время на поиск подходящих.
- - Клиентские правки, которые присылаются в процессе реализации таск-а.
- - Различные непредвиденные БАГ-ги. на которые приходиться порой затрачивать больше времени.
- ... .

И многое другое, что в итоге влечёт за собой отсрочку срока сдачи проекта.

Пытался уже найти информацию о том как правильно рассчитывается время.
Боб мартин предлагает использовать формулу "PERT". Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.


Собственно у меня вопрос.
Кто как рассчитывает время для реализации task-ов, и в итоге у кого получается уложиться в срок ?

Comments

[Roman K]

Боб мартин предлагает использовать формулу "PERT". Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.

А твоё начальство и клиенты умнее дяди Боба?

[Антон]

Мол, это много

Вы говорите о разном:
PERT - это прогноз
Не согласно мое начальство - это ожидание
А потому, какая разница какую формулу использовать и как считать время, если начальство и клиенты хотят получить тот срок, который хотят, а не тот, который требует технологический процесс?
Если автобус едет со скоростью 60км в час, это значит он будет в точке назначения через час и как бы вы не считали, он раньше не будет.
Отсюда вывод: значит начальству нужно распределять нагрузку, нанять более опытного и быстрого кодера, смириться с тем, что есть.
Формула PERTвполне имеет право быть при расчетах, но в неё всё равно надо закладывать ваш опыт в аналогичных проектах. Если опыта нет, то эта формула не совсем подходит, либо требует корректировки с учетом ознакомления, тестов, проб.

Answer 1

[Robur]

Но с результатами данной формулы не согласно мое начальство и клиенты. Мол, это много.

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

нужно определить какой вариант - ваш и действовать в соответствии.

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

еще вот такой метод очень популярен:

Собрал с разработчиков оценку, посчитал. Надо заложить риски.
- умножить на два?
- Нет, на два это не научно. Надо умножать на число e или на число пи, в зависимости от сложности проекта.
- А это как определяется? "E..., какой сложный" и "Пи... какой сложный"?

Answer 2

[Иван Шумов]

На самом деле ничего сложного в этом нет. Надо иметь несколько эталонных задач, которые вы четко понимаете сколько времени делаете, например на 1/4, 1, 5 часов. Сопоставлять новые таски с ними и докидывать сверху относительно области не знания части задачи (а лучше вообще сначала сделать исследование чтобы такого не было) + накинуть на всякие коммуникации (все тоже из опыта берется)

Comments

[acabun]

Спасибо. Мысль интересная. Проверю.

Answer 3

[Dimonchik]

не парься, так у всех
https://www.youtube.com/watch?v=SQ4NAOU5Jso

главное - и это главное что ты должен вынести их этого топика - соскакивай с PHP

Comments

[acabun]

Спасибо. Обязательно по смотрю.