2-1 · Глава 2 · 4 мин. чтения

Настоящая отправная точка доставки программного обеспечения — это не код

Каждый развертывание начинается не с пул-реквеста или строки кода, а с идеи. Узнайте, как формализовать процесс от идеи до задачи и избежать пустой работы.

Настоящая отправная точка доставки программного обеспечения — это не код

Каждое развертывание, которое вы когда-либо делали, откуда-то начиналось. Но это «откуда-то» — не пул-реквест, не ветка и не строка кода. Оно начиналось раньше, часто с разговора, который никто не додумался записать.

Представьте: пользователь сообщает, что кнопка «Сохранить» не работает. Или на совещании команды кто-то говорит: «Надо бы добавить уведомления». Или в логах ошибок видно, что у базы данных постоянно заканчиваются соединения. Эти моменты и есть настоящие отправные точки доставки программного обеспечения. Прежде чем появится какой-либо код, прежде чем запустится хоть один пайплайн, кто-то должен решить: какую идею реализовывать, а какую отложить или вовсе отбросить.

Ловушка неформальности

В небольших командах этот процесс принятия решений кажется естественным. У кого-то возникла идея, он поговорил с коллегой и начал писать код. Это кажется быстрым и эффективным. Но за этой скоростью скрываются неочевидные издержки.

Идея, которую не продумали, превращается в код, на который тратится время впустую. Два человека могут параллельно делать одну и ту же функцию, не зная о работе друг друга. Хорошая идея теряется, потому что её никто не записал. Команда выкатывает код, но код не решает реальную проблему.

Я видел, как команды тратили недели на создание функции, которую никто не просил, просто потому, что исходная идея была расплывчатой и никто не подверг её сомнению до начала написания кода. Код работал. Тесты проходили. Но функция оставалась невостребованной, потому что не соответствовала тому, что на самом деле нужно пользователям.

От идей к отслеживаемой работе

По мере роста команды и повышения серьезности продукта неформальных разговоров перестает хватать. Нужна система для захвата, обсуждения и приоритизации идей до того, как они превратятся в код.

Большинство команд используют какую-либо форму отслеживания задач: Jira, Trello, GitHub Issues, Linear или даже общий документ. Каждая идея становится тикетом с описанием того, что нужно сделать, почему это важно, а иногда и как к этому подойти. Затем команда обсуждает: это важно? Это срочно? Можем ли мы сделать это с тем, что у нас есть прямо сейчас?

Это обсуждение важно, потому что у вашей команды ограниченное время и энергия. Не каждую идею можно реализовать. Приходится выбирать. Решение может основываться на бизнес-приоритете, технической срочности или на том, кто доступен для работы.

Некоторые команды используют спринт-планирование, чтобы решить, какие тикеты войдут в следующий рабочий цикл. Другие используют асинхронное голосование в чате или регулярные сессии по бэклогу. Формат менее важен, чем привычка принимать явные решения до того, как кто-то напишет код.

Скрытая работа до кода

Вот что легко упустить: на этом этапе кода еще нет. Есть только заметки, обсуждения и решения. Но именно здесь начинается настоящий путь доставки. Тикет, получивший приоритет, становится входными данными для следующего шага: написания кода.

Многие инженеры и менеджеры думают, что доставка начинается, когда кто-то открывает редактор и начинает печатать. Это не так. До первого нажатия клавиши уже существует цепочка решений, определивших, стоит ли вообще писать код, что он должен делать и как к этому подойти.

Команды, которые пропускают эту фазу, часто получают код, который не используется, функции, которые не попадают в цель, или переделки, которые сжигают время и моральный дух. Код может быть технически безупречен. Но если он решает не ту проблему, техническое совершенство не имеет значения.

Почему это важно для вашего пайплайна

Вы можете подумать: «Это звучит как управление проектами, а не как CI/CD». Но вот в чем связь.

Ваш пайплайн доставки предназначен для того, чтобы взять идею и безопасно и быстро превратить ее в работающее программное обеспечение. Если сама идея плохо определена, ваш пайплайн становится машиной, которая быстрее доставляет плохие идеи. Быстрый пайплайн не помогает, если вы доставляете не то, что нужно.

Вот почему зрелые команды инвестируют в фазу до кода. Они убеждаются, что идея ясна, приоритет установлен, а ожидаемый результат определен. Затем они позволяют пайплайну делать свою работу — эффективно доставлять это четко определенное изменение.

Практический чек-лист до написания кода

Прежде чем кто-либо напишет код для следующей функции или исправления, пройдитесь по этим вопросам:

Какую проблему это решает? Можете ли вы описать ее одним предложением без использования технического жаргона?
Кому это выгодно? Пользователям, внутренним командам или просто для удобства команды разработки?
Что произойдет, если мы не сделаем это? Если ответ «ничего плохого», пересмотрите приоритет.
Есть ли более простой способ проверить идею? Можете ли вы провести валидацию с помощью ручного процесса, фича-флага или прототипа, прежде чем браться за полную реализацию?
Кому нужно знать об этом изменении? Саппорту, документации, QA, эксплуатации или другим командам, которых это может затронуть.

Этот чек-лист занимает пять минут. Он может сэкономить недели потраченных впустую усилий.

Вывод

Код — это не отправная точка доставки. Отправная точка — это идеи. Качество вашей доставки зависит не только от того, как быстро вы можете выкатить код, но и от того, насколько хорошо вы решаете, какой код писать в первую очередь.

Прежде чем оптимизировать свой пайплайн, оптимизируйте свой процесс от идеи до решения. Быстрый пайплайн, который доставляет не то, что нужно, — это просто более быстрый способ тратить время впустую. Сначала добейтесь правильной идеи, а затем позвольте вашему пайплайну делать то, что у него получается лучше всего: безопасно и многократно доставлять эту правильную идею.