Пять лет назад, в 2019, ontico начал проводить конференцию по управлению знаниями в ИТ - KnowledgeConf. Первые два раза это была отдельная конференция, а потом пришел ковид, произошло укрупнение, и сейчас она идет отдельным треком в составе TeamleadConf - это сильно расширяет аудиторию участников. Но программу по-прежнему готовит отдельный ПК. С управлением знаниями очень забавная ситуация: с одной стороны, знания - основа ИТ, а с другой - управление ими часто погружено в другие процессы: онбординг, коммуникации, управление разработкой и сопровождением в которых недостаток знаний порождает с этим проблемы, а еще становится частью процесса ухода ключевого человека, который уносит знания. С этими вопросами многие сталкивались, и если у вас есть опыт, которым интересно поделиться - подавайте заявку на доклад здесь https://cfp.knowledgeconf.ru/ Срок - до 20.02, но, как на всех конференциях онтико, чем раньше подашь - тем больше внимания ПК и больше шансов, что вам помогут сделать достойный доклад.

Пятая статья про инженерную модель личности https://vc.ru/hr/1018029 «Модель личности: механизмы драйва и мотивации» продолжает тему эмоций и рассказывает про механизмы, которые обеспечивают нам драйв и мотивацию, и про управление ими – чтобы любая наша деятельность: работа, семья, воспитание детей – давали драйв и приносили радость и удовлетворение в достаточной мере. Полное оглавление серии https://mtsepkov.org/Self-Det

Как обычно в конце марта (20 и 22.03), состоится AgileDays Это - одна из тех конференций, на которых я стараюсь быть каждый год вот уже 15 лет, чтобы держать руку на пульсе изменений, посмотреть что происходит в современном менеджменте, и не только в ИТ: с тех пор, как Греф прочитал Сазерленда, Agile мощно пошел в другие отрасли, куда раньше входил гораздо осторожнее. И конференция дает репрезентативный срез происходящего, не только благодаря докладам, но и благодаря активному общению. И это - интересно. Приходите, буду рад увидеться. А отчеты о прошлых конференциях есть у меня на сайте.

Сегодня - на http://waw-conf.ru мой доклад - открывающий, о будущам общества, ИТ и аналитиков. Презентация - у меня на сайте https://mtsepkov.org/Future-WAW

#wawconf Алишер Умаров. Аналитик 2.0 - Шестирукий Шива или как выжить в современных реалиях с ИИ.

Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.

Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.

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

И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.

Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.

Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).

Зачем это надо? Аналитик может стать core-участникам команды.

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

А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.

Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.

#wawconf Дмитрий Безуглый. Трансформация отдела Анализа: Пути к Усилению роли и ценности в условиях интенсивной цифровизации. У Димы, как часто бывает, получился доклад из ряда не слишком связанных, на мой взгляд, тезисов. Но каждый из них - отдельно интересен.

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

Информатизация - этап, когда ИТ использовалось чтобы улучшить процессы в компаниях. Enterprise unify process - апофеоз. Позиционирование. БА - гуру, которые помогают бизнесу принимать решения. СА - гуру в области реализации. Но этот этап - прошел. А новый этап - цифровизация. И твердый факт: ИТ и отделы проектирования не возглавили цифровизацию. И вообще прошла мимо CIO.

Почему? Потому что аналитики могут быть интересны бизнесу как партнеры, А для этого они должны уметь анализировать рынок, конкуретнов, unit-экономику, прогнозировать. А они - не про это, они бодаются о том, писать use case или user story, а от бизнеса ждут постановки задачи. И бизнес теряет интерес, и не видит, о чем разговаривать.

Впрочем, у бизнеса тоже бывают странные представления про аналитиков. В Авито был период, когда велели всем аналитикам обучиться BABOK. B они пытались натянуть эту теорию на свою практику.

