Серия «Фреймворк управления IT-компанией»

Посмотреть на VK video: https://vk.com/video-227120888_456239019

Фреймворк управления IT-компанией — это простая “табличная” модель (или “канвас”), которая позволяет наглядно разложить всё, что происходит в компании:
кто, на каком уровне, за что отвечает, как идут процессы и где происходят сбои.

Ссылки:

• Вот сама экселька.

• Вот ChatGPT-агент для "поиграть" (нужен VPN)

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

Для модераторов: видео, чатгпт-агент, фреймворк, этот текст - все создано мной. Текст создан при помощи ИИ, но опять же - по результатам моего видео.

Для чего нужен такой фреймворк?

• Быстро понять, где у тебя в компании пробелы, конфликты, тупики или “бутылочные горлышки” — от продакшна до бэкофиса.

• Синхронизировать команды: все говорят на одном языке, видно, кто за что отвечает и как пересекаются зоны ответственности.

• Помогает при росте, масштабировании, реструктуризации, подготовке к аудиту, антикризисных вмешательствах.

• Видно не только “что делать”, но и “кто должен делать” — для всех функций: Dev, Support, HR, Finance, Sales и т.д.

Как пользоваться на практике?

1. Берёшь свой кейс — например, “у нас баги в проде и никто не хочет их чинить”, или “очередь на оформление сотрудников по 2 недели”.

2. Раскладываешь по канвасу: кто, на каком уровне, в каком домене вовлечён; что делается, что не делается, где стоп.

3. Ищешь “красные зоны” и противоречия: где процессы буксуют, где функции не договариваются друг с другом.

4. Для каждой проблемы можно подобрать решение (например, через ТРИЗ — классические способы разруливания конфликтов и противоречий: автоматизация рутины, перераспределение ролей, изменение процесса и т.д.).

5. Собираешь дорожную карту изменений: кто и что должен сделать, чтобы ситуация сдвинулась.

Для кого это?

• Весь C-Level любой компании: CEO, CIO, CMO, CAO, CFO, CDTO, CTO, тимлиды, руководители групп, руководители продуктов, любые менеджеры, которые хотят видеть всю картину и решать не только технические, но и организационные затыки.

• Полезно и для стартапа, и для крупной компании — масштабируется под размер.

Ключевой смысл

Фреймворк — это универсальная “карта”, на которой видно:

• Где у тебя сбой/пробел

• Кого это реально касается

• Как быстро придумать решение и реализовать изменения, не превращая это в “игру в глухой телефон” между командами.

P.S. Можно пользоваться и для “самодиагностики”, и для командной работы — удобно рисовать на доске, обсуждать на планёрках, разбирать кейсы, быстро запускать изменения.

"Это инструмент, который позволяет разложить всю работу компании по ролям и процессам, быстро находить слабые места, понимать кто и как может их исправить. Работает и для Dev, и для HR, и для бизнеса — подходит всем, кто хочет чтобы компания работала как система, а не как хаотичный набор отделов."

Базовая архитектура — 4 уровня + столбцы ("канвас")

Уровни (строки):

1. Рынок/Внешняя среда — откуда появляются идеи (рынок "нанимает" основателей для проверки гипотез).

2. Бизнес/Основатели/C-level — проверка и масштабирование гипотезы (выделяют ресурсы, рискуют, принимают решения).

3. Оперейшенс/Эксплуатация — обеспечение доставки ценности рынку (текущая работа, техподдержка, ручные процессы).

4. Оперативно-тактический уровень — улучшение, разработка, оптимизация процессов (разработчики, аналитики, проектные команды).

Столбцы ("аспекты"):

• Планирование/Управление — что планируем, кто отвечает, как принимаются решения, как устроена оргструктура.

• Технологии/Работа — что делается "руками" (продукт, фичи, процессы, автоматизация).

• Контроль/Взаимодействие — обратная связь, мониторинг, контроль результатов, взаимодействие между уровнями.

• Развитие/Инвестиции — как привлекаются и тратятся ресурсы, как строится масштабирование, due diligence, аудит.

• Триггеры/Процедуры — как меняется команда/процесс при сбое, росте тревожности, выгорании; что делаем при неудаче гипотезы, как перераспределяем роли.

3. Ключевые идеи и примеры

• Рынок генерирует идеи, "нанимает" фаундеров — если гипотеза не взлетает, рынок "нанимает" других или замораживает идею.

• Проверка и масштабирование гипотезы — основатель должен уметь быстро собрать минимальный working product на коленке, протестировать на рынке (пример с "эксельками" за 100 рублей).

