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