3

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

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

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

Ссылки:

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

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

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

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

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

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

  • Видно не только “что делать”, но и “кто должен делать” — для всех функций: 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 не может обосновать — это "жёлтая" проблема (разногласие, но диалог есть). Если постоянный скандал между маркетингом и продажами (некачественные лиды) — это "красная" зона.

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