Когда вы заказываете разработку ПО, ваш первый вопрос: – Сколько времени и денег займет создание? И, если речь идет о рынке фриланс-услуг – по сути вы устраиваете тендер, где побеждает назвавший наименьшую цену и время на разработку.

Но ответьте мне, всегда ли покупка товара по заведомо заниженной цене – есть благо для вас? Допустим некто предлагает вам купить Мерседес за $1,000 – вы сразу чуете подвох, да? Мерседес не может стоить так дешево. Но почему вы не ощущаете подвоха, когда вам предлагают сделать интернет-магазин с нуля за $100? Правильно, потому что вы не понимаете как здесь формируется цена, и как адекватно оценить трудозатраты на разработку. Давайте вместе посмотрим. С картинками.

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

– Нужно сделать интернет-магазин, предложения по стеку, деньгам и срокам пишите в комментарии.

Скорее всего, в реальном мире, данный тендер выиграет какая-то студия, которая специализируется на интернет-магазинах и может демпинговать в силу наличия наработанных годами шаблонов. И это правильно, так и должно быть. Но мы помним, что магазин у нас просто для примера. На его месте вполне может оказаться CRM для управления лесным хозяйством в Вологодской области – а такой шаблон у студии найдется вряд ли.

Поехали:

1. Первое что делает разработчик – переводит «Нужно сделать интернет-магазин» на пригодный для разработки язык – прикидывает архитектуру веб-приложения.

2. Начнем со стека технологий. Для магазина возьмем всем привычную связку: Laravel/Vue через REST API, и на MySQL. Сразу заказчику: - Настаивайте на использовании популярных технологий – так проще найти нового исполнителя, который подхватит флаг разработки, когда старый уйдет в запой (на место «запоя» подставьте любой из нежданчиков этой жизни, которые за каждым ее поворотом).

3. Теперь давайте разобьем функционал стандартного интернет-магазина на функциональные модули:

У вас получится что-то вроде этого (дада, понимаю, что все нарисуют эту схему по-своему – напишите об этом каментах, чем больше хейта – тем лучше ;)

Это, как мы видим – стандартная UMLка – очень удобно для визуализации, и лучшего понимания сути предстоящего.

4. Примерно прикинем какие экраны нам нужны на фронтэнде для реализации функционала из предыдущей схемы:

Это, соответственно, для отрисовки дизайнеру и далее – фронтэнд-кодеру.

5. Теперь смотрим какие сущности на бэке будут представлять все это хозяйство:

Повторюсь: это примерная схема, мы сейчас не ставим целью детальную проработку архитектуры – нам просто нужно примерно прикинуть объем работы в человеко-часах.

6. Далее – хорошо бы набросать список основных эндпойнтов для REST API:

7. Можем сделать список контроллеров для Laravel:

8. Как видите, на этом уровне мы уже примерно можем определить объем человеко-часов – потому что время на написание того или иного контроллера уже более-менее понятно.

9. То же самое касается и отрисовки экранов интерфейса, и кодирования их поведения на Vue.js

10. Теперь просто возьмем ПРИМЕРНЫЕ трудозатраты на типовые задачи:

Разработка модели и контроллера для продукта (включая CRUD операции): 4-6 часов

Создание и стилизация компонента Vue для отображения списка продуктов: 3-5 часов

Разработка и интеграция корзины покупок (бэкенд + фронтенд): 8-12 часов

Реализация системы аутентификации (бэкенд + фронтенд): 6-10 часов

Создание и стилизация главной страницы: 5-8 часов

Разработка функционала оформления заказа (бэкенд + фронтенд): 10-15 часов

И ориентируясь на них, можем при помощи школьной арифметики оценить общий объем работ по кодингу.

11. Далее – накидываем 20% от полученного времени на проектирование (здесь, конечно, многое зависит от стиля разработки, но нам хоть какие-то цифры получить сейчас нужно).

12. +30% на отладку и тестирование. На самом деле, это может быть и +100% – все зависит от того-сего-пятого-десятого. И в целом, это не редкость, когда на отладку времени уходит больше, чем на саму разработку – ибо деление на разработку и отладку – весьма условное – это единый процесс.

13. На развертывание среды локально и на сервере – тоже времени накиньте. В зависимости от экзотичности платформы и потребностей движка – тоже времени нормально так может уйти, особенно – на незнакомом хостинге. Скажем, еще +10%

14. И да, опять чуть не забыл упомянуть САМОЕ ГЛАВНОЕ :) На маленьких проектах ОСНОВНУЮ часть времени у разработчика может занять не столько сама разработка, сколько понимание бизнес-процессов, которые требуется автоматизировать в вашем бизнесе. Об это стукаются очень многие, и заказчики, и разработчики. При этом и те и другие недоумевают - «почему их собеседник настолько тупой?» :) Но на самом деле это нормально на начальных этапах, поскольку они говорят по сути на разных языках, а понятия «язык» и «интеллект» напрямую коррелируются между собой.

15. Есть еще и особая категория кейсов – легаси, это когда приходится доделывать за другими. И хотя это достаточно частая история на фрилансе (в том числе и потому, что разработчики бросают изначально недооцененные проекты), ее рассмотрение я оставлю на потом. Пока лишь скажу кратко: – Иногда проще и быстрее написать заново с нуля, чем переделывать уже сделанное. Вот насколько плохо это бывает порой.

Итого: ...

****

Всё, я устал писать, тем более что и так достаточно – до этого момента дочитают не только лишь все – мало кто сможет это сделать (Ц)

Но если вы таки это сделали – теперь вы доподлинно понимаете, какой айсберг находится за вашим простым запросом:

– Нужно сделать интернет-магазин, предложения по стеку, деньгам и срокам пишите в комментарии.

Предложение-то можно сделать какое угодно – но вот будет ли оно реалистичным? Получите ли вы в нужные сроки необходимый вам функционал?

И заметьте – никакая «безопасная сделка» вас не спасет от просроченных дедлайнов. А иногда это бывает весьма критичным для бизнеса.

То есть, если вы не получите продукт в оговоренные сроки, и даже не заплатите за это ни копейки – то кто вернет вам просроченное время?

А ведь именно это просроченное время и получается как результат неадекватной предоценки проекта. На госзакупках этому служат залоги, но здесь-то у нас не госзакупки – залогов нет.

Нормальным решением здесь может быть обращение к незаинтересованному системному аналитику. А хоть бы даже и ко мне. Жестких гарантий, разумеется, я не дам, но адекватность подхода к вопросу гарантировать могу.

И да, если какой-то из аспектов рассмотренной темы нужно развернуть – пишите в комментарии – будет тема для следующего креатива.

Этот текст в формате PDF в Телеграм: https://t.me/pgodb/7 

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

https://t.me/romand

https://pgod.ru