×Закрыть

Как делаются cost estimate для проектов?

Привет, очень интересно как делают cost estimate для проектов ПМы в нашем галерном сообществе(в маленьких и больших галлерах) и в адекватных продуктовых компаниях.Как эти процессы отличаются?

Буду рад,если кто-то сможет привести примеры либо накинет статтей почитать.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ловите из личного опыта работы на пресейле аналитиком:

— изучается спецификация переданная клиентом
— составляется список задач на основе этой спецификации
— уточняете вопросы у клиента
— дополняете задачи на основе дополнительных клиентских данных
— на ее основе строится Mindmap проекта
— если не знаете сколько займет узкопрофильная задача, отдаете ее на оценку соответствующему синьйору
— выставляются взаимосвязи между тасками
— получаете диаграмму Ганта проекта
— корректируете проект с учетом рисков
— сводите данные из Ганта в Excel таблицу
— учитываете рейты по каждому члену команды, состав команды и риски
— на выходе получаете эстимейт проекта по деньгам и времени
— передаете сейлзу

А кто оплачивает всю эту работу? И сколько % она по сравнению со стоимостью проекта?
По сути — это получается разработка ТЗ и архитектуры до того, как проект зашел.

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

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

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

оценка делается 2-3 дня не больше

не больших проектах бизнес-анализ и архитектура занимают не по одному месяцу. давать оценку без них — слегка странно.

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

если не знаете сколько займет узкопрофильная задача, отдаете ее на оценку соответствующему синьйору

Вот выше писали про разбивку на конкретные задачи. Вы умеете такое без детальной архитектуры?

пачиму? )) вот скажем есть специально обученные и специально нанятые эксперты (без кавычек) которые говорят «мы дадим вам оценку за 2 недели и соотв. рейт включая 3х на выходные» но понятно «бизнесу» это не подходит он находит первого мало мальски завалящего синьора ах простите solution architect даром что тот в теме не рубит от слова вообще кроме как красивые пасочки рисовать и он рисуте красивые пасочки и «даёт оценку без них» все счастливы все довольны чистый профитЪ!

ЗЫ: понятно что потом возникают «некоторые технические детали» об которых не знает прямо скажем никто т.е. от слова вообще запатчить какой-нибудь apache ignite? да запросто! как запатчить? ну это уже не наши проблемы мы тут только стратегией занимаемся )) но тут конечно есть некий нюанс скажем так «бизнес чуйка» которая надо признать у бизнеса тоже хоть немножко но работает ну конечно если #внезапно не найдётся «синьор» который под этим подпишется но тут надо признать у бизнес снова хоть немножко но работает та самая чуйка и просто тупых таки тоже вычисляют а поскольку реальной оценки никто так и не дал... то по опыту аккуратно свиливают )) х.з. как они там объясняют это политически но технически скажем как пример «мы поддерживаем но только в виде даунгрейда на предыдущую версию» (к) (тм) все совпадения с реальность суть есть случайность всё написанное суть есть художественный вымысел под пиво ))

ЗЫ: тут понимаешь ли какая проблема несмотря на «бизнес-анализ» и прочую лабуду «софт-скиллз» в современном мире всё ещё существуют технически сложные задачи под которыми либо никто не подписывается либо таки да у «софт скиллз насяльника» развивается своего рода «хард скиллз чуйка» когда он может и не понимает но жопой чует что «бизнес-анализ и архитектура» на самом деле липа липовая и подписаться под этим проектом никак нельзя ну просто потому что на джунов он тупо не масштабируется )) ну а дальше снова те же ж самые «софт-скиллз» как от этого аккуратно и профитабельно увилять.

ЗЫ: просто тут конечно у технического эксперта таки максимально выгодная позиция он просто и не глядя на последствия может прямо сказать «вы все е.лись эта х.ня никак не делается даже за год даже при наличии соотв. уровня гребцов идите на.» (к) (тм) то конечно разным там насяльника синхронной гребли так сказать нельзя... ну хотя бы б потому что никакой чисто технической экспертизы у них на самом деле и нет )) так что таки да чисто техническим экспертам сильно проще. В т.ч. «давать оценку».

так не всегда обязательно заестимейтить весь проект. Делается +/- детальный естимейт на пол-года , год. Остальное поверхостно, с условием разговора в конце года и нового естимейта. Архитектуру продумать за месяц не проблема, учитывая что люди которые этим занимаются делали подобоные проекты не раз (синьйоры таки :)

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

ну да за выходные мне прямо предлагали давали премию 500 баксов (может быть) ))

А потом нахлебаются и вернутся и оплатят дважды.

это все равно ни хера не работает — читай правило ninety-ninety, но да с чего-то надо начинать, намного благоразумнее разбивать на модули и продавать поэтапно (помодульно)

