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

1. Часы и деньги – это в нашем случае – одно и то же. Например, мой час стоит от 2000 рублей в зависимости от. И когда я оцениваю для себя проект – я просто прикидываю время, которое я на него затрачу, а затем умножаю его на.

2. Самое основное в контексте фриланса, чего не понимает большинство заказчиков: достоверная оценка проекта – это сама по себе работа, требующая времени, и, соответственно – времени, которое кто-то должен оплатить. Либо это время оплачивает заказчик, либо исполнитель.

3. Ключевое слово в предыдущем абзаце - «достоверная». Потому что несложно бухнуть от балды: «50 часов» или «100 часов» – но кто потом возьмет на себя издержки, если эта оценка разойдется с реальной – в разы. А такое бывает. Причем, даже у опытных системных аналитиков.

4. Итак, как мы оцениваем задачу:

   1. Сначала переводим бессвязное описание от заказчика, на более-менее приемлемый для разработки язык. Примерно определяем архитектуру приложения.
   2. Разбиваем задачу на модули.
   3. Модули разбиваем на еще более мелкие подзадачи, до тех пор пока каждую из них не станет возможным адекватно оценить в часах на основе общепринятого опыта.
   4. Суммируем полученное в п.4.3.
   5. Сюда же добавляем время, затраченное на переговоры с заказчиком, девопс, тестирование, накидываем процентов 30 на нежданчики.

5. В результате всего этого получаем более-менее достоверную предоценку задачи.

6. Соответственно, лично я, например, заказы, где стоимость указана меньше, чем стоимость времени, которое тратится на все вышеперечисленное – попросту пролистываю – фриланс это ведь не благотворительность, это обычная работа, с оплатой по времени.

7. Разумеется, я существенно упростил все эту схему – для краткости и наглядности. Но даже такая упрощенная система – намного лучше, чем полное ее отсутствие.

8. И да, не для всех проектов это применимо. Особенно если планируется много R&D, девопса, и т.п.

9. И да, чуть было не забыл САМОЕ ГЛАВНОЕ (пхахах) – зачастую, особенно в маленьких заказах, ОСНОВНАЯ часть времени уходит на понимание задачи как таковой. То есть, понимание бизнес-процессов, которые требуется автоматизировать. И вот этот момент – это как раз и есть самый корень непонимания между подрядчиком и исполнителем на фрилансе. Потому что заказчик, который уже годами вертится в своем бизнесе, с трудом понимает эту очень простую вещь – что разработчик ПО этих лет в бэкграунде не имеет, и ему требуется зачастую большая когнитивная работа, чтобы в сжатые сроки понять то, на что у заказчика ушли месяцы и годы.

Теперь вы это знаете, и ваш взгляд на разработку ПО стал чуточку адекватней.

Роман Духанин

Этот же текст в моем тг-канале: https://t.me/pgodb/6