Коллеги, а сколько по времени у вас занимает оценка стоимости проекта разработки…

16 ответов

1. Работаем с коллегой в таком случае по часам. Оценку делаем очень примерную и заказчик понимает, что это очень субьективные цифры. Мы сугубо про ux/ui, для нашей работы это норма.

2. ,

3. пальцем в небо, потом выход на ТЗ или ППО и переоценка

4. Практический опыт такой. Выполняя повседневную работу ведете полный хронометраж, в конце недели часик его медитируете. Через три месяца у вас разовьется скилл точной интуитивной оценки проектов в вашей сфере деятельности. И время без часов довольно точно сможете называть. Хрономеираж можно вести с 20-минутным шагом. Хотя сейчас есть автоматические средства, типа Timing.app for teams, я считаю что только личное внимание с заполнением хронокарты (см. НОТ Гусева), позволяет развить этот скилл. И он у вас останется навсегда.

5. Есть три подхода в таком варианте.
   1. Оценивать постфактум, как тут написано
   2. Проводить аналитику (как отдельную услугу) и затем оценивать — в большенстве случаев так получается даже дешевле для клиента, так как меньше переделок.
   3. Оценивать по клиенту — смотреть, сколько он может заплатить и ставить ценник по максимуму! )

6. Нет требований — нет точной оценки. Исходить надо из этого. Остальное по ситуации.

7. Часто становится понятно исходя из опыта, примерно какой ролевой и количественный состав команды потребуется для реализации проекта в заданный срок. Стоимость работы специалистов известна. Дальше легко считается примерная стоимость реализации проекта

8. Бриф и после телефонный звонок с уточнениями позволяют на 90 процентов попасть в оценку

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

10. Есть хорошая практика переоценки после каждого этапа.
    Сделали аналитику, проектирование, прототип — переоценили дизайн. Сделали дизайн — переоценили вёрстку и бэк

11. Нельзя оценить то, чего нет. Соответственно, если нет четкого ТЗ, а заказчик отказывается, то лучше не связываться. Иногда отсутствие четкого ТЗ, даже при том, что заказчик может быть вашим знакомым, может вам дорого обойтись. Я когда-то будучи фрилансером оценил один проект на свою голову. На первый взгляд это был просто блог. Но один из абзацев ТЗ содержал фразу «и т.д.». Так вот, это «и т.д.» вылилось мне в настройку кросспостинга, настройку oauth, настройку мультиязычности и еще в кучу другого функционала. А переоценку проекта невозможно было произвести. С другой стороны, заказчик будучи непрофессионалом не сможет написать вам четкое ТЗ. Например, как-то раз получил ТЗ, в котором заказчику нужно было приложение с возможностью загрузки в него видеоуроков. В конечном счете подробно поговорив с заказчиком было установлено, что нужно не только приложение, но и бекенд приложение (REST API). Одним словом, всегда оставляйте за собой право на переоценку проекта при добавлении новых пунктов к ТЗ или при появлении новых уточняющих аспектов ТЗ. Также не будет лишним встретиться с заказчиком и обговорить детали заказа. Некоторые даже предлагают разработку ТЗ на платной основе. Т.е. на основе пожеланий заказчика и с учетом вашего видения строится ТЗ и за это клиент вам заплатит. Например, 300-400 у.е. Тогда вы можете оценить проект, так как у вас объективно на руках будет ТЗ. Если заказчик просит назвать стоимость проекта без ТЗ, либо со скудным ТЗ, то можно открыто сказать, что невозможно оценить стоимость того, чего нет.

12. Как выше писали — трудно оценить чего нет) Нет ТЗ — нет оценки. Но можно сделать прогноз. Например с помощью сторипоинтов. Имея Скорость команды за пару спринтов и бэклог.

13. Диапазон всегда можно сказать, какой смысл ждать подробного ТЗ месяц-два? Уже бизнес-потребность может быть не актуальна.
    Примерно прикидываешь, например, 1-2 млн, спрашиваешь у заказчика, у вас есть столько денег? Он говорит нет или есть.
    Делаем мвп сначала, выпускаем на рынок, это дешевле и заказчик уже получает выгоду, а в процессе подготовки мвп можно и ТЗ написать сразу же в момент разработки.

14. Если речь идет про Заказную работу с фиксированными в договоре сроками и стоимостью, то в отсутствии ТЗ нужно либо заложить много рисков, либо сказать что оценка не точная. Крайне не рекомендую эту оценку без уточнения включать в договор.
    Будь это коммерческая или in-house разработка, алгоритм простой, декомпозируешь то, что написано до задач и оцениваешь. В случае когда нет ТЗ очень рекомендую применить лучшие практики покер планирование, группировку по бакетам, сортировку задач на шкале объемности. Это позволит дать субьектиную оценку всей команды максимально быстро и насколько это возможно (в отсутствии подробного ТЗ) точно.

15. Я сам заказчик, а не программист, но знаю точно, что большой проект оценить невозможно. То что мне кажется простым, зантмает больше времени и наоборот.
    Честнее будет выставить €/h с тем что это может занять от 100 до 10 000 часов 😉

16. Бриф или первый разговор позволяет понять примерно понять, что будет входить в проект (только приложение, приложение + сервер или что-то еще) и примерную сложность — уже можно назвать вилку. Если совпадает с возможностями/ожиданиями заказчика, тогда прорабатываем детальнее и называем более точную стоимость. Если все ОК — пишем вместе ТЗ и по нему называем точную цену

Комментарии закрыты.