Назад
процесс разработки приложений

Процесс разработки приложений: взгляд из-за кулис

Процесс разработки приложений — нечто большее, чем «давайте просто накодим тут что-нибудь и посмотрим, что будет». Не верьте всем, кто говорит обратное. 

Разработка MVP или полной продуктовой версии — это не только про код. Это больше про людей и … кучу других, которые также должны быть закрыты. Это сложно и долго. Предлагаю копнуть глубже и посмотреть на процессы изнутри. 

Роли и этапы проекта

Сперва выясним, как выглядит стандартная проектная команда. Процесс разработки приложений курируют, как минимум, CEO, менеджер проекта и тимлид.

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

Кто и за что отвечает:

  • CEO — согласовать первоначальные договоренности, определить бизнес-цели, построить долгосрочные партнерские отношения с клиентом.
  • Менеджер проекта — организовать команду(спланировать спринты, провести дейли митинги, ретроспективы = и т. д.), управлять скоупом проекта, приоритезировать работу, информировать заказчика о прогрессе.
  • Тимлид — управлять командой разработчиков, делегировать задачи, код-ревью.
READ MORE  Особенности разработки мобильного приложения для службы доставки: кейс B2B-сервиса Cargo

В процессе разработки приложений команда практически всегда проходит через пляски с бубном следующие этапы:

процесс разработки приложений

Рассмотрим каждый подробнее.

Пресейл

Любой проект начинается с пресейла. На этапе пресейла ни CEO, ни менеджер проекта, ни тимлид не имеют полного понимания будущего проекта. Понимания нет, но нужно как-то оценить фронт работ, продать оценку и стартовать.

процесс разработки приложений

Пресейл кажется очевидным. Однако уже здесь цели команды расходятся

Чего ждет команда от пресейла?

CEO Тимлид Менеджер проекта
Продать и запустить проект. Чем меньше оценка, тем легче продать. Не тратить время на “потенциальные” проекты. Убедиться, что я и клиент  одинаково понимаем бизнес-цели и приоритеты.
Не отпугнуть клиента большой оценкой. Тем не менее, она должна быть точной и реалистичной. Получить готовый к старту проект. Выделить время на разбор деталей и оценку, чтобы успешно продать проект, но без ущерба текущим.

Кто несет ответственность за пресейл? СEO. Менеджер и тимлид выступят, скорее, как ограничение по важным для них вопросам — все остальное СEO закроет сам.

Старт

Оценка продана. Стартуем! Чего ждет команда от старта?

CEO Тимлид Менеджер проекта
Занять свободных разработчиков. Собрать команду, с которой будет  максимально комфортно работать. Нереалистично в 99% случаев 🙁 Получить команду, которая не подведёт.
Добиться доверия клиента. Для этого буду постоянно апдейтить о прогрессе. Подстраховаться. Согласовать с клиентом бэклог проекта и реальные дедлайны.
“Разделить” время тимлида на два проекта. Eсли возможно. Потому что тимлидский ресурс — самый ценный. Заложить побольше времени на проработку проектной архитектуры. Избежать новых пресейлов и других ‘стартовых’ проектов.
Попробовать новые технологии, чтобы команда прокачивала скиллы и не скучала. Поделить задачи. Сложные — миддлам, попроще — джунам. Не пробовать новые технологии. Большой риск не уложиться в дедлайны.

Кто отвечает за старт? Менеджер. На старте решает тот, кто отвечает за выполнение изначальных договоренностей и установление новых по ходу работ.

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

Разработку запустили. Ответственность передали. Едем дальше.

READ MORE  Кейс экспресс-дизайна от агентства Purrweb: как упаковать медицинский стартап за $1500 и привлечь $400 тысяч

Активная фаза

В процессе разработки приложений активная фаза — это про Тимлида и PM’а. CEO уже давно не в авангарде, но, как всегда, близко: D

Чего хочет команда от активной фазы?

CEO Тимлид Менеджер проекта
Уложиться в сроки и стабильно деливерить прогресс. Избежать новых требований. Новые требования = потенциальные изменения архитектуры/команды = боль. Знать, что команда уделяет достаточно времени проектным задачам.
Знать, что команда уделяет достаточно времени проектным задачам. Выделять достаточное количество времени на багфикс. Поддерживать уровень клиентского доверия с помощью апдейтов и демо.

Кто отвечает за активную фазу? Тимлид. Потому что в активной фазе у руля стоит тот, кто знает техническую часть и бизнес-логику проекта от и до. СEO и менеджер мониторят прогресс и помогают команде поддерживать стабильный уровень продуктивности.

Кризис

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

Кризис может и не случиться. Но если приходит, то всегда неожиданно.

Допустим, все-таки, пришел. На этом этапе команда хочет сделать все возможное, чтобы минимизировать последствия. Как именно?

CEO Тимлид Менеджер проекта
Возьмусь разруливать ключевые проектные решения. Так, я защищу команду и не потеряю клиента. Сфокусируюсь на проекте, который находится в кризисе (если до этого работал параллельно на двух проектах). Подниму прозрачность до небес. Буду апдейтить клиента по несколько раз в день, потому что “Чувак, мы реально делаем все, чтобы вылезти из проблем”.
Буду Cуперменом. Решу проблемы и верну клиентское доверие. Получить список задач, раскиданный по приоритетам. Выкину неприоритетные таски из бэклога. Время ограничено, жопы горят — сделаем максимум.

Кто отвечает за “выйти из кризиса”? Потерять репутацию — больно, поэтому на этапе кризиса CEO включается на 100%. Просто потому это чаще всего про изменение изначальных договоренностей.

Кризис не всегда касается разбора факапов со стороны команды. Иногда это про перераспределения бюджета, рабочих часов или бизнес-требований. Все эти вопросы касаются CEO.

Завершение

Кризис позади — ура! Команда вымоталась: кто-то успел заскучать от рутинных задач/отсутствия новых технологий. Кайф в том, что кризис позади и продукт близок к завершению.

Чего хочет команда на этапе, когда процесс разработки приложений подходит к концу?

CEO Тимлид Менеджер проекта
Дальше развивать проект. Потому что продукт крайне редко бывает “полностью готовым”. Качественно завершить проект. Bыделить время на “полировку”/devops Просто закончить нынешний проект.
Переключить тимлида на другой проект. Если не вредит запуску и саппорту нынешнего. Попробовать новые технологии, бизнес-задачи, архитектуры = Переключиться на новый проект, чтобы прокачать скиллы. Выделить достаточно времени на новый проект. Потому что конец текущего проекта = старт нового.

Кто отвечает за завершение проекта? Менеджер. Потому что он проконтролирует работу на этапе приемки. CEO все так же где-то рядом, потому что развитие партнерских отношений превыше всего 🙂

READ MORE  Гид по дизайн-проектам: Создаем предварительный концепт

Подытожим

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

Попробуем вычленить главное:

  • Процесс разработки приложений — не про общие цели. И это нормально.
  • Процесс разработки приложений — не про общие цели. Более того, все члены команды имеют разные микро-цели с самого начала.
  • У команды проекта разные микро-цели. ГЛОБАЛЬНАЯ ЦЕЛЬ одна — разработать продукт, который поможет клиенту достичь бизнес-целей и заставит пользователей сказать: «Кто же смог сделать так круто?»