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