Взаимодействие бизнеса и ИТ бывает печально: из 100 заявок, реализуется 2, при этом ломается в 10 местах, идут критические баги. А дальше - стокгольмский синдром, бизнес от ИТ зависит, "давайте дружить мирно". Впрочем, я думаю, что Дима тут сильно утрирует ситуацию. И реакция зала говорит о том же. Реально ИТ дает ценность для бизнеса, и бизнес - понимает какую именно.

Цифровизация - история не про то, что берем существующий бизнес и пытаемся усилить ИТ, к 100 людям в операционке добавить 50 ИТ и взлететь. Это идея о том, чтобы заменить тех людей. Не ходить к прачке с вопросом, как сделать автоматическую стиральную машину. Кредитный конвейер - не то, чтобы поддержать работу 10к андерайтеров. Они про то, чтобы работал автомат, который поддерживают 20 человек и 200 человек разбирали не типовые частные случаи. То есть ИТ должно перестроить бизнес.

С моей точки зрения, тут и правда и неправда. Потому что информатизация - тоже про это, и задачи такого изменения кредитного конвейера я слышал еще в конце 90-х, и не просто слышал, банки так и делали. Конечно, бывает и то отношение, о котором говорил Дима, и когда-то был этап, когда автоматизация преимущественно поддерживала бизнес, но это было давно. Еще в 2017, рассказывая про эволюцию ИТ-проектов на SECR я говорил о сращивании ИТ и бизнес-частей проекта, смотри 7 слайд презентации https://mtsepkov.org/BA-methods-SECR-2017

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

Но вот то, что классическая проектная организация, особенно с выделением ИТ-проекта - тупиковая ветвь развития - в целом правильно, тут я согласен.

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

А вот что верно, это схема современного изменения в управлении, которая зафиксировала ряд переходов.
* Задачи -> Цели
* Люди -> Команды
* Мотивация -> Ценность
* Процессы -> Продукты
* Структура (иерархия) -> Сеть

Отсюда метастратегия: от оптимизации к трансформации. Задача анализа: двигаться от проектов в создание и развитие продуктов; быть источником данных для data driven decision. При этом работа с данными часто чистое поле, которое легко отдают. Дальше задача - научиться извлекать из data lake то, что будет наносить пользу бизнесу. Не ждать от бизнеса задачи, а самому порождать идеи.

И в конце была очень интересная схема как стать частью решения, с конкретными областями. На ней Product lab - песочница, в ней весело. Stars Fab - новые растущие продукты, здесь офигенно. А начинаем с Data Lab.

Денис Бесков организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести протокол в Миро, думаю, он его опубликует. А от меня - ссылка на мои доклады про разделение ответственности в разработке https://mtsepkov.org/Roles их было довольно много, тема развивалась.

#wawconf Наталья Семенова. Концептуальное мышление - драйвер развития и преодоления непреодолимого. Для меня загадка этого доклада - ссылка на первоисточник концепции концептуального мышления как подхода к мышлению. Быстро находится Conceptual Thinking, но это вроде что-то другое. Из доклада я бы сформулировал, что концептуальное мышление - просто мышление с помощью концепций. Для которого выделено 7 уровней, начиная с 0: не пользуется (0), пользуется базовыми правилами (1), распознает модели (2), применяет сложные концепции (3), упрощает сложность (4), создает новые концепции (5), создает новые концепции по сложным вопросам (6), создает новые модели (7) - это я записал со слайда, можно подробнее посмотреть на телеграм-канале Наташи https://news.1rj.ru/str/SmartSpeaker_public/48

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

Смена взгляда inside - inside out - outside in помогла разобраться в ситуации, когда она не видела развития и ушла из аналитиков выращивать чеснок. Мы часто видим сферу, в которой находимся. И не знаем, что за ней. И потому не знаем куда идти - внутри все известно, а снаружи - неизвестность и муть. Надо выйти в inside out и далее outside in.

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

IGOE framework (inputs guides outputs enablers) помог выбрать направления развития.

Цикл Колба, который начинается с ошибки: опыт - анализ - теория - практика. Его применил руководитель, спровоцировав ее развитие, а концепт она узнала через пару лет.

