Техническое задание — это не то же самое, что и постановка на реализацию. Техническое задание — это результат обработки исходных (организационных, бизнес-) требований, их уточнения и перевода на системный/технический уровень.
Постановка задачи на реализацию — это описание способа реализации исходных требований, технического задания, архитектурного решения, изложение требований к устройству спроектированного решения (на этом этапе исходные требования уже обработаны).
Место постановки на реализацию
в процессе создания IT-продукта
Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.
Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации готового ИТ-решения
Техническое задание разрабатывается на этапах Инициации и Определения метода решения бизнес-задачи. Здесь мы говорим про выявление проблемы, сбор исходных требований, формирование какого-то запроса на решение этой проблемы.
Введение в бизнес-аналитику
Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.
Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.
Зачем нужна постановка на реализацию?
- Определить границы, защититься от их изменений
- Зафиксировать критерии успешного результата
Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи
«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»
Кто пишет постановку на реализацию?
- Менеджер проекта / менеджер продукта
- Аналитик
- Тимлид разработки, например, когда аналитика на проекте нет. Тогда менеджер верхнеуровнево описывает необходимые функции, а команда разработки сама пишет для себя постановки и задачи.
Кому нужна постановка на реализацию?
- Менеджеру проекта (или продукта) . Для менеджера постановка на реализацию выполняет защитную функцию: он понимает, что часть функциональности описана, все понимают что делать, границы реализации защищены.
- Аналитику. Сама по себе постановка – это способ документирования, к ней всегда можно вернуться, чтобы посмотреть как функция была реализована. Постановка – это хороший способ отслеживать свой результат.
- Команде. Именно в постановке есть описание того, что нужно делать. В постановке описывается некий облик решения, который позволяет команде разработать продукт не только в соответствии с требованиями, но и в соответствии с теми решениям, которые были приняты на верхнем уровне.
- Заказчику. Так, например, технический заказчик может активно участвовать в технических решениях. Бизнес-заказчик может согласовывать отдельные разделы постановки – ниже мы поговорим о том, что может быть ему интересно. Участие заказчика позволяет определить перечень требований, которые нужно реализовать в рамках этой постановки. Оно необходимо, чтобы понимать, что будет на выходе после реализации.
Основные разделы постановки на реализацию
Как системному аналитику ставить задачи на разработку
- Контекст задачи
- Ключевые источники информации
- Заинтересованные стороны
- Критерии приемки результата
- Нефункциональные требования и ограничения
- Описание решения
Разделы постановки на реализацию
Рассмотрим эти разделы на примере:
Предположим, компания занимается продажей товаров через интернет (e-commerce). В целях привлечения новых клиентов и удержания существующих, компании требуется предоставить клиентам возможность получать дополнительную информацию при заказе товара.
Необходимо разработать сервис по расчету и предоставлению клиенту плановых сроков доставки заказа. Считаем, что до этого мы никаких сроков потенциальному клиенту не озвучивали.
Давайте пройдемся по разделам постановки и попробуем понять, какую информацию стоит в них отражать.
Раздел 1. Контекст задачи
Контекст задачи – это краткая информация о ситуации и проблемах, из-за которых возникла стоящая перед вами задача по автоматизации. Данная часть постановки – это, по сути, срез бизнес-требований, которые были собраны бизнес-аналитиком на предыдущем этапе.
- сформировать «мостик» между заказчиком и исполнителем,
- минимизировать риск того, что решение будет оторвано от реалий будущего использования,
- разработчикам придумать лучшее решение,
- тестировщики могут разработать максимально приближенные к реальному использованию тест-кейсы,
- команде погрузиться в предметную область и прокачать экспертизу в предметной области,
- аналитику в трассировке требований на проблемы бизнеса.
- Описание функций бизнес-языком
- Описание бизнес-процесса
- Бизнес-требования
- Перечень проблем бизнеса
Кейс: возможность предоставления клиенту плановых сроков доставки заказа
Компания не имеет собственных средств доставки грузов.
Базовые сроки доставки предоставляются сервисами компаний-перевозчиков, далее в них учитываются сроки подготовки заказа и риски, которые может учесть компания.
Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.
Для чего этот бизнес-контекст разработчикам?
Ведь решение уже есть, для чего давать исходные данные в виде контекста? Дело в том, что в некоторых случаях описание решения может быть менее конкретным. Риски по формированию детального решения можно переложить на команду. Если члены команды являются экспертами в предметной области, понимают как пользователь и бизнес будут этими функциями пользоваться, то они сделают более качественное решение.
Пример из практики:
Делали систему для компании, где работали операторы 24 часа в сутки. Специфика работы компании заключалась в том, что ночью было принято работать без света. Если не знать этой специфики, можно было бы сделать какой-то вырвиглазный интерфейс, в котором ночью работать было бы невозможно. А зная и понимая это, проектировщик интерфейсов разработал такие интерфейсы, которые позволяют работать одинаково удобно и днём, и ночью.
- Мы можем делать постановку на разном уровне детализации.
- Чем выше уровень детализации постановки, тем больше места для маневра команды разработки. Это позволяет выбрать лучший вариант для решения поставленной бизнесом задачи.
Раздел 2. Ключевые источники информации
В этом разделе постановки речь идёт о едином перечне источников информации, описание которых снижает риск использования недостоверной информации.
Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.
- Описание внешнего или ранее реализованного API (например, API компании-перевозчика). Разработчик не должен сам искать в интернете какую-то версию, т.к. она может оказаться не последней и не согласована с архитектором.
- HLD (high-level design, описание архитектуры)
- Стандарты заказчика, если речь идет про передачу листинг кода, а также когда есть свои определенные стандарты его оформления
- Ссылка на памятку по чтению постановки. В некоторых случаях формат постановки может быть достаточно объемным и в нем могут использоваться артефакты, которые не всегда будут понятны человеку со стороны (или даже разработчику команды, который может воспринять постановку неправильно). Поэтому ссылка, например, на соглашение о моделировании вполне может быть источником информации.
Раздел 3. Заинтересованные стороны
Заинтересованные стороны (далее ЗС) — это перечень людей, которые будут влиять на принятие решений и от которых зависит успех реализации.
- Определение принадлежности реализуемых в рамках постановки на реализацию требований к ЗС.
- Позволяет проверить, что все необходимые ЗС выявлены и привлечены.
- Дает понимание о том: кто принимает решения, с кем можно коммуницировать при реализации, кто будет в ходе испытаний принимать решение согласно критериям приемки.
- Можно использовать этот перечень при согласовании и демо.
Роли заинтересованных сторон
Разница между проектными ролями и бизнес-ролями ЗС
Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.
Как ставить задачу бизнес аналитику
Продуктовая аналитика — жизненно необходимый инструмент для осознанного развития бизнеса.
Она позволяет отслеживать поведение пользователей, удовлетворённость продуктом, реакцию на новые фичи, формировать портреты аудитории и многое-многое другое.
Но, если допустить ошибки при настройке аналитики, легко упустить пользу или вообще сделать неверные выводы.
В статье для «Секрет фирмы» рассказываем, как правильно настраивать продуктовые метрики, собрать только нужную информацию и грамотно интерпретировать полученные данные.
Анна Куликова
Продуктовый аналитик 65apps
Анализируй это: краткое руководство по внедрению продуктовой аналитики
Компании собирают и анализируют данные, чтобы понять, как IT-продукт (например, мобильное приложение) влияет на бизнес. Аналитика позволяет отслеживать поведение пользователей, удовлетворенность продуктом, реакцию на новые фичи и многое другое. От этого зависит стратегия развития продукта — мы понимаем, что необходимо изменить, чтобы удержать пользователя, повысить его лояльность или достичь других заявленных целей. Так реализуется осознанный подход к изменениям, основанный на данных, а не интуиции.
Но, если допустить ошибки при настройке аналитики, сборе информации или ее интерпретации, легко упустить пользу. Следует держать в голове несколько важных моментов.
Определить необходимые метрики на старте
Обычно компании отслеживают базовые данные о работе продукта и поведении пользователя: количество пользователей (DAU, WAU, MAU), длительность сессий, популярные разделы, кнопки, сценарии, источники трафика, средний чек и тд. Минимальная аналитика помогает «держать руку на пульсе», но ее недостаточно для более глубокого анализа продукта.
Итоговый набор метрик зависит, во-первых, от предметной области, к которой относится продукт (ритейл, контент, финтех и др.). Во-вторых, от текущих бизнес-целей (увеличить прибыль, привлечь новых клиентов и др). Если игнорировать эти условия, есть риск собрать много лишних данных или вообще не получить нужную информацию. В любом случае, это зря потраченные время и силы, а для бизнеса с ограниченными ресурсами это может стать настоящей проблемой.
Продуктовая аналитика помогает на более глубоком уровне проследить связь бизнеса и приложения, отталкиваться не от пользовательских сценариев, а от решаемых задач. Если нужно оценить эффективность части продукта и принять решения о развитии или закрытии направления — определяем, какие метрики нужны и отслеживаем именно их.
Кейс из жизни
После того, как в приложении для ритейла внедрили новый раздел с акциями и спецпредложениями, стояла задача — проанализировать эффективность обновления. В документации по аналитике были прописаны десятки метрик — отслеживалось много событий, собирался большой объем данных. Когда понадобилось проанализировать эффективность нового раздела, оказалось, что данных не хватает.
Дело в том, что изначально вовлеченность пользователей в новом разделе считали не разделяя их на группы — зарегистрированных и незарегистрированных пользователей. А для аналитики это — ключевой показатель. Ошибка заключалась в том, что был описан весь путь пользователя, но не предусмотрены важные для решения задачи нюансы. Когда внедряется продуктовая аналитика, снижается вероятность, что того, что нужных для анализа данных не будет хватать. Мы начинаем думать не только пользовательским сценарием, но текущими задачами — перед стартом всех работ.
Смотреть вглубь
Задача продуктовой аналитики заключается не только в сборе данных и анализе, но и в интерпретации. Только так можно найти ответы на вопросы и понять, что повлияло на результат. Не всегда причины изменений тех или иных показателей очевидны, иногда требуется более глубокий анализ причин и следствий.
Кейс из жизни
Однажды мы наблюдали резкое снижение кликабельности одного тематического блока на главном экране приложения — это произошло после небольшого редизайна этого экрана. На первый взгляд, это было негативное последствие нововведения. Но в процессе более тщательного анализа фичи выяснилось, что остальные показатели внутри этого блока, наоборот, значительно выросли (из-за притока релевантной аудитории). То есть, снижение одной метрики не обязательно говорит об ухудшении; возможно, это говорит об улучшении — за счет роста других.
Если аудитория приложения резко выросла, необходимо определить, что на это повлияло, и исходя из этого выстраивать план дальнейших действий. Если рост вызван изменениями в приложении — надо продолжать работать в этом направлении. Но это может быть связано совсем с другим.
Известен кейс, когда аудитория в приложении резко выросла из-за действий конкурента — запуск масштабной рекламной кампании повысил интерес ко всем приложениям нового формата. Без аналитики и поиска причин, мы могли бы подумать, что рост аудитории связан с обновлением приложения или внедрением новой фичи.
Аналитика нужна, чтобы понять, почему произошло то или иное событие. Для такой исследовательской работы нужны соответствующие компетенции и инструменты, умение «видеть со стороны», чтобы докопаться до истины и не совершать ошибок.
Принимать решения продуктовой командой
Продуктовый аналитик — партнер продакт-менеджера по принятию продуктовых решений. Он помогает формулировать гипотезы, опираясь не только на опыт и видение продакт-менеджера, но на данные, в первую очередь. Аналитик помогает проверять продуктовые гипотезы на основе существующих закономерностей, даже до их внедрения.
Например, если нужно решить, как повысить монетизацию в приложении, поможет моделирование. С помощью имеющихся данных можно спрогнозировать результат — получится ли больше зарабатывать, если отключить рекламу и оставим только платную подписку; или наоборот, оставить только рекламу.
Кейс из жизни
Приложение с развлекательным текстовым и аудио-контентом в приоритет ставило задачу по захвату рынка и расширению аудитории. Поэтому сфокусировались на метриках прироста аудитории — количестве установок, количестве новых пользователей, DAU/MAU.
Позже выяснилось, что пользователи не задерживаются в приложении надолго и, чтобы сохранять текущие темпы прироста аудитории, надо работать над метрикой удержания (Retention, Churn Rate). В этой ситуации на помощь приходит продуктовая аналитика — мы изучали, что же пользователи делают в приложении, какой контент им больше нравится. Так сформировали ряд продуктовых гипотез, направленных на удержание: начиная от ранжирования контента в каталоге и рассылкой уведомлений определенным категориям пользователей, заканчивая персональными рекомендациями и новыми форматами контента. Часть из них сработала.
Чек-лист: как внедрить аналитику
и не упустить пользу
Выбрать систему для отправки событий о действиях пользователя в мобильном приложении
Наиболее распространенные сервисы: AppMetrica от Yandex, Firebase от Google, Amplitude и др. Выбор сервиса зависит от бюджета, объема аудитории и личных предпочтений.
Для нашего примера возьмем AppMetrica от Yandex – этот сервис бесплатный и достаточно легко настраивается.
Определить базовые метрики, которые необходимо отслеживать для продукта
Здесь хорошей практикой является проведение серии мозговых штурмов с участием всех заинтересованных членов команды. Полезно будет привлечь к этому процессу не только аналитиков и представителей менеджмента, но и других сотрудников (например, разработчиков, специалистов по поддержке клиентов, дизайнеров и др.), поскольку у каждого из них будет свой взгляд на метрики.
Если говорить про базовые метрики ритейлеров, скорее всего, в этом списке окажутся MAU/WAU/DAU (месячная/недельная/дневная активная аудитория), количество новых установок, новых зарегистрированных пользователей, ARPU/ARPPU (средний доход на пользователя и на платящего пользователя), конверсия в регистрацию и оформление заказа, средний чек, частота совершения покупок и др.
Спроектировать карту событий
Принять решение о степени детализации такой карты – то есть о том, насколько подробно будет отслеживаться каждое действие пользователя — необходимо исходя из выбранных метрик. На этом этапе аналитик расписывает, какие действия пользователя и при каких условиях нужно отслеживать. С помощью этой информации будут рассчитываться метрики.
После этого желательно расписать формулы для расчета метрик. Если с активными пользователями и новыми установками все понятно — их по умолчанию отслеживает практически любая система продуктовой аналитики, то для более детальных метрик все не так просто. Например, чтобы посчитать конверсию в успешное оформление заказа (отношение всех пользователей, совершивших заказ ко всем активным пользователям приложения), как минимум, нужно отслеживать факт каждой успешной оплаты заказа в привязке к конкретному пользователю.
Кроме того, сразу стоит учитывать, что, если конверсия окажется ниже, чем мы рассчитывали, нужно будет обязательно выяснить причины. А это значит, необходимо дополнительно отслеживать каждый шаг пользователя на этапе оформления заказа (добавление товара в корзину, выбор способа доставки, оплаты, ввод персональных данных и т.д.), чтобы понять, в какой именно момент он от нас ушел – это даст основания для формирования продуктовых гипотез.
Поставить задачу на разработку: настроить интеграцию с выбранной системой аналитики и реализовать отправку событий из разработанной карты.
На этом этапе понадобятся ресурсы не только продуктовых аналитиков, но и разработчиков, которым необходимо будет изучить документацию по внедрению выбранного сервиса в мобильное приложение, а также реализовать отправку событий в соответствии с требованиями от аналитика. Хорошей практикой является формирование правил именования событий для конкретного продукта. Например, название события может состоять из нескольких ключевых слов, разделенных нижним подчеркиванием:
— название экрана, на котором происходит событие (назовем экран оформления заказа order);
— название элемента, с которым взаимодействует пользователь (например, кнопка «Оформить заказ» — placeOrderButton);
— название отслеживаемого действия пользователя (например, нажатие на кнопку — tap).
Тогда событие нажатия на кнопку оформления заказа будет именоваться order_placeOrderButton_tap. Требования к отправляемым событиям, описываемые в задаче на разработку, должны содержать имена событий и описание действий пользователя и технических условий, соответствующих бизнес-логике приложения, при которых это событие должно отправляться в аналитику.
Разработать дашборды по выбранным метрикам
После того, как события реализованы и начали отправляться в выбранный сервис аналитики, можно приступать к разработке дашбордов. Обычно для разработки дашбордов применяются различные BI-системы, для некоторых задач бывает достаточно выгрузок в Excel или отчетов в Google-таблицах. Отметим, что выбранная нами AppMetrica от Yandex интегрируется с BI-системой Yandex DataLens, которая позволяет аналитику разрабатывать дашборды через интуитивно понятный интерфейс.
При появлении новых фич в продукте повторить действия из пунктов 2-5.
Скорее всего, потребуется пересмотреть набор метрик, доработать карту событий и реализовать события для новой фичи. А впоследствии — адаптировать дашборды.
Когда продукт станет более зрелым, а аудитория начнет измеряться десятками и сотнями тысяч новых пользователей в день, придется задуматься о более сложных системах работы с данными, настройке и администрировании собственного хранилища, пересмотре инструментария.
Источник: blog.65apps.com