Большинство срывов в заказной разработке случаются не из-за кода, а из-за того, что никто не знает, кто решает, как выглядит «готово» и как менять договорённости. Этот урок описывает рабочий порядок проекта со стороны заказчика: кого назначить, как проходит цикл с демо, как фиксировать готовность и что делать, когда требования меняются.
После урока вы сможете
- Назначить роли со стороны заказчика и понять роли исполнителя
- Договориться о ритме демо и о том, что значит «готово»
- Вести изменения требований через журнал, а не через переписку
Содержание
Кто за что отвечает
Со стороны заказчика нужны три роли. Один человек может совмещать их в небольшом проекте, но записать их стоит всё равно.
Владелец продукта
- Что делает
- Принимает решения по функциям и приоритетам, согласует результат
- Чем рискуете, если её нет
- Требования меняются с каждым совещанием, каждая итерация удваивается
Представитель пользователей
- Что делает
- Показывает реальную работу сотрудников, тестирует на демо
- Чем рискуете, если её нет
- Продукт соответствует брифу, но неудобен тем, кто будет им пользоваться
Ответственный за доступы и данные
- Что делает
- Предоставляет тестовые доступы, выгрузки, ключи, решает вопросы безопасности
- Чем рискуете, если её нет
- Проект стоит из-за ожидания данных, и срок сдвигается по вашей вине
Со стороны исполнителя обычно есть руководитель проекта (связь с вами, сроки, риски), аналитик или дизайнер (сценарии, макеты), разработчики, тестировщик. Уточните на старте имена и то, кто из них может принимать решения от имени компании. И убедитесь, что вы знаете, кто ваш единственный контакт: если вопрос нужно задавать пятерым, отвечать будет никто.
Этапы и цикл с демо
Типичный проект проходит одни и те же этапы, независимо от размера:
- Бриф и оценка. Задача, объём первой версии, смета.
- Проектирование. Сценарии, прототипы, схема данных. Результат: что именно строим, с экранами.
- Разработка итерациями. Части продукта выходят по порядку приоритета.
- Тестирование и приёмка. Проверка на реальных данных, замечания, правки.
- Запуск и стабилизация. Развёртывание, наблюдение, исправление ошибок первых недель.
Центральный элемент этапа разработки — демо: показ работающего результата на тестовой версии. Не слайды и не скриншоты, а живой продукт, в котором вы сами можете что-то нажать. Рабочий ритм: демо через каждую итерацию, обычно раз в одну-две недели, в одно и то же время. Если за месяц у вас не было ни одного демо, пора задавать вопросы. Из чего складывается срок и что его удлиняет, разобрано в статье «Сколько времени занимает разработка».
Чтобы демо работало, подготовьтесь:
- заранее получите перечень того, что будут показывать;
- пригласите представителя пользователей, а не только руководителя;
- сверяйте показанное с критериями из брифа, а не с общим ощущением;
- дайте обратную связь в оговорённый срок. Задержка с ответом на вашей стороне также сдвигает срок проекта.
Что значит «готово»
У команды и заказчика всегда два представления о готовности, если их не согласовать. Договоритесь на старте об определении «готово» для любой функции:
- критерии из брифа выполнены, вы проверили их сами или вместе с командой;
- функция работает на тестовых данных, близких к реальным;
- известных блокирующих ошибок нет;
- права ролей проверены;
- инструкция или заметка для пользователей обновлена;
- функция развёрнута на стенде, где вы можете её увидеть без помощи разработчика.
«Готово на моём компьютере» и «готово, но нужно ещё чуть-чуть» готовностью не считаются. Каждый пункт определения проверяется на демо, а результат фиксируется в виде короткой записи: что принято, что вернулось на доработку и почему.
Как менять требования
Требования изменятся. Это нормально: вы увидите работающий продукт и поймёте то, чего не понимали по описанию. Проблема не в изменении, а в том, что оно происходит устно и без оценки последствий. Простой порядок:
- Любое изменение записывается в общий журнал: что изменилось, кто просит, зачем.
- Исполнитель оценивает влияние на срок, бюджет и состав работ и отвечает письменно.
- Владелец продукта принимает решение: сделать сейчас, перенести на следующую очередь или отказаться.
- Решение фиксируется в журнале, а при изменении цены или срока — в дополнительном соглашении.
Работает правило обмена: добавили новое — решите, что убрать или отложить. Иначе пакет работ растёт, а срок и бюджет остаются прежними только на бумаге. Отдельно различайте две вещи: замечание о несоответствии зафиксированному поведению (исправляется в рамках оплаченной работы) и новая идея (отдельная оценка). Эту границу лучше записать в договоре, как описано в статье «Гарантии и договор».
Рабочий лист: карта проекта
Заполните одну страницу и отправьте исполнителю — вам нужно письменное согласие на каждый пункт. Ответы сохраняются в вашем браузере.
Рабочий лист
Карта проекта
Заполнено 0 из 8
Имя, сколько часов в неделю у него есть, и что он вправе решать без согласований
Кто показывает реальную работу и тестирует на демо
Кто даёт тестовые доступы, выгрузки, ключи и решает вопросы безопасности
Единственный контакт со стороны исполнителя и кто принимает решения от его имени
День, время, длительность; кого приглашаем
Шесть пунктов из урока, поправленные под ваш случай
Журнал → письменная оценка влияния → решение владельца продукта → фиксация
За сколько дней вы отвечаете на вопросы и замечания исполнителя
Ответы хранятся только в вашем браузере — на нашем сервере их нет. Скачайте файл, чтобы не потерять.
Чек-лист: перед каждым демо
Подготовка к демо
Выполнено 0 из 5
Отметки хранятся только в вашем браузере.
Проверьте себя
Самопроверка: как идёт проект
0 из 5
Ответы хранятся только в вашем браузере.
Что дальше
Когда функции начинают выходить итерациями, наступает момент приёмки. Следующий урок: «Приёмка работ: что проверить до подписания акта». Подход к ведению проектов на нашей стороне описан на странице заказной разработки ПО.