Достаточно просто, если не лезть в детали.
Берется спецификация (допустим она есть ясная и подробная), разбивается на задачи, которые оценивает команда. Если команда не может оценить задачу — она разбивается на подзадачи.
Накидывание сверху:
если команда точно знает что надо делать в задаче — +20%
Если есть сомнения — 50-100%
Если совсем ничего не ясно — рисерч и потом оценка.

Риски: смотрите на получившийся список задач и спрашиваете себя и команду — «что и где может пойти не так», тоже документируете. Если ещё и получается оценить влияние риска в часах, отлично.
Собираете всё вместе, берете рейты и считаете стоимость, дописываете туда же финансовую сторону рисков, которые нашли.
Отдаете сейлу, пусть продаёт это клиенту :)

Методом проб и ошибок. Сразу говорю ПМ’ом не был, но естимейты делал для команды из нескольких фриланс девов.
Делишь задачу на этапы, делишь на подзадачи , детализируешь с девом и ставишь сколько времени он планирует выполнять. Если говорит оч много или оч мало, детализируешь еще раз — ибо 100% дев угадывает...
В итоге получаешь детальный список из задач каждая из которых по 1-2 часа + в тотал накидываешь 20-30% запаса

Дальше начинаются факапы и експеременты
В итоге получаешь прогноз + реальность (обязательно )
Сравниваешь > уже понимаешь скорость работы дева и корректируешь. Запас 20-30% всегда накидываешь.
Больше итераций, большая точность естимейтов. Новая команда — новые експерименты (но хотябы для себя уже знаешь разумные мерки)

Вообще накидывать надо 100-200%, но кастомер может не согласиться

Денис, я бы сказал по другому:
— естимейты, это для тебя ! Для понимания движения по проекту и когда надо отзеркалить это кастомеру. Ведь ты всегда можешь сказать неправду, но в конечном итоге факап будет твой, потеря репутации и тд — тоже твои.

— 100-200% накидывать анриал Это значит что ты не можешь и не знаешь как естимейтить. Тогда уже лучше — time & material и не позориться, ну или в ПМы не идти. Это все таки один из самых ценных скиллов

— клиенту, ты уже сам решаешь сколько накинуть. Вы ведь сразу обговариваете стоимость часа работы и вкладываете свою прибыль. А клиент тоже не думак, увидит 100500 часов и побежит в Индию :)

It is very hard to predict, especially the future. ©

Вот как будет да ну его нафуй — это только половина

Это как анекодте —
Покупает заяц у волка соль:
— Взвесь мне, волк, пол-кило.
— Заяц, у меня весов нет, так давай я тебе на глаз насыплю?
— На куй себе насыпь, собака бешеная!
:-)

Если серьёзно, то Пол Демарко ещё в 80х написал «Вальсируя с медведями» — ничегошеньки с тех пор не поменялось. И заметь, он не про индусов синьёрных синьёр архитект лидов писал.

Берётся лучший из среднестатистических (в идеале тот, где добрая половина копипасты), в зависимости от упоротости синьйорности менеджера, их количества, и количества тупых тёлок приписанных к команде в любой формальной роли — отнимается от 15 до 30 процентов — и это дедлайн.

Забудьте добавить к нему то время, пока команда даже не приступала к проекту, потому что не была собрана или была занята другим или её вообще не существовало.

Гарантия срыва дедлайна от 99.(9)% до 146% (если заказчик местный или полуместный)

Здесь на ДОУ есть статья. Но еще можно экспериментальным способом (возможно сработает)
После того, как проект будет завершен и принят, сдан, нужно наизусть заучить сколько он

cost estimate

И повторять это каждый день (несколько раз в день, по нескольку минут, как молитву или мантру)
Так вы в будущем (настоящем) создадите информационную площадку.
Гипотетически она может «фонить» в прошлое то есть информация с этой площадки или базы просочиться возможно в прошлое однако в трудно распознаваемом виде — почти как мои Моны Лизы в твиттере. И тем не менее если в будущем вы проделаете такого рода манипуляции с необходимой вам в настоящем информацией возможно вы сможете более точно

cost estimate

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

Если вопрос о fixed price, то это почти магия. можно конечно разложить на составляющие, но это выходит за рамки комментария

и с некой вероятностью ситуация все равно оборачивается жопой :(

С вероятностью 50% даже избушка оборачивается к лесу передом

а прикинь там #внезапно на практике вероятность 0.67 хотя чисто теоретически таки да должна быть 0.5 попробуй такое «разложить на составляющие и заэстимэйтить» ))

избушка
к лесу передом
на практике

Стесняюсь спросить, что ж вы там такое практикуете

это не работает так после того как полсистемы будет написано клиент вспомнит о пару мелких деталей из-за которых надо будет сделать кучу не учтенных изменений что приведет к росту количество багов — а конец проекта во времени отодвинется на полгода

Для fixed price вначале делается анализ требований и ТЗ, они подписываются клиентом, все, что не вошло — за отдельную плату.

Никак. Time and materials наше все.

Подписаться на комментарии