Оценка проекта по времени, когда не ясно, что за проект?

Question

[Ivo Dimitrov]

Доброго времени суток.


Я работаю проектировщиком пользовательского интерфейса и возникла у меня проблема и вопрос одновременно — как оценивать время.


Когда спецификация (ТЗ) есть, то разработчик может кучу методов применить для оценки. Это могут быть некие формулы, а может и planning poker, но всегда ясно одно — у него есть конкретика. То есть он видит задачу, она у него расписана.


Но вот в моем случае я начинаю проект, когда еще сам заказчик не знает, что там будет, что он хочет и т.д., но требует оценку окончания аналитики (прототипы + спецификации). Я могу дать примерную оценку, но чаще случается так, что либо промахиваюсь (даю больше, чем мне потребовалось), либо проект разрастается, становится большим и я не успеваю. Соответственно заказчик негодует, шеф негодует, а я работаю по выходным и по 20 часов в сутки.


Итак вопрос — как рассчитать время на данный этап, если трудно понять что и как будет? Может быть поменять/внедрить какую либо практику?


Заранее спасибо за ответы.

Answer 1

[yadeveloper]

Такие заказчики бывают. Как было сказано выше, без полного объема информации, вы не сможете дать нормальный эстимейт. Однако есть выход и из этой ситуации. Наверняка же есть какие то базоые требования к реализации, которые точно нужно будет делать? Дайте эстимейт на этот кусок работы, заложите поправку в 2.5 раза и сделайте примечание, что этот эстимейт только для конкретного куска работы, информация по которому у вас есть. Далее просто будем делать правки, по мере поступления задачи. На вопрос вида «мне нужна полная цифра», отвечайте «пол-года и будем значительно сокращать по мере поступления информации» :)

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

Если что то не учли, предупредите менеджера\клиента сразу по ситуации, не откладывайте разговор на потом. Не бойтесь сказать, что вам нужно больше времени. Поверьте, гараздо хуже не выполнить работу в обещанный клиенту срок, чем заложить больше времени с учетами рисков.

При планировании — закладывайте риски. Есть задача, делится на 2 этапа. Первый этап может быть сделан за 1 день, если все будет хорошо, но вот тут и тут могут возникнуть сложности на решение которых может потребоваться еще 1-2 дня. А вот второй пункт — неясен. Может быть 1 день, может быть 2 дня, в зависимости от успешности первого пункта. Но давайте возьмем здесь 3 дня + 1 на собственное тестирование\проверку реализации бизнес требования.

Именно такое, развернутое эстимейтирование, позволит вам избежать множества проблем, перейти на нормальный рабочий график. Клиент будет понимать, почему вам нужно больше времени (или может понадобиться) и вы будете спокойны, зная, что у вас в запасе еще есть время.

Comments

[pel]

Хотел написать сам, но прочитал оратора выше и молча плюсую по всем абзацам.
Что интересно, тоже умножаю сроки на 2.5. И ведь по итогу получается всё как раз.

[yadeveloper]

2.5 — базовое число, оно вариируется под каждого непосредственно. Как правило в меньшую сторону. А если еще и проводить собственный анализ потраченного времени, то можно узнать о себе очень много интересного :)

[Ivo Dimitrov]

Спасибо большое за ответ. Осталось сейчас решить, как объяснить клиенту, почему дата сдвигается =)

[pel]

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

DarwinTenk, мне кажется, проекты, когда клиент сам еще не знает до конца, чего хочет, сто́ит изначально вести на повременной оплате (это скорее вашего шефа должно беспокоить).
И да, держите клиента в курсе, как продвигается задача, какие задержки возникли и какие появились причины для пересчета общих сроков. Включая мелочи. Все 100500 мелочей, каждая из которых заняла 10 минут на выполнение, и при этом еще на 5 минут выбила вас из потока. Как показывает практика, клиент начинает относиться лояльнее, когда начинает понимать, что вы делаете.

[Дмитрий Кинаш]

>>как объяснить клиенту, почему дата сдвигается

Если клиент попался неуступчивый и хочет окончания работ к конкретной дате, то можно делать запросы «важной» информации (иногда действительно важной) к ответственным сотрудникам. А потом предъявлять отсутствие их реакции как «задержки по вине сотрудников заказчика» — обычно это помогает начать диалог по пересмотру сроков на более реалистичные.

Answer 2

[super]

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

Comments

[yadeveloper]

Есть понятие планирование и подобная оценка — возможна. Когда в упомянутой вами науке спонсируют какие либо исследования, в бизнес-планах обязательно фигурируют даты контрольных точек, дат по состоянию на которые будут корректироваться те или иные решения. Мало кто будет спонсировать тот или иной бизнес проект без наличия этих самых «вех». Если группа ученых получает финансирование на исследования в области лекарств, например, от рака — они должны составлять отчеты о своих достижениях непосредственно спонсорам. И если проект планировался изначально на 10 лет и на протяжении 2х лет вообще никаких подвижек нет — проект как правило закрывается или будет переведен в другие состояния, не суть важно

Answer 3

[mark_ablov]

берите самую пессимистичную оценку :)

Answer 4

[Alexander]

Очень интересно, а цену вы тоже с потолка назначаете, не зная, что именно надо будет делать?
Нет задачи — нет времени на ее выполнение, нет стоимости. И точка.
Сначала ТЗ, хотябы бриф, потом все остальное. Проект разрастается — пишите дополнения в ТЗ со своими сроками и отдельной сметой.