Штош, первый пост всегда самый сложный.

Позвольте представиться: я фронтендер — разработчик интерфейсов с солидным опытом. В прошлом я работал инженером АСУТП и слесарем по ремонту бортовой авионики летательных аппаратов. Сейчас я занимаюсь программированием и содержу на иждивении рыжего кота.

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

Почему в современной разработке так сложно и дорого изменить цвет кнопки?

Предыстория:

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

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

Что будет дальше?

Я выпущу серию постов о том, как вообще происходят изменения в современных IT-продуктах, на примере простого изменения цвета кнопки.

Продолжение следует.

Я обещал продолжать — я продолжаю, цикл постов будет строиться в формате «шаг за шагом». Я попробую описать действующих лиц и то, что происходит на каждом шаге.
Сразу скажу, что процесс, который будет описан, — сферический в вакууме, для профильных специалистов он может показаться избыточным. Цель всего этого мероприятия — показать, как вообще может быть устроен подобный процесс.    

Начинается всё с менеджера продукта и/или системного аналитика. Кто они такие?

Буду краток, потом перейду на аббревиатуры:

Product Manager (PM)
- Определяет стратегию и видение продукта
- Приоритизирует задачи и управляет бэклогом (очередью задач на разработку)
- Коммуницирует с бизнесом и клиентами
- Отвечает на вопрос «Зачем делать?»

Системный аналитик (SA)
- Анализирует бизнес-процессы и требования
- Формализует технические спецификации
- Проектирует архитектуру решений
- Отвечает на вопрос «Как сделать?»

Что у них общего: Обе роли связывают бизнес и разработку, работают с требованиями.
Чем они должны различаться: PM фокусируется на рыночной ценности и ROI продукта, SA — на технической реализации. PM управляет жизненным циклом продукта, SA проектирует решения под конкретные задачи.

Очень часто, в целом — почти всегда, в компаниях эти роли смешивают, но почему-то продолжают называть их или PM, или SA отдельно, хотя это может быть PM+SA в одном лице. Я буду называть этого человека PM, я так привык, т. к. чистых системных аналитиков никогда в живую не видел.

Вводную закончили, погнали:

Шаг 0: Рождение гипотезы

PM предположил, что если покрасить кнопку из серой в синюю, она станет заметней и пользователи будут по ней кликать больше, чем обычно. Если будут кликать хотя бы на 5–10% больше пользователей, то это приведет к большему количеству целевых действий, что в дальнейшем приведет к росту числа заказов и, в конечном итоге, росту прибыли.
Как он это понял? На кнопке уже была метрика, которая позволяла считать клики и общее соотношение всех посещений к нажатиям. Он посмотрел на метрики других кнопок на этом экране, они в целом схожи, т. к. все они серого цвета и их целевым действием является совершение заказа, просто приводят к заказам товаров с разной стоимостью. Помните? Не просто хлеб, а в нашем случае аж два хлеба, да и с молоком. Таким образом формируется конечная идея:
Ярче кнопка — больше кликов — больше целевых действий с большей стоимостью — больше прибыли. Все довольны, пользователи тратят больше денег, закрыли KPI, получили премии и стали молодцами. У менеджера продукта загорелись глаза, и он пошел описывать задачу.

Жаль, что это только гипотеза, но задача PM — их проверять, а те, которые оправдают себя, — воплощать в жизнь.

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

Шаг 1: Формализация требований

PM описывает требования для разработки, они могут быть в формате пользовательской истории (user story) или описаны просто отдельными связанными между собой пунктами. Требования могут выглядеть, например, так:

Общие требования:

- Кнопка «Купить два хлеба и молоко» должна стать синей в соответствии с макетом, тут может быть ссылка на макет, и хорошо, если она есть.
- Релиз должен быть под экспериментом.
- Кнопка с новым цветом должна отправлять отдельное событие аналитики, которое можно явно отделить от события кнопки до изменения цвета.

Требования к эксперименту:

- Квота пользователей на эксперимент: 10%.
- Длительность эксперимента: 2 недели.
- В случае падения количества кликов более чем на 10% в течение первых 24 часов — сворачиваем эксперимент досрочно.

Стабильный релиз после эксперимента:

- В случае роста количества кликов на 5% и более в течение 2 недель, раскатываем изменения на 100% пользователей, иначе сворачиваем эксперимент и оставляем как было

