Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

Меня зовут Дмитрий и я занимаюсь Agile трансформациями компаний и помогаю компаниям выстраивать процессы, а также являюсь основателем консалтингового агентства Smart units. Последние несколько лет выстраивал процессы заказной разработки, а также участвовал в крупных проектах реализации продукта вместе с вендором. И здесь набил много ошибок, а также сформировал набор правил того, как действительно нужно вести разработку продукта если вдруг вы являетесь либо Заказчиком, либо компанией которая предоставляет услуги по заказной разработки.

Та система, которую я опишу, позволит вам получать более быстрый и качественный результат при заказной разработке. А самим компаниям, которые делают заказную разработку, получать более счастливых клиентов, которые будут возвращаться за новым сотрудничеством.

Ключевая проблема заказной разработкой

Заказная разработка - один из самых сложных процессов разработки, т.к. в ходе него возникает несколько вызовов:

1. Решить потребности Заказчика, чтобы он остался доволен;

2. Сделать это в рамках ограниченного срока и бюджета;

3. Организовать эффективное взаимодействие команды Заказчика и Компании разработчика.

И в рамках этих 3 вопросов в классической разработке появляется ряд проблем:

1 проблема. В ходе подготовки проекта

Подготовка проекта, в ходе которой пытаются учесть все детали и упаковать их ТЗ. В результате чего мы тратим огромное количество времени и ресурсов для того, чтобы учесть все требования. Я проходил подобный путь с разными компаниями и вместо того чтобы начинать делать уже продукт, мы тратили месяцы на то, чтобы согласовать договор, постоянно исправляя пункты договора и обсуждая стоимость. А какое количество ресурсов было задействовано со стороны аналитики, разработки, безопасности и других.

Почему это проблема:

• Неопределенность в начале проекта: На ранних этапах часто сложно полностью определить требования и детали проекта, что может привести к неправильным предположениям и ошибкам в планировании.

• Замораживание требований: Попытка учесть все детали с самого начала может привести к желанию "заморозить" требования, что делает систему не способной к адаптации к изменениям. В ходе проекта очень сложно эти изменения производить, происходит цикл согласования Скоупа, стоимости и изменения договора. 

Как следствие, это потеря большого количества времени на то, что потом все равно поменяется.

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

2 проблема. Реализация по строму ТЗ

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

Я часто замечал, что в ходе реализации по строгому ТЗ люди перестают думать и совершают ошибки. Также единственной целью вендора становится успеть в срок и даже перестают думать о качестве. Так в одном проекте, когда срок подходил к концу, а много чего еще не было сделано, вендор просто напросто начать жертвовать качеством лишь бы сдать проект вовремя. А когда с стороны Заказчика начали проводить ревью кода, нашли очень много несовершенств и технического долга, который после сдачи проекта пришлось устранять затрачивая дополнительный бюджет.

Также вендор не знает специфику и реальные потребности Заказчика, поэтому разработка по ТЗ идет в лоб, и даже если там что то не учли, вряд ли про это спросит вендор, так как он не обладает полной картиной.

3. Взаимодействие между заказчиком, его командой и командой вендора

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

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

Как работать по другому или гибкий подход к реализации проектов?

Во первых в любых проектах при реализации заказной разработки необходимо понимать три важных фактора:

1. Требования меняются 

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

1.1. Здесь важно обеспечить гибкость как в контракте так и во взаимодействии

Виды контрактов

• Самый легкий и гибкий - это Time and material, когда оплата производится за фактически отработанное время (дни команды). Здесь легко договориться о недельных или двухнедельных спринтах, точках планирования с вендором и обзора результатов, в ходе которого вы легко сможете планировать и менять требования на пути, а также регулярно сможете наблюдать прогресс по проекту. 

• Еще один вид контрактов - это когда мы не планируем весь проект целиком, а планируем и фиксируем объем работ только на итерацию (условно на 2 недели) и каждые две недели у нас есть прогнозируемый ожидаемый результат, на который коммитится вендор, и даже если он не выполнил объем работ, то это не снимает с него обязательств. В конце каждого спринта подписывается акт приема сдачи.

• Также можно в договор прописать скоуп в виде пользовательских историй которые должны быть сделаны. В них должны быть указаны критерии приемки, чтобы однозначно понимать что планируется сделать и не было расхождений в понимании Заказчика и вендора. Пользовательская история с одной стороны описывает решение проблемы клиента, а с другой - вносит понимание что должно быть сделано с помощью критериев приемки.

