Я знаю людей из корпоративных разработчиков, которым outsourcing буквально «жизнь поломал». Энергичный хлопок дверью.
– Всем нужен программист, – сказал я, возвращаясь к ботинкам.
Embarcdero (Borland) не использует модель outsourcing-а в «чистом виде», однако схема привлечения внешних ресурсов вполне может считаться полезной для рассмотрения, особенно в свете backsourcing-а. Почему Embarcadero не всё делает сама? Почему базовый продукт нуждается в дополнении со стороны технологических партнёров? Как что-то отдать на сторону, а потом забрать? Нужно ли думать об backsourcing-е как неизбежном завершении outsourcing-а? Можно ли вообще обойтись без этого?
Outsourcing самим звуком вызывает негативную реакцию со стороны «собственных разработчиков», на что есть масса причин. Теперь к этому добавится ещё одно однокоренное слово – backsourcing. Чтобы это не стало «второй возможностью хлопнуть дверью», разберёмся в деталях. Хорошая команда, выполняющая работу на заказ похожа на спецназ. Каждый боец обладает несколькими компетенциями. Но куда ж без «танка»? Мягкие и изнеженные корпоративные разработчики не могут ничего противопоставить закалённому в баттлах сейлу. Такой «очаровашка» очень быстро вотрёт вашему CIO, что именно его команда сделает все гораздо лучше.
Заходов на «аутсорс» много. Одним из первых является следующий тезис: «мы уже делали то, что вам нужно, и у нас есть наработки». Как бы намекают, что за деньги другого, предыдущего заказчика, они уже сделали решение, а теперь просто и дешево допилят его до вашего случая. Это будет гораздо дешевле, чем инициировать и фондировать собственное направление.
Кроме этого, «собственные разработчики» уже давно разленились (растренировались). Их бы, конечно, взбодрить scrum-ом… (это будет отдельный демотивационный сет). Но наше решение уже не просто аналогичное, но ещё и почти-(полу-)готовое.
Дальше, конечно, работает красноречие. Свои корпоративные разработчики уже давно не рисуют картину будущего в ярких красках. На вопрос «куда будем развивать систему» обычно хмурятся брови, руки убираются в карманы, взгляд отводится в сторону. Это – понятно, когда оплата повремённая, зачем брать себе extra mile? А внешний краснобай и баламут всегда весел, бодр и оптимистичен.
Психология внешней команды хорошо иллюстрируется дачным строительством. Любая бригада, пришедшая на смену уволенной, начинает ругать результаты труда предыдущих деятелей. У своих нет шансов отбиться.
Аккумулятор оптимизма в голове CIO после такой «зарядки» генерирует энергию творчества, однако контуры внутренних разработчиков настроены совсем на другую частоту. Но именно это и является причиной outsourcing-а!
В очень многих случаях «отдача проекта на сторону» вызвана именно потерей контроля над собственной командой. Наш начальник никогда не был хорошим разработчиком! Он постоянно лезет в наши дела! Он не понимает, о чём говорит! Давайте продолжать в том же духе. Тогда шеф ответит в стиле Макиавелли. Возьмёт вторую внешнюю команду.
Хотя начальник может повести себя более дипломатично. Чужие приходят и уходят, а свои будут всегда. Немножко за счёт «аутсорса» поднапрячь своих, чтобы не чувствовали свою незаменимость/уникальность, но совсем-то злить/унижать не надо.
Проблема-то в контролируемости команды разработчиков («как пасти котов») решается за счёт «аутсорса» легко. Но только в теории и только при разговоре с их «продажником». За хороший контракт они пообещают чуть ли не веб-камеры за спинами разработчиков.
Но ситуация будет совсем другой при завершении проекта. Только генетически наивные люди думают, что заказчик решает всё. Завал проекта – это, прежде всего, удар по заказчику, т.к. у него тоже есть свой начальник. Более того, CIO вынужден не просто взять проект/заплатить деньги, но ещё и внедрить его и использовать долгие годы. Если собственный проект подлежит списанию, то можно обосновать «объективной реальностью» в плане смены бизнес-процессов (бизнес-идей) и потребностей менеджеров. А если результат труда аутсорсеров не нужен, значит, им не так поставили задачу. Кто виноват? Кто ставил задачу.
При сдаче проекта можно настолько выкрутить руки заказчику, что он даже закроет глаза на недоделки.
И вот уже под злорадные смешки корпоративных программистов «а мы предупреждали» их начальник принимает решение о backsourcing-е.
Мифы о дешевизне и качестве «внешней разработки» легко развеиваются, если немного отвлечься от мыслей о кодировании и подумать о деньгах (при всей отвратительности этой идеи). Кто всё-таки не может заставить думать себя о смысле программирования в контексте оплаты, я настоятельно рекомендую жениться и завести детей.
- Когда нам считают деньги внешнего проекта, то туда не заносят стоимость времени внутренних сотрудников на помощь аутсорсерам, хотя бы на составление ТЗ.
- Стоимость разработки определяется качеством кода. Качество кода нужно для снижения стоимости сопровождения/модификации/развития системы. Но нужно это «своим», а не «внешним».
- Качество разработки зависит от степени протестированности. В прикладной разработке написать кейсы может только человек, знакомый с предметной областью. Тут как бы уже и требовать неприлично такое с аутсорсеров.
- Срок выполнения типового проекта соизмерим с периодом генерации новых бизнес-идей, поэтому велика вероятность (чем дальше, тем вероятнее), что в финале вам выдадут заранее устаревшую по функционалу систему.
- Гибкость и модифицируемость системы определяется архитектурой. Архитектура внешних решений часто бывает одноразовой. Очень велик соблазн сделать «жёсткосварную» конструкцию из прутков, чем точить на станке универсальные многоразовые узлы.
Если инвертировать указанные выше пункты, то можно легко обосновать необходимость удержания разработки внутри творческого коллектива. Только не надо без нужды обострять отношения со своим IT-начальством, чтобы outsourcing не стал инструментом возмездия за непокорность.
Но outsourcing имеет и более адекватных причины, в частности, желание помочь близкой по духу команде. Какой бы дружественной ни была команда, объективные причины сэкономить приведут к тому, что сделанный на стороне проект будет представлять собой «чёрный ящик с мухами». Открой её и появится целый рой саморазслетающихся быстроплодящихся багов.
Большинство экспертов сразу скажут – нужна хорошая/правильная документация! Записывание ходов шахматной партии никогда не предотвращало драку, но провоцировало её.
Ввязываясь в outsording, нужно думать о backsourcing-е, т.е. возврате проекта в лоно материнской компании. Лучше всего быть готовым к этому на любой стадии.
Конечно, можно воспользоваться доводами против outsourding-а и закопать его. Но как бы вам не пришлось её откапывать (да-да, как в анекдоте).
Правильный outsourcing всегда должен подразумевать backsourcing. Не обязательно проговаривать/прописывать, но держать в голове. Тогда целью autsourcing-а никогда не будет компенсация отсутствия нужной компетенции у своей команды. А нужен ли тогда outsourcing at all? Конечно, нужен. Он позволяет сглаживать пики нагрузки на основную команду. Это мы (Embarcadero) делаем в период интенсивной подготовки релиза.
Есть примеры, когда вовлечение внешних команд оказывало негативное влияние. Возьмём схему, характерную для Delphi, когда есть материнский продукт, а есть – сателлитная технология, которая может входить в одну поставку с базовым пакетом. Так обычно было с «генераторами отчётов». Понятно было желание «не ввязываться» в боковое направление, которое де-факто является идеологически изолированным от основного инструментария. Основная команда могла концентрироваться на кодогенерации и компонентном наполнении, тогда как независимые команды могли поставлять свои решения. Вроде бы такая хорошая конкурентная схема впоследствии и порождала проблемы.
Вначале, когда технологический партнёр борется за право вхождения в поставку, он буквально рвёт постромки. Но нет тут единой синхронизирующей стратегии, поэтому главная и дополнительная технологии развиваются рассогласовано. Мы на три релиза уже вперед пошли, а наш партнёр только-только очнулся. Получается, что мы его паровозим, а он второй локомотив переоборудовал в спальный вагон.
Так продолжалось несколько раз, старожилы помнят ReportSmith, QuickReport, Rave Report. Каждый раз технология выстреливала, а потом не выдерживала релизной гонки. И только с четвертого раза мы нашли партнёра Fast Reports, который выпускает синхронные релизы, отрабатывая новые фреймворки и мультиплатформенность.
Особо хочется отметить то, что для FastReports осталась ниша для до-зарабатывания денег. В принципе, такая схема применима и для outsourcing-а. Команда делает что-то сверх-ТЗ и имеет за это отдельные поступления. Сам факт наличия возможности для до-получения денег стимулирует внешнюю команду не замыкаться на базовом функционале и держать своё решение в потенциоально развиваемом состоянии.
В случае с библиотекой доступа к данным AnyDAC мы не видим outsourcing-а, разве что открытость Delphi дала шанс выпускать внешнее решение. Зато можно наблюдать «выкуп» технологии с последующим ре-брендингом в FireDAC. Это позволило опять же синхронизировать развитие базовой и дополнительной технологии в период революционного освоения мультиплатформенного подхода.
Реализация же контрактных инициатив происходит при наличии супервайзера. На аутсорс уходит – да – классическое ТЗ, но под присмотром и руководством изнутри. Таким образом, соблюдается единство и контроль качества компонентов на уровне исходных кодов, включая стилистику. Здесь уже можно говорить о чистом «аутсорсинге» и изначальном планировании «бэксорсинга».
Самое главное, что причины, инициировавшие outsourcing, со знаком минус не являются основанием для backsourcing-а. Это – два связанных решения, а умение их правильно реализовывать на уровне управления процессами дают преимущества:
- снижение нагрузки на основную команду;
- более быстрое экстенсивное развитие технологии;
- соблюдение интересов качества основной архитектуры/фреймворка;
- единообразие технологической реализации;
- предупреждение сепарации компетенций в команде;
- ещё одна степень свободы в перераспределении ресурсов.
Поменьше личностных факторов, побольше объективности.
Сейчас наступает для многих корпоративных команд тяжёлый момент. Мобильная разработка требует новой компетенции. Аутсорсеры прям порвать готовы за контракт на мобильное решение для бизнеса. Если это будет из-за недостатка собственной компетенции, то разработчики становятся жертвой, даже если это изначально не планировалось. Обратите внимание на мультиплатформенные средства разработки мобильных приложений для Android и iOS на основе единой базы исходных кодов. Не сепарируйте и не размывайте собственную компетенцию. Иначе это сделают другие.
Автор: VsevolodLeonov
