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

Наемники и королевские советники

Консультанты, практически независимо от их опыта, делятся на две группы. Первую группу я называю «наемниками»; они, как правило, имеют меньшую ставку почасовой оплаты по сравнению со второй группой, и их используют для решения конкретных практических задач. Вторая группа консультантов — «королевские советники». Они, как правило, берут за свои услуги больше, чем «наемники», и предполагается, что у них есть готовые ответы на любые вопросы. Они входят во внутренний круг, посещают собрания, высказывают свое мнение и обычно участвуют в жизни компании на таких уровнях, которые недоступны «наемникам».

Недавно я имел случай пообщаться с одним из своих коллег, которого можно отнести к категории «наемников», и он, как выяснилось, был очень разочарован тем, как мало влияния он имел на реальный ход процесса. Компания ожидала от него конкретного результата — разработанного программного продукта, и на этом его влияние заканчивалось. Чтобы внедрить проверенные опытом подходы (то, что называют best practice) или создать процесс, он должен был действовать очень тонко, осторожно «пропихивая» свои идеи там и сям. Как правило, его исходный код пропускался через контрольно-проверочную систему, был хорошо документирован, ежедневно дополнялся и тестировался с использованием автоматизированных сценариев. Прочие разработчики просто передавали дискеты друг другу и уповали на лучшее. Разочарованный невозможностью повлиять на процесс, мой знакомый решил, что в следующий раз возьмется за консалтинговый проект, только если получит должность архитектора или руководителя группы высокого уровня.

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

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

Я не хочу никого ни в чем обвинять; ограниченное участие «королевских советников» в реализации проекта обычно объясняется бюджетными вопросами. Однако, пусть даже у руководства были самые благие намерения, получить рекомендацию по решению проблемы — это совсем не то же самое, что реализовать решение на практике. Допустим, вы жалуетесь: «В моей машине скорость с задержкой переключается со второй на третью», и вам отвечают: «О, это известная проблема, вам нужно модернизировать TRAC ECU». Большое спасибо, это я и сам знаю. При разработке стратегических приложений подобные недопонимания неприемлемы.

Нужен ли вам консультант?

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

  • Готовы ли вы вкладывать средства в специализированную команду разработчиков стратегических приложений? Или же вы пытаетесь временно залатать дыру до тех пор, пока у вас не появится «кто-нибудь, кому можно это поручить»?
  • Можете ли вы (или ваша команда разработчиков) определить, какие технические риски связаны с проектом? Смогут ли они справиться с ними?
  • Работали ли члены вашей команды вместе раньше?
  • Есть ли у вас действующий процесс разработки программ?
  • Является ли разработка программ ключевым компонентом вашего бизнеса?

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

Каких консультантов выбрать

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

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

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

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

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

Внешние коммуникации

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

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

Дэн Пайлон — программный архитектор в фирме Blueprint Technologies. В настоящее время он обучает клиентов Blueprint объектно-ориентированному анализу и дизайну, а также программным архитектурам. С ним можно связаться по e-mail: dpilone@blueprinttech.com.