Рабочий процесс Smartum

 
Здесь в Smartum мы занимаемся запуском стартапов уже достаточно долгое время. Около 5 лет (или более 50 проектов) : CRM-системы, приложения для дистанционного обучения, VPN-приложения, социальные сети и так далее.

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

Итак, сегодня мы бы хотели поговорить об этом рабочем процессе. Быть может, вы также захотите применить его у себя в бизнесе (или, быть может, заказать у нас приложение… Кто знает?). Приступим!

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

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

И конечно же клиент хочет знать точную стоимость продукта, сроки запуска, и при этом иметь определенные гарантии после него. Для наиболее быстрого и безопасного запуска продукта мы используем принципы методологии Lean.

Основная идея заключается в создании MVP (минимально жизнеспособного продукта). Это позволяет и нам и клиенту определить по-настоящему важные функции, после чего как можно быстрее запустить проект в разработку.

Несмотря на то, что этот рабочий процесс больше подходит для мобильных приложений (где цикл разработки обычно короче), его вполне можно применять и для web-проектов.

• Стандартный срок разработки для большинства проектов — 3 месяца. Конечно, сюда не входят большие проекты для банков, или для авиаперевозчиков 🙂 , так как достаточно сложно планировать такие большие проекты без отдельной команды бизнес-аналитиков.
• Мы разбиваем проект на этапы. Каждый этап длится 3 месяца. Первый этап — MVP, в то время как второй этап нацелен на оптимизацию проекта под большие нагрузки, улучшение кода, добавление новых функций.
• Мы предоставляем новую версию приложения заказчику каждые 2 недели (итерация). Это позволяет клиенту контролировать процесс разработки и предоставлять нам своевременную обратную связь.

Теперь поговорим в деталях:

1. Документация, необходимая для начала работы
2. Цели для каждой итерации первого этапа
3. Гарантия
4. Цели на второй этап

До начала разработки

От клиента требуется:

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

Техническая документация:

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

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

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

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

Проектная документация

После того как клиент и команда определились с требованиями, мы начинаем  готовить план разработки (roadmap)  который состоит из:

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

 
Планирование задач на каждую итерацию (iteration breakdown). Составляется командой совместно с клиентом для того, чтобы обе стороны понимали, что должно быть выполнено в пределах данной итерации. По ее завершению, клиент должен подтвердить выполненные работы. Оплата выполненных работ должна быть произведена в течение 5 дней после завершения итерации.

 
Распределение нагрузки/формирование команды (resource allocation/team setup). Перед началом процесса разработки нужно определить, какие члены команды будут подключаться на каждом отдельном этапе.

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

Итерации

Первый этап разработки длится 3 месяца, и состоит из 6 итераций:
 

1. Верстка статичных экранов, настройка сервера
2. Основной функционал приложения
3. Отладка ключевой функциональности. Разработка оставшихся функции приложения согласно приоритетам.
4. Завершение разработки всех функций. После 4-й итерации разработка нового функционала прекращается.
5. Стабилизация приложения, исправление найденных багов. Реализация дополнительных функций, необходимых для релиза (e-mail рассылки, интеграция аналитики и т.д.)
6. Завершение стабилизации приложения, оптимизация под различные устройства, улучшение производительности

Итерация #1

Задачи и результат:

• Создание базовой структуры приложения и интерфейса: верстка основных экранов
• Проектирование базы данных
• Подготовка документа с описанием API (для взаимодействия бэкэнда с приложением).
• Настройка сервера
• Проработка  интеграции со сторонними приложениями/сервисами

 
Почему?

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

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

Итерация #2

Задачи и результат:

• Завершить работы, связанные с дизайном и интерфейсом (верстка большей части экранов приложения)
• Команда мобильной разработки должна ознакомиться с API, предоставленным ей backend-командой, и подтвердить, что всё готово, и можно начинать интеграцию.
• Завершить реализацию всех API-интерфейсов на стороне back-end
• Статичная верстка страниц без логики на стороне front-end (администраторская панель)

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

Итерация #3

Задачи и результат:

• Реализовать большую часть сетевой архитектуры и API
• Интеграция со сторонними сервисами (если приложение это подразумевает)
• Основной функционал приложения работает без критических ошибок
• Завершить реализацию бизнес-логики на стороне back-end
• Интеграция API на стороне front-end, подключение основной бизнес-логики

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

Итерация #4

Задачи и результат:

• Завершить разработку основных функций приложения
• Закончить реализацию бизнес-логики со стороны front-end
• Тестирование и оптимизация API со стороны back-end
• Список известных проблем, выявленных QA-командой
• (!) В конце итерации клиент должен подтвердить, что в приложении присутствуют все требуемые функции (логика)

 
Почему?  

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

Итерация #5

Задачи и результат:

• Стабилизация приложения — команда исправляет баги, заявленные QA-командой и клиентом
• В течение итерации клиент предоставляет итоговый список задач, которые нужно сделать для приемки проекта.
• В конце итерации — стабильное приложение в котором отсутствуют критические баги
• Тестирование интерфейса на соответствие дизайну. Подготовленный список задач для правок в 6 итерации.

 
Почему? Обычно для релиза проекта бывает необходимо выполнить несколько задач,  не входивших в изначальный план. Например:
 

• Интеграция e-mail рассылок
• Внедрение в приложение аналитики
• Создание сопутствующей страницы-лендинга, etc.

Итерация #6

Задачи и результат:

• Исправить все замечания из приемочного списка на стороне пользовательского клиента и front-end
• Сопоставить текущий дизайн приложения с изначальным вариантом и реализовать правки для полного соответствия.
• Подготовка к запуску и тестированию на различных устройствах
• Подготовка к бета-тесту приложения (в случае необходимости)

 
! В случае, если ваш продукт разрабатывается для iOS, на данном этапе рекомендуется отправить приложение на модерацию в App Store, так как процесс модерации приложения может занять до нескольких недель.

Релиз (Beta launch)

После завершения разработки, приложение отправляется на модерацию для последующего размещения в App Store/Google Play (если это мобильное приложение). При этом нужно учитывать, что продолжительность процесса модерации может варьироваться от пары часов (Google Play) до нескольких недель (App Store).

В случае, если клиент хочет опробовать свой продукт на небольшой группе пользователей, релизу приложения может предшествовать бета-тест. В зависимости от платформы и целей бета-теста можно использовать разные инструменты — Crashlytics, TestFlight, Diawi и т.д.

Гарантийный Период

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

2-й этап

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

Напоследок

В заключение, мы хотели бы упомянуть о типичных ошибках при разработке продукта, которых нетрудно избежать:
 

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

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

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