Расширение штата или аутсорсинг устаревших систем

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

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

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

Расширение штата дает ресурсы, но не результат

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

Иногда это ровно то, что нужно. У продуктовой команды может быть четкая граница сервиса и очередь понятных задач на шесть месяцев. Пока идет найм, ей могут понадобиться два опытных Go-разработчика. Работу можно разделить, проверить и выпустить с помощью механизмов, которыми команда уже владеет. В такой ситуации расширение штата повышает пропускную способность без еще одного управленческого слоя.

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

Фред Брукс описал календарную версию этой проблемы в книге The Mythical Man-Month: новые люди могут еще сильнее задержать опаздывающий программный проект, потому что обучение и общение съедают ресурсы, которые рассчитывали добавить. Иногда закон Брукса повторяют так, будто увеличение команды никогда не помогает. Это слишком широкое толкование. Дополнительные инженеры полезны, когда работу можно разделить, интерфейсы стабильны, а кто-то способен справиться с дополнительными проверками. Они мешают, когда каждому новому участнику нужны дефицитные специалисты, чтобы объяснить плохо описанную систему.

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

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

Аутсорсингу нужна стабильная граница

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

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

Типичный провал начинается с толстого документа требований и тонкого определения приемки. Подрядчик реализует названные экраны и интерфейсы. Позже заказчик обнаруживает, что квартальное закрытие зависит от конкретного порядка записей и недокументированной повторной попытки. Подрядчик называет это запросом на изменение, потому что в документе такого не было. Заказчик называет это дефектом, потому что производственная система ведет себя так пятнадцать лет. Обе позиции можно защитить, но система все равно не работает.

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

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

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

Ответственность за поставку сдвигает границу риска

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

Такая модель полезна, когда у работы есть ясная деловая граница, но ее реализация содержит много неизвестного. Хороший пример: переписывание унаследованного приложения. Заказчик может назвать процессы, которые должны продолжить работу, подключаемые системы и неизменные эксплуатационные ограничения. Он может не знать всех правил в исходном коде и лучшей целевой архитектуры. Подрядчику платят за то, чтобы он устранил эту неопределенность и доказал результат.

Модель стоит дороже чистых ресурсов, потому что подрядчик включает риск в цену. Такая надбавка разумна, только когда риск действительно переходит к нему. Читайте исключения. Если подрядчик вправе объявить платным изменением любое недокументированное поведение, задержку зависимости или различие среды, неизвестные факторы все еще принадлежат заказчику. Если заказчик обязан предписать архитектуру, одобрить каждый технический выбор и предоставить команду выпуска, подрядчик не может честно отвечать за поставку.

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

Не путайте гарантию с эксплуатационной ответственностью. Подрядчик может обещать исправить дефекты после приемки, пока ваша команда обнаруживает инциденты, ограничивает ущерб и решает, откатываться ли назад. Такой порядок может подходить, но риск в 02:00 остался у вас. Если подрядчик должен реагировать, дайте ему телеметрию, инструкции, доступ и прямую обязанность дежурить. Ожидания без доступа приводят к телефонным совещаниям, а не к восстановлению.

Ответственность за поставку лучше всего работает, когда приемку можно выполнить как проверку. Тесты, воспроизведение трафика, сверка результатов и учения по восстановлению превращают спор о полноте в доказательства. Мнение управляющего комитета их не заменит, особенно когда люди, одобрившие объем, спят во время первого сбоя.

Архитектура принадлежит тому, кто может отклонить изменение

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

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

Здесь полезна идея Майкла Найгарда об Architecture Decision Record, потому что короткая запись фиксирует одно решение, его контекст и последствия. Мартин Фаулер подчеркивает, что более позднее решение должно заменять старую запись, а не переписывать историю. Для отношений с подрядчиком это важно. Чистая история решений показывает, был ли плохой результат следствием ограничения, технического выбора или новых данных, и не превращает журнал в список виноватых.

У записи все равно должен быть владелец решения. Папка с ADR способна одинаково аккуратно задокументировать как здравое суждение, так и паралич. Добавьте к каждому существенному решению четыре поля: инициатор, опрошенные стороны, принимающий решение и условие пересмотра. Последнее важно, потому что разумный выбор при десяти тысячах транзакций в день может стать неверным после слияния, которое удвоит нагрузку.

Team Topologies предлагает команды, ориентированные на поток и отвечающие за него от начала до конца, а также вспомогательные команды, которые за ограниченное время развивают недостающую компетенцию. Для контрактов полезен следующий вывод: помощь должна повышать самостоятельность команды-владельца. Если внешние специалисты становятся постоянными переводчиками между вашим продуктом и вашей же платформой, вы создали зависимость, а не развили команду.

