Как сделать заказной веб- или mobile-проект с нуля: процессы, правила и немного крови

В интернете и книгах полным-полно best practices, которые освещают те или иные моменты в работе над ИТ-проектом. Однако best practices не позволяют увидеть всю картинку, на которой был бы виден весь путь реализации проекта с нуля. Мне не удалось найти такой «мануал», который бы разложил четко и по полочкам весь объем и порядок работ в заказном проекте. Поэтому идея поделиться своим опытом в разработке «внешних проектов» показалась мне неплохой — быть может, вы узнаете здесь себя.

Статья будет полезна:

• Для начинающих и опытных руководителей ИТ-проектов (aka Project Manager).
• Заказчиков внешних (аутсорс) команд разработки под ключ и не под ключ.
• Существующих компаний и команд, которым интересны процессы у других.
• Тех, кто хочет собрать команду для аутсорс разработки.
• Всех, интересующихся процессами в разработке на заказ.

Йо! Меня зовут Андрей Пономаренко. Я и моя команда занимаемся заказной разработкой, а именно созданием веб- и mobile-приложений с нуля.

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

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

Сразу оговорюсь: речь пойдет не о лендингах на два дня работы и не об интернет-магазинах на Tilda, Wordpress или Wix.

Речь пойдет о кастомных решениях со сроками разработки от трех месяцев до пары лет. Пример такого проекта — platform.goldfixing.ru. GoldFixing — одна из наших работ — платформа, посвященная рынку сбережений и накоплений в драгметаллах, и новый канал продаж для одного нишевого банка.

О процессах: я расскажу про выработанный нами базовый flow. В слово flow я вкладываю порядок работ и сопутствующие практики, которые мы берем за основу в наших проектах. Другими словами, это скелет процессов и регламентов, легко адаптируемый под каждый конкретный проект. Этот flow предполагает, что заказчик в целом понимает, что за продукт или продукты он хочет создать, как он планирует их продвигать и как на них зарабатывать. Мы не занимаемся маркетингом (к слову, в комментариях я смогу вам посоветовать кое-кого с пушечным опытом в этих вопросах).

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

А затем я поэтапно все-все расскажу.

• Проект — деятельность, в рамках которой создаются продукты.
• Продукт — нечто (услуга, приложение, anything), решающее пользовательскую проблему.
• Инфраструктура проекта — среда, где оживают продукты. Серверы, виртуалки, системы сбора ошибок, логов, мониторинг.
• Project Manager — руководитель проекта.
• Frontend или Mobile Developer = разработчик клиентской части приложения.
• Backend Developer — разработчик серверной части приложения.
• QA Engineer — специалист по обеспечению качества.
• devOps — разработчик проектной инфраструктуры.
• UX/UI Designer — дизайнер;
  UX означает ответственность за удобство, доступность и функциональность интерфейса;
  UI означает ответственность за графическую составляющую интерфейса.
• Estimate — временная оценка трудозатрат.
• User Story — пользовательское требование.
• Wireframes — образ дизайна низкой точности. Он должен отвечать на вопросы: что, где и как будет расположено в интерфейсе. То есть обозначать основную группу контента (что), структуру информации (где) и взаимодействие между интерфейсом и пользователем (как).
• «Сырье» для разработчиков — всевозможные требования + макеты + wireframes.

Я делю работу над первым релизом внешнего проекта на пять этапов:

1. Ознакомительный этап.
2. Подготовительный этап.
3. Этап разработки.
4. Этап сдачи проекта или модуля.
5. Этап поддержки.

Для всех последующих релизов остаются актуальны пункты со второго по пятый.

Результат этапа:

• Подписанный рамочный договор с заказчиком
• Синхронизированное понимание целей и задач
• Сформированная основа для единой команды с заказчиком на весь горизонт сотрудничества

Нужно получить от заказчика ответы на следующие вопросы:

• Что он хочет сделать?
• Зачем он хочет это сделать?
• Для кого он хочет это сделать?
• На каких технологиях он хочет это делать?
• Сколько времени у него есть на создание этого?
• В каких границах живет бюджет на создание?
• Какие у заказчика есть переживания?
• Что заказчик относит к узким местам?
• Какие есть требования к железу/производительности/пользовательским устройствам?
• Как заказчик видит сдачу проекта?
• Как заказчик видит сопровождение проекта по его окончании?
• В каких границах живет бюджет на сопровождение?
• Можно ли положить проект в наше портфолио?

Нужно рассказать заказчику весь путь работы над проектом.
Лично я пересказываю то, о чем пишу в данной статье.
Это можно сделать по-разному: устно, текстом, презентацией, еще как-то. Постарайтесь определить, кем является заказчик — визуалом, аудиалом, кинестетиком или дискретом, и, в зависимости от этого, выбирайте способ изложения своего flow.

