Вы понимаете разницу между системным и структурным анализом?

Когда я встречаю какой-нибудь SWOT, матрицы/лестницы Ханта или BCG, или когда мне начинают подсыпать какие-нибудь околонаучные термины, у меня в памяти всплывает эта книга, а точнее, объявленная в ней вступительная статья.

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

Wow-эффект в узком кругу читателей упомянутой выше вступительной статьи можно на новоязе передать так: “Крч, если tl;dr, весь системный анализ строится на трех понятиях: вход, процесс и выход”.

О! Так гораздо проще запомнить. И проще применять - без трепета “что-то сделаю не по учебнику” и с учетом конкретной ситуации.

SWOT строится на понятиях “внутри-снаружи” и “плохо-хорошо”. Перемножаем, получаем “внутри-хорошо” - S, “внутри-плохо” - W, “снаружи-хорошо” - O, “снаружи-плохо” - T. Или Ханта: “знаю - не знаю”, “осознаю - не осознаю”.

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

Зачем? Тут вспоминается реакция знакомой блондинки когда кто-то начинал с ней умничать. “Ты скажи, что ты хочешь” — и наблюдала, как тот пытался скрыть, что он на самом деле хочет.

Да, мы применяем тот или иной набор понятий исходя из того что хотим. И плохо, если наоборот.

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

2000-й год
Я: “Нам нужно систему, где мы фиксируем заявки, по базе определяем ее тип, по типу - нужные входные данные, а также исполнители. Когда занесены входные данные, исполнителям по почте приходят задания. В задании - кнопка, нажимают, когда выполнили”.

ИТ-директор: ”Нуууу… Давай так… Нам нужно будет ТэЗэээ. В тэзэ нужно расписать все процессы… Потом нужно будет выделить бюджэээт. Посмотрим, если что-то есть, закупим, потом будем внедряяять…”.

Я: “Уже посмотрел, ничего не нашел… Процессы у нас постоянно меняются… Бюджет на эту задачу никто не выделит, директор в этом не очень понимает… Но ему нужны поставленные процессы. У всех стоит Outlook, почта, есть сервера, есть MS Access. Нам нужно только это связать…”.

ИТ-директор: “Нет, так не пойдет. Я занимаюсь инфраструктурой, корпоративными сервисами. Программистов не держим. Самописками не занимаемся. Так что помочь не могу.”

Я - еще стажер. Деваться некуда, залез в макросы. Через 2 месяца сделал учетную систему движения имущества на MS Access, и это очень не понравилось ИТ-директору. Но другой не было, и бюджет для него никто не выбивал. Еще через месяц запустил ту самую, где задачи рассылались письмами. Сейчас это называют “workflow”, и это уже баян. А тогда это было из категории “а что, так можно было?”.

На следующий день ИТ-директор стал и.о. генерального… И эту систему сразу убил.

С тех пор меня ИТ-директора не любили, в других компаниях тоже. И оно понятно - что-то тут поставит, напишет, а если уйдет, то кто подхватит… Ставили то, что уже готово, и не будет головной болью. Поэтому тогда ИТ отставала от потребностей управления.

Любопытно, что сейчас ситуация перевернулась. Системы часто дают больше, чем нужно. Знание инструментов является признаком, что есть управленческие компетенция. Если знаешь Jira, скорее всего умеешь в agile…

P.S.
2006-й год.
Компания выставлена на продажу, я - директор компании по M&A сделкам. Меня приглашают изучить компанию.
— А какие у вас информационные системы? — спрашиваю.
— Ну у нас 1С, и еще какая-то старая система учета имущества, не знаем откуда взялась...

Корпоративные шахматы

На первый взгляд история, которая будет ниже, похожа на то, как Давид победил Голиафа путем того, что заDDoS-ил его бизнес-процессы. Но я бы увидел в этом пример иллюзорности того, что в проектировании организаций кто-то “проектирует” кого-то. "Проектирующие" сами являются частью "проектируемого", и в некотором роде получается, что организация проектирует сама себя. Растет как организм исходя из заложенного генотипа и доступных ресурсов.

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

Известная госкомпания, реформируется, подчиненная структура сливается с вышестоящей, формируется новая управляющая компания отрасли. Два C-level начальника имеют пересекающиеся зоны ответственности. Один за систему управления, другой за инвестиции. Пересекаются в системе управления проектами. У первого есть ресурс на консультантов, у второго - нет. Второй по рекомендации привлекает молодого ноунейм-сотрудника, который раньше работал в подчиненной структуре.

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

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

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

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