Окно Джохари: мне/другим известно/неизвестно. 4 зоны, и есть зона неизвестного. И многие консультанты дают модели, известные им, но неизвестные вам. Вы приходите к семейному консультанта, он говорит: "у вас разные языки любви" или "вы в треугольнике Карпмана". Модель описывает частично, вы понимаете - и снова к психологу. Но если бы знали самостоятельно - могли бы применять. И учитывать сложность. Но там есть область неизвестного ни вам ни другим, что в ней делать?

У нее был доклад про делегирование, который реально был про лидерство. В какой-то момент поняла, что от нее ждут лидерства, принятия решений, и начала это делать, и учиться этому. Но пошел конфликт с руководителем. Разобраться помогла модель Адизеса: она и руководитель были предприниматели, а модель объясняет, что они всегда будут конфликтовать. Ситуацию объяснили. Модель помогает и решить ситуацию, и строить команды - чтобы были нужные факторы.

Модель холакратии - выстраивание автономных зон ответственности и принятия решений.

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

Читала про VUCA - BANI - не заходило. Хотя антихрупкость зашла - а она про BANI. Но последние 2 года перешла из западной компании в российскую. Многое перестало работать. Почему? И нашла концепт SHIVA - он дал объяснение: зарождается новый мир, а не просто разрушается старый. И она поставила вопрос: как надо изменить парадигму мышления чтобы в SHIVA-мире жить, не изменяя ценностям. И она выписала: что нельзя делать, и что другое нужно делать. Согласовала мышление с миром.

И выводы. Что делать для развития концептуального мышления
* Менять взгляд inside-out - outside-in
* Изучать существующие концепции, не переизобретайте велосипеды
* Переводите в диаграммы - об этом не было, но это очень полезно, и все модели были визуальными. А это перенастраивает мозг
* Идите туда, где нет готовых решений
Только помните: концепции упрощают, поэтому важно знать много и смотреть с разных сторон.

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

Уровни - есть:
* Бизнес в целом - вписка в рынок
* бизнес-процессы
* модель автоматизации БП
* Функциональный дизайн ИТ-систем
* Конструктивный дизайн ИТ-систем
Но в динамике по ним разворачивается сложный путь.

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

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

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

2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой - идея решения.

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

С привязкой - сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.

У решений выписываем плюсы и минусы - по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик - он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика - подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная - она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.

Дальше решение детализируется по разным бизнес-процессам.
* Детализировать модель - по шагам
* Детализировать контекст. Съемка одежды и съемка конструктора - разное: одеть куртку на манекен или собрать из конструктора что-то - разное время. А декоративная сетка - вообще нельзя в студии.
* Детализация бизнес-процесса. Своя фотостудия или чужая - тогда билинг и так далее, ценообразование с выбором фотостудии.
* Контроль качества
* Управление процессом
* Обеспечение деятельности - расходники и так далее.
* Фискальный аспект
* Последовательность, организация, информация.

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

Это все - проработка на бизнес уровне.

3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной - увеличивает ошибки, на товаре - может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.

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

Еще делаем проекцию на структуры данных. ШК - может ли один быть у нескольких товаров и так далее.

При проекции не создается новых знаний или принятие решений. Просто преобразование.

4. Возврат на проектирование - при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.

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

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

4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров - разное количество. Например, у обуви 7, у одежды - 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка - в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.

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

6. Конструкция. Типовые деления, виды приложений, которые мы используем.

7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?

8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров - получили объемы, они дают технические решения. И тут могут появиться проблемы.

9. Проработка аспектов качества - было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд - очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.

Аспекты качества - на разных уровнях. Верхний - качество бизнес-процессов, а автоматизация - одна из тактик. Хотя качество автоматизации тоже играет.

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

В завершении - комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.

