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

В интернете и книгах полным-полно best practices, которые освещают те или иные моменты в работе над ИТ-проектом. Однако best practices не позволяют увидеть всю картинку, на которой был бы виден весь путь реализации проекта с нуля.

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

Кому будет полезна данная статья

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

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

Intro

Йо! Меня зовут Андрей Пономаренко. Я и моя команда занимаемся заказной разработкой, а именно созданием веб- и 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. Этап поддержки.

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

1. Ознакомительный этап

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

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

Шаг 1: Узнать что хочет заказчик

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

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

Шаг 2: Согласовать с заказчиком flow, по которому вы с ним будете работать

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

Лично я пересказываю то, о чем пишу в данной статье.

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

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

Как формируется стоимость проекта?

У каждого члена команды есть стоимость часа.

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

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

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

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

Шаг 3: Познакомить заказчика с командой

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

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

Шаг 4: Подписать рамочный договор

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

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

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

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

В этом договоре отражаются основные права и обязанности сторон.

То есть в этот договор вшивается вся «бюрократия».

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

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

Hint

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

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

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

Шаг 5: Засетапить проект

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

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

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

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

Свой выложу в отдельной статье.

Написанные кровью правила:

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

2. Подготовительный этап

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

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

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

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

Шаг 1: Подготовиться к творческому процессу

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

Аналитик и UX/UI дизайнер на выходе дают свои estimate.

Project Manager курирует процесс.

Зачем тут QA?

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

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

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

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

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

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

Шаг 2: Подготовить сырье

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

Project Manager все так же курирует процесс.

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

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

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

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

Шаг 3: Завести задачи

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

Шаг 4: Провести оценку трудозатрат, сроков и стоимости, и сформировать задание на разработку

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

В рамках направленностей (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. Составьте критический путь и матрицу рисков. Держите в уме все места, где вас может заблокировать заказчик. О том что такое критический путь и матрица рисков можно будет прочитать в конце статьи.

Этап 3. Этап разработки

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

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

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

Организуйте команде условия

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 никогда не удается двигаться. Всегда будет несколько в работе. Важно следить за тем, чтобы технический долг, недоделанные фичи и баги не перевалили за критическую линию. Если перевалят — быть беде. Слушайте команду. Следите за ее эффективностью

Этап 4: Сдача проекта (или его части)

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

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

Написанные кровью правила:

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

Этап 5: Поддержка и сопровождение

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

Срок гарантийного периода прописывается в договоре.

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

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

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

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

Так не придется ничего выдумывать. Ибо подписка всегда будет не выгодна как минимум одной стороне.

Написанные кровью правила:

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

Полезные ссылки:

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

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

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

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

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

Вопросы к аудитории

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