Первый натиск прошел. Пошла вторая фаза - ноунейм начал выдавать документы, нужно было давать разгромные рецензии. Рецензии пишут, но реакция - “спасибо, поправим”... Тоже не срабатывает…

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

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

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

Они достали всё из ящика и отдали ноунейму. Ноунейм это всё упаковал и вынес на правление. Предправления назвал док добротным и предложил утвердить. Такого не ожидал никто. Тут даже не было стадии “а поговорить”. Это был шах и мат.

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

Ноунейм развернул и запустил все наработки айтишников - корпоративный портал, MS Project - всё, что было куплено, но не использовалось. Выставил ИТ-департамент в выгодном свете, и много лет после этого получал поздравления с днем рождения от ИТ-директора в запрещенной соц.сети.

Расходы на рекламу: 1 310 ₽, результаты:
▫️Показов 950,
▫️Кликов (переходов на лендинг) 106,
▫️Переходов с лендинга на бот 62,
▫️Запустили бот 35,
▫️Загружено резюме 15,
▫️Создали сопроводительных писем бесплатно - 8.

Прошло 3 дня, как я ради эксперимента запустил Яндекс.Директ для “Карьерного консультанта” на минималках. До этого я говорил сам, и слышал от других что-то типа:

есть техническая компетенция, но проблема в маркетинге

По себе знаю, что это просто зона комфорта - не хотим этим заниматься. Привыкли пилить фичи, вот и пилим)

Тщи, разработчики, расширить зону комфорта поможет осознание того, что маркетинг - это такая же техническая компетенция. Сейчас это уже именно так. Кастевы за 5 минут дает ИИ. Креативы дает ИИ. Вы только настраиваете сервисы, которые особо не отличаются от сервисов типа Github или Yandex.Cloud. И нужно расставить метрики внутри продукта (см. картинку). Метрики движения пользователя к вашему продукту вам дадут в сервисах.

Да, про “ИИ может” теперь из каждого утюга, но я проверил) Может почти везде и не всегда сразу… Gamma.app генерит красивые лендинги, но к ним не подключишь метрики. К Тильде можно подключить метрики, но там ИИ генерит тексты лендинга плохо, но хотя бы общий каркас дает быстро, а сами тексты можно в другом ИИ. И так далее.

Настраиваете, тестируете по метрикам. И делаете отладку, если видите слив конверсии.

#buildinpublic

Ошибок бояться не бояться

— Как вы прокомментируете утверждение: “В нашей компании мы постоянно ищем новые решения и подходы. Для этого нужно быть готовым к экспериментам и не бояться ошибок”?
— Ошибками что считаем здесь мы? Развиваться чтобы, экспериментировать и гипотезы тестировать компания должна. Гипотезы подтверждение или опровержение - любой исход достойный. Ошибка здесь — гипотезу подтвердил, а несостоятельной она оказалась потом, либо рабочую гипотезу отбросил. Правильной работе с гипотезами внимание уделять нужно.

На старте известных всем переговоров услышал от Президента фразу “мы получили прививку самостоятельности…”. И сейчас понимаю, что каждый разработчик должен получить прививку маркетинга, чтобы понимать, насколько на самом деле значимы для пользователей те фичи, которые ему кажется интересным запилить.

Выпустив “Карьерного консультанта”, я переключился на учебный курс “ИТ по вызову”, поставив себе задачу не делать его, пока не получу какое-то подтверждение спроса. Должен сказать, с задачей не справляюсь. Спрос не подтвержден, а продукт сделать хочется) Накопившиеся знания “киснут”, теряют актуальность со временем, и просят, чтобы ими поделились.

Что делать? Дожимать упаковку и привлекать пользователей, или пилить курс?

Так какой же у вас продукт?

Такой вопрос часто можно было услышать на каких-нибудь конкурсах стартапов от “эксперта из жюри” в адрес волнующегося докладчика. Мне довелось многократно оказывать в жюри, и я со временем стал отказываться, видя, насколько безответственна и безнаказанна позиция данного “эксперта”. Иногда доходило до “я бы это не купил” или “вы бы лучше сделали…”. Да ты ж не ЦА вообще, кто тебя спрашивает?

Уловка в том, что ценность как луковица - многослойна. Может начинаться с декларации ценности существования компании как таковой (Uber: «Мы переосмысливаем то, как движется мир к лучшему»), эта ценность на своем пути гранулируется, оформляется, упаковывается и заканчиваться какой-то конкретной фичей в приложении. И где-то там по пути можно встретить то, что привыкли называть “продуктом”.