Далее PM ставит задачу для дизайна — актуализировать кнопку в макетах и подготовить макеты для разработки.
Требования в задаче для дизайна могут быть выглядеть так: «Конкретная кнопка на определенном экране должна сменить цвет с серого на синий.» Хорошо если PM приложит скриншот из интерфейса сервиса и ссылку на задачу, в которой описаны общие требования.

Дальше он ждет, пока дизайн возьмет задачу в работу и вернется к нему с готовыми макетами.

Дизайн в разработке IT-решений и цифровых сервисов играет очень важную роль. Вы даже не представляете, какие ужасные интерфейсы делают разработчики, если им не будут готовить макеты дизайнеры. Не любой дизайнер сможет придумать интерфейс, который будет сочетать в себе красоту и удобство использования (UI/UX). Я встречал примеры хорошо выглядящего дизайна, но совершенно не удобного в повседневном использовании, уверен, что и ты тоже. Красивый дизайн, который еще и удобен — это очень сложно, разработка таких макетов может занимать сотни часов и является очень тяжелой задачей.

Шаг 2: Актуализация макетов

Дизайнер в соответствии с собственными приоритетами доходит до задачи, которую ему поставил PM, открывает макеты — находит нужный, смотрит доступные цвета в продукте, руководствуясь брендбуком или принятой цветовой палитрой, правит цвет кнопки на синий (нужного оттенка), возможно, формирует новый компонент, т. к. эта кнопка в перспективе может быть использована в других частях продукта. Далее ему необходимо показать готовые макеты PM.

Шаг 3: Согласование макета с PM

Если выстроен процесс, то дизайнер дожидается согласования цвета кнопки, если нет — то дизайнер ставит встречу с PM и показывает изменения уже на макете, в процессе может выясниться, что доступный из палитры брендбука синий цвет не подходит, но есть другой. Они могут привлечь еще дизайнера или еще одного PM, обсудить это еще на одной встрече. В конечном итоге одна из них (если повезет — первая) все-таки заканчивается согласованием цвета.

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

Один из главных вопросов, который должен задать себе PM, — а возможно ли вообще внести планируемые изменения в сервис? Как дорого и сложно их будет сделать? В случае простого изменения цвета кнопки рисков того, что это займёт недели или месяцы, практически нет, но в случае более масштабных изменений или планах создания нового функционала такие риски всегда нужно учесть. PM должен держать в голове мысль, что стоимость внесения изменений в продукт может быть существенно больше, чем та польза и выгода, которую они принесут, другими словами, нужно убедиться, что «игра стоит свеч».

Шаг 4: Первоначальная оценка от разработки

На этом этапе PM, в рамках существующего процесса или просто отдельной встречей, собирается с лидами разработки для оценки первоначальных требований. Это должны быть не просто первые попавшиеся высокоуровневые разработчики, а непосредственно владельцы кода, которые очень глубоко понимают, как все устроено в тех частях сервиса, где планируются изменения. Лиды разработки должны ответить на следующие вопросы:
— Достаточны ли требования, описанные в задаче?
— Есть ли «подводные камни» и прочие граничные условия, которые не смог заметить PM?
— Как сложно будет внести предложенные изменения, оценить в часах или SP(story points)?
Если от разработки поступят замечания, PM должен внести их в требования и повторять шаги 1–4 до тех пор, пока требования не будут согласованы с реальностью и всеми участниками процесса. 
Будем считать, что требования согласованы, наконец-то можно нести задачу в команду для ее реализации.

PM подготовил требования, согласовал их с дизайном, лидами разработки и реальностью, самое время отдать задачу в разработку. Но разработчики не сидят без дела, у них есть ранее запланированные задачи, которыми они заняты в текущий момент. Но как отдать им задачу в разработку?
Существуют разные методологии и целые философии управления жизненным циклом проекта, но нам важны именно методологии. Наиболее популярные сейчас это Scrum и Kanban - они используются практически повсеместно, но это отдельная тема, причем не просто для цикла постов, но и целых книг.

Очень коротко об этих методологиях

Scrum - ритмичная работа с временными отрезками - спринтами
- Жёсткая структура: фиксированные спринты (2-4 недели)
- Чёткие роли: Scrum Master, Product Owner, команда
- Планирование объёма работ на спринт

Kanban - непрерывный поток без разделения по времени, когда задачи добавляются в самый конец или в соответствии с их приоритетами
- Задачи поступают и завершаются непрерывно
- Нет строгих ролей/сроков
- Ограничение количество задач в работе одновременно
- Фокус на оптимизацию потока

