Всем привет! Сразу заметим: в этой статье не будет описано никаких принципиально новых подходов и решений. Все приёмы, так или иначе, известны опытным ИТ-менеджерам. Мы хотим поделиться нашим опытом и рассказать, какие составляющие проекта мы сочли для себя обязательными и почему.
В нашей компании принято проводить ретроспективы — встречи по итогам завершенного проекта для анализа и обсуждения процесса создания продукта. На встрече собирается вся проектная команда, и мы обсуждаем успехи и провалы конкретного проекта, рассматриваем возможности применения удачных решений в других проектах и процессах и придумываем решения для избежания неудач, снижения рисков и затрат в будущих аналогичных проектах. На одной из последних таких встреч мы выделили несколько практик и подходов, которые должны помочь нам справиться с типичными проблемами проектов по разработке мобильных приложений.
Мы поняли, что для нас часто не подходит ТЗ как формат проектирования и фиксирования требований. Создание одного универсального документа, который должен покрыть все стороны требований к продукту, требует совместной работы большого количества разных людей как с нашей стороны, так и со стороны заказчика, и занимает очень много времени. При этом с итоговым весьма объемным документом разработчику работать будет сложно и неудобно (слишком много лишней для разработчика «воды», сложно искать ответы на конкретные вопросы), а идеальным, скорее всего, документ всё равно не будет: не все детали будут описаны.
Если говорить о мобильных проектах, которые по объему работ обычно укладываются в 3-4 месяца, то писать для них единое большое и подробное ТЗ — не рационально, так как на это уйдёт примерно столько же времени, сколько работа над самим проектом. С другой стороны, работать без фиксированных требований невозможно, и приходится искать компромисс.
Мы решили, что гораздо быстрее, эффективнее и полезнее для разработки будет согласовывать различные аспекты требований в виде отдельных документов (которые, при необходимости, можно будет собрать в единое ТЗ). Пакет согласованных документов перед началом разработки должен включать следующее:
В первую очередь, требования должны описывать значение продукта для пользователя (в форме user stories, user cases) и модель данных с точки зрения пользователя и бизнеса (сущности и связи между ними). Для построения модели данных необходимо провести анализ серверного решения, если оно уже есть (например, вы готовите мобильное приложения для системы, имеющей сайт).
Имея готовый vision и модель данных, можно приступать к проработке дизайна приложения. Поскольку проработка хорошего дизайна интерфейса всегда проходит в несколько этапов, сначала необходимо сделать скетчи экранов (= мокапы, прототипы), так как их можно сделать гораздо быстрее, чем полноценный дизайн, и стоят они дешевле. Screen flow можно строить одновременно с проработкой скетчей: например, используя Balsamiq, но в большом приложении он получается слишком большим, даже если разбить на отдельные диаграммы по разделам приложения, так что для дальнейшей работы над дизайном лучше иметь скетчи отдельно.
В нашей компании принято проводить ретроспективы — встречи по итогам завершенного проекта для анализа и обсуждения процесса создания продукта. На встрече собирается вся проектная команда, и мы обсуждаем успехи и провалы конкретного проекта, рассматриваем возможности применения удачных решений в других проектах и процессах и придумываем решения для избежания неудач, снижения рисков и затрат в будущих аналогичных проектах. На одной из последних таких встреч мы выделили несколько практик и подходов, которые должны помочь нам справиться с типичными проблемами проектов по разработке мобильных приложений.
Проработка и согласование требований
Проблема
Мы поняли, что для нас часто не подходит ТЗ как формат проектирования и фиксирования требований. Создание одного универсального документа, который должен покрыть все стороны требований к продукту, требует совместной работы большого количества разных людей как с нашей стороны, так и со стороны заказчика, и занимает очень много времени. При этом с итоговым весьма объемным документом разработчику работать будет сложно и неудобно (слишком много лишней для разработчика «воды», сложно искать ответы на конкретные вопросы), а идеальным, скорее всего, документ всё равно не будет: не все детали будут описаны.
Если говорить о мобильных проектах, которые по объему работ обычно укладываются в 3-4 месяца, то писать для них единое большое и подробное ТЗ — не рационально, так как на это уйдёт примерно столько же времени, сколько работа над самим проектом. С другой стороны, работать без фиксированных требований невозможно, и приходится искать компромисс.
Решение
Мы решили, что гораздо быстрее, эффективнее и полезнее для разработки будет согласовывать различные аспекты требований в виде отдельных документов (которые, при необходимости, можно будет собрать в единое ТЗ). Пакет согласованных документов перед началом разработки должен включать следующее:
- Vision — описание общего представления о конечном продукте в терминах бизнес-отрасли заказчика, отражающее основные задачи, решение которых реализуется посредством приложения
- Модель данных — логическое определение объектов, которыми оперирует приложение, и связей между ними
- Скетчи — графические наброски экранов, отображающие расположение элементов интерфейса
- Screen flow — диаграмма переходов между экранами приложения.
В первую очередь, требования должны описывать значение продукта для пользователя (в форме user stories, user cases) и модель данных с точки зрения пользователя и бизнеса (сущности и связи между ними). Для построения модели данных необходимо провести анализ серверного решения, если оно уже есть (например, вы готовите мобильное приложения для системы, имеющей сайт).
Имея готовый vision и модель данных, можно приступать к проработке дизайна приложения. Поскольку проработка хорошего дизайна интерфейса всегда проходит в несколько этапов, сначала необходимо сделать скетчи экранов (= мокапы, прототипы), так как их можно сделать гораздо быстрее, чем полноценный дизайн, и стоят они дешевле. Screen flow можно строить одновременно с проработкой скетчей: например, используя Balsamiq, но в большом приложении он получается слишком большим, даже если разбить на отдельные диаграммы по разделам приложения, так что для дальнейшей работы над дизайном лучше иметь скетчи отдельно.