Поэтому когда я вижу, что кто-то застрял в том, чтобы “определить продукт”, я Боже упаси не лезу утверждать “как правильно”. Раз уж умные люди на серьезных щщах могут сказать, что продукт, это то, что упомянуто в чеке в разделе “операция”, значит наука тут бессильна. Поэтому я сразу перехожу к темам:
▫️ давайте вспомним, что есть еще такие слова, как “услуга”, “сервис” (да, одно и то же на разных языках, но нюансы есть), “решения”, “функции” и т.д.
▫️ давайте договоримся о понятиях, которые именно нашей команде будут интуитивно понятны и нам не придется прилагать усилия в коммуникации
▫️ когда будем договариваться о понятиях, давайте определим, к чему мы применяем продуктовые метрики - LTV, retention и другие — по ним мы можем определить общеупотребительный продукт…
▫️ … и быстрее приступаем к работе.

Продукт - это только часть ценности, которую мы несем. Зачастую даже сам процесс продажи продукта (выделение проблемы, предложение решения) сопряжен с предоставлением ценности. Поэтому ценность должна становиться фокусом.

С чего начинать руководить

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

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

Стандартные модели оргпроектирования подразумевают создание вертикалей и горизонталей взаимодействия, в рамках которых управляющие сигналы движутся “сверху-вниз”, а информация о состоянии дел “снизу-вверх”. Зная об искажениях информации руководители создают дополнительные вертикали контроля. Это если упростить и пока не вдаваться в детали о том, что подразумевается под этими вертикалями и горизонталями.

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

Но это ведь не системное решение, это воля и репутация отдельных людей — см. первый абзац. Есть отдельные кейсы, когда получение информации извне ставится как системная задача. Например, на протяжении многих лет запускались отдельные ГИС маркировки и прослеживаемости различных товаров. И потом государство объединило все эти системы и отдало под управление коммерческой структуре (бренд “Честный знак”), которая, насколько я понимаю, внедрила одну ключевую инновацию: добровольная система общественного контроля (мобильное приложение, где потребители могут считывать всю информацию).

В этом месте должен быть какой-то вывод. Но его пока нет.

Результаты или команда

“Тед Лассо” — хорошая художественная иллюстрация противопоставления управленческих акцентов: результаты или команда.

Имеем управленца, который сам плохо ориентируется в предмете деятельности. Ему ничего не остается кроме того, чтобы сфокусироваться на развитии команды. При этом постоянно испытывает давление от руководства — нужны результаты. Управленец “верит”, что сильная команда даст результаты, и выступает “барьером” между высшим руководством и командой. По мере развития сюжета команда продолжает проигрывать, но мелкие результаты проявляются. Управленца не убирают, и на горизонте 3-х лет его ставка срабатывает: команда дает хорошие результаты. Уже в высшей лиге выясняется, что топовые управленцы придерживаются того же подхода — развития команды без оглядки на “wins or losses”.

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

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

Но тут очень легко попасть в ловушку того, что некоторые сотрудники “считывают” эту модель и начинают “играть в развитие”. В итоге ты не развиваешь, а нянчишься.

Как понять, что ты развиваешь команду, а не становишься нянькой, оберегающей сотрудников от “ничего не понимающего руководства”, требующего “необоснованные результаты”?

Я утверждаю, что критерий есть, и он довольно простой. Но об этом в следующий раз.

P.S. Для практикующих языки на сериалах: “Тед Лассо” — хороший пример английского в американском и британском звучании.

Нянчишься ли ты с командой или ее развиваешь, определяется тем, кто больше требует результатов – руководство или сама команда.

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

Принцип выглядит как максима с подвохом.

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

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

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

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

Во-вторых, развивать кого-то или что-то – это немного крайность. Руководитель может проявлять внимание к интересам сотрудников, повышая их лояльность, развивать общую культуру взаимодействия или просто защищать. Этого бывает достаточно. У меня был забавный кейс, когда я только возглавил подразделение и не знал всех процедур, я не отследил сдачу какого-то отчета одним из сотрудников. Мне сказали, что сотрудника оштрафуют, на что я сказал, что штрафовать нужно меня, сотрудника не трогаем. Штрафовать меня у них рука не поднялась, сотрудника оставили в покое, а я получил плюс к карме – другие руководители так не делали.

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

