Как не уволиться после третьего «всё переделываем», или Почему правки — это хорошо
Пока у всех дёргается глаз после очередной итерации правок, мы радуемся. Рассказываем, почему правки это нормально и что делать, если проект идёт не туда.
Как это обычно бывает
Знаете игры, где от вашего выбора зависит развитие сюжета? Так и здесь: у заказчика есть два пути, которыми он может пойти. И если проект идёт не туда, чаще всего дело в двух типичных причинах.
Развилка № 1: клиент знает, чего хочет, и предлагает конкретную реализацию, которая не подходит его проекту
Представим, что к нам пришёл вымышленный заказчик — Барсик Лапкин, владелец крупного интернет-магазина зоотоваров. У него маленький технический штат — всего три разработчика, которые поддерживают большую платформу. Команда знает, что им нужно, но решения не подходят для целей бизнеса:
- «Сделайте нам личный кабинет, чтобы как у банка: с пушами, автосохранением и сегментацией».
- «Фильтры должны быть как у OZON».
- «Лучше сразу на микросервисах, чтобы потом не переписывать».
На деле это значит, что никто до конца не понимает, какие задачи приоритетные, зачем нужен кабинет и будет ли им кто-то пользоваться. Формулировки общие, но при этом у клиента уже есть чёткое представление, как нужно делать. Поэтому важно не бежать сразу в реализацию, а на старте сделать шаг назад, разобраться, какие у бизнеса цели, что действительно нужно пользователям, и уже потом обсуждать, какими средствами этого достичь.
Тем не менее проект уже стартует, а значит, нам нужно много общаться с Барсиком Лапкиным и его командой, уточнять, переспрашивать, а где-то даже брать за основу предположения, чтобы не просто «сделать кабинет», а сделать платформу, которая будет работать.
Развилка № 2: клиент меняет решения на ходу, а команда уже всё сделала
У Барсика Лапкина есть вымышленный партнёр — Мурзик Мурлыкин, серьёзный бизнесмен и производитель кошачьих вкусняшек. В отличие от коллеги, у Мурзика почти нет технических специалистов в команде. Есть только один разработчик на подряде, который поддерживает сайт. Из-за этого бизнесмен меняет решения на ходу:
- Сначала — «Хочу создать онлайн-сервис психотерапии для котов. Внутри ещё будет магазин с вкусняшками».
- Через два месяца — «Я решил, что онлайн-сервис психотерапии — ерунда. Давайте лучше сделаем платформу по передержке для котиков и туда засунем магазин с вкусняшками».
- Через год — «А почему бы не сделать просто интернет-магазин с кормами, пивом и шоколадом для котов?».
И в моменте каждый новый виток идей кажется логичным, если бы к этому времени не было проделано столько работы:
- продуман UX платформы онлайн-сервиса психотерапии;
- свёрстан раздел «Выберите своего кошачьего психолога»;
- подключён календарь для бронирования услуг для сервиса по передержке.
При самом плохом варианте всё сложится в папку «Не пригодилось», потому что вместо одного внятного продукта получается комбо из трёх незавершённых. Команда устаёт от постоянных изменений, а работа превращается в бесконечное «сначала». Ни один функционал не доведён до конца, потому что при каждом созвоне цели обновляются (а значит, и задачи тоже).
Хотя развилки историй Барсика и Мурзика разные, решение одно. Объясняем дальше, как работать в таком режиме (и почему местами это даже полезно).
Почему так происходит и нормально ли это
Познакомим вас поближе с нашими уважаемыми, но вымышленными клиентами. На примерах Барсика и Мурзика расскажем, как подход заказчика к процессам влияет на проект.
Барсик Лапкин
Владелец интернет-магазина больше полагается на силы команды, чем на свои. Барсик начинал давно, и тогда ещё не было интернета. Кот хорошо разбирается в офлайн-бизнесе, но ничего не понимает в онлайне, поэтому выбирает передать эти заботы компетентным специалистам. В итоге проделанную работу согласовывает его команда разработчиков, а он лишь изредка проверяет сделанное и ждёт результата. Да и ресурс тратить неохота: лучше попить молока с семьёй.
Мурзик Мурлыкин
А вот бизнесмен вовсю вовлечён в проект. Он много читает про IT, интересуется искусственным интеллектом, и у него в голове тысяча идей, которые хочется реализовать. Поэтому Мурзик каждый день созванивается с командой, интересуется, на какой стадии разработка, и предлагает разные инструменты для реализации задач.
Кажется, что с такими разными подходами к проектам и у команды должны быть разные стратегии работы, индивидуальные под каждого заказчика. Но это не так: цель в обоих случаях одинаковая — максимально включить клиента в процессы, чтобы исключить риски и дать заказчику результат, который ему понравится. Для этого мы:
- Разговариваем. Например, у Мурзика должен быть в команде тот, кто говорит по-человечески и с командой, и с пушистым бизнесменом. Такой «переводчик» с проектного на простой. Он объяснит, почему мы выбрали микросервисную архитектуру и что за гибкая методология, по которой мы работаем. Обычно эта задача ложится на проджект-менеджера, который понимает, чего хочет бизнес и как это объяснить технической команде.
- Регулярно стучимся к клиенту. Даже если Барсик ушёл пить молоко, а Мурзик уехал на конференцию по нейронкам, мы всё равно продолжаем держать руку на пульсе. Созваниваемся, присылаем промежуточные версии, уточняем, всё ли идёт по плану. Лучше на раннем этапе вместе решить, что нужно переделать, чем через три месяца услышать: «А мы хотели по-другому».
Когда проект идёт не туда, это нормально, потому что часто вначале никто не знает, куда нужно прийти. И это естественно: бизнес растёт, приоритеты меняются, появляются новые идеи. Например, Мурзик вчера хотел сделать психологическую онлайн-платформу, а сегодня с аналитиками решил, что для его целей сервис по передержке сработает лучше.
И это не значит, что вначале команда не собрала достаточно информации о проекте или просто плохо работала. Это значит, что проект живой, он развивается и будет долгосрочным. И всё, что нужно сделать, — это не пытаться угадывать мысли клиента, а создать процесс, в котором любые повороты маршрута не превращают проект в бардак.