Scrum при работе на заказ

Буквально на прошлой неделе мне звонила не безызвестная в моем городе компания Axmor и спрашивала ищу ли я работу скрам мастером. Когда начала выяснять для чего оно им, оказалось, что для внутреннего продукта. На вопрос, почему они не используют таких людей для работы во внешних проектах, мне ответили, что это невозможно. На мой взгляд, Agile-контракты вполне реальны даже не в продуктовой компании. Давайте посмотрим, что может мешать переводить внешнюю разработку на scrum?

Scrum это дорого

Если при обычном подходе во взаимодействии с заказчиком участвует только PM, а остальные “делом” заняты и работают, то в scrum общаться с заказчиком будут все! Если PM потратит на встречу 1 час, то команда потратит 1 час*количество членов команды. Очень часто именно экономическое обоснование останавливает от перехода на фреймворк.

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

Двойная работа

Лень объяснять про плюсы scrum

Почему большинство продуктов сейчас пока создается по водопаду? Потому что люди не знают, что можно по-другому и никто им это не объясняет. Ведь куда легче взять готовое ТЗ, оценить, умножить на два, закрыв свои риски таким образом, и начать делать. Чем возиться с заказчиком и объяснять ему все тонкости и пользы другого подхода. А польза будет в первую очередь заказчику! Это занимает некоторое время и обычно, не маленькое! Когда я была обычным PM и пришла на тренинг по Scrum, где мы играли Video Scrum, я была шокирована: “Кааак, в первом спринте не нужен сценарий ролика, а уже нужно видео?! Кааак это сделать за такое короткое время?!” И потом наступило прозрение 🙂

Вот буквально вчера я проводила Митап с Lego Scrum и пыталась донести до аудитории суть в основном не в увеличенной скорости разработки, основное отличие в том, что вы начинаете раньше доносить ценность до своего пользователя, зарабатывать раньше и уменьшать общий риск ошибки продукта. С водопадом вы донесете ценность только через год, а обратную связь получите, наверное, через 1,5. И в результате вообще сделаете около 60% работы в стол, потому что рынку за год уже понадобится другое.

Лень воспитывать владельцев продуктов

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

cueeigpxyaahwlr
если у вас U-образная форма присутствия владельца продукта, то у вас проблемы

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

Agile-контракты

Это штука непростая, потому что здесь должна быть некоторая степень доверия между вами и заказчиком. При классическом подходе мы чуть ли не перемножаем основную оценку разработки в 2, а то и в 3 раза, чтобы в случае внезапно возникших рисков они были покрыты.То есть риск в основном на компании-разработчике, поэтому получается фиксированная цена и список фич.

Другой полюс всего этого безобразия, это когда риски полностью лежат на заказчике, а разработчики получают безлимитный бюджет, т.е. time & material, и работают со скоростью ленивых морских котиков. Только в очень длительных отношениях возможно такое взаимодействие или в очень серьезных технически-сложных проектах.

Agile говорит, что на самом деле можно найти компромисс и у нас есть третье решение, оно в плоскости где-то между первым и вторым. Что нужно сделать, просто не фиксировать все три точки классических проектов: фичи, сроки и бюджет. А зафиксировать только 2, которые чаще всего важны бизнесу – это сроки и бюджет. Дальше, объяснить, что у нас нет сейчас никаких адекватных объяснений, что рынок ждет все твои фичи из ТЗ, которые ты там принес. Это могут быть галлюцинации, которые на самом деле нужно проверять. Приоритезируем их в порядке важности для пользователя и начинаем планомерно разрабатывать, обозначая себе несколько релизов по пути.

csm_agile_en_976fe518e8

Это и будет тот спасительный процесс, который избавит заказчиков от кучи ненужных функций, потраченных зря бюджетов и незаинтересованных глаз команды. Если вы сможете притаскивать в команду периодически реальных пользователей, которые будут говорить что им нравится и что бы они улучшили, потому что неудобно, это будет вообще класс. Чтобы не получилось, как ниже на картинке..

kak-sozdavali-tehnicheskoe-zadanie

Advertisements