В упомянутом “Тед Лассо” герой “переизобретает” голландский “тотальный футбол” 70-х, смысл которого – игроки постоянно меняются позициями и ролями. Сначала я подумал: “о, аджайл!”, а потом понял, что нет, не совсем. Компетенция аджайл и “кросс-функциональные команды” - это быстро создать минимально работоспособную команду (minimally workable team, MWT – не благодарите). А тут больше похоже на то, что сейчас именуется “T-образные сотрудники” (T-shaped): люди с глубокой компетенцией в одной области, и средними – в смежных областях.

Автотесты и довольный начальник

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

Если вы маленькая компания, результат работы практически не нужно декомпозировать на подразделения по разным BSC, дереву целей или каким-то еще фреймворкам.

Очень продвинутые - это значит у вас выполнена декомпозиция и построены процессы управленческого мониторинга. Вроде выглядит как управленческий “must have”, но на практике это редкость и вот почему.

Возьмем пример из программирования. Есть такое понятие “автотесты” - программный код, который проверяет работу другого программного кода. Используется там, где повышенные требования к надежности, например, в банковских приложениях. Общее правило: если вы заказываете разработку с применением автотестирования, можете смело умножать бюджет на два.

Аналогично с компанией. Вот вы провели стратегическую сессию, выписали цели, поставили иерархию (или применили еще какой-то стратегический фреймворк), определили метрики, словили инсайт/дофамин, разъехались и ничего не работает. Ибо метрики должен кто-то считать, делать это с какой-то регулярностью, у него должны быть инструменты, ресурсы, входящая информация для метрик. И это должно быть отдельно от основных процессов. Т.е. строится организационная ветка, которая замеряет работу “основной” организации. Это не ее полный дубль, но заметная часть.

Часто ли мы это видим? Нет… Поэтому зачастую в средних компаниях “результат” естественным образом сводится к “довольный начальник”.

Этот короткий цикл постов начинался с заголовка “Результаты или команда”. Слова, используемые нами как очевидность, или слышимые как лозунги: “мне нужны результаты” или “нужна команда”. И получилось, что мы довольно редко имеем дело с результатами и командами в “чистом виде”. Как свет, проходящий через призму, дает спектр, так и с понятиями, которые мы используем – всмотревшись, получаем спектр их различных проявлений. Чтобы работать, нужно каждое понятие пропускать через призму “что конкретно имеется в виду”.

“Убить босса” – заметил краем глаза то ли корешок, то ли обложку книги, проходя по разделу экономической литературы в “Библио-глобусе”. “Кликбейтный” как сейчас говорят. Не стал смотреть, куда-то торопился. Да и не хотелось – тогда я впервые сам стал “боссом” – возглавил небольшую компанию. Компания была в убытках, собственник решил, что хуже не будет, пусть попробует.

С того момента жизнь стала делиться на четкие циклы: как к 1-му числу месяца накопить денег на аренду офиса, как к 10-му иметь достаточно денег для выплаты зарплат. А иначе нельзя: нужно показывать, что в компании все норм, иначе разбегутся — кругом все компании растут. Ну и конечно, был наивен и глуп, закрывал “кассовые разрывы” 🤦‍♂️ из личных средств, в надежде вернуть позже. И еще эта странная полоса отчуждения между тобой и коллективом.

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

Поэтому тогда, 19 лет назад, выходя из Библио-глобуса, и до сих пор в отголосках в голове пульсировал вопрос: “За что?”

Это замечают на встрече одноклассников

Самое большое открытие в части образа жизни за последний год – это вода. Ну да, как и все я знаю, пейте больше воды, stay hydrated и все такое. Думал, ок, по утрам выпиваю большой стакан воды, а дальше по желанию.

Оказалось нет. Пить воду только когда испытываешь жажду, это все равно, что принимать душ, когда уже все чешется.

Пить воду (именно воду, а не чай или пиво) нужно в таком объеме, что для того, чтобы это не бесило постоянным желанием в туалет, нужно определиться с циклами, как с едой. Выявляется не сразу и индивидуально. Но зато организм начинает “промываться” изнутри. По крайней мере, такой образ у меня рисуется.

Эту мысль мне втолковывала врач-нефролог, которая заодно почему-то решила поработать психотерапевтом. Убедила. Я попробовал. Готов рекомендовать.

Набираешь двухлитровую (я беру больше) бутыль утром, и задача к вечеру выпить.

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

Ну… а на встрече одноклассников тебе говорят, что ты хорошо выглядишь)

