Сегодня цифровые продукты конкурируют за внимание и деньги пользователей и покупателей, которые избалованы качественными цифровыми сервисами и приложениями. Крупные IT-корпорации, такие как Apple, Google, Facebook, Amazon, «Яндекс» задают высокий уровень стандартов качества своих приложений, поэтому для того, чтобы продукт смог занять достойное место среди цифровых сервисов, команде нужно очень сильно постараться и вложить серьезные ресурсы в проект.
Еще одна особенность цифровых продуктов в том, что они, равно как и требования к ним, быстро меняются и устаревают. В связи с этим становятся востребованными такие модели работы, которые отвечают требованиям по скорости изменений, их внедрению и выведению на рынок.
При подготовке к созданию цифрового продукта необходимо учитывать как требования потенциальных пользователей, так и заказчика. С одной стороны, продукт должен решать существующую задачу, потребность или проблему пользователя или компании, если продукт направлен на b2b-аудиторию. С другой стороны, он должен решать реально существующие задачи целевой аудитории таким образом, чтобы экономика проекта (Unit-экономика, метрики вовлеченности и Lifetime Value и другие показатели) отражали целесообразность его создания.
Еще один важный фактор, который оказывает колоссальное влияние на успех продукта – выстроенная коммуникация между членами команды. От нее зависит скорость выхода проекта на рынок, его качество, рентабельность и удовлетворенность пользователей.
4 ошибки компаний, которые пытаются донести IT-команде видение по цифровому продукту
1. Размытые требования к продукту
Часто заказчики выступают в режиме визионеров и авторов идеи продукта. Как правило, он имеет размытое очертание из-за того, что заказчик представляет продукт в целом. Однако для того, чтобы перейти от идеи к реализации, нужно провести серьезную работу по декомпозиции проекта на конкретные действия, которые позволят оценить продукт с точки зрения финансовых, человеческих и временных ресурсов. Поэтому размытые требования – частая ошибка на раннем этапе работы над продуктом. Однако если видение декомпозируется на более четкие детали, оно может стать точкой роста проекта.
2. Отсутствие в команде аналитика или попытка создать продукт без него
Аналитик или бизнес-аналитик может участвовать в команде проекта либо со стороны заказчика, либо со стороны IT-команды. Зачастую аналитик переводит пожелания клиента в конкретные задачи разработчиков при создании продукта. Часто эту функцию могут выполнять продакт-менеджеры или менеджеры проектов. Типичная ошибка – попытка сформулировать видение продукта и оценивать его сразу с разработчиками. Если аналитика нет, то в проекте, скорее всего, будут проблемы.
3. Разработка продукта по требованиям руководителей, а не потребителей
Еще одна частая ошибка – ситуация, когда цифровой продукт создается по требованиям заказчика разработки, а не пользователей конечного продукта. Это распространенная ошибка, в том числе заказчиков и клиентов с большим количеством ресурсов и денег. Как правило, такие проекты оказываются невостребованными на рынке. В некоторых случаях уровень востребованности оказывается ниже ожидаемого с точки зрения экономики и финансовой модели проекта.
4. Жесткие временные и финансовые рамки проекта
Суть ошибки заключается в том, что менеджмент, заказчики или руководство пытаются поставить проект в жесткие рамки по срокам, бюджету и конфигурации участников команды разработки, не понимая реального объема работ. Обычно если цифровой продукт идет по такому сценарию, в 99% случаев он выходит за границы бюджета и сроков из-за того, что нужно выполнить гораздо больше работы, чем предполагалось изначально.
В том случае, если проект вписывается в бюджет и сроки, как правило, он оказывается недоработан, потому что при разработке проекта команда четко придерживалась обозначенных финансовых и временных ограничений.
Основные риски при разработке цифрового продукта
Основные риски связаны с выходом за обозначенные заказчиком рамки в виде сроков, бюджета, качества и требуемого функционала. Избежать этих рисков можно при выстроенной коммуникации с командой разработки и при выборе оптимальной модели работы. В том случае, если в проекте много неизвестных, касающихся цифрового продукта, команде следует выбрать итеративный подход, когда работа над продуктом разбивается на мини-проекты, которые выполняются в обозримые сроки. Обычно это 1-2 недели или месяц. Затем команда анализирует итоги одной итерации и продолжает работу.
Если команда хочет поставить проект в рамки по бюджету, срокам и качеству, необходимо написать всю документацию заранее на старте проекта, чтобы разработчикам был четко понятен объем функционала, выполнение которого они берут на себя. В таком случае можно придерживаться модели фиксированного бюджета.
Основные правила коммуникации с командой разработки
Основной принцип коммуникации – регулярность встреч, которые могут проводиться онлайн в Skype, Zoom, Google Meet и на других платформах. В начале работы необходимо подготовить документацию с требованиями к продукту, из которой сформировать так называемую базу знаний проекта. Для организации базы знаний можно использовать приложения, предоставляющие такие компоненты, как базы данных, доски канбан, календари и напоминания (например, Notion).
В отличие от классической практики, когда формировалось большое техническое задание в виде объемного документа, работу с требованиями по цифровым продуктам целесообразно выстраивать в Notion в виде таблицы, календаря или канбан-доски. В этом случае техническое задание разбивается на десятки, сотни или тысячи требований, каждое из которых оформляется в отдельной карточке. В результате получается система карточек, таблиц или канбан-досок, в которых документируются требования к продукту, прикрепляются различные данные, ссылки и комментарии разработчиков. Все это позволяет работать с большим объемом требований, в том числе с версионностью, когда требования к продукту меняются.
При подготовке документации к цифровому продукту можно использовать как классические подходы к разработке программного обеспечения, так и более современные, «продуктовые» подходы.
Классические подходы, как правило, используются на стадии проектирования и тестирования программного обеспечения. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выявление потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификацию (документирование требований) и проверку правильности.
К продуктовым подходам можно отнести такие подходы, как Jobs-to-be-done, Customer Journey Mapping, Lean Canvas.
Jobs to be Done — это подход, который помогает понять, как и почему люди принимают решение о первой покупке продукта. Этот подход позволяет прогнозировать, какой продукт будет востребован на рынке, а какой — нет.
Customer Journey Mapping – «карта пути клиента», в которой описаны точки контакта потребителя с компанией, его эмоции, действия, проблемы, а также чего не хватает для того, чтобы воспользоваться продуктом.
Lean Canvas – это таблица из девяти блоков, которая позволяет сжать большой план запуска нового продукта до одной страницы. Таблица состоит из следующих блоков:
- Целевая аудитория.
- Проблема и альтернативные решения.
- Уникальная ценность продукта.
- Как продукт решит проблемы?
- Способы продвижения.
- Как продукт принесет доход?
- На что тратим деньги?
- Ключевые показатели.
- Скрытое преимущество.
Если команда начинает действовать в продуктовом подходе, дальше она разбивает масштабные задачи на несколько более мелких, которые прописываются в таск-менеджере – приложении для фиксации задач. По каждой задаче можно установить время на ее выполнение. Впоследствии задачи из таск-менеджера можно использовать для подготовки отчета для заказчика по работе над проектом.
Грамотный современный подход к коммуникации в проекте между заказчиком или клиентом и командой разработки является основой успеха разработки современного цифрового продукта и вывода его на рынок.
Читайте также:
С другой стороны, он должен решать реально существующие задачи целевой аудитории таким образом, чтобы экономика проекта (Unit-экономика, метрики вовлеченности и Lifetime Value и другие показатели) отражали целесообразность его создания.
Если это не так, то это проблема продукта или метрик?
Крайне интересная статья! Хочу ещё подумать, некоторые вопросы мне не очень понятны или кажуться противоречивыми.
Например:
Разве бывает выход за рамки обозначенного закзачиком функционала? Кто-то по собственной инициативе работал? Можно ли пояснить это?
Автор абсолютно прав про хорошие коммуникации. Пожалуй это и и правда самое важное для разработчика. Но из статьи я снова не понял, как разработчик в вашей команде может коммуницировать с заказчиком. Да и надо и это? Но снова не настаиваю и солидарен с автором, что без аналитика не стоит браться за работу. ))) Но тогда кого Вы называете "разработчиком"? Поясните, пожалуйста.
Но если про "без аналитика" ясно(такое бывает, увы), то вот это я не понял совершенно:
Не могли бы пояснить, как на этапе тестирования можно готовить документацию? Что вы имели в виду. Это действительно интересно. Или это касается изменений в документации по проекту?
По фазе разработки требований. Не могли бы вы раскрыть детали, с кем проводится интервью? Руководство? Персонал? Почему вы выделяете ошибку: "3. Разработка продукта по требованиям руководителей, а не потребителей"?
Повторюсь, статья из серии редких на форуме. Очень интересно!
Наверное в статье идет речь об какойто гибкой метрдологии разработки ИТ. Классический подход требует написания ТЗ из сотен страниц. А тут вносятся изменения и проект как то переделывается на ходу. Примерно как плыть на корабле и одновременно перестраивать его корпус.
Автор, вольно или невольно, смешивает основные категории рисков в IT проектах, их причины, последствия и то, что менеджер проекта и риск-менеджер должны делать в ежедневном режиме в ходе проекта.
Как пример - почему, собственно, проект вышел из бюджета? В чём причина? Как менеджер проекта должен поступить?
В зависимости от этапности и плана проекта, согласованных ранее, есть график подготовки проектных документов. Варианты возможны.
Насколько можно видеть по содержанию статьи, автор где-то говорит о продукте, где-то - о проекте, где-то - о методологии. Иногда - о маркетинге.
Возможно, читатель должен сам найти, что именно ему интересно.
В 2009г я сидел без работы пару месяцев. И один знакомый мне человек попросил помочь ему в разработке ИТ системы. ИТ система представляла собой целевую социальную сеть для начинающих программистов, с навешанную на ней модель простого менеджмента из нескольких ролей:
- программист начального уровня 1 совсем сырой;
- программист начального уровня умеющий кодить кусок кода;
- программист способный прочитать ТЗ и что то накодить или собрать из нокоденных кусков;
- программист способный распилить задачи на подзадачи, проверить и принять результат, собрать в единое целое куски системы;
- администратор;
- руководитель работающий во внешнем конутре.
В рамках этого некомерческого проекта я описывал функции всех ролей, права доступа, какие кнопки видят в зависимости от статуса, какие задачи могут инициировать внутри системы.
Я участвовал в написании блока ТЗ на отображаемые менюшки в зависимсоти от роли в системе, разработке и увязке функционалов. Для меня было неожиданно насколько это объемная работа. Каждая нажимаемая кнопка меняет базы данных, перевешивает флаги, прекрепляет одно к другому и тд. Ежедневно генерились страницы, структура базы данных расширялась, количество флажков к каждому событию в системе росло. К концу работы примерно 40-50% времени уходило на то что бы найти и уточнить что писалось раньше и какие у нас были приняты решения. Весь объем просто не помещался в голове.
Систему тестили без меня, нагнали несколько десятков программеров и они в ней что то успешно кодили. Причем довольно жесткая система информационного обмена не позволяла сильно косячить и работать по ней могли совсем программисты-дрова.
Я уверен, что для реализации гибких методологий написания ИТ продуктов нужны какие то космические компетенции участников. А правильно отстроенная система менеджмента на основе детального ТЗ и декомпозирования работ позволяет работать с людьми-дровами и получать стабильный результат.
Ну это мое субъективное мнение на основе крайне небольшого опыта.
Алексей, я могу согласиться с этим. На мой взгляд, гибкие методики и создавались в расчёте на относительно высокий уровень программиста. На высокий уровень доверия к нему и ответственности. Но в гибких методиках присутствует свой набор недостатков. Я бы предложил такой вариант появления и развития гибких методик. Они появились во времена резкого роста возможностей программирования - клиент-сервер, 3-х уровневая система, веб-2.0. и т.д. Времена, когда заказчик не могу сразу понять эти возможности, да и разработчик не всегда видел конечный продукт - главное ввязаться в бой. И я много много раз встревал в такие работы - тут поправил, там подрезал, здесь кусочек. Кабы не клин, да мох, так бы и плотник сдох.
Сейчас это стало и модным, и привычным. Думаю, что через пару-тройку лет мы придём к новой, более жёсткой методике разработки. Слишком много систем, сервисов, огромные базы, кроссплатформенность. Вот сейчас на нашем текущем проекте очень нелгко бывает, когда меняется часть команды. Описать и задокументировать все тонкости неимоверно трудно. И незнание этих деталей, которых очень много, увеличивает сроки разработки довольно существенно. Опять тестируем, опять ошибаемся.
Да, это так, график есть, но почему автор привязал это действие к этапу тестирования? Такое не только возможно, но и, Вы правы, часто бывает, но как и на любом другом этапе. Зачем нужно выделять этап тестироваия для подготовки документации? Для этого есть очень устойчивые практики. Тот же ГОСТ для всех систем прописывает это.
Похоже, что автор уже поправил текст? Я не знаю, что имеется в виду под "классическими подходами" во множественном числе.
Я бы вернулся к плану проекта и посмотрел бы именно там - что в какой момент готовится и согласовывается. Если при этом используется какой-либо национальный или международный стандарт - отлично.
Но важно понимать, является ли продукт 100% заказным или коробочным, и как именно он тестируется - это на момент начала тестирования уже известно и согласовано с заказчиком.
Кажется, да, поправил. Но я снова согласен с Вами больше, чем с автором. Если есть заказчик, то очень глупо и очень сложно отходить от его требований. А в случае каких-то юридических коллизий доказать свою правоту без опоры на ТЗ практически невозможно. И тестирование - частично является делом внутренним для исполнителя, но и игнорировать согласованную программу и методику испытаний просто невозможно. Я не могу понять у уважаемого автора логику в разрезе обследование-тз-пояснительная записка, план разработки- тестирование-приёмка (ПМИ). По-другому-то почти не бывает. И это нисколько не мешает внедрять любые методики экстремального програмирования, как инструмента для программиста.
В коробочных продуктах да, бывает, деньги кончились, получай то, что есть. Но там и заказчик очень условный.
Если одним словом - да.
Заказчик всегда есть - внешний (в случае заказной системы) или внутренний (коробочный продукт). У этого заказчика всегда есть требования, которые включают функционал, сроки и бюджет, помимо прочих. Всегда есть и риски - с точностью до проекта.
Заказчик, естественно, имеет право получить то, что он хотел - и под чем все подписались. Иначе разработка просто бы не началась.
Это азы, который знает каждый менеджер проекта в IT.
А зачем бы это делать? Кому это может понадобиться?
Еще раз - да. В комиссию по приемке входят представитель заказчика, которому доступны результаты тестирования.
Совершенно верно. Какие угодно методики программирования находятся одним или более уровнями ниже, чем методология проекта или подходы к сбору требований для будущего продукта. Вспомним, для чего гибкие методологии появились, кто их авторы, и какие известные проблемы пытались с их помощью решить.
Будем надеяться, что автор даст необходимые комментарии.
Для коробочных продуктов требования собираются и компонуются в пакеты принципиально иначе, и там большая интеллектуальная нагрузка на маркетинг и финансовое планирование, иногда - с участием венчурного (или другого внешнего) капитала.
В проектах разработки, интеграции и внедрения крупных систем ПО бюджет обсуждается на самых ранних стадиях вместе с другими ключевыми требованиями заказчика, а контроль отклонений и анализ причин - основная головная боль менеджера проекта. Тут тоже ничего нового, на мой взгляд, эта схема в своих основах не меняется десятилетиями.
А записывать базовые принципи видимо желания не хватало. Наглядный сборник антипаттернов, когда разработкой занимаются не программисты, а глупые менеджеры, слепо считаюшие что с их колокольни виднее больше всего. Зато как говорится, получили бесценный жизненный опыт.
Вам нужно было тесты писать, раз уж выбрали разработку через тестирование. А с общим функционалом определятся в виде дорожной карты: альфа, бета, гамма, дельта и далее версиями, вплоть до выхода версии 1.0, в которой основной костяк работы сделан, общий функционал определен, а в дальнейшем вносятся мелкие и средние, но заметные правки без перекройки "основы основ" всей системы.
Как это работает? Я смотрю здоровой абстракцией и на таком уровне специфики реализации не имеют значения. Очень хорошо это изложено в книге Тони Бьюзена "Супермышление".