Сегодня - на http://waw-conf.ru мой доклад - открывающий, о будущам общества, ИТ и аналитиков. Презентация - у меня на сайте https://mtsepkov.org/Future-WAW
👍6🔥2
#wawconf Алишер Умаров. Аналитик 2.0 - Шестирукий Шива или как выжить в современных реалиях с ИИ.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
👍2
#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
При этом Дима тут же делает вывод о том, что от проектов надо переходить к продуктам. Но рассказанная история про кредитный конвейер не создает никаких новых продуктов, нет там никакого продуктового мышления. Продуктовое мышление - про другое. Про что именно продуктовое мышление, на мой взгляд, Дима так и не сказал.
Но вот то, что классическая проектная организация, особенно с выделением ИТ-проекта - тупиковая ветвь развития - в целом правильно, тут я согласен.
Дальше был спорный тезис о том, что даже когда бизнес не слишком готов к цифровизации, аналитик должен наносить пользу и должен делать бизнес все более цифровым, насколько это возможно. На мой взгляд, чаще всего в результате такого подхода будет не польза, а вред, за который аналитик будет огребать, а потом жаловаться, что бизнес его не так понял.
А вот что верно, это схема современного изменения в управлении, которая зафиксировала ряд переходов.
* Задачи -> Цели
* Люди -> Команды
* Мотивация -> Ценность
* Процессы -> Продукты
* Структура (иерархия) -> Сеть
Зачем презентация? Мы пришли в ИТ чтобы сделать мир лучше. И мечтаем о том, чтобы компания принимали стратегические и локальные решения разумно, с учетом последствий, чтобы продуктами можно было гордиться. Он в эту сторону работает уже много лет, а ощущения - как лягушка толкает бегемота.
Информатизация - этап, когда ИТ использовалось чтобы улучшить процессы в компаниях. 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.
И в конце была очень интересная схема как стать частью решения, с конкретными областями. На ней Product lab - песочница, в ней весело. Stars Fab - новые растущие продукты, здесь офигенно. А начинаем с Data Lab.
Денис Бесков организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести протокол в Миро, думаю, он его опубликует. А от меня - ссылка на мои доклады про разделение ответственности в разработке https://mtsepkov.org/Roles их было довольно много, тема развивалась.
👍5🔥1
#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
* Изучать существующие концепции, не переизобретайте велосипеды
* Переводите в диаграммы - об этом не было, но это очень полезно, и все модели были визуальными. А это перенастраивает мозг
* Идите туда, где нет готовых решений
Только помните: концепции упрощают, поэтому важно знать много и смотреть с разных сторон.
Дальше в докладе было много историй, как различные концепции помогали ей решать разные ситуации в жизни. Как иллюстрация самого подхода.
Смена взгляда 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
* Изучать существующие концепции, не переизобретайте велосипеды
* Переводите в диаграммы - об этом не было, но это очень полезно, и все модели были визуальными. А это перенастраивает мозг
* Идите туда, где нет готовых решений
Только помните: концепции упрощают, поэтому важно знать много и смотреть с разных сторон.
Telegram
Smart Speaker Public
❤2👍1
#wawconf Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований. Очень интересный доклад о том, как реально происходит проектирование систем. Не теоретически обоснованным одним спуском по уровням, пусть даже замкнутым в итерационный цикл, а с многочисленными возвратами. И какие мыслительные операции выполняются на каждом шаге. И поскольку он это делает не осознанно, то у него боль от несоответствия идеальному процессу, описанному в учебниках, а еще он может пропускать важные, но не очевидные шаги. В презентации было много схем, а у меня будет линейный конспект.
Уровни - есть:
* Бизнес в целом - вписка в рынок
* бизнес-процессы
* модель автоматизации БП
* Функциональный дизайн ИТ-систем
* Конструктивный дизайн ИТ-систем
Но в динамике по ним разворачивается сложный путь.
Рассказ был на конкретном примере, что позволяло почувствовать, что лежит за словами: фотостудия для интернет-магазина, в которую привозят образцы товаров для фото и публикации, а сами образцы возвращают на склад. И на входе процесс был организован вручную.
Вводная: ручной процесс трудоемок и дает ошибки при привязке фото к товарам, давайте попробуем это улучшить с помощью автоматизации. Типичная вводная от бизнеса.
Первый шаг - модель процесса. Бизнес ее не принес. Тут она проста: заказать, привезти, снять и две ветви: привязать к товару и отобразить, а товар вернуть на склад.
2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой - идея решения.
Заказ решается быстро, делаем отчет, сравнивая товары на складе с наличием фотографий товаров.
С привязкой - сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.
У решений выписываем плюсы и минусы - по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик - он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика - подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная - она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.
Дальше решение детализируется по разным бизнес-процессам.
* Детализировать модель - по шагам
* Детализировать контекст. Съемка одежды и съемка конструктора - разное: одеть куртку на манекен или собрать из конструктора что-то - разное время. А декоративная сетка - вообще нельзя в студии.
* Детализация бизнес-процесса. Своя фотостудия или чужая - тогда билинг и так далее, ценообразование с выбором фотостудии.
* Контроль качества
* Управление процессом
* Обеспечение деятельности - расходники и так далее.
* Фискальный аспект
* Последовательность, организация, информация.
Для шагов есть типовые задачи, например, заказ со склада - там надо использовать, не придумывать. А есть - не типовые, их надо уметь конструировать через типовые. И нужен опыт оценки трудоемкости, чтобы удерживать стоимость.
Это все - проработка на бизнес уровне.
3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной - увеличивает ошибки, на товаре - может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.
Уровни - есть:
* Бизнес в целом - вписка в рынок
* бизнес-процессы
* модель автоматизации БП
* Функциональный дизайн ИТ-систем
* Конструктивный дизайн ИТ-систем
Но в динамике по ним разворачивается сложный путь.
Рассказ был на конкретном примере, что позволяло почувствовать, что лежит за словами: фотостудия для интернет-магазина, в которую привозят образцы товаров для фото и публикации, а сами образцы возвращают на склад. И на входе процесс был организован вручную.
Вводная: ручной процесс трудоемок и дает ошибки при привязке фото к товарам, давайте попробуем это улучшить с помощью автоматизации. Типичная вводная от бизнеса.
Первый шаг - модель процесса. Бизнес ее не принес. Тут она проста: заказать, привезти, снять и две ветви: привязать к товару и отобразить, а товар вернуть на склад.
2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой - идея решения.
Заказ решается быстро, делаем отчет, сравнивая товары на складе с наличием фотографий товаров.
С привязкой - сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.
У решений выписываем плюсы и минусы - по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик - он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика - подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная - она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.
Дальше решение детализируется по разным бизнес-процессам.
* Детализировать модель - по шагам
* Детализировать контекст. Съемка одежды и съемка конструктора - разное: одеть куртку на манекен или собрать из конструктора что-то - разное время. А декоративная сетка - вообще нельзя в студии.
* Детализация бизнес-процесса. Своя фотостудия или чужая - тогда билинг и так далее, ценообразование с выбором фотостудии.
* Контроль качества
* Управление процессом
* Обеспечение деятельности - расходники и так далее.
* Фискальный аспект
* Последовательность, организация, информация.
Для шагов есть типовые задачи, например, заказ со склада - там надо использовать, не придумывать. А есть - не типовые, их надо уметь конструировать через типовые. И нужен опыт оценки трудоемкости, чтобы удерживать стоимость.
Это все - проработка на бизнес уровне.
3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной - увеличивает ошибки, на товаре - может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.
Когда мы поделили на задачи - потерялась связь между ними. Печать ШК на накладной - это основной способ их получить, или это workaround когда нет ШК на товаре, и на первом шаге можно без него? При этом печать накладной, скорее всего, уже есть, то есть нам надо доработать стандартную фичу, и, наверное, вставить эту задачу соответствующей команде - поэтмоу важно понимать критичность.
Еще делаем проекцию на структуры данных. ШК - может ли один быть у нескольких товаров и так далее.
При проекции не создается новых знаний или принятие решений. Просто преобразование.
4. Возврат на проектирование - при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.
Обработка исключений. Фотограф забыл сделать фото ШК, или система не может ШК распознать - как исправляется ситуация? Например, поскольку на товаре ШК может быть плохой, печать на накладной дублирует возможность сделать фото.
При возврате к уровень бизнес-процессов они могут меняться, и, возможно, потребуются доработка автоматизации.
4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров - разное количество. Например, у обуви 7, у одежды - 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка - в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.
5. Есть модель автоматизации - делаем дизайн. А потом идет возврат от дизайна к модели. Аналитики часто делают дизайн в рамках конкретного типового набора. А в конкретных случаях может быть нужен выход за типовые рамки. И от дизайна - идет возврат на уровень конструкции системы и бизнес-процессов с учетом дизайна.
6. Конструкция. Типовые деления, виды приложений, которые мы используем.
7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?
8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров - получили объемы, они дают технические решения. И тут могут появиться проблемы.
9. Проработка аспектов качества - было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд - очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.
Аспекты качества - на разных уровнях. Верхний - качество бизнес-процессов, а автоматизация - одна из тактик. Хотя качество автоматизации тоже играет.
Источник идей автоматизации не обязательно прилетает сверху, от бизнеса. Он может быть снизу - от новых технологий, от идей команд.
В завершении - комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.
А где функциональные требования? Они возникали во всех операциях в двух случаях.
* При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно - и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают - и нельзя проверить ТЗ.
* Модель взаимосвязи разных моделей.
Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн - работа с моделью. Проекция моделей - тоже без ФТ.
Еще делаем проекцию на структуры данных. ШК - может ли один быть у нескольких товаров и так далее.
При проекции не создается новых знаний или принятие решений. Просто преобразование.
4. Возврат на проектирование - при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.
Обработка исключений. Фотограф забыл сделать фото ШК, или система не может ШК распознать - как исправляется ситуация? Например, поскольку на товаре ШК может быть плохой, печать на накладной дублирует возможность сделать фото.
При возврате к уровень бизнес-процессов они могут меняться, и, возможно, потребуются доработка автоматизации.
4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров - разное количество. Например, у обуви 7, у одежды - 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка - в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.
5. Есть модель автоматизации - делаем дизайн. А потом идет возврат от дизайна к модели. Аналитики часто делают дизайн в рамках конкретного типового набора. А в конкретных случаях может быть нужен выход за типовые рамки. И от дизайна - идет возврат на уровень конструкции системы и бизнес-процессов с учетом дизайна.
6. Конструкция. Типовые деления, виды приложений, которые мы используем.
7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?
8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров - получили объемы, они дают технические решения. И тут могут появиться проблемы.
9. Проработка аспектов качества - было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд - очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.
Аспекты качества - на разных уровнях. Верхний - качество бизнес-процессов, а автоматизация - одна из тактик. Хотя качество автоматизации тоже играет.
Источник идей автоматизации не обязательно прилетает сверху, от бизнеса. Он может быть снизу - от новых технологий, от идей команд.
В завершении - комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.
А где функциональные требования? Они возникали во всех операциях в двух случаях.
* При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно - и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают - и нельзя проверить ТЗ.
* Модель взаимосвязи разных моделей.
Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн - работа с моделью. Проекция моделей - тоже без ФТ.
👍4
Итого, аналитик не просто обеспечивает согласованность решений стейкхолдеров, он делает оптимальное решение. Первое решение далеко не всегда оптимально.
* Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.
* Решения по выбору принимает менеджер.
* Все это делаем используя некоторое количество мыслительных операций, они перечислены.
* Между уровнями - всегда конструкция. Внутри уровня может быть проекция.
И есть боль. В постановках очень часто пишут, что надо изменить. И в результате разобраться, как система работает в окружении очень сложно - надо инкрементально проработать все постановки. Нужно быть представление, чтобы работать сейчас.
* Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.
* Решения по выбору принимает менеджер.
* Все это делаем используя некоторое количество мыслительных операций, они перечислены.
* Между уровнями - всегда конструкция. Внутри уровня может быть проекция.
И есть боль. В постановках очень часто пишут, что надо изменить. И в результате разобраться, как система работает в окружении очень сложно - надо инкрементально проработать все постановки. Нужно быть представление, чтобы работать сейчас.
🔥3
#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-страничник - основной формат для создания и обсуждения стратегии. Не презентация. Есть шаблон от Амазон. Черновик, разослать и попросить прокомментировать. И разбор, правка. Чтобы на выходе встречи был документ.
В России идет активный выход, но есть большие бренды, у которых нет интернет-продаж, и у них могут начаться проблемы. И надо уметь фокусироваться в одном направлении и в идеале - как единое целое. Сейчас интенсивный рост у Самоката и Яндекс-лавке. Чем они отличаются? У них - узкий ассортимент, 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-страничник - основной формат для создания и обсуждения стратегии. Не презентация. Есть шаблон от Амазон. Черновик, разослать и попросить прокомментировать. И разбор, правка. Чтобы на выходе встречи был документ.
👍3
Книги:
* 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-страничника.
* 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-страничника.
Google Docs
Шаблон шестистраничника
Стратегия [Компании] на [2024]-[2025] годы Цель документа – описать стратегию [Компании] на [2024]-[2025] годы с анализом рынка, стратегическими выборами и ключевыми ставками. [Зачем нам нужна стратегия?] Вдохновляющие цели [Миссия компания - зачем ваша компания…
👍3🐳1
После некоторого перерыва публикую шестую статью про инженерную модель личности https://vc.ru/hr/1042085 «Модель личности: как обучается наш мозг». Она посвящена различным механизмам, обеспечивающим формирование ансамблей нейронов, образующих модель мира, на основе которой человек принимает решения и действует. Полное оглавление серии https://mtsepkov.org/Self-Det
vc.ru
Модель личности: как обучается наш мозг — Карьера на vc.ru
Продолжаю публикацию серии статей, посвященной инженерной модели личности. В предыдущих статьях (оглавление) мы разобрали функционирование мозга, ход мышления при управлении текущей деятельностью, включая эмоциональные механизмы. А в этой мы рассмотрим обучение…
❤5👍2🐳1
Очередная статья про модель личности https://vc.ru/hr/1048774 «Внутренняя сцена и объективная реальность» посвящена спектаклю, который разворачивается наше мышление. Он обеспечивает планирование будущего и рефлексию прошлого. Декорации этого спектакля – представления человека о мире, а играют в нем актеры-аватары, созданные человеком по собственным представлениям о себе и о других людях. И все наши оценки себя и окружающего мира выполняются на основе этого спектакля. Так что метафора Вильяма Шекспира «Мир – театр, В нем женщины, мужчины, все – актеры» оказывается не просто метафорой, а достаточно точным описанием происходящего.
Я поднимаю системный уровень рассмотрения нашего мышления, абстрагируюсь от конкретных ансамблей нейронов и смотрю на то, что в целом разворачивается в нашем мозге за счет их работы. Полное оглавление серии https://mtsepkov.org/Self-Det
Я поднимаю системный уровень рассмотрения нашего мышления, абстрагируюсь от конкретных ансамблей нейронов и смотрю на то, что в целом разворачивается в нашем мозге за счет их работы. Полное оглавление серии https://mtsepkov.org/Self-Det
vc.ru
Модель личности: внутренняя сцена и объективная реальность — Карьера на vc.ru
Внутри нашего мозга идет спектакль, который обеспечивает планирование будущего и рефлексию прошлого. Декорации этого спектакля – представления человека о мире, а играют в нем актеры-аватары, созданные человеком по собственным представлениям о себе и о других…
👍3🔥2👏2❤1
Пару недель назад прошел первый Winter Analitycal Weekend (WAW) от организаторов ЛАФ. Было много хороших докладов и мастер-классов, интересных обсуждений и интенсивного общения в кулуарах. Я выступал с докладом Место ИТ и аналитиков в будущем мире, где размышления были не только о трендах развития ИТ, но и развития общества в целом: любую систему необходимо рассматривать в контексте развития надсистемы. По отзывам участников, рассказ оказался интересным и полезным. Как обычно, я публиковал резюме докладов на телеграм-канале, а теперь собрал их в общий отчет с конференции https://mtsepkov.org/WAW-2024 Надеюсь на продолжение в следующем году и летом на ЛАФ!
❤7🔥2
Восьмая статья про модель личности https://vc.ru/hr/1058974 «Я и мои аватары» разбирает, сколько у нас аватаров, как они появляются и насколько они автономны, то есть имеют собственный набор целей, желаний и представлений о мире, а также поговорим о сознательном конструировании аватара. Полное оглавление серии https://mtsepkov.org/Self-Det
vc.ru
Модель личности: Я и мои аватары — Карьера на vc.ru
Продолжаю серию статей про инженерную модель личности (оглавление). В предыдущей статье «Внутренняя сцена и объективная реальность» мы разобрали, что все наши решения мы принимаем не на основе объективной картины мира, а на основе спектакля на нашей внутренней…
❤1
#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 находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.
И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.
Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.
👍4❤2
#DevOpsConf Карапет Манасян из MOEX Group. Сколько стоит платформа? Вопреки названию, доклад - не про деньги, он про процессы, обеспечивающие платформенный подход, которые надо наладить. Конечно, процессы стоят денег, но это не главное. Рассказ был о построении платформенной конструкции в рамках MOEX Group. При этом типовой платформенный подход с полной однородностью процессов и единым технологическим стеком у них не подходит, так как бизнес - существенно гетерогенный, есть торговые решения с длинным релизным циклом, есть финтех с коротким тестированием гипотез и есть критическая инфраструктура со своими требованиям регулятором. Тем не менее, они рассматривают сделанное именно как платформу, а не как работу DevOps инженеров.
Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.
Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно.
Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.
Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.
Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.
Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.
Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно.
Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.
Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.
Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.
👍3🔥3❤2
#DevOpsConf Евгений Харченко из Райффайзен Банк. Как DevOps влияет на эффективность организации? Очень интересный доклад о реально наблюдаемой корреляции между показателями инженерной культуры и метриками эффективности. На масштабе 3000 сотрудников в 148 командах. Метрики касаются применения инженерных практик и интегральной производительности по модели DORA. А по культуре - на модель Ron Westrum, которая разделяет три вида: патологическую, бюрократическую и генеративную.
Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:
* В командах происходит активный обмен информацией.
* В командах происходит взаимодействие ролей.
* Есть общая ответственность за продукт и платформу
* В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения
* В командах Проводятся анализы причин проблем, ошибок и неудач
* В командах приветствуются новые идеи по улучшению процессов
Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое.
Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.
Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:
* В командах происходит активный обмен информацией.
* В командах происходит взаимодействие ролей.
* Есть общая ответственность за продукт и платформу
* В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения
* В командах Проводятся анализы причин проблем, ошибок и неудач
* В командах приветствуются новые идеи по улучшению процессов
Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое.
Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.
👍2
#DevOpsConf Анастасия Граф. Как организовать базу знаний так, чтобы даже новичок-джун всё смог найти сам? Анастасия - из Maxim Technology, разработка для Taxi Maxim, 350 ИТ-шников распределенная команда по городам России. Доклад развивает тему доклада на #TeamleadConf-2023 (есть конспект в моем отчете), но отличается фокусировка. Тогда был рассказ о процессе и технических способах организовать документацию, а здесь фокус на результат - базу знаний с легким поиском и с соучастием разработчиков в ее поддержке. И основная задача тут - изменение культуры: переход от ситуации, когда тот к кому нужна информации, обращается в чатик или к соседу, к ситуации, когда человек сначала идет за ответом в базу знаний, и только если ответ не нашел идет его искать к соседу или в чатик, а найдя ответ - еще и дополняет базу знаний. Это именно изменение культуры. Но чтобы оно произошло должны быть предпосылки.
4 требования, они были сформулированы на слайде, а потом по каждому шел рассказ.
1) Легко делиться знаниями. Чтобы писали все, а не специально выделенный человек. Для этого надо дать возможность писать всем, в том числе джунам - у них есть вопросы, есть ответы, которые будут полезны следующему джуну. И каждому должно быть понятно, что и как написать, это обеспечивает типизация контента и шаблоны структуры с подсказками по заполнению каждого поля.
Типы страниц: термин; справочник - на каждой странице ответ на один вопрос; страница книги - ответ на сложный вопрос, собранный из простых и ссылок. Страница справочника включает историю изменений, чтобы отличать опечатки от содержательных актуализаций. В шаблон страницы книги зашит фидбэк, сразу.
2) Статья написана понятно читателю. Целевая аудитория часто шире, чем задумываешься. Есть люди, далекие от ИТ, которым тоже интересно не ходить с вопросами к ИТ. И здесь - ревью, обратная связь и легкость изменения. Перевести реакцию из "у вас непонятно" к "мне непонятно это и это".
3) Легко найти нужный материал. Тут есть проблема со сленгом - надо писать понятные названия. А еще работать с метками. У них документацию ведут сами команды, и они образуют дерево статей так как им удобно, в своей логике и ориентируются в своем пространстве. Которая отличается от логике соседней команды. А поиск нужен по всей документации, и метки помогают определить нужный набор страниц. И они помогают делать тематические подборки, на которых собирается вся необходимая информация.
4) Все материалы достоверны и актуальны на текущую дату. Самое сложно реализуемое. Что не надо перепроверять, а если нашел неверное - то заинтересован исправить. Реализуется за счет статусной модели для страниц, и за счет активного применения сборных страниц, которое позволяет править в одном месте. Статус - метка на странице: В работе, Ревью, Опубликована, На корректировку.
Итого, что нужно сделать:
* Дать возможность писать всем, включая джунов. Потому что у него есть что написать, ответить вопросы.
* Типизация контента. Шаблоны для каждого типа. Структуры с подсказками.
* Круг энтузиастов, которые пишут, либо встройка наполнения базы знаний включено в процесс.
* Порядок верификации и обновления. Нужен триггер обновления - когда и по какому алгоритму проверять, и алгоритм поиска устаревших страниц - через различные отчеты.
На этом - все. А мне во время доклада пришла мысль посмотреть на изменение культуры документирования как на процесс уборки и поддержания порядка: (1) есть пространства, где ты при необходимости убираешься сам, (2) есть - где активно сигнализируешь о беспорядке, (3) есть - где лишь жалуешься и страдаешь, а (4) есть - где игнорируешь. И задача - чтобы расширить пространства 1 и 2 каждого членов команды, обеспечив перекрыте всего пространства активистами. Это может дать другой взгляд.
4 требования, они были сформулированы на слайде, а потом по каждому шел рассказ.
1) Легко делиться знаниями. Чтобы писали все, а не специально выделенный человек. Для этого надо дать возможность писать всем, в том числе джунам - у них есть вопросы, есть ответы, которые будут полезны следующему джуну. И каждому должно быть понятно, что и как написать, это обеспечивает типизация контента и шаблоны структуры с подсказками по заполнению каждого поля.
Типы страниц: термин; справочник - на каждой странице ответ на один вопрос; страница книги - ответ на сложный вопрос, собранный из простых и ссылок. Страница справочника включает историю изменений, чтобы отличать опечатки от содержательных актуализаций. В шаблон страницы книги зашит фидбэк, сразу.
2) Статья написана понятно читателю. Целевая аудитория часто шире, чем задумываешься. Есть люди, далекие от ИТ, которым тоже интересно не ходить с вопросами к ИТ. И здесь - ревью, обратная связь и легкость изменения. Перевести реакцию из "у вас непонятно" к "мне непонятно это и это".
3) Легко найти нужный материал. Тут есть проблема со сленгом - надо писать понятные названия. А еще работать с метками. У них документацию ведут сами команды, и они образуют дерево статей так как им удобно, в своей логике и ориентируются в своем пространстве. Которая отличается от логике соседней команды. А поиск нужен по всей документации, и метки помогают определить нужный набор страниц. И они помогают делать тематические подборки, на которых собирается вся необходимая информация.
4) Все материалы достоверны и актуальны на текущую дату. Самое сложно реализуемое. Что не надо перепроверять, а если нашел неверное - то заинтересован исправить. Реализуется за счет статусной модели для страниц, и за счет активного применения сборных страниц, которое позволяет править в одном месте. Статус - метка на странице: В работе, Ревью, Опубликована, На корректировку.
Итого, что нужно сделать:
* Дать возможность писать всем, включая джунов. Потому что у него есть что написать, ответить вопросы.
* Типизация контента. Шаблоны для каждого типа. Структуры с подсказками.
* Круг энтузиастов, которые пишут, либо встройка наполнения базы знаний включено в процесс.
* Порядок верификации и обновления. Нужен триггер обновления - когда и по какому алгоритму проверять, и алгоритм поиска устаревших страниц - через различные отчеты.
На этом - все. А мне во время доклада пришла мысль посмотреть на изменение культуры документирования как на процесс уборки и поддержания порядка: (1) есть пространства, где ты при необходимости убираешься сам, (2) есть - где активно сигнализируешь о беспорядке, (3) есть - где лишь жалуешься и страдаешь, а (4) есть - где игнорируешь. И задача - чтобы расширить пространства 1 и 2 каждого членов команды, обеспечив перекрыте всего пространства активистами. Это может дать другой взгляд.
👍5