Я привык работать по Scrum, потому будем считать, что в текущем примере используется он, тогда нам потребуется этап планирования, но если бы использовался Kanban - то PM просто положил задачу на некую доску, в соответствии с ее приоритетом или в рамках какого-то утвержденного процесса, и команда до нее со временем добралась.

Шаг 5: Планирование спринта

В один прекрасный день вся команда разработки и PM собирается на встрече, на которой они совместно планируют объем работ на ближайший спринт. PM показывает команде уже согласованные и уточненные требования, так что команде остается их внимательно изучить, задать вопросы и уточнения, если они появятся, и дать оценку сложности реализации в часах или Story Point (SP). После чего формируется объем задач на следующий спринт, где интересующая нас задача займет в нем свое место в соответствии с ее приоритетом относительно других задач.

Спустя какое-то время разработчик добрался до задачи, она хорошо описана, согласована всеми, кем только можно, он берет ее и делает.

Шаг 6: Разработка

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

Шаг 7: Ревью кода

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

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

Всё не так просто, разработчикам верить нельзя, правда. Даже если они со слезами на глазах утверждают, что всё отлично, изменения простые и не содержат багов. Они точно врут! Сами того не ведая.

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

Точно ли там нет багов и как новый функционал соответствует требованиям, определяет служба качества (QA). Иногда пройти тестирование — отдельный сложный квест.

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

CI/CD (Continuous Integration/Continuous Delivery) — если очень коротко - автоматизация сборки, тестирования и развертывания кода для быстрого/безопасного обновления ПО.

Шаг 8: Развертывание на тестовом окружении

Допустим, CI/CD все-таки существует и изменения можно доставить на стенд, тогда разработчик нажимает кнопку в системе управления версией (GitHub/GitLab/Bitbucket/Another) и оно само магически разворачивается в некое окружение, в зависимости от уровня колдуна, который настраивал CI/CD, после этого может запуститься процесс тестирования или дизайн-ревью, все нужные люди призовутся сами в задачи и им придут уведомления

Шаг 9: Дизайн-ревью

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

Дизайнер получает ссылку на тестовый стенд и, возможно, тестовые доступы, чтобы он мог пойти и посмотреть, чего там напрограммировали разработчики интерфейсов. Если дизайнер найдет проблемы, то заведёт задачу, в которой опишет, что именно ему не понравилось, тогда шаги 6–8 будут повторяться, пока дизайн не согласует то, что было сделано.

Внимание, анекдот!

Заходит тестировщик в бар. Заказывает кружку пива. Заказывает 0 кружек пива. Заказывает 999999999 кружек пива. Заказывает -1 кружку пива. Заказывает ФАОЛФВОЫЛ. Тут заходит реальный пользователь. Спрашивает, где здесь туалет. Бар сгорает в адском пламени, убивая всех вокруг.
Тестирование действительно важный этап, который помогает существенно улучшить качество сервиса. Тестирование — это отдельная огромная тема, в которую, я уверен, когда-нибудь я зароюсь с головой и расскажу интересные штуки.

Шаг 10: Тестирование

После дизайн-ревью подключается команда тестирования. Они (или это вообще один человек) детально исследуют стенд, который передали разработчики, для того чтобы подтвердить следующие гипотезы:
- То, что сделал разработчик, соответствует требованиям.
- Требования, которые он внес, не влияют на другие части продукта.
- Учтены все граничные условия.

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

Тестирование какое-то время измывалось над разработкой, находило старые баги, выдавая их за новые, они задавали тонны вопросов и прочих уточнений, и, спустя все стадии, начиная от отрицания, кончая принятием, все-таки поставили резолюцию «протестировано».

Шаг 11: Планирование релиза

Все очень зависит от процессов, которые приняты у разработки, иногда QA раскатывают релиз, иногда разработчики, где-то девопсы, но релиз должен быть подготовлен, какие-то действия должны быть выполнены, слиты ветки, запущены нужные пайплайны CI/CD.

Шаг 12: Релиз

Очень хорошо, если релиз осуществляется одной кнопкой через CI/CD. Допустим, эта кнопка есть, ответственный за это человек ее нажимает, происходит очень сложная магия, и в конечном итоге изменения доставляются на прод. Но! Никто ничего не видит!
Но в этом и план, как ранее планировалось, релиз выполнялся с экспериментом, а это значит, чтобы понять, будет ли эффект от внесенных изменений, нужно «включить» эти изменения на определенную долю пользователей.

Шаг 13: Проведение эксперимента