Дальше этот flow нужно вместе с заказчиком скорректировать так, чтобы обеим сторонам было комфортно.

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

Таким образом стоимость проекта/этапа/задачи определяется стоимостью часа работы конкретного специалиста и estimate на его работу.

Как вычислять себестоимость и стоимость часа — повод для отдельной статьи.

Ниже будет представлена используемая мной боевая таблица для расчета стоимости проекта.

Можно очно или онлайн. На встрече присутствуют наша команда и команда заказчика.

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

Коротко о том, что это за договор такой:

Рамочный договор

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

В конце статьи можно подробнее прочитать, что такое рамочный договор и посмотреть пример.

В этом договоре отражаются основные права и обязанности сторон.
То есть в этот договор вшивается вся «бюрократия».
При этом все, что касается содержательной части, то есть конкретных задач/сроков/стоимостей, пакуется в отдельные мини-договора, называющиеся заданиями (приложениями), которые «приклеиваются» к рамочному договору.
Таким образом с точки зрения бюрократии появляется гибкость в декомпозиции проекта на задачи/сроки/стоимости.

Hint:
Я сторонник того, чтобы в задании к договору задач было не больше, чем на месяц. Скажем, если есть этап на 3 месяца — мы бьем его на 3 подэтапа, каждый длительностью в месяц.
Таким образом, в случае проблемного заказчика мы не рискуем потерять денег больше, чем за 1 месяц работы.
Заказчик тоже остается в плюсе — он не рискует сразу всеми деньгами -> чаще видит промежуточные результаты работ -> спит спокойней.

На старте каждого проекта есть определенный набор действий, которые нужно совершить, чтобы поставить проект на «рельсы».

Этот набор действий можно представить как чек-лист:

• Завести каналы в Slack
• Подготовить Jira/Confluence
• Ввести в курс дела команду
• Проанализировать контрагентов на стороне заказчика
• Настроить GitLab
• Составить перечень документации
• И так далее

Этот список может быть очень большим. У каждого он свой.
Свой выложу в отдельной статье.

1. Письменно фиксируйте все договоренности с заказчиком. Ведите протоколы встреч, получайте от заказчика ОК на каждый протокол
2. Письменно зафиксируйте зоны ответственности ваши и заказчика
3. Роли и зоны ответственности в команде тоже должны быть четко и письменно зафиксированы на старте
4. С самого начала введите команду в курс дела. Принимайте решения вместе с ней, а не за нее
5. Четко пропишите порядок сдачи проекта или его модулей
6. Обозначьте заказчику, что он может делать, взаимодействуя с членами вашей команды, а что нет. Остерегайтесь особо ретивых заказчиков, которые могут попробовать схантить кого-нибудь у вас

Результат этапа:

• Сформированное сырье для разработчиков
• Таймлайн(план-график)
• Стоимость каждого продукта с разбивкой по модулям
• Подписанное задание к рамочному договору на разработку модуля/задачи/этапа

Данный этап выступает в роли фундамента для всех последующих этапов. Это делает его самым важным.

Подготовка — самый творческий и непредсказуемый процесс в силу того, что здесь происходит притирка с заказчиком и много взаимодействия с ним. А заказчики все разные.

Аналитик, UX/UI дизайнер и QA, держась за руки, общаются с заказчиком, собирают всю критическую для них информацию.
Аналитик и UX/UI дизайнер на выходе дают свои estimate.
Project Manager курирует процесс.

Зачем тут QA?
QA — это человек, который отвечает за качество. Качество не только системы, но и качество требований, wireframes и макетов. Эти три сущности нужно тестировать на понятность, полноту, непротиворечивость и адекватность. Это значит, что ему нужно с самого начала приглядывать за тем, что, как минимум, аналитик и дизайнер ничего не упускают при общении с заказчиком. А как максимум — валидировать и дополнять заказчика, «тестировать» те вводные, что он дает.

Project Manager берет эти estimates, проверяет, что команда ничего не забыла, не перепутала, что estimates обоснованы, на основе опыта работы с командой закладывает буфер и получает итоговый estimate.

На основе estimates Project Manager формирует таймлайн и стоимость.

Затем идет коммуникация с заказчиком, торги за estimates/сроки/стоимость, корректировки в вводных для аналитика и дизайнера.

Если все окей — для данного этапа создается задание к рамочному договору.

Пример задания для данного этапа можно глянуть внизу статьи.

Аналитик, UX/UI дизайнер и QA все так же держатся за руки.
Project Manager все так же курирует процесс.

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

