Продакт-оунер в аутсорсинге

Автор: Александр Якима (www.enter-agile.com)


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


В аутсорсинге отношение "Команда - Продакт-оунер" накладываются на отношение "Поставщик - Заказчик" и эти форматы отношений во многом сущесвенно влияют друг на друга.

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

Здесь сразу хочу упредить душевное расстройство всех аутсорсинг-менеджеров и в особенности сейлов: мы не говорим здесь о модели staff extension (или как ее еще называют - staff augmentation). Эта модель лишена смысла с точки зрения Agile. Речь не идет о том, чтобы возвращаться к ненавистному "бади-шопу", от которого только-вот придумали как уйти с помощью новомодных (хотя и весьма порочных) парадигм, нет... Успешный Agile-аутсорсинг может работать только если agile-команды будут целостны и самодостаточны на стороне вендора, за исключением П-О. Вот это "маленькое исключение" как раз и определяет характер сервиса.

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

1. Доверия априори нет, заслужить всегда сложно. Именно потому, что Agile не может жить без доверия между Продакт-оунером и Командой этот пункт мы выносим на первое место. При этом часто и заказчик и вендор делают все против правил, удаляясь от желаемого результата. В основном либо потому, что заказчик пытается предохраняться где нужно и где нет - фиксировать скоуп, требовать четких коммитментов, там где это не представляется возможным, обложиться метриками и SLA-соглашениями, полагая, наверное, что юридически весомые документы умеют сами анализировать требования, писать и тестировать код... С другой стороны вендоры - вместо того, чтобы убирать барьеры, очень часто их создают под сладким соусом самоуправляемости, независимости и соблазнительной идеи маркетировать себя как поставщика black-box сервиса, где заказчику неочем беспокоиться на ежедневном уровне, а только перебросить через кирпичную стенку требования, а оттуда со временем назад вылетит "потенциально доставляемый инкремент" (сложно, наверное, подыскать более ироничное применение акронима PSI)...

2. Продакт-оунершип как хобби. Это встречается в аутсорсинге весьма часто... к сожалению. Продакт-оунер - это ключевая роль в гибкой разработке. Самая важная! Неправильно полагать, что: была бы хоть команда разработчиков - и уже можно что-то делать... Без хорошего продакт-оунера проектная работа обречена (либо на коллапс, либо на влачение жалкого существования). То, что часто происходит в действительности, не перестает удивлять - в качестве промоушена самому выдающемуся разработчику со стороны заказчика вверяют аутсорсинговую команду... при этом он остается занят разработкой и не имея малейших подозрений о том, почему важно в первую очередь выполнять роль П-О, переносит на два дня демо итерации, потому что он должен что-то там доразработать, дофиксать, а потом наступит и черед вернуться к agile-каденции ввереной ему команды...

3. Ревенью важнее методологии. Так считает практически любая компания-поставщик, это диктуется ее основными бизнес-инстинктами. Это тот случай, когда инстинктами должен управлять разум. Очень часто аутсорсинг-вендор и знает что нужно бы в процессе поменять, но видя малейшее противление со стороны заказчика, сворачивает все "излишне нервирующие" темы и просто продолжает работать как есть. Опять, же - проще сказать, чем сделать... это правда. Все три приведенных примера исходят из самой сущности аутсорсинг-разработки и поэтому очень сложно устранимы. Но пункт 3 наиболее сложен, так как еще и противоречит общепринятому "заказчик всегда прав..."

Теперь несколько фраз о способах решения этих сложностей.

Что касается №1, то тут вопрос скорее отношения к собственному бизнесу, чем объективная проблематика. Иными словами, аутсорсинг-компаниям, конечно необходимо как-то обосновывать высокие рейты (по сравнению с другими), однако делать это можно по-разному. По крайней мере без резких противоречий с ключевыми принципами и ценностями Agile. Это становится особенно четко видно, когда "продается" услуга заманчиво называемая "Agile Fixed Price" или "Agile Managed Delivery" или как-то еще с одним и тем же подтекстом - Agile с минимальной тратой времени Продакт-оунера - но это нонсенс. Наоборот, разумный аутсорсинг-вендор увидит тут конкуррентное преимущетво по сравнению с "недоучками", предлагая то, что на самом деле будет работать и послужит хорошим бизнес-кейсом, подспорьем для приобретения новых клиентов в будущем - модель которая максимально сближает П-О и Команду, не ставит лишних барьеров. Это отдельная большая тема, в текущем посте же только скажу, что в какие бы юридические и маркетинговые обертки не был облачен проект, если П-О не будет "знать всех своих разработчиков в лицо" в полном смысле фразы, то надо помнить, что тогда не только Agile невозможен, но и отказаться от такого "черного ящика" П-О будет всегда очень легко. Подумайте на секунду, слышали ли вы много случаев противоположных, чтобы в продуктовой компании П-О уволил всю (!) свою команду? В аутсорсинге это случается сравнительно часто. Повод для раздумий, не так ли?..

№2 решается всегда непросто. Если удастся (и если есть кому), то нужно такого П-О постепенно "обучать". Не нужно сильно комплексовать из-за того, что это заказчик. Если делать все аккуратно, никто не заметит, что это по сути образовательный процесс. Хуже, если П-О страдает существенной упертостью, бывает и такое. Придется тогда тратить больше времени на "логирование проблем и сбор фактажа", которые время от времени в ходе ретроспектив необходимо будет своему П-О в очень корректной форме предоставлять. Вода камень точит...

№3 - исходит полностью из культуры компании, поэтому тут совет двоякий. Во-первых, тем, кто на эту культуру сильно влияет исходя из своего заоблачного служебного положения - помнить всегда о том, что именно мега-успешные Agile проекты приносят дивиденды в виде лояльных заказчиков, творчески заряженных сотрудников, и много buzz'а вокруг компании о том, как здесь умеют делать software. Тем же от кого зависит хотя бы ситуация на проекте и кто хочет эту проблему разрешить - наберитесь терпения и все-таки постепенно добивайтесь процессных изменений. Каждый успешный шажок - аргумент для вашего менеджмента, что вы поступаете правильно. Ваша мотивация - шанс стать проводником изменений во всей компании по уже известному вам паттерну, когда наступит время. Поверьте, у вас в этом почти не будет конкуррентов...

No comments:

Post a Comment

 
Powered by Blogger