2 месяца назад я опубликовал в канале пост о ролевых дисфункциях и разделении работы в компании на 3 уровня (стратегический, тактический и операционный). Обещал продолжение с примерами из реальной практики, но совсем запамятовал. Сегодня вспомнил и решил вернуться к этой теме.
Начнем с моего любимого анти-паттерна "наш CTO пишет код". Я его встречал несколько раз и обычно он порождался одной и той же цепочкой событий. Небольшой компании нужен CTO, но хотелось бы кого-то из знакомых и желательно готовых работать "за идею". На примете есть только разработчики с разным уровнем опыта, поэтому выбор падает на одного из них. Причем, зачастую даже без архитектурного или техлидского опыта.
Такой кандидат всю жизнь работал на операционном уровне, изредка возможно заглядывая в тактический. Именно этим он и продолжает заниматься на новой позиции: пишет код, делает ревью, локальный дизайн и т.д. При этом в полной уверенности, что это реально круто, ведь CTO "близок к команде". На практике же это означает, что на стратегическом уровне вообще ничего значительного не сделано и при этом в команде появляется "бутылочное горлышко", тормозящее разработку. А там есть чем заняться: архитектура, нефункциональные требования, стратегия технологического развития, потенциальные партнерские интеграции, презентации, выстраивание инженерных процессов и т.д.
Второй анти-паттерн я называю "заоблачный PMO". Он проявляется когда костяк этой влиятельной организации находится сугубо на стратегическом уровне и не вовлечен в тактику от слова совсем. То есть, люди на 100% выделены заниматься стратегическими задачами и не работают с реальными проектами, командами и продуктами. В результате, такой PMO порождает множество "полезнейших" KPI, оторванных от реальности задокументированных процессов, проектные комитеты и другие ценные артефакты. А вся остальная компания либо находит способы их элегантного игнорирования, либо страдает.
Для улучшения ситуации можно формировать PMO (если уж очень хочется иметь его формально в организации) ислючительно из практиков своего дела, которые минимум на 30-50% занимаются тактической работой. Тогда пропасть между теоретически красивыми идеями и прикладным применением становится гораздо уже.
Последний на сегодня пример будет из близкой мне области консалтинга. Консультантов обычно нанимают для помощи на стратегическом уровне, реже на тактическом уровне. Но бывает так, что заказчику очень хочется закрыть горячую проблему руками консультанта прямо сейчас, потому что из своих быстро никто не справится. Это очень пагубная практика по нескольким причинам. Во-первых, работа консультанта на операционном уровне не исправляет глобальные проблемы в компании, а просто тушит пожары. Во-вторых, даже в успешном случае, масштабировать такой успех самостоятельно будет очень тяжело. В-третьих, большинство консультантов давно работает на стратегическом и тактическом уровне, но не факт что успешно справится с операционными задачами. Ну и наконец, не факт, что консультанту интересно со всей душой работать на операционном уровне.
Поэтому гораздо лучше даже с тушением локальных пожаров справляется подход менторства, когда консультант на тактическом уровне работает с представителем компании, активно участвующем в операционной работе.
Поделитесь в комментариях, с какими интересными проявлениями данной проблемы вы сталкивались на практике, кроме известных power point архитекторов.