А где функциональные требования? Они возникали во всех операциях в двух случаях.
* При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно - и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают - и нельзя проверить ТЗ.
* Модель взаимосвязи разных моделей.
Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн - работа с моделью. Проекция моделей - тоже без ФТ.

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

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

#wawconf Борис Вольфсон. Ландшафт стратегий в большой компании. Сфокусированный и минималистичный рассказ про то, как делать стратегию с конкретными фреймворками и материалами. Иллюстрирвоанный примером Сбермаркета и еще нескольких. Сбермаркет - динамично развивающийся стартап, с с 2016, 2019 - 1.9, 2020 - 20.7, 2021 - 62.6, 2022 - 102.8, в конкурентной среде: Озон фреш, Вкусвилл, Wildberries и т.д. Когда пришел, были явные признаки проблем со стратегией: постоянные пожары и хаотичное планирование - план на квартал-год с непонятными целями. Вообще типичная ситуация - каждое подразделение бежит в свою сторону, и менять курс, перефокусироватсья - сложно. Есть успешный пример Netflix, который рассылал DVD и смог переключиться на стриминг. А его конкурент блокбастер - не смог.

В России идет активный выход, но есть большие бренды, у которых нет интернет-продаж, и у них могут начаться проблемы. И надо уметь фокусироваться в одном направлении и в идеале - как единое целое. Сейчас интенсивный рост у Самоката и Яндекс-лавке. Чем они отличаются? У них - узкий ассортимент, 2-3к, в отличие от Магнита 5-6к или супермаркета на 10-15к. Зато сделали фокус на скорость доставки. То есть фокус - это еще и отказ от каких-то направлений.

Фокусировку важно согласовывать вплоть до слова, расхождения во мнениях топов вызывает большие расхождения ниже - правило маятника. Прибыльные и неубыточные - о разном. Стратегическое видение - 1-2 страницы текста, и проходят несколько раз, добиваясь понимания.

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

Пример фокусировки. В ecomerce 3 направления: быстрые и удобный сервис, широкий ассортимент и выгодные цены. Провели анализ в 2020 и сфокусировались на сервисе. В после начала СВО перефокусирвоались на выгодных ценах - стало более востребовано.

Что НЕ делаем - тоже есть в документе. В 2020 году было зафиксировано:
* Core - доставка grocery essentials из любимых магазинов.
* Не запускаем moms & pops формат - любимые магазины на районе
* Не делаем работаем с услугами, не делаем youdo и подобное

Ландшафт стратегий.
* Корпоративный: платформа на каждый день + устойчивый, прибыльный и публичный бизнес
* Вертикальные стратегии: клиенты, ритейлеры, сборщики и курьеры, бренды, новые вертикали и эксперименты
* функциональный уровень: продукт, разработка.

На функциональном уровне.
* Видение продукта, через 5 лет или через 1-2 года (зависит от стабильности). Целевой CJM в сбермаркете. Или в B2b телекоме - день сотрудника в контексте работы. Haven & help: текущая картинка для вашего или чужого продукта с болями, и идеал
* 5-7 ключевых инициатив. Метрики и ответственные за них.

Фреймворк PlayToWin - для вертикальных стратегий. Делал Procter & Gamble, доступны шаблоны
* Цели inspirations - большая вдохновленная цель, супер-OKR. Как у Форда: машин должно стать больше лошадей.
* Where to play - рыночные сегменты где играем и где НЕ играем, точки атаки. HH когда начинался - только на белых воротничках, а только потом только пошел на синие.
* How will we win choosen markets Как мы победим на этом рынке
* Capabilities и management systems

Самое пробемное - выбор рынка и способа победы на них. Канвасы value proposition, в книге Blue ocean strategy

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

Книги:
* playing to win - фреймворк
* good strategy bad strategy - различия
* Blue ocean strategy - инструменты value канвас
* Working Backwards Colin Bryar and Bill Carr
* On strategy сборник Harvard business review - там конкретные кейсы

