Мы продолжаем рассказывать историю маленькой кнопки “Дублировать”, которая позволяет делать копии проектов в Darlean. В предыдущей статье мы описали путь от запроса пользователя до гипотезы и ее тестирования. Этот материал посвящен бизнес и системному анализу, дизайну и разработке.
Функциональные и нефункциональные требования
Наш следующий герой — бизнес-аналитик. Он нам предоставит, в числе прочего, функциональные требования (как именно должно происходить дублирование проекта), нефункциональные требования (как быстро должен дублироваться проект), модель вариантов использования (графическую репрезентацию работы кнопки дублирования), а также анализ затрат и выгод (во сколько обойдется разработка функции и какие выгоды она принесет) и влияния на новой функции на систему в целом.
“На этапе бизнес-анализа у нас также работает отдельный отдел CX-review (исследование клиентского опыта). Еще нет ни одной строчки кода, но команда экспертов может дать обратную связь о том, насколько хорошо новая функция вписывается в общий клиентский путь.
Кнопка “Дублировать” может оказаться непонятной для пользователя. Или ее нажмут слишком много раз и потом удалят оригинал с уже внесенными изменениями вместо копии? Пользователю это не понравится, поэтому наши специалисты заранее предусматривают все случаи, когда клиент пытается “сломать систему» и дают свои рекомендации.
Как-то клиентам не понравилось, что просроченные задачи в программе выделяются красным цветом. Мы предложили отключать красный цвет. Но сотрудники CX-review напомнили, что в этом как раз и есть ценность нашего продукта: предупреждать клиента, что нельзя срывать сроки выполнения задач”, — делится Санжар Кадыров.
Почему делать кнопку — дорого
Итак, давайте сделаем небольшое резюме на середине нашего пути. Мы уже задействовали продакт-менеджера, бизнес-аналитика, техлида и UX-дизайнера. Каждый из них получает зарплату. Но все это не идет ни в какое сравнение с зарплатами разработчиков, QA-инженеров, DevOps, специалистов техподдержки, которым предстоит создавать и сопровождать нашу кнопку.
Поэтому наш следующий шаг — утвердить наши идеи со стейкхолдерами — ТОП-менеджментом компании. К ним мы приходим не просто с идеей, а готовыми инсайтами, подтвержденными результатами исследований, а также ответами на вопрос: «Как все это сделать?».
Стоит заранее подчеркнуть, что все цифры и расчеты в статье являются иллюстративными и используются для лучшего понимания материала.
Таким образом, итоговая презентация обычно представляет собой анализ в виде:
“Если мы поставим кнопку, реализация которой обойдется в 250 000 тенге, мы вернем затраты за 12,5 месяцев за счет снижения customer churn (оттока клиентов) на 5% и увеличения NPS, что приведет к дополнительному доходу в 200 000 тенге в год”.
Видя такие данные, стейкхолдер может принять обоснованное решение и одобрить разработку.
А теперь можно писать код?
Еще нет. Разработчик не может напрямую работать с PRD. Ему нужно техническое задание, созданное на специальном языке. Таком, как UML. Скажем, яичницу вы можете приготовить не полагаясь на рецепт. Бефстроганов уже потребует наличия под рукой списка ингредиентов и порядка действий. План здорового питания, помимо названий блюд, содержит такие термины, как калории и дефицит.
Приготовление блюд на уровне мишленовского ресторана требует не только рецепта, но и точного описания техники, времени приготовления, температуры для каждой стадии и списка особых навыков шеф-повара. А теперь представьте, что мы усложнили аналогию еще на пару уровней и тогда мы можем приблизиться к UML-диаграммам в программировании, где каждый шаг детализирован и требуется понимание сложных взаимодействий и зависимостей.
К работе приступает системный аналитик, который создаст Software requirements document для разработчиков. К слову, на графике сверху мы тоже все упростили. Настоящая диаграмма содержит конкретные функции, которые должны быть реализованы в коде.
А вот теперь, да, уже осталось достаточно близко до начала разработки. Команда продакт-менеджеров вместе с разработчиками и системным-аналитиком принимает решение в какой спринт попадет наша кнопка. И, когда наступает выбранный спринт, разработчики создают код. Об этом мы расскажем в отдельном материале.
Код написали, можно нажимать?
В зависимости от сложности разработки нашей кнопки и множества других факторов, может уйти от одной до двух недель. После этого наступает этап quality assurance, когда тестировщики проверяют итоговый результат.
“Тестировщики пытаются “поломать систему”, так они выявляют баги, которые устраняют разработчики. Но есть еще один этап — User acceptance testing. Это когда после тестировщиков UX-дизайнеры тестируют функционал с позиции пользователей. Они дают комментарии: что, где и как работает, корректно или некорректно. По этим комментариям мы снова просим разработчиков исправить или отправляем на релиз”, — рассказывает Санжар Кадыров.
Так готово или еще нет?
Еще нет, ведь DevOps инженерам DAR предстоит провести сборку и релиз готового функционала. Они отвечают за настройку инфраструктуры, развертывание обновлений и контроль стабильности системы после внедрения новых функций. Только после этого кнопка «Дублировать проект» станет доступной всем пользователям системы Darlean.
И теперь довольному клиенту можно проводить больше тоев или сосредоточиться на действительно творческой работе, не отвлекаясь на рутинные задачи и повторяющиеся процессы. Рад и клиент, получивший новую фичу, и продакт, успешно выполнивший работу, и разработчик, которому качественно организовали рабочий процесс, и стейкхолдеры, получившие новую версию улучшенного продукта.
Но даже после релиза работа не заканчивается. Команда поддержки и разработчики продолжают мониторинг, собирают отзывы пользователей и вносят необходимые улучшения, чтобы программа в целом работала без сбоев и приносила максимальную пользу.
