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

Обычно люди не хотят меняться. Им очень нравится оставаться в своей зоне комфорта, даже если нахождение в ней не приносит позитивных результатов. Меняться и пробовать что-то новое сопряжено с рисками и требует дополнительных усилий и вложений. Поэтому проще всего найти оправдания почему мы НЕ МОЖЕМ МЕНЯТЬСЯ. В мире аутсорсинга таким оправданием становятся фразы наподобие: “никто на нашем рынке так не работает”, “клиент никогда не пойдет на такой способ работы”, “гибкие методологии неприменимы в нашем контексте”, “у нас нет вообще доступа к заказчику”…

Клиент не пойдет на такой способ работы? Да только потому, что он никогда не видел успешного деливери продукта от таких олдскульных “горе-вендоров”. Именно поэтому клиент заранее пытается перекрыть свои риски и получить элемент влияния на вас в виде fixed-price контракта. Чтобы можно было нагибать вас в любой момент и заставлять таки сделать свою работу, в которой вы заявили себя профессионалом, а по факту делаете все через одно место. Они тоже научены горьким опытом работы с такими вендорами и проваленными многомиллионными проектами.

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

“Если вы, как вендор, не умеете выпускать рабочий продукт с регулярностью от нескольких дней до пары недель — вы занимаетесь не тем бизнесом. Вы дилетант и прохвост. Go back to school. Никакие контракты вас не спасут. Учитесь (это долго). Ну или же наймите трёх толковых программистов (не больше), каждого со стажем и знанием как минимум трёх различных платформ (вам нужны широкопрофильщики) и избавьтесь от всего остального «балласта». Некоторые программисты в десятки раз более продуктивны других (как следствие, другие в десятки раз менее продуктивны). Вдумайтесь в эти цифры. Поэтому на деле закладка никаких коэффициентов и буферов в бюджеты и сроки не помогает.”

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

• ваш прогресс в виде работающего продукта;
• ваше желание снизить риски за счет правильной приоритезации функциональности;
• ваше постоянное стремление разобраться в бизнесе клиента и попытки сделать его успешнее, а не просто реализовать все юзкейсы, которые только смогли придумать наши бизнес-аналитики или SME клиента;
• вашу прозрачность в принятии решений и финансовой отчетности;
• вашу заботу о будущем продукта после его сдачи в эксплуатацию и поддержку…

Я затрагивал эту тему в описании отличий между классическим PM и Agile менеджером в отдельной статье.

Гибкие методологии неприменимы в вашем контексте? А что в вашем контексте такого удивительного? Бизнес домен? Распределенная команда? Строгий клиент, который экономит каждую копейку? Наличие внешних регуляторов на рынке? Спешу вас расстроить: вы сможете без особого труда отыскать на рынке успешные примеры разработки продуктов практически в любом бизнес домене, с различной степенью распределенности команды и совершенно с разными по уровню строгости клиентами. Вопрос в другом: они не все будут иметь одинаковый скопированный под копирку процесс разработки. Именно поэтому методологии и называются гибкими, они способны и должны адаптироваться под внешние ограничения, но при этом оставаясь в рамках тех же принципов и ценностей. Поэтому изначальный вопрос я бы перефразировал как “мы не умеем строить или адаптировать гибкие методологии под наш контекст”. А это уже снова вопрос компетентности, опыта и знаний.

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

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

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