Непонимание причин задающих пределы роста компаний происходит из старых моделей, которые считаются верными. Известно, что компания во время своего роста несколько раз сталкивается со снижением выручки и финансовыми трудностями. Деньги-индикатор. Выручка растет-растет потом бац и остановилась. И ничего не получается сделать. Пока она останавливается на 3 млн рублей можно разобраться. На 50 тоже. Миллиард долларов тоже хорошая цифра, но там и проблемы позаковыристее.

Изменяются ли какие-то модели когда наступают кризисы развития?

Причина ухудшения финансовых показателей снижение общей производительности труда. Оказывается производительность также растет «ступеньками». Есть имперические числа, которые можно измерять в выручке или в количестве людей, работающих в компании (числа Домбара). Где-то примерно эти числа совпадают с численностью воинских подразделений: отделение, взвод, рота, полк… У военных это связано это с критичностью скорости коммуникаций. Есть целые исследования, которые ставят успешность управления в зависимость длины этих команд управления. И понятно, что мат на войне выигрывает.

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

Можно сделать много команд, но тогда количество обрабатываемых данных уменьшится. Можно сделать мало команд. Очевидно, что есть правила, по которым находится оптимум. В других случаях правила для этого оптимума выбираются другие. Хотя часто правила не подвергаются сомнению. Связность кода — это хорошо или всегда плохо?

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

Есть 3–4 больших проекта, которые сложили мое понимание модели ИТ организации. Отладка ИТСМ модели работы линии поддержки в продуктовом Касперском. Отладка CMMI 5 уровня в продуктово-внедренческом Неткрекере. И исследовательский проект в Кастисе. И немножко фоном этого всего производственное планирование по методике ББК теории ограничений. А также ещё пяток проектов, которые связаны с вебом, интернет-магазинами и другими архитектурами бизнеса и человеческим поведением.

ИТ организация в отличие классических моделей имеет дело в умственным трудом. Это в терминах привычных “интенсивностей” и “длительностей”, которые рассматриваются, как базовая величина модели управления, дает разброс производительности в десятки раз. Согласно последним исследованиям мозга отличия способностях разных людей может достигать 40–50 раз. Это означает, что один программист может думать 2 недели, а более опытный решит задачу за 15 минут. К чему это приводит?

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

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

Наиболее опытные специалисты, которые имеют авторитет, игнорируют все что происходит в разработке. Главное и интересное— это релизы. Если внимание сфокусировать на релизах с технарским подходом и углубляться в непрерывную интеграцию с девопсом, то происходит неожиданная деградация службы поддержки. Поддержка не успевает осознать все изменения в продукте. Как-то нужно синхронизировать рост компетенций всей компании. Вместе с процессами управления и передачи информации или по отдельности? Желательно, как-то по-новому. А то опять будет крику, что кипиаи никому не нужны и таймшиты — это зло. Но тут другой учет времени и скорости.

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

Чем плохо, когда оно «сразу всё знает»? Тогда пропадает лидерство. Кто-то уже устал от руководства, а лидера внутри компании, который будет ошибаться и учиться — нет. Люди захотят систему. Система плохая значит будут уходить без всякой лояльности и работать без вовлеченности.

Значит, когда компания дойдет до следующей стадии развития, (вдруг это удастся сделать на технологиях) руководство придется поменять. Все сразу. Оцените риски и затраты. Людей всех придется поменять потому, что они приучены под «старую систему». Хотя в случае, когда компания очень быстро набирает новых людей бывает, что нужно поменять только руководство.

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

В одной компании помню поменяли 9 из 10 руководителей проектов. Половина из них вернулась просто признала, что нужно работать по-другому.

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

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

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

С точки зрения синхронизации например важно понимать, что характер работы фронэнда и бэкэнда разный. Разные циклы работ. Например: дни или недели. Где-то надо запланировать и проработать ТЗ а где-то надо смотреть по месту и корректировать.

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

(Перепечатывается с любезного разрешения автора)