Назад

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

Время чтения: 4 минут

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

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

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

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

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

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

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

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

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

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

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

    Пресейл

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

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

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

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

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

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

    Старт

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

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

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

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

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

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

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

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

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

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

    Кризис

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

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

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

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

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

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

    Завершение

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

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

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

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


    Подытожим

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

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

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