Как доносить до команд?
* 6-страничник обсуждается с продуктовыми директорами, и к концу обсуждения каждый понимает для своего подразделения
* Потом презентация продуктовым лидам. На каждый параграф текста рисуют 2-3 экрана - восприятие для визуалов. И эта презентация показывается всем, нужен overcommunication
* Цели - OKR. У каждой ключевой ставки есть метрики. И дальше идет вниз. Именно это обеспечивает исполнение.

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

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

И в заключении - что делать.
* Прочтите материалы
* Попробуйте формат 6-страничника
* Попробуйте инструменты для отдельных элементов стратегии
* В рамках большой компании попробуйте сделать ландшафт стратегий

Шаблон 6-страничника.

После некоторого перерыва публикую шестую статью про инженерную модель личности https://vc.ru/hr/1042085 «Модель личности: как обучается наш мозг». Она посвящена различным механизмам, обеспечивающим формирование ансамблей нейронов, образующих модель мира, на основе которой человек принимает решения и действует. Полное оглавление серии https://mtsepkov.org/Self-Det

Очередная статья про модель личности https://vc.ru/hr/1048774 «Внутренняя сцена и объективная реальность» посвящена спектаклю, который разворачивается наше мышление. Он обеспечивает планирование будущего и рефлексию прошлого. Декорации этого спектакля – представления человека о мире, а играют в нем актеры-аватары, созданные человеком по собственным представлениям о себе и о других людях. И все наши оценки себя и окружающего мира выполняются на основе этого спектакля. Так что метафора Вильяма Шекспира «Мир – театр, В нем женщины, мужчины, все – актеры» оказывается не просто метафорой, а достаточно точным описанием происходящего.

Я поднимаю системный уровень рассмотрения нашего мышления, абстрагируюсь от конкретных ансамблей нейронов и смотрю на то, что в целом разворачивается в нашем мозге за счет их работы. Полное оглавление серии https://mtsepkov.org/Self-Det

Пару недель назад прошел первый Winter Analitycal Weekend (WAW) от организаторов ЛАФ. Было много хороших докладов и мастер-классов, интересных обсуждений и интенсивного общения в кулуарах. Я выступал с докладом Место ИТ и аналитиков в будущем мире, где размышления были не только о трендах развития ИТ, но и развития общества в целом: любую систему необходимо рассматривать в контексте развития надсистемы. По отзывам участников, рассказ оказался интересным и полезным. Как обычно, я публиковал резюме докладов на телеграм-канале, а теперь собрал их в общий отчет с конференции https://mtsepkov.org/WAW-2024 Надеюсь на продолжение в следующем году и летом на ЛАФ!

Восьмая статья про модель личности https://vc.ru/hr/1058974 «Я и мои аватары» разбирает, сколько у нас аватаров, как они появляются и насколько они автономны, то есть имеют собственный набор целей, желаний и представлений о мире, а также поговорим о сознательном конструировании аватара. Полное оглавление серии https://mtsepkov.org/Self-Det

#DevOpsConf Игорь Курочкин. NextOps — что будет после DevOps. Открывающий доклад о направлениях развития DevOps. Вау-фишка Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их. И на этом этапе попытки нанести нечто полезное разбиваются о засилье этих паразитных практик. В общем, мы все знаем, что так и происходит, и это частное проявление бюрократизации, как ее исследовал Крозье, но в докладе был конкретный обобщенный путь, и это интересно. Дальше обобщенный путь наложен на DevOps и получается тоже понятная картина, DevOps уже 15 лет и как модный бренд уже прошел фазу полезного развития. Так что стоит задуматься о следующем тренде, которые Игорь назвал NextOps и который позволит сделать следующий шаг. И в докладе была попытка, на основе анализа работы отцов-основоположников DevOps и других трендах это нащупать. Это было интересно, но, на мой взгляд, не слишком перспективно, потому что опыт показывает, что гуру успешного направления очень редко становятся драйверами следующего. Хотя исключения бывают. Конспекта этой части не будет, смотрите доклад.

И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.

Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.