Я бы хотел рассказать об опыте прохождения курса для руководителей организаций, а также о своих наблюдениях после данного курса.

За моими плечами немало лет в разработке: от проектирования и разработки сложных B2B-систем до выполнения различных ролей — от старшего разработчика и техлида до бизнес-аналитика и даже владельца продукта. Было и создание стартапа, который, к моему удивлению, успешно живет до сих пор. Однако недавнее обучение заставило меня сильно переосмыслить взаимодействие между бизнесом и IT-отделом (особенно по разработке).

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

Кому может быть полезна эта статья?

1. Программистам и IT-специалистам (in-house, удаленка, контракт)

Рынок трансформируется сейчас со скоростью звука. Сегодня изолированная инженерная экспертиза («я просто выполняю все по ТЗ») теряет ценность. Например, многое по четкому и подробному ТЗ уже могут делать ИИ-агенты, хоть пока и под присмотром человека-супервайзера. От Senior-разработчиков и архитекторов (а скоро, вероятно, и от Middle) требуют глубокого понимания доменной области, цикла Product Delivery и даже Product Discovery.

Бизнес — это не просто про привлечение лидов. Это сложный процесс: собрать боли клиентов, найти точки входа для решения, разработать продукт, провести QA, доставить его пользователю и извлечь финансовую выгоду. Если вы хотите быть востребованным специалистом, нужно учиться мыслить этими категориями.

Важный спойлер: даже работая в найме, лучше относиться к себе как к независимому подрядчику (отдельному бизнес-юниту). Четко разделяйте зону ответственности, просчитывайте риски для заказчика и предупреждайте о последствиях технических решений. Такой проактивный подход подсознательно прокачивает управленческие навыки, страхует вас от увольнения, а компанию — от провальных релизов.

2. Владельцам бизнеса и управленцам

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

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

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

Проблематика

Попробую обозначить проблему: сейчас мир находится в глобальной экономической неопределённости, и потенциальные клиенты вашего бизнеса (неважно, кто вы — разработчик ПО, предприниматель или наемный руководитель) ведут себя осторожно. Клиенты хоть и имеют запросы и бюджеты, не торопятся их тратить — откладывают до момента «когда реально припрёт», снижая общую кривую спроса.

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

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

• Боль разработчиков: кажется, что их недооценивают; в спринт навалено слишком много задач без нормальной оценки; ТЗ кривые, а бизнес сам не знает, чего хочет. Плюс фрустрация от рынка: «Я знаю крутой стек, пишу чистый код, но не понимаю, как продать свою экспертизу по адекватному прайсу».

• Боль бизнеса: тотальный слив бюджетов и рассинхрон с IT-отделом. Бизнес мыслит категориями ROMI, окупаемости, снижения рисков и скорости проверки гипотез. Разработчик мыслит категориями стека, архитектуры, чистоты кода и закрытых сторипоинтов.

Эта статья — попытка выстроить мост между техническими специалистами и управленцами.

Дисклеймер: Конечно, я не претендую на полное решение столь фундаментальной проблемы лишь одной своей волшебной статьёй, не ждите этого. Однако я попытаюсь, опираясь на призму своего немалого опыта работы в IT, опыта моих друзей и коллег (еще более опытных), а также — что немаловажно — опыта прохождения курса для руководителей, достроить некоторые кирпичики этого моста.

Часть 1. Маркетинг, Личная миссия, миссия организации:

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

Чтобы лучше осознать миссию (и затем без труда перейти к построению бренда), мы составляли личное видение. Нам были предложены различные способы составить и описать свою миссию, чтобы ответить на ключевые вопросы «кто я», «что я делаю» и «зачем я это делаю». Нам дали в качестве домашнего задания составить свою миссию и пирамиду личного видения. Предлагалось использовать таблицы и пирамиды известных бизнес-консультантов — такие как пирамида логических уровней Роберта Дилтса, а также пирамиды личного бренда от Фреда Зигмана и Дженнифер Холлоуэй.

Для начала мы взяли для нашего ДЗ конкретно пирамиду Дилтса и по ней расписали свое видение на 5-10 лет.

Я бы еще добавил здесь японский метод самоопределения Икигай — он более глубинный (хоть и кажется простым), зато даёт намного больше ответов по самоидентификации и личному видению. Когда у вас появляется полное видение, которое согласуется с миссией, у вас появляется план на каждый месяц, неделю и день. Все это раскрывается при видении надцелей на горизонте 5 лет. Надцелями можно назвать большие крупные цели, которые реально вас зажигают, но это уже за рамками данной статьи. Даже если что-то идет не так из-за внешних факторов, вы все равно найдете ресурс делать свои задачи дальше — проверено не только мной, у вас появляется системность и постоянство намерений и действий. Для разработчиков, кстати, Икигай неплохо работает и как инструмент профилактики профессионального выгорания — он помогает вовремя заметить разрыв между тем, что вы делаете, и тем, что вас реально драйвит. Вы получите отличный инструмент убрать прокрастинацию. Здесь все эти методы указаны просто для примера, если у вас есть свой способ чтобы найти личное видение, то применяйте его. Так как на основе этого уже можно и нужно выстраивать маркетинг того что вы делаете.