• Гибкая оргструктура — фреймворк подходит и для микрокоманд, и для бигтеха (просто уровни будут разного "веса").

• Смысл раздельности эксплуатации и разработки — разработка улучшает эксплуатацию, но не подменяет ее (эксплуатация должна уметь жить отдельно!).

• Документация и процессы — если разработчик не может по документации доставить улучшение в эксплуатацию самостоятельно — значит, команда срослась, и это проблема (особенно опасно в кризис).

• Роль контроля и мониторинга — у бизнеса должен быть "светофор" по всем сервисам, иначе вы не управляете процессом, а гадаете на кофейной гуще.

• Оценка и развитие — регулярный аудит, сравнение план-факта, готовность к инвестициям и due diligence.

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

4. Работа с многодоменностью (многофункциональный канвас/MФОК)

• Любой домен (разработка, продажи, маркетинг, финансы, HR, аналитика и т.д.) можно разложить по этим уровням/столбцам.

• Взаимодействие между доменами и уровнями — источник конфликтов и роста.

• Пример: если финдир не даёт деньги на железо, а CTO не может обосновать — это "жёлтая" проблема (разногласие, но диалог есть). Если постоянный скандал между маркетингом и продажами (некачественные лиды) — это "красная" зона.

• Связка с ТРИЗ: большинство проблем между доменами решаются стандартными ТРИЗ-приёмами (формулируй противоречие, ищи решение по шаблону, патчи по месту возникновения)

— решать конфликты между уровнями управления — от разработчиков до C-level;

— выявлять противоречия проверенными методами (без перелопачивания всей компании и выгорания команды);

— визуализировать функциональную архитектуру компании и точек роста в условиях тотального пиздеца.

Сейчас на рынке зачистка middle-менеджмента, - драка за менеджерские вакансии идёт по 300 человек за место. Невыброшенными на рынок остались только те, кто умеет всё делать руками. Рулят ими не те, кто лучшие, а те, кто верные. На них внезапно обрушилась работа настоящего C-level: стратегические решения, антикризисные шаги, политика, архитектура процессов.

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

Участие бесплатное (пока). Чтобы получить доступ к вебинару, добавляйтесь в чат участников.

P.S. пересылайте своему c-level, коллеги! Будет интересно всем!

Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!

Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.

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

Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.

Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.

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

Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.

— Ошибки у джунов за 25 лет не поменялись. Например, в сервисах рассылок кто-нибудь обязательно стрельнёт тестовым письмом по всей базе клиентов. Иногда и не тестовое. Просто криво настроили environment. И каждый раз это "впервые в истории компании". Поэтому набившие шишки спецы придумали blameless postmortem, sandbox-окружения, A/B, фича-флаги и права доступа.

— Джуны интересны: они растут, впитывают, учатся. Но косячат громко и неожиданно. Сеньоры — безопаснее, но если перезрели, становятся упрямыми и сложными в общении. С любыми старайтесь не разгонять темп, а строить плавный ритм. Плавность важнее скорости. Привет культуре code-review, обратной связи и менторства!

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

— Если IT-компания зовёт к себе и обещает, что вы у них заработаете на квартиру — вас наё%ывают. Всегда. Без исключений. Единственный рабочий путь к "квартире" через IT — это успешные акции (опционы или программы мотивации в акционерных обществах) в быстрорастущих компаниях. Но это исключение, а не правило.

— Среди начальства — от младших тимлидов до верхов — полно случайных людей. Если такой начинает давить авторитетом, истерить или хамить, почти гарантированно: он просто не в курсе сути вопроса, но признавать это не хочет. Слепая уверенность при отсутствии знаний — один из признаков Dunning–Kruger effect.

— Если вы руководите, будьте готовы к свадьбам, рождению детей и, увы, смертям у родственников сотрудников. Иногда — к алкоголикам и наркоманам. Если вы обо всём этом узнаёте заранее — значит, вы неплохой руководитель. Если узнаёте по факту в формате скандала, задумайтесь, не занимаете ли вы чужое место. Здесь важна не просто "информированность", а создание доверительной среды, где сотрудник может вовремя предупредить о личных трудностях.

— Если вы про себя думаете: "я строгий, но справедливый" — скорее всего, вы муд@к. А если вам нормально на планёрке обматерить программиста, который ничего не сделал — вы не просто муд@к, вы ещё и пид@р, которого терпят из страха. Недолго. В Leadership Science известно понятие toxic high performers — люди, которые дают результат, но разрушают культуру. Их терпят до поры. Потом увольняют, когда ущерб становится очевиден.

Всех приглашаю в свой тг канал - https://t.me/ctorecords, там ещё больше постов.