В ходе общения с заказчиком продукты бьются на модули.

И дальше, итеративно для каждого модуля, есть следующие активности:

• Аналитик и дизайнер вместе вынимают информацию из заказчика.
  Дизайнер переваривает ее и выдает wireframes с драфтами макетов
• Аналитик структурирует мысли заказчика и дизайнера, а затем излагает их в виде пользовательских, функциональных и прочих требований. Пример в конце статьи.
• QA впитывает всю информацию и следит, чтобы вводные данные и результаты (требования/wireframes/макеты) были адекватны, полны и непротиворечивы
• Project Manager по необходимости привлекает разработчиков/девопса для обсуждения технических требований, ограничений и т.д.
• Project Manager следит за тем, чтобы не придумали чего-то такого, что неоправданно повысило бы риски/сложность проекта
• Происходит согласование с заказчиком требований/wireframes/драфтов макетов
• Дизайнер делает финальные макеты и согласовывает их

1. Каждый модуль (Epic) Project Manager декомпозирует на User Story, которые сформулировал аналитик + заводит всякие «служебные» задачи, например, «Реализовать библиотеку компонентов приложения (UI Kit)»
2. Каждую User Story/Task разработчик декомпозирует на технические задачи
3. QA валидирует декомпозицию — следит за тем, чтобы задачи были понятно сформулированы, и чтобы с данной декомпозицией было удобно проводить тестирование

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

В рамках направленностей (frontend/backend) оценивать работы по модулю должны лиды или в случае их отсутствия — конкретные исполнители.

1. Разработчики дают estimates заведенным им задачам
2. Project Manager проверяет, что команда ничего не забыла, не перепутала, что декомпозиция полна, а estimates обоснованы
3. Project Manager на основе опыта работы с командой закладывает буферы и получает итоговый estimate, сроки и стоимость модуля. Если опыта работы с командой нет — следует закладывать буферы, исходя из сложности задач, степени обоснованности estimate исполнителем и собственного опыта

В итоге получается таблица с расчетом стоимости проекта. Ее пример в конце статьи.
Там же пример задания на разработку.

1. Не делайте оценку сами. У вас есть команда. Пусть она оценивает. А вы держите в уме, кто в вашей команде насколько точно оценивает. Для того, чтобы вести статистику в Jira, есть инструменты для построения отчетов схождения estimates. Закладывайте свой буфер на оценку каждого по отдельности
2. Если вы сами собирали команду, то доверяйте ей. И при любых раскладах слушайте ее и слышьте ее. Как устанавливать доверительные отношения с новой командой — повод для отдельной статьи
3. Далеко не всегда можно позволить себе начать писать первые строчки кода, имея все-все сырье. В такой ситуации четко определите с командой необходимый минимум для того, чтобы начать разработку, не переживая о том, что вы сходу начали создавать «монстра», и потом непонятно, сколько всего придется перепиливать
4. Далеко не всегда условия позволяют провести обстоятельную оценку. В таком случае команде нужно понять наиболее опасные места и оценить трудозатраты хотя бы для них. Четко держите в голове те места, где «уступать нельзя», и отстаивайте у заказчика/руководства необходимость в детализации сырья
5. Если заказчик хочет сроки, которые невозможны с вашими оценками, не подписывайтесь на эти сроки. Сроки делятся на желаемые и реальные: ) Нельзя в 5-литровую банку влить 7 литров воды. И даже 6 литров. И даже 5.5 литров. Если заказчик хочет привязаться к дате — нужно менять требования так, чтобы оценка (с буфером) сошлась с ожидаемой заказчиком датой. Аналогично с бюджетом.
6. Если заказчик говорит: «а давайте вот эти требования потом додумаем, по ходу дела разберемся» — обозначайте, что вы не сторонник нездорового авантюризма, что эти доделки выйдут в отдельное задание в рамках договора. То есть Project Manager не должен подписываться на абстрактные и непродуманные задачи. Это допустимо только при предоставлении аутстафф-услуг
7. Если заказчик говорит: «мы предоставим вам дизайн, сейчас есть драфты, давайте на основе них сделаем оценку и подпишемся» — обозначайте, что вы напрямую зависите от дизайна и что, не имея четкого дизайна, вы будете вынуждены закладывать внушительный буфер
8. Составьте критический путь и матрицу рисков. Держите в уме все места, где вас может заблокировать заказчик. О том что такое критический путь и матрица рисков можно будет прочитать в конце статьи.

Про этот этап можно написать отдельную книгу.
Или, по крайней мере, отдельную статью.

Обозначу ключевые моменты.