💻 Наблюдения для IT-специалистов:

Невозможно начать прокачивать свой личный бренд, не ответив на вопросы: «кто вы?», «чем вы отличаетесь от других IT-специалистов?», «для кого именно ваша услуга/работа (подробно, в деталях: какие типы организаций и т.д.)?», «зачем вы в этом мире (при наличии большого числа конкурентов)?» и подобные.

Личный бренд. Невозможно поднять чек на контракте (или оклад в найме, если на уровне вашей идентичности (кто вы?) вы чувствуете себя просто «наемным рабочим» или «винтиком, который работу работает»). Личный бренд нужно развивать, хоть коммитами в GitHub, хоть дельными комментами на Хабре :)

Тут имеется в виду не только пересобрать свою профессиональную визитку, резюме и другие внешние витринные атрибуты, сколько проделать фундаментальную работу со своим профессиональным позиционированием: расписать, понять и увидеть суть того, что вы несете в этот мир, чтобы у вас в идеале начал вырисовываться план на минимум 5, а лучше 10 лет развития.

Однако просто расписать это все, как в абстрактных теоретических фреймворках, — мало. Нужно еще иметь план действий по приближению к своей миссии и выполнять его систематически каждый день (отсюда и будет расти дисциплина, и уходить прокрастинация).

Прохождение курса помогло мне по-новому взглянуть также на управление разработкой и связать маркетинговые цели компании с архитектурными решениями

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

Все начинается с тех же вопросов, что и для сотрудников. Не ответив на базу и не расписав миссию организации (например, по пирамиде Дилтса), дальше нет смысла что-либо делать, совсем.

Сначала нужны ответы на вопросы: «Что делает организация?», «Зачем это делает?», «Для кого именно ваш продукт или услуга?», «Чем эти люди занимаются?» и так далее. Казалось бы, банальные вопросы, и по логике вещей организация должна знать на них ответы сама по себе. Однако же многие организации недостаточно хорошо прорабатывают это… Если этого нет на бумаге или в электронном виде, то, значит, этого, видимо, нет.

Нужно попробовать отказаться от подхода, при котором из разработчиков выжимают все соки. Если вы не дадите ИТ-специалисту четких метрик и прозрачных условий (в том числе по мотивации), не наладите контроль, доверие и распределение ответственности — система будет копить технический долг и рухнет при масштабировании. В каких-то компаниях, где я работал, были четкие критерии мотивации и аттестации (и повышения оплаты разработчикам). Однако, положа руку на сердце, в большинстве компаний не было столь четких критериев мотивации для разработчиков (или они работали не так, как ожидалось). Знали бы вы, как рвется доверие в тылах компании, если учесть современную инфляцию и то, что большинство разработчиков — интроверты, для которых поднять тему оплаты (если нет четких прописанных правил) само по себе огромный стресс.

Просто закончу этот абзац принципами из миссии IBM:

1. Преданность успеху каждого клиента;

2. Инновации, значимые для всего мира;

3. Доверие, уважение к сотрудникам и личная ответственность во всех взаимоотношениях.

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

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

Довольно фундаментальное исследование на эту тему проводили экономисты Пьер Каух и Ян Албер из Института экономики труда. Оказалось, что для некоторых стран (в том числе России) если бы уровень обобщенного доверия был выше хотя бы на 20–30%, то экономический потенциал и ВВП могли бы быть выше — чуть ли не на 70–80%. С этим можно спорить, но у меня нет оснований не доверять этим данным.

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

Часть 2. Тренды и Стратегическое планирование

На второй встрече глубже обсудили тактику («прямо сейчас») и стратегию (видение на 5 лет вперед, в идеале на 10).

Базой для стратегии является результат из предыдущей части – понимание миссии и личного видения. Ответы на вопросы: «Кто мы?» и «Чего мы хотим, что делаем (для кого/чего)?» и тд. На это уже накладываются много других факторов, такие как:

Умение анализировать макротренды (ИИ, импортозамещение, и так далее), открытая аналитика и данные по стартапам и инновациям на различных ресурсах (RB.RU, открытые данные Фонда содействия инновациям, Product Radar, AngelList, F6S, Gust, Y Combinator и другие, особенно нужно уделять внимание локальным трендам), микротренды, сигналы различной силы, исходящие от рынка (как идет найм, поиск, увольнение работников и сотрудников). Трезво оценивать хайп вокруг технологий и не только технологий.

Можно грубо сказать, что за решение тактических вопросов отвечает Agile методология (и прочие штуки), в которой нужно нынче разбираться не только людям из IT. Хотя Agile, это лишь — часть тактики. Идеальной художественной иллюстрацией сочетания стратегии и тактики является «Вокруг света за 80 дней». За стратегию отвечает Фогг (хоть и так себе), а за тактику Паспарту (идеально). Паспарту — классический пример Agile методологии: решает быстро одну задачу за другой, по мере их появления, и быстро передает результат стратегу. Получает новую задачу. При этом возникает вектор движения, без которого Фогг никуда бы не добрался. При этом сам Паспарту периодически путается во многом и без стратега бы тоже мало что хорошего у него вышло. То есть настало время, когда каждый сам себе и Паспарту, и Фогг.

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

Предыдущая же команда разработки посовещалась с заказчиком и предложила этот сырой React Native for Web. Во многом это было настойчивое пожелание заказчика в ТЗ — иметь единую кодовую базу. Однако задача зрелой разработки — вовремя и настойчиво рассказать риски и отговорить от сырых технологий, чего сделано не было.

Поскольку планировалось, что одна кодовая база будет использоваться как под iOS и Android, так и под Web. Да, делался упор именно на мобильные версии в перспективе. Однако мобильная версия не требовала каких-то серьезных низкоуровневых обращений к железу. Именно для этих целей лучше мог бы на тот момент подойти Ionic Framework (по крайней мере точно для успешного старта продакшна и обрастания первыми тысячами пользователей), который был на тот момент намного более предсказуем для прода, также по факту сильно более прост и быстр для разработки (особенно в плане кросс-платформенной совместимости). Хоть Ionic имеет компромиссы в виде работы с железом.

В процессе доработки постоянно приходилось изобретать какие-то велосипеды, чтобы данная библиотека работала согласно ожиданиям, терялось время. Так ещё и в момент выпуска в продакшн и появления новых первых пользователей в системе вскрылось очень много не просто багов, а серьёзных архитектурных проблем, которые при имеющихся ресурсах было исправить весьма затруднительно. Так как она всё равно не давала полной стопроцентной кроссплатформенности. Стоит ли говорить о расстройстве заказчика в этот момент? В общем, тот случай, как раз, когда приходится тушить пожары в абсолютно ненужном месте. Хотя сама по себе библиотека прекрасная, но её звёздный час наступил только через года 3, когда она окончательно интегрировалась в Expo.

💻 Наблюдения для IT-специалистов:

Когда вы предлагаете заказчику технологическое решение, фреймворк и так далее, стоит учитывать Кривую Гартнера (Gartner Hype Cycle), посмотрите, где это решение находится. Например, если технология на «Пике завышенных ожиданий» или падает в «Долину разочарования» — вы подставляете клиента. То же касается и пет-проектов на хайповых технологиях: если делаете их просто чтобы изучить эти технологии, можете легко потерять свое время.

Сюда же можно отнести оверинжиниринг. Хоть выглядит и банально, но вполне вероятно, Kubernetes в проекте не нужен, если для задач достаточно стандартной контейнеризации в Docker.

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

Например, даже если дело касается разработки UI, и дизайнер рисует что-то слишком хипстерское, то нужно попробовать убедить руководство или заказчика использовать Эвристики Нильсена, они являются универсальными для большинства пользователей.

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

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

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

Безусловно, для быстрой валидации продуктовых гипотез в B2B-сегменте можно и нужно использовать легковесные подходы. Например, оркестрацию процессов через n8n или делегирование рутины AI-ассистентам при создании базового функционала на современных стеках. Однако мой опыт показывает, что в таких случаях лучше с первого дня закладывать API-first подход и модульность. Это позволяет не «выкидывать код на помойку» после проверки гипотезы, а бесшовно заменять low-code узлы на высоконагруженные микросервисы по мере роста транзакций, сохраняя жесткие стандарты безопасности и отказоустойчивости.

Про SWOT-анализ…

SWOT-анализ нужен всем: обязателен для предпринимателей и руководителей (и конечно фрилансеров) и даже нужен для наемных работников.

Слово «SWOT-анализ» слышали абсолютно все, кто хоть немного знаком с бизнес-терминологией. И в 90% случаев его делают неправильно. Классическая ошибка — сесть перед пустым листком и начать выписывать свои хаотичные мысли: «Ну, экономика сейчас непонятная (риск). Налоги высокие. Зато я креативный (сила)». На выходе получается бессмысленный набор банальностей, который никак не помогает бизнесу принимать решения.

