На протяжении своего опыта я довольно регулярно встречаю безуспешные проекты, ключевой ошибкой в которых была передача их на аутсорсинг без соответствующей проработки связанных с этим рисков. Мне хотелось бы поделиться принципами, которыми я руководствуюсь при принятии решения, отдавать ли сторонней компании работу или находить ресурсы внутри вверенного мне подразделения.
Поводом для написания этой статьи явилось несколько известных мне проектов в моей компании, где решение о передаче на аутсорсинг, как в конце концов выяснилось, было неправильным. Этих ошибок уже нам не избежать, но, возможно, мои рекомендации помогут избежать новых проблем.
Сразу оговорюсь, что все нижеследующее будет относится преимущественно к ИТ. Про передачу на аутсорс бухгалтерии, логистики или других неайтишных направлений, я намеренно не упоминаю. Если принципы, на ваш взгляд, будут распространяться на них — пробуйте. Сейчас же пока сосредоточимся на ИТ-решениях.
ПЕРВОЕ. Принимая решение, отдавать ли на аутсорсинг разработку нового ПО и на каких условиях, я стараюсь оценить влияние разрабатываемого продукта на конкурентные преимущества компании. Очевидно, что в отношении корпоративного веб-сайта такое влияние значительно меньше, чем, скажем, для интернет-магазина, поддерживающего розничные или оптовые продажи. Если же, например, электронная коммерция является основным бизнесом компании, то такой сайт становится поистине «стратегическим ресурсом». Его передавать сторонней компании нельзя.
Один из показательных примеров — наш интернет-магазин. После сдачи компанией-разработчиком нам сайта интернет-магазина, полноценно поддерживать его могли только сами разработчики, потому что уровень «кривизны» программных решений зашкаливал за все мыслимые и немыслимые рамки. Если предположить, что разработчики имеют свой особый склад ума, позволивший им это создать, то, наверное, они способны это и поддерживать. Нам же пришлось многое переписать заново. В итоге, дополнительных сил было вложено столько, что проще было с самого начала делать все внутри компании.
ВТОРОЕ. Подрядчику нужно отдавать или мало, или много. Под «мало» я понимаю небольшой проект, качество которого внутренняя команда может оценить на стадии технической приемки, к которому можно неплохо описать требования и хорошо протестировать. Под «много» я понимаю комплексный проект, в который входит полноценное внедрение и обучение техспециалистов, подготовка технической документации, сдача работ «под ключ», передача подрядчику право принимать самостоятельные решения в рамках бюджета и поставленных перед ним высокоуровневых целей. Я хочу отметить, что в этой схеме нет места «средним» проектам. Потому что, на мой взгляд, нельзя их сделать качественно на стороне. Для небольших задач (вариант «мало») можно даже привлекать фрилансеров, но в этом случае необходимо иметь по крайней мере двухкратный запас времени и расширенный резервный бюджет на покрытие связанных с этим рисков риски.
ТРЕТЬЕ. Подрядчик должен быть высокоответственнен, надежен и стабилен. А для этого им должна стать компания, соответствующая уровню и масштабу поставленных перед нею задач. Правило про первый блин комом работает здесь как нигде — ни один подрядчик не сможет вникнуть во все особенности вашей инфраструктуры, не «наступив на грабли», не «испробовав» все ручки и рычажки. Именно поэтому плохо менять подрядчиков как перчатки — каждый новый стоит не только денег и времени, но и совместных ошибок.
Примеров из собственного опыта масса — в прошлом году для развития сайта нам пришлось отказаться от ряда мелких подрядчиков в пользу одного крупного. Количество ошибок сократилось на порядок, качество повысилось.
ЧЕТВЕРТОЕ. По окончании проекта, разработанное решение должно целиком и полностью перейти к заказчику. Техническая поддержка решения должна производиться уже силами компании-заказчика. На мой взгляд, ни при каких условиях, подрядчик не должен оставлять за собой какие-либо «сокровенные знания». Всякого рода гарантийная поддержка после завершения контракта, обязательства исправлять ошибки — от лукавого. Это не работает. Нужно делать всё, чтобы проект сразу вставал на собственную техническую поддержку.
Как пример из собственного опыта, в Web Media Group при разработке одного из сайтов я настоял на необходимости включить в проектную команду подрядчика специалистов из нашей компании и замкнуть на него ключевые этапы разработки. В результате мы получили сайт вместе со знанием, как он работает «внутри», а подрядчик лучше уловил наши «хотелки» на самом раннем этапе. Обычно такая схема очень непопулярна на рынке веб-разработок, потому что она добавляет рисков разработчику, которых он в других случаях избегает. Но если смотреть с позиции заказчика, для него эта схема работает на ура.
По одному из наших программно-аппаратных решений по продажам через киоски «начинку» разрабатывала внешняя компания. Особенность была в том, что, упрощенно говоря, они отдали нам проект на условиях аренды. Услуги по технической поддержке и по развитию продукта постепенно дорожали, а цена ухода с каждым месяцем возрастала. Ошибкой было то, что в контракте не было предусмотрено полной передачи продукта. Опять же, выходом было то, что мы просто сделали все заново. Совокупные затраты на создание второй версии продукта «с нуля» оказались даже меньше, чем в ситуации, когда мы получили продукт «в аренду», а удовлетворенность абсолютно всех заинтересованных в этом проекте лиц возросла многократно.
Единственное оправдание в передаче на аутсорсинг — экономия денег и времени. Всегда сопоставляйте ценность этой экономии с рисками, которые сулит такое решение.
Один из показательных примеров — наш интернет-магазин. После сдачи компанией-разработчиком нам сайта интернет-магазина, полноценно поддерживать его могли только сами разработчики, потому что уровень «кривизны» программных решений зашкаливал за все мыслимые и немыслимые рамки. Если предположить, что разработчики имеют свой особый склад ума, позволивший им это создать, то, наверное, они способны это и поддерживать. Нам же пришлось многое переписать заново. В итоге, дополнительных сил было вложено столько, что проще было с самого начала делать все внутри компании.
ВТОРОЕ. Подрядчику нужно отдавать или мало, или много. Под «мало» я понимаю небольшой проект, качество которого внутренняя команда может оценить на стадии технической приемки, к которому можно неплохо описать требования и хорошо протестировать. Под «много» я понимаю комплексный проект, в который входит полноценное внедрение и обучение техспециалистов, подготовка технической документации, сдача работ «под ключ», передача подрядчику право принимать самостоятельные решения в рамках бюджета и поставленных перед ним высокоуровневых целей. Я хочу отметить, что в этой схеме нет места «средним» проектам. Потому что, на мой взгляд, нельзя их сделать качественно на стороне. Для небольших задач (вариант «мало») можно даже привлекать фрилансеров, но в этом случае необходимо иметь по крайней мере двухкратный запас времени и расширенный резервный бюджет на покрытие связанных с этим рисков риски.
ТРЕТЬЕ. Подрядчик должен быть высокоответственнен, надежен и стабилен. А для этого им должна стать компания, соответствующая уровню и масштабу поставленных перед нею задач. Правило про первый блин комом работает здесь как нигде — ни один подрядчик не сможет вникнуть во все особенности вашей инфраструктуры, не «наступив на грабли», не «испробовав» все ручки и рычажки. Именно поэтому плохо менять подрядчиков как перчатки — каждый новый стоит не только денег и времени, но и совместных ошибок.
Примеров из собственного опыта масса — в прошлом году для развития сайта нам пришлось отказаться от ряда мелких подрядчиков в пользу одного крупного. Количество ошибок сократилось на порядок, качество повысилось.
ЧЕТВЕРТОЕ. По окончании проекта, разработанное решение должно целиком и полностью перейти к заказчику. Техническая поддержка решения должна производиться уже силами компании-заказчика. На мой взгляд, ни при каких условиях, подрядчик не должен оставлять за собой какие-либо «сокровенные знания». Всякого рода гарантийная поддержка после завершения контракта, обязательства исправлять ошибки — от лукавого. Это не работает. Нужно делать всё, чтобы проект сразу вставал на собственную техническую поддержку.
Как пример из собственного опыта, в Web Media Group при разработке одного из сайтов я настоял на необходимости включить в проектную команду подрядчика специалистов из нашей компании и замкнуть на него ключевые этапы разработки. В результате мы получили сайт вместе со знанием, как он работает «внутри», а подрядчик лучше уловил наши «хотелки» на самом раннем этапе. Обычно такая схема очень непопулярна на рынке веб-разработок, потому что она добавляет рисков разработчику, которых он в других случаях избегает. Но если смотреть с позиции заказчика, для него эта схема работает на ура.
По одному из наших программно-аппаратных решений по продажам через киоски «начинку» разрабатывала внешняя компания. Особенность была в том, что, упрощенно говоря, они отдали нам проект на условиях аренды. Услуги по технической поддержке и по развитию продукта постепенно дорожали, а цена ухода с каждым месяцем возрастала. Ошибкой было то, что в контракте не было предусмотрено полной передачи продукта. Опять же, выходом было то, что мы просто сделали все заново. Совокупные затраты на создание второй версии продукта «с нуля» оказались даже меньше, чем в ситуации, когда мы получили продукт «в аренду», а удовлетворенность абсолютно всех заинтересованных в этом проекте лиц возросла многократно.
Единственное оправдание в передаче на аутсорсинг — экономия денег и времени. Всегда сопоставляйте ценность этой экономии с рисками, которые сулит такое решение.
