Как избежать проблем с аутсорсингом программного обеспечения

Аутсорсинг программного обеспечения - это катастрофа, ожидающая своего решения; мы все это знаем. Во-первых, вы обнаружите компанию, которая обещает вам все, что вы пожелаете: по времени и в рамках бюджета, высочайшее качество, красивый пользовательский интерфейс, передовые технологии и беспроблемную пожизненную поддержку. Итак, вы отправляете первый платеж, и ваше путешествие начинается. Команда почти не понимает ваши потребности, качество ужасное, все ваши сроки  и бюджетные ожидания серьезно нарушаются, и уровень разочарования стремительно растет. И «лучшая» часть заключается в том, что вы не можете уйти, иначе все деньги, которые вы потратили, будут уничтожены, и вам придется начинать с нуля. Вы должны оставаться «женатым» на этой команде, потому что вы не можете позволить себе «развод». Есть ли способ сделать аутсорсинг программного обеспечения безопасным?

Да, это возможно сделать и действительно без проблем, но вы должны быть готовы извратить свою философию управления.

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

Я узнал этот принцип от Вэй Ляо Цзы. Он сказал, в соответствии с Классикой военной стратегии Древнего Китая, с.239:

Когда информация снизу достигает высокого уровня, а проблемы высокого уровня проникают вниз, это самая идеальная ситуация

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

Они проделали большую работу, вы заплатили много денег, но готового к продаже продукта еще нет. 

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

Давайте забудем об этих прекрасных обещаниях и сосредоточимся на уродливой реальности.

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

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

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

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

Помня принцип, о котором я упомянул выше, вот моя рекомендация: Удостоверьтесь, что команда понимает 1) ваши ограничения по времени, стоимости и сфере действия и 2) последствия их нарушения. Это касается первой части принципа: вы должны открыто и часто сообщать свои проблемы. Обычно происходит так, что команда аутсорсинга не знает реальной деловой ситуации и слышит «Мне нужно это как можно скорее» каждый день.

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

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

Вот как может звучать правильное ограничение времени и затрат:

Функции A, B и D должны быть готовы до
Первого июня, потому что наш маркетинг
Кампания начинается с пятого июня. Если
У нас их нет, я потеряю 25 000 долларов
В маркетинговых расходах. Если это произойдет, мне
придется сократить ежемесячный бюджет развития
на половину.

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

Вы теряете уважение, и они начинают относиться к вам как к дойной корове

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

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

Зачем вам это нужно к первому июня? Почему вы хотите потратить менее 50 000 долларов? Зачем вам нужны все пять функций в версии 1.0? Почему вы хотите, чтобы ваше веб-приложение было готово к работе с 1K параллельными сеансами? Зачем вам нужно мобильное приложение в первом выпуске?

Ответьте сами и убедитесь, что ваши ответы понятны аутсорсинговой компании. Не скрывайте эту информацию.

Продукт настолько неуклюж

Вы хотите, чтобы ваше веб-приложение выглядело как Pinterest, реагировало быстро, было легко использовать, и вы гордитесь, когда показываете его своим друзьям. Но продукт, который они создали для вас, неуклюж, медленен, и, честно говоря, уродлив. Вы просите их что-то сделать, и они продолжают давать вам обещания. Проект продолжает потреблять ваши деньги, и его бюджет растет, но внешний вид не улучшается. Это далеко от Pinterest, очень далеко. Разочарование растет, и вы не видите какой-либо разумный выход из этого. Единственный совет, который вы получаете от своих друзей, - это повторить все с нуля с помощью новой команды веб-разработчиков. Как это звучит? Бьюсь об заклад, это знакомо.

Мы призываем спонсоров проекта быть пессимистами и негативно оценивать наше качество

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

Опять же, имея в виду принцип вековой давности, я бы рекомендовал, чтобы с первого дня проекта вы установили рутинную процедуру проверки их результатов и выражения своих опасений. В наших проектах на Teamed.io мы просим наших клиентов присутствовать в GitHub, часто просматривать наши релизы и сообщать о любых несоответствиях, обнаруженных как проблемы GitHub. Мы призываем спонсоров проекта быть пессимистичными и негативными относительно нашего качества с самого начала проекта. Мы понимаем, что это то, как мы можем свести к минимуму риск «сложенного разочарования».

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

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

Я не могу положиться на их обещания

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

Команда боится вас, и для того, чтобы держать вас на борту в качестве платежеспособного клиента, вам придется солгать

По моему опыту, эта непредсказуемость и ненадежность команды аутсорсинга программного обеспечения в большинстве случаев вызвана самим спонсором проекта. Это происходит, когда вы не слушаете их, или они боятся сказать вам правду, что обычно одно и то же. Некоторые называют это «управляемым страхом развитием». Команда боится вас, и для того, чтобы держать вас на борту в качестве платежеспособного клиента, вам придется врать.

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

Если вы вознаграждаете свою команду, когда они делают вас счастливыми с хорошими новостями, вы обучаете их лгать вам

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

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

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

Вот практическая рекомендация. Во-первых, регулярно сообщайте о своих разумных целях и ограничениях, как я объяснил выше. Убедитесь, что команда понимает ваши бизнес-планы и причины «почему». Во-вторых, регулярно спрашивайте членов команды о рисках и проблемах. Спросите их, почему они считают, что цели проекта могут быть скомпрометированы. Более того, пусть они регулярно документируют риски и сообщают о них вам. Вознаградите их за честность в этом списке рисков.

Попробуйте, и вы будете удивлены тем, сколько интересных вещей будет содержать список рисков.