КАк заказать разработку программного продукта

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

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

На первый взгляд, все имплементации идей отлично ложится в компактное мобильное приложение, веб-сайт, простой монолит с привычными всеми CRUD операциями. Создается впечатление, что можно легко поднять jHipster для бэкенда, фронт написать на готовом шаблоне (Angular, React, VueJS – что кому удобнее), что много времени не займет и вообще проект прост, который можно сделать “задней левой ногой”.

Но, как обычно, он кроется в деталях. При планировании процесса разработки происходит детализация каждого из этапов, каждый из компонентов и элементов, описывается взаимодействие между ними, интеграция внешних сервисов, рисуются дизайны и маршруты движения пользователя (так называемые User Flow). Разница в оценках времени/стоимости разработки до планирования и после отличается в разы (обычно не менее 2-3).

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

Хотя бывают ситуации, когда профаны указывают завышенные цены. Собственно наблюдал ситуации, когда заказчику был продан функционал, суммы явно превышает затраченные усилия, выполненный некачественно, а затем функционал за отдельную плату “выпиливания” из проекта.\

Так как человеку, который по ИТ не связана заказать качественный программный продукт? Куда обращаться? – Я сформировал краткий перечень правил, следование которым позволит снизить риск сотрудничества с неквалифицированным или неответственным исполнителем (касается как организаций, так и фрилансеров, одиноких разработчиков):

1. Не заказывайте софт в близких знакомых или родственников – в этом случае чрезвычайно трудно (в силу моральных и других моментов) указать точную цену которая будет мотивировать работать.

2. Проверяйте предыдущие работы, портфолио – сколько из указанных проектов “еще живы”, есть схожие по тематике с вашим и т.д.

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

4. Закажите детализированное платное ТС – только за оплаченные услуги можно привести к ответственности, перечитайте ТС, проверьте насколько подробно оно расписано, правильно поняли вашу идею, проследите как писалось ТС, общались с вами по непонятным моментам, или просто не включили в ТС то что не поняли, проявили инициативу и добавили что-нибудь из своих идей?

 

5. Попросіть оцінити проект у раз

    1. швидкої розробки.

    2. якісної розробки.

    3. оптимальне співвідношення якість/швидкість.

6.Предложите пример плана тестирования.

7. Не торопитесь – очень редко нужно создавать продукт в короткие сроки.

8. Разбейте создание на несколько изолированных этапов.

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

2. Работающая — связать все проверенные гипотезы, проверенные функции и интеграции в единую систему и выпустить продукт.

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

Сподіваюся, короткі поради убережуть вас від розчарувань у процесі розробки програмного продукту.

 

Share This

Leave a comment