Интересным, но не совсем понятным в современной парадигме разработки становится место аутсорсинга в любом виде.

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

Это очень похоже на описание проектной деятельности: проектная стадия “transition” рассматривается как просто как “передача в эксплуатацию”. При таком подходе после приемки следующей важнейшей задачей заказчика будет обеспечить эксплуатацию нашей системы. Со стороны заказчика понадобится команда/организация, которая будет заниматься этой эксплуатацией, обеспечивать режим “Run”. Для этой команды необходимо представить инструкции по эксплуатации, и у нее должны быть все необходимые навыки, а значит возможно понадобится предусмотреть и обучение этой команды. Без соответствующих инструкций/обучения эта команда будет выяснять особенности эксплуатации новой системы методом проб и ошибок, т.е. скорее всего работать не с тем качеством, которое требуется заказчику.

Если вы слышите (или говорите) “разработайте нам такую-то штуку”, но при этом не говорится о том, кто ее будет поддерживать и что ему с ней нужно будет при это делать – знайте, здесь рано или поздно что-то взорвется (хорошо если рано).

Но чаще всего мы хотим не просто получить новую систему, а также хотим в дальнейшем в ней что-то менять. Иными словами, мы сразу предполагаем проекты аналогичные проекту первоначальному созданию системы, возможно в меньшем масштабе. Для такого рода доработок нам нужна подробная актуальная техническая документация к системе (не путать с инструкциями по эксплуатации!): это как собственно программный код, так и требования/описания фич системы, принятые важнейшие решения, схемы работы, разворачивания и т.д. – одним словом все то, что понадобится разработчику разобраться в том, как работает система и выполнить свою часть работы. Если эта документация сохранилась только в голове самого разработчика “предыдущего этапа разработки”, новой команде разразработки придется заниматься практикой Reverse Engineering, а именно по имеющейся функциональности и низкоуровневым описаниям (т.е. коду) воссоздавать описания более высокоуровневые описания (например, решения почему сделано именно так, а не иначе) и требования к разработке. Если подходить к этой практике ответственно, после того как мы в процессе reverse engineering мы получаем модульное разбиение нашей системы, мы в соответствие с обратным законом Конвея аналогичным способом должны структурировать и нашу организацию. (Я вряд ли слышал о том, чтобы так кто-то делал, и возможно многие проблемы развития legacy-систем связаны именно с этим). Это же соображение становится важным и в следующем пункте.

Итак, если мы хотим продолжать менять что-то в нашей системе после ее передачи/transition, нам нужно передавать реализацию всех практик ее жизненного цикла, иначе для каждой доработки придется проводить reverse engineering. Иными словами, невозможно передать систему, которая будет меняться в дальнейшем без передачи команды (или организации), которая создает эту систему, выполняет все необходимые практики ЖЦ (управление фичами и их оценку, разработку, тестирование и т.д.). Невозможно (или непростительно дорого) построить систему одной организацией, а затем на этом месте построить новую организацию.

Из этого следуют выводы:

• Если сдается система “под ключ” — она не предполагает изменения (или предполагает лишь незначительные изменения).
• Если предполагается, что система продолжит развиваться — она должна создаваться одновременно с командой, которая продолжит ее поддерживать.
• Если предполагается, что на нашем системном ландшафте будут появляться новые системы необходимо прорабатывать практики жизненного цикла самих команд.

Теперь вернемся к вопросу, который мы поставили в начале главы. В каком виде может существовать аутсорсинг? Может ли существовать вообще? На мой взгляд, это будет либо создание систем “под ключ”, которые не предполагают дальнейших изменений (таких проектов множество, хотя конечно на слуху проекты другие). Либо продолжительное сотрудничество заказчика с аутсорсером.

Какие еще есть варианты?