The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Аутсорсинг программного обеспечения - это бедствие, которое ждет своего часа; мы все знаем об этом. Сначала вы находите компанию, которая обещает вам все, что вы могли бы пожелать от продукта - доставку в срок и в рамках бюджета, высочайшее качество, красивый пользовательский интерфейс, передовые технологии и беззаботную пожизненную поддержку. Вы отправляете первый платеж, и ваше путешествие начинается. Команда едва понимает ваши потребности, качество ужасное, все ваши ожидания по времени и бюджету серьезно нарушены, а уровень разочарования растет стремительно. И “лучшее” в этом всем - вы не можете отказаться, иначе все деньги, которые вы потратили до сих пор, пропадут, и вам придется начинать с чистого листа. Вам приходится оставаться “в браке” с этой командой, потому что вы не можете позволить себе “развод”. Есть ли способ правильно делать аутсорсинг программного обеспечения?
Да, это возможно сделать правильно и без лишних хлопот, но вам придется быть готовым изменить свою философию управления.
Основной фундаментальный принцип здесь заключается в том, что 1) вы должны открыто и часто общаться со своей аутсорсинговой командой о своих опасениях, и 2) они должны открыто и часто общаться с вами о рисках и проблемах. Это два основных фактора успеха в аутсорсинге программного обеспечения, которые очень часто пренебрегаются.
Этот принцип я узнал от Вэй Ляоцзы. Он сказал, согласно “Классическим военным стратегиям Древнего Китая”, стр. 239.
Позвольте мне продемонстрировать несколько практических примеров катастроф, связанных с аутсорсингом программного обеспечения, и объяснить, как их можно избежать, если следовать указанному двухтысячелетнему принципу.
Всегда остается 95 процентов готовности, и всегда есть что-то, что не реализовано или не работает. Они проделали много работы, вы заплатили много денег, но готовый к выходу на рынок продукт пока не существует. Это занимает недели и месяцы; в списке ожидания всегда что-то есть, и вы просто не можете закончить это. Вы начинаете видеть этот проект в своих кошмарах, и Прозак уже не помогает. Как звучит? Знакомо?
Я надеюсь, вы понимаете, что независимо от того, какой контракт вы заключили с вашим партнером по аутсорсингу программного обеспечения, сколько графиков вы установили или сколько обещаний было сделано, они хотят сохранить вас в качестве клиента навсегда. Ну, пока у вас есть деньги на счету.
Вы хотите, чтобы ваш бизнес преуспевал и процветал, верно? Они хотят того же для своего бизнеса. Ваш успех означает готовый и запущенный продукт для конечных пользователей. Их успех означает бесконечный процесс написания программного обеспечения для вас. У этих двух целей очень мало общего. Я бы даже сказал, что они противоречат друг другу - когда вы успешны, они проваливаются.
Конечно, они скажут вам, что хотят закончить этот продукт для вас и получить новые контракты в будущем. Они скажут, что их основная мотивация - сделать вас счастливым и получить хорошую рекомендацию. Они заверят вас, что удовлетворенность клиентов важнее денег. Однако я советую вам быть достаточно сильным, чтобы встретиться с реальностью - это все ложь.
Большинство проектов по аутсорсингу программного обеспечения проваливаются. Очень большинство (смотрите последний отчет CHAOS). Разработчики программного обеспечения понимают это лучше вас, преимущественно потому, что они видят, как это происходит каждый день. И ваш проект не является исключением. Так что давайте забудем о этих красивых обещаниях и сосредоточимся на уродливой реальности - вы остаетесь один на один.
Исходя из принципа, о котором я упомянул выше, вот мое рекомендация: убедитесь, что команда понимает 1) ваши реальные ограничения по времени, стоимости и объему работ и 2) последствия их нарушения. Это касается первой части принципа - вы должны открыто и часто общаться о ваших опасениях. Обычно случается так, что команда аутсорсинга не осведомлена о реальной деловой ситуации и слышит только “мне это нужно как можно скорее” каждый второй день.
“Как можно скорее” - это не срок. Более того, это очень демотивирующая замена реалистическому этапу. Когда команда не знает, когда именно вам нужен продукт, что именно должно быть готово к этой дате, и почему, она начинает работать против вас. Здесь акцент делается на “почему”. Для большинства бизнес-владельцев трудно ответить на этот вопрос.
Зачем вам нужно, чтобы продукт был готов к первому июня? Просто потому, что вам надоело ждать? Это не разумный ответ. Вам надоело, но у вас все еще есть деньги на счету. Они будут продолжать выставлять вам счета, и не будут уважать вас. Они не будут относиться к вам как к сильному и целеустремленному бизнес-персоне. Вы либо не достаточно умны, чтобы определить свои временные ограничения, либо скрываете их от команды. В любом случае, они не оценят такое поведение.
Вот как может звучать правильно определенное временное и стоимостное ограничение:
Когда компания по аутсорсингу программного обеспечения, ваш партнер, слышит такое определение срока, она становится вашим настоящим партнером. Теперь ее цели совпадают с вашими. Если пропущен веховой момент, вы пострадаете, и они понимают, как именно. Кроме того, они видят, как ваше страдание также перенесется на их плечи.
Перестаньте просить их закончить все как можно скорее. Прекратите звонить им дважды в день и кричать час о их плохой работе. Прекратите использовать язык в деловых электронных письмах. Прекратите всю эту шумиху. Это все равно вам не помогает. Более того, это только ухудшает ситуацию, потому что вы теряете уважение, и они начинают относиться к вам как к дойной корове - довольно глупой и эмоциональной.
Вместо этого, сделайте свою домашнюю работу и определите свои реалистичные вехи. Подумайте о ваших реальных ограничениях по времени, объему и бюджету. Запишите их в очень короткие и лаконичные предложения. Убедитесь, что ваши ограничения реалистичны, и их описания отвечают на главный вопрос - “почему”.
Зачем вам это нужно к первому июня? Зачем вам хочется потратить менее 50 000 долларов? Зачем вам нужно, чтобы все пять функций были в версии 1.0? Зачем вам нужно, чтобы ваше веб-приложение было готово к обработке 1 тысячи одновременных сеансов? Зачем вам нужно мобильное приложение в первом релизе?
Ответьте себе и убедитесь, что ваш ответ понятен компании по аутсорсингу. Не скрывайте эту информацию.
Вы хотите, чтобы ваше веб-приложение выглядело как Pinterest, было быстрым, простым в использовании и вызывало гордость, когда вы показываете его своим друзьям. Но продукт, который они создали для вас, неуклюжий, медленный и, честно говоря, уродливый. Вы просите их что-то сделать с этим, но они продолжают давать вам обещания. Проект постоянно поглощает ваши деньги, а его бюджет только растет, но внешний вид и ощущение не улучшаются. Он очень далек от Pinterest, очень далек. Растет разочарование, и вы не видите никакого разумного выхода из этой ситуации. Единственный совет, который вы получаете от своих друзей, - пересоздать все с самого начала с новой командой разработчиков веб-сайтов. Как это звучит? Я уверен, что это знакомо.
Я считаю, что коренная причина этой тупиковой ситуации - страх конфликта. На ранних стадиях проекта вы пытаетесь сделать все возможное, чтобы поддерживать хорошие отношения с аутсорсинговой компанией и не обидеть никого. Вы не хотите контролировать работу кого-либо, потому что они могут воспринять это как оскорбление. Вы не хотите высказывать свои опасения по качеству, потому что они могут разочаровать команду. Вы просто надеетесь, что они улучшат продукт в будущем, но когда наступает будущее, уже поздно.
Опять же, помня о древнем принципе, я рекомендую, чтобы с первого дня проекта вы установили регулярную процедуру проверки результатов и выражения своих опасений. В наших проектах в Zerocracy мы просим наших клиентов присутствовать в GitHub, часто проверять наши релизы и сообщать о любых несоответствиях в качестве проблем GitHub. Мы призываем спонсоров проектов быть пессимистичными и негативными по отношению к нашему качеству уже с самого начала проекта. Мы понимаем, что таким образом мы можем минимизировать риск «накопленного разочарования».
Попробуйте сделать то же самое в своем проекте, который аутсорсится разработчику из-за рубежа. Не бойтесь их обидеть. Итеративная и инкрементальная критика - это гораздо более здоровый подход, чем отсутствие обратной связи, которая заканчивается войной. Найдите способ регулярно информировать вашу команду разработчиков об вашем мнении о их результатах. Не старайтесь быть милыми, чтобы сохранить проект. Вы делаете себе дурную услугу. Вместо этого, откройтесь по поводу ваших опасений. Помните первую часть вышеуказанного принципа - вы должны открыто и часто выражать свои опасения. Именно так вы стабилизируете проект и минимизируете риски.
Кроме того, очень хорошей практикой является время от времени приглашать технических рецензентов для получения независимых мнений о разрабатываемом продукте. Прочитайте мою другую публикацию на эту тему: Вам действительно нужны независимые технические рецензии!.
Вы звоните им, составляете планы, объявляете вехи, определяете функции, устанавливаете приоритеты, договариваетесь о качестве и потом кладете трубку. Через несколько дней вы понимаете, что это была полная трата времени. Они не выполняют свои обещания, потому что всегда происходит что-то новое. Кто-то заболел, сервер сломался, какое-то программное обеспечение оказалось неработоспособным, код больше не работает и так далее. Вы снова звоните, выражаете свое недовольство, делаете резкие обвинения, перестраиваете вехи, переопределяете функции, сбрасываете приоритеты и через несколько дней начинаете все сначала. Было такое, правда? Знакомо?
По моему опыту, эта непредсказуемость и ненадежность команды по разработке программного обеспечения в большинстве случаев вызвана самим спонсором проекта. Это происходит, когда вы не слушаете их или они боятся сказать вам правду, что, как правило, одно и то же. Некоторые называют это “разработкой, основанной на страхе.” Команда боится вас, и чтобы сохранить вас как платящего клиента, они вынуждены лгать вам.
По сути, они говорят вам то, что вы хотите услышать - что конец проекта близок, что текущие ошибки легко исправить, что проблемы с производительностью незначительные, что качество архитектуры выдающееся и что команда очень мотивирована работать с вами. Когда вы слышите что-либо из перечисленного, задайте себе вопрос - Вы поощряете их говорить правду? Вы вознаграждаете их за то, что они приносят вам плохие, но честные новости?
Еще раз, ссылаясь на основной принцип, упомянутый выше, я рекомендую убедиться, что ваши мотивы для наград и наказаний прозрачны для вашего партнера по разработке программного обеспечения и основаны на целях проекта, а не на ваших личных эмоциях.
В одном из моих предыдущих постов я писал, что счастливый клиент - ложная цель для команды разработки программного обеспечения. Клиент, который продвигает эту цель, является ужасным клиентом, который обречен на провал проекта. Если вы вознаграждаете свою команду, когда они делают вас счастливыми хорошими новостями, вы учите их лгать вам. Если вы ожидаете от них только хороших новостей, вы убиваете в них желание говорить правду и делать то, что хорошо для проекта, а не для вас лично.
Вы заставляете их не спорить с вами. Другими словами, вы подавляете поток информации, который должен приходить к вам от работающих на вас людей. Вы изолируете себя, и команда начинает работать против вас, а не с вами.
Вот практическое рекомендация. Во-первых, регулярно объявляйте свои разумные цели и ограничения, как я объяснил выше. Убедитесь, что команда понимает ваши деловые планы и “почему” логику, стоящую за ними. Во-вторых, регулярно спрашивайте у членов команды о рисках и проблемах. Спрашивайте их, почему они считают, что цели проекта могут быть нарушены. Еще лучше, позвольте им регулярно документировать риски и сообщать их вам. Вознаграждайте их за честность в этом списке рисков.
Попробуйте и вы удивитесь, сколько интересного может содержать этот список рисков.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:29
