Многие организации по разработке программного обеспечения используют в своих проектах внешние трудовые ресурсы. Когда компании прибегают к гибкой и рациональной разработке, часто возникает вопрос: "Вписывается ли аутсорсинг в гибкую среду?". Ответ: это возможно, но для гарантии успеха потребуется тщательная предварительная проработка и последовательное выполнение плана. В этом цикле статей из двух частей Тони Граут делится своим опытом в области эффективного применения гибкого аутсорсинга и указывает критические элементы, необходимые для достижения оптимальных результатов.
Каждый руководитель группы разработчиков программного обеспечения или другого подразделения сталкивался с ситуацией, когда предстоящий проект кажется слишком большим, чтобы его организация могла справиться с ним без посторонней помощи. Может показаться, что это задача принципиально нового типа. Даже если группа, умело пользуясь методами гибкой разработки, успешно справляется с крупными (скажем, рассчитанными более чем на 25 человек) проектами, перспектива привлечения помощников по контракту при реализации следующего проекта может показаться проблематичной.
Дух гибкой разработки во многом связан с доверием в команде, большая она или малая, и требуется понимание принципов гибкой разработки, которые могут иметь определенные нюансы для каждой конкретной команды. Вам, конечно, знакомы эти проблемы. Но способы применения аутсорсинга в проектах гибкой разработки все же существуют, и учитывая эти условия и возможности, можно облегчить себе задачу. Естественно, речь идет о создании наилучших взаимоотношений между заказчиком и подрядчиком и о понимании того, чего каждая сторона пытается достичь за счет гибкости.
Понимание мотивов ― поставщика и своих собственных
Те, кто достаточно хорошо освоил гибкие методы, способен оценить организацию, которая может подойти в качестве помощника в реализации проекта. Однако когда организации обращаются за помощью к внешним поставщикам, часто имеет место несовпадение их собственных целей с целями их родительской организации. Например, многие организации, практикующие внутреннюю разработку, придерживаются подхода " заниматься гибкой разработкой", вместо того, чтобы " быть гибкой командой" или ставить перед собой цель " стать гибкой командой". Многие считают, что гибкость - это всего лишь набор простых правил, хотя на самом деле это комплексный подход, направленный на то, чтобы быстро и своевременно принести больше выгод заказчику для его собственного бизнеса и акционеров.
Поэтому я всегда начинаю с объяснения того, что настоящая цель методов гибкой разработки программного обеспечения ― это гибкость бизнеса. Прежде чем рассматривать возможность аутсорсинга, важно понимать, как это будет работать для вашего собственного бизнеса.
Другими словами, мы должны начать разговор с гибкости на уровне бизнеса, а затем уже спускаться к его технической подоплеке. Всегда нужно отталкиваться от искомой гибкости бизнеса. Речь не о том, отдавать ли предпочтение экстремальному программированию (XP) перед разработкой на базе тестирования; речь о необходимости предложить рынку нужное программное обеспечение, чтобы предприятия могли принести больше выгод своим клиентам и получить больше прибыли. Это верно как для работодателей, так и для их субподрядчиков.
Обычно я не пытаюсь убедить клиентов переходить к гибкой разработке. Большинство организаций уже применяет гибкие методы на том или ином уровне; хотя, естественно, многие сталкиваются с трудностями при их реализации в своих собственных уникальных условиях. Эта статья организована вокруг принципов Agile Manifesto в попытке в первую очередь показать, как гибкий аутсорсинг соотносится с самими концепциями, определяющими гибкую разработку. Я не буду перечислять все четыре основополагающих принципа Manifesto, но давайте рассмотрим первые два, просто чтобы начать эту дискуссию.
Предпочтения отдельных лиц и их взаимодействие важнее процессов и инструментов
Что касается гибкости бизнеса, то действительно существует прямая связь между этой концепцией и Agile Manifesto, первый принцип которого гласит, что предпочтения отдельных лиц и их взаимодействие важнее процессов и инструментов.
В некоторых организациях бытует мнение, что если люди могут рационально работать и взаимодействовать, то "инструменты" не нужны. На самом деле, одним из основных факторов успеха является прочное рабочее взаимодействие между предприятием и его внутренней ИТ-организацией. В среде аутсорсинга люди-участники этого ключевого взаимодействия особенно важны, потому что когда привлекают субподрядчиков, работа естественным образом распределяется. Ключевые бизнес-ресурсы не обязательно находятся в непосредственной близости от бизнес-подразделений, а могут оказаться в другой части света. Мы сталкиваемся с самыми разнообразными оншорными и офшорными моделями среди наших клиентов.
В этих условиях для эффективного взаимодействия требуется высокий уровень доверия. И это один из вопросов, которые не выражены явно в Agile Manifesto. Мы строим доверительные отношения с людьми; мы не строим доверительных отношений с организациями ― это приходит позже.
Работающее программное обеспечение важнее полной документации
Быстрое создание и последовательное предоставление работающего программного обеспечения имеет решающее значение, но в контексте аутсорсинга при заключении договора иногда теряется самая суть этого принципа Manifesto. Мне приходилось наблюдать сложнейшие переговоры о контрактах и поставках, когда пытались добиться компетентной и скрупулезной работы, сосредоточившись не на предоставлении работающего программного обеспечения, а на подписании разнообразных документов на протяжении жизненного цикла проекта.
Я как-то работал над государственным проектом по созданию онлайновой системы для органов полиции. От партнера по аутсорсингу требовали систему на основе устаревшей технологии, которая грозила создать проблемы с точки зрения производительности. В контракте говорилось, что критерии оплаты и выходного контроля считаются выполненными, если исполнитель представит документацию по архитектуре программного обеспечения, показывающую, как в унаследованной системе решаются эти проблемы производительности. Спустя шесть месяцев был готов 250-страничный документ, полный схем и текстовых описаний того, как они собираются решать эти проблемы. И им заплатили. Но спустя еще 18 месяцев никакого работающего программного обеспечения все еще не было, и пришлось вмешаться юристам.
Если бы в этом проекте применялись методы гибкой разработки, то вместо того чтобы полагаться лишь на документацию, группа в первую очередь должна была бы представить некое работающее программное обеспечение для демонстрации архитектуры. Это классический пример того, как методы гибкой разработки помогают заказчикам и разработчикам идти в ногу.
Для успешного аутсорсинга проектов гибкой разработки необходимо выбрать наилучшего поставщика, основываясь на понимании своих бизнес-целей и организационных ограничений. В этой первой из двух статей рассмотрены два первых принципа Agile Manisfesto, гласящих, что предпочтения отдельных лиц и их взаимодействие важнее процессов и инструментов и что работающее программное обеспечение важнее полной документации. Во второй части мы продолжим эту дискуссию и дадим пять советов, которые помогут читателю гарантировать успех.