Как контролировать разработку, если вы не программист

Чтобы контролировать разработку без технических знаний, не нужно читать код. Нужны пять вещей: тестовая версия, которую вы открываете в любой момент; демонстрация результата раз в неделю; доска задач, где видно, что сделано и что в работе; журнал изменений требований; и доступы к репозиторию, хостингу и домену на вашем аккаунте. Этого хватает, чтобы заметить проблему через неделю, а не через три месяца. Для крупных проектов раз в 1–2 месяца полезен независимый взгляд другого разработчика.

Инструмент 1. Тестовая версия

Тестовая версия — копия будущего сайта или системы на отдельном адресе, например test.vash-sajt.ru. Подрядчик выкладывает туда сделанное, и вы можете открыть и проверить. Требуйте её с первой-второй недели. Если тестовой версии нет месяц, вы не знаете, что происходит с проектом.

Что проверять самостоятельно:

• Открывается ли то, что обещали к этой дате.
• Работает ли на вашем телефоне.
• Проходит ли главный сценарий: оставить заявку, оформить заказ, создать клиента.
• Совпадает ли с утверждённым макетом.

Инструмент 2. Демонстрация раз в неделю

Короткий созвон на 20–30 минут, где подрядчик показывает работающую версию и рассказывает, что будет дальше. Это правило из гибких методологий разработки: результат каждого короткого цикла показывают заказчику (описание практики в руководстве по Scrum). Для вас важны не термины, а сам факт: каждую неделю вы видите новый рабочий кусок.

Как проводить:

1. Подрядчик показывает, а не рассказывает. Слайды и отчёты не в счёт.
2. Вы сами пробуете пройти сценарий на демо, не только смотрите.
3. В конце фиксируете: что принято, что нужно поправить, что будет к следующей встрече.
4. Если два раза подряд показывать нечего — это сигнал.

Инструмент 3. Доска задач

Попросите доступ к доске задач подрядчика или ведите общую. Подойдёт любой инструмент: Яндекс Трекер, Kaiten, YouGile, Битрикс24, даже общая таблица. Минимальные колонки — «запланировано», «в работе», «на проверке», «готово».

Инструмент 4. Журнал изменений

Всё, что вы попросили после утверждения ТЗ, записывается отдельно с оценкой и решением. Это защищает от ситуации, когда проект незаметно вырос в полтора раза. Подробно — в статье о новых требованиях посреди проекта.

Инструмент 5. Доступы на вас

Попросите, чтобы с первого дня:

• код хранился в репозитории на вашем аккаунте или вы были его владельцем;
• хостинг и домен были оформлены на компанию;
• аккаунты сторонних сервисов (почта, SMS, платёжный сервис) были на вас.

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

Приёмка этапа без программиста

Приёмка — главный момент контроля. Проверяйте по сценариям из ТЗ, а не «в целом». Для сайта: оставьте заявку с телефона и компьютера и убедитесь, что она дошла туда, куда должна. Для магазина: оформите заказ, оплатите тестовой картой, отмените. Для CRM: создайте клиента, сделку, задачу, посмотрите отчёт, зайдите под ролью менеджера и убедитесь, что чужих клиентов не видно. Каждый сценарий отмечайте как пройденный или с замечанием. Замечания пишите конкретно: что делали, что ожидали, что увидели. Такой протокол занимает час, но потом служит основой и для гарантии, и для оплаты этапа.

Сколько контроля достаточно

Слишком плотный контроль тоже вредит: ежедневные созвоны и десятки уточнений в день отнимают у команды время на работу. Ориентир — одна демонстрация в неделю, проверка тестовой версии перед ней и ответы на вопросы команды в течение рабочего дня. Если проект критичен и идёт большой командой, добавьте короткий письменный статус в середине недели: что сделано, что мешает.

Что делать с технической частью

Есть вещи, которые без программиста не проверить: качество кода, безопасность, архитектура. Здесь помогают:

• Независимый аудит раз в 1–2 месяца или перед приёмкой крупного этапа. Другой разработчик за 1–2 дня смотрит код и отвечает: можно ли это поддерживать, есть ли очевидные уязвимости, соответствует ли подход задаче.
• Автоматические проверки. Спросите, есть ли тесты и запускаются ли они автоматически при каждом изменении. Ответ «нет, у нас всё проверяет тестировщик» для небольших проектов допустим, для сложных систем — тревожный.
• Инструкция по развёртыванию. Попросите описать, как запустить проект с нуля. Если такой инструкции нет, проект зависит от памяти конкретного человека.

Сигналы, что пора вмешаться

• Нет тестовой версии больше трёх недель после начала разработки.
• Демонстрации переносятся.
• На вопросы отвечают «почти готово» несколько недель подряд.
• В репозитории нет новых изменений больше недели.
• Сменился разработчик, и вас не предупредили.
• Подрядчик просит оплату следующего этапа до сдачи текущего.

Каждый сигнал по отдельности может иметь объяснение. Два и больше одновременно — повод для серьёзного разговора и плана восстановления графика.