1. Организуйте четкие каналы и процессы коммуникации
2. Сформулируйте зоны ответственности каждой роли (frontend/backend/devOps/design и т.д.)
3. Сформулируйте зоны ответственности каждого члена команды
4. Выберите удобные инструменты. Например:
   - GSuite — почта. Расскажите ребятам, как пользоваться фильтрами и лейблами в Gmail
   - MIRO — wireframes/схемы и т.д.
   - Figma — макеты
   - Slack — мессенджер
   - LambdaTest — парк девайсов
   - GitLab — VCS
   - JIRA/Confluence (да, их есть, за что хейтить, но я лично альтернативу лучше не подобрал)
   

5. Настройте Workflows в вашем менеджере задач

6. Организуйте devOps-магию в виде CI/CD в связке с уведомлениями в Slack

7. Организуйте в Slack поток уведомлений о происходящем в Figma/Miro/Jira/Confluence/Sentry
8. Убедитесь, что у вас есть согласованный внутри команды git-flow

Story за story

1. Разработчики взяли несколько задач и ушли их пилить
2. Разработчики сделали задачи, отправили их на валидацию QA
3. QA провалидировали, часть пустили в Done, часть вернули в Rework
4. За пару итераций победили story
5. Команда провела внутренний demo — QA продемонстрировал сделанную User Story Project Manager’у, дизайнерам и аналитику
6. Команда получила фидбек
7. Команда что-нибудь доделала
8. Project Manager провел demo разрабатываемой story перед заказчиком
9. Project Manager получил фидбек
10. Команда что-нибудь доделала

Примечания:

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

С точки зрения бюрократии в задание в рамках договора скорее всего будет зашит модуль = группа сторей. Однако ничто не мешает сдавать их story за story.
Раньше получите фидбек от заказчика — меньше возни будет при закрытии задания.

Помните: то, что приложение открывается и хорошо работает в браузере — не значит, что оно готово к production.

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

Для этого нужны (основное):

• правильно организованные доступы
• система сбора ошибок
• система мониторинга, health checks, алерты
• система сбора логов
• бекапы

И вся эта жуть в организации порой дается сложнее разработки самих продуктов.

1. В первую очередь занимайтесь интеграциями. Никогда не знаешь, на каком шаге в интеграции случится затык
2. Проводите ретроспективы. Не нужно часто. Нужно не редко. И не забывайте устранять проблемы, найденные в ходе ретроспектив. А не просто их записывать в meeting notes.
3. Следите за багажом из недоделок/багов и мелочей. Прям story за story никогда не удается двигаться. Всегда будет несколько в работе. Важно следить за тем, чтобы технический долг, недоделанные фичи и баги не перевалили за критическую линию. Если перевалят — быть беде. Слушайте команду. Следите за ее эффективностью

Если на этапах 2 и 3 все было сделано по красоте, то при адекватности заказчика этап 4 будет проходить просто.

1. Устраиваете demo day. Показываете заказчику все сделанное
2. Получаете фидбек
3. Вносите в продукты правки на основе фидбека
4. Передаете заказчику
   - Код
   - Документацию и инструкции
   - Требования, макеты, wireframes
   - Прочие исходники
   - Доступы к серверам/хостингам/доменам
5. Даете заказчику согласно договору N дней на проведение внутренних проверок. В грустных случаях — на основе ПМИ/ПСИ
6. Получаете список доделок
7. Устраняете доделки
8. Закрываете задание к договору
9. Получаете рассчет

1. Не кладите все яйца в одну корзину. Не стоит в рамках договора делать задания объемом на несколько месяцев. Делая задания небольшими, вы рискуете меньшими суммами в случае недобросовестного заказчика

После сдачи проекта в течение M дней справедливо устранять возникающие на стороне заказчика проблемы, относясь к ним как к «гарантийному случаю».
Срок гарантийного периода прописывается в договоре.

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

1. Почасовой биллинг, оплата раз в месяц
   
2. Подписка — X рублей в месяц
   

С точки зрения бюрократии оба формата нормально ложатся в формат заданий в рамках договора.

ИМХО, почасовая выглядит справедливее по отношению к обеим сторонам.
Так не придется ничего выдумывать. Ибо подписка всегда будет не выгодна как минимум одной стороне.

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

Подробнее о том, что такое рамочный договор можно прочитать тут.

Пример рамочного договора и заданий к нему — тут.

Пример пользовательских и функциональных требований — тут.

Пример таблицы с подсчетом стоимости проекта — тут.

Про критический путь и матрицу рисков — тут и тут.

1. Какие места вы хотели бы, чтобы я раскрыл поподробнее?
2. Какие эпизоды из своего опыта вы бы отнесли к «Правилам, написанным кровью»?