А нужны ли программисты в штате?
Из переписки: «Ок, мы поняли про WIP, шаблоны, эскалации, ИТ-слой процесса. Но тогда нужно нанимать программистов в штат? И каких?»

Сначала базовая развилка: «гигиена» vs «двигатель»
Есть автоматизация-гигиена: CRM, учет, документооборот, заявки, типовые шаблоны, интеграции. Это нужно всем и всегда это дешевле купить готовым.

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

Правило: своя разработка оправдана, если это «двигатель» конкурентности, который влияет на unit economics и плохо покупается коробкой. Но команда должна жить как продуктовая/проектная единица с roadmap, а не как «вечный цех по хотелкам».

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

Но большинство компаний нанимают «программиста» не потому, что им нужна разработка, а потому что у них болит хаос. И они пытаются лечить хаос кодом.
Не лечится!

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

Кого на самом деле нужно нанимать и когда
Теперь аккуратно «отрежем» малый бизнес. Пока вы маленькие, у вас обычно 1–2 ключевые системы, изменения редкие, интеграций мало, а половина процессов держится на голове владельца (и на его телефоне). В таком состоянии постоянный программист чаще вреден: он превращается в личного шамана, который «единственный знает как». И вы получаете новую зависимость вместо скорости.

Но как только вы становитесь средним предприятием, появляются признаки, которые нельзя «перетерпеть»:
• 3+ критичных систем (CRM + учет + документы + что-то ещё),
• 2–3 потока, которые должны работать параллельно и быстро,
• регулярные изменения и интеграции,
• видимые очереди между функциями.

Вот здесь почти неизбежно нужны две роли. И это не «IT-директор с армией». Это две точки управления скоростью:

Роль 1. Архитектор потока (процесс/BA-роль).
Это человек, который держит контракты процессов: вход/выход/DoD, SLA, эскалации, метрики потока. Он превращает «работу отдела» в сервис с понятными правилами. Из этой роли естественным образом вырастет бизнес-архитектор.

Роль 2. Инженер автоматизации и интеграций.
Не «настройщик одной коробки», а тот, кто строит нервную систему: API, события, оркестрация, надежность, наблюдаемость. Он делает так, чтобы ваши системы работали как единый поток, а не как зоопарк с пересылкой Excel по почте. Из этой роли вырастает enterprise/integration architect – архитектура ландшафта, а не «прикрутить кнопку».

Разработка ИТ-слоя процесса: в штате или на стороне?
Моё мнение простое – прямо по Хлебникову: архитектура должна быть своей, исполнение может быть смешанным (зависит от контекста).

Если ИТ-слой процесса – критичен (а он критичен, когда от него зависит P&L напрямую), то внутри должен быть человек, который определяет события, контракты данных, «источники истины» и правила оркестрации, а разработку адаптеров/коннекторов можно отдавать наружу, но строго по вашим контрактам и под его контролем.

Если вы отдаете наружу архитектуру, смыслы и интеграции – вы не аутсорсите, вы отдаете управление своей скоростью.

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

#автоматизация #производительностьтруда