Перед началом эксперимента, буквально для его чистоты, нужно убедиться, что никаких событий поступать не начало, после чего, опять же, через CI/CD или свои собственные технические решения нужно начать показывать кнопку с новым цветом на 10% пользователям.
В условиях эксперимента были следующие требования: «В случае падения количества кликов более чем на 10% в течение первых 24 часов — сворачиваем эксперимент досрочно», потому если на следующие сутки это требование не будет выполнено, эксперимент будет свернут досрочно, флаги через CI/CD будут сняты, и пользователи не будут видеть эти изменения совсем. Но будем надеяться на хорошее.

Казалось бы, всё сделано: кнопка перекрашена, релиз прошёл успешно, эксперимент запущен. Но самое интересное только начинается. Ведь теперь нужно понять — а сработала ли наша гипотеза? Или мы просто потратили кучу времени и ресурсов на то, что в итоге окажется бесполезным?

Шаг 14: Анализ результатов эксперимента

Две недели прошли, метрики собраны, данные лежат в аналитике. Теперь PM, аналитики и, возможно, даже сам разработчик (если ему не лень) садятся разбирать цифры.

Что они ищут?

- Изменение конверсии — сколько пользователей из экспериментальной группы (тех, кто видел синюю кнопку) нажали на кнопку по сравнению с контрольной (теми, кто видел старую серую).
- Статистическую значимость — не случайны ли эти 5–10%? Возможно, просто в эти две недели люди просто хотели больше хлеба, чем обычно?
- Побочные эффекты — не упали ли другие метрики? Например, если синяя кнопка отвлекает от других важных элементов интерфейса.

Если всё хорошо и гипотеза подтвердилась (кликов действительно стало больше), то PM радостно потирает руки и готовится к финальному шагу.

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

Шаг 15: Вывод функционала из-под эксперимента

Допустим, всё прошло успешно. Тогда:

- Финальный релиз — через CI/CD или вручную изменения раскатываются на 100% пользователей.
- Удаление экспериментального кода — задача в беклог, чтобы свернуть эксперимент и удалить фича-флаги, ну и серую кнопку тоже.
- Документирование — где-то в недрах проектной документации появится запись: _«Синяя кнопка увеличила конверсию на X%»_. Теперь это знание можно использовать в будущем.

И вот она — победа! Кнопка синяя, кликов больше, бизнес доволен, PM получает премию (или нет), а разработчики… Ну, разработчики просто идут делать следующую задачу.

Эпилог

Просто поменять цвет кнопки. Что может быть проще. Но за этим стоит огромное количество процессов, людей и решений. И это ещё относительно простой пример!

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

Даже такая простая задача, как смена цвета кнопки, требует участия всей команды и занимает значительное время. Вот как выглядит процесс и распределение трудозатрат:  

Ключевые этапы и роли

1. Product Manager (PM) – 14–29 часов  
   - Анализ метрик, гипотеза, требования, согласования, контроль релиза и анализ результатов.  

2. Дизайнер – 4–11 часов  
   - Подбор цвета, правка макетов, дизайн-ревью.  

3. Фронтенд-разработчик – 5–11 часов  
   - Внесение изменений в код, добавление аналитики, доработки после ревью.  

4. QA (тестировщик) – 4–12 часов  
   - Проверка функционала, регрессионное тестирование, выявление багов.  

5. DevOps – 1.5–6 часов  
   - Настройка CI/CD, деплой на тестовое и продакшен-окружение.  

6. Аналитик – 4–8 часов  
   - Оценка результатов A/B-теста, проверка статистической значимости.  

7. Другие разработчики (ревью кода) – 1–3 часа  
   - Проверка кода перед мержем.  

Общие трудозатраты
- Минимально: ~35 часов (если всё идеально).  
- Реалистично: 50–70 часов (стандартный процесс с согласованиями).  
- Максимально: 80+ часов (если возникли доработки, баги или споры о цвете).  

Вывод
Изменение цвета кнопки – это не просто правка CSS, а сложный процесс с участием 5–7 специалистов. В среднем он занимает 1–2 недели работы всей команды. Чем крупнее продукт, тем больше времени уходит на согласования и тестирование.  

Так что в следующий раз, когда скажут «ну это же просто поменять цвет», можно смело отвечать: «Да, всего-то 50+ часов работы» 😉

Вывод нейронки мне понравился, он похож на правду, я сам красил кнопки и проходил через похожие процессы, потому считаю оценку времени весьма достоверной.

Вы легко можете прикинуть среднюю ЗП за средний час среднего IT сотрудника и получить сколько это стоит денег.

А теперь представьте, сколько займет времени переделать целиком какой-то экран или добавить большую фичу.