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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналитик, 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 все так же курирует процесс.

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

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

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

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

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

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

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

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

Story за story

Примечания:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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