Выбор подрядчика — это оценка рисков, а не поиск самой низкой цены. Ниже вопросы, ответы на которые показывают, как команда работает на самом деле. Задавайте их до договора, а не после первого срыва сроков.
Про команду и процессы
- 1 Кто конкретно будет работать над проектом и сколько людей в команде?
- 2 Что произойдёт, если ведущий разработчик уйдёт в отпуск или уволится?
- 3 Как вы оцениваете задачи и что делаете, когда оценка не сходится с фактом?
- 4 Как выглядит ваш обычный отчёт о ходе работ и как часто он приходит?
- 5 Кто со стороны заказчика должен участвовать и сколько времени это займёт?
Про качество и тестирование
- 1 Есть ли автоматические тесты и что именно ими покрыто?
- 2 Как вы проверяете проект перед выкладкой на прод?
- 3 Что происходит при сбое на проде: кто узнаёт первым и как?
- 4 Делаются ли резервные копии и проверялось ли восстановление из них?
Про код и независимость
- 1 Кому принадлежат права на код и где он хранится?
- 2 Сможет ли другая команда продолжить работу без вас?
- 3 Есть ли документация и в каком виде вы её передадите?
Ответ «код на нашем сервере, доступ дадим по запросу» — прямой риск. Рабочий вариант: репозиторий принадлежит заказчику, доступ у команды.
Что поддерживать после запуска
- Стоимость поддержки и что в неё входит, а что считается доработкой.
- Время реакции на критичный сбой и как оно фиксируется в договоре.
- Порядок передачи проекта, если вы решите сменить команду.
Признаки, что проект придётся переделывать
- Оценку называют за один день, не задав ни одного вопроса о процессах.
- Смета состоит из одной строки без детализации.
- Ни слова о тестах, окружениях и мониторинге.
- Отказ назвать состав команды.
- Готовность взяться за любую задачу — от мобильного приложения до 1С — силами трёх человек.
Если проект уже пишется и появились сомнения, полезнее не менять подрядчика вслепую, а сначала получить независимую оценку состояния кода — это то, что даёт технический аудит. С ним разговор о передаче проекта идёт предметно, а не на доверии.