Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".
Создание новых продуктов связано с большим количеством неопределенности.
Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.
Клепая простейшие CRUD приложения, проблеме планирования неоткуда взяться: общаемся с потенциальными пользователями, делаем несколько макетов будущего продукта, определяем требования, отправляем это всё команде дизайнеров и разработчиков. Готово – выпускаем.
Но когда мы разрабатываем продукты с большим количеством технических и бизнесовых неопределенностей — а это именно то, чем обычно занимаются стартапы и продуктовые команды — то такой план трещит по швам. Методология, призванная ускорить разработку, наоборот её замедляет, команда от этого стрессует и ловит фрустрацию, отставая от сроков всё больше и больше.
Это происходит, когда беспочвенный оптимизм разбивается о жестокую реальность неопределенности, свойственной процессу разработки продукта.
Неопределенности технических продуктов
Проблема классической системы планирования в том, что она не объясняет как работать с неизвестностью и неопределенностью, с тем, из чего состоит разработка сложных продуктов.
В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей – неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.
За последний год мы разработали систему планирования которая позволяет решать поставленные задачи, минуя проблемы классического подхода.
Основа нашей системы — это три техники, пришедшие из Agile/Scrum:
Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.
Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.
Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.
Мы идём по этим пунктам раз за разом, в зависимости от того, на каком уровне неопределенности мы находимся с текущей проблемой.
Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:
Мы можем продвигаться быстро, но не так быстро, чтобы закапывать себя в технических долгах.
Мы можем вносить коррективы на ходу, не привязываясь к дате начала следующего спринта.
Мы можем изучать вопрос итеративно, нежели надеяться, что команда знает все аспекты проблемы наперед.
Когда всё совсем непонятно – мы не знаем как приступить к задаче, – мы проводим анализ. Когда в результате приходит в голову возможное решение – мы делаем спайк, чтобы понять предметную область. Далее мы выпускаем трассер, чтобы убедиться, что текущее решение может слаженно работать с нашей текущей архитектурой. Если всё ок, двигаемся дальше. Если нет, то можем вернуться к самому началу.
На каждом шаге система дает новую информацию для следующего шага и для выхода из неопределенности в целом. Эта постоянная обратная связь, вероятно, самая важная деталь всего подхода.
Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.
Идея нашей системы в признании, что системы рано или поздно дают сбой, нужно принимать план Б или даже план В. Просто нужно быть к этому готовыми.
1. Анализ
Начинайте с проведения анализа если:
У вас есть проблема
Вы не знаете как её решить
Не важно, пытаетесь ли вы перестроить всю архитектуру или просто добавляете новую кнопочку на свой сайт.
Без понимания как решить проблему не торопитесь писать код. Наоборот, вам нужно заняться анализом, продумать возможные пути решения, а после прикинуть все плюсы и минусы каждого из них.
Плюсы и минусы должны быть основаны на технических факторах типа:
Насколько трудоёмкая будет реализация
Насколько дорого это выйдет
Сколько времени потребуется
Какой гибкости мы лишаемся, принимая именно это решение
Насколько этим удобно будет пользоваться
Под разные команды значимость тех или иных факторов может быть разная.
В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:
Наша операционная нагрузка
Наш автобусный фактор
Скорость нашей команды
Мы анализируем каждый из путей, оценивая то, как мы можем уменьшить нашу операционную нагрузку, уменьшить автобусный фактор и улучшить скорость нашей команды.
Одним из распространенных результатов анализа — это документация типа такой:
Repository: плюсы и минусы
Плюсы
Это эффективный способ предоставлять доступ большому объему данных: записал один раз и читаешь отовсюду
Подсистемам не нужно думать как создаются и потребляются данные в других подсистемах
Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных
Работа с данными происходит по общей схеме, поэтому легче подключать новые подсистемы
Минусы
Подсистемы должны работать с общей схемой, что может влиять на производительность
Эволюция данных: "дорого" принимать новую модель данных, потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать
Нет уверенности, что в вопросах безопасности и бэкапов репозиторий всегда будет удовлетворять некоторые подсистемы
Довольно сложно деплоить репозиторий на несколько машин, сохраняя видимость централизованного хранилища, из-за необходимости в избыточности данных и сохранении консистентности
Анализ, как целенаправленная деятельность, должен быть ограничен по времени (чтобы вы не тратить бесконечное количество времени, выбирая разные варианты) и предоставлять либо один конкретный из возможных путей решения, либо понимание, что не имеет большого смысла в это погружаться самостоятельно и лучше перепоручить это специалистам извне.
2. Spike
Спайк нужен, когда:
У вас есть проблема
У вас есть хоть какая-то идея как её решить
Спайк — это решение на коленочке на выброс. Иногда это может показаться пустой тратой времени, но хороший спайк может выявить детали, которые могут остаться незамеченными, бросайся мы прямиком к серьезному проектированию.
Хотя результат спайка и будет выброшен по завершению, но используя его правильно, мы можем глубже погружаться в суть самой проблемы.
Спайк сам по себе не поможет решить задачу быстрее, но даст понимание того, как с продуктом взаимодействуют люди в настоящих условиях, от чего мы сами сможем продвигаться к решению быстрее.
Хороший пример — это бумажный прототип.
Собирание бумажного макета может показаться бессмысленным, особенно сейчас, когда его можно по быстрому накидать в Sketch и экспортировать в любой удобный формат, но обыкновенным людям, тестировщикам продукта, может быть удобнее взаимодействовать с бумагой. Включаются тактильные взаимодействия с продуктом, а давать обратную связь становится ещё проще.
Минимальным вкладом в решение при обычном планировании является то, как мы начинаем фактически решать проблему. При спайках же минимальный вклад — это нечто, что помогает выяснить в чем на самом деле состоит проблема.
3. Трассер
Трассирующая пуля, трассер — это боевой припас особой конструкции, который оставляет луч света в полёте. В разработке трассер — это техника для ситуаций, когда:
У вас есть проблема
У вас есть решение, но вы не знаете как много времени это займет.
Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:
очень небольшое
запускается в продакшен окружении
остается, а не выбрасывается
Представьте, что вам нужно сделать подписку на емейл рассылку с вашего сайта. В этом случае спайк может быть бумажным прототипом. Трассером может быть поле ввода на сайте и кнопка, которая:
успешно получает текст из поля ввода
отправляет этот текст в Segment
идёт в customer.io из Segment
обновляет список для рассылки
Может не быть валидации почты, да и любого количества улучшений, после которых мы будем считать дело сделанным, но если эта последовательность действий работает (в том числе в продакшен окружении), то она будет работать и после внесения финальных штрихов.
Трассер — это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.
Трассер здесь для того, чтобы доказать, что решение действительно работает, захватив предметную область настолько широко, чтобы взглянуть на картину в общем, но не достаточно широко, чтобы тратить на это слишком много времени.
Цикл Анализ — Спайк — Трассер
Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"
Быстрое движение не сводится к тому, чтобы как можно быстрее составить законченный план, потому что никто не знает реалистичен ли такой законченный план в принципе.
Работая над проектами с большим количеством неопределенности или технических рисков, нам следует анализировать, делать спайки и трассеры, чтобы шаг за шагом, итеративно рассеивать неизвестность — следовать лучикам света в темном лесу.
Благодарю Антона Сметанина @dizzy_dalvin за помощь в редактуре