1.2. Не забыть про нефункциональные требования

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

Какие это виды требования:

• Требования к тестированию и тестовым сценариям;

• Требования к коду;

• Требования безопасности системы;

• Требования логирования;

• Требования к документации;

и другие.

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

1.3. Определить Definition of done

Очень важный документ о котором все забывают и особенно важен при условиях гибкой разработки. Когда вы обсуждаете с вендором разработку по итерациям и приемку раз в итерацию, важно зафиксировать определение Готово (или definition of done). Иначе сложится ситуация, когда вам что то сделали, но должным образом не протестировали (например нагрузку) или качество кода не соответствует ожиданиям.

В Definition of done мы включаем все вещи необходимые для того, чтобы считать продукт или его часть готовыми. 

Без этого артефакта вам будут отгружать полуготовое решение не пригодное к использованию и будет сложно прогнозировать завершение т.к. объем незавершенки будет расти каждый спринт, поэтому важно убедиться и зафиксировать базовые критерии definition of done в контракт и убедиться что они выполняются каждый спринт.

2. Договоритесь заранее с вендором о совместной работе как одна команда

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

Есть несколько правил:

• Единый чат для Заказчика и вендора где можно решать вопросы продукта и разработки;

• Договоритесь о регулярных созвонах (дейли, планированиях, обзорах результатов);

• Определите правила взаимодействия и проведите kick off проекта на старте с участием обеих сторон.

3. Выделите участников в команду проекта на 100%

Нужно убедиться, что участники с двух сторон и со стороны вендора, и со стороны Заказчика, выделены на 100% в проектную команду и не ведут в параллель несколько проектов, так как это пагубно влияет на скорость взаимодействия, фокусировку людей и качество решений. Я на практике проходил варианты, когда люди были выделены на 100%  и когда специалисты вытаскивались на конкретные задачи. В первом случае уровень мотивации, понимания что мы делаем и фокусировки на задачи, во много раз повышался, что влияло на скорость взаимодействия, вовлеченность и в итоге на более качественные и быстрые результаты.

4  Обсудите процесс

Если вы хотите вести проекты по Agile в заказной разработке, тогда у вас должен быть выстроен процесс взаимодействия со всеми участниками в духе Agile:

• Выстроите разработку продукта в итерациях в которых вся работа должна быть сделана (с учетом definition of done);

• Убедитесь что есть Product owner который может принимать решения и приоритизировать беклог продукта;

• Участники выделены в команду на 100% и у них есть все инструменты и полномочия чтобы реализовывать проект;

• Обеспечьте быстрое взаимодействие с сервисными функциями. Например с теми, кто выдает доступы в компании, безопасностью. Тк часто при реализации проектов с вендором им нужно давать много доступов в ходе проекта и если это взаимодействие и быстрая реакция с сервисными функциями будет не налажена, то вы просто будете терять время на согласования. В идеале чтобы опять же в команду на проект были выделены люди которые смогут эти запросы быстро отрабатывать;

• Поддерживайте культуру и ценности Agile, где во главу ставится заказчик и его потребности, желание сделать хорошо,а  не просто выполнить в срок, получить деньги и уйти.

Выводы

Проблемы проектного подхода в заказной разработке давно известны и с ними сталкиваются 100% компаний. Вариант фиксирования стоимости, срока и бюджета возможен, если вы делаете что-то очень понятное с бизнес и технической точек зрения, где нет зависимостей с другими командами, в том числе. Как правило, это коробочные решения или простые сайты. Однако, если вы создаете продукты с нуля или даже части продуктов, такие как мобильные приложения, где есть бизнес-неопределенность, много технических нюансов и требуется взаимодействие нескольких команд, ведите проекты по Agile. 

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

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

Поэтому, почему бы сразу не сделать все по-нормальному и не пойти гибким путем создания продукта, чтобы получить качественный результат за меньшие деньги?

Статья подготовлена в преддверии старта курса "Agile Project manager". По ссылке вы можете узнать о курсе подробнее, а также успеть записаться на ближайший поток.

Если вас заинтересовал подход, подписывайтесь на мой телеграм-канал, а также если нужна поддержка компании в выстраивании подобных процессов, обращайтесь.