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