Главное правило стратегического планирования: Мусор на входе — GIGO, мусор на выходе (Garbage In, Garbage Out).

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

Давайте разберем эту цепочку «на пальцах», чтобы стало все понятно:

Как устроен конвейер стратегического анализа: Пошаговый гайд

Весь процесс движется сверху вниз — от сбора сырых фактов к точечным стратегическим решениям:

1. Идентификация стейкхолдеров (Верхний уровень): Мы четко определяем, для кого и ради кого проводится анализ (заказчики, клиенты, партнеры, команда, инвесторы).

2. Пять фильтров внешней и внутренней среды (Уровень фундамента):

• КФУ (Ключевые факторы успеха): Сравнение с лидерами рынка по критическим параметрам (наличие ТЗ, фиксированная смета, скорость техподдержки).

• SNW-анализ: Оценка внутренних ресурсов (Strong — сильная позиция, Neutral — нейтральная, Weak — слабая).

• 5 сил Портера: Оценка давления рынка (власть покупателей, влияние поставщиков софта, демпинг конкурентов).

• PESTEL-анализ: Макрофакторы (законодательство, ФЗ-152, налоги, регуляторы, общая экономика).

• Матрица «Продукт — Рынок»: Четкое сопоставление типа услуги (кастомная разработка, консалтинг, продуктовое решение) и сегмента (микробизнес, Enterprise, госсектор).

3. Агрегация в SWOT (Квадранты S, W, O, T): Данные из фильтров КФУ и SNW автоматически формируют наши Внутренние силы (S) и Слабости (W). Данные из Портера и PESTEL определяют наши Внешние возможности (O) и Угрозы (T). Никакой отсебятины, предположений и домыслов — только факты из предыдущих шагов.

4. Поэлементный SWOT и Стратегические альтернативы: Мы скрещиваем факторы между собой (например: Силы + Возможности) и получаем пошаговый план конкретных действий (Что делать? От чего защищаться? Куда и что инвестировать?)

Как же спроектировать этот анализ, если объем вам кажется огромным и непосильным? – Конечно с помощью ИИ.

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

Используйте искусственный интеллект как стартовый бустер.

Задайте ИИ правильный контекст: «Ты — профессиональный бизнес-консультант. Я — фрилансер/наемный работник/предприниматель, занимаюсь вот этим. Помоги мне составить первичную матрицу PESTEL и 5 сил Портера для моей ниши». Вот вводные данные…

То же самое сделать для других анализов, и потом все «скомпилировать» в SWOT-таблицу. Однако…

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

То есть вручную провести аудит конкурентов — зайти на условный Авито (это просто пример, возьмите более подходящий ресурс, где вы продаете свои товары или услуги) или сайты конкурентов (или другие открытые данные), выписать их реальные цифры/факты, изучить/понять их УТП, проанализировать их отзывы и боли их клиентов.

Зачем это нужно конкретно вам?

💻 Наблюдения для IT-специалистов:

С кем вы себя сравниваете: Вы должны проводить этот анализ, сравнивая себя с другими специалистами вашего уровня на рынке. Главный инсайт: Этот инструмент покажет, почему вы уперлись в финансовый потолок. Вы можете обладать колоссальным техническим стеком и опытом (Сильная сторона — S), но если у вас тотальный провал в навыках продаж или презентации продукта (Критическая слабость — W), вы так и будете продавать сложнейшие системы дешевле тех, кто более наглый и упакованный в плане маркетинга. SWOT покажет, какие конкретно софт-скиллы вам нужно прокачать прямо сейчас, чтобы поднять свою стоимость на рынке.

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

Это просто жизненно необходимо!

С кем вы себя сравниваете: Вы сравниваете свою компанию исключительно с прямыми и косвенными бизнес-конкурентами в вашей нише.

Вот как эти стратегические инсайты отражаются на бизнесе и процессах: грамотный анализ рынка четко показывает, стоит ли вкладывать огромные деньги в создание массовых «коробочных» продуктов, где есть огромный риск попасть под каток Big Тех — гигантов. Гораздо рациональнее уйти в высокомаржинальную премиальную кастомную разработку под узкие ниши — например, сосредоточиться на кастомных CRM для отельного бизнеса или медицины. Если у вас есть личная экспертиза в этих сферах, она станет серьезным весомым преимуществом и барьером для других игроков, а инвестиции в разработку окупятся, а не сгорят в заведомо проигрышной войне с гигантами или с другими просто сильными игроками в конкретных нишах.

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

