Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Меня зовут Дмитрий и я занимаюсь Agile трансформациями компаний и помогаю компаниям выстраивать процессы, а также являюсь основателем консалтингового агентства Smart units. Последние несколько лет выстраивал процессы заказной разработки, а также участвовал в крупных проектах реализации продукта вместе с вендором. И здесь набил много ошибок, а также сформировал набор правил того, как действительно нужно вести разработку продукта если вдруг вы являетесь либо Заказчиком, либо компанией которая предоставляет услуги по заказной разработки.
Та система, которую я опишу, позволит вам получать более быстрый и качественный результат при заказной разработке. А самим компаниям, которые делают заказную разработку, получать более счастливых клиентов, которые будут возвращаться за новым сотрудничеством.
Ключевая проблема заказной разработкой
Заказная разработка - один из самых сложных процессов разработки, т.к. в ходе него возникает несколько вызовов:
Решить потребности Заказчика, чтобы он остался доволен;
Сделать это в рамках ограниченного срока и бюджета;
Организовать эффективное взаимодействие команды Заказчика и Компании разработчика.
И в рамках этих 3 вопросов в классической разработке появляется ряд проблем:
1 проблема. В ходе подготовки проекта
Подготовка проекта, в ходе которой пытаются учесть все детали и упаковать их ТЗ. В результате чего мы тратим огромное количество времени и ресурсов для того, чтобы учесть все требования. Я проходил подобный путь с разными компаниями и вместо того чтобы начинать делать уже продукт, мы тратили месяцы на то, чтобы согласовать договор, постоянно исправляя пункты договора и обсуждая стоимость. А какое количество ресурсов было задействовано со стороны аналитики, разработки, безопасности и других.
Почему это проблема:
Неопределенность в начале проекта: На ранних этапах часто сложно полностью определить требования и детали проекта, что может привести к неправильным предположениям и ошибкам в планировании.
Замораживание требований: Попытка учесть все детали с самого начала может привести к желанию "заморозить" требования, что делает систему не способной к адаптации к изменениям. В ходе проекта очень сложно эти изменения производить, происходит цикл согласования Скоупа, стоимости и изменения договора.
Как следствие, это потеря большого количества времени на то, что потом все равно поменяется.
Так в одной компании мы несколько месяцев потратили на то, чтобы согласовать требования с вендором, хотя далее эти требования постоянно менялись и мы не меньше времени тратили на согласование.
2 проблема. Реализация по строму ТЗ
Проблема заключается в том, что при реализации по строгому ТЗ мы перестаем думать о результате, а думаем только о том, как выполнить ТЗ.
Я часто замечал, что в ходе реализации по строгому ТЗ люди перестают думать и совершают ошибки. Также единственной целью вендора становится успеть в срок и даже перестают думать о качестве. Так в одном проекте, когда срок подходил к концу, а много чего еще не было сделано, вендор просто напросто начать жертвовать качеством лишь бы сдать проект вовремя. А когда с стороны Заказчика начали проводить ревью кода, нашли очень много несовершенств и технического долга, который после сдачи проекта пришлось устранять затрачивая дополнительный бюджет.
Также вендор не знает специфику и реальные потребности Заказчика, поэтому разработка по ТЗ идет в лоб, и даже если там что то не учли, вряд ли про это спросит вендор, так как он не обладает полной картиной.
3. Взаимодействие между заказчиком, его командой и командой вендора
Взаимодействие Заказчика и его команды и Компании разработчика, часто выглядит как сложная машина в которой невозможно коммуницировать и быстро решать вопросы. Все очень формально, команды, как правило, находятся на расстоянии, коммуникации происходят долго и главное каждый несет ответственность за свой кусок, а когда нужно сделать вместе, все ломается и никто не хочет брать ответственность.
Всегда, когда решение которое делает вендор зависит от решений Заказчика, когда нужно плотно интегрировать и вместе тестировать решение, важна общая командная работа, иначе это превратиться в то, что каждый свой кусок сделал, а общего результата нет. А чтобы он получился, еще столько же времени нужно потратить на исправления и интеграцию.
Как работать по другому или гибкий подход к реализации проектов?
Во первых в любых проектах при реализации заказной разработки необходимо понимать три важных фактора:
Требования меняются
Невозможно учесть все на старте, поэтому обеспечьте в вашем контракте с вендором гибкость в договоре, чтобы требования можно было менять.
1.1. Здесь важно обеспечить гибкость как в контракте так и во взаимодействии
Виды контрактов
Самый легкий и гибкий - это Time and material, когда оплата производится за фактически отработанное время (дни команды). Здесь легко договориться о недельных или двухнедельных спринтах, точках планирования с вендором и обзора результатов, в ходе которого вы легко сможете планировать и менять требования на пути, а также регулярно сможете наблюдать прогресс по проекту.
Еще один вид контрактов - это когда мы не планируем весь проект целиком, а планируем и фиксируем объем работ только на итерацию (условно на 2 недели) и каждые две недели у нас есть прогнозируемый ожидаемый результат, на который коммитится вендор, и даже если он не выполнил объем работ, то это не снимает с него обязательств. В конце каждого спринта подписывается акт приема сдачи.
Также можно в договор прописать скоуп в виде пользовательских историй которые должны быть сделаны. В них должны быть указаны критерии приемки, чтобы однозначно понимать что планируется сделать и не было расхождений в понимании Заказчика и вендора. Пользовательская история с одной стороны описывает решение проблемы клиента, а с другой - вносит понимание что должно быть сделано с помощью критериев приемки.
1.2. Не забыть про нефункциональные требования
Важный нюанс в разработке - это нефункциональные требования, которые вендор должен выполнить, иначе без них у вас не заработает приложение или оно не будет соответствовать должному качеству.
Какие это виды требования:
Требования к тестированию и тестовым сценариям;
Требования к коду;
Требования безопасности системы;
Требования логирования;
Требования к документации;
и другие.
Базовые требования вы можете зафиксировать в контракте, те которые вы точно знаете что нужны. Остальные при условии гибких контрактов вы можете добавлять по ходу.
1.3. Определить Definition of done
Очень важный документ о котором все забывают и особенно важен при условиях гибкой разработки. Когда вы обсуждаете с вендором разработку по итерациям и приемку раз в итерацию, важно зафиксировать определение Готово (или definition of done). Иначе сложится ситуация, когда вам что то сделали, но должным образом не протестировали (например нагрузку) или качество кода не соответствует ожиданиям.
В Definition of done мы включаем все вещи необходимые для того, чтобы считать продукт или его часть готовыми.
Без этого артефакта вам будут отгружать полуготовое решение не пригодное к использованию и будет сложно прогнозировать завершение т.к. объем незавершенки будет расти каждый спринт, поэтому важно убедиться и зафиксировать базовые критерии definition of done в контракт и убедиться что они выполняются каждый спринт.
Договоритесь заранее с вендором о совместной работе как одна команда
Важно при взаимодействии с вендором убедиться, что команда вендора и команда заказчика работают вместе.
Есть несколько правил:
Единый чат для Заказчика и вендора где можно решать вопросы продукта и разработки;
Договоритесь о регулярных созвонах (дейли, планированиях, обзорах результатов);
Определите правила взаимодействия и проведите kick off проекта на старте с участием обеих сторон.
Выделите участников в команду проекта на 100%
Нужно убедиться, что участники с двух сторон и со стороны вендора, и со стороны Заказчика, выделены на 100% в проектную команду и не ведут в параллель несколько проектов, так как это пагубно влияет на скорость взаимодействия, фокусировку людей и качество решений. Я на практике проходил варианты, когда люди были выделены на 100% и когда специалисты вытаскивались на конкретные задачи. В первом случае уровень мотивации, понимания что мы делаем и фокусировки на задачи, во много раз повышался, что влияло на скорость взаимодействия, вовлеченность и в итоге на более качественные и быстрые результаты.
4 Обсудите процесс
Если вы хотите вести проекты по Agile в заказной разработке, тогда у вас должен быть выстроен процесс взаимодействия со всеми участниками в духе Agile:
Выстроите разработку продукта в итерациях в которых вся работа должна быть сделана (с учетом definition of done);
Убедитесь что есть Product owner который может принимать решения и приоритизировать беклог продукта;
Участники выделены в команду на 100% и у них есть все инструменты и полномочия чтобы реализовывать проект;
Обеспечьте быстрое взаимодействие с сервисными функциями. Например с теми, кто выдает доступы в компании, безопасностью. Тк часто при реализации проектов с вендором им нужно давать много доступов в ходе проекта и если это взаимодействие и быстрая реакция с сервисными функциями будет не налажена, то вы просто будете терять время на согласования. В идеале чтобы опять же в команду на проект были выделены люди которые смогут эти запросы быстро отрабатывать;
Поддерживайте культуру и ценности Agile, где во главу ставится заказчик и его потребности, желание сделать хорошо,а не просто выполнить в срок, получить деньги и уйти.
Выводы
Проблемы проектного подхода в заказной разработке давно известны и с ними сталкиваются 100% компаний. Вариант фиксирования стоимости, срока и бюджета возможен, если вы делаете что-то очень понятное с бизнес и технической точек зрения, где нет зависимостей с другими командами, в том числе. Как правило, это коробочные решения или простые сайты. Однако, если вы создаете продукты с нуля или даже части продуктов, такие как мобильные приложения, где есть бизнес-неопределенность, много технических нюансов и требуется взаимодействие нескольких команд, ведите проекты по Agile.
Те принципы, которые я описал выше, помогут вам получить более качественный продукт, иметь более прозрачную разработку и лучшее взаимодействие между сторонами. Да, здесь может сложится иллюзия того, что бюджет и скоуп менее предсказуемы, но так и в классической разработке они также не непредсказуемы. То, что вы их определили на старте и зафиксировали, совсем не означает, что оно в реальности будет таким. В 90% все идет не так.
Так в одном проекте, например, получив продукт с определенным скоупом и суммой, мы в итоге его переписали, так как получили много технического долга, и следующие 6 месяцев занимались отладкой, вместо того чтобы продолжать его развивать. В итоге потратили вдвое больше бюджета, если не больше. А в начале казолось все предсказуемо.
Поэтому, почему бы сразу не сделать все по-нормальному и не пойти гибким путем создания продукта, чтобы получить качественный результат за меньшие деньги?
Статья подготовлена в преддверии старта курса "Agile Project manager". По ссылке вы можете узнать о курсе подробнее, а также успеть записаться на ближайший поток.
Если вас заинтересовал подход, подписывайтесь на мой телеграм-канал, а также если нужна поддержка компании в выстраивании подобных процессов, обращайтесь.
