Как быстро и точно оценить проект без ТЗ

[questor]

В принципе топик достаточно тривиален и сводится к паре предложений:
1. Ешьте слона по кусочкам
2. Оценивайте задание исходя из опыта решения прошлых задач.

Тем не менее, возможно кому-то на начальных этапах такая подробная детализация поможет, особенно подробное описание видов ТЗ (по параметру детальности описания) на добрую половину поста.

[natnal]

1. Ешьте слона по кусочкам

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

2. Оценивайте задание исходя из опыта решения прошлых задач.

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

[LexB]

Не знаю насколько такой подход рабочий.
Можно завести процект в системе типа Jira и там отмечать все Assumption, Out of scope и Business/Functional Requirements.
Assumption — уточнить допущенные предположения, чтобы ваше толкование не расходилось с толкованием заказчика.
Business/Functional Requirements — проверить какие именно бизнес кейсы должны быть решены за счет автоматизации.
Заказчику это будет видно (т.е. ему будет видно что рабоба над его ТЗ ведется), каждый элемент можно обсуждать там же.

4. Если, глядя на ТЗ, вы видите, как можно улучшить эту еще не разработанную систему, вы предлагаете заказчику сразу учесть те потребности, которые, почти наверняка, возникнут в процессе реализации проекта. Ошибка в том, что очевидные для вас детали могут быть незаметны или пока неважны для заказчика, и вашу заботу он расценит как желание навязать ему ненужный функционал за дополнительную плату.

Описать как Out of scope, в дальнейшем, если потребудется, реализовать как CR.

Ну и составить по Requirements т.н. Traceability Matrix чтобы провериьть как ваш функционал покрывает бизнес тредования.

[natnal]

Возможно, вы говорите о более поздней стадии — когда проект уже взят в работу и идет дальнейшее (уже оплачиваемое) обсуждение деталей его реализации. В этом случае, конечно, есть инструменты для ведения проекта и взаимодействия с заказчиком. Но применять такой подход на стадии, когда на заказ претендуют 20 человек, и вероятность получить проект пусть не 1/20, но всё равно не более 1/5, считаю преждевременным.

[Nomad1]

Итак, нужно установить стоимость проекта, покрывающую затраты на разработку.

Оценка сроков на этапе обсуждения ТЗ (если это не идеально-недостижимый уровень 3++, конечно) всегда будет занижена! Мой совет: не работайте с коэффициентом меньше 1.3-1.5x от себестоимости, иначе все-равно выйдете за сроки и стоимость из-за «мелких пожеланий», форс-мажоров, времени, потраченного на обсуждения и подписание (а оно ведь тоже должно оплачиваться!). В крайнем случае, если мучает совесть и сделана работа быстрее, можете добавить наработок на будущее — более детальную админку, вспомогательные утилиты, качественное многоуровневое логирование и пр. На деле же нередко бывает, что и запрашивая 2x от себестоимости и рассчитывая на 2-3 месяца можно «встрять» на пол-года работ и в лучшем случае выйти в ноль, будто бы работали в офисе, с налогами, соц плюшками и пр.

[natnal]

Мой совет: не работайте с коэффициентом меньше 1.3-1.5x от себестоимости

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

Ну, и нужно уметь останавливать поток пожеланий заказчика:

«В ТЗ, на основе которого мы договорились делать проект, сказано про танцующих розовых слоников? Нет? Значит, их не будет. Или будут, но за отдельную плату в размере Х рублей — оплатите, пожалуйста, счет.»

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

[Jumanji]

Если говорить про уровень 0, то мы для себя выбрали такой вариант, вместо того что бы выяснять как именно надо, мы отправляем заказчику 1 или 2 варианта того, как мы видим этот сайт, с акцентом на местах которые являются ключевыми при формировании цены, сразу с ценами, разумеется.

[natnal]

Мне понравился подход одного дизайнера, с которым недавно работали: на просьбу рассказать до начала работ хотя бы примерно, как всё будет выглядеть, он отвечает, что у него уже есть в голове хороший вариант, но описывать его словами не имеет смысла — надо брать и делать. Хороший способ заинтриговать заказчика, который не может четко сформулировать, что хочет.

[macik_spb]

К вопросу о слоне. В случае когда ТЗ очень не проработано. Называю ориентировочную цену несколько занижая стоимость или диапазон цен (на сколько можно оценить и исходя из заказчика), с оговоркой, что точную цену можно назвать только после детальной проработки ТЗ. Объясняю, на сколько необходимо ТЗ, безотносительно буду ли я исполнителем всего заказа. И предлагаю вариант проработать его (естественно за счет заказчика), получая таким образом возможность откусить кусок пирога. А заодно и понять на сколько это тяжелый проект и тяжелый заказчик. Далее можно поиграть ценой в своих интересах. В принципе заказчик все равно остается в плюсе, т.к. у него на руках нормальное ТЗ и есть возможность более точно оценить стоимость работы и найти более адекватного исполнителя.

[xanep]

Думаю, так должен поступать каждый профессионал (в смысле объяснять необходимость ТЗ и предлагать его проработать).