“Ясное, как солнце…”(с) определение стратегии (нет)

Наблюдаю примечательный феномен. В одном паблике, посвященном организационным стратегиям, несколько раз делаются акценты на том, сколько – 20, 30, 50 – определений понятия стратегии было найдено в различных источниках. Даже был эксперимент с обобщением определений с помощью ИИ.

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

— Зачем нам нужно определение стратегии?
— Почему так много определений?
— Что делать в ситуации, когда много определений?

На первый вопрос вроде как ответ понятен: понятие применяется в коллективе и требуется какая-то конвенция, что под этим понимать. Конвенция, в свою очередь, может опираться на то, как “правильно” (т.е. на конвенцию, принятую в неком объемлющем обществе), либо на то, как “удобно”. Для обслуживания первого варианта и происходит выработка определений.

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

На 3-й вопрос - конечно же нет смысла пытаться дать 51-е (“самое правильное”) определение. Фиксируем как факт, что работаем со множеством представлений. Договариваемся или обходим стороной – обсуждаем на уровне личного восприятия.
Что-то вроде того, что “стратегия” – это что-то про принятие решений, требующих длительной реализации, но не план. (Это я сейчас не определение давал, а восприятие описывал.)

Какой из этого “руководительский вывод”.
– Оказавшись в компании, можно предварительно оценить культуру: там тяготеют к “правильному” или без разницы.
– Если к “правильному” - ок, это не нужно ломать, просто подобрать нужное “правильное”.
– Если без разницы - не торопиться с внедрением представлений, не спешить насаживать искусственно. Они созреют в совместной практике, и будут более органичными и рабочими.

А практику нужно создавать.

В пятницу выложил в открытый тест ИИ-бота для медицинской клиники. Беседа о симптомах, оценка релевантности пользователя, запись на прием - стартовый набор ожиданий от ассистента. Первый клиент - клиника лечения варикоза.

В этом проекте я впервые:
▫️использовал vibe-кодинг (программирование с помощью ИИ)
▫️записывал на видео процесс разработки как контент для “IT по вызову”.

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

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

Кстати, монтаж также выполняется с помощью ИИ в сервисе riverside.fm: видео транскрибируется, и дальше работаешь с ним как с текстом — вносишь коррективы в текст, он правит на видео.

#buildinpublic

Ребенок не хочет учить историю, а хочет играть в Роблокс.

Как обычно, подумал, можно ли совместить то, что интересно, с тем, что полезно.

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

Зашел поискать “история России в роблокс”. Что-то нашел… но… В общем, не нашел.

У них в этом году средневековье, крещение Руси и т.д. Посмотрел с ним “Викинг” (наша экранизация по теме с Козловским). Да, 18+, но, к сожалению, с контентом 18+ ребенок познакомился в классе 3-м - 4-м – добро пожаловать в дивный новый мир.

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

Тогда я поставил себе Roblox Studio, и примерно минут через 15 с помощью встроенного ИИ-ассистента сгенерил фрагмент игровой локации. Потом залез в интернет и примерно еще минут через 10 нашел публикацию о конкурсе на выдачу грантов на прототипы игр. От 7,5 до 15 млн. (пруф)

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

Конструирование VS Созревание

Впервые принимая руководство компанией, я общался с владельцем на стандартом языке бизнес-планирования: вот план действий, вот план по доходам / расходам / прибыли / инвестициям.

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

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

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

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

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

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

Какой из этого руководительский вывод? Если ты идешь от орг.развития:
1. Не создавать ложных ожиданий у собственника. Он должен понимать, что ты будешь делать. Если брать аналогию с шахматами, ты создаешь выигрышную позицию на доске, а не атакуешь.
2. Перепроверь стартовые прогнозы в бизнес-плане. Учел ли ты все факторы и естественные процессы, которые забываются, когда сознание находится в “конструкторском” режиме.

Продукт владеет мной, а не я им

Идея начинать со спроса благополучно ушла в сад. Я выпускаю продукты, потому что представляю, как классно они будут работать, а не сколько я на этом заработаю. Надеюсь, это лечится, а пока встречайте: ИИ-плагин для Miro, который за минуты делает кастдев по интересующей вас области. Общее время разработки - примерно 3 дня с помощью Lovable - интегрированная среда разработки с ИИ, где деплой проекта выполняется одной кнопкой.

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

А что если получается, что время на разработку продукта примерно такое же, что и на разработку презентации про него?