Непонимание заказчиком ответственности за надлежащую коммуникацию с разработчиками, и наоборот – ожидание у разработчиков инициативы со стороны бизнеса по обеспечению команды всем необходимым – порождает серьезные дорогостоящие проблемы обеим сторонам. Современный скрам-подход как раз решает эту дилемму. Слава Москаленко объясняет, как именно.

Проблема

Одна из самых острых проблем во взаимоотношениях между заказчиками и разработчиками – это недостаток коммуникации, вследствие чего возникает ряд угроз:

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

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

Семь сфер скрам-команды

В последнее время скрам-подход сделал шаг вперед и стал еще ближе к бизнесу. В официальном руководстве “Скрам” (Scrum Guide 2020) сказано о семи сферах ответственности скрам-команды:

Взаимодействие со стейкхолдерами.
Верификация.
Поддержка.
Операционная деятельность.
Экспериментальная деятельность.
Исследовательская деятельность.
Разработка (а также любая другая деятельность, помогающая достичь цели разработки).

Проблема, которую мы раскрываем в этой статье, касается первого пункта в списке – взаимодействие со стейкхолдерами. Это предполагает такие черты скрам-команды:

интегрированность (и внутреннюю – деятельность разработчиков, тестировщиков, аналитиков и др. интегрированная между собой, и внешнюю – деятельность команды не является “аппендиксом” в организации, а интегрированная в ее бизнес)
целостность (кроссфункциональность, автономность, ответственность каждого участника);
компетентность (каждый участник команды, в частности, и команда в целом выполняют четко очерченные роли и обязанности).

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

Симптом козла отпущения

Скрам-команда и стейкхолдеры: как повысить производительность современной разработки? 1

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

Симптом козла отпущения на самом деле опасен, ведь свидетельствует о низком уровне ответственности и зрелости скрам-команды. Не стоит рассчитывать на высокий результат.

Говоря о “шаге вперед” и развитии скрама, я имею в виду, что:

Современный Scrum осознает эту проблему.
Современный Scrum имеет для нее решения.

Решение заключается в смещении акцента с одной роли (например, владельца продукта) в сторону ответственности со стороны всей команды. Это предполагает уменьшение вредной зависимости от одной персоны и помогает ускорить разработку.

Звучит удивительно просто, однако реализовать переход от поисков “крайнего”, “виноватого”, “козла отпущения” до командной ответственности – крайне непросто. Чтобы этого достичь, команда должна быть зрелой, и скрам-мастер должен вырастить ее до такого уровня (см. перечень рекомендуемых статей на эту тему в конце статьи).

Стейкхолдеры

Кто такие стейкхолдеры? В контексте разработки IT-продукта – все, кого она касается.

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

Проблема гармоничных отношений со стейкхолдерами

Скрам-команда и стейкхолдеры: как повысить производительность современной разработки? 2

У каждого подразделения компании своя специфика, поэтому в корне взаимодействия между ними заложен определенный конфликт. Для того, чтобы достичь цели разработки (product goal), современный скрам ставит задачу – достичь гармонии в этом взаимодействии.

На построение гармоничных отношений могут в большей степени влиять одни, а не другие участники разработки. Например, владелец продукта, скрам-мастер или эксперт. Естественным образом возникают:

зависимость от такой фигуры;
угроза токсичности (за достижения всей команды хвалят друга “любимца публики”, что вызывает зависть, чувство несправедливости и демотивовуе команду).

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

Кто и как должен решить проблему взаимоотношений со стейкхолдерами

Мы уже выяснили, что уповать на отдельное лицо (например, владельца продукта) в этом вопросе – ложный и устаревший путь.

Современный Scrum настаивает на усилении роли скрам-команды. Соответственно, “взаимодействие со стейкхолдерами” стоит первым пунктом в перечне сфер ответственности скрам-команды в официальных постулатах Скара.

Следовательно, именно самоорганизованная скрам-команда отвечает за формирование гармоничных отношений со стейкхолдерами.

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

Черный ящик

Скрам-команда и стейкхолдеры: как повысить производительность современной разработки? 3

Но как именно “команда отвечает”? Scrum сознательно оставляет эту мистику команде. Проиллюстрируем это примером “черного ящика”.

На входе имеем ряд задач, которые необходимо выполнить. На выходе – желаемый результат. Посередине – черный ящик. Когда результат удовлетворяет или превышает ожидания всех сторон – никого не волнует, что внутри “ящика”.