Архитектура может остаться внутри компании при любой коммерческой модели. Меняется объем управления. При расширении штата внутренняя архитектура предусмотрена по умолчанию. При аутсорсинге нужно контролировать шов. При ответственности за поставку вы задаете ограничения и позволяете подрядчику проектировать внутри них. Эти схемы можно смешивать для отдельных решений, но каждое исключение добавляет передачу, которой нужен владелец.

Сбой пакета в 02:00 зачитывает контракт вслух

Производственный сбой показывает реальное распределение ответственности быстрее любой презентации об управлении. Представьте перенесенное пакетное задание по расчетам, которое читает 1,8 миллиона записей, пишет проводки и публикует событие о завершении. В 02:07 оно останавливается после фиксации транзакции в базе данных, но до публикации события. Планировщик помечает задание как упавшее.

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

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

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

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

Запишите операционное соглашение в форме, которую инженеры могут проверить. Этот пример не относится к стандартам. Это компактное приложение к контракту, которое устраняет самую дорогую неоднозначность:

incident: settlement-batch-partial-commit
detection_owner: customer-operations
incident_commander: delivery-supplier
data_mutation_approver: customer-finance-platform
diagnosis_sla_minutes: 20
allowed_without_approval:
  - pause-downstream-consumers
  - capture-logs-and-state
forbidden_without_approval:
  - rerun-batch
  - publish-completion-event
  - restore-database
exit_evidence:
  - ledger-count-reconciled
  - duplicate-check-passed
  - downstream-event-confirmed

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

Знания остаются там, где принимают решения

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

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

При аутсорсинге обычно создают явные артефакты, потому что их требует коммерческая граница. Слабое место находится в контексте. Пакет передачи описывает конечное состояние, а команда подрядчика помнит, почему отвергнутые варианты не сработали. Внутренние инженеры должны участвовать в проверках проекта и учениях по инцидентам, а не принимать одни документы. Такое участие расходует ресурсы во время поставки, и эти затраты покупают будущую независимость.

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

Измеряйте передачу самостоятельными действиями. Может ли внутренний инженер объяснить расположение границы? Может ли команда исследовать неудачное воспроизведение без вопроса подрядчику о том, где искать? Может ли она внести небольшое изменение и доказать паритет? Число документов и посещение встреч измеряют входные данные. Успешное изменение без помощи служит доказательством.

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

Контроль и ответственность должны двигаться вместе

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

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

Ограничения финансовой ответственности не говорят инженерам, что делать во время инцидента. Они регулируют часть денежного спора после ущерба. Для эксплуатационного риска нужны более быстрые механизмы: доступ, оповещения, право принимать решения, критерии отката и отрепетированный путь к человеку, который может принять деловые последствия. Разделяйте юридическое возмещение и управление инцидентом. Правовые средства важны, но они не сверят бухгалтерские записи до начала рабочего дня.

Управление изменениями требует такой же точности. Команды небрежно называют изменением как минимум четыре разных события:

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

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

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

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

Практическая проверка ищет симметрию. Для каждого обязательства выясните, есть ли у обязанной стороны сведения и полномочия для его выполнения. Для каждого права согласования выясните, несет ли согласующий вызванную им задержку. Для каждого переданного риска определите доказательство его принятия подрядчиком. Обязательство без контроля позже превращается в исключение. Контроль без последствий сразу ведет к небрежному управлению.

Закупка должна проверить операционную модель

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

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

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

Используйте этапы приемки, соответствующие риску:

1. Определите наблюдаемое поведение и допуски до начала реализации.
2. Запишите архитектурные ограничения отдельно от предпочтительных решений.
3. Воспроизведите репрезентативные производственные случаи и сверьте результаты.
4. Проведите одно учение по восстановлению с назначенными владельцами решений.
5. Попросите внутреннего инженера внести и проверить небольшое изменение без участия подрядчика.

Это единая цепочка доказательств, а не пять административных этапов. Проект может пройти проверку исходного кода и функциональное тестирование, но провалить восстановление, потому что никто не отвечает за частичное состояние. Он может доказать паритет, но провалить самостоятельное изменение, потому что все знания остались снаружи. Приемка должна выявить эту разницу раньше окончательного счета.

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

Подходящая модель следует за неопределенностью

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

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

Не используйте ответственность за поставку как способ обойтись без внутреннего владельца. Заказчик по-прежнему отвечает за деловые правила, принятие риска и долгую жизнь системы. Подрядчик не может решить, какое финансовое расхождение допустимо или какой клиентский процесс разрешено изменить. Хороший ответственный за поставку устраняет техническую неопределенность. Он не заменяет решения руководства.

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

Выбор должен пройти последнюю проверку. Запишите правдоподобный сбой в 02:00, человека с правом действовать, доступные ему доказательства и сторону, которая заплатит за исправление системы. Если один из ответов звучит как «совместно» или «будет согласовано», контракт еще не распределил работу. Он отложил спор до момента остановки системы.