Процесс разработки приложений — нечто большее, чем «давайте просто накодим тут что-нибудь и посмотрим, что будет». Не верьте всем, кто говорит обратное.
Разработка MVP или полной продуктовой версии — это не только про код. Это больше про людей и … кучу других, которые также должны быть закрыты. Это сложно и долго. Предлагаю копнуть глубже и посмотреть на процессы изнутри.
Роли и этапы проекта
Сперва выясним, как выглядит базовый состав лиц, принимающих решения в проектной команде. Процесс разработки приложений курируют, как минимум, CEO, менеджер проекта и тимлид.
Чтобы закрывать задачи и избегать конфликтов, команда делит зоны ответственности.
Кто и за что отвечает:
- CEO — согласовать первоначальные договоренности, определить бизнес-цели, построить долгосрочные партнерские отношения с клиентом.
- Менеджер проекта — организовать команду(спланировать спринты, провести дейли митинги, ретроспективы = и т. д.), управлять скоупом проекта, приоритезировать работу, информировать заказчика о прогрессе.
- Тимлид — управлять командой разработчиков, делегировать задачи, код-ревью.
В процессе разработки приложений команда практически всегда проходит через пляски с бубном следующие этапы:
Рассмотрим каждый подробнее.
Пресейл
Любой проект начинается с пресейла. На этапе пресейла ни CEO, ни менеджер проекта, ни тимлид не имеют полного понимания будущего проекта. Понимания нет, но нужно как-то оценить фронт работ, продать оценку и стартовать.
Пресейл кажется очевидным. Однако уже здесь цели команды расходятся
Чего ждет команда от пресейла?
| CEO | Тимлид | Менеджер проекта |
| Продать и запустить проект. Чем меньше оценка, тем легче продать. | Не тратить время на “потенциальные” проекты. | Убедиться, что я и клиент одинаково понимаем бизнес-цели и приоритеты. |
| Не отпугнуть клиента большой оценкой. Тем не менее, она должна быть точной и реалистичной. | Получить готовый к старту проект. | Выделить время на разбор деталей и оценку, чтобы успешно продать проект, но без ущерба текущим. |
Кто несет ответственность за пресейл? СEO. Менеджер и тимлид выступят, скорее, как ограничение по важным для них вопросам — все остальное СEO закроет сам.
Старт
Оценка продана. Стартуем! Чего ждет команда от старта?
| CEO | Тимлид | Менеджер проекта |
| Занять свободных разработчиков. | Собрать команду, с которой будет максимально комфортно работать. Нереалистично в 99% случаев 🙁 | Получить команду, которая не подведёт. |
| Добиться доверия клиента. Для этого буду постоянно апдейтить о прогрессе. | Подстраховаться. | Согласовать с клиентом бэклог проекта и реальные дедлайны. |
| “Разделить” время тимлида на два проекта. Eсли возможно. Потому что тимлидский ресурс — самый ценный. | Заложить побольше времени на проработку проектной архитектуры. | Избежать новых пресейлов и других ‘стартовых’ проектов. |
| Попробовать новые технологии, чтобы команда прокачивала скиллы и не скучала. | Поделить задачи. Сложные — миддлам, попроще — джунам. | Не пробовать новые технологии. Большой риск не уложиться в дедлайны. |
Кто отвечает за старт? Менеджер. На старте решает тот, кто отвечает за выполнение изначальных договоренностей и установление новых по ходу работ.
Важно! Перед тем, как CEO переобуется в наблюдателя пойдет искать новые проекты, необходимо убедиться, что менеджер взял на себя ответственность за проект.
Разработку запустили. Ответственность передали. Едем дальше.
Активная фаза
В процессе разработки приложений активная фаза — это про Тимлида и PM’а. CEO уже давно не в авангарде, но, как всегда, близко: D
Чего хочет команда от активной фазы?
| CEO | Тимлид | Менеджер проекта |
| Уложиться в сроки и стабильно деливерить прогресс. | Избежать новых требований. Новые требования = потенциальные изменения архитектуры/команды = боль. | Знать, что команда уделяет достаточно времени проектным задачам. |
| Знать, что команда уделяет достаточно времени проектным задачам. | Выделять достаточное количество времени на багфикс. | Поддерживать уровень клиентского доверия с помощью апдейтов и демо. |
Кто отвечает за активную фазу? Тимлид. Потому что в активной фазе у руля стоит тот, кто знает техническую часть и бизнес-логику проекта от и до. СEO и менеджер мониторят прогресс и помогают команде поддерживать стабильный уровень продуктивности.
Кризис
Для команды активная фаза самая безопасная. Правда в том, что процесс разработки приложений — это не про скачущих по облакам единорогов.
Кризис может и не случиться. Но если приходит, то всегда неожиданно.
Допустим, все-таки, пришел. На этом этапе команда хочет сделать все возможное, чтобы минимизировать последствия. Как именно?
| CEO | Тимлид | Менеджер проекта |
| Возьмусь разруливать ключевые проектные решения. Так, я защищу команду и не потеряю клиента. | Сфокусируюсь на проекте, который находится в кризисе (если до этого работал параллельно на двух проектах). | Подниму прозрачность до небес. Буду апдейтить клиента по несколько раз в день, потому что “Чувак, мы реально делаем все, чтобы вылезти из проблем”. |
| Буду Cуперменом. Решу проблемы и верну клиентское доверие. | Получить список задач, раскиданный по приоритетам. | Выкину неприоритетные таски из бэклога. Время ограничено, жопы горят — сделаем максимум. |
Кто отвечает за “выйти из кризиса”? Потерять репутацию — больно, поэтому на этапе кризиса CEO включается на 100%. Просто потому это чаще всего про изменение изначальных договоренностей.
Кризис не всегда касается разбора факапов со стороны команды. Иногда это про перераспределения бюджета, рабочих часов или бизнес-требований. Все эти вопросы касаются CEO.
Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.
ПодписатьсяЗавершение
Кризис позади — ура! Команда вымоталась: кто-то успел заскучать от рутинных задач/отсутствия новых технологий. Кайф в том, что кризис позади и продукт близок к завершению.
Чего хочет команда на этапе, когда процесс разработки приложений подходит к концу?
| CEO | Тимлид | Менеджер проекта |
| Дальше развивать проект. Потому что продукт крайне редко бывает “полностью готовым”. | Качественно завершить проект. Bыделить время на “полировку”/devops | Просто закончить нынешний проект. |
| Переключить тимлида на другой проект. Если не вредит запуску и саппорту нынешнего. | Попробовать новые технологии, бизнес-задачи, архитектуры = Переключиться на новый проект, чтобы прокачать скиллы. | Выделить достаточно времени на новый проект. Потому что конец текущего проекта = старт нового. |
Кто отвечает за завершение проекта? Менеджер. Потому что он проконтролирует работу на этапе приемки. CEO все так же где-то рядом, потому что развитие партнерских отношений превыше всего 🙂
Подытожим
Не берусь утверждать, что все вышеизложенное — абсолютная истина для всех и каждого. Статья больше про процесс разработки приложений, а именно, про то, как это работает у нас в Purrweb.
Попробуем вычленить главное:
- Процесс разработки приложений — не про общие цели. И это нормально.
- Процесс разработки приложений — не про общие цели. Более того, все члены команды имеют разные микро-цели с самого начала.
- У команды проекта разные микро-цели. ГЛОБАЛЬНАЯ ЦЕЛЬ одна — разработать продукт, который поможет клиенту достичь бизнес-целей и заставит пользователей сказать: «Кто же смог сделать так круто?»