Футбол

Проведем параллель с футболом. Нападавшие забивают голы и поэтому первыми получают венец славы. Несмотря на это, в интервью журналистам они часто уверяют: “Победа – заслуга не моя, а всей команды”. Если бы не пас полузащитника, нападающий не смог бы реализовать голевой момент. Если бы не защитники и вратарь – команда пропустила бы кучу голов и не смогла выиграть. Нечто похожее происходит и в работе скрам-команды.

Примеры из практики

Два этажа

Компания имела собственные IT-платформы и свой штат разработчиков. Программисты комфортно расположились в прозрачной зале на 24-м этаже небоскреба, в то время как бизнесмены на 25-м.

Представители бизнеса системно требовали от “айтишников” выполнить то или иное задание и не всегда получали ожидаемый результат, вследствие чего сформировали негативное отношение к коллегам. Это породило нездоровый климат в компании и плохо влияло на результаты. (Такую же проблему с отношением бизнеса к IT я наблюдал и в случае аутсорса!) Двадцать пятый этаж откровенно презирал жителей двадцать четвёртого, которые чувствовали себя ненадежными! О какой мотивации могла идти речь?

Руководство компании пригласило меня внедрить Scrum в один из проектов разработки.

Скрам-команда и стейкхолдеры: как повысить производительность современной разработки? 4

Первое, что я сделал, это попросил компанию привлечь к нашей команде владельца продукта, который будет представлять интересы всей компании, и переселить его с 25-го (где были представители бизнеса) на 24-й (в число айтишников). На основе скрам-модели я сформировал новую скрам-команду.

Пребывание представителя бизнеса (Product Owner) в самой сердцевине создания продукта помогло устранить множество препятствий, собрать ценные сведения, донести важную информацию до стейкхолдеров.

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

Чтобы достичь желаемого результата, как скрам-мастер я убедился в том, что:

Все участники скрам-команды понимают ожидания стейкхолдеров;
Изменен стиль коммуникации на ненасильственный (существует уважение к коллегам, недопустим тексичний стиль общения – высокомерный, низкий или даже наглый)
Стейкхолдеры поняли ожидания со стороны команды разработчиков и начали взаимодействовать (оперативно предоставлять необходимые сведения, объяснять и т.д.).

Тандем

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

Мы сформировали целостную скрам-команду. Со стороны заказчика получили замечательного представителя (владельца продукта). Как скрам-мастер я сделал все со своей стороны, чтобы обеспечить команду всем необходимым для разработки, и сформировать ее как интегрированную (все участники разработки – программисты, тестировщики, аналитики и др. – функционировали как единый организм).

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

Скрам-команда и стейкхолдеры: как повысить производительность современной разработки? 5

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

Мы просто были честными, откровенными и открытыми к поиску оптимальных решений. Так вместе с командой мы пришли к согласию, что лучшее решение – включить еще одного эксперта, который также будет представлять банк (заказчика), сотрудничать с командой и как инсайдер предоставлять ей все необходимые сведения по разработке.

Таким образом, владелец продукта обеспечил качественную коммуникацию с конечными потребителями, а также с руководством компании, в то время как отдельный эксперт предоставлял основательные сведения о работе компании или специфики отрасли. Вышел успешный тандем со стороны двух представителей бизнеса.
Благодаря такому тандему мы успешно достигли гармоничных отношений с заказчиком и цели продукта (product goal).

Стоит заметить, что команда со своей стороны также сработала профессионально – вела себя проактивно, задавала все вопросы, необходимые для того, чтобы лучше понять ожидания и требования заказчика, и чтобы “тандему” были понятны потребности разработчиков.

Без “тандема”, вероятно, никто не взял бы ответственности на себя, по старой привычке обвиняя владельца продукта. Зато результат порадовал всех:

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

ВЫВОДЫ

Развитие Scrum еще больше удовлетворяет потребности современного бизнеса благодаря эмпирически доказанному подходу по функционированию скрам-команд.
Менеджерам необходимо осознать свою ответственность за формирование гармоничных отношений с разработчиками, предоставляя им необходимую информацию и специалистов, которые помогут устранить бюрократические и другие препятствия на пути создания продукта.
Участникам разработки необходимо вырасти в зрелую и интегрированную команду (где интегрированы и внутренние, и внешние сферы деятельности), которая способна самостоятельно решать проблемы для выполнения продуктовой цели.