Денис Бесков организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести протокол в Миро, думаю, он его опубликует. А от меня - ссылка на мои доклады про разделение ответственности в разработке 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
#DevOpsConf Илья Барбашов из Авито. Developer Experience: обзор подходов и как мы их применяем. Доклад был четко из двух частей: теории о метриках продуктивности разработки и практика повышения этой продуктивности на основе общих механизмов продуктового подхода, примененного к разработке платформы. Связь первого и второго - сильно пунктиром. И тут отдельный вопрос - насколько эти теории все-таки помогают, что делают лучше?
Контекст: в авито 2500 инженеров, 1800 микросервисов. Платформа покрывает все от создания и разработки сервиса до выкатки и эксплуатации, содержит реестр сервисов и библиотек, связей, решение типовых задач в микросервисной архитектуре. Платформа 5 лет в разработке, очевидные задачи - решены. При этом не известно, насколько мы хороши, есть много идей фич, но профит от них их - неясен, а хочется понимать заранее. И нет product manager - эту роль выполняет сама команда, тимлиды. Итого: непонятно в какую сторону работать. А хотелось бы иметь ориентиры, например, метрика.
Поискали метрики в индустрии.
* DORA 4 метрики: как часто катите, как быстро докатываете до прода, как часто падаете, как быстро восстанавливаете. И у них есть квалификация low - medium - high - elite. У них платформа позволяет работать на уровне elite, улучшения лежат уже в русле команд. А там идет работа по team maturity model компании
* SPACE: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow - всеобъемлющий, но применение неясно
* Три изменения DevEx: Flow state, cognitive load, feedback loop. Более практичен, и это не CAP-теорема, можно все три улучшать.
Flow State: если инженера прерыват встречи, срочные задачи и блокеры, автономность выбора инженером задачи, понятные цели и задачи проекта - чтобы выбирать, интересные задачи. Не решается техническими средствами, это организация. В avito есть playbook, он это как-то решает.
Cognitive load: насколько надо напрячь мозг, чтобы эту задачу сделать. Непонятный фреймворк или технология, новый бизнес-домен и так далее. Делится на два типа: полезная, которая бьет в решение задачи, и паразитная - нечеткие требования и дополнительные знания, например, кубовые манифесты. Платформа снижает типовые задачи, чтобы разработчик не думал о кубернетисе, о том, что интеграция сломается - есть проверки, можно посмотреть любой сервис и так далее.
Feedback Loops: все действия, которые надо делать разработчику пока решает задачу. Компиляция, циклы запуска тестов и так далее. И pull request при итеративном code review. CI. Итеративные согласования, например, с безопасниками. Количество циклов, вероятно, убрать не сможем, а скорость повысить - да. Они здесь работают через стандартизацию - стандартизирвоанный CI/CD, линтинг, среда разработки с автоматической настройкой зависимости. Среда может поднять для тестов все зависимости, шины данных, базы данных - если нужно для тестов.
Но дальше вопрос: как эту историю мерить? Фреймворк рекомендует три метрики: ощущаемая легкость разработки, ощущаемая удовлетворенность разработчиков, ощущаемая продуктивность. Это все - субъективно.
И на этом часть про теорию заканчивается, и начинается история про практику. Которая начинается с CustDev, при котором понимаешь реальное использование платформы пользователем и их проблемы. Он эффективен, но дорог. Поэтому дополняем его опросом пользователей.
Google-форма с фичами, по каждой оценки: не использую, если использую - удовлетворенность от очень недоволен до очень доволен. И обязательно поле для свободного фидбэка, по опыту половина людей пишут содержательно. Где взять список вопросов? Плохая мысль - попросить это сделать команды разработки платформы, потому что у них представление по устройству платформы, а пользователь использует иным образом. Поэтому берем CustDev и вопросы - по путям пользователя.
Контекст: в авито 2500 инженеров, 1800 микросервисов. Платформа покрывает все от создания и разработки сервиса до выкатки и эксплуатации, содержит реестр сервисов и библиотек, связей, решение типовых задач в микросервисной архитектуре. Платформа 5 лет в разработке, очевидные задачи - решены. При этом не известно, насколько мы хороши, есть много идей фич, но профит от них их - неясен, а хочется понимать заранее. И нет product manager - эту роль выполняет сама команда, тимлиды. Итого: непонятно в какую сторону работать. А хотелось бы иметь ориентиры, например, метрика.
Поискали метрики в индустрии.
* DORA 4 метрики: как часто катите, как быстро докатываете до прода, как часто падаете, как быстро восстанавливаете. И у них есть квалификация low - medium - high - elite. У них платформа позволяет работать на уровне elite, улучшения лежат уже в русле команд. А там идет работа по team maturity model компании
* SPACE: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow - всеобъемлющий, но применение неясно
* Три изменения DevEx: Flow state, cognitive load, feedback loop. Более практичен, и это не CAP-теорема, можно все три улучшать.
Flow State: если инженера прерыват встречи, срочные задачи и блокеры, автономность выбора инженером задачи, понятные цели и задачи проекта - чтобы выбирать, интересные задачи. Не решается техническими средствами, это организация. В avito есть playbook, он это как-то решает.
Cognitive load: насколько надо напрячь мозг, чтобы эту задачу сделать. Непонятный фреймворк или технология, новый бизнес-домен и так далее. Делится на два типа: полезная, которая бьет в решение задачи, и паразитная - нечеткие требования и дополнительные знания, например, кубовые манифесты. Платформа снижает типовые задачи, чтобы разработчик не думал о кубернетисе, о том, что интеграция сломается - есть проверки, можно посмотреть любой сервис и так далее.
Feedback Loops: все действия, которые надо делать разработчику пока решает задачу. Компиляция, циклы запуска тестов и так далее. И pull request при итеративном code review. CI. Итеративные согласования, например, с безопасниками. Количество циклов, вероятно, убрать не сможем, а скорость повысить - да. Они здесь работают через стандартизацию - стандартизирвоанный CI/CD, линтинг, среда разработки с автоматической настройкой зависимости. Среда может поднять для тестов все зависимости, шины данных, базы данных - если нужно для тестов.
Но дальше вопрос: как эту историю мерить? Фреймворк рекомендует три метрики: ощущаемая легкость разработки, ощущаемая удовлетворенность разработчиков, ощущаемая продуктивность. Это все - субъективно.
И на этом часть про теорию заканчивается, и начинается история про практику. Которая начинается с CustDev, при котором понимаешь реальное использование платформы пользователем и их проблемы. Он эффективен, но дорог. Поэтому дополняем его опросом пользователей.
Google-форма с фичами, по каждой оценки: не использую, если использую - удовлетворенность от очень недоволен до очень доволен. И обязательно поле для свободного фидбэка, по опыту половина людей пишут содержательно. Где взять список вопросов? Плохая мысль - попросить это сделать команды разработки платформы, потому что у них представление по устройству платформы, а пользователь использует иным образом. Поэтому берем CustDev и вопросы - по путям пользователя.
👍1
Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали zero-trust политики, стало неудобнее. Но оказалось, что только половина в zero-trust, а вторая половина - flow, если что-то не сработало - неясно как разбираться. И эту часть можно решить, сделали проект с dba.
Разработчик готов мириться с неудобствами, но только если они редки. Часто повторяющиеся операции должны быть безупречны. Лучше сделать проще, но понятно и предсказуемо.
Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev
А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю.
В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
Разработчик готов мириться с неудобствами, но только если они редки. Часто повторяющиеся операции должны быть безупречны. Лучше сделать проще, но понятно и предсказуемо.
Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev
А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю.
В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
#DevOpsConf Екатерина Лысенко из RoboGate. Неизбежность, или Как приучить Devops-инженеров к проектированию. В докладе две части: почему надо проектировать, вторая - что такое - проектирование. И были примеры из реальных кейсов, одни - сквозные по докладу, другие - локальные.
Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или busdev полагает, что его задача ограничена коммутацией контрагентов с бизнесом.
Если приземляем на devops, то работа в рамках должностных обязанностей приводит к тому, что вы все время тушите пожары, которые непрерывно возникают из-за динамики бизнеса. Но когда devops говорят о бизнесе в целом, то они часто все равно ограничиваются автоматизацией и своим пониманием, что они могут сделать. А на вопрос "почему так" отвечают "бизнес так хотел" или "100 лет работает, не трогай". И с такими невозможно говорить.
Проблема, почему devops действуют так, отчасти, в образовании - молодая специализация, университеты не готовят, они самоучки или кончали курсы, где им дали инструменты. И в результате devops не участвуют в архитектурных комитетах, а если участвуют - то не имеют права вето при принятии решений, то есть их приглашают для информирования. И в вакансиях проектирования не требуют.
На мой взгляд, тут определенный логический провал в рассуждении: почему выход за границы специализации непременно означает проектирование, и наоборот, почему работа в границах специализации не включает проектирование, ведь конвейер поставки ты же делаешь не ad hoc. На мой взгляд, ответ дает системный подход: когда ты создаешь подсистему, в данном случае - конвейвер поставки, ты, прежде всего, должен вписать ее в надсистему, а надсистемой в данном случае является работа бизнеса в целом. Внутри подсистемы можно оставаться, только если интерфейс уже кем-то определен, при чем с учетом потенциала подсистемы, а это знает именно devops. F иначе вписывание будет кривое. И в примерах необходимость проектирования была понятна, если devops не участвует, то бизнес прибегает с неразумными решениями.
Проектировщик решает следующие задачи:
* разработка продукта в соответствии с бизнес-вызовами
* поддержка и развития уровня качества продукта
* исполнение технической стратегии
* взаимодействие между бизнес-юнитами
Для решения ему надо понимать 5 проекций. Катя показывала их как уровни, но, на мой взгляд, это не совсем верно.
* Business vision. Полный, включая цели и не автоматизированные сценарии. Именно на этом уровне часто есть альтернативные варианты решений
* System vision. B тут часто надо обобщить разнородные частные решения, которые дали разные команды
* Integration vision. API, и там важно описывать содержание, бизнес-логику взаимодействия, которые лежат за пределами swagger
* Infrastructure vision. Он проявляется наверх, например, есть платежный провайдер, в какой-нибудь стране, где странно пополняют счета меняет json - и сообщения перестают проходить из-за кем-то поставленного ограничения в 1мб.
* Management vision: стратегии, культура. Компания меняет культуру от хакеров с крафтерам: не давай-давай, а тщательно делаем с архитектурой и рисками. И это - напрямую влияет на devops.
Проектирование - не только в крупном. Когда вы делаете анализ инцидента и пишете PIR, то там не так важно, как прошел инцидент. Важно - как не повторить, что изменить, какие меры применить. А это - проектирование.
Для архитектурных решений важно писать ADR - architecture decision record: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.
Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или busdev полагает, что его задача ограничена коммутацией контрагентов с бизнесом.
Если приземляем на devops, то работа в рамках должностных обязанностей приводит к тому, что вы все время тушите пожары, которые непрерывно возникают из-за динамики бизнеса. Но когда devops говорят о бизнесе в целом, то они часто все равно ограничиваются автоматизацией и своим пониманием, что они могут сделать. А на вопрос "почему так" отвечают "бизнес так хотел" или "100 лет работает, не трогай". И с такими невозможно говорить.
Проблема, почему devops действуют так, отчасти, в образовании - молодая специализация, университеты не готовят, они самоучки или кончали курсы, где им дали инструменты. И в результате devops не участвуют в архитектурных комитетах, а если участвуют - то не имеют права вето при принятии решений, то есть их приглашают для информирования. И в вакансиях проектирования не требуют.
На мой взгляд, тут определенный логический провал в рассуждении: почему выход за границы специализации непременно означает проектирование, и наоборот, почему работа в границах специализации не включает проектирование, ведь конвейер поставки ты же делаешь не ad hoc. На мой взгляд, ответ дает системный подход: когда ты создаешь подсистему, в данном случае - конвейвер поставки, ты, прежде всего, должен вписать ее в надсистему, а надсистемой в данном случае является работа бизнеса в целом. Внутри подсистемы можно оставаться, только если интерфейс уже кем-то определен, при чем с учетом потенциала подсистемы, а это знает именно devops. F иначе вписывание будет кривое. И в примерах необходимость проектирования была понятна, если devops не участвует, то бизнес прибегает с неразумными решениями.
Проектировщик решает следующие задачи:
* разработка продукта в соответствии с бизнес-вызовами
* поддержка и развития уровня качества продукта
* исполнение технической стратегии
* взаимодействие между бизнес-юнитами
Для решения ему надо понимать 5 проекций. Катя показывала их как уровни, но, на мой взгляд, это не совсем верно.
* Business vision. Полный, включая цели и не автоматизированные сценарии. Именно на этом уровне часто есть альтернативные варианты решений
* System vision. B тут часто надо обобщить разнородные частные решения, которые дали разные команды
* Integration vision. API, и там важно описывать содержание, бизнес-логику взаимодействия, которые лежат за пределами swagger
* Infrastructure vision. Он проявляется наверх, например, есть платежный провайдер, в какой-нибудь стране, где странно пополняют счета меняет json - и сообщения перестают проходить из-за кем-то поставленного ограничения в 1мб.
* Management vision: стратегии, культура. Компания меняет культуру от хакеров с крафтерам: не давай-давай, а тщательно делаем с архитектурой и рисками. И это - напрямую влияет на devops.
Проектирование - не только в крупном. Когда вы делаете анализ инцидента и пишете PIR, то там не так важно, как прошел инцидент. Важно - как не повторить, что изменить, какие меры применить. А это - проектирование.
Для архитектурных решений важно писать ADR - architecture decision record: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.
Когда ADR нужны?
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...
В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.
На этом - все.
* Необходимо встроить новый продукт в архитектуру
* Реинжиниринг домена сервисов
* Выбор новой технологии
* Есть задачи на реализацию технической стратегии - она долгосрочна и меняется, надо понимать куда шли
Примеры: Единый клиент, оптимизация под рост нагрузки х10, перенос отчетов в BI...
В конце из зала был вопрос: как начать проектирование? На него было два исключающих ответа.
* Просто начните. Кто разрешит? А кто запретит, идешь и делаешь! А руководству показать пользу - на паре инцидентов.
* Если в компании культура тушения пожаров, то в одиночку это не изменить, и в любом случае изменение - не простое.
На этом - все.
❤2