Наконец, SWOT-матрица дает прозрачный и измеримый ответ на важнейший управленческий вопрос: кто по приоритету нужен компании прямо сейчас? Она четко подсветит, нужно ли инвестировать в сильного IT-архитектора (чтобы навести порядок в коде и разблокировать производственные мощности) или в сейлза — или же наоборот, покажет, кого нанимать точно не надо, спасая компанию от раздутого ФОТ.

Часть 3. Траблшутинг и Риск-менеджмент. Перестать бояться и начать действовать эффективно и проактивно.

Обсудили риски и решение возникающих проблем.

Постулат: работа вслепую, не осознавая риски, — скорее всего, закончится плохо. Может пронесет, а может и нет.

Главная ошибка при управлении рисками — игнорировать их из-за страха или оппортунистического подхода, когда риски проще принять, чем исправлять.

Алгоритм проработки любого риска (это может быть как осознаваемый, так и не осознаваемый страх):

1. Тотальный сбор: Выписать абсолютно все риски и страхи, приходящие в голову. Не менее 10-11, лучше больше.

2. Экстремальный сценарий: Докрутить риск или страх до худшего реального сценария.

3. Для каждого риска обозначить два числа по двум осям. 1-я ось — вероятность возникновения, значения от 1 до 5. 2-я ось — степень ущерба, последствия, тоже от 1 до 5.

4. Проранжировать их по стандартной матрице рисков, которая используется в бизнес-консалтинге. Пример — тут

5. Обратить внимание на те риски, которые попали в красную зону (можно также обратить внимание на риски в желтой зоне, но ближе к красным), и отдельно их осмыслить.

6. Взять диаграмму Исикавы (для примера) и расписать риски как основные боковые кости рыбы. Должно получиться по 2-3 с каждой стороны, итого 5-6.

7. Далее для каждой кости и для каждого риска написать несколько шагов и способов его решения, то есть подкости для каждой кости.

8. Смотрим на получившуюся «майнд-рыбную-карту» и просветляемся. В идеале вы должны почувствовать себя легче от того, что осознаёте, как решать риск, который беспокоил.

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

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

💻 Наблюдения для IT-специалистов:

Попробовать рассмотреть себя не просто как работника, а как компанию-подрядчика: Суть — рассматривайте себя как независимый инженерный юнит, оказывающий консалтинговые и интеграционные услуги вашему бизнесу. Вы не просто пишете код, вы управляете рисками и бизнес-процессами на своей стороне (Аналитика, PM, Архитектура, Разработка, QA). Если бизнес спускает требования, которые ставят под угрозу стабильность системы или выходят за рамки SLA, то ваша задача — проактивно эскалировать проблему! Оцифруйте риски, предложите альтернативные решения и архитектурные паттерны или фазирование проекта. Эффективная работа строится на прозрачности и управлении ожиданиями, а не на героическом выгорании в попытках успеть к нереалистичному дедлайну. Лучше максимально аргументированно указать, что вы не можете сделать подвиг, а потом немного превысить ожидания заказчика.

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

Вот как системный подход к рискам защищает компанию на практике.

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

Чтобы внезапный уход сотрудников не парализовал компанию, процессы должны быть завязаны на жесткие PM-инструменты (task-трекеры, регламенты, контроль веток кода в Git), а не на «незаменимых» людей. При таком подходе замена человека происходит быстро и безболезненно для темпа разработки продукта.

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

1. Дробление информации: Сотрудник видит только свой изолированный модуль и не имеет доступа к сквозной бизнес-логике, общей архитектуре или клиентской базе.

2. Юридический контур: Права на интеллектуальную собственность, жесткие NDA и договоры фиксируются заранее, максимально защищая ваш бизнес.

Часть 4. Позиционирование и маркетинг

На занятии обсудили известную концепцию в маркетинге 4p, то что она является основой маркетинга в серьёзной организации. Эта концепция образована от четырёх английских слов p — Product (Продукт), p — Price (Цена), p — Place (Место), p — Promotion (Продвижение). Также есть другие концепции: например 7p, там где добавляются p — Process (Процесс) p — people (Люди) p — Physical Evidence (Физическое окружение).

Также то как происходит процесс от выявления маркетинговых потребностей, до продаж и какое место в этом занимает имплементации программного продукта.

Если рассмотреть всю цепочку доставки ценности то мы можем выделить в маркетинге также четыре важных кластера. 1й — стратегический менеджмент в начале (блоки: выявление потребностей, ценностей, продуктовых нормативов), в конце тактический менеджмент (блоки: работа на рынках и работа с потребителями). Их соединяют 2 кластера инновационный менеджмент (блок: разработка продукта) и производственный менеджмент (блок: тестирование и получение обратной связи от пользователя)

Маркетинговые исследования без иллюзий: Валидация через данные

Маркетинговые исследования сводятся к двум фундаментальным вопросам: «Кто точно наш клиент?» и «Кто точно НЕ наш клиент?». Тут важна не только постоянная сверка с реальными данными от частных слов и запросов в поисковых машинах, до попадания в открытой статистике информации с бизнес платформ и реальных собранных данный для организации (да хоть снова тот же Avito можно взять для наглядности если данные с него могут быть для вас релевантны).

Важно также сделать сегментацию и ценообразование:

Далее необходимо отсегментировать вас для ваших клиентов в данной известной схеме из четырёх квадратов — Price Quality Matrix.

💻 Наблюдения для IT-специалистов:

Если вы чётко понимаете, какую именно ценность закрывает ваша задача и код по всей цепочке ценности, то это очень хорошо. Если нет — не стесняйтесь спросить аналитика, продуктового дизайнера, PM или того, кто ближе к бизнесу, возможно даже собственника, если компания маленькая. Спросить: «зачем это делается?», «какую проблему решает?», «почему так?». А если вы узнаете или сможете прикинуть в деньгах, сколько стоит ваша фича, то и мотивация, и ответственность у вас несомненно прибавятся.

Если в вашей работе так или иначе присутствует T&M, или вы проставляете отработанные часы строго по отчетности, ваша главная задача — обеспечивать прозрачность и предсказуемость для заказчика. Четкое соблюдение ТЗ и фиксация границ своей ответственности — это то, что отличает профи от начинающего. Лучше оценить свою работу с запасом, чтобы не подводить бизнес. Прозрачность оценки — это метрика зрелости инженерной культуры. Любая фича должна оцениваться не только в часах, но и через призму FinOps: как она повлияет на потребление ресурсов и стоимость поддержки. Если требования бизнеса выходят за рамки согласованного скоупа и реальности, задача сеньора и архитектора — не строить эмоциональные баррикады, а грамотно управлять ожиданиями. Мы подсвечиваем бизнесу стоимость изменений и технологические риски, предоставляя данные для принятия решений, а не уходим в глухую оборону.

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

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

Вот как это выглядит на практике, если перевести на язык процессов:

До начала разработки должен быть виден четкий контур продукта. Многие гипотезы сегодня можно и нужно проверять вообще без единой строчки кода. Это спасает компанию от слива бюджетов и не позволяет команде выпасть в бесконечный цикл выпуска фич, которые рынку окажутся просто не нужны.

Четкое техзадание нужно иметь и в голове, и на бумаге, чтобы команда разработки всегда видела конечную точку. Никакой Agile не поможет, если команда не понимает, куда плывет лодка. Сформировать этот контур можно в том числе благодаря маркетингу — тогда команда двигается кратно быстрее, не теряя времени.

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

Часть 5. Бренд

Для бренда, как было сказано, точкой отсчета является миссия и личное видение.

Бренд строится строго сверху вниз — от содержательно-идеологической части к тактическим инструментам:

Брендинг — это не только дизайн и логотип, а архитектура смыслов.

Брендинг — это процесс, который связывает «высокую» миссию компании с приземленными задачами в спринте.

1. Ядро: Миссия (главное обещание и посыл бренда) и его ценности (рациональные и эмоциональные). Они формируют устойчивый имидж (образ) у потребителей.

2. Система идентификации (Фирменный стиль, к программистам не относится): Логотип, шрифтовые пары, цветовая гамма, корпоративная культура, стандарты документации, интерьер и даже униформа сотрудников. Они выполняют три функции: повышение узнаваемости/репутации, вызов прямой ассоциации с фирмой и отличие от конкурентов.

3. Система продвижения (Тактика): Реклама, специальные акции, работа со СМИ, развитие бренда (в том числе и личного).

Эволюция любого визуального решения идет по цепочке: Логотип (знак) → Фирменный стиль (правила сборки и шрифты) → Айдентика (корпоративная среда) → Бренд (ментальная ценность в голове потребителя).

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

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

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

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

Совпадение по ценностям дает и конкретный бизнес-результат: вы получаете не просто исполнителей, которые вяло работают ради зарплаты, а команду, которая выдает максимальную эффективность и осознанно двигает продукт вперед.

Часть 6. Бизнес-процессы и управление проектами

Рассмотрим важную триаду: Проект, Процесс, Продукт.

Главное, к чему стоит стремиться: в идеале бизнес должен быть таким, чтобы его можно было передать или продать как закрытый, собранный чемодан, который работает без ручного вмешательства фаундера. Готовый к дальнейшему использованию.

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

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

Отличия

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

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

Продукт: Готовый товар или услуга, несущие измеряемую ценность для рынка. Конкурентоспособность продукта держится на трех китах: цена, ассортимент и дополнительный сервис (скорость доставки/кастомизируемость/и т.д.).

Алгоритм работы с процессами:

1. Выберите критически важный или проблемный процесс (например, обработка заказа клиента, прием на работу).

2. Опишите его «как есть» со всеми деталями и участниками.

3. Проанализируйте слабые места, потери, риски.

4. Спроектируйте улучшенную версию «как должно быть».

5. Внедрите изменения, обучите людей.

6. Начните измерять ключевые показатели до и после изменений.

Пример описания процесса — воронка продаж: Четко определить стадии, которые проходит лид. Определение критериев перехода: какие условия должны быть выполнены, чтобы лид перешел на следующую стадию? Описание действий на каждом этапе: что конкретно должен сделать менеджер (звонок, письмо, презентация, расчет КП, отправка договора)? Определение ответственных: кто владелец процесса? Кто выполняет задачи на каждом этапе? Определение входов/выходов: какая информация нужна на входе этапа? Что является результатом этапа? Документирование: создание регламента, схемы процесса (BPMN, простая блок-схема).

💻 Наблюдения для IT-специалистов:

Снова возвращаемся к важному моменту: относитесь к своей работе (даже в штате на окладе) так, будто вы — независимый контрагент для своего работодателя.

Выпишите все свои внутренние процессы на бумагу (или электронно) — честно, без эмоций и придумываний. Распишите роли, чтобы понимать, кто за что отвечает. Сразу станет видно, где и что неэффективно.

Вот как этот подход сказывается на реальной разработке:

Масштабируемость бизнеса напрямую зависит от того, насколько ИТ-процессы отвязаны от конкретных людей. Если вы видите узкое место, ваша задача как техлида — спроектировать автоматизированный workflow, который устранит человеческий фактор, а не просто жаловаться на хаос.

При проектировании архитектуры — например, B2B SaaS-решений или систем рассылок на микросервисах — критически важно исключить ручное вмешательство: когда процессы зашиты в автоматизированные пайплайны CI/CD, IaC и строгие регламенты, работа идет без остановок.

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

👔 🎯Наблюдения для владельцев бизнеса и управленцев:

Вы никогда не поймете, почему процесс приводит к неэффективному расходу бюджетов и времени, если не расписать его максимально подробно. В идеале — с BPM-схемами, со всеми деталями. Главное — еще расписать роли: у кого какая роль на проекте. У одного человека может быть несколько ролей, как говорили. Только когда пройдёте по каждому шагу воронки/каждому звену бизнес-процесса, увидите: где реально можно улучшить, на каком этапе и как вообще замерить эффективность на входе и выходе. А если всё это держать в голове — оно так и будет без конца буксовать, и эффективнее не станет.

Часть 7. Команда и KPI

Важность психологии и эмоционального интеллекта (EQ)

Команда — это не роботы, а живые люди. Чтобы управлять командой эффективно, нужно уметь работать как со своими эмоциями, так и с эмоциональным состоянием окружающих.

Для наглядности можно вспомнить колесо эмоций Роберта Плутчика:

• Пик интенсивности (внутренний круг): Если коллега находится на пике (в ярости или панике), конструктивные уговоры не сработают. В этом состоянии бесполезно апеллировать к логике.

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

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

Эмоциональный контакт. Чтобы по-настоящему замотивировать инженера, одной лишь интересной задачи порой недостаточно. Иногда стоит просто сесть, собрать качественную обратную связь и поговорить по душам. Построение эмоциональной связи с разработчиками позволяет нащупать их истинные драйверы — то, от чего у человека действительно «горят глаза». Найденная точка мотивации впоследствии может стать основой для прозрачных и органичных KPI.

Пример: разработчику банально не хватает видимости результатов своего труда, из-за чего нарастает выгорание. В B2B-продукте стоит наладить его плотное общение с аналитиками, а в B2C — с маркетингом, чтобы инженер получал живой отклик от пользователей и понимал реальную ценность внедряемого функционала.

Для любого процесса можно и нужно выстраивать систему KPI с учетом ролевой модели исполнителя. Составление базовой матрицы (например, оценка релиза функционального блока за месяц или два спринта с суммарным весом показателей equal 1) — стандартная практика, подстраиваемая под специфику конкретного проекта.

💻 Наблюдения для IT-специалистов

• Если в компании есть понятные KPI: Это хороший показатель при условии, что метрики реальны, а не взяты с потолка. Прозрачная система дает предсказуемость и уверенность в завтрашнем дне. Внезапное введение KPI далеко не всегда означает подготовку к сокращениям — чаще всего руководству требуется объективный инструмент для справедливого расчета вознаграждения.

• Если KPI отсутствуют: Ситуацию можно обсудить с техлидом или менеджментом, опираясь на средние показатели команды. Оцените, сколько задач и смежных вопросов (архитектура, помощь коллегам, рефакторинг) закрывается за спринт. Это поможет объективно откалибровать уровень своей производительности.

  Важно: Линейный подсчет закрытых тикетов искажает мотивацию и вредит качеству. Зрелые команды опираются на инженерные метрики (например, DORA: Deployment Frequency, Change Failure Rate, Mean Time to Restore).

Отличным ориентиром для внутренних KPI служат стандарты крупных Open Source проектов: четкие требования к покрытию тестами, качеству оформления Pull реквестов и глубине ревью кода. Инженер должен прозрачно видеть связь между качеством своих архитектурных решений и стабильностью всей системы (SLI/SLO).

👔 🎯 Наблюдения для владельцев бизнеса и управленцев

KPI — это не только инструмент контроля подчиненных. Систему метрик можно применять шире: к контрагентам, заказчикам и к самому себе.

• Фиксированный оклад vs KPI: Жесткая привязка базовой зарплаты к KPI демотивирует инженеров. Базовый оклад должен закрывать нормальный уровень жизни без постоянного переутомления. KPI должен выступать инструментом для получения повышенного дохода (премий и бонусов). Давление строгими таблицами дает обратный эффект, хотя систематическое и кратное невыполнение базовых показателей — может быть поводом для расставания.

• Качество метрик: Слепой подсчет тикетов вреден, так как задачи кардинально различаются по сложности. Сравнение двух Senior-разработчиков исключительно по количеству закрытых задач не дает объективной картины. Метрики должны отражать реальное решение бизнес-проблем, а не гонку за галочками.

• KPI для клиентов: Полезно вести внутренний учет показателей по клиентам (без их прямого уведомления). Это помогает оценить не только выручку от конкретного заказчика, но и реальную маржинальность с учетом сложности коммуникации и затраченных ресурсов команды.

Часть 8. Про ИИ

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

Для технологических организаций сегодня ИИ — это не философский концепт, а прагматичный инструмент ускорения Time-to-Market. Главный вопрос сейчас лежит не в области теоретических дискуссий о разуме машин, а в плоскости эффективной и безопасной интеграции автономных агентов и AI-ассистентов в корпоративный контур.

Основная проблема большинства компаний при ИИ-трансформации: отсутствие системных процессов и критериев успешности внедрения ИИ-трансформации:

• Инженерный эффект: Грамотное применение ИИ для генерации тестов, написания boilerplate-кода или парсинга документации дает колоссальное буст по скорости.

• Безопасность и контроль: Внедрение требует жестких регламентов информационной безопасности (чтобы коммерческая тайна и продуктовые данные не утекали куда не нужно)

Вместо заключения: От хаоса к системе

Прохождение бизнес-курса помогло наглядно систематизировать знания: переход от просто старшего инженера к роли техлида или технического партнера требует кардинального сдвига в мышлении. Уметь писать поддерживаемый код и проектировать архитектуру — это сегодня базовый гигиенический минимум. Настоящая ценность рождается на стыке технологий, маркетингового анализа, управления рисками и операционной эффективности.

Инструменты бизнес-анализа — от SWOT-матриц до продуктовых метрик — это необходимый инвентарь для современного техлида и тем более CTO. Когда IT-отдел начинает говорить с собственником и CEO на понятном языке — терминами окупаемости, рисков и скорости доставки фич (Time-to-Market) — в компании исчезает вечная проблема «непонятых гениев». Вместо нее начинается предсказуемая работа над продуктом.

Времена, когда бизнесу достаточно было нанять программистов, выдать им абстрактное ТЗ и надеяться на чудо, прошли. Сегодня выигрывают те, кто умеет соединять инженерные решения с бизнес-целями.

Интересно узнать ваш опыт: внедряете ли вы бизнес-метрики в инженерные команды и с какими главными трудностями сталкивались при построении системных процессов?

Про автора:

Обычно я занимаюсь проектированием сложной backend-архитектуры и различных систем: E-commerce, кровавый Enterprise (ERP, BPM, DMS и другие ругательные слова), также внимательно наблюдаю за тем что происходит в стартапах, и сам порой в них участвую. Если тема синергии бизнеса и IT вам близка или хочется и есть что добавить из вашей практики — кроме комментариев тут, буду рад обменяться опытом например в LinkedIn: https://www.linkedin.com/in/e-p-ushakov/ или личке в тг https://t.me/Magic_Geny