Заказать разработку страшно по одной причине: платят вперёд, а результат виден в конце. Ошибка в выборе подрядчика стоит дороже ошибки в коде: переделывать приходится месяцы работы вместо строчки. Большая часть провалов случается до старта - задачу описали на словах, предложения сравнили по сумме, а на середине работы выяснилось, что исполнитель и заказчик понимали её по-разному.
Ниже - как пройти этот путь: кого искать, что спросить, как проверить и что зафиксировать до подписания. Посмотрите на наши проекты: у большинства из них цена и срок появились только после разбора требований.
С чего начинается выбор подрядчика?
Коротко: выбор начинается с описания своей задачи: что должно работать, для кого, что считается готовым результатом. Пока этого нет, сравнивать предложения нечем. Поиск исполнителей - потом.
Первое, что делает большинство заказчиков, - собирает логотипы и портфолио. Это приятная, но бесполезная работа, если у вас ещё нет ответа на три вопроса: какая задача решается, кто будет этим пользоваться и что вы считаете готовым результатом.
Опишите задачу на одну-две страницы: что сейчас происходит и почему это не устраивает, кто будет пользоваться результатом, что должно заработать, что точно не входит в работу. Отдельно - ограничения: сроки, бюджетный потолок, действующие системы, с которыми новая должна стыковаться.
Такой текст нужен в первую очередь вам. С ним вы одинаково расскажете задачу трём разным подрядчикам и получите сравнимые предложения. Без него каждый додумает детали сам, и цены будут отличаться в разы.
Какие подрядчики бывают и кому какой подходит?
Коротко: для небольшой и понятной задачи хватает фрилансера или небольшой студии; где нужна непрерывная поддержка и ответственность за результат - студия; крупные агентства берут большие проекты с длинным горизонтом. Своя команда оправдана, когда разработка становится постоянной функцией.
Дешевле всех фрилансер, но у него ограничен ресурс: он один, и в отпуске или на больничном работа встаёт. Крупное агентство даёт больше людей и процессов, но берёт дороже и не всегда включает в договор поддержку и передачу.
| Тип исполнителя | Кому подходит | На что смотреть |
|---|---|---|
| Фрилансер | небольшая задача, понятное ТЗ, нет срочности | насколько доступен второй человек, будет ли поддержка после сдачи |
| Небольшая студия | задача средней сложности, нужен результат и поддержка | кто ведёт проект, что с передачей кода и документации |
| Крупное агентство | большой проект, длинный горизонт, много интеграций | кто из команды реально делает вашу задачу, а не продаёт |
| Своя команда | разработка нужна постоянно, продукт развивается | стоимость найма и управления против подрядчика |
Смешанный вариант встречается чаще, чем чистый. Разбор требований и проектирование заказывают у тех, кто это умеет, а разработку ведут своей командой или меньшим подрядчиком. Так дешевле, если у вас есть кому вести работу.
Какие вопросы задать подрядчику на первой встрече?
Коротко: спрашивайте про свою задачу: как её поняли, что сделают первым, что может пойти не так и как будут сдавать. По вопросам, которые исполнитель задаёт вам, видно, разбирается он в деле или продаёт.
Технологии на первой встрече почти ничего не решают: заказчику обычно неважно, на каком языке написана программа, если она работает и её можно поддерживать. Полезнее проверить, как исполнитель думает. Десять вопросов, которые стоит задать:
- Как вы поняли задачу своими словами?
- Что нужно уточнить, чтобы назвать цену и срок?
- Что вы сделаете в первую очередь, а что можно отложить?
- Что в этой задаче может пойти не так и как вы это увидите заранее?
- Кто конкретно будет работать и кто отвечает за результат?
- Как вы покажете промежуточный результат и как часто?
- Что считается готовой работой и как это принимается?
- Кому принадлежат права на код и все исходники?
- Что будет после сдачи: поддержка, доработки, исправление ошибок?
- Что вы не будете делать и почему?
Ответы важнее регалий. Исполнитель, который сразу называет точную цену и срок, ничего не уточняя, скорее всего угадывает - и заложит запас или недосчитает. Тот, кто задаёт вам встречные вопросы про пользователей, нагрузку и будущие изменения, разбирается в предмете.
В студии разработки D2Tech разбор требований начинается с того, что мы задаём вопросы до конца и записываем критерии приёмки для каждого пункта. Цена и срок у нас появляются до первой строки кода. Если хотите увидеть, как это выглядит на вашей задаче, опишите её, и мы пришлём состав работ и смету за 24 часа.
Как проверить портфолио и отзывы?
Коротко: смотрите на кейсы, похожие по типу задачи, и на людей, с которыми можно связаться. Количество кейсов мало о чём говорит. Спросите, что в проекте пошло не так: честный ответ говорит больше, чем список успехов.
Портфолио легко сделать красивым, поэтому проверяйте его на совпадение с вашей задачей. Если вы заказываете интеграцию двух систем, а у исполнителя одни одностраничные сайты, это не значит, что он не справится, но опыта в вашем случае у него нет.
Попросите контакты двух-трёх заказчиков с похожими проектами и задайте им один вопрос: что в проекте сломалось и как это решали. Подрядчик, который сам рассказывает о сложностях, вызывает больше доверия, чем тот, у кого всё всегда гладко.
Отзывы на сайтах и в каталогах проверяются слабо: их можно купить, накрутить или написать самому. Отраслевые разборы советуют просить доступ к коду и разговаривать с прежними заказчиками. В договор добавляют запрет на передачу работы субподрядчику: портфолио подделать легко, а живого заказчика - нет.
Смотрите на косвенные признаки: есть ли у исполнителя люди, которые работают давно (текучка говорит о проблемах внутри), ведёт ли он блог или разборы, где видно ход мысли, совпадают ли сроки в кейсах с реальностью.
Что показывает пробное задание?
Коротко: небольшая платная задача на ваших данных показывает то, что не расскажет ни одна презентация: как исполнитель уточняет требования, что присылает на выходе и укладывается ли в оценку.
Самый честный тест - дать маленькую часть реальной работы на настоящих данных: один отчёт, одна интеграция на тестовом контуре, одна страница с рабочим поведением. Задача занимает несколько дней и стоит немного, а взамен вы видите, как исполнитель работает, пока цена ошибки ещё невелика. Абстрактный тест на выдуманном примере здесь бесполезен: он ничего не говорит о работе с вашими данными.
Оценивают на выходе три вещи. Как исполнитель уточнял задачу: спрашивал по делу или додумывал. Что именно он сдал: работающее или набросок. Совпал ли результат с оценкой: если небольшая задача заняла вдвое больше обещанного, весь проект, скорее всего, поведёт себя так же.
Одна задача не расскажет о человеке всё. Те, кто сам нанимал исполнителей, предупреждают об этом же: смотреть стоит ещё и на ход мысли на встрече.
Как сравнивать коммерческие предложения и оценки?
Коротко: сравнивайте то, что стоит за итоговой суммой: объём работ, допущения, порядок изменений и что входит в поддержку. Разброс цен на одну задачу чаще отражает разное понимание объёма, чем обман.
Два предложения на одну и ту же работу могут отличаться в разы и при этом описывать разное. Пока непонятно, что именно входит в каждое, сравнивать нечего. Одинаковые названия этапов скрывают разный объём: «авторизация» у одного исполнителя - это вход по логину, у другого - роли, сессии и восстановление доступа. Разложите предложения по строкам и смотрите, где расхождения.
| Что сравнивать | На что смотреть |
|---|---|
| Состав работ | одинаковые ли этапы: разбор, проектирование, разработка, тесты, внедрение |
| Допущения | что исполнитель счёл само собой разумеющимся и не заложил в цену |
| Порядок изменений | как считаются правки после старта и кто их согласует |
| Приёмка | по каким признакам работа считается сданной |
| Что после сдачи | гарантийный срок, исправление ошибок, поддержка |
| Команда | кто ведёт проект и что будет, если человек уйдёт |
Самая низкая цена - самый высокий риск: исполнителю придётся где-то экономить, и чаще всего экономят на том, что вы не увидите при приёмке - тестах, обработке ошибок, документации. Завышенное предложение тоже ничего не обещает: часть суммы может уйти в запас на случай, который не наступит.
Красные флаги: когда отказываться?
Коротко: отказывайтесь, когда исполнитель называет точную цену и срок без вопросов, не готов показать договор и приёмку или избегает разговора о правах на код и поддержке. Это не обязательно обман, но проверять такого исполнителя нужно дольше.
| Признак | Решение |
|---|---|
| Называет точную цену и срок после одного созвона, без уточнений | уточнить: пусть объяснит, из чего сложилась оценка |
| Не может объяснить ход работы своими словами | уточнить: попросить разобрать план по шагам |
| Уходит от вопроса о правах на код и исходники | отказаться: права на результат должны быть у вас |
| Не говорит, что будет после сдачи | отказаться: поддержка не обсуждалась |
| Портфолио из чужих кейсов или без контактов заказчиков | отказаться: нечего проверять |
| Готов подписать договор только на своих условиях без правок | отказаться: у вас не будет защиты |
| Настаивает на предоплате всего проекта целиком | уточнить: платить по этапам нормальнее |
| Отвечает на вопросы через дни, пропадает на неделю | отказаться: в проекте будет так же |
Красные флаги не приговор по одному. Смотрите на их количество: один повод уточнить - нормально, четыре-пять подряд - повод искать дальше. Отраслевые обзоры среди тревожных признаков называют отсутствие похожих проектов, вялую переписку до найма и молчание о том, что будет после запуска.
Что проверить в договоре до подписания?
Коротко: в договоре должно быть описано, что считается результатом, как он принимается, кому принадлежат права на код и что происходит после сдачи. Сумма и срок - не единственное, о чём стоит договориться.
Разработку на заказ чаще всего оформляют договором подряда: исполнитель делает работу и сдаёт результат, заказчик принимает и платит. В законе есть статьи, о которых полезно знать до подписания, пока спора ещё нет.
Что считается результатом и как он принимается, описано в статье 720 ГК РФ; требования к качеству работы - в статье 721, а последствия недостатков и обязанность их исправить - в статье 723. Если в договоре не будет своих критериев приёмки, принять работу придётся по общим правилам, и доказать, что работа сделана плохо, станет труднее.
Права на программу, созданную по заказу, закон решает в пользу заказчика: по статье 1296 ГК РФ исключительное право принадлежит тому, кто заказал разработку, если в договоре не написано иное. Проверьте, что ваш договор не переписывает это в пользу исполнителя. Иначе после смены подрядчика может оказаться, что продолжить работу над своим продуктом вы не имеете права.
Ещё три пункта, которые смотрят до подписания: как считается дополнительная работа (новая оценка и согласие до начала), какая ответственность у исполнителя за срыв срока, и что входит в поддержку после сдачи. Договор стоит показать юристу, который работал с ИТ.
Как не переплатить за работу?
Коротко: переплачивают в двух случаях: когда требования разобраны плохо и исполнитель закладывает в цену запас, и когда заказывают больше, чем нужно. Чем яснее описана задача, тем меньше запаса и доплат.
Оценку до разбора требований называют конусом неопределённости. Стив Макконнелл, автор книги об оценке программных проектов, показывает: в начале разброс огромный и сужается только с каждым принятым решением. Исполнитель, который называет фиксированную цену раньше этого, защищается запасом на всё непонятное. Запас вы оплачиваете вперёд - это плата за чужую осторожность.
Похожий механизм описал Мартин Фаулер и назвал его миражом фиксированного объёма. Когда цену и объём жёстко закрепляют, часть исполнителей специально занижает цену на входе и добирает на изменениях: каждая правка оформляется отдельным соглашением.
Ещё один источник переплаты - лишняя работа. Иногда задача решается проще, чем кажется. Часть функций не нужна на старте, часть закрывается готовыми средствами. Честный исполнитель скажет об этом сам, даже если это уменьшит его смету.
Что делать после выбора подрядчика?
Коротко: до первой строки кода зафиксируйте, что будет сделано, по каким признакам это примут и как считаются изменения. Только после этого начинайте разработку: так спор о качестве решается по заранее описанным признакам, а не в конце проекта.
Когда исполнитель выбран, не спешите начинать работу.
- Разбор требований: что именно делаем, в каком порядке, что считаем готовым результатом.
- Критерии приёмки для каждого пункта - признаки, по которым вы проверите, что работа выполнена.
- Ведение изменений: как оформляется новая просьба, кто её оценивает и согласует.
- Цена и срок - зафиксированы до старта, дальше меняются только через согласование.
Такая подготовка выглядит как лишний этап, но она снимает главный риск: спор о том, хорошо ли сделана работа, разбирается по заранее описанным признакам, а не по ощущениям в конце. В одном из наших проектов заказчик получил описание, по которому подрядчик может назвать цену и сдать работу, а спор о качестве решается по эталону.
Если вы запутались в задаче и не можете выбрать исполнителя, дело не в вас. На разборе часто выясняется, что задача решается проще, чем казалось, и дешевле.
Источники
- Гражданский кодекс РФ, статьи 709, 720, 721, 723 - цена и смета, приёмка работы, качество, последствия недостатков (часть вторая): https://www.consultant.ru/document/cons_doc_LAW_9027/
- Гражданский кодекс РФ, статья 1296 - права на программу, созданную по заказу (часть четвёртая): https://www.consultant.ru/document/cons_doc_LAW_64629/e1a2a66199f94c314b8613a44d2abbad7203f7ee/
- Мартин Фаулер, «Fixed Scope Mirage»: https://martinfowler.com/bliki/FixedScopeMirage.html
- Стив Макконнелл, «The Cone of Uncertainty»: https://www.construx.com/books/the-cone-of-uncertainty/
- АЛРФ, о договоре подряда и акте приёмки: https://alrf.ru/articles/podpisyvayte-vsegda-dogovor-i-akt/
- CMS Magazine, «Красные флаги в договоре с подрядчиком»: https://cmsmagazine.ru/journal/items-krasnye-flagi-v-dogovore-s-podryadchikom/
- ComNews, «Как распознать недобросовестного ИТ-подрядчика»: https://www.comnews.ru/content/234147/2024-07-05/2024-w27/1009/
- ITWeek, «Как не ошибиться с выбором ИТ-подрядчика»: https://www.itweek.ru/management/article/detail.php?ID=229696
- European Business Magazine, «The red flags to watch for when choosing a software developer»: https://europeanbusinessmagazine.com/the-red-flags-to-watch-for-when-choosing-a-software-developer/
- DOU, об ограничениях тестовых заданий: https://dou.ua/lenta/articles/test-assignment-for-job-seekers/
Если выбирать подрядчика всё равно тревожно, начните с малого: опишите задачу, и мы пришлём состав работ и смету за 24 часа - без обязательств.