https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0MaksWiki - Блог:Максима Цепкова [ru]2024-03-09T09:34:19ZMediaWikihttps://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-03-09:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-9:_MBTI_-_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D0%BC_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BD%D0%B5%D0%BF%D0%BE%D1%85%D0%BE%D0%B6%D0%B5%D0%B3%D0%BE2024-03-09: Модель личности-9: MBTI - представляем мышление непохожегоMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-03-09T09:30:22Z2024-03-09T09:30:22Z<p>Девятая статья про модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1068280">«<b>MBTI: представляем мышление непохожего</b>»</a> посвящена типологии Майерс-Бриггс, которая, на мой взгляд, является лучшей моделью, позволяющей понять мышление другого, не похожего на тебя человека, представить спектакль жизни на его внутренней сцене. А это – совершенно необходимо для эффективной коммуникации и взаимодействия в команде различающихся людей, которые, по исследованиям Белбина, сильнее однородных команд. Этой статьей я начинаю разбор психологических моделей, сопоставления их с базовым уровнем моделей личности.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">Оглавление серии</a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0p9wX1K88wYrZYuuPMUTSi28czzoZoVZmZ6GvEtPEoFFdwQshw59XbSnYkgr51bSEl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-03-03:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-8:_%D0%AF_%D0%B8_%D0%BC%D0%BE%D0%B8_%D0%B0%D0%B2%D0%B0%D1%82%D0%B0%D1%80%D1%8B2024-03-03: Модель личности-8: Я и мои аватарыMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-03-03T13:29:28Z2024-03-03T13:29:28Z<p>Восьмая статья про модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1058974">«<b>Я и мои аватары</b>»</a> разбирает, сколько у нас аватаров, как они появляются и насколько они автономны, то есть имеют собственный набор целей, желаний и представлений о мире, а также поговорим о сознательном конструировании аватара.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">Оглавление серии</a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0T99oRfAVcuJe6mBb2FECij3wXJEuaKX7qvst1c9NtgcjDqqTp1ujtQtdg5tE82UHl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-02-28:_WAW-2024_-_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82:_%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D1%85_%D0%B4%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%D0%BE%D0%B2_%D0%B8_%D0%BC%D0%B0%D1%81%D1%82%D0%B5%D1%80-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2_%D0%B8_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D1%8B%D1%85_%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B92024-02-28: WAW-2024 - хороший старт: много хороших докладов и мастер-классов и интересных обсужденийMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-02-28T10:25:39Z2024-02-28T10:33:18Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>В середине февраля, 16-18.02 прошел первый <a rel="nofollow" class="external text" href="http://waw-conf.ru/"><b>Winter Analitycal Weekend (WAW)</b></a>. Это была давняя мечта организаторов <a rel="nofollow" class="external text" href="http://lafest.ru"><b>Летнего аналитического фестиваля (ЛАФ)</b></a> — сделать аналогичное событие зимой, и вот она, наконец, осуществилась. Мероприятие было относительно камерным, примерно 150 участников, проходило, как и ЛАФ в загородном отеле, так что можно было не только послушать доклады. но и отдохнуть и позаниматься всякими спортивными активностями. А также - активно общаться не только в перерывах, но и вечером в фойе отеля. Качество докладов было высокое, кроме докладов было много интересных мастер-классов. Кроме того, в замысле организаторов было обсуждение о будущем специализации аналитиков, для этого были организованы обсуждения в группах, которые прошли довольно активно.
</p><p>Я выступал, слушал доклады и участвовал в обсуждениях, вел репортаж на своем телеграм-канале, а сейчас публикую единым отчетом.
Организаторы поощряли активность по организации различных обсуждений, для этого было два отдельных зала, и они оказались заполнены довольно плотно.
</p><p>В частности, <b>Денис Бесков</b> организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести <a rel="nofollow" class="external text" href="https://miro.com/app/board/uXjVNrmW_lw=/"><b>протокол в Миро</b></a> А от меня — ссылка на мои доклады про разделение ответственности в разработке <a rel="nofollow" class="external free" href="https://mtsepkov.org/Roles">https://mtsepkov.org/Roles</a>, которую я обещал участникам. Их было довольно много, тема развивалась.
</p><p>В начале отчета — о моем выступлении. Мне был запрос от организаторов — поразмышлять о развитии ИТ и специализации аналитика. Доклад так и называется <a href="https://mtsepkov.org/%D0%9C%D0%B5%D1%81%D1%82%D0%BE_%D0%98%D0%A2_%D0%B8_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2_%D0%B2_%D0%B1%D1%83%D0%B4%D1%83%D1%89%D0%B5%D0%BC_%D0%BC%D0%B8%D1%80%D0%B5_(WAW-2024)" title="Место ИТ и аналитиков в будущем мире (WAW-2024)"><b>Место ИТ и аналитиков в будущем мире</b></a>: Как учит системный подход, всякую систему надо прежде всего рассматривать в контексте объемлющей надсистемы. А значит, рассказ о будущем ИТ невозможен без рассмотрения развития мира в целом. Поэтому начинался доклад именно со сценариев развития человеческого общества в целом. С одной стороны. события последних лет показывают. что краткосрочные прогнозы тут сомнительны. С другой стороны. долговременные тренды примерно понятны. Все это было в докладе, презентация была сразу опубликована на моем сайте, а видео ожидается примерно в течении месяца после конференции. По отзывам участников, рассказ оказался интересным и полезным.
</p><p>А теперь — про остальные доклады.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>В середине февраля, 16-18.02 прошел первый <a rel="nofollow" class="external text" href="http://waw-conf.ru/"><b>Winter Analitycal Weekend (WAW)</b></a>. Это была давняя мечта организаторов <a rel="nofollow" class="external text" href="http://lafest.ru"><b>Летнего аналитического фестиваля (ЛАФ)</b></a> — сделать аналогичное событие зимой, и вот она, наконец, осуществилась. Мероприятие было относительно камерным, примерно 150 участников, проходило, как и ЛАФ в загородном отеле, так что можно было не только послушать доклады. но и отдохнуть и позаниматься всякими спортивными активностями. А также - активно общаться не только в перерывах, но и вечером в фойе отеля. Качество докладов было высокое, кроме докладов было много интересных мастер-классов. Кроме того, в замысле организаторов было обсуждение о будущем специализации аналитиков, для этого были организованы обсуждения в группах, которые прошли довольно активно.
</p><p>Я выступал, слушал доклады и участвовал в обсуждениях, вел репортаж на своем телеграм-канале, а сейчас публикую единым отчетом.
Организаторы поощряли активность по организации различных обсуждений, для этого было два отдельных зала, и они оказались заполнены довольно плотно.
</p><p>В частности, <b>Денис Бесков</b> организовал очень интересное обсуждение про аналитиков: их область ответственности, хорошие практики, критерии выбора подходящих людей, способы обучения. Я активно участвовал, а участвовать и конспектировать у меня не получается. А Денис ухитрялся вести <a rel="nofollow" class="external text" href="https://miro.com/app/board/uXjVNrmW_lw=/"><b>протокол в Миро</b></a> А от меня — ссылка на мои доклады про разделение ответственности в разработке <a rel="nofollow" class="external free" href="https://mtsepkov.org/Roles">https://mtsepkov.org/Roles</a>, которую я обещал участникам. Их было довольно много, тема развивалась.
</p><p>В начале отчета — о моем выступлении. Мне был запрос от организаторов — поразмышлять о развитии ИТ и специализации аналитика. Доклад так и называется <a href="https://mtsepkov.org/%D0%9C%D0%B5%D1%81%D1%82%D0%BE_%D0%98%D0%A2_%D0%B8_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2_%D0%B2_%D0%B1%D1%83%D0%B4%D1%83%D1%89%D0%B5%D0%BC_%D0%BC%D0%B8%D1%80%D0%B5_(WAW-2024)" title="Место ИТ и аналитиков в будущем мире (WAW-2024)"><b>Место ИТ и аналитиков в будущем мире</b></a>: Как учит системный подход, всякую систему надо прежде всего рассматривать в контексте объемлющей надсистемы. А значит, рассказ о будущем ИТ невозможен без рассмотрения развития мира в целом. Поэтому начинался доклад именно со сценариев развития человеческого общества в целом. С одной стороны. события последних лет показывают. что краткосрочные прогнозы тут сомнительны. С другой стороны. долговременные тренды примерно понятны. Все это было в докладе, презентация была сразу опубликована на моем сайте, а видео ожидается примерно в течении месяца после конференции. По отзывам участников, рассказ оказался интересным и полезным.
</p><p>А теперь — про остальные доклады.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B8.D1.88.D0.B5.D1.80_.D0.A3.D0.BC.D0.B0.D1.80.D0.BE.D0.B2._.D0.90.D0.BD.D0.B0.D0.BB.D0.B8.D1.82.D0.B8.D0.BA_2.0.C2.A0.E2.80.94_.D0.A8.D0.B5.D1.81.D1.82.D0.B8.D1.80.D1.83.D0.BA.D0.B8.D0.B9_.D0.A8.D0.B8.D0.B2.D0.B0_.D0.B8.D0.BB.D0.B8_.D0.BA.D0.B0.D0.BA_.D0.B2.D1.8B.D0.B6.D0.B8.D1.82.D1.8C_.D0.B2_.D1.81.D0.BE.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.80.D0.B5.D0.B0.D0.BB.D0.B8.D1.8F.D1.85_.D1.81_.D0.98.D0.98">Алишер Умаров. Аналитик 2.0 — Шестирукий Шива или как выжить в современных реалиях с ИИ</span></h1>
<p><b>Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.</b>
</p><p>Это несложно, и сильно повышает производительность, есть замеры. До 70 % на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай… Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита — для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
</p><p>В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
</p><p>И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
</p><p>Что нужно для этого? Главное — надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL — синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности — надо разжевывать, писать структурно. Это полезно не только для ИИ.
</p><p>Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
</p><p>Зачем это надо? Аналитик может стать core-участникам команды.
</p><p>Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований — имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ — и он реально поможет.
</p><p>А вот умение говорить со всеми интересантами — это пока самому, отдельная компетенция.
</p><p>Как делать, чтобы не утекало? Сбер и ВТБ — стали делать свои модельки. Еще можно обезличивать — как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
</p><p>Из комментариев.
</p>
<dl><dd> Phil Delgyado. Хмм. В известном чате сисаналитиков есть свой чатбот. И я регулярно смотрел на вопросы и ответы. И 70 процентов ответов (в моей компетенции) содержат критические ошибки — пропущены важные тезисы, придуманы несуществующие возможности, просто куча воды и так далее. Опытный специалист в теме — да, может использовать ответы как источник 'воды' или проверку 'не забыл ли что'. Неопытному ответы от текущего AI скорее вредны. Ну и если в компании внедрение chatgpt дает большую прибавку к производительности, значит значительная часть артефактов просто не нужна и надо бы процессы починить)</dd>
<dd> mtsepkov. Ну, там были конкретные примеры: опиши api по тексту формально для swagger, нарисуй по тексту диаграмму и т. п. Там понятная экономия времени и польза. Речь про «расскажи чего не знаю», в основном, не шла. То есть это — не средство повысить квалификацию, а средство быстрее сделать полутехническую часть работы.</dd>
<dd> Phil Delgyado. Вот все эти примеры, на мой взгляд, про вредное. Не должно быть таких задач вообще.</dd>
<dd> mtsepkov Это не отдельные задачи, а кусочки. То есть нет задачи «сделать описание для swagger по тексту», есть задача «спроектировать api», результат — в формате swagger. Её человек может делать сам, а может — давая текстовые описания ИИ с просьбой выдать результат. Второй способ быстрее. С диаграммами — аналогично. И так далее.</dd></dl>
<h1><span class="mw-headline" id=".D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9_.D0.91.D0.B5.D0.B7.D1.83.D0.B3.D0.BB.D1.8B.D0.B9._.D0.A2.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D1.8F_.D0.BE.D1.82.D0.B4.D0.B5.D0.BB.D0.B0_.D0.90.D0.BD.D0.B0.D0.BB.D0.B8.D0.B7.D0.B0:_.D0.9F.D1.83.D1.82.D0.B8_.D0.BA_.D0.A3.D1.81.D0.B8.D0.BB.D0.B5.D0.BD.D0.B8.D1.8E_.D1.80.D0.BE.D0.BB.D0.B8_.D0.B8_.D1.86.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.B2_.D1.83.D1.81.D0.BB.D0.BE.D0.B2.D0.B8.D1.8F.D1.85_.D0.B8.D0.BD.D1.82.D0.B5.D0.BD.D1.81.D0.B8.D0.B2.D0.BD.D0.BE.D0.B9_.D1.86.D0.B8.D1.84.D1.80.D0.BE.D0.B2.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D0.B8">Дмитрий Безуглый. Трансформация отдела Анализа: Пути к Усилению роли и ценности в условиях интенсивной цифровизации</span></h1>
<p>У Димы, как часто бывает, получился доклад из ряда не слишком связанных, на мой взгляд, тезисов. Но каждый из них — отдельно интересен.
</p><p>Зачем презентация? Мы пришли в ИТ чтобы сделать мир лучше. И мечтаем о том, чтобы компания принимали стратегические и локальные решения разумно, с учетом последствий, чтобы продуктами можно было гордиться. Он в эту сторону работает уже много лет, а ощущения — как лягушка толкает бегемота.
</p><p>Информатизация — этап, когда ИТ использовалось чтобы улучшить процессы в компаниях. Enterprise unify process — апофеоз. Позиционирование. БА — гуру, которые помогают бизнесу принимать решения. СА — гуру в области реализации. Но этот этап — прошел. А новый этап — цифровизация. И твердый факт: ИТ и отделы проектирования не возглавили цифровизацию. И вообще прошла мимо CIO.
</p><p>Почему? Потому что аналитики могут быть интересны бизнесу как партнеры, А для этого они должны уметь анализировать рынок, конкурентов, unit-экономику, прогнозировать. А они — не про это, они бодаются о том, писать use case или user story, а от бизнеса ждут постановки задачи. И бизнес теряет интерес, и не видит, о чем разговаривать.
</p><p>Впрочем, у бизнеса тоже бывают странные представления про аналитиков. В Авито был период, когда велели всем аналитикам обучиться BABOK. B они пытались натянуть эту теорию на свою практику.
</p><p>Взаимодействие бизнеса и ИТ бывает печально: из 100 заявок, реализуется 2, при этом ломается в 10 местах, идут критические баги. А дальше — стокгольмский синдром, бизнес от ИТ зависит, «давайте дружить мирно». Впрочем, я думаю, что Дима тут сильно утрирует ситуацию. И реакция зала говорит о том же. Реально ИТ дает ценность для бизнеса, и бизнес — понимает какую именно.
</p><p>Цифровизация — история не про то, что берем существующий бизнес и пытаемся усилить ИТ, к 100 людям в операционке добавить 50 ИТ и взлететь. Это идея о том, чтобы заменить тех людей. Не ходить к прачке с вопросом, как сделать автоматическую стиральную машину. Кредитный конвейер — не то, чтобы поддержать работу 10к андерайтеров. Они про то, чтобы работал автомат, который поддерживают 20 человек и 200 человек разбирали не типовые частные случаи. То есть ИТ должно перестроить бизнес.
</p><p>С моей точки зрения, тут и правда и неправда. Потому что информатизация — тоже про это, и задачи такого изменения кредитного конвейера я слышал еще в конце 90-х, и не просто слышал, банки так и делали. Конечно, бывает и то отношение, о котором говорил Дима, и когда-то был этап, когда автоматизация преимущественно поддерживала бизнес, но это было давно. Еще в 2017, рассказывая про эволюцию ИТ-проектов на SECR я говорил о сращивании ИТ и бизнес-частей проекта, смотри 7 слайд презентации <a rel="nofollow" class="external free" href="https://mtsepkov.org/BA-methods-SECR-2017">https://mtsepkov.org/BA-methods-SECR-2017</a>
</p><p>При этом Дима тут же делает вывод о том, что от проектов надо переходить к продуктам. Но рассказанная история про кредитный конвейер не создает никаких новых продуктов, нет там никакого продуктового мышления. Продуктовое мышление — про другое. Про что именно продуктовое мышление, на мой взгляд, Дима так и не сказал.
</p><p>Но вот то, что классическая проектная организация, особенно с выделением ИТ-проекта — тупиковая ветвь развития — в целом правильно, тут я согласен.
</p><p>Дальше был спорный тезис о том, что даже когда бизнес не слишком готов к цифровизации, аналитик должен наносить пользу и должен делать бизнес все более цифровым, насколько это возможно. На мой взгляд, чаще всего в результате такого подхода будет не польза, а вред, за который аналитик будет огребать, а потом жаловаться, что бизнес его не так понял.
</p><p>А вот что верно, это схема современного изменения в управлении, которая зафиксировала ряд переходов.
</p>
<ul><li> Задачи -> Цели</li>
<li> Люди -> Команды</li>
<li> Мотивация -> Ценность</li>
<li> Процессы -> Продукты</li>
<li> Структура (иерархия) -> Сеть</li></ul>
<p>Отсюда метастратегия: от оптимизации к трансформации. Задача анализа: двигаться от проектов в создание и развитие продуктов; быть источником данных для data driven decision. При этом работа с данными часто чистое поле, которое легко отдают. Дальше задача — научиться извлекать из data lake то, что будет наносить пользу бизнесу. Не ждать от бизнеса задачи, а самому порождать идеи.
</p><p>И в конце была очень интересная схема как стать частью решения, с конкретными областями. На ней Product lab — песочница, в ней весело. Stars Fab — новые растущие продукты, здесь офигенно. А начинаем с Data Lab.
</p><p>К моему конспекту был комментарий Димы: «С моих слов записано не верно))) Спасибо за конспект». В общем, да, я всегда интерпретирую в конспекте и в результате смысл может отличаться от замысла автора. Это относится ко всем конспектам.
</p>
<h1><span class="mw-headline" id=".D0.9D.D0.B0.D1.82.D0.B0.D0.BB.D1.8C.D1.8F_.D0.A1.D0.B5.D0.BC.D0.B5.D0.BD.D0.BE.D0.B2.D0.B0._.D0.9A.D0.BE.D0.BD.D1.86.D0.B5.D0.BF.D1.82.D1.83.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5.C2.A0.E2.80.94_.D0.B4.D1.80.D0.B0.D0.B9.D0.B2.D0.B5.D1.80_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F_.D0.B8_.D0.BF.D1.80.D0.B5.D0.BE.D0.B4.D0.BE.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BD.D0.B5.D0.BF.D1.80.D0.B5.D0.BE.D0.B4.D0.BE.D0.BB.D0.B8.D0.BC.D0.BE.D0.B3.D0.BE">Наталья Семенова. Концептуальное мышление — драйвер развития и преодоления непреодолимого</span></h1>
<p>Для меня загадка этого доклада — ссылка на первоисточник концепции концептуального мышления как подхода к мышлению. Быстро находится Conceptual Thinking, но это вроде что-то другое. Из доклада я бы сформулировал, что концептуальное мышление — просто мышление с помощью концепций. Для которого выделено 7 уровней, начиная с 0:
</p>
<dl><dd> 0 — не пользуется</dd>
<dd> 1 — пользуется базовыми правилами</dd>
<dd> 2 — распознает модели</dd>
<dd> 3 — применяет сложные концепции</dd>
<dd> 4 — упрощает сложность</dd>
<dd> 5 — создает новые концепции</dd>
<dd> 6 — создает новые концепции по сложным вопросам</dd>
<dd> 7 создает новые модели</dd></dl>
<p>Это я записал со слайда, можно подробнее посмотреть на телеграм-канале Наташи <a rel="nofollow" class="external free" href="https://t.me/SmartSpeaker_public/48">https://t.me/SmartSpeaker_public/48</a>
</p><p>Дальше в докладе было много историй, как различные концепции помогали ей решать разные ситуации в жизни. Как иллюстрация самого подхода.
</p><p>Смена взгляда inside — inside out — outside in помогла разобраться в ситуации, когда она не видела развития и ушла из аналитиков выращивать чеснок. Мы часто видим сферу, в которой находимся. И не знаем, что за ней. И потому не знаем куда идти — внутри все известно, а снаружи — неизвестность и муть. Надо выйти в inside out и далее outside in.
</p><p>Лалу в открывая организации будущего дал схемы развития мышления: импульсивная, конформисткая, достиженческая, плюралистическая, эволюционная парадигмы.
</p><p>IGOE framework (inputs guides outputs enablers) помог выбрать направления развития.
</p><p>Цикл Колба, который начинается с ошибки: опыт — анализ — теория — практика. Его применил руководитель, спровоцировав ее развитие, а концепт она узнала через пару лет.
</p><p>Окно Джохари: мне/другим известно/неизвестно. 4 зоны, и есть зона неизвестного. И многие консультанты дают модели, известные им, но неизвестные вам. Вы приходите к семейному консультанта, он говорит: «у вас разные языки любви» или «вы в треугольнике Карпмана». Модель описывает частично, вы понимаете — и снова к психологу. Но если бы знали самостоятельно — могли бы применять. И учитывать сложность. Но там есть область неизвестного ни вам ни другим, что в ней делать?
</p><p>У нее был доклад про делегирование, который реально был про лидерство. В какой-то момент поняла, что от нее ждут лидерства, принятия решений, и начала это делать, и учиться этому. Но пошел конфликт с руководителем. Разобраться помогла модель Адизеса: она и руководитель были предприниматели, а модель объясняет, что они всегда будут конфликтовать. Ситуацию объяснили. Модель помогает и решить ситуацию, и строить команды — чтобы были нужные факторы.
</p><p>Модель холакратии — выстраивание автономных зон ответственности и принятия решений.
</p><p>Как только узнал про модель — можно применить. И это экономит время. Ты идешь наверх — всегда упираешься во что-нибудь.
</p><p>Читала про VUCA — BANI — не заходило. Хотя антихрупкость зашла — а она про BANI. Но последние 2 года перешла из западной компании в российскую. Многое перестало работать. Почему? И нашла концепт SHIVA — он дал объяснение: зарождается новый мир, а не просто разрушается старый. И она поставила вопрос: как надо изменить парадигму мышления чтобы в SHIVA-мире жить, не изменяя ценностям. И она выписала: что нельзя делать, и что другое нужно делать. Согласовала мышление с миром.
</p><p>И выводы. Что делать для развития концептуального мышления
</p>
<ul><li> Менять взгляд inside-out — outside-in</li>
<li> Изучать существующие концепции, не переизобретайте велосипеды</li>
<li> Переводите в диаграммы — об этом не было, но это очень полезно, и все модели были визуальными. А это перенастраивает мозг</li>
<li> Идите туда, где нет готовых решений</li></ul>
<p>Только помните: концепции упрощают, поэтому важно знать много и смотреть с разных сторон.
</p>
<h1><span class="mw-headline" id=".D0.95.D0.B2.D0.B3.D0.B5.D0.BD.D0.B8.D0.B9_.D0.A1.D0.BA.D0.BE.D1.80.D0.B8.D0.BA.D0.BE.D0.B2._.D0.9C.D0.BE.D0.B4.D0.B5.D0.BB.D0.B8_.D0.B0.D0.B2.D1.82.D0.BE.D0.BC.D0.B0.D1.82.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D0.B8_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81.D0.BE.D0.B2_.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.BE_.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D1.85_.D1.82.D1.80.D0.B5.D0.B1.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B9">Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований</span></h1>
<p>Очень интересный доклад о том, как реально происходит проектирование систем. Не теоретически обоснованным одним спуском по уровням, пусть даже замкнутым в итерационный цикл, а с многочисленными возвратами. И какие мыслительные операции выполняются на каждом шаге. И поскольку он это делает не осознанно, то у него боль от несоответствия идеальному процессу, описанному в учебниках, а еще он может пропускать важные, но не очевидные шаги. В презентации было много схем, а у меня будет линейный конспект.
</p><p>Уровни — есть:
</p>
<ul><li> Бизнес в целом — вписка в рынок</li>
<li> бизнес-процессы</li>
<li> модель автоматизации БП</li>
<li> Функциональный дизайн ИТ-систем</li>
<li> Конструктивный дизайн ИТ-систем</li></ul>
<p>Но в динамике по ним разворачивается сложный путь.
</p><p>Рассказ был на конкретном примере, что позволяло почувствовать, что лежит за словами: фотостудия для интернет-магазина, в которую привозят образцы товаров для фото и публикации, а сами образцы возвращают на склад. И на входе процесс был организован вручную.
</p><p>Вводная: ручной процесс трудоемок и дает ошибки при привязке фото к товарам, давайте попробуем это улучшить с помощью автоматизации. Типичная вводная от бизнеса.
</p><p>Первый шаг — модель процесса. Бизнес ее не принес. Тут она проста: заказать, привезти, снять и две ветви: привязать к товару и отобразить, а товар вернуть на склад.
</p><p>2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой — идея решения.
</p><p>Заказ решается быстро, делаем отчет, сравнивая товары на складе с наличием фотографий товаров.
</p><p>С привязкой — сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.
</p><p>У решений выписываем плюсы и минусы — по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик — он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика — подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная — она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.
</p><p>Дальше решение детализируется по разным бизнес-процессам.
</p>
<ul><li> Детализировать модель — по шагам</li>
<li> Детализировать контекст. Съемка одежды и съемка конструктора — разное: одеть куртку на манекен или собрать из конструктора что-то — разное время. А декоративная сетка — вообще нельзя в студии.</li>
<li> Детализация бизнес-процесса. Своя фотостудия или чужая — тогда билинг и так далее, ценообразование с выбором фотостудии.</li>
<li> Контроль качества</li>
<li> Управление процессом</li>
<li> Обеспечение деятельности — расходники и так далее.</li>
<li> Фискальный аспект</li>
<li> Последовательность, организация, информация.</li></ul>
<p>Для шагов есть типовые задачи, например, заказ со склада — там надо использовать, не придумывать. А есть — не типовые, их надо уметь конструировать через типовые. И нужен опыт оценки трудоемкости, чтобы удерживать стоимость.
</p><p>Это все — проработка на бизнес уровне.
</p><p>3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной — увеличивает ошибки, на товаре — может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.
</p><p>Когда мы поделили на задачи — потерялась связь между ними. Печать ШК на накладной — это основной способ их получить, или это workaround когда нет ШК на товаре, и на первом шаге можно без него? При этом печать накладной, скорее всего, уже есть, то есть нам надо доработать стандартную фичу, и, наверное, вставить эту задачу соответствующей команде — поэтмоу важно понимать критичность.
</p><p>Еще делаем проекцию на структуры данных. ШК — может ли один быть у нескольких товаров и так далее.
</p><p>При проекции не создается новых знаний или принятие решений. Просто преобразование.
</p><p>4. Возврат на проектирование — при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.
</p><p>Обработка исключений. Фотограф забыл сделать фото ШК, или система не может ШК распознать — как исправляется ситуация? Например, поскольку на товаре ШК может быть плохой, печать на накладной дублирует возможность сделать фото.
</p><p>При возврате к уровень бизнес-процессов они могут меняться, и, возможно, потребуются доработка автоматизации.
</p><p>4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров — разное количество. Например, у обуви 7, у одежды — 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка — в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.
</p><p>5. Есть модель автоматизации — делаем дизайн. А потом идет возврат от дизайна к модели. Аналитики часто делают дизайн в рамках конкретного типового набора. А в конкретных случаях может быть нужен выход за типовые рамки. И от дизайна — идет возврат на уровень конструкции системы и бизнес-процессов с учетом дизайна.
</p><p>6. Конструкция. Типовые деления, виды приложений, которые мы используем.
</p><p>7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?
</p><p>8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров — получили объемы, они дают технические решения. И тут могут появиться проблемы.
</p><p>9. Проработка аспектов качества — было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд — очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.
</p><p>Аспекты качества — на разных уровнях. Верхний — качество бизнес-процессов, а автоматизация — одна из тактик. Хотя качество автоматизации тоже играет.
</p><p>Источник идей автоматизации не обязательно прилетает сверху, от бизнеса. Он может быть снизу — от новых технологий, от идей команд.
</p><p>В завершении — комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.
</p><p>А где функциональные требования? Они возникали во всех операциях в двух случаях.
</p>
<ul><li> При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно — и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают — и нельзя проверить ТЗ.</li>
<li> Модель взаимосвязи разных моделей.</li></ul>
<p>Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн — работа с моделью. Проекция моделей — тоже без ФТ.
</p><p>Итого, аналитик не просто обеспечивает согласованность решений стейкхолдеров, он делает оптимальное решение. Первое решение далеко не всегда оптимально.
</p>
<ul><li> Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.</li>
<li> Решения по выбору принимает менеджер.</li>
<li> Все это делаем используя некоторое количество мыслительных операций, они перечислены.</li>
<li> Между уровнями — всегда конструкция. Внутри уровня может быть проекция.</li></ul>
<p>И есть боль. В постановках очень часто пишут, что надо изменить. И в результате разобраться, как система работает в окружении очень сложно — надо инкрементально проработать все постановки. Нужно быть представление, чтобы работать сейчас.
</p>
<h1><span class="mw-headline" id=".D0.91.D0.BE.D1.80.D0.B8.D1.81_.D0.92.D0.BE.D0.BB.D1.8C.D1.84.D1.81.D0.BE.D0.BD._.D0.9B.D0.B0.D0.BD.D0.B4.D1.88.D0.B0.D1.84.D1.82_.D1.81.D1.82.D1.80.D0.B0.D1.82.D0.B5.D0.B3.D0.B8.D0.B9_.D0.B2_.D0.B1.D0.BE.D0.BB.D1.8C.D1.88.D0.BE.D0.B9_.D0.BA.D0.BE.D0.BC.D0.BF.D0.B0.D0.BD.D0.B8.D0.B8">Борис Вольфсон. Ландшафт стратегий в большой компании</span></h1>
<p>Сфокусированный и минималистичный рассказ про то, как делать стратегию с конкретными фреймворками и материалами. Иллюстрирвоанный примером Сбермаркета и еще нескольких. Сбермаркет — динамично развивающийся стартап, с с 2016, 2019 — 1.9, 2020 — 20.7, 2021 — 62.6, 2022—102.8, в конкурентной среде: Озон фреш, Вкусвилл, Wildberries и т. д. Когда пришел, были явные признаки проблем со стратегией: постоянные пожары и хаотичное планирование — план на квартал-год с непонятными целями. Вообще типичная ситуация — каждое подразделение бежит в свою сторону, и менять курс, перефокусироватсья — сложно. Есть успешный пример Netflix, который рассылал DVD и смог переключиться на стриминг. А его конкурент блокбастер — не смог.
</p><p>В России идет активный выход, но есть большие бренды, у которых нет интернет-продаж, и у них могут начаться проблемы. И надо уметь фокусироваться в одном направлении и в идеале — как единое целое. Сейчас интенсивный рост у Самоката и Яндекс-лавке. Чем они отличаются? У них — узкий ассортимент, 2-3к, в отличие от Магнита 5-6к или супермаркета на 10-15к. Зато сделали фокус на скорость доставки. То есть фокус — это еще и отказ от каких-то направлений.
</p><p>Фокусировку важно согласовывать вплоть до слова, расхождения во мнениях топов вызывает большие расхождения ниже — правило маятника. Прибыльные и неубыточные — о разном. Стратегическое видение — 1-2 страницы текста, и проходят несколько раз, добиваясь понимания.
</p><p>Стратегию надо не только принять, надо еще и действовать в соответствии с ней. Типичная ситуация, когда операционка и мелкие проекты забирают львиную долю времени, а на большие стратегические проекты его не остается. Правильно — наоборот. Об этом была известная иллюстрация про заполнение банки камнями: начинать надо с крупных проектов с ключевыми ставками, а мелочь должна заполнять промежутки, а не наоборот. стратегических проектов мало, на 6к человек — не более 10. Стратегия из 100 шагов никогда не будет сделана.
</p><p>Пример фокусировки. В ecomerce 3 направления: быстрые и удобный сервис, широкий ассортимент и выгодные цены. Провели анализ в 2020 и сфокусировались на сервисе. В после начала СВО перефокусирвоались на выгодных ценах — стало более востребовано.
</p><p>Что НЕ делаем — тоже есть в документе. В 2020 году было зафиксировано:
</p>
<ul><li> Core — доставка grocery essentials из любимых магазинов.</li>
<li> Не запускаем moms & pops формат — любимые магазины на районе</li>
<li> Не делаем работаем с услугами, не делаем youdo и подобное</li></ul>
<p>Ландшафт стратегий.
</p>
<ul><li> Корпоративный: платформа на каждый день + устойчивый, прибыльный и публичный бизнес</li>
<li> Вертикальные стратегии: клиенты, ритейлеры, сборщики и курьеры, бренды, новые вертикали и эксперименты</li>
<li> функциональный уровень: продукт, разработка.</li></ul>
<p>На функциональном уровне.
</p>
<ul><li> Видение продукта, через 5 лет или через 1-2 года (зависит от стабильности). Целевой CJM в сбермаркете. Или в B2b телекоме — день сотрудника в контексте работы. Haven & help: текущая картинка для вашего или чужого продукта с болями, и идеал</li>
<li> 5-7 ключевых инициатив. Метрики и ответственные за них.</li></ul>
<p>Фреймворк PlayToWin — для вертикальных стратегий. Делал Procter & Gamble, доступны шаблоны
</p>
<ul><li> Цели inspirations — большая вдохновленная цель, супер-OKR. Как у Форда: машин должно стать больше лошадей.</li>
<li> Where to play — рыночные сегменты где играем и где НЕ играем, точки атаки. HH когда начинался — только на белых воротничках, а только потом только пошел на синие.</li>
<li> How will we win choosen markets Как мы победим на этом рынке</li>
<li> Capabilities и management systems</li></ul>
<p>Самое пробемное — выбор рынка и способа победы на них. Канвасы value proposition, в книге Blue ocean strategy
</p><p>6-страничник — основной формат для создания и обсуждения стратегии. Не презентация. Есть шаблон от Амазон. Черновик, разослать и попросить прокомментировать. И разбор, правка. Чтобы на выходе встречи был документ.
</p><p>Книги:
</p>
<ul><li> playing to win — фреймворк</li>
<li> good strategy bad strategy — различия</li>
<li> Blue ocean strategy — инструменты value канвас</li>
<li> Working Backwards Colin Bryar and Bill Carr</li>
<li> On strategy сборник Harvard business review — там конкретные кейсы</li></ul>
<p>Как доносить до команд?
</p>
<ul><li> 6-страничник обсуждается с продуктовыми директорами, и к концу обсуждения каждый понимает для своего подразделения</li>
<li> Потом презентация продуктовым лидам. На каждый параграф текста рисуют 2-3 экрана — восприятие для визуалов. И эта презентация показывается всем, нужен overcommunication</li>
<li> Цели — OKR. У каждой ключевой ставки есть метрики. И дальше идет вниз. Именно это обеспечивает исполнение.</li></ul>
<p>Где именно определяются показатели — зависит от культуры компании, у него есть опыт и сверху и снизу. В любом случае это согласуется.
</p><p>Каждый человек понимает, что такое быстрая доставка или хорошие цены. И как он может повлиять своей работой. Наприvер, на выгодные цены менеджер по работе с поставщиками влияет за счет договоренности об акциях и скидках, которые делают цены выгоднее, а доставщики — снижением себестоимости доставки, чтобы предложить лучшие условия доставки.
</p><p>И в заключении — что делать.
</p>
<ul><li> Прочтите материалы</li>
<li> Попробуйте формат 6-страничника</li>
<li> Попробуйте инструменты для отдельных элементов стратегии</li>
<li> В рамках большой компании попробуйте сделать ландшафт стратегий</li></ul>
<p><a rel="nofollow" class="external text" href="https://docs.google.com/document/d/1WMEhx7VRc7zjX36K7ZEDJPQMI54fmWevFDs7xq3R4Jc/edit"><b>Шаблон 6-страничника</b></a>.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-02-26:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-7:_%D0%92%D0%BD%D1%83%D1%82%D1%80%D0%B5%D0%BD%D0%BD%D1%8F%D1%8F_%D1%81%D1%86%D0%B5%D0%BD%D0%B0_%D0%B8_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C2024-02-26: Модель личности-7: Внутренняя сцена и объективная реальностьMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-02-26T15:15:20Z2024-02-26T15:15:20Z<p>Очередная статья про модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1048774">«<b>Внутренняя сцена и объективная реальность</b>»</a> посвящена спектаклю, который разворачивается наше мышление. Он обеспечивает планирование будущего и рефлексию прошлого. Декорации этого спектакля – представления человека о мире, а играют в нем актеры-аватары, созданные человеком по собственным представлениям о себе и о других людях. И все наши оценки себя и окружающего мира выполняются на основе этого спектакля. Так что <b>метафора Вильяма Шекспира «Мир – театр, В нем женщины, мужчины, все – актеры»</b> оказывается не просто метафорой, а достаточно точным описанием происходящего. Я поднимаю системный уровень рассмотрения нашего мышления, абстрагируюсь от конкретных ансамблей нейронов и смотрю на то, что в целом разворачивается в нашем мозге за счет их работы.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">Оглавление серии</a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid024VTe9u5dxLAYKne14bGZZgvP6Bm9YYCN1TW98nhHfuAiByqn1NfsgR9CunE24FKBl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-02-21:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-6:_%D0%BA%D0%B0%D0%BA_%D0%BE%D0%B1%D1%83%D1%87%D0%B0%D0%B5%D1%82%D1%81%D1%8F_%D0%BD%D0%B0%D1%88_%D0%BC%D0%BE%D0%B7%D0%B32024-02-21: Модель личности-6: как обучается наш мозгMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-02-21T15:45:21Z2024-02-21T15:45:21Z<p>После некоторого перерыва публикую шестую статью про инженерную модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1042085">«<b>Модель личности: как обучается наш мозг</b>»</a>. Она посвящена различным механизмам, обеспечивающим формирование ансамблей нейронов, образующих модель мира, на основе которой человек принимает решения и действует.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">Оглавление серии</a>
[<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid02q3FytAsqNYmLjMRBqwKAbtcE6Ssc7UUkkDVqfWPc6TLcDYxcAi7XNYupmj5RKwTul">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-02-06:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-5:_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC%D1%8B_%D0%B4%D1%80%D0%B0%D0%B9%D0%B2%D0%B0_%D0%B8_%D0%BC%D0%BE%D1%82%D0%B8%D0%B2%D0%B0%D1%86%D0%B8%D0%B82024-02-06: Модель личности-5: механизмы драйва и мотивацииMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-02-06T09:31:55Z2024-02-06T09:31:55Z<p>Пятая статья про инженерную модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1018029">«<b>Модель личности: механизмы драйва и мотивации</b>»</a> продолжает тему эмоций и рассказывает про механизмы, которые обеспечивают нам драйв и мотивацию, и про управление ими – чтобы любая наша деятельность: работа, семья, воспитание детей – давали драйв и приносили радость и удовлетворение в достаточной мере.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">Оглавление серии</a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0wv5zeqGvREhoX64PoALJhCKMVS8M9DhrLGh35CBMCbbk5g4caJhuVR9wecPU6Fzrl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-01-29_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8-4:_%D0%AD%D0%BC%D0%BE%D1%86%D0%B8%D0%B8_%D0%B8_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B8%D0%BC%D0%B8_-_%D0%BD%D0%B0%D1%88_%D0%B2%D0%BD%D1%83%D1%82%D1%80%D0%B5%D0%BD%D0%BD%D0%B8%D0%B9_%D0%BA%D0%BE%D1%82%D0%B8%D0%BA2024-01-29 Модель личности-4: Эмоции и управление ими - наш внутренний котикMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-01-29T15:46:27Z2024-01-29T15:46:27Z<p>Четвертая статья про инженерную модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/1006659"><b>«Эмоции и управление ими – наш внутренний котик»</b></a> посвящена эмоциональным механизмам. Эмоции влияют на все наше состояние, включая способности к мышлению, поэтому это важная составляющая модели личности. Эти механизмы эмоций были сформированы у млекопитающих при переходе от инстинктов и рефлексов к обучению как основному методу передачи знаний. Они включают центры регулирования, связанные с разными видами позитива и счастья, и другие центры, задача которых – обеспечить быструю реакцию на опасные ситуации. Чтобы управлять своими эмоциями, этим механизмы стоит представлять детально. Они лежат ниже уровня осознанного мышления, однако, зная их, можно научиться эффективно управлять своими эмоциями косвенным образом. Подчеркну: не контролировать эмоции, не держать их в узде, не бороться с ними, а управлять так, чтобы наша жизнь в целом была богаче, разнообразнее и позитивнее. Я планировал рассказать все механизмы эмоций в одной статье, но она получается очень объемной. Поэтому в этой статье фокус будет на эмоциональную оценку ситуации, а механизмы мотивации и счастья мы разберем в следующей.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Оглавление серии</b></a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0UhT4RgYabztJCzKuNDhFhTwhUWMxF4nSTnZJ2Z4KvRoYPeUQfedH247xz4CHPx2Nl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-01-19:_%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D0%BC%D0%BE%D0%B7%D0%B3%D0%B0:_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B8_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D1%81%D0%B0%D0%BC%D0%B8%D0%BC_%D1%81%D0%BE%D0%B1%D0%BE%D0%B92024-01-19: Работа мозга: уровни управления самим собойMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-01-19T12:07:58Z2024-01-29T15:46:12Z<p>Третья статья про инженерную модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/992606">«<b>Работа мозга: уровни управления самим собой</b>»</a> рассматривает контуры мышления, которые управляют нами. Привычная точка зрения состоит в том, что нами управляет единственный осознаваемый поток мыслей. Правда, иногда в нем появляются мысли ниоткуда, а иногда мы делаем что-то странное, и приходится разбираться, как же оно получилась. А реальность состоит в том, что у нас в мозге есть несколько контуров управления, и часть из них – наши автопилоты, которые не слишком осознаются нашим сознанием. Гриша Петров, с которым я обсуждал представленную в статье схему при подготовке доклада на #TeamleadConf, утверждает, что она соответствует большинству современных моделей мозга. Ну, с точностью до терминологии, это понятно. Статья получилась большая, но я решил не делить на две. Хорошего чтения! Продолжение следует…
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Оглавление серии</b></a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid02bkKsXC4K52fzQ1828t7PzkvegHRFgZLCRAg2JwPzjfVBEe6FZYoisTJ2u9x2npRnl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-01-16:_%D0%91%D0%B0%D0%B7%D0%B0_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_-_%D0%B0%D0%BD%D1%81%D0%B0%D0%BC%D0%B1%D0%BB%D0%B8_%D0%BD%D0%B5%D0%B9%D1%80%D0%BE%D0%BD%D0%BE%D0%B2_-_%D0%BF%D1%80%D0%BE%D0%B4%D0%BE%D0%BB%D0%B6%D0%B0%D1%8E_%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B82024-01-16: База мышления - ансамбли нейронов - продолжаю публиковать модель личностиMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-01-16T11:18:50Z2024-01-16T11:18:50Z<p>Вторая статья про инженерную модель личности <a rel="nofollow" class="external text" href="https://vc.ru/hr/988186"><b>База мышления - ансамбли нейронов</b></a> рассматривает базовый механизм мышления – возбуждение ансамблей нейронов, управляемую динамиками внимания. Следующая будет посвящена функциональной и структурной модели мозга, потом поговорим про обучение, механизмы эмоций, внутреннюю сцену и схемы самоопределения, и доберемся до разбора нейрофизиологических оснований моделей психологии.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Оглавление серии</b></a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0MqUtXQ4EC3aUPSFfVbUj1g32ywX5771pD9VRuNtt4W5Cc9acDzdXW4xfWTDV7iZhl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-01-13:_%D0%98%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_-_%D0%BD%D0%B0%D1%87%D0%B8%D0%BD%D0%B0%D1%8E_%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8E2024-01-13: Инженерная модель личности - начинаю публикациюMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-01-13T11:47:50Z2024-01-13T11:47:50Z<p>Больше полутора лет назад, в мае 2022 я опубликовал статью про <a href="https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2022-05-23:_%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8" title="Блог:Максима Цепкова/2022-05-23: Модель личности">Модель личности</a>, которая послужила основанием для развития <a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение">докладов и статей по самоопределению</a> и сама дорабатывалась в ходе этого. И в ноябре я сделал представил обновленную модель в <a href="https://mtsepkov.org/%D0%9C%D0%B5%D0%BD%D1%8F%D1%8F_%D1%81%D0%B5%D0%B1%D1%8F_%D0%B8_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_-_%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%B9_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE:_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(Teamlead-2023)" title="Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)">докладе на #TeamleadConf</a>. В планах было по результатам выступления обновить статью, но материал получается очень объемный, уже более 100к знаков, поэтому я решил публиковать его по готовности на vc.ru. Сегодня опубликована первая статья <b><a rel="nofollow" class="external text" href="https://vc.ru/hr/984751">Инженерная модель личности</a></b>, с общей структурой модели и методологией сборки. Вторая будет посвящена базовым механизмам мозга. Дальше мы поговорим про функциональную и структурную модель мозга, затем про механизмы эмоций, работу внутренней сцены и схемы самоопределения, и доберемся до разбора нейрофизиологических оснований моделей психологии. Надеюсь, это будет полезно.
</p>
<pre><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Оглавление серии</b></a>
<a rel="nofollow" class="external text" href="https://www.facebook.com/mtsepkov/posts/pfbid0VNyWs7Kt3QRJgukcNuzoySKX17JH63L8c2MvEnFUoDuD4Pe6rXvzAefuw5R5hXHAl">Пост на FB</a>
</pre>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2024-01-07:_DevrelConf_-_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_%D0%BE_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F%D1%852024-01-07: DevrelConf - конференция о конференцияхMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2024-01-07T10:16:10Z2024-01-07T10:35:11Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Последней конференцией уходящего года был <a rel="nofollow" class="external text" href="http://DevRelConf.ru">DevRelConf</a>, который прошел 9.12 на следующей неделе после Highload и Teamlead. Эта конференция рождалась как небольшой митап деврелов, активно работавших на этих (и других) конференциях для рефлексии и обмена опытом, но уже несколько лет она вышла за рамки небольшого митапа и активно развивается. Это - органическое развитие, и организаторы каждый раз удивляются масштабам, который конференция получает в очередном году. Хотя, казалось бы, это можно было прогнозировать просто по темпам развития деврел-активностей в компаниях.
</p><p>Эта конференция проходила на площадке Яндекса, и места для offline-участников закончились до того, как была вывешена программа. А на доклады было 43 заявки, из которых было отобрано 11, что для одного трека - очень много, тем более, что помимо выступлений была панельная дискуссия и фейл-час. Так что выступления были короткие, а конференция прошла динамично. Фокусом прошлой конференции были способы коммуникации с бизнесом о том, зачем вообще бизнесу нужен devrel и что он может. И, по-видимому, эта задача в целом решена (ну или прошлых докладов достаточно), и по пожеланиям участников, фокус был на практические доклады, рассказывающие о разнообразных инструментах devrel, включая не стандартный опыт, таком, как организация ИТ-катка. Такой фокус свидетельствует о том, что профессия прошла период становления и вступила в зону экстенсивного развития.
</p><p>А еще была панель с организаторами конференций, на котором они говорили о трендах развития. И это перекликалось с тем, что звучало в докладах: конференции из профессионального мероприятия превращаются в парк развлечений. Вернее, профессиональная составляющая сохраняется, по сильно увеличивается развлекательная часть на стендах с раздачей мерча, развлечениями и призами. Насколько это хорошо - вопрос открытый, но игнорировать это нельзя. Хотя, как участник многих конференций, могу сказать, что на конференциях онтико и у Орликова (AnalystDays и SQAdays) это проявляется по-разному. А на региональных - вообще иначе, это прозвучало на панели и видно из моего опыта. Но зависит это не только от организаторов, но и от аудитории, на Teamlead атмосфера и стенды отличаются от Highload, и стендов на Teamlead меньше. К сожалению, запись панели не опубликована.
</p><p>У меня не получилось побывать на всех докладах - я в шесть вечера уехал на самолет, улетел в отпуск. А на некоторых слотах сильно зацепило обсуждение в кулуарах. Так что отчет не полный. Но что есть - публикую. Как всегда, это телеграфный конспект с голоса, несколько причесанный.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Последней конференцией уходящего года был <a rel="nofollow" class="external text" href="http://DevRelConf.ru">DevRelConf</a>, который прошел 9.12 на следующей неделе после Highload и Teamlead. Эта конференция рождалась как небольшой митап деврелов, активно работавших на этих (и других) конференциях для рефлексии и обмена опытом, но уже несколько лет она вышла за рамки небольшого митапа и активно развивается. Это - органическое развитие, и организаторы каждый раз удивляются масштабам, который конференция получает в очередном году. Хотя, казалось бы, это можно было прогнозировать просто по темпам развития деврел-активностей в компаниях.
</p><p>Эта конференция проходила на площадке Яндекса, и места для offline-участников закончились до того, как была вывешена программа. А на доклады было 43 заявки, из которых было отобрано 11, что для одного трека - очень много, тем более, что помимо выступлений была панельная дискуссия и фейл-час. Так что выступления были короткие, а конференция прошла динамично. Фокусом прошлой конференции были способы коммуникации с бизнесом о том, зачем вообще бизнесу нужен devrel и что он может. И, по-видимому, эта задача в целом решена (ну или прошлых докладов достаточно), и по пожеланиям участников, фокус был на практические доклады, рассказывающие о разнообразных инструментах devrel, включая не стандартный опыт, таком, как организация ИТ-катка. Такой фокус свидетельствует о том, что профессия прошла период становления и вступила в зону экстенсивного развития.
</p><p>А еще была панель с организаторами конференций, на котором они говорили о трендах развития. И это перекликалось с тем, что звучало в докладах: конференции из профессионального мероприятия превращаются в парк развлечений. Вернее, профессиональная составляющая сохраняется, по сильно увеличивается развлекательная часть на стендах с раздачей мерча, развлечениями и призами. Насколько это хорошо - вопрос открытый, но игнорировать это нельзя. Хотя, как участник многих конференций, могу сказать, что на конференциях онтико и у Орликова (AnalystDays и SQAdays) это проявляется по-разному. А на региональных - вообще иначе, это прозвучало на панели и видно из моего опыта. Но зависит это не только от организаторов, но и от аудитории, на Teamlead атмосфера и стенды отличаются от Highload, и стендов на Teamlead меньше. К сожалению, запись панели не опубликована.
</p><p>У меня не получилось побывать на всех докладах - я в шесть вечера уехал на самолет, улетел в отпуск. А на некоторых слотах сильно зацепило обсуждение в кулуарах. Так что отчет не полный. Но что есть - публикую. Как всегда, это телеграфный конспект с голоса, несколько причесанный.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D1.82.D0.BE.D0.BD_.D0.A7.D0.B5.D1.80.D0.BD.D0.BE.D1.83.D1.81.D0.BE.D0.B2_.D0.B8.D0.B7_Yandex_Cloud._.D0.94.D0.B0.D0.B2.D0.B0.D0.B9_.D0.B7.D0.B0.D0.BF.D1.83.D1.81.D1.82.D0.B8.D0.BC_.D0.BF.D0.BE.D0.B4.D0.BA.D0.B0.D1.81.D1.82..._.D0.B8.D0.BB.D0.B8_.D0.BD.D0.B5.D1.82">Антон Черноусов из Yandex Cloud. Давай запустим подкаст... или нет</span></h1>
<p>Антон записывает подкасты очень давно, с 2008. В этом году у него примерно 600 часов из 1900 - на подкасты. Публичный подкаст "The Art of Programming", корпоративный подкаст "Безопасно говоря" про безопасность и другие.
</p><p>Корпоративный подкаст - это не то, что индивидуальный или публичный, и дальше речь пойдет про корпоративные: нужен ли он компании, для каких целей и как его организовать.
</p><p>Вообще подкаты появились в 2004: Danny Gregorie пишет письмо и изобретает механизм подкастов - доставка контента по подписке. И Adam Curry - подхватил и запустил. В 2005 Tunes 4.9 - и все обычные узнали, что есть подкаст, индустрия стартанула.
</p><p>Отличие подкаста от других типов передач: тематическое ограничение на контент, серийная передача и фокус на доступе по подписке. Естественно, случайные слушатели тоже приветствуются, но задачей является превращение их в постоянных, которым настолько интересен контент, что они согласны за это платить.
</p><p>Сейчас на VK-музыка 20к проектов, Яндекс-музыка - 25к подкастов, емкость около 30к. Подкасты хостятся на музыкальных площадках, потому что они умеют эффективно доставлять звук, но содержание у них - не музыка. Выделить среди подкастов корпоративные не получается - они шифруются, проводят партизанский маркетинг. Но их много.
</p><p>Проблема корпоративного подкаста - не столько деньги, сколько загрузка специалистов. Деньги под идею получить обычно можно, так как на первой фазе их надо не так много. Разовое участие как гость - несложно для специалиста и кажется, что его достаточно просто организовать. Тем не менее, это от 1 до 6 часов рабочего времени, а у загруженного специалиста его надо специально выделять, это не пауза между другими задачами. При этом астрономический срок подготовки и выхода подкаста имеет очень большой разброс: от 1 недели до 6 месяцев, это сильно зависит от организации процессов. Его время на подготовку - примерно такое же. И если для специалиста это - разовое участие, то для деврела получается значительная активность, так как нужен регулярный выпуск.
</p><p>Достаточно типична ситуация, когда есть желающие выступить в подкасте, а деврел не уверен, что это нужно. И тогда есть вариант отправить такого желающего в к тем, кто уже ведет подкасты, чтобы человек попробовал. Это - не так сложно, может быть достаточно 1 часа: бриф на 30 минут о чем говорить, плюс 30 минут для общение с подкастерами, у которых будет запись. Но так можно только с лояльными подкастами, которым нравится бренд компании. Может быть дольше, если надо пообщаться с пиаром и провести разные активности, тут у него статистический пик в 3 часа. Запись подкаста может быть бесплатной или стоить денег, диапазон от 0 до 50к. Это - не считая промоушена конкретного подкаста, он отдельно.
</p><p>В чем смысл участия гостем? Это реальный опыт для человека, после которого он может перестать хотеть быть подкастером и перестанет терроризировать деврела. Если интерес сохраняется - то гостем можно отправить несколько раз, и в принципе человек может втянуться, быть гостем разных подкастов и разговаривать на разные темы. В презентации была ссылка на podcast guide, как это делать.
</p><p>Типичная ошибка, которую не надо совершать - это не доверять людям, подслушивать, попросить прислать запись и поправить. Это злит любого подкастера и лояльность бренду упадет.
</p><p>А остальное - техника: свое помещение, оборудование, специалисты и софт; финансы: аренда, продакшн, промоушн. У подкастеров, к которым отправляешь в гости это есть. А вот если человек не остыл и хочет делать собственный подкаст, и убедил в этом руководство. то деврелу надо будет это организовывать. Помещение, оборудование, специалисты и софт стоит 40-80к, но это - на серию, а не на один выпуск.
</p><p>И я тут из своего опыта хочу отметить, что техника и помещение - не главное, запускаться можно без этого. Я около года участвовал в проекте запуска TMFM - это гибрид свободного интернет-радио и подписки, дающей доступ к выпускам по выбору. Начальный этап там был в формате выпусков-монологов от отдельных ведущих, когда их набралось достаточно, то запустили непрерывную ротацию. И поскольку это была проверка бизнес-гипотезы, то у одних это был просто смартфон, а у других - более профессиональные варианты. И с самого начала была запущена аналитика по тому, дослушивают ли выпуск, или переключаются, это давало хорошее сравнение. Так вот, выяснилось, что никакой корреляции между качеством записи и интересом слушателей - нет, контент - главное. Да, нужен гигиенический уровень. но он достигается на смартфоне. Только надо записывать в тихой комнате, закрыв окна и двери, когда за стеной нет громких звуков, типа перфоратора. Еще нужно, чтобы стул не скрипел, и вообще сидеть на нем аккуратно, а смартфон лучше расположить вверх ногами микрофоном к горлу и записывать на него, и это - лучше чем большинство гарнитур, преимущество дает только дорогой профессиональный микрофон, и оно не принципиально. Пост-обработка записи профессионалами - полезна, но организаторы далеко не сразу нашли профи, которые умеют работать с такими записями: большинство говорили, что "ничего нельзя сделать", пришлось провести конкурс - и тогда профи нашлись. То есть такое умение - отдельная компетенция у работающих со звуком, и она редкая. Зато такой запуск дает возможность начать удаленно и на своем оборудовании, и для проверки гипотезы это очень ценно.
</p><p>Кстати, еще поделюсь уроками: есть мнение, что хороший выпуск должен быть коротким, 5-7 минут, потому что слушают в машине или в паузах, и там - малые временные слоты. Это с самого начала было рекомендацией, но не обязательным требованием. И выяснилось, что при хорошем контенте до конца дослушивают и длинные выпуски по 20-30 минут. Казалось бы, короткий выпуск сделать легче, но лично у меня с этим часто были проблемы, так как я хотел донести комплекс связанных идей, которые надо было еще проиллюстрировать примерами, и в 7 минут это не помещалось. Теперь от своего опыта возвращаюсь к докладу.
</p><p>Главное - организация.
</p>
<ul><li> Запись подкаста - полноценная работа, которая требует соответствующего отношения. В свободное время - не делается.</li>
<li> Надо отобрать ведущих, чтобы умели говорить, чтобы не бесил голос. А если подкаст с видео - то еще внешний вид и манера держаться, надо тренировать, проводить тестовые записи. Можно позвать опытного подкастера, особенно на начальном этапе. И надо учитывать, что люди болеют и увольняются, поэтому нужно несколько ведущих. Но это - техника, с которой не надо спешить, смотри следующие пункты.</li>
<li> Начало проекта - придумать 10 тем, их надо попросить придумать того, кто хочет делать подкаст, это же будут темы его выпусков. Тут есть разные подходы, но обычно тема - это название, подводка 4-5 предложений, и тезисы для разговора, которые разворачиваем. На этом этапе пропадает примерно половина желающих вести подкаст.</li>
<li> Когда есть темы: понять, кто твой слушатель и выбрать жанр. Жанров 20+, это вне доклада. Самый простой - запись интервью, 10 вопросов и погнали. Затем посоветоваться с дизайном, потом придумать название. Именно в таком порядке</li>
<li> Дальше надо заново придумать 10 тем: фокус-группа слушателей, жанр и название влияют на темы.</li>
<li> Написать сценарий на 3 ближайших выпуска. На этом этапе еще 2/3 отсеиваются.</li></ul>
<p>Учитывая процент отсева, начинать надо не с техники и ведущих, а с проработки контента. Но если с темами получится, то надо быть готовым технику обеспечить, иначе человек инициатор будет думать, что ты и не собирался ничего делать, а задачи по темам ставил в надежде, что он передумает.
</p><p>Вопрос: как проверить гипотезу о состоятельности подкаста? Есть тематика, гипотеза об аудитории. Способы проверки: опрос, тизер - из проектной деятельности. Подкаст - продукт, значит custdev
</p><p>Была история. 5 стартовых записей, тестовый период 6 месяцев, 42 эксперимента, каждый - перемонтаж, сделали 13 записей от 2 до 20 минут, более 200 рабочих часов + 300к. 3 раза меняли стиль и повысили конверсию +25%, добавили персонажа "старик" - еще +10%, еще "девушка" +12%, а когда поставили девушку в социальную роль - +58%. А потом поняли, что на тех цифрах которые они имеют - делать подкаст не надо. Закрыли и списали.
</p><p>На Яндекс-музыке сложно померить подписку - потому что там нет статистики. и промоушн забывает.
</p><p>Аудитория подкаста - не прослушивание, а органический рост подписанной базы. Можно в телеграм-канал собирать, а дальше оттуда черпать. Но это уже не про запуск.
</p><p>Ошибки.
</p>
<ul><li> Ключевая - не советоваться с пиаром гостей. Это убивает карьеру, потеря работы</li>
<li> Упустить работу с комментариями в соцсетях. Все может быть понято неправильно, вести к негативу. Надо следить и реагирвовать.</li></ul>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B5.D0.B9_.D0.9C.D0.B0.D1.80.D0.B0.D1.85.D0.B8.D0.BD_.D0.B8.D0.B7_Phystech.Genesis._.D0.9A.D0.BE.D0.B3.D0.B4.D0.B0_.D0.BD.D0.B5_.D1.81.D1.82.D0.BE.D0.B8.D1.82_.D0.BF.D1.80.D0.BE.D0.B2.D0.BE.D0.B4.D0.B8.D1.82.D1.8C_.D1.85.D0.B0.D0.BA.D0.B0.D1.82.D0.BE.D0.BD.D1.8B.3F">Алексей Марахин из Phystech.Genesis. Когда не стоит проводить хакатоны?</span></h1>
<p>Алексей провел 120+ хакатонов в 17 странах, 25к участников, 100+ партнеров, и доклад - обобщение опыта. При этом фокус - не на технике организации хакатона, а на целях, которые можно достичь.
</p><p>Итак, какие задачи <b>НЕ</b> решает хакатон.
</p>
<ul><li> Хочу нанять 100500 сеньоров за два дня</li>
<li> Хотим пофиксить все баги в нашем продукте</li>
<li> У нас в бэклоге заплесневело пара задач, отдадим студентам. В принципе, так можно, но студенты не будут благодарны</li>
<li> Участники сделают 100 фич, готовых в прод</li></ul>
<p>Какие задачи решает хакатон
</p>
<ul><li> Повысить awareness бренда среди junior-to-middle. Хакатон на 200 человек дает охват 200к.</li>
<li> Расширить воронку найм в junior-to-middle. Хакатон на 200 человек - 600 целевых анкет, не все придут - но с этим можно работать.</li>
<li> У бизнеса есть запрос на генерацию идей, нужно хотим получить отклик от ИТ-сообщества. Идеи будут.</li>
<li> Мы понимаем, что качественный код - больше 2 дней, нужны люди и идеи, перспективные мы потом доведем до прода сами. </li>
<li> Если ваш продукт ориентирован на разработчиков. то с помощью хакатона его можно продвинуть, вынести в массы, а также проверить гипотезы.</li></ul>
<p>При этом важно поставить понятный KPI - измерение цели, например:
</p>
<ul><li> Virus hach, для awareness: хотим 1000 участников, 6к регистраций, более 1м пользователей, nps 8 из 10.</li>
<li> Sber Cloud - привлечь малый и средний бизнеса (на слайде неверно): цель была 70 команд МСБ, 50 решений.</li></ul>
<p>KPI меряем не только постфактум, а в процессе подготовки, и он влияет на способ работы.
</p><p>Барьеры проведения хакатона
</p>
<ol><li> Нет понимания развития стратегии бренда в целом. Хакатон встраивается в воронку, его результат должен куда-то пойти и нанести пользу. Если результат зависает в воздухе - он бесполезен.
<ul><li> Даже если сейчас стратегии нет, есть идеи - то все равно делаем cjm, jobs to be done</li>
<li> Начать с базы - хабр, сообщества, митапы</li>
<li> Настроить обработку лидов рекрутментом</li>
<li> Сходить к бизнесу, поговорить об использовании результатов.</li>
<li> Есть гайд, в презентации - ссылка: как встроить хакатон в воронку. </li>
<li> И пример.
<ul><li> Задача из 3 основных тем, которые уже анонсированы на хабре</li>
<li> На продвижении - статьи рекомендовали, люди пришли подготовленные.</li>
<li> Получили крутые решения</li>
<li> Подняли трафик на хабр</li></ul></li></ul></li>
<li> Нет задач на хакатон. Идти надо к бизнесу, он мыслит широко, у него есть гипотезы. Только потом - в разработку. Тоже есть гайд. Кейс ВТБ: узнали у бизнеса mobile+web и metaverse, провели исследование на фокус-группах - что малая задача, реализуемо </li>
<li> Если нет задач и экспертов. Можно партнерится, McKinsey партнерился со сбермаркетам, одним - решения, другим awareness</li>
<li> Нет денег. Калькулятор стоимости хакатона. Можно партнерится с командами, можно идти в ВУЗы - там не профи, но дешево.</li>
<li> Нет фокуса на кайф у участников. Тогда делать точно не стоит.</li></ol>
<p>На слайде диаграмка: команда, бюджет, kpi. Если одного нет - можно устранить недостаток, в презе было как именно, а рассказать не успел.
</p><p>И в заключении призыв: проводите с любовью к аудитории!
</p>
<h1><span class="mw-headline" id=".D0.95.D0.B2.D0.B3.D0.B5.D0.BD.D0.B8.D1.8F_.D0.A4.D0.B8.D0.BD.D0.BA.D0.B5.D0.BB.D1.8C.D1.88.D1.82.D0.B5.D0.B9.D0.BD_VK._.D0.9F.D0.BE.D0.B9.D0.BC.D0.B0.D0.B9_.D0.BC.D0.B5.D0.BD.D1.8F.2C_.D0.B5.D1.81.D0.BB.D0.B8_.D1.81.D0.BC.D0.BE.D0.B6.D0.B5.D1.88.D1.8C.2C_.D0.B8.D0.BB.D0.B8_.D0.A0.D0.B0.D0.B1.D0.BE.D1.82.D0.B0_.D1.81.D0.BE_.D1.81.D0.BF.D0.B8.D0.BA.D0.B5.D1.80.D0.B0.D0.BC.D0.B8">Евгения Финкельштейн VK. Поймай меня, если сможешь, или Работа со спикерами</span></h1>
<p>По опросу, поиск докладчиков - самое сложное в работе деврелов. Она готовила 100+ выступлений, и они попадают в топовые выступления конференций.
</p><p>Выступление эксперта - дешевый способ продвижения тех.бренда. Классный спикер - лицо компании. Но если спикер несет спорную чушь - это тоже от лица компании. Кто-то на митапе сказал, что язык А предпочитает Б, а СМИ напишет "разработчик вконтакте заявил..."
</p><p>Нужен управляемый процесс. Не просто звать всех "выступайте".
</p><p>По шагам:
</p>
<ul><li> Найти и заманить</li>
<li> Помочь подготовиться</li>
<li> Помочь во время и после</li>
<li> Мотивация</li></ul>
<p>Эти этапы - признаются важными по опросу.
</p><p>Выступать нельзя заставить, вернее, один раз - можно, но результат - сомнителен, а повторения не будет.
</p><p>Главное - убрать препятствия и барьеры.
</p>
<dl><dd> Первый барьер для новичков - непонятно что делать, вообще. Разница между ни разу не выступал и один раз выступил. И там - faq в компании, куда пойти, что сделать - и надо в открытом доступе, как только сотрудник подумает пойти. Дальше поэтапный план со сроками. предупреждение о нагрузке, точки помощи, например, слайды.</dd>
<dd> Барьер-2. Зачем выступать - самому спикеру объяснить понятным ему языком. Прокачка своих скиллов - развитие команды - Экспертность-Известность-Новые крутые коллеги - больше крутых проектов.</dd>
<dd> Барьер-3. Это никому не интересно - надо пиарить спикеров, показывать, что это интересно. Поддержка топами - чтобы не было "пожалуйста без отрыва от процессов", "конференции - фигня" - это сложная ситуация, с ней надо отдельно работать. И чтобы не только понимали пользу, но и транслирвоали ее. И подавали пример. </dd>
<dd> Барьер-4. Много других важных дел. Решение - быть пушнилой. Лишнее напоминание никогда не лишнее (хотя имеются противопоказания). Опрос коллег показывает, что им полезно. Надо на берегу договариваться "когда спросить", "когда напомнить". Сказать "передумал, нет времени" - ОК, а вот забыв пропустить - нет. Убеждаемся, что не потеряно.</dd></dl>
<p>Помощь в подготовке.
</p>
<ul><li> Тема. Про темы - у Ромы Поборчего был доклад и еще несколько - Макс Шевченко, Гриша Петров. Это не такая проблема, у людей есть наметки. Надо не вытащить, а докрутить коучинговыи вопросами.</li>
<li> Содержание: цель выступления - зачем я это сделал; целевая аудитория - что ты делаешь; польза аудитории</li>
<li> Заявка: название - баланс конкретики и кликбейта; тезисы для публикации; общие вопросы (био, аудитория, рыба о компании) - тут нужна инструкция; тезисы для ПК со спойлерами и планом - все равно это рассказывать придется, и лучше написать, чтобы поняли.</li>
<li> Отследить, что отклик пришел.</li></ul>
<p>Когда приняли - готовим доклад и презентацию. Был алгоритм подготовки, сначала делаем структуру. Шаблон презентации экономит время. Помощь дизайнера полезна, то он должен быть с опытом в презентациях.
</p><p>Опасный источник неудачи - несоответствие доклада и аудитории
</p><p>Репетиции с ПК и внутри - нужно, но надо не переборщить. И тут разные задачи: у ПК задача сделать конфу в целом приемлемой, а у компании - сделать топ-доклад. это разные задачи. Но можно делать общий прогон или вести запись, по которой давать обратную связь.
</p><p>При подготовке надо быть пушнилой, но не мешать. Секрет успешного успеха: надо готовиться к конференции. Подготовка рулит.
</p><p>День Х. Помочь ориентироваться на конфе, особенно в Сколково - там запутанная площадка. Состояние в моменте сильно влияет на выступление. Так что стоит быть поблизости, чтобы поддержать, если что случилось: вы лучше умеете решать вопросы. И послушать - они видят вас в зале, это успокаивает.
</p><p>Выступление - большой проект. Его надо закончить праздником. Впечатления и фидбэк, подсветить хорошее, например, вопросы.
</p><p>И колесо закручивается: попробую выступить - это нестрашно - хорошо получилось - результаты на всю компанию - куда записываться на следующее выступление.
</p><p>Мотивация. У всех - разная мотивация к работе. Выступают не ради подарков, хотя толстовка - важно и приятно. Мотивацию надо понимать и поддерживать.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B0.D1.81.D1.82.D0.B0.D1.81.D0.B8.D1.8F_.D0.9D.D0.B5.D1.82.D0.BA.D0.B0.D1.87.D0.B5.D0.B2.D0.B0_.D0.B8.D0.B7_VK._.D0.9A.D0.B0.D0.BA.D1.83.D1.8E_.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D1.83_.D0.BC.D0.BE.D0.B6.D0.B5.D1.82_.D0.BF.D1.80.D0.B8.D0.BD.D0.BE.D1.81.D0.B8.D1.82.D1.8C_.D1.81.D1.82.D0.B5.D0.BD.D0.B4_.D0.BD.D0.B0_.D0.BA.D0.BE.D0.BD.D1.84.D0.B5.D1.80.D0.B5.D0.BD.D1.86.D0.B8.D0.B8.2C_.D0.B8.D0.BB.D0.B8_.D0.9A.D0.B0.D0.BA_.D1.81.D1.8A.D0.B5.D1.81.D1.82.D1.8C_.D1.80.D1.8B.D0.B1.D0.BA.D1.83_.D0.B8_.D0.B4.D0.B0.D0.BB.D0.B5.D0.B5_.D0.BF.D0.BE_.D1.81.D0.BF.D0.B8.D1.81.D0.BA.D1.83">Анастасия Неткачева из VK. Какую пользу может приносить стенд на конференции, или Как съесть рыбку и далее по списку</span></h1>
<p>Она делала стенды компаний, в которых 200-1000-10к сотрудников, это разный масштаб. Сейчас деврел в VK, 20 интеграций от 4 до 150 м и стенды в топ-3. Она лид деврел vk, у нее своя команда, и команды деврелов продуктов.
</p><p>Сейчас стенды - гигиена для деврел, на highload 59 стендов, будет больше. И разработчики приходят не послушать и посмотреть что происходит в индустрии, а за мерчом. И хотят не проходить задания. а получить бесплатно, чтобы было быстро. Идет эволюция: из профи-конференции в ярмарку тщеславия. Этот тренд не радует, но объективно он есть, и надо учитывать.
</p><p>Стенд: задача - команда - идеи - реализации.
</p><p>С задачей два сценария: или про стенд решило руководство, или решили сами.
</p><p>Если решило руководство - бизнес, cto, cpo, hr, то вопрос: какая конкретная задача? Далеко не всегда ответ будет.
</p>
<ul><li> Что не должно быть задачами: все ходят, мы каждый год ходим, бюджет есть - что не сходить. </li>
<li> Могут быть: наем, релиз, ребрендинг, продажи. </li>
<li> Задачу стоит проверить контраргументами: стоит ли это делать с помощью стенда? Например, масштаб найма - может лучше дай-офер? Продажи - есть ли ЦА на конфе? Показать релиз - а это круто для аудитории, повысит статус компании? </li></ul>
<p>Если решаем сами, то путь не отличается, вопросы - те же, но самому себе.
</p><p>Два уровня KPI.
</p>
<ul><li> Бизнес: продажи, оферы, рейтинги, деньги. </li>
<li> У стенда: проходимость, контакты, кол-во людей прошедших опрос; бренд-трекинг в динамике. Не более! </li></ul>
<p>Не закапывайте себя - не формируйте неправильные ожидания у бизнеса.
</p><p>Если в компании продуктов и команд много и они разные, то вопросы по командам, где болит и есть задачи, с ними и идете на стенд. Стенд может решать разные задачи - как витрина.
</p><p>Команда.
</p>
<ul><li> Нельзя делать стенд без разработчиков. Хотя это игнорируют. Разработчики - целевая аудитория, надо для них сделать прикольное, а для этого получать в подготовке обратную связь.</li>
<li> Где взять разработчиков и почему пойдут? Сообщество, искать у кого мотивация</li>
<li> Каждый должен делать свою работу: кто умеет писать - пишет тексты, кто умеет дизайн - дизайнит и т.п.</li>
<li> Идеальный пример: проджект (чатик, встречи), профильные разработчики - штурм и проверка идей, стендисты, копирайтер, маркетинг, дизайнер, СММ менеджер,...</li>
<li> Реальность: проджект - вы. стендисты = разработчики. копирайтер, маркетинг и cvv - один, который хорошо пишет. Дизайнеры, менеджеры по застройке, агентство - надо, делегировать,</li></ul>
<p>Идеи. За эксперименты, на штурме - все идеи. Оля Бузова, замок и песка, воздушные акробаты, 10 путевок, котик на стенде. Записываем. А потом - матчим с задачами от бизнеса, ценности EVP, технологии, лиды - хотя бы собираем. Котик на стенде может помочь рассказать про Basic (барсик) - не реализовано, но можно. Но это уже фильтр после генерации.
</p><p>Стенд:
</p>
<ul><li> часто так: визуал 30% механика 30% мерч 30% люди 10%</li>
<li> нужно по-другому: визуал 10% (был пример банер+2 стены) механика 30% мерч 10% люди 50% Потому как главное - чтобы люди привлекали и общались.</li>
<li> Механика - это не только игра, может быть зона экспертов.</li></ul>
<ul><li> Визуал: в ТЗ - эргономично, доступно, для вас</li>
<li> Механика: работает на ваши задачи, не развлечение. Рожденное внутри - лучшая. Никто лучше вас не знает про вас. Не отдавайте креатив внешним агентствам или интегрируйте правильных людей в процесс выбора и выбора решений. Баланс между интеллектуальным и развлекательным, разные активации на разный вкус. Если цель - объединить - то подумайте про геймификацию на цель.</li>
<li> Мерч - игра вдолгую, он должен ассоциироваться с вами, носки-ск связка. Дорого не значит классно, классный мелкий мерч, брелоки - борются. Не обесценивайте - не раздавайте просто так. </li></ul>
<p>Люди: промоперсонал на техконфе - зло, они могут наливать сок, но не должны презентовать компанию, они портят облик. Скучающие разработчики на бинбегах - зло, с этим надо работать, в том числе отпускать погулять, с вызовом сообщением. Соблюдайте баланс тех, кто умеет говорить и умеет ответить на вопрос.
</p><p>Охота за контактами. Не прячьте слона, все знают. Не добывайте обманным путем, играйте честно и давайте выбор.
</p><p>В конце чек-лист: зачем; сохраняем лицо мы это мы; не переусердствуйте с креативом; правильные люди; механики как инструмент; не мерч - главное; контакты - честно.
</p><p>Чудес не бывает. Классный стенд не приведет толпу кандидатов и не обогатит. Но поможет собрать контакты и презентовать компанию, и получить обратную связь на эту презу.
</p><p>И в заключении. <b>На нашем рынке предложение должно формировать спрос, а не наоборот</b>. Потому что по обратной связи от разработчиков надо просто раздавать мерч и не напрягать. Но это не решает ваши задачи. Впрочем, я отмечу, что по обратной связи от ИТ-катка, люди хотят контента, докладов. Так что тут вопрос баланса.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.BD.D0.B0_.D0.9A.D1.83.D1.80.D0.BD.D0.BE.D1.81.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_.D0.AF.D0.BD.D0.B4.D0.B5.D0.BA.D1.81._.D0.A1.D1.82.D0.B5.D0.BD.D0.B4.2C_.D0.BA.D0.BE.D1.82.D0.BE.D1.80.D1.8B.D0.B9_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B8.D0.BB_.D0.B8.D0.BD.D0.B6.D0.B5.D0.BD.D0.B5.D1.80">Анна Курносова из Яндекс. Стенд, который построил инженер</span></h1>
<p>Продолжение темы стенда. Чек-лист стенда и интеграции в конференцию. Он сделан по тем же пунктам, и в чем-то повторяет, а в чем-то отличается, по-другому ставит акценты. И я хочу отметить, что в презентации - очень много материалов. которые проговаривали пунктиром.
</p>
<pre>Сбор рабочей группы. Кто стоит, предлагает идеи, верифицирует контент.
</pre>
<ul><li> Откуда: через руководителей, через коллег-деврелов (если они есть), просто зайти в инженеров</li>
<li> Договариваемся на берегу - куда идем, чем будет заниматься. Есть у кого замылен глаз. Но если хотим нестандартного или не повторяться - то надо работать с новичками и солому подкладывать</li>
<li> Обсудить желание самого инженера, каждого. Даже когда получили через руководителей</li>
<li> Границы: работы в группе, неудобные вопросы. Почему не уволился, чем ваши проекты классные и отличаются. Их себе задаешь не часто.</li>
<li> Много этапов, жесткий тайминг, движение по самому медленном - поддерживаем</li>
<li> Нет быстрого эффекта. Нельзя сделать одну конфу и получить очередь на вакансию. Инженеры в группе могут ждать - формируем ожидания. Метрики, с которым входим, показываем воронку, обратную связь.</li>
<li> Найма не будет. Если говоришь - половина людей уходит и это ОК.</li></ul>
<p>Первый слайд на каждой встрече.
</p>
<ul><li> работа со стендом - часть работы, руководитель должен быть в курсе</li>
<li> встреча - дорогая, много людей собрать. Высказываем мнение не молчим, уважаем</li>
<li> Тайминг</li>
<li> Встреча с камерами! Мимика рулит</li>
<li> Не прогуливаем встречи, делаем домашки - рефлексия</li></ul>
<p>Посылы - что говорим о себе.
</p>
<ul><li> Переоизобретаем посылы</li>
<li> не используем готовые evp (ценности, принципы, манифест).
<ul><li> есть вероятность, что готовые посылы не проверялись на инженерах, они про продукты</li>
<li> есть вероятность, что они устарели</li>
<li> инженеры могут прочитать и запомнить, но вряд ли пойдут проверять. Мы прочли "компания двигает индустрию в будущее", мы прочли, воспроизвели, а тут человек спрашивает "как интересно, давайте подробнее" - и он зависает. Тогда впечатление портится. Надо самим верить, а для этого переизобретать.</li></ul></li>
<li> У нее есть механика - есть на слайдах. не рассказана. 6 вопросов. Но вопросы должны меняться, в зависимости от цели и компании: рассказать что вы есть, или донести, что сейчас выводим вау-проект и так далее. Она сама тоже ответила. </li></ul>
<p>Задали вопрос инженеру "почему пришли в компанию". Его задают на стенде. И если у них стандартные ответы, которые не вдохновляют, с этим надо работать.
</p>
<ul><li> Уникальность - меняем название компании - если тезис остается справедливым - не интересно. </li>
<li> Гигиена - про зарплату, печеньки есть у всех, это не может быть решающим фактором. Проверка - через отрицание.</li>
<li> Оценочные суждения надо подкреплять. Потому что у всех много данных и крутые проекты, нужны доказательства, цифры про ваши.</li></ul>
<p>Просеяла, получила текстик - и получилась внятная история, которую можно вынести наружу.
</p><p>И инженеры сами проходят этот путь - могут доказать. И себя проверять - она много раз делала, и все равно фильтр.
</p><p>Рассказываем про сито - и они сами себя челленджат в группе. Перечитываем что получилось. Когда инженеры рассказывают техническое - они себя челленджат. Пишут на Котлине, на фреймворке - а кто-то из соседней говорят "это устарело". И еще отсекается соблазн обобщать на компанию.
</p><p>Проверяем то, что получилось с официальной позицией компании, evp (employee value proposition) и rtb (reasons to believe). Разбираемся, если не совпало.
</p><p>Как с деньгами и метриками?
</p>
<ul><li> Нет ничего - чат-бот, люди проходят квизы за мерч, что-то запоминают.</li>
<li> Конфа - партнерская. Когда человек пришел на вашу - он ваш. А на общей конфе - много стендов конкурируют за внимание.</li>
<li> Откуда новое - от инженеров. Деврел знает как работает конфа. Инженеры знают продукт - дайте площадку.</li>
<li> Наборсы: (а) проведите через cjm продукта участника конференции. Идея для яндекс-директ сделать таргет так, чтобы при запросе с конфы вылезали банеры с задачами, и ответ можно было вбить в поиск. (б) специфика конфы - головоломки, квизы, (в) сценарии агентства - необитаемый остров и т.п. </li>
<li> Тестируем творчество - на стендистах, они лояльны. Тренировка стояния на конфе - одни стендисты отвечают, другие играют роль посетителей. Не только сам стендист тренируется, то и коллеги знают, кто в чем силен и где нужна поддержка. </li></ul>
<ul><li> День Х. Последняя регулярка, когда напутствие. Самое начало, деврел - не свободен: у него фокус поддержки людей на стенде. Форс-мажор со стендистами - подстраховка и т.п.</li></ul>
<p>А зачем это все? Инженеры 2 месяца заняты непонятно чем? Деврел может сам все сделать? Может быть. Это вопрос веры, она сомневается в своем подходе. Но последние годы - стенды удачные, все больше подходят с вопросом "кто делал", а они отвечают "мы сами".
</p><p>Благо от процесса - как в выступлении. Глубже разбираешься в продукте, свой и соседний. И можно рассказать на коммюнити. И опытные стендисты.
</p>
<h1><span class="mw-headline" id=".D0.9F.D0.B0.D0.BD.D0.B5.D0.BB.D1.8C_-_.D0.B2.D0.B7.D0.B3.D0.BB.D1.8F.D0.B4_.D0.BD.D0.B0_.D0.B4.D0.B5.D0.B2.D1.80.D0.B5.D0.BB.D0.BE.D0.B2_.D0.BE.D1.82_.D0.BE.D1.80.D0.B3.D0.B0.D0.BD.D0.B8.D0.B7.D0.B0.D1.82.D0.BE.D1.80.D0.BE.D0.B2_.D0.BA.D0.BE.D0.BD.D1.84.D0.B5.D1.80.D0.B5.D0.BD.D1.86.D0.B8.D0.B8">Панель - взгляд на деврелов от организаторов конференции</span></h1>
<p>Участвовали Олег Бунин из онтико, Дмитриев из jug.ru и Григорий Коган из Ижевска, там региональные конференции. Записи панели нет.
</p><p>Дальше тезисы, не все с указанием авторства.
</p>
<ul><li> Бунин. Несколько лет назад пришли на конференцию банки, решившие что нужна экосистема. И был скачек активности на стендах: мерч, призы и так далее. Сейчас будет следующий скачок - добавится реальный сектор.
<ul><li> На этом Highload было 59 стендов, на следующем будет 80, если в Сколково, а если в Крокус - то неограниченно.</li>
<li> Есть гигантские стенды, а есть - небольшие, и они тоже работают.</li>
<li> Но зеленые и желтые компании - хотят свои конференции, так что могут быть разные сценарии.</li></ul></li>
<li> Коган из Ижевска. Есть несколько групп партнеров. Федеральные работают по методичкам из центра. Гонка вооружений, механики одинаковые и мерч тоже. Местные ИТ - пытаются им подражать. А местные не-ИТ часто имеют старые представления, что достаточно выступить со скучными циферками, и организаторы пытаются как-то поменять это представление, вытащить их в современность.</li>
<li> Бунин. Луна-парк, развлечения - важная часть мероприятие. Приходят на контент, но главное - общение и луна-парк - место общения. И плюшевые игрушки не помогут - они есть у всех, тут победители по бюджету. Надо конкурировать с умом, доклады - важно. </li>
<li> Ижевск - три мероприятие, одно - их и еще два. Студенты - приходят собирать мерч только.</li>
<li> Бунин. Краеугольный камень evp. Почему разработчику надо придти в вам. И дальше - его тащите через конференции и митапы. Инструменты набросаем, но как отобрать, если нет цели?</li>
<li> Суть HR-бренда - это когда человек задумался о новой работе - и вспомнил вашу компанию. А что в HR-бренде кроме найма.</li>
<li> Что вспомнит разработчик про компанию, покидав плюшевые кастрюли в дырку? С мест были реплики, что там хитрая механика: чтобы покидать - очередь, и с теми, кто стоит в очереди стендисты работают, рассказывают. </li>
<li> На конференции нужна инфраструктура для всех, и для стендистов тоже, потому что они на стенде с 8 до 20.</li>
<li> Ижевск.
<ul><li> Интересная интеграция - ПМ-бар, потому что, оказывается, у многих была работа в баре.</li>
<li> Непейвода - постоянный участник, и там разные штуки. И идея трека - рассказать интересненькое, в том числе для партнеров.</li>
<li> Малые мероприятия, растут до конференции, решающей социальные задачи.</li>
<li> Технлогическая конфа, играли слоган - самая умная вечеринка. От слогана компании "умная компания".</li>
<li> Интеграция - параллельно с афтерпати квиз или что-то еще.</li></ul></li>
<li> Реплика от Бунина: evp самая умная компания - сейчас не катит, в 2015 было можно, а сейчас все считают умными.</li>
<li> Дмитриев.
<ul><li> Одна компания проводила конфу, спонсор интегрировался, а стендистов не набрал.</li>
<li> Кейс. Подается заявка через call for paper. Не обязательно сам докладчик, подают за него. Приходит на созвон с ПК дверел, до конфы недели 3, показывает 4 слайда. ПК просит спикера, а тот возмущается: что вы меня зовете? Прилично таких случаев, когда приводит дверел и защищает спикера, и тогда перегибают палку.</li></ul></li>
<li> Партнерские доклады. Пришли в ПК с требованием взять доклад. И потом пошли жаловаться организаторам "вы можете сказать ПК, чтоб тот знал". </li>
<li> А еще - три одинаковых стенда с одинаковой механикой и мерчом. </li>
<li> Мир раздавал книги, как устроена у них разработка - и было круто и интересно.</li>
<li> Ижевск. Лунапарк и развлекухи - пойдут сеньоры или мидлы? Сеньор: все как обычно - лучше почитаю хабр. Нужен контент.</li>
<li> Бунин. Сеньоры любят носки. Но давайте играть по-серьезному. Время плюшевых игрушек и сахарной ваты закончилось. Их разбирают, но что это говорит о компании... У них - 180 видов интеграций. Но чтобы предложить - нужно evp</li>
<li> Запрос. На больших конференциях где 2-4 тысячи участников - сложно знакомиться. Нужны механики. </li></ul>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B8.D0.BD.D0.B0_.D0.9A.D0.B0.D1.88.D0.B8.D1.80.D1.81.D0.BA.D0.B0.D1.8F_.D0.B8.D0.B7_.D0.A2.D0.B8.D0.BD.D1.8C.D0.BA.D0.BE.D1.84.D1.84._.D0.9E.D1.81.D1.82.D0.BE.D1.80.D0.BE.D0.B6.D0.BD.D0.BE.2C_.D1.82.D0.BE.D0.BD.D0.BA.D0.B8.D0.B9_.D0.BB.D0.B5.D0.B4:_.D0.BE.D1.82_IT-.D0.BA.D0.B0.D1.82.D0.BA.D0.B0_.D0.B4.D0.BE_IT-.D0.BF.D0.B8.D0.BA.D0.BD.D0.B8.D0.BA.D0.B0">Алина Каширская из Тинькофф. Осторожно, тонкий лед: от IT-катка до IT-пикника</span></h1>
<p>Рассказ о том, как выходить за рамки привычного и искать новые форматы. Как соблюсти баланс веселья. В организации был интересный опыт взаимодействия с маркетингом и пиаром, они мыслят иными масштабами, чем деврелы. И как оценивать результаты мероприятия, если это - первая штука.
</p><p>К концу 2022 года было понимание, что все, что делают деврелы - стало базисом, многие вокруг делают тоже самое. Год был сложный, росли и выживали, но на будущее думали, что надо искать что-то новое. И тут пришли ивентщики и сказали, что есть бронь на каток в парке Горького. И кто-то из топов предложил "может, выйдем за привычный формат?" Идею придумали топы, но продумать подробности и реализовать - доверили деврелам, это свидетельство репутации в компании.
</p><p>Что хотели? Хотели выйти за отдельные стримы. Сделать место, куда можно придти всей семьей, показать папе, маме, детям. А еще вместимость площадки позволяет позвать коллег из других компаний, и они решили, что это будет интересно. И действительно получилось сделать фестиваль на люду с большим числом участников из разных компаний. В этом году будут делать еще раз. Отмечу, что каток уже анонсирован. Будет детская зона, ребенка можно взять с собой на большой. а можно - оставить там.
</p><p>Минивыводы. Хотите быть дерзкими - будьте. Но ответьте есть ли базис: удовлетворены ли заказчики, оценивают ли стейкхолдеры вас как экспертов, без этого не будет доверия. Как искать? Ищите - в других форматах. Она сама любит выставки, ходит и смотрит: садовых ложек и многое другое. там попадаются идеи.
</p><p>Делали быстро, за 1 месяц надо сделать каток на 3500 участников. Поэтому была совместная работа с PR, маркетингом и внешним агентством. Уроки взаимодействия.
</p>
<ul><li> Нужен синк! В большой компании тяжело продать идею смежникам, сделать за месяц новую классную идею.</li>
<li> Нужно иметь четкий таймлайн принятия решений. </li>
<li> PR. Первый заход был - какие ресурсы. У ребят - крупные запуски или GR. Надо честно сказать про ресурсы. Поделить поляну, где кто эксперт. PR отдали vip, и они были рады, отпустить и оторваться от привычного. F те предложили классную идею с мишками - офлайн-перформанс у 7 ИТ-компаний. И надо делать единую команду, общие синки и соорганизация. </li>
<li> PR мыслит масштабно, его участие обеспечило 18+ млн уникальных пользователей, таких цифр не было не разу, 2 ТВ-сюжета, публикации</li>
<li> HR-маркетинг. У них есть свой, чтобы пришла их аудитория. Но они никогда не делали такой огромный ивент на такую аудиторию. При этом декабрь - дорогой для рекламы, а в январе - спят. Надо думать, какие каналы задействовать, иметь планы Б, В, Г... У них сработали сторис в мобильном банке. </li>
<li> Агентство с ведущими - провал, не угадали с профилем. И пришлось идти в микроменеджмент.
<ul><li> Дизайнеры любят править ваши логотипы не доустимым образом, за этим надо следить.</li>
<li> Обязательно скажите где стоп-слово, какие шутки - не допустимы. </li>
<li> В квиз и квест они интегрировали историю со своими продуктами, это сработало хорошо.</li></ul></li></ul>
<p>Про оцнеку. Много участников и позитива. Но и негатива много, в паблике любая остывшая чашка кофе снизит оценку. Будьте к этому готовы. Сработала история, что люди ходили парами, семьями, командами. Была миддл и сеньор-аудитория. И это стало самое обсуждаемое событие.
</p><p>И, что интересно, судя по отзывам люди все равно хотели докладов.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B8.D0.BD.D0.B0_.D0.91.D0.BE.D1.80.D0.BE.D0.B2.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.B8.D0.B7_AvitoTech._.D0.94.D0.B8.D1.81.D1.82.D1.80.D0.B8.D0.B1.D1.83.D1.86.D0.B8.D1.8F_.D0.BA.D0.BE.D0.BD.D1.82.D0.B5.D0.BD.D1.82.D0.B0.2C_.D0.B8_.D0.B7.D0.B0_.D1.87.D1.82.D0.BE_.D0.BE.D0.BD.D0.B8_.D1.81_.D0.BD.D0.B0.D0.BC.D0.B8_.D1.82.D0.B0.D0.BA">Алина Боровицкая из AvitoTech. Дистрибуция контента, и за что они с нами так</span></h1>
<p>Это доклад без rocket science, просто выравнивание опыта.
</p><p>В феврале 2022 - ушли fb и твиттер. И они замолчали на месяц, на рынке все странно, все планы сломались.
</p><p>Выход - выходить с контентом. Рекламы не было, просто посты в соцсетях.
</p><p>Как быть, если материала мало, а работать нужно? Инженер выступил - можно переписать, сделать статью или серию постов. Или короткие шоты. Не стесняйтесь переиспользовать, у каждого типа контента - своя досягаемость аудитории.
</p><p>Какие инструменты у них остались? Остались вконтакте и телеграм. Еще есть дзен и rutube - дубли.
</p><p>Репост статей, телеграмные кружочки (они конверсию не увеличивают), посты в соцсетях. Пост из телеграма надо конкретно промоутить. Telegram ads, но там не посчитать эффективность.
</p><p>Видео, митапы, крупные проекты - тоже надо продвигать
</p>
<ul><li> Митап - зайдет в Яндекс-директ</li>
<li> Стажировки - Вконтакте</li></ul>
<p>Маркетинг всегда работает по-разному. Вы запомнили настройки - а в яндекс-директе обновились алгоритмы. Или вы задолбали аудиторию Маркетинг - нестабилен. Надо успокоиться и тестировать.
</p><p>К сожалению, в инструментах, которые остались, в Яндексе и Вконтакте, их целевой аудитории нет. Она была в FB и inst и Телеграм. И надо как-то дотягиваться.
</p><p>Можно покупать рекламу. И TelegramAds, хотя есть вопрос - этично ли ее отправлять туда, где вам отказали в рекламе?
</p><p>Почему не надо боятся маркировки рекламы? Потому что легче не станет. Процесс маркировки лучше делегировать с ответственностью. Токен может делать любая сторона, можно автору.
</p><p>Нет разницы, размещено платно или бесплатно, суть в содержании.
</p>
<ul><li> Если описываете свойства товара без призыва, восторгов - это не реклама. А если любимая конференция и промокод - реклама. </li>
<li> Спикер сходил в подкаст со ссылкой - обычный пост. А если промокод и призыв покупать - реклама.</li>
<li> Если сомневаетесь, что сами можете - делегируйте</li></ul>
<p>В мае был массовый лонч Академии Аналитиков в 2023. По площади в Яндекс директ и таргет по группам ВК
</p><p>Прицельные истории - социальные сети, выходы и партнеров - и посевы в правильных целевых группах. Телеграм-бот - дубль лендинга, и еще telegram ads. И почта на тех, кто не дошел до финала - тем, кто реально прогрел и хотел. И большой отчет - откуда кто пришел, при чем с воронкой. Сколько кликов и до какого этапа дошли кто пришел.
</p><p>Как меньшими усилиями доставлять? Делегируйте! Но! Не было ни единого агенства, которое сразу поняло. Нужно полгода на срабатывание.
</p><p>Если нет возможности - аккуратно приспосабливайте услышанное из этого доклада. Приоритеты, потом переиспользование, потом малые группы и каналы, потом другие бюджеты на малых мощностях (10тр - Яндекс-директ).
</p><p>Срабатывает неожиданно. В одной хейтерской группе регистраций на митап было больше, чем в дружественных.
</p><p>Но чем больше делегируете, меньше контролируете - тем больше места вам для креативной идеи.
</p><p>Экспериментируйте и тестируйте. Будьте любознательны!
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-12-08:_%D0%9B%D0%B8%D0%B7%D0%B0_%D0%A4%D0%B5%D0%BB%D1%8C%D0%B4%D0%BC%D0%B0%D0%BD_%D0%91%D0%B0%D1%80%D1%80%D0%B5%D1%82%D1%82._%D0%9A%D0%B0%D0%BA_%D1%80%D0%BE%D0%B6%D0%B4%D0%B0%D1%8E%D1%82%D1%81%D1%8F_%D1%8D%D0%BC%D0%BE%D1%86%D0%B8%D0%B82023-12-08: Лиза Фельдман Барретт. Как рождаются эмоцииMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-12-08T07:52:14Z2023-12-08T07:52:14Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BD%D0%B8%D0%B3%D0%B8" title="Категория:Книги">О других книгах</a></div>
<p>Полное название книги — амбициозно: <b>Как рождаются эмоции. Революция в понимании мозга и управлении эмоциями</b>. Как и декларировано, в книге предлагается принципиально новая теория работы эмоций. Мне книгу рекомендовали как современный уровень научного представления об эмоциях при обсуждении моего доклада на <a href="https://mtsepkov.org/%D0%9C%D0%B5%D0%BD%D1%8F%D1%8F_%D1%81%D0%B5%D0%B1%D1%8F_%D0%B8_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_-_%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%B9_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE:_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(Teamlead-2023)" title="Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)">Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)</a>. У меня это представление вызывает достаточно много возражений, которые я хочу зафиксировать в отзыве, а содержание книги тут будет не слишком подробно. Вопросы возникли потому, что, на мой взгляд, в этой новой теории проявлен существенный дефицит системного мышления, в основном — обобщения, игнорирующие существенную разницу различных сущностей. Впрочем, такой поверхностный подход объясним общим системным эффектом поверхностности образования в демократиях, о котором смотри Алексиса де Токвиль «Демократия в Америке», а также рядом частных социальных причин, некоторых из которых я буду касаться дальше.
</p><p>Необходимо отметить, что несмотря на все возражения, Лиза Баррет, автор книги — молодец. Потому что она борется с теорией, которая находится на гораздо более дремучем уровне, и при этом была признана как базовая теория эмоций, классический подход.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:BarrettEmotionCover.jpg" class="image"><img alt="BarrettEmotionCover.jpg" src="https://mtsepkov.org/images/1/1a/BarrettEmotionCover.jpg" width="330" height="421" /></a></div>
<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BD%D0%B8%D0%B3%D0%B8" title="Категория:Книги">О других книгах</a></div>
<p>Полное название книги — амбициозно: <b>Как рождаются эмоции. Революция в понимании мозга и управлении эмоциями</b>. Как и декларировано, в книге предлагается принципиально новая теория работы эмоций. Мне книгу рекомендовали как современный уровень научного представления об эмоциях при обсуждении моего доклада на <a href="https://mtsepkov.org/%D0%9C%D0%B5%D0%BD%D1%8F%D1%8F_%D1%81%D0%B5%D0%B1%D1%8F_%D0%B8_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_-_%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%B9_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE:_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(Teamlead-2023)" title="Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)">Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)</a>. У меня это представление вызывает достаточно много возражений, которые я хочу зафиксировать в отзыве, а содержание книги тут будет не слишком подробно. Вопросы возникли потому, что, на мой взгляд, в этой новой теории проявлен существенный дефицит системного мышления, в основном — обобщения, игнорирующие существенную разницу различных сущностей. Впрочем, такой поверхностный подход объясним общим системным эффектом поверхностности образования в демократиях, о котором смотри Алексиса де Токвиль «Демократия в Америке», а также рядом частных социальных причин, некоторых из которых я буду касаться дальше.
</p><p>Необходимо отметить, что несмотря на все возражения, Лиза Баррет, автор книги — молодец. Потому что она борется с теорией, которая находится на гораздо более дремучем уровне, и при этом была признана как базовая теория эмоций, классический подход.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:BarrettEmotionCover.jpg" class="image"><img alt="BarrettEmotionCover.jpg" src="https://mtsepkov.org/images/1/1a/BarrettEmotionCover.jpg" width="330" height="421" /></a></div>
<h1><span class="mw-headline" id=".D0.9E_.D0.BA.D0.BB.D0.B0.D1.81.D1.81.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.BE.D0.B9_.D1.82.D0.B5.D0.BE.D1.80.D0.B8.D0.B8">О классической теории</span></h1>
<p>Для начала — о классической теории. Она проста. Есть шесть базовых эмоций: счастье, гнев, печаль, отвращение, удивление, страх (happiness, anger, sadness, disgust, surprise, fear), и все они однозначно отражаются на лице человека, это — врожденно, практически неконтролируемо и не зависит от культуры и социума. Эмоции перечислены по статье <a rel="nofollow" class="external text" href="https://en.m.wikipedia.org/wiki/Discrete_emotion_theory">Discrete emotion theory</a>, в статье про <a rel="nofollow" class="external text" href="https://en.m.wikipedia.org/wiki/Paul_Ekman">Пола Экмана</a>, автора теории, набор отличается: wrath, grossness, fear, joy, loneliness, shock. Лиза точно использует anger, так что правильно опираться на первую статью. Проблемы с этой теорией очевидны: она предполагает, что господь бог, вернее природа-мать говорит по-английски, и потому сделали механизмы выражения эмоций специально под соответствующие английские понятия. То, что сам набор базовых эмоций был получен простым опросом ведущих психологов, без особой работы по выделению конкретных эмоций — это уже вишенка на этом торте. Хотя эта вишенка, безусловно повлияла на признание теории: ведь каждый из опрошенных внес свой вклад. Ну и мимика тоже выбрана относительно произвольно, актеров попросили показать. Забавно, что печаль — это надутые губы, как при обиде, вероятно потому, что обида в базовые эмоции не попала, то есть ситуации обиды классифицированы как частный случай печали.
</p><p>Как же могла появиться и быть признана классикой такая теория? Для этого была веская социальная причина: у военных был заказ на распознание эмоций, под эти работы можно было получить финансирование, и это было понятным стимулом, но теорию надо было довести до практического применения. И Экман откликнулсЯ, о его работе с военными явно написано в биографии. А бихевиоризм, который был тогда мейнстримом в психологии, предписывал не разбираться в механизмах мышления, а ограничиваться внешней конструкцией стимул-поведение. Кстати, бихевиоризм никуда не исчез с тех времен, не взирая на великую когнитивную революцию, и для этого тоже есть социальные причины, пару лет назад я писал об этом пост <a href="https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2021-03-04:_%D0%91%D0%B8%D1%85%D0%B5%D0%B2%D0%B8%D0%BE%D1%80%D0%B8%D0%B7%D0%BC_%D0%B8_%D1%84%D0%B0%D1%81%D0%B0%D0%B4_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85_%D1%86%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9" title="Блог:Максима Цепкова/2021-03-04: Бихевиоризм и фасад против реальных ценностей">Бихевиоризм и фасад против реальных ценностей</a>.
</p><p>А научное подтверждение? Методика экспериментов была сконструирована таким образом, чтобы подтвердить теорию. Лиза это анализирует в своей книге, ее критическая часть очень скурпулезна. Она не первая, у кого эта теория вызывала вопросы, но там были отдельные сообщения, которые игнорировали, поэтому Лиза проводила анализ «по площади». Это касается и подтверждений, которые были получены в разных культурах. Отметим, что они были необходимы, ведь американские военные работают по всему миру. Лиза в ходе исследований поехала в то племя в южной Африке, куда ездила группа, подтвердившая теорию, но в другую деревню, повторение эксперимента окончилось неудачной, а детальный анализ показал, что подтверждающих исследований был существенный этап, который в статье оказался исключен: если человек показывал результаты, сильно отличающиеся от предсказанного теорией, то исследователи, полагали, что он просто не понял их объяснений… Выяснили это потому, что переводчик у экспедиции был тот же самый.
</p><p>В целом, история классической теории базовых эмоций для меня понятна — были гранты, из освоили: нарисовали умозрительную концепцию и подтвердили исследованиями, в которых важно было именно подтверждение теории, а не научная истинна.
</p>
<h1><span class="mw-headline" id=".D0.A2.D0.B5.D0.BE.D1.80.D0.B8.D1.8F_.D0.9B.D0.B8.D0.B7.D1.8B_.D0.91.D0.B0.D1.80.D1.80.D0.B5.D1.82_.D0.BA.D1.80.D0.B0.D1.82.D0.BA.D0.BE">Теория Лизы Баррет кратко</span></h1>
<p>Теперь перейдем к тому, что предлагает Лиза. Она говорит, что все эмоции — исключительно результата социального опыта, при чем индивидуального. Что никаких объективных механизмов за эмоциями не стоит. Есть внутренние ощущения тела, которые получает мозг и которые можно измерить объективными методами: сердцебиение, температура и так далее. А дальше мозг в моменте интерпретирует это, как его научили, конструируя эмоцию. И вы можете подумать, что у вас нравится парень, с которым пошли на свидание, хотя у вас просто начинается грипп, это пример из собственного опыта, который Лиза приводит.
</p><p>Тут надо сделать пояснение о терминах. В русской школе психологии есть различие эмоциональных процессов: аффект — эмоция — настроение — чувство по длительности действия. В западной терминология иная, она восходит к <a rel="nofollow" class="external text" href="https://ru.wikipedia.org/wiki/Вундт,_Вильгельм">Вильгельму Вундту</a>, это конец 19 века. Лиза прямо на него ссылается. Есть аффект — приятное или неприятное состояние, оно не дифференцировано и есть у человека и у животных. А дальше у человека есть эмоции — интерпретация этих состояний, как она была сформирована социальными взаимодействиями.
</p><p>Естественно, из такого различения терминов следует, что животных никаких эмоций нет, только аффекты — просто по определению, это не вопрос доказательств. И даже если набор аффектов детализировать, разделяя, голод-сытость от недосыпания-хорошего отдыха и от недостатка-удовлетворения половой жизнью, то это получается не слишком интересно: ведь это — животная часть, а не человеческая. Теория опирается тезис о принципиальном отличии человека от животных, который, хотя и был поколеблен еще Дарвином (середина 19 века), продолжал жить и живет до сих пор, не взирая на всю современную этологию. Но, все равно, очень странно, если Вундт на самом деле считал, что животные не могут различить конкретные причины отрицательного и положительного состояния, путают голод с недосыпом, и что люди это тоже путали бы, если бы их не научили, что голод и секс — это про разное.
</p><p>Несколько странно, что Лиза, которая очень отрицательно относится к теории триединого мозга за то, что она делит личность на зверя и рационального человека, не замечает этой границы в собственной модели, делящей аффекты и эмоции ровно в том же месте. Это как раз к вопросы о системном мышлении, учащем выделять границы и замечать, как их проводят другие.
</p><p>Отмечу, что эмоциям у животных в книге посвящена отдельная глава 12, в которой Лиза как раз обосновывает, что у животных нет человеческих эмоций, потому что у них очень ограничена способность формировать понятия, их можно этому обучить, но в достаточно ограниченном объеме, и, конечно, передать сложные эмоции, которые классическая теория назвала базовыми — не получится. Так что эмоции им приписывают люди. Повторюсь, в такой терминологии это — очевидный вывод.
</p><p>Если кратко про теорию — то это все. Дальше пойдут отдельные положения и мои комментарии к ним.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.BE.D0.B7.D0.B3_.D0.BA.D0.B0.D0.BA_.D0.BC.D0.B0.D1.88.D0.B8.D0.BD.D0.B0_.D0.BF.D1.80.D0.B5.D0.B4.D1.81.D0.BA.D0.B0.D0.B7.D0.B0.D0.BD.D0.B8.D0.B9">Мозг как машина предсказаний</span></h1>
<p>Лиза говорит, что основное назначение мозга — это предсказания для управления внутренним состоянием организма, бюджетом его ресурсов. Основой предсказаний служит внутренние ощущения, интероспекция. А социальная интерпретация, эмоции — это вторично. По сути, здесь мы неявно проявляется та самая отрицаемая граница между человеком и животными.
</p><p>Я хочу заметить, что назначение мозга как инструмента предсказаний, благодаря которому человек стал лучше адаптироваться к окружающему миру и деятельно изменять его, безусловно, правильно. Это, в том числе, согласуется с современыми взглядами на эволюцию — принцип свободной энергии Фристона говорит, что эволюция усложняет модели мира для уменьшения ошибок предсказания, подробное популярное изложение можно прочитать <a rel="nofollow" class="external text" href="https://evan-gcrm.livejournal.com/1548097.html">здесь</a>.
</p><p>Но то, что мозг — инструмент предсказаний не означает, что все его части только предсказаниями занимаются, это все равно, что говорить, что транспортные компании перевозят или люди живут. Это справедливо, но внурти транспортной компании надо различать саму перевозку от погрузки, разгрузки, хранения. Так и в работе мозга надо различать предсказания, то есть моделирование будущего, от аналиа и интерпретаций настоящего и от команд на действия и обеспечения их исполнения организмом. В книге этого нет.
</p><p>В книге вообще в не рассматривается человек как активно действующий субъект. Задача поддержания гомеостаза заменена на задачу поддержания динамического равновесия, аллостаза, но с чем связана эта динамика — не рассматривается.
</p><p>Понятно, что когда мы намереваемся что-то выполнить, то для этого требуются ресурсы организма и их надо подготовить. И этот сценарий работы мозга отличается от реактивного поведения, в котором может быть нужна мобилизация ресурсов в ответ на какие-то замеченные внешние изменения. И, вероятно, тут следует различать (1) процесс анализа внешних сигналов и дает предсказания о требуемых действиях, (2) процесс планирования будущие активные действия и так же выдает сценарии, и (3) мониторинг текущего исполнения, например, движения тела и корректирует, если возникают отклонения. Ведь механизмы управления в теле основаны на химических реакциях, и отклонения — неизбежны, их надо корректировать, и тут есть очень сложная регуляция на мышцах: есть большие мышцы для быстрых, сильных и неточных движений и мелкие для их корректировки, и все это работает и управляется параллельно и согласованно. Возможно, процессы в мозге стоит выделять по-другому, тут, как и в процессах в организации, нет объективных физических границ нет, но и полного произвола тоже нет. Но описывать всю внутреннюю работу мозга единственным словом «предсказания» (prediction) убирает любые возможности анализа. Например, мы не можем различать ошибки анализа и интерпретации от ошибок предсказания изменений и от ошибок планирования, у нас есть обобщенные ошибки. Понятно, что такое объединение — неявный след бихевиоризма, которые предписывал не погружаться внутрь мозга.
</p><p>Модель непрерывных сценарных предсказаний и сравнения реальности с ними описана в главе 4 Происхождение чувств, вместе с рядом экспериментальных данных. Но все эксперименты можно описать как в рамках модели непрерывных предсказаний, так и в рамках более сложной модели: идет непрерывный мониторинг угроз, требующих реакции-действия (на пути руки возникло препятствие), и работает с ожидаемыми сигналами, при поступлении которых действия надо изменить в соответствии со сценарием (руку уже поднесли к предмету, пора хватать). При поступлении сигналов инициируется реакция, не всегда на сознательном уровне. Понятно, что системы распознавания при этом могут дать ошибку, равно как и вычисление предсказания, дальше модель корректируется. Все описанные эксперименты можно интерпретировать в обоих моделях, но создание предсказания гораздо более вычислительно трудоемко, поэтому второй вариант представляется более адекватным, пока эксперимент не докажет иное. Отмечу, что оба варианта — не реактивное поведение стимул-реакция, которое автор опровергает.
</p>
<h1><span class="mw-headline" id=".D0.9D.D0.BE.D1.80.D0.BC.D0.B0.D1.82.D0.B8.D0.B2.D0.BD.D0.B0.D1.8F_.D0.B8_.D0.B8.D0.BD.D0.B4.D0.B8.D0.B2.D0.B8.D0.B4.D1.83.D0.B0.D0.BB.D1.8C.D0.BD.D0.B0.D1.8F_.D1.80.D0.B5.D0.B0.D0.BA.D1.86.D0.B8.D1.8F">Нормативная и индивидуальная реакция</span></h1>
<p>Еще один отпечаток бихевиоризма в том, во всех исследованиях рассматривается нормативная эмоциональная реакция. То есть когда в эксперименте люди стараются что-то сделать, а экспериментатор ругает их за плохую работу, отпуская критические и даже оскорбительные замечания, то предполагается, что люди обязательно испытывают гнев. И, аналогично если в рабочей ситуации начальник сообщил, что повышение получит не сотрудник, а его коллега, то сотрудник также испытывает гнев. Потому что залезть внутрь головы мы не можем, это «не научно», не дает эмпирических данных. Эта нормативная реакция проходит через все исследования, которые связаны с классической теорией, но это же появляется и в описании новых исследований. Она предполагает, что внутри получился гнев, а различаются лишь внешние его проявления, мимика и другое внутреннее состояние: одни кипят от злости, другие плачут. Естественно, при таком объединении поучается, что мы не можем отделить одну эмоцию от другой. Отметим, что переводчики специально оговорили, что они в одних случаях переводят anger как гнев, а в других как сердитость по смыслу. Но по сути такой перевод вводит дополнительную дифференциацию в ту самую теорию базовых эмоций.
</p><p>И когда Лиза говорит о конструировании эмоций на основе индивидуального опыта, она тоже не различает отдельные этапы. Она говорит, что вас социально научили реагировать определенным образом через личный жизненный опыт и через фильмы, и другие культурные артефакты, и сформировали у вас понятие «anger», которым вы пользуетесь. И призывает уменьшать гранулярность этих понятий. Но тут есть очень важный момент: при крупной и произвольно спроектированной гранулярности эмоций указать на их отпечаток действительно невозможно. А вот если мы детализируем гранулярность, а еще разделяем этап выбора эмоции и этап выражения этой эмоции через мимику или словами, то, вероятно, такие отпечатки можно будет найти.
</p><p>Но Лиза не проводила исследования по дифференциации реакций, она ограничилась лишь тем, что зафиксировала большое различие реакций при той крупной гранулярности, которую дает базовая теория. И я тут хочу сказать, что рассуждая аналогично, можно обосновать, что отдельные понятия для кошки и собаки тоже являются фикцией: все похожи, индивидуальное различие конкретных экземпляров много больше, чем отличия между видами, и еще отличия домашних и бездомных гораздо важнее, чем отличия между кошками и собаками. Этим рассуждениям будем мешать возможность не просто увидеть кошек и собак, но и провести научные исследования по внутреннему строению, геному и так далее, а вот если смотреть только на внешние проявления все будет неплохо. А внутрь эмоций залезть гораздо сложнее.
</p>
<h1><span class="mw-headline" id=".D0.9D.D0.B5.D0.B9.D1.80.D0.BE.D1.84.D0.B8.D0.B7.D0.B8.D0.BE.D0.BB.D0.BE.D0.B3.D0.B8.D1.8F_.D1.8D.D0.BC.D0.BE.D1.86.D0.B8.D0.B9">Нейрофизиология эмоций</span></h1>
<p>Почему я полагаю, что с эмоциями связаны нейрофизиологические механизмы, хотя Лиза Баррет их отрицает? Потому что есть достаточно много исследований, связанных с конкретными гормональными нейрофизиологическими механизмами. Здесь можно вспомнить исследования Хелен Фишер. Они обязаны своим происхождением идее опровергнуть мнение, сложившееся в научном сообществе о том, что вся романтичная любовь — социальное явление, выдуманное поэтами и писателями 19 века, а реальна лишь потребность в сексе.
</p><p>Но Хелен Фишер не пыталась найти в мозгу отпечаток любви, это бы точно у нее не вышло, потому что понятие любви охватывает очень большой спектр состояний. Однако, она разложила ее на отдельный фазы и искала, есть ли что-то общее в каждой фазе, ставила эксперименты, в том числе включающие томографические обследования. И у нее получилось найти четыре нейрофизиологических механизма, основанных на путях распространения в мозге разных гормонов, и проявляющихся при создании и развитии отношений. Часть из них было известно и раньше, другие были открыты в ходе ее исследований. Позднее она обобщила это на другие виды деятельности и получился четыре пути мотивации: дофамин, ответственную за поисковое поведение и исследования, а в отношениях проявляющуюся на этапе поиска партнера, тестостерон, который отвечает за агрессию, победу и секс, окситоцин и эстроген, отвечающий за обнимашки, ласки, теплые социальные отношения и социальное подкрепление и серотонин — счастье регулярной повседневной деятельности, обеспечивающий внутреннее подкрепление и самооценку. И еще были пути, связанные с механизмами, которые проявляются при разочарованиях, расставаниях и неудачах.
</p><p>Ход экспериментов подробно описан в ее книге «Почему мы любим: природа и химия романтической любви», и это было выдвижение и проверка гипотез, получение научно-значимых подтверждений для своих результатов. Именно поэтому я не сомневаюсь, что аналогичные исследования можно провести для эмоций и так же вскрыть их механизмы — только это будет не умозрительно построенные базовые эмоции, а те механизмы, которые сформированы в ходе эволюции еще у животных, и которые продолжают действовать. Ведь животные в одних угрожающих ситуациях проявляют агрессию, в других убегают, а в третьих замирают. Все эти действия требуют конкретных ресурсов организма, которые, естественно, надо регулировать. И эти механизмы остались у человека, хотя в нынешней социальной реальности, возможно, больше мешают, чем помогают. И их надо понять и учитывать, когда ты управляешь собой, а не игнорировать или рассматривать как личный опыт, которым можно произвольно управлять.
</p><p>Отмечу, что в терминах психологической школы, в которой работает Лиза Баррет все это относится к уровню аффектов, а не к уровню эмоций. А вот в книге Хелен Фишер, которая работала в поле нейрофизиологии, а не психологии, такого разделения нет.
</p>
<h1><span class="mw-headline" id=".D0.92.D1.8B.D0.B1.D0.BE.D1.80_.D1.8D.D0.BC.D0.BE.D1.86.D0.B8.D0.B8_.D0.B8_.D0.B5.D0.B5_.D0.B2.D1.8B.D1.80.D0.B0.D0.B6.D0.B5.D0.BD.D0.B8.D0.B5">Выбор эмоции и ее выражение</span></h1>
<p>Если мы рассматриваем механизм эмоций как частный случай работы мозга, то есть минимум три фазы: фаза выбора реакции, фаза гормональной реакции и фаза выражения в коммуникации через мимику и язык. И именно выбор реакции определяет, какой из механизмов будет запущен.
</p><p>В книге Лиза рассказывает, что она проверяла тезис о связи амигдалы (amygdala, миндалевидное тело) и страха, и было обнаружено, что ее возбуждение фиксируется в ответ на любую новую ситуацию, а не только в случае страха. Но если мы работаем в модели опознания ситуации для выбора реакции, то так и должно быть: амигдала проверяет, следует ли в ответ на данную ситуацию готовится к бегству или к драке, а далее выносит вердикт и при положительном ответе идет гормональный ответ. И, естественно, опознание новой ситуации идет параллельно всеми областями мозга, ответственными за различные виды реакций. Исследование фМРТ показывает возбуждение, но не показывает, какая из областей выдала вердикт. При этом знакомая ситуация опознается быстро, без возбуждения и ответ следует сразу.
</p><p>Кстати, в главе 12, посвященной эмоциям животных, вернее, их отсутствию, про реакцию в угрожающей ситуации есть очень характерное рассуждение: раз мы увидели угрозу, значит обязательно должна возникнуть эмоция страха, а дальше — три возможных реакции. Собственно, это так и описывается: «испугался и замер», «испугался и убежал», «испугался, но напал». И поскольку в последнем варинте амигдала не задействуется, Лиза делает вывод что экспериментальное подтверждение ее связи со страхом — не обоснованы. В то время как очевидный путь — дифференцировать эти три случая страха, и заключить, что для них есть разные нейрофизиологические механизмы. Как это делала Хелен Фишер для переживаний, связанных с любовью. Правда, при этом эмоция вдруг получит отпечаток в мозгу, а это противоречит теории.
</p><p>Теперь другая часть, мимика. Новорожденные люди, как и новорожденные звери, различают свои внутренние состояния, отличают голод от потребности во сне, хотя понятно, что могут путать. Дальше им надо передать эту информацию маме, чтобы вызвать ее действия. Понятно, что есть универсальный способ — крик, но действия-то нужны разные, и от матери следует не всегда ожидаемый ответ, и ей тоже надо это передать, отличая ситуацию «сейчас покормлю» от «не время, покормлю позже». Речи еще нет, а мимика уже есть и, собственно, именно на этом этапе новорожденный обучается, вырабатывается язык мимики для коммуникации с мамой и другими окружающими. Ну и далее это развивается, общение через мимику заложено как базовый способ, но конкретные выражения у млекопитающих, включая человека, отсутствуют, они формируются через обучения. На мой взгляд, исследования Лизы показали именно это.
</p>
<h1><span class="mw-headline" id=".D0.9E.D0.B1.D1.83.D1.87.D0.B5.D0.BD.D0.B8.D0.B5_.D1.8D.D0.BC.D0.BE.D1.86.D0.B8.D1.8F.D0.BC">Обучение эмоциям</span></h1>
<p>Итак, мой тезис в том, что гормональные механизмы эмоций заложены на уровне нейрофизиологии, а Лиза Баррет их отрицает. Однако, независимо от этого определение ситуаций для конкретной эмоциональной реакции и способы выражения конкретных эмоций формируется обучением, они на записаны в мозг. У человека есть две ветки обучения: индивидуальное, основанное на взаимодействии с родителями и другими окружающими людьми, которое начинается с рождения и социально-культурное, которое сейчас тоже начинается рано через просмотр мультиков и фильмов.
</p><p>В книге обучение представляется в достаточно сокращенном варианте: фильмы, обучение в школах и культура в целом построены на классической теории базовых эмоций, ее же используют родители при сознательном обучении детей, а через мимику ребенок видит фактические выражения эмоций, которые слабо соответствуют теории. Я думаю, что все не так плохо, фильмы — многоплановы и вовсе не обязательно показывают тот состав шести базовых эмоций, в разговорах тоже говорят об эмоциях и переживаниях шире, хотя, возможно, та часть школьной программы, где рассказывают научные представления об эмоциях основана именно на этой теории.
</p><p>К призыву Лизы ориентироваться на мелкую гранулярность эмоций, учиться различать реакции организма и собственные переживания от социально предписанных, пользоваться широким понятийным аппаратом я, безусловно, присоединяюсь.
</p>
<h1><span class="mw-headline" id=".D0.9F.D0.BE.D0.BD.D1.8F.D1.82.D0.B8.D1.8F_.D0.B4.D0.BB.D1.8F_.D1.8D.D0.BC.D0.BE.D1.86.D0.B8.D0.B9">Понятия для эмоций</span></h1>
<p>Поскольку, в соответствии с теорией Лизы, основой эмоций являются сформированные понятия о них, то в главе 5 и далее Лиза рассматривает, как именно они формируются. В соответствии с теорией Лизы, объективных показателей, по которым мы можем разделить разные эмоции, не существует, а значит понятия представляют собой категории, к которым мы относим частные случаи. К ним надо, во-первых, отнести собственные внутренние состояния, во-вторых, отнести состояния других людей, с которыми ты непосредственно общаешься, а, в-третьих, относить состояния посторонних лиц, с которыми нельзя вступить в коммуникацию, например, воспринимая фильмы или обсуждая их. Чтоб описать работу с категориями Лиза пользуется теорией прототипов, которая претендует на современное описание механизмом того, как мышление работает с абстрактными понятиями.
</p><p>В соответствии с этой теорией, мозг не может напрямую работать с обобщенным понятием, например, понятием животного, а визуализирует его через конкретный образ-прототип. Прототип зависит от накопленного опыта, я бы сказал — веса различных ассоциаций, при этом еще и конструируется в моменте, учитывая контекст разговора. То есть когда ты говоришь о домашних животных или о животных Африки, то будут предъявлены разные прототипы, а если еще пойдет уточнение, что речь идет о домашних животных Африки — то появится что-то третье. И эти прототипы у каждого человека — свои, они зависят от личного опыта и того культурного контекста, который человек впитал. И тут есть тонкий момент: личный опыт включает множество экземпляров, например, фактов общения с кошками. Если у тебя есть собственная кошка, то для нее точно есть персонализированный образ, и такие же есть для нескольких знакомых кошек. Когда ты играешь на улице с конкретной кошкой, то в моменте образ тоже персонализируется в деталях — ты же взаимодействуешь с конкретной кошкой. А вот насколько эти персонализированные образы сохраняются в мозгу, а насколько обобщаются, науке не слишком известно. И вовсе не обязательно, что когда вы говорите о сказочном коте, или коте из какой-то истории, которую рассказывает друг, то будут вытащены именно эти образы.
</p><p>Но с кошкой — просто, у нее есть образ. С животным — сложнее, потому что животные — очень разные, и что такое — обобщенный прототип — неясно. Образ для животного и для зверя может быть сильно разный, хотя слова — почти синонимы. И не факт, что он вообще есть, потому что конкретизация мешает обобщенным рассуждениям. А с эмоциями все вообще сложно, потому что тут мы описываем слабо предъявляемые внутренние состояния и переживания, показать можно лишь позу и выражение лица. А описание внутренних состояний наука учит игнорировать как неточные и невоспроизводимые.
</p><p>Лиза использует наиболее простой вариант теории, говорит, что мозг хранит все экземпляры, что они как-то разложены по тем понятиям, которые у нас есть, и что прототип не существует постоянно, а конструируется в моменте, предъявлением наиболее подходящего экземпляра или синтезом из нескольких.
</p><p>Лиза говорит, что есть два способа категоризации: по внутреннему устройству и по целям, второй тип категорий может объединять самые разные предметы, например, создавая категория инструментов. Поскольку общего устройства в виде отпечатка возбуждения в мозгу или в физиологических параметрах организма у категорий эмоций не обнаружено, то Лиза заключает, что речь идет о категоризации по целям. Тут у меня есть вопросы: почему способов категоризации всего два? Тем более, что в классификацию по целям попали «предметы, вызывающие шум», или «животные, способные взбираться на деревья» — это же атрибут, как и цвет. Какие именно цели объединяют такую категорию как «гнев» — они не предъявлены. Вообще, несмотря на призывы к более детальной классификации эмоций, Лиза при рассмотрении использует именно общие категории из классической теории, хотя ранее уже доказала, что в них-то точно нет смысла. То есть ситуация тут такая же, как с отсутствием отпечатков: их не обнаружено именно для этих шести базовых эмоций, что естественно, потому что в них объединили очень разные эмоции, и на основании этого сделан вывод, что отпечатков нет вообще. А в данном случае заключили, что мы классифицируем по целям, но цели предъявить тоже не получилось.
</p><p>В общем, на мой взгляд есть недостаток системного мышления, и не только у автора. Описан эксперимент с шимпанзе, которым предъявляли человеческие эмоции, в ходе которого явно поменяли задачу: в одном варианте требовалось обучиться классификации экспериментатора, она предъявлялась, а в другой — самостоятельно построить классификацию, а удачей считалось, если она совпадет с имеющейся у экспериментатора. Первая задача решаема — шимпанзе хорошо обучаются, а вторая — нет, потому что у шимпанзе точно нет врожденной классификации человеческих эмоций и нет опыта взаимодействия. А экспериментаторы считают, что оба эксперимента отвечали на один и тот же вопрос. Кстати, отметим, что эксперимент аналогичен экспериментам с людьми по классификации эмоций.
</p><p>Показательно рассуждение про радость от чужого несчастья — слово для обозначения этого было недавно заимствовано в английский из немецкого, а в русском есть давно — злорадство. Автор полагает, что появление понятия привело к тому, что люди начали испытывать эту эмоцию. Но это — явно не так. Люди испытывали эту эмоцию, радовались чужому несчастью и раньше. Просто это было несколько неприлично, и для описания хватало словосочетания. А сейчас, в силу каких-то социальных явлений понятие потребовалось — и появилось заимствование.
</p><p>Вообще если разбираться в конструктиве, то есть строить категории эмоций, то надо понимать, что эмоции есть разной сложности. Есть достаточно конкретные и однородные: радость, голод, боль, обида, а вот печаль — это явно сложное понятие, и сердитость — тоже, потому что она из трех тактов: ты почувствовал раздражение, идентифицировал причину, и теперь по отношению к ней испытываешь сдерживаемую агрессию. При этом отдельные слова — не обязательны, хотя они сокращают коммуникацию и способствуют гранулярности восприятия. Но можно работать со словосочетаниями или даже предложениями. И важно разделять внутренние ощущения от их описания словами, это — про разное. Точно так же, как важно разделять внутренние ощущения от мимики. У Лизы это слеплено в обоих случаях.
</p><p>Еще стоит заметить, что на рисунке 6.1, которым автор показывает представление понятий, представлен направленный граф, на котором смешаны отношения общее-частое и целое-часть. Там уровни абстракции, а не сеть. И отсутствуют прототипы, а если опираться на теорию прототипов — то их надо представить.
</p><p>А если мы рассматриваем социальную ситуацию, например, кейс с начальником, который отдал место другому (глава 6), то там еще сложнее. Потому что когда сотрудник это узнает, то возникает его индивидуализированная реакция. Которой вовсе не обязательно является гнев, как требует того норматив поведения, вполне может быть смирение с высшей волей и печаль по этому поводу или другие варианты. Дальше эта реакция как-то проявляется, и насколько рациональное мышление в моменте скорректировало первый импульс — тоже зависит от человека и ситуации. А потом мы еще то что произошло как-то объясняем, сначала — для себя, а потом, возможно, и для других, и это все — разные истории. Понятно, что они все — внутри, никаких объективных свидетельств тут нет, и бихевиоризм велит все это слепить в один непоозрачный клубок. Бихевиоризм как бы в прошлом, но те основания субъективизма и невоспроизводимости, по которым он предписывал отвергать для науки сведения о внутренних рассуждениях и переживаниях индивидуума — никуда особо не делись.
</p><p>И все тоже самое проявляется и в других ситуациях, которые описываются в книге, например, кейсах с полицейскими, которые кого-то там застрелили, потому что подумали, что увидели оружие. Если мы хотим разобраться, чтобы изменить статистику случаев, то надо разложить ситуацию на фазы, посмотреть, где именно происходят ошибки, с чем они связаны и их изменять. А обобщать, что это происходит потому, что полицейские не любят чернокожих — это пропаганда, а не наука.
</p><p>И еще одну путаницу вносит идея про то, что мозг все время предсказывает. Он не только предсказывает, он категоризирует ситуацию, чтобы далее на основе категоризации построить сценарий развития ситуации и своего поведения. И ошибки могут быть на разных этапах — анализа, предсказания развития ситуации, построения своего поведения, его реализации, их надо различать. В кейсе с дочкой, которая ошибочно приняла другого человека за дядю Кевина у нас ошибка опознания.а не предсказания.
</p><p>При этом анализ работает сложно, там вовсе не обязательно берут все детали и делают заключение, очень часто на основании каких-то ключевых признаков делается обобщенная категоризация, и далее мозг ищет подтверждающие детали, а иногда обращает внимание на опровержение. Это все в реальном времени, ошибки — вполне возможны и типичны. Кстати, в науке — тоже самое, нет сбора деталей и обобщения, гипотеза строится на отдельных замеченных идеях, это <a rel="nofollow" class="external text" href="https://document.wikireading.ru/34442">дуга Эйнштейна</a>. Другое дело, что научный метод предписывает далее эти гипотезы проверять, как поиском подтверждений, так и на отсутствие противоречащих данных, и насколько это добросовестно делается — вопрос отдельный. Критика подтверждений теории базовых эмоций показывает, что с добросовестностью тут проблемы, и принятые социальные механизмы научного сообщества ее не обеспечивают.
</p><p>В главе 8 есть большое рассмотрение, касающееся концепции эссенциализма — того, что у любой категории должна быть внутренняя сущность. И многие проблемы классической теории эмоций оно обосновывает тем, что авторы как раз опирались на концепцию эссенциализма.
</p><p>На мой взгляд, тут ложная дихотомия: либо эссенциализм, либо произвол для построения категорий. Научный подход в том, чтобы выявить некоторые закономерности и внутренние механизмы, и оперировать ими. То, что классическая теория эмоций выявила их неверно — не значит, что их не существует. Если мы посмотрим на систематику в биологии, то было очень много произвольных классификаций растений и животных, прежде чем появилась нынешняя эволюционная классификация. А сделанный анализ ДНК еще и перестроил ее. Нейрофизиология, на мой взгляд, сейчас знает достаточно про гормональные и другие механизмы мозга, чтобы построить научную теорию эмоций. А не просто опровергать произвольные умозрительные классификации.
</p><p>Концепт эссенциализма и далее появляется в книге, в том числе в главе 13, которая является завершающей. Лиза напоминает, что понятия создает социальная реальность, взаимодействия с другими людьми и потому за ними не может быть никакой внутренней сущности, кроме такого соглашения. Но, на мой взгляд, наличие соглашения означает, что мы можем указать на сущность — через набор объектов, которые обобщает то или иное понятие — как учит рациональное мышление, и соглашение — это договоренность об этих объектах, которая может быть различной.
</p><p>А еще она говорит, что локализовать эти понятия в конкретных нейронах, как это предполагает эссенциализм, невозможно. И тут тоже у Лизы чересчур сильный тезис. Я приведу такую аналогию, когда мы смотрим на сложные движения человека, например, танец, то в каждом перемещении задействуется множество мышц, которые у хорошего танцора работают согласованно, обеспечивая плавность движений в одних случаях и резкие движения в других. Мы не можем указать конкретную мышцу, ответственную за конкретное движение. Но это вовсе не означает что все движения выполняются всем телом: оно выполняется конкретными мышцами, напрягающимися и расслабляющимися определенным образом, у него есть локализация в мыслях. Так и понятий есть множество частных случаев, которые они описывают, а также локализация в нейронах и связях между ними — ансамблях нейронов по <a rel="nofollow" class="external text" href="https://en.wikipedia.org/wiki/Attention_schema_theory">Attention schema theory</a> <a rel="nofollow" class="external text" href="https://ru.wikipedia.org/wiki/Грациано,_Майкл">Майкла Грациано</a> или <a rel="nofollow" class="external text" href="https://ru.wikipedia.org/wiki/Когнитом">Когнитомах</a> по <a rel="nofollow" class="external text" href="https://ru.wikipedia.org/wiki/Анохин,_Константин_Владимирович">Анохину-внуку</a>. Да, они распределены по многим отделам мозга, перекрываются, и там одни понятия переходят в другие, обобщенные образы в конкретные и так далее. Но это не значит, что локализации нет.
</p><p>А пока это не сделано — надо решать инженерную задачу управления своими эмоциями, улучшать формирование представлений об эмоциях у детей. Это — нормальная инженерная постановка задачи. И это — вопрос индивидуальный, спасение утопающих — дело рук самих утопающих.
</p>
<h1><span class="mw-headline" id=".D0.AD.D0.BC.D0.BE.D1.86.D0.B8.D0.B8_.D0.B8_.D1.81.D0.BE.D1.81.D1.82.D0.BE.D1.8F.D0.BD.D0.B8.D0.B5_.D0.BE.D1.80.D0.B3.D0.B0.D0.BD.D0.B8.D0.B7.D0.BC.D0.B0">Эмоции и состояние организма</span></h1>
<p>Главы 9-10 посвящены управлению эмоциями и их связи с состоянием организма и болезнями. С одной стороны, там многое верно: эмоции влияют на состояние организма, эмоциональное состояние существенно в ходе болезни. Но при этом неявно сохраняется разделение на эмоции и аффекты, рассмотрение которых находится за рамками книги, эмоции рассматриваются исключительно как социально сконструированные. И потому рассмотрение получается существенно неполным, по стрессу, депрессии, и другим проблемам.
</p><p>А идеи здорового питания — хорошо, только наука пока не слишком хорошо отвечает, какое питание является здоровым с учетом индивидуальности людей.
</p><p>А тезис о повышении гранулярности эмоций и о просвещении — хороший и правильный. И тезисы о том, что эмоции культурно-обусловлены и потому есть значительное культурное разнообразие для эмоций, в том числе, проявляющееся через разные наборы эмоций в разных языках, и в современном мире, где люди переезжают и рядом оказываются носители самых разных культур это надо учитывать.
</p>
<h1><span class="mw-headline" id=".D0.AD.D0.BC.D0.BE.D1.86.D0.B8.D0.B8_.D0.B8_.D0.B7.D0.B0.D0.BA.D0.BE.D0.BD">Эмоции и закон</span></h1>
<p>Этому посвящена глава 11. В общем, тут нечего комментировать. У Лизы много частных проблемных случаев, но из них ничего не следует. Понятно, что законы писали давно, но о том, что эмоции можно симулировать, что в голову человека не залезешь, их авторы были вполне осведомлены. И никакой базовой теории эмоций про однозначную проявление эмоций через мимику тогда не было. И что сытый человек — благодушен, а голодный — строг — тоже понимали без современных научных подтверждений. Так что не слишком понятно, что новые теории эмоций могут практически дать. Лиза сама тут ограничивает рекомендации просвещением, и это — правильно, потому что надо противодействовать и неверному пониманию эмоций и в целом осознанности присяжных и судей. А более радикальные идеи о замене присяжных профессиональным жюри, приведены без оснований и гипотез о достигаемых таким образом целях. Да и в любом случае, они требуют комплексного рассмотрения проблемЫ, вопрос об эмоциях тут недостаточен, надо выходить в социальные вопросы рассмотрения суда и наказаний в целом.
</p>
<h1><span class="mw-headline" id=".D0.97.D0.B0.D0.BA.D0.BB.D1.8E.D1.87.D0.B5.D0.BD.D0.B8.D0.B5">Заключение</span></h1>
<p>Если это — последнее слово науки об эмоциях, то оно вызывает печальку. Хорошо, что классическая теория базовых эмоций опровергнута, тут Лиза Баррет молодец. Но для конструктивного рассмотрения надо еще убирать границы между аффектами и эмоциями, разделяющую человека и животных, проведенную Вундтом и вести комплексное рассмотрение, учитывая и внутренние ощущения и понятийный их категоризацию через понятия и рациональные объяснения, выдаваемые постфактум, с учетом формирования всего этого личным опытом и социальной средой.
</p><p><br />
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-12-07:_SQAdays-33_-_%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B4%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%D1%8B_%D0%B8_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B0%D1%8F_%D0%B0%D1%82%D0%BC%D0%BE%D1%81%D1%84%D0%B5%D1%80%D0%B02023-12-07: SQAdays-33 - качественные доклады и хорошая атмосфераMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-12-07T14:38:25Z2023-12-07T14:38:25Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Впечатления от <a rel="nofollow" class="external text" href="https://sqadays.com/ru/program/110410"><b>SQAdays-33</b></a>, на которой я был в конце ноября, уже смазаны следующими конференциями: Highload и Teamlead. Однако, я помню что на SQAdays, как обычно, была очень качественная атмосфера, много общения и качественные доклады. Собственно, именно атмосферой мне более 10 лет назад понравился SQAdays, и меня очень радует что она по-прежнему хороша. Это не только мое мнение, я слышал и отзывы других участников. А вау-докладом конференции был доклад Алексея Пименова о работе с противодействием изменений. Он, кстати, был признан лучшим докладом конференции. А меня впечатлило хорошее сочетание в одном докладе довольно широкого теоретического изложения и практических приемов, я тоже так хочу и буду стараться.
</p><p>Я тоже выступал на конференции с докладом <a href="https://mtsepkov.org/%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5:_%D1%87%D0%B5%D0%B3%D0%BE_%D1%8F_%D1%85%D0%BE%D1%87%D1%83_%D0%BE%D1%82_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_%D0%B8_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_(SQAdays-2023)" title="Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)"><b>Самоопределение: чего я хочу от жизни и работы</b></a>. По теме самоопределения у меня уже была серия докладов, но организаторы сказали, что потребность - все равно есть, и есть актуальные вопросы, не все из которых освещены в докладе. Например, пора ли самоопределяться? Потоvу что, оказывается, есть сейчас стереотип что место работы надо менять часто, и только человек освоился и начал расти, как он думает "что-то я засиделся, стало слишком спокойно" - и идет на новое место, хотя потенциал этого еще не исчерпан. Или другая ситуация: ты успешно сменил команду и специализацию, осваиваешься, идет тяжело. Как понять, это трудности адаптации, или не повезло с командой, или ты выбрал не свое дело? Или ты устал на проекте и хорошо бы сходить в отпуск, но через месяц-два сдача этапа: идти или подождать, как договариваться? И так далее. Многие из этих вопросов - про управление драйвом, а это - часть процесса самоопределение. И я постарался расширить доклад, добавив ответы на них. Презентация - на странице доклада, там же появится видео и есть ссылки на другие доклады и статьи по теме.
</p><p>А теперь - про другие доклады. Начну я с доклада Алексея Пименова, а дальше пойду по порядку.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Впечатления от <a rel="nofollow" class="external text" href="https://sqadays.com/ru/program/110410"><b>SQAdays-33</b></a>, на которой я был в конце ноября, уже смазаны следующими конференциями: Highload и Teamlead. Однако, я помню что на SQAdays, как обычно, была очень качественная атмосфера, много общения и качественные доклады. Собственно, именно атмосферой мне более 10 лет назад понравился SQAdays, и меня очень радует что она по-прежнему хороша. Это не только мое мнение, я слышал и отзывы других участников. А вау-докладом конференции был доклад Алексея Пименова о работе с противодействием изменений. Он, кстати, был признан лучшим докладом конференции. А меня впечатлило хорошее сочетание в одном докладе довольно широкого теоретического изложения и практических приемов, я тоже так хочу и буду стараться.
</p><p>Я тоже выступал на конференции с докладом <a href="https://mtsepkov.org/%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5:_%D1%87%D0%B5%D0%B3%D0%BE_%D1%8F_%D1%85%D0%BE%D1%87%D1%83_%D0%BE%D1%82_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_%D0%B8_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_(SQAdays-2023)" title="Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)"><b>Самоопределение: чего я хочу от жизни и работы</b></a>. По теме самоопределения у меня уже была серия докладов, но организаторы сказали, что потребность - все равно есть, и есть актуальные вопросы, не все из которых освещены в докладе. Например, пора ли самоопределяться? Потоvу что, оказывается, есть сейчас стереотип что место работы надо менять часто, и только человек освоился и начал расти, как он думает "что-то я засиделся, стало слишком спокойно" - и идет на новое место, хотя потенциал этого еще не исчерпан. Или другая ситуация: ты успешно сменил команду и специализацию, осваиваешься, идет тяжело. Как понять, это трудности адаптации, или не повезло с командой, или ты выбрал не свое дело? Или ты устал на проекте и хорошо бы сходить в отпуск, но через месяц-два сдача этапа: идти или подождать, как договариваться? И так далее. Многие из этих вопросов - про управление драйвом, а это - часть процесса самоопределение. И я постарался расширить доклад, добавив ответы на них. Презентация - на странице доклада, там же появится видео и есть ссылки на другие доклады и статьи по теме.
</p><p>А теперь - про другие доклады. Начну я с доклада Алексея Пименова, а дальше пойду по порядку.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B5.D0.B9_.D0.9F.D0.B8.D0.BC.D0.B5.D0.BD.D0.BE.D0.B2._.D0.AF_.D0.BF.D1.80.D0.B5.D0.B4.D0.BB.D0.B0.D0.B3.D0.B0.D1.8E_-_.D0.BE.D0.BD.D0.B8_.D0.BE.D1.82.D0.BA.D0.B0.D0.B7.D1.8B.D0.B2.D0.B0.D1.8E.D1.82.D1.81.D1.8F.21">Алексей Пименов. Я предлагаю - они отказываются!</span></h1>
<p><b>Превосходный доклад о психологических аспектах сопротивления изменениям и работе с ними</b>. Социальные аспекты сопротивления доклад не затрагивал, в вопросах они проявились, Леша отвечал и сказал, что об этом у нее есть отдельный доклад.
</p><p>Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.
</p><p>Питер Сенге писал: "люди любят изменения, люди не любят меняться самим. И если понять как мыслят люди - можно увидеть природу сопротивления. Для этого Алексей опирается на модель Канемана Думай медленно, решай быстро, Канеман выделил в мозгу две системы: быстрых решений и реакций, которую навал Система-1 и медленных размышлений, которую навал Система-2.
</p><p>Система-1 обучается многократным повторением, на личном опыте, поэтому обучается медленно, зато реагирует быстро и не энергозатратна. Система-1 работает при процессах, которые выполняются автоматически: при вождении автомобиля, у боксеров в бою, а достигается это повторением, но для мыслительных процессов эти механизмы тоже работают, мы можем отвечать или писать код тоже на автомате.
</p><p>Система-2 - логическое мышление, обучается через теорию и чужой опыт, по сравнению с ситемой-1 - быстро, на хорошем тренинге можно получить информацию, эквивалентную 2-3 года личного опыта и начать ее опрокидывать в практику за счет упражнений, но реагирует эта система медленно - размышление требует времени, и крайне энергозатратна.
</p><p>Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.
</p><p>Если говорить в позитиве, то и модель Маклина - вполне рабочая модель, если рассматривать ее как выделение логических уровней, подобно к тому, как мы выделяем логические уровни приложения (фронт-бэк-БД), при этом каждый уровень не просто обрабатывает запросы другого, а имеет собственные активные процессы, обращающиеся к другим. Схемы работы мозга, которые получаются на их основы, вполне совместимы с современными моделями работы мозга. Если интересует - я готов обсуждать подробнее. И модель Канемана тоже рабочая, она - функциональная, описываемые ей эффекты есть, а уж как она локализована в мозгу - вопрос отдельный, не следует путать функциональное и модельное деление системы, они отличаются. Когда нейрофизиологи предложат иную локализацию систем Канемана и уточнят их - будем ей пользоваться.
</p><p>И отдельное замечание про энергозатратность. Нейрон - это клетка, и как клетка он обладает постоянным потреблением АТФ, описываемое циклом Кребса, вариации в пределах 5%, тепловые карты возбуждения мозга показывают именно такие вариации. Но вот для взаимодействия с другими нейронами, размышления ему нужен дофамин, ресурс которого ограничен и в лимбической системе есть регулятор, направляющий его в части, управляющие движением, если ситуация предполагает, что организму придется драться или убегать, то есть в стрессе, или в неокортекс для спокойных размышлений. А так мозг не устает. Разработчик "устал" писать код и пошле "отдыхать" в Warcraft - мыслительных ресурсов эта игра требует не меньше, а иногда - больше. Просто система подкрепления перестала воспринимать написание кода как полезную деятельность и выдавать дофамин под нее.
</p><p>Последнее замечания как раз касается тезиса Алексея, что если человек - метеозависимый или мало спал, то для привычной механической работы, например, у токаря, проблем нет, только безопасность снижается, так как она требует включения Системы-2 для выработки реакции, а для разработчика или тестировщика это важно, он в результате просидел весь день и нифига не сделал. Связь более сложная, я лично писать и отлаживать код могу даже в уставшем состоянии, а вот сложные задачи проектирования или писать статьи надо на свежую голову.
</p><p>Возвращаюсь к конспекту. Есть борьба двух систем за ресурсы. Вы системой-1 ведете автомобиль, а системой-2 обсуждаете ремонт в квартире, вдруг на дорогу выбегает собака, контраварийная езда требует всех ресурсов, и Система-2 отключилась. И наоборот, он этот тест часто проводит: ходит с человеком кругами по залу и человек складывает двухзначные цифры, ок, потом предлагает умножать, простой пример - не проблема, а сложный - человек может пойти в отказ, но если начинает считать - останавливается, потому что система-2 забрала все ресурсы, на прогулку не осталось. При этом в подавляющем числе случаев побеждает система-1.
</p><p>Как это работает с изменениями? Вы приходите в команду, готовите логичные аргументы, рассчитываете на систему-2 - а они влетают в систему-1 и получаете фабрику гнилых отмазок. Почему? Любые новые роли атакуют идентичность человека. "Некогда объяснять, ты scrum-мастер" - а он PM, он знает кто оно такой, перспективы и так далее - много вопросов. Новая ответственность атакует чувство собственного достоинства и так далее. Люди чувствуют, что получат гораздо меньше, чем потеряют. Есть люди, которые за любой кипеж кроме голодовки - их 15-20% они всегда за. А остальные - видят проблемы и угрозы и консервативны.
</p><p>Что мы можем с этим сделать? Поскольку сопротивление - эмоционально, то нам надо эмоцию остановить. При чем быстро. А то он успел возразить, вы вступили в спор, а дальше, даже если логика у оппонента проявилась - ему уже надо признать, что он не прав, а это - снова эмоции.
</p><p>Принцип дзю-до: не спорим, а присоединяемся и ведем. "Так не работает, мы делали" - присоединяемся "да, не работает, я тоже пробовал, давай обсудим как у вас не работало и у меня, подумаем можно ли что сделать". Обсуждение переводит в логику, и потом уже выводим на конструктив. Когда проектируете изменения - попробуйте предсказать аргументы и понять, как будете присоединиться.
</p><p>Другой инструмент - перебить эмоцию более сильной: "если это не сделать нас всех уволят". Но надо быть хорошим психологом, потому что перебить надо именно эмоцией, и есть риски: если вы неверно попали - эмоция развивает, или человек согласиться ии пойдет другим путем: обидеться, уволиться и настроить против, или устроить итальянскую забастовку. Он этот метод не любит и не применяет, но видел людей, у которых он хорошо работает.
</p><p>Дальше - ответы на вопросы.
</p><p>Вопрос. Если команда против и выходит в саботаж, что делать?
Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.
</p><p>Что почитать? Есть хороший бизнес-роман Рей Иммельман "Босс бесподобный или бесполезный". Будете искать - есть еще книги с похожими названиями: "Хороший босс, плохой босс" и "Хороший плохой босс", они про другое, не путайте.
</p><p>Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".
</p><p>Вопрос. Есть предложения по изменениям, я их убедила, ввели изменения, а пошло не так и они оказались плохими. И тебе говорят "ты виновата". У него в голове ответ, что делать, чтобы не допустить: надо анонсировать изменения как гипотеза, и оформить "мы верим, что будем делать это и получим результат, поймем так-то, а если их не будем - будет откат". Сейчас, когда история уже произошла, надо самостоятельно повиниться: "да, облажались", а дальше: может, проблема, что только я обдумывала, надо месте и так далее, попробовать включить обвинителей в социальную группу.
</p><p>Вопрос. Есть системные администраторы на площадках "я не буду делать - не знаю", хотя на собеседованиях показывали. А другие - сидят в кабинеты и не выходят в поле. Что делать? Ответ: дело в авторитете руководителя, как его поднимать, если технических скилов недостаточно. Лайфхак: собрать группу, и сказать "такая задача - ваши предложения". У него есть игра: 3 стикера, довольная, нейтральная, недовольная. Выигрышная стратегия: хорошие расхватали, потом даешь недовольную, не доволен - какие предложения, и так далее - требуешь договариваться. Чтобы не выходить впозицию "я начальник - ты дурак", а это - не перспективно.
</p><p>Вопрос. При внедрении изменений сталкиваешься с манипуляторами, которые тоже давят на систему-1, эмоции. Как быть? Ответ: подумай, нужен ли такой вредитель в команде? А в моменте спроси при всех: "Какого результата ты хочешь добиться такими возражениями?" - это может рассыпать чистый деструктив, вывести в область конструктивных предложений.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.B0.D1.80.D0.B8.D0.BD.D0.B0_.D0.A2.D0.B0.D1.80.D0.B0.D1.81.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_SimbirSoft:_.D0.98.D0.BD.D0.B4.D0.B8.D0.B2.D0.B8.D0.B4.D1.83.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.BF.D0.BB.D0.B0.D0.BD_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F">Марина Тарасова из SimbirSoft: Индивидуальный план развития</span></h1>
<p>Доклад важен мне, потому что сам я буду выступать на связанную тему - о самоопределении и профессиональном росте. Мне доклад очень понравился. Он начался с важного тезиса: компании выгодно вкладываться в специалиста, чтобы он развивался, хотя при этом сотруднику надо будет больше платить, потому что в результате проект компании лучше двигается. Отмечу, что это не для всех компаний справедливо, есть компании, предоставляющие тестировщиков на аутсорсинг в определенной нише рынка, и если сотрудник слишком развивается, то для него не могут найти проект, надо менять компанию.
</p><p>Главное что дает индивидуальный план развития - визуализацию и прозрачность процесса. Чеканная формулировка: что визуализировано - достижимо, что достигнуто - достойно награды. По опросу аудитории, ИПР - не единственный способ, есть самостоятельное развитие с оценкой через внутреннюю оценку или контроферы и другие варианты.
</p><p>Парные профиты для сотрудника и руководителя: развитие навыка ускоряет проект, прозрачность процесса, визуализация цели и контроль развития важны обоим, аргументация при повышении зарплаты для сотрудника и прогноз финансов у руководителя, мотивация и вдохновение важны обоим.
</p><p>Первый шаг - определяем и фиксируем цели. Чаще всего у сотрудника не определенные желания, а вопрос: что надо сделать, чтобы вырасти, увеличить зарплату. И здесь вопрос коммуникации.
</p><p>Планы развития всегда включают soft skill, а не только hard. Не должно быть много: 1-2 hard + 1 soft. Откуда брать: из задач проекта, существующих проблем и потребностей улучшения, обратная связь от команды, будущие задачи - тренды и бизнес-цели проекта, опыт других, карьерное консультирование. Цели встраивают личное развитие в развитие проекта.
</p><p>Развитие soft skill можно делать через доп.активности на проекте: демо, ретро, лидство (наставничество, кураторство), ревью и внепроектные активности - митапы, конференции, статьи.
</p><p>Вопросы-помощники: зачем, хватает ли навыков для выполнения задачи, какие проблемы есть на проекте, какие задачи интересны?
</p><p>После целей: декомпозиция цели на задачи - как с user story, критерии успеха и сроки и контролируем процесс.
</p><p>Что делать, когда сроки сдвигаются? Задача не выполнена вообще, когда ничего не делали. Если делали - вопрос сколько сделали. Корректируем план, если не сделано. Вопрос - в чем не выполненная задача полезна для бизнеса? Если надо было запустить автоматизацию, а ты возишься с инфраструктурой - то награда будет маленькой.
</p><p>Цикл контроля общий: Цель - План и параметры - Мониторинг в точках контроля - Коррекция по результатам мониторинга.
</p><p>В точках контроля важно спросить: актуальны ли еще цели? продвигают ли задачи к цели? Решаются ли задачи? Не бойтесь сказать "нет", изменить планы. Не надо доедать кашу до конца, если она стоит в горле.
</p><p>Что делать, чтобы сотрудники хотели составить ИПР? Покажите своим примером. Я поехала выступать на конференцию - публикую фотки, потом расскажу про доклад, сотрудников тоже может вдохновить, они захотят выступить. Еще она сама каждый квартал защищает производственные цели перед топами, и их рассказывает сотрудникам - они могут помочь.
</p><p>Про мотивацию есть книга Светлана Иванова "Мотивация на 100% - где у нее кнопка". Преподнесение информации - идеальна. Я, правда, тут хочу предостеречь: есть другая книга Шпренгер "Мифы мотивации", где автор разбирает все известные схемы мотивации и показывает, что они ведут к деградации в долгую. Книга - старая, но я критикуемые методы видел и в свежих, люди работают в короткую. Так что полезно самим соотнести перед применением.
</p><p>Что делать, когда берут задачи и не делают? В точках контроля: "много работ на проекте" и т.п. Это прокрастинация, он не принимает задачи.Откуда взять ресурсы? Нет ответа на этот вопрос. Про тайм менеджмент рассказывать не будет. Мы взрослые и должны сами настраивать.
</p><p>Поведение итогов: фиксация результатов, официальная встреча - рассказ, анализируем что удалось и что не удалось и почему, планируем следующую итерацию. Аплодисменты, похвала, наград - обязательно.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.B8.D1.82.D0.B0.D0.BB.D0.B8.D0.B9_.D0.A1.D1.82.D0.B0.D1.80.D0.BE.D1.81.D1.82.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.9F.D0.A1.D0.91._.D0.92_.D1.87.D1.91.D0.BC_.D0.B8.D0.B7.D0.BC.D0.B5.D1.80.D1.8F.D1.8E.D1.82.D1.81.D1.8F_.D0.B8.D0.BD.D0.B6.D0.B5.D0.BD.D0.B5.D1.80.D1.8B_.D0.BF.D0.BE_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8E">Виталий Старостин из ПСБ. В чём измеряются инженеры по тестированию</span></h1>
<p>Хороший доклад о том, как мониторинг сам по себе улучшает ситуацию, потому что проблемы становятся явными. У них количество людей сильно возросло, и они решили ввести метрики, чтобы понимать, кто и что делает, работы нет или ее не видно, опасения, что метрики покажут не адекватную картину, понятное отношение сотрудников, которые не хотят чтобы их мерили, потому что и так работают хорошо. И они решили двигаться, не смотря на опасения. В презентации был чек-лист идеальной метрики и полный набор метрик, который они используют. И подробно раздирались метрики для ручного регресса, который является дорогим процессом - 27 тестировщиков + капитан + команда разработки 3.5 дня на первую итерацию. Тест кейсы распределялись по тестировщикам автоматически равномерно по оценке трудоемкости, дальше тестировщики их выполняли, если кто-то не успевал - товарищи ему помогали, а выполнение тест-кейсов фиксировалось. Метрики позволили увидеть, кто именно из тестировщиков столкнулся с наибольшими проблемами и дальше поговорить, чтобы эти проблемы увидеть и решить. Из интересного: выяснилось, что алгоритм распределения тест-кейсов реально распределяет их неравномерно, выявились тест-кейсы с неверной оценкой, увидели, что процесс актуализации тест-кейса не работает, а он - дорогой. В целом был получен результат, время первой итерации сократилось в 1.5 раза, с 28 до 19 часов, и дальше это было стабильно. Они продолжают работать по выявленным проблемам. А потом будет следующий такт.
</p>
<h1><span class="mw-headline" id=".D0.A2.D0.B0.D0.B8.D1.81.D0.B8.D1.8F_.D0.A2.D0.BE.D0.BB.D1.81.D1.82.D1.83.D0.BD.D0.BE.D0.B2.D0.B0_.D0.B8_.D0.95.D0.BB.D0.B5.D0.BD.D0.B0_.D0.9A.D0.BE.D1.80.D0.B5.D0.BD.D0.B5.D0.B2.D0.B0_.D0.B8.D0.B7_VK_Tech._.D0.9F.D1.80.D0.B5.D0.BE.D0.B4.D0.BE.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.82.D1.80.D1.83.D0.B4.D0.BD.D0.BE.D1.81.D1.82.D0.B5.D0.B9_.D0.BA.D1.80.D0.BE.D1.81.D1.81-.D0.BF.D1.80.D0.BE.D0.B4.D1.83.D0.BA.D1.82.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F:_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4.D1.8B.2C_.D0.BB.D0.B0.D0.B9.D1.84.D1.85.D0.B0.D0.BA.D0.B8_.D0.B8_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82.D1.8B">Таисия Толстунова и Елена Коренева из VK Tech. Преодоление трудностей кросс-продуктового тестирования: подходы, лайфхаки и инструменты</span></h1>
<p>Рассказ про VK workspace - коммуникационная платформа для бизнеса: teams, почта, календарь, мессенджеры, диск и так далее. Пользователи воспринимают продукт как целое, хотя могут пользоваться отдельными частями. И там появляются кросс-продуктовые фичи, которые интегрированы более чем в одном продукте и должны быть представлены единообразно. Разработкой занимается несколько команд или несколько участников из этих команд. И при этом всегда возможны не стыковки из-за несогласованных действий команд. Проблема понятная, и решения, в общем, тоже понятные - нужна координация и согласованность процессов, и это надо выстроить.
</p><p>Для координации:
</p>
<ul><li> назначить одного координатора за каждую фичу, он отвечал целиком, обычно один из тимлидов разработки</li>
<li> единая страница в конфлюенсе по фиче - собраны задачи, этапы, статусы</li>
<li> регулярные синки с привлечением ответственных из команд</li>
<li> особое внимание - выкатка в прод: фиксация договоренностей, все задачи фиксируются в jira и их статус виден </li>
<li> если у команд конфликт приоритетов - решают продукты, они договариваются</li>
<li> бывает, что сроки не выдерживают - тогда эскалация, но тут сильно помогают статусы, дают своевременный сигнал </li>
<li> защита архитектуры - представители от каждой продуктовой команды, нет координатора.</li></ul>
<p>А дальше следующий уровень, различие ценностей, процессов и ожиданий.
</p>
<ul><li> Одной команде важно качество продукта, а другой - сроки</li>
<li> Надо выработать правила общения, договориться об определенных вещах и соблюдать договоренности.</li>
<li> Определить ситуации, когда собираются звонки.</li>
<li> Разные команды работают в разных процессах: Scrum, Kanban, собственный процесс, может быть несколько досок, а не одна. Они анализировали различия, для выравнивания одна команда взяла часть процессов у соседей и адаптировали.</li>
<li> Организовать agile-практики для кросспродуктовой команды по фиче: ретро, груминг. И надо синхронизировать ожидания, так как в разных командах эти мероприятия делают по-разному.</li>
<li> Одной команде важно тестировать до предпрода, а другой - только на нем из-за особенностей конфигурации - надо найти решение, по факту сделали отдельные стенды.</li></ul>
<p>Казалось бы, все понятно, но далеко не всегда это делают и это - боль. Это было видно по реакции зала.
</p>
<h1><span class="mw-headline" id=".D0.98.D0.B2.D0.B0.D0.BD_.D0.96.D0.B5.D0.BB.D0.B5.D0.B7.D0.BA.D0.BE.D0.B2_.D0.B8_.D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B5.D0.B9_.D0.9A.D0.BE.D0.B6.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.9F.D0.A1.D0.91._.D0.92_.D1.81.D1.82.D1.80.D0.B0.D0.BD.D0.B5_.D0.BD.D0.B5.D0.B2.D1.8B.D1.83.D1.87.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.83.D1.80.D0.BE.D0.BA.D0.BE.D0.B2.2C_.D0.B8.D0.BB.D0.B8_.D0.BA.D0.B0.D0.BA_.D1.81.D0.BE.D0.B7.D0.B4.D0.B0.D0.B2.D0.B0.D0.BB.D0.B0.D1.81.D1.8C_.D1.88.D0.BA.D0.BE.D0.BB.D0.B0_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.9F.D0.A1.D0.91">Иван Железков и Алексей Кожин из ПСБ. В стране невыученных уроков, или как создавалась школа тестирования ПСБ</span></h1>
<p>Тотальный дефицит привел к тому, чтобы создать школу обучения новичков внутри. Потому что программы обучения на рынке очень слабо коррелируют с потребностями. Когда вы обучаете для себя - можно получить тех, кто нужен. И был короткий рассказ, как они это сделали.
</p>
<ol><li> Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.</li>
<li> Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов</li>
<li> Опишите роль - кто должен получиться.</li>
<li> Разработайте контент.</li>
<li> Запустите обучение.</li></ol>
<p>Про 2 и 3 важно: обучение под себя, поэтому взяли внутренний фреймворк разработки банка и пометили артефакты, которые разрабатывают тестировщики. Это - основные темы, из них следуют знания и компетенции для них - получается контент. Он не висит в воздухе, он привязан к реальному процессу банка, и артефакты создаются не модельные, а реальные.
</p><p>Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.
</p>
<ol><li>. Первичная оценка и передача знаний</li>
<li> Создание рабочего артефакта</li>
<li> peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга</li>
<li> Оценка экспертами результата</li></ol>
<p>Этап peer2peer оказался очень ценным, студенты снимают большое количество ошибок, и еще закрепляют знания, что сильно разгруает экспертов на следующем этапе.
</p><p>По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.
</p><p>Результаты:
</p>
<ul><li> частичное решение проблемы подбора через обучения молодых - джун+, подтверждено</li>
<li> снижение текучки - эксперты смогли проявить себя по-другому</li>
<li> сокращение затрат на обучение за счет привлечения внутренних экспертов</li></ul>
<p>В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B0.D1.81.D1.82.D0.B0.D1.81.D0.B8.D1.8F_.D0.97.D0.BE.D0.BB.D0.BE.D1.82.D1.8B.D1.85_.D0.B8.D0.B7_2GIS._.D0.A2.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BD.D0.B0_.D0.BB.D0.B5.D1.82.D1.83:_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B9_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4_.D0.BA_.D0.B2.D0.B8.D0.B7.D1.83.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.BC.D1.83_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8E">Анастасия Золотых из 2GIS. Тестирование на лету: новый подход к визуальному тестированию</span></h1>
<p>Продукт Otello: web, мобилки, множество платформ, виджеты для встройки. Среднее время разработки и доставки фичи 5 дней, смесь ручного и автоматизированного тестирования, в автотестах - случайные разрешения для устройств и случайные данные с генерацией на лету. Их команда тестирует фронт, бэк и интеграция - через моки. Команда решала задачу расширить автотесты, добавив проверку по скриншотам, так как проверка на всех платформах и разрешениях - трудоемкая. Классический подход основан на том, что ты держишь эталонные скриншоты и сравниваешь с ними результаты, которые получил при прогоне теста. В их случае возникают сложности: эталонные скриншоты надо обновлять вручную, и не очевидно, что это даст меньше работы, чем ручное тестирование, к тому же на скриншоте - фиксированное разрешение и данные, нельзя использовать случайную генерацию.
</p><p>Поэтому они реализовали комбинированную конструкцию: сделали повторяемую генерацию данных с использованием random seed, что позволяет прогнать один и тот же тест на проде и на тестовом стенде, и снять скриншоты, которые должны совпасть там, где функционал не менялся. Снятие скриншотов встроили в систему функциональных тестов, а вот их сравнение запускается отдельно, и не совпадение на останавливает конвейер поставки, а разбирается вручную. Со снятием скриншотов есть отдельные проблемы, когда есть анимация и дочитка блоков, их не разбирали, а дали ссылку на другой доклад. Сравнение идет по хэшу, так как основная масса совпадает и это - быстро, а если хэш не совпал - используют pixelmatch, и результат показывают три картинки: тестовую, эталонную и расхождения. Понятно, что есть фичи с редизайном интерфейса, когда скриншоты с прода и теста точно не совпадают, они помечены отдельно, с учетом номеров версий, и это оставлено на ручное тестирование - пока функционал не докатят до прода.
</p><p>В целом - заработало, были оценки по ускорению тестирования. А еще такие тесты позволили поймать некоторые косвенные эффекты, когда в мобилки иногда просачиваются эффекты, которые должны работать только в web, или когда появляются дополнительные информационные блоки, которых не должно быть.
</p>
<h1><span class="mw-headline" id=".D0.AD.D0.BC.D0.B8.D0.BB.D1.8C_.D0.91.D0.B0.D1.80.D0.BB.D1.8B.D0.B1.D0.B0.D0.B5.D0.B2_.D0.B8.D0.B7_Doubletapp._.D0.9D.D0.B0_.D1.81.D1.82.D0.B0.D1.80.D1.82..._.D0.92.D0.BD.D0.B8.D0.BC.D0.B0.D0.BD.D0.B8.D0.B5..._.D0.9D.D0.B0.D0.B3.D1.80.D1.83.D0.B6.D0.B0.D0.B5.D0.BC.21">Эмиль Барлыбаев из Doubletapp. На старт... Внимание... Нагружаем!</span></h1>
<p>Короткий рассказ про организацию нагрузочного тестирования. Потому что важно не просто дать нагрузку - надо дать разную нагрузку для определения разных характеристик. Для начала надо понять, какие запросы будут давать основную нагрузку, обычно они составляют малое количество функционала, и тестировать надо именно их, а не по площади. Далее даем нагрузку и делим три зоны: слабую, когда потребляемые ресурсы постоянны, а время отклика около нуля и не растет, основную, в которой ресурсы растут линейно и рост времени отклика примерно линеен по нагрузки, и стрессовую, когда мы постепенно приближаемся к максимуму нагрузки. В целом у нас - образная кривая, и эти зоны - ее деление. В примере пределом было 100 rps, слабая дона 0-40, рабочая 40-80 и стрессовая от 80. Дальше сравниваем вычисленную нагрузку с ожидаемой. Если ожидаемая ниже - то можно сокращать ресурсы. Если больше - нужно масштабирование, горизонтальное (больше нод) или вертикальная (мощность ноды). И делаем три вида тестов: под рабочей нагрузкой проверяем стабильность работы, стрессовое для проверки работоспособности под большой нагрузкой и долгое (8+ часов) тестирование под низкой нагрузкой, чтобы увидеть, что ресурсы сервиса не текут. Еще нужно тестирование всплеска, обычно есть события, когда ожидается всплеск нагрузки, вплоть до перегрузки, и надо проверить, что когда оно проходит, сервис возвращается к рабочим параметрам. Помимо этого нужно тестирование объема, что накопление данных не повышает время отклика. И в конце доклада - оформление отчета и рекомендации lzk начинающего, но это - стандартно.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D1.84.D0.B8.D1.81.D0.B0_.D0.9B.D0.B0.D0.B2.D1.80.D0.BE.D0.B2.D0.B0._.D0.9F.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81.D0.B0_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BF.D0.BE_.D0.BF.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D0.BC.D0.B0.D0.BC">Анфиса Лаврова. Проектирование процесса тестирования по проблемам</span></h1>
<p>Любопытный доклад об успешном сокращении регресса от 6 недель до 2, а далее до одной, с уменьшением числа занятых тестировщиков с 5 до 3, то есть трудоемкость уменьшилась в 10 раз. Что важно - были разобраны неверные шаги, которые предприняли сначала. А также показано применение различных методов - организации процессов, анализ причин на простых примерах. Так что в целом - успех. А сами неверные шаги служат хорошей иллюстрацией того, как применение стереотипных ответов может оказаться неверным в конкретной ситуации.
</p><p>Сначала была часть про процессы с простой схемой: процесс есть способ организации деятельности, с помощью которого в ответ на некоторую потребность гарантировано достигается результат с понятными ресурсами и способами управления: потребность -> (управление, ресурс) -> результат. Организация процесса оберегает от ошибок и сберегает ресурсы. Пример из жизни: у них не было процесса превращения запроса от клиента, которые поступал на общий почтовый ящик поддержки в тикет в таск-трекере: ящик смотрели все сотрудники, чтобы обеспечить более быструю реакцию, но кто берет задачу - определено не было, поэтому иногда создавали два тикета, а иногда - не одного. Решили, что будет один постоянный ответственный за разбор ящика. Понятно, что есть и другие варианты, например, регулятрное дежурство, или договоренность о пометке письму в ящике, если создан тикет и так далее.
</p><p>Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.
</p><p>Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Когда Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.
</p><p>Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.
</p><p>Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увеличилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.
</p><p>После этого решила, что нужен анализ. Есть два метода: дерево текущей реальности и 5 почему. Дерево попробовали - сложно, а 5 почему у них сработал. На слайдах и в рассказе было объяснение, что именно они увидели: они прогоняют все 5000 тестов для всех 3 баз платформ, в то время, как часть из тестов проверяют фронт, UI, который для всех платформ одинаков, а часть - проверяют еще и бизнес-логику, которая может различаться, так как для каждой платформы бэк имеет свою реализацию. Очевидно, что тесты, которые исключительно проверяют фронт достаточно прогнать один раз. И они разметили тесты, сократив время прогона.
</p><p>Кроме того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.
</p><p>Что интересно, мотивация сотрудников в результате тоже выросла. Долгий регресс с механическим повторением кейсов их сильно демотивировал. Так что заодно была решена вторая проблема.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B4.D1.80.D0.B5.D0.B9_.D0.91.D1.80.D0.BE.D0.B2.D0.BA.D0.BE_.D0.B8.D0.B7_.D0.90.D0.B2.D0.B8.D1.82.D0.BE._.D0.9E.D1.86.D0.B5.D0.BD.D0.BA.D0.B0_.D1.80.D0.B8.D1.81.D0.BA.D0.BE.D0.B2_.D0.B2_.D1.80.D0.B0.D0.B7.D1.80.D0.B5.D0.B7.D0.B5_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D0.B8_.D0.BA.D0.B0.D1.87.D0.B5.D1.81.D1.82.D0.B2.D0.B0_.D0.BF.D1.80.D0.BE.D0.B4.D1.83.D0.BA.D1.82.D0.B0">Андрей Бровко из Авито. Оценка рисков в разрезе модели качества продукта</span></h1>
<p>Интересный доклад с приземлением общей теории управления рисками к тестированию продукта. На хорошем уровне, со ссылками на стандарты, это было в презентации, но я записал не все. Но, к сожалению, в докладе не было приземления этой теории на практику в разных вариантах, и каких-то не очевидных примеров применения, тонкостей. Хотя некоторое количество примеров - было. Но такое представление все равно полезно - чтобы ничего не забыть, и чтобы показать соответствие стандартам, это может быть важно для проекта.
</p><p>Риск-менеджмент работает с реализацией позитивных и негативных сценариев, но обычно рассматривают только негативные. Общая схема: (Оценка риска: идентификация, анализ, определение степени риска) -> Обработка риска, а снаружи - цикл: область применения -> коммуникация -> отчетность -> мониторинг.
</p><p>Уровень риска: вероятность * влияние, оцениваем по трем градациям низкий-средний-высокий по каждой оси. Для программы надо описать требуемый профиль риска, стандартного нет, и это понятно: для медицинских программ одни требования, для информационных сайтов - другие, для систем, от которых зависит исполнение бизнес-процесса - третьи и так далее.
</p><p>Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.
</p><p>Виды риска:
</p>
<ul><li> риск проекта: персонал, поставщики, организация, лицензии, техника</li>
<li> Риск продукта - опыт пользователя: функциональность, ошибки и та далее.</li></ul>
<p>Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.
</p><p>Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.
</p><p>Делаем чек-лист. На слайде был скриншот из системы работы с рисками, Слева - виды тестирования, справа - список рисков, их вероятность и влияние.
</p><p>Список рисков целесообразно вести не для каждого проекта, а общий, а для проекта из него делать выборку и описывать параметры. У них есть корпоративный список рисков и процесс ведения: изменения инициируют тестировщики, плюс ведется регулярный пересмотр актуальности и оценки рисков.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D1.82.D0.BE.D0.BD_.D0.A1.D0.B5.D0.BC.D0.B5.D0.BD.D1.87.D0.B5.D0.BD.D0.BA.D0.BE._.D0.A7.D0.B8.D1.81.D1.82.D0.B0.D1.8F_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B0_.D0.B2_.D0.BA.D0.BE.D0.BD.D1.82.D0.B5.D0.BA.D1.81.D1.82.D0.B5_.D0.90.D0.B2.D1.82.D0.BE.D0.BC.D0.B0.D1.82.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D0.B8_.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F">Антон Семенченко. Чистая архитектура в контексте Автоматизации тестирования</span></h1>
<p>Это был доклад о том, как архитектура влияет на качество продукта и тестирование. Антон ведет фундаментальную проработку темы и сейчас материала на 16 часов. Он обещал выложить его в понедельник, а сам доклад был обзорным рассказом без презентации. Но главная цель - не передать содержание, а показать тестировщикам, что им надо не дистанцироваться от архитектурной работы, не принимать разработанную архитектуру как данность, а активно участвовать в работе над архитектурой. Дальше - тезисы, записанные с голоса.
</p><p>Смысл Архитектуры - снижение стоимости продукта на всех этапах, включая тестирование и эксплуатация.
</p><p>Отделить архитектуру от дизайна невозможно ни в строительстве, ни в ИТ. Дверная ручка - - дизайн, фундамент здания - архитектура, а декоративные колонны - что? В ИТ тоже самое, есть design pattern и architecture pattern, но многое на стыке. К архитектуре точно относится принципы деления на компоненты и организации взаимодействия между ними, к дизайну - детали внутреннее устройство компонент, а вот выделение отдельных компонент или принципы проектирования компонент - на стыке.
</p><p>Классическая архитектура включает три уровня: UI, бизнес-логика и БД. Но если у нас бизнес-логика является основой, есть сменная БД и интерфейс, управляемый бизнес-логикой, то фактически у нас при бизнес-логике есть два плагина: UI и БД. Но может быть и по-другому. SOA - лишь часть архитектуры, она говорит о способах пересечения границы компонента чтобы обеспечить взаимодействие.
</p><p>Роберт Мартин. Clear Architecture. В одной из глав он приводит 4 варианта архитектуры: трехкомпонентная, функционально-разделенная, сущность-плагины и еще один. При этом в коде - одинаковое количество классов и интерфейсов. Получается, что логически ошибки везде одинаковы - раз речь идет о коде. Но раз они одинаковы, то архитектура не влияет на тестируемость? Но опыт говорит о другом. Проверки в коде - разработчиками в unit-test, и если это делают - то ошибки должны быть найдены. Тогда где влияние архитектуры?
</p><p>Юнит-тесты, code review и многие другие практики. И QA должны понимать эти аспекты и участвовать в проработке, вписывать их в свою стратегию тестирования. И дальше фокусироваться на пересечения границ.
</p><p>Автотесты - куда встраивать: есть unit, api, есть функциональные. Куда ставить? Автотесты - тоже часть архитектуры системы в целом. Чтобы тестировать слои изолировано, полезно встраивать промежуточные слои: command-line, api для тестирования. Это позволяет статьи независимым от того, что тестируешь на этапе подготовки данных для конкретного теста, сделать тесты более изолированными. Если в приложении часто возникают проблемы безопасности - давайте вынесем их за скобки функциональных тестов и будем проверять их отдельно, а для этого сделаем способ работы, при котором "все позволено" - но отдельным модулем, который точно не выкатим на прод.
</p><p>Design pattern humble object. Скромный объект. Разобьем сложный объект на два, разделим сложность. Так в свое время появился MVC: разделим на клиенте визуальное представление (View) и бизнес-логику (Controller). Потом еще был Module-View-Presenter, MVVM - они тоже делили сложность. Декомпозиция уменьшает сложность разработки, обеспечивает независимое тестирование и локализации ошибки. База данных. СУБД - plugin для приложения. ORM - плугин для плугина.
</p><p>Разрабатывали монолит, стал монстром, решили декомпозировать - куча проблем с тестированием. Это проблема архитектуры, но в других терминах. Потому сделали два шага в одном: изменили архитектуру и поменяли реализацию. Если монолит внутри структурирован - разбит на компоненты, используется dependency rules и разные методы пересечения границ - фабрики, IoC и другие то он потом хорошо развалится на микросервисы. А если микросервисы декомпозированы неверно, то ошибки и не кончатся.
</p><p>Надо понимать, что есть архитектура, принимать участие в архитектурных диспутах и ее построении - чтобы архитектура была удобной для целей тестирования. Принципы архитектуры похожи: они так или иначе определяют способы разделения на компоненты и способы взаимодействия между ними - границы и способы пересечения.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-12-05:_%D1%81%D1%82%D0%B0%D1%82%D1%8C%D1%8F_%D0%A1%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D1%8B_%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F:_%D1%81%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D1%83%D0%B5%D1%82_%D0%BB%D0%B8_%D1%81%D0%B2%D1%8F%D0%B7%D1%8C_%D0%BC%D0%B5%D0%B6%D0%B4%D1%83_DDD_%D0%B8_%D0%9E%D0%9E%D0%9F2023-12-05: статья Способы отображения: существует ли связь между DDD и ООПMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-12-05T13:37:50Z2023-12-05T13:37:50Z<p>В обсуждении докладов на конференции AnalystDays проявился вопрос о связи DDD и ООП. Для меня эта связь очевидна, и для Эрика Эванса она тоже была такой, это видно из его книги и вполне естественно: ООП в начале нулевых тогда был мейнстримом. А вот сейчас, когда основой архитектуры являются микросервисы, то фокус может быть на едином языке и структурировании предметной области через выделение ограниченных контекстов и сопряжение между ними, и в этом случае связь с ООП становится не столь явной. Однако, для использования всегда полезно представлять метод в целом, включая тот контекст, который был очевиден, когда метод создавался и потому не акцентирован явно. Поэтому родилась <b>статья <a rel="nofollow" class="external text" href="https://habr.com/ru/companies/custis/articles/774644/">Способы отображения: существует ли связь между DDD и ООП</a></b> в которой я не только рассказываю историю, но и говорю про современные практики применения.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-12-03:_Teamlead_-_%D0%B4%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%D1%8B_%2B_%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B5_%3D_%D0%B2%D0%B0%D1%83!2023-12-03: Teamlead - доклады + общение = вау!MaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-12-03T08:21:39Z2024-01-29T07:14:10Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Сразу после #highload был #Teamlead, в которой были #KnowledgeConf и #TechLead. 1800+ участников в Сколково, после 3600 на Highload было свободно, и треков всего 9, а не 13. Атмосфера была другая, но тоже качественная, много докладов и общения. Был вау-доклад Анны Обуховой, у Анны всегда хорошие доклады, я ее много слышал на разных конференциях, но этот — реально вау. Анна рассказывала про нейрофизиологию креативного мышления. Еще хочу отметить доклад Евгения Идзиковского, который дал простую технику работы со страхом и другими эмоциями. Думаю, именно доклады Анны и Жени сделали мое вау-впечатление от конференции. И любопытный доклад Яны Фёдоровой про ИмаДЖУНариум — представление джунов о лидах, в основе которого лежит исследование, обработка 100 интервью, а не просто личный опыт или умозрительная концепция и Руслана Сафина про покрытие тестами архитектуры, что позволяет сделать подход Arcitecture as code.
</p><p>В число значимых докладов конференции я нескромно зачислю свой доклад <a href="https://mtsepkov.org/%D0%9C%D0%B5%D0%BD%D1%8F%D1%8F_%D1%81%D0%B5%D0%B1%D1%8F_%D0%B8_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_-_%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%B9_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE:_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(Teamlead-2023)" title="Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)"><b>Меняя себя и других — понимай устройство: инженерная модель личности</b></a>. У меня получилось собрать архитектурную схему личности, которая позволяет сшивать нейрофизиологические и психологические модели, понимать конструкцию комплексно. Ценность — примерно как для архитектурной модели legacy-системы. В принципе развивать можно и без нее. Но если модель есть — это сильно помогает разбираться. На конференции я ее рассказал, и мы много обсуждали в кулуарах до доклада и после нее, что помогло мне самому продвинуться. Презентация — выложена, и она достаточно подробна. Видео пока нет, но у меня есть статья <b><a href="https://mtsepkov.org/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8" title="Модель личности" class="mw-redirect">Модель личности</a></b>, с которой я стартовал доклад, и свежий доклад <a href="https://mtsepkov.org/%D0%AF_%D0%B8_%D0%BC%D0%BE%D0%B8_%D0%B0%D0%B2%D0%B0%D1%82%D0%B0%D1%80%D1%8B_%D0%B2_%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B0%D0%BA%D0%BB%D0%B5_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_(%D0%9F%D0%98%D0%A0-2023)" title="Я и мои аватары в спектакле жизни (ПИР-2023)">Я и мои аватары в спектакле жизни (ПИР-2023)</a> с опубликованным видео, куда вошла значительная часть материала. И я планирую статью о модели доработать и актуализировать, но это, наверное, займет пару месяцев — там много материала.
</p><p>А теперь — конспекты докладов, которые я начну с двух перечисленных, а потом — остальные в порядке выступлений. Я хочу напомнить. что был только на одном треке из 9, а на части слотов предпочел общение, так что представлена лишь малая часть.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Сразу после #highload был #Teamlead, в которой были #KnowledgeConf и #TechLead. 1800+ участников в Сколково, после 3600 на Highload было свободно, и треков всего 9, а не 13. Атмосфера была другая, но тоже качественная, много докладов и общения. Был вау-доклад Анны Обуховой, у Анны всегда хорошие доклады, я ее много слышал на разных конференциях, но этот — реально вау. Анна рассказывала про нейрофизиологию креативного мышления. Еще хочу отметить доклад Евгения Идзиковского, который дал простую технику работы со страхом и другими эмоциями. Думаю, именно доклады Анны и Жени сделали мое вау-впечатление от конференции. И любопытный доклад Яны Фёдоровой про ИмаДЖУНариум — представление джунов о лидах, в основе которого лежит исследование, обработка 100 интервью, а не просто личный опыт или умозрительная концепция и Руслана Сафина про покрытие тестами архитектуры, что позволяет сделать подход Arcitecture as code.
</p><p>В число значимых докладов конференции я нескромно зачислю свой доклад <a href="https://mtsepkov.org/%D0%9C%D0%B5%D0%BD%D1%8F%D1%8F_%D1%81%D0%B5%D0%B1%D1%8F_%D0%B8_%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85_-_%D0%BF%D0%BE%D0%BD%D0%B8%D0%BC%D0%B0%D0%B9_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE:_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8_(Teamlead-2023)" title="Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)"><b>Меняя себя и других — понимай устройство: инженерная модель личности</b></a>. У меня получилось собрать архитектурную схему личности, которая позволяет сшивать нейрофизиологические и психологические модели, понимать конструкцию комплексно. Ценность — примерно как для архитектурной модели legacy-системы. В принципе развивать можно и без нее. Но если модель есть — это сильно помогает разбираться. На конференции я ее рассказал, и мы много обсуждали в кулуарах до доклада и после нее, что помогло мне самому продвинуться. Презентация — выложена, и она достаточно подробна. Видео пока нет, но у меня есть статья <b><a href="https://mtsepkov.org/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8" title="Модель личности" class="mw-redirect">Модель личности</a></b>, с которой я стартовал доклад, и свежий доклад <a href="https://mtsepkov.org/%D0%AF_%D0%B8_%D0%BC%D0%BE%D0%B8_%D0%B0%D0%B2%D0%B0%D1%82%D0%B0%D1%80%D1%8B_%D0%B2_%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B0%D0%BA%D0%BB%D0%B5_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_(%D0%9F%D0%98%D0%A0-2023)" title="Я и мои аватары в спектакле жизни (ПИР-2023)">Я и мои аватары в спектакле жизни (ПИР-2023)</a> с опубликованным видео, куда вошла значительная часть материала. И я планирую статью о модели доработать и актуализировать, но это, наверное, займет пару месяцев — там много материала.
</p><p>А теперь — конспекты докладов, которые я начну с двух перечисленных, а потом — остальные в порядке выступлений. Я хочу напомнить. что был только на одном треке из 9, а на части слотов предпочел общение, так что представлена лишь малая часть.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.BD.D0.B0_.D0.9E.D0.B1.D1.83.D1.85.D0.BE.D0.B2.D0.B0._.D0.9A.D0.B0.D0.BA_.D1.81.D1.82.D0.B8.D0.BC.D1.83.D0.BB.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D1.82.D1.8C_.D0.BA.D1.80.D0.B5.D0.B0.D1.82.D0.B8.D0.B2.D0.BD.D0.BE.D0.B5_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B2_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D0.B5_I.D0.A2-.D1.81.D0.BF.D0.B5.D1.86.D0.B8.D0.B0.D0.BB.D0.B8.D1.81.D1.82.D0.BE.D0.B2">Анна Обухова. Как стимулировать креативное мышление в команде IТ-специалистов</span></h1>
<p>Вау-доклад Анну Обуховой о нейрофизиологических механизмах креативного мышления на кейсе создания креативной команды, успешно решившей реально крутую инновационную задачу. Доклады Анны всегда превосходны, но тут было именно вау.
</p><p>Кейс. Крупная в масштабах страны корпорация, условно нефтегазтяжмаш со своими заводами. К ней прилетел черный лебедь. Вернее серенькая уточка, типа зимой выпал снег, не ожидали. Появилось оборудование, которое позволило компаниям меньшего размера делать аналоги продуктов корпорации, и эти компании съели весь высокомаржинальный рынок. Заводы у корпорации — остались, но там массовая продукция с низкой маржинальностью. Задача — сделать креативную команду, которая придумает выход из этой ситуации, сделает новый продукт или что-то похожее. При том, что последний новый продукт корпорация делала 10 лет назад.
</p><p>Анна сказала, что сделать может, она понимает механизмы. Но их будут все ненавидеть — потому что дресс-код, дисциплина и дедлайны гробят креативность сразу. Потому что нормальное состояние творческого человека — постоянное легкое счастье. И люди не будут ходить в офис, будут работать отдельно, это — полгода минимум, потому что месяца три креативность надо прогревать, для этого ездить на все конференции, и никаких гарантий результата нет. Топы заказчика согласились.
</p><p>Кто был в команде?
</p>
<ul><li> Вася — самый умный. Без дураков, не на ровном месте. У наработано много шаблонов, они хорошие и позволяют решать задачи. И он не слишком любит ошибаться сам, высмеивает ошибки других, и не очень любит Петю.</li>
<li> Катя — недавно пришла, не знает местных правил, мозг занят адаптацией, она понимает, что еще не своя. Не уверенна решениях, боится Васю.</li>
<li> Петя — балагур, умеет порождать новое и разное, не боится высказывать оригинальное, превращать все в анекдоты. И это не всегда во-время, оттягивает интерес других, может их обижать. И с Васей отношения не слишком хорошие.</li>
<li> Алиса — классная, даешь задание — и сразу бежит выполнять, не боится теребить людей, вижу цель — не вижу препятствий. Но тревожная, быстро истощается.</li></ul>
<p>Почему команда именно такая было за рамками рассказа, думаю, для этого были основания.
</p><p>Кто из них самый креативный? Ответ — никто, потому что креативность — комплексная штука, которой никто из них не обладает. У Васи слишком много шаблонов и боязнь ошибки, Петя свои идеи не умеет доводить до решения, у Алисы — решение задач, а не мышление, а Катя в стрессе и мышление блокировано. Тем не менее, сделать из них креативную команду поучилось.
</p><p>Что же такое креативность? Методика основана на исследованиях американского института нейролидерства.
У мозга есть три сети:
</p>
<ul><li> <b>Salience network</b> — сеть выявления значимости: реакция на внешние стимулы, модель Я, управление вниманием.</li>
<li> <b>Default network</b> — сеть пассивного режима. C ней нельзя говорить, нельзя дать задания, она сама варит социальные отношения приматов. Кто-то на тебя посмотрел — и она интерпретирует. Сеть выявления значимости — помогает, интерпретирует лица. Виртуальные образы, мысли, творчество, внутренний диалог.</li>
<li> <b>Executive network</b> — центральная исполнительная сеть: префронтальная кора, удержание фокуса деятельности при целенаправленных рассуждениях и выполнении задач, логическое мышление. Посчитайте пальцы: пока считаете — ни о чем не думаете.</li></ul>
<p>Как работает мышление?
</p>
<ul><li> Все начинается с salience network — выявление значимости. Она почувствовала голод.</li>
<li> Default network предлагает способы, говорит: давай поедим, давай в магазин сходим, давай доставку или еще что-то сделаем.</li>
<li> Потом решение — пошли в магазин, и executive network обеспечивает выполнение.</li>
<li> Пришли в магазин, тут еда, можно все сразу есть, а default network выдает: так нельзя, тут правила, социальное поведение, надо сначала положить в корзину, заплатить, потом уж есть и лучше дома — и executive network управляет по-другому.</li></ul>
<p>Одновременно default и executive не работают, и между ними переключался salience. У креативного переключения между сетями происходит часто и быстро, а у не-креативного происходит редко, работа идет по очереди. И важно, чтобы не было стресса. Потому что миндалина и еще несколько центров говорят «мысли — это классно, но сначала выжить» — испуганный не креативный человек.
</p><p>Насколько я понимаю, по сути это различие стереотипных действий и рассуждений по наработанным шаблонам, когда выборы надо делать редко, и конструирование или поиск решений в случае множества альтернатив, когда решения можно переключать многократно, что как раз требует частого переключения.
</p><p>Для мышления нужна энергия. Привычная деятельность требует 35 % энергии, целенаправленный действия, когда включена логика в eхecutive system — 40-45 %, для активации default network — 65 % энергии. Стресс сбрасывает энергию до 25 %, то есть 75 % уходят шли на обеспечение безопасности, на все остальное — лишь 25 %. По исследованиям, проведенным в 2018—2019, то есть до ковида, среднее количество энергии у офисных работников — 33 %: они слегка задолбанные и замученные, даже голод различают нечетко.
</p><p>Почему ребята в команде не смогут креативно мылить: у Васи сильное мышление в executive, но остальные в загоне, Катя — в стрессе, у Пети работает default, но он не умеет управлять и выводить на исполнение executive, у Алисы тоже executive, но наработаны шаблоны не мышления, а выполнения. Собираем из не-креативных людей креативную команду.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:Teamlead-2023-Obuhova.jpg" class="image"><img alt="Teamlead-2023-Obuhova.jpg" src="https://mtsepkov.org/images/thumb/9/92/Teamlead-2023-Obuhova.jpg/400px-Teamlead-2023-Obuhova.jpg" width="400" height="300" srcset="https://mtsepkov.org/images/thumb/9/92/Teamlead-2023-Obuhova.jpg/600px-Teamlead-2023-Obuhova.jpg 1.5x, https://mtsepkov.org/images/thumb/9/92/Teamlead-2023-Obuhova.jpg/800px-Teamlead-2023-Obuhova.jpg 2x" /></a></div>
<p>Слайд 8 фаз креативного процесса с переключением сетей, красивая елочка, которую я воспроизведу текстом, а потом будут детали по каждой фазе .
</p>
<ol><li> Значимая идея — salience</li>
<li> Собрать образы — default</li>
<li> Группировать данные — executive</li>
<li> Варианты достижения — salience</li>
<li> Инсайт идея — default</li>
<li> Интуитивная оценка — salience</li>
<li> Логическая оценка — executive</li>
<li> Праздник победы — salience</li></ol>
<p>Теперь подробнее по стадиям.
</p><p><b>1. Значимая идея salience</b>. Решаемая задача должна стать доминантой. Концепция доминанты — Ухтомский: устойчивое возбуждение куска коры головного мозга, которая отвечает за определенную потребность. Когда доминанта образуется, она давит остальную активность, выделяя главное.
</p><p>Будет ли у команды что-то придумать? Да не особо. Мы предлагаем еще одну доминанту. Мы не можем действовать напрямую, потому что это приведет к стрессу, который отключает креативное мышление. Поэтому идем по-другому, создаем информационную доминанту, искусственно прогреваем информационную сеть.
</p><p>Мозг монозадачен: концентрируется на одной, между тремя можем переключаться. Информационно прогрели работу над созданием идеи, а физиологию — ослабили, команда работала не в офисе, были комфортные условия.
</p><p>Прогрев доминанты — разговор, воспоминание. Разговор нужен не менее 10 минут — вспомни, и идет вспоминание — доминанта прогревается. Теплая доминанта держится 6 часов, потом остывает и уходит из фокуса — мозг забывает.
</p><p>Про прогрев надо помнить, если даешь обратную связь более чем через 6 часов — надо область прогреть вспоминанием. Иначе негативная связь будет воспринята как незаслуженная обида, наезд, а позитивная — как спонтанная похвала, а не подкрепление правильных действий: приятно, за что — непонятно, идем дальше.
</p><p>Для работы надо удерживать доминанту. Каждое утро на летучке — каждый раз вспомнить не менее 10 минут. Дальше вечером командное событие — о чем думал, какие идеи появились. А еще надо погреть перед сном. Есть кратковременная память и долговременная, и надо, чтобы salience network чтобы запомнила — работаем над значимой идеей.
</p><p>Есть правило Хебба: чем более прогреваем — тем сильнее связи, становится привычнее думать. А чтобы физиология и стресс не взяли верх, надо кормить и не пугать дедлайнами. Вообще. Говорить «через две недели» про то, что что 10 лет не делали — нельзя. Перестройка мозга занимает 3 месяца и людей надо отпустить. Выделить бюджет на полгода и не думать о результате. никакого прогресса.
</p><p><b>2. Собрать образы для default network</b>. C ней нельзя разговаривать, ставить задачу, надо можно лишь напитать фактами для размышлений. Для этого подходят факт-карты, инструмент придумал Андрей Курпатов. Не путать с mind map, которые ориентированы на структуру для executive network, а не default. Чтобы выложить 150 фактов, она может работать. Мы просим default network подумать посмотреть связи — она под оценку связей и взаимодействия. Она сама сделает.
</p><p>Чтобы наполнить факт-карты — покупаем билеты на все конференции, просто чтобы ходили и доклеивали факт-карты, и без явного результата, просто наполнение карты. И на этом этапе команде будут завидовать и ненавидеть, потому что люди как бы не работают, и их надо от этого оградить, чтобы не было стресса.
</p><p><b>3. Группировать данные</b>. Стикеры на стену — чтобы все вместе там было. Стикеры — важно, потому что написание снижает тревожность что забудем: мы напрягли префронтальную кору и отняли ресурсы у центра стресса, когда пишем — не боимся. Это называется labeling, пишем коротко и успокаиваемся
</p><p><b>4. Продумывание вариантов достижения</b>. Выявление значимости — salience, передняя поясная извилина: перевод внимания, посредник между корой и лимбической системой. Чтобы было больше вариантов — надо придумывать варианты.
</p><p>Для разогрева упражнение 18 (или 16) рож. Чертим лист на клеточки, задание — нарисовать за 20 секунд в каждом квадратике по роже. Дальше по кругу, что откликнулось, какие варианты нравятся. В среднем Нравятся с 4 по 6, потому что первые 3 — привычные, как умеют, стандартные, Дальше надо креативить что-нибудь, и люди придумывают, а к последним — устает и времени нет.
</p><p>Это как техника 5 почему: на первые почему дают очевидные ответы, о которых уже наверняка думал, поэтому надо очевидное убрать.
</p><p>Креативность связана с дистальным моделированием — это способность представить себя в другой ситуации, другим человеком.
</p>
<ul><li> Темпоральное — что будет через 24 часа. Через 100 лет — а что будет через 100 лет?</li>
<li> Место — представь в разных местах. Нью-Йорк, Токио, на Марсе</li>
<li> Другой человек: Брак Обама утешает друга в сложной ситуации — а какая сложная ситуация может быть у друга Барака Обамы.</li>
<li> Совсем другой: Представь разумной плесенью. Как разумная плесень будет выбирать рабов? Представь себя марсианином, какой путеводитель по Земле тебе нужен?</li></ul>
<p>Проксиальное моделирование помогает в повседневной жизни. Представьте задачу, которую не хочется делать. Представьте, что ситуация не у вас, а у друга Васи. Дайте Васе совет, что делать. Что чаще всего советуют люди? Первое — делай, вторая — не делай, остальное дальше. И это же совет самому себе.
</p><p>Дистальное моделирование. Представь ты сидишь в пространстве, комната. Ты приглашаешь человека в комнату того, чье мнение интересно. Приглашай, играешь сам с собой. И этот человек дает совет, ты ему подарок. у вас small talk. Кого пригласили — разных персонажей, в том числе известных, от кого хочешь совет, какой ответ они дали, о чем говорили — шевелим структуру.
</p><p><b>5. Инсайт — default</b>. Это нелинейное мышление.
</p><p>В мозгу три типа волн: гамма — инсайт, бета — бодрствование и альфа — дрема. Альфа — у ребенка, когда вы ругаетесь с ребенком, вы ругаетесь с собой, который почти заснул.
</p><p>Когда высокая тревожность — плохие решения основанные на ценностях.
</p><p>Хорошие идеи — перед сном, на прогулке, в курилке, в разговоре вечером может по другой ситуации — это начинает говорить default network. Только 4 % за рабочим столом, и то — когда с прогулки вернулись.
</p><p>Сначала альфа-волны возрастают — почти засыпаем, расслабление, почти ничего 25 минут! — и тут появляется вероятность инсайта. Спокойно, смотрим внутрь — нет salience, не работает надо проблемой. Можно выпить 40 г крепкого или 125 вина — не больше
</p><p><b>6. Интуитивная оценка — salience</b>. Мурчит или нет, сигналы изнутри. Если мурчит — связалось с потребностью и ценностью, это внутри выдал.
</p><p><b>7. Логическая оценка — executive</b>. Тут методы известны: moscow, кано и так далее.
</p><p><b>8. Праздник победы — salience</b>, надо обязательно отметить результат, получить награду.
</p><p>Они 3 месяца тренировали мозг, и потому получилось достичь результата, выдать идею с первой итерации. Но это — случайность, Анна была готова, что потребуется 2-3 итерации. И может не получится, гарантий нет, но мы сильно повышаем вероятность.
</p><p>Я тут хочу отметить, что в целом процесс похож на <a rel="nofollow" class="external text" href="https://document.wikireading.ru/34442">Дугу Эйнштейна</a> — то, как Эйнштейн понимал появление научных открытий. Но там, естественно, не было нейрофизиологии. Еще интересно сравнить этот процесс с теорией U Отто Шармера (<a href="https://mtsepkov.org/U-theory" title="U-theory" class="mw-redirect">мой конспект книги</a>), оно в целом — похоже. Но у Шармера это запаковано, механизмы не вскрыты, а в объяснениях работы метода он, по сути, оперирует миром объективно существующих идеальных объектов.
</p><p>Что касается в исследований. которые легли в основу метода, то для меня остается открытым вопрос о креативности для людей, живущих в тяжелых условиях. Из истории известно, что многие писатели, ученые, художники, музыканты и певцы начинали творить именно в таких условиях, а некоторые так жили всю жизнь, признание пришло после смерти. При этом есть конкретные кейсы, когда утверждается, что после признания уровень новизны, креативности в творчестве падал, может быть, просто потому что к тому времени человек уже приобретал больше опыта и мог комбинировать из наработанного. Про творчество таких людей может быть две гипотезы. Базовые механизмы регулирования мозга работают в моменте, без стратегии, а моменты, когда человек поел, выспался или счастлив все равно случались и творчество могло проявляться именно в эти кратковременные периоды легкого счастья. Либо разнообразие возможных путей творчества гораздо шире, и исследования открыли лишь один из них, и, может быть, для некоторых состояние сытости наоборот. противопоказано.
</p><p>Для задачи создания в компаниях креативных команд вопрос о способах креативности в тяжелых условиях не слишком важен, если мы растим у людей креативность, потому что накормить человека и создать другие хорошие условия сейчас относительно легко. А те, кто могут создавать команды креативности в тяжелых условиях, подобно тому. как Берии создавал шарашки, сделают это и без теории. Но вот с социальной точки зрения ответ на вопрос — важен, потому что если требование хороших условий и отсутствия стресса в жизни — сильное, то сами люди в тяжелых условиях могут «махнуть на творчество рукой», и, что более существенно, те, кто потребляет результаты творчества могут ввести отсекающий критерий отбора, блокирующий путь, подобно тому, как HR часто необдуманно и необоснованно ставят критерий высшего образования или молодого возраста, в том числе там, где он реально не нужен. Понятно, что тех, кто творил в сложных условиях раньше в томограф не засунешь, а выбрать среди тех. кто сейчас еще безвестен не так просто и требует денег, но с научной точки зрения для полноты исследований это требуется, а с социальной — важно.
</p><p>Дальше — заметки с ответов на вопросы. Зафиксиввоано не все, а наиболее интересное для меня. Это обсуждали в зоне дискуссий весь следующий слот.
</p><p>Как захотеть сделать любую задачу? Есть простой подход: 30 секунд физическое антистрессовое упражнение, любое, чтобы успокоить миндалину. потом 4 минуты по методике action grow (AGROW) — мозг подготовлен на 17 минут продуктивной работы по задаче. Методика AGROW, к сожалению, не гуглится, поиск ведет на общую методику GROW, я у себя нашел в <a href="https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2020-06-30:_%D0%90%D0%BD%D0%BD%D0%B0_%D0%9E%D0%B1%D1%83%D1%85%D0%BE%D0%B2%D0%B0._%D0%92%D1%8B%D0%B3%D0%BE%D1%80%D0%B0%D0%BD%D0%B8%D0%B5_%D1%81%D1%82%D1%80%D0%B5%D1%81%D1%81%D0%B0_%D0%B8_%D0%B2%D1%8B%D0%B3%D0%BE%D1%80%D0%B0%D0%BD%D0%B8%D0%B5_%D1%81%D0%BA%D1%83%D0%BA%D0%B8" title="Блог:Максима Цепкова/2020-06-30: Анна Обухова. Выгорание стресса и выгорание скуки">конспекте семинара Анны «Выгорание стресса и выгорание скуки»</a>, но без подробностей, так что не факт, что там рассказ, а не ссылка. <a rel="nofollow" class="external text" href="https://youtu.be/F8tJgQJ3nRI">Здесь сам семинар</a>.
</p><p>Про батарейку. 100 % — потенциал, исследования, в которых 80 % — максимум. Потенциалы конкретных людей различаются, но можно считать, что для социальной группы успешно работающих в сложных отраслях типа ИТ они примерно равны максимуму. Энергию меряет Weltory, но у нее максимум — 100 %, там фактически измеряют активность вегетативной нервной системы. Если ее проценты умножить на 0.8 0- будет абсолютная цифра.
</p><p>Лидер должен быть +15 % к команде, чтобы вести за собой. Если лидер заболел. то потенциал снижается, но есть 3-4 месяца на восстановление, сохраняется кредит доверия.
</p><p>Чтобы люди не бесили — надо 60 % энергии. Болезнь отрубает эмпатию. Маску заинтересованного доброжелательного человека — не эмулировать. Понимание, что кого-то не любят — не скрыть. Опыт, наработанные шаблоны спасает профессиональную деятельность, но эмпатия и внимание не шаблонизируется.
</p><p>Курпатов — хороший научпоп. Дубинин, Сапольски — научная альтернатива, но там значительно тяжелее. Включение default network у Курпатова — технологично сделано.
</p><p>Если запускать такой процесс — очень важно держать факт-карты, а то будут сваливаться на другое, на mind map и похожее.
</p><p>Был анализ техник фасилитации с точки зрения нейробиологии. В основном техники успокаивают, чтобы включить мозг в нужный момент, то есть включить executive, выключив миндалину.
</p><p>Уровни потребностей у людей разные. Врожденное или обученное — сложный вопрос. Рождаемся с темпераментом, воспитываем характер, и вопрос конфликта между темперамента и характера, шаблоны.
</p><p>Выгорание, уровни стресса: обычный — парадоксальный (без важного-неважного) — дзен (все неважно) — потом на любую мелочь следует взрыв. При высоком уровне нагрузки можно сознательно поддерживать динамическое равновесие на коротких циклах по полчаса работа-восстановление. Она лично — научилась.
</p><p>Лимбическая система отключает энергию коре не потому, что реально устал и ее не осталось, она экстраполирует: ты уже час думал, два думал, результата нет — скоро умрешь, надо прекращать. Поэтому надо организовывать циклы и внутренние подкрепления, авторизацию результата и другие.
</p><p>Работа с заявками пользователей или заказчиков. Важно увидеть за ней боль человека, поставить себя на место другого, а для этого нужна энергия. Если энергии нет, то первичная реакция — уроды задолбали. А ели увидел боль — то получается нормальная задача, и решая ее — получаешь подкрепление: ты снял чужую боль. Иначе мозг тратит энергию на заявку, раз, другой, потом экстраполяция «скоро умру» и вырубание. Не потому что энергии реально нет, он просто экстраполировал, что и дальше будет расход без восстановления — заявки не кончаются. Восстановление — авторизация результата и другие техники. Цикл потратил-восстановил. И важно, чтобы подкрепление поймал эмоциональный уровень мозга, рациональные рассуждения тут не работают. Если снял чужую боль — больше восстановление, чем когда просто решил задачу, потому что идут связи со смыслом и ценностями. Можно и по-другому. мотивации у всех разные, главное — с ними связывать работу по каждой заявке.
</p>
<h1><span class="mw-headline" id=".D0.95.D0.B2.D0.B3.D0.B5.D0.BD.D0.B8.D0.B9_.D0.98.D0.B4.D0.B7.D0.B8.D0.BA.D0.BE.D0.B2.D1.81.D0.BA.D0.B8.D0.B9._.D0.9E.D1.81.D0.BE.D0.B7.D0.BD.D0.B0.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D1.8C_2.0.C2.A0-_.D0.BF.D0.BE.D1.87.D0.B5.D0.BC.D1.83_.D0.BC.D1.8B_.D0.B8.D1.81.D0.BF.D1.8B.D1.82.D1.8B.D0.B2.D0.B0.D0.B5.D0.BC_.D0.B8.D0.BC.D0.B5.D0.BD.D0.BD.D0.BE_.D1.8D.D1.82.D0.B8_.D1.87.D1.83.D0.B2.D1.81.D1.82.D0.B2.D0.B0_.D0.B8_.D0.BA.D0.B0.D0.BA_.D0.BF.D0.BE.D0.BB.D0.BD.D0.BE.D1.81.D1.82.D1.8C.D1.8E_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B8.D1.82.D1.8C_.D0.BD.D0.B5.D0.B6.D0.B5.D0.BB.D0.B0.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D1.81.D0.BE.D1.81.D1.82.D0.BE.D1.8F.D0.BD.D0.B8.D0.B5">Евгений Идзиковский. Осознанность 2.0 - почему мы испытываем именно эти чувства и как полностью изменить нежелательное состояние</span></h1>
<p>Это очень интересный доклад, который дает технику работы с эмоциями. Проще всего это описать в модели, которую Евгений не рассказывал, и которую я услышал от Вадима Демчога: спектакль жизни играется на двух сценах: в объективной реальности и на внутренней сцене у меня в голове, и поведением во многом управляет не реальность, а увиденное внутри. И в докладе речь шла о том, что многие эмоции обусловлены тем, что на внутренней сцене разворачивается ролик, не имеющий отношения к реальности, который призван вызвать переживание и направить поведение. Дальше была техника, как этот ролик можно увидеть и понять, что представленное в нем не имеет отношения к реальности, и дальше изменять реакцию. То есть мы можем повлиять на встроенную систему, чтобы мое поведение поменялось.
</p><p>Дальше конспект доклада. Эмоции, неприятные переживания — есть, несмотря на то, что мы их не хотим. Я понимаю, почему боюсь, что я делаю из-за страха, но природа страха изнутри — неясна, и как провзаимодействовать со своим страхом, чтобы его убрать — неясно. Но доклад дает методику для этого, и она работает не только для страха, но и для других эмоций, просто в экспресс-варианте со страхом — проще.
</p><p>Схема работы психики проста: (1) Что-то случилось снаружи или внутри — идет сигнал; (2) Психика сигнал обрабатывает: категоризирует и вызывает поведение. Механизм заточен под то, что происходит быстро в дикой природе. Увидели тигра — страх — убегаем. Но у нас не дикая природа. Жизнь не дает реальных опасностей, ну если не переходите на красный или не делаете подобные действия. Поэтому не получается создавать простые реакции: увидел начальника — убегаешь, увидел свою девушку — пусть приготовит еду или займетесь чем-то еще приятным, обычно много вариантов и выбор не однозначен. То есть механизм эмоций, заточенный под простые реакции, сбоит.
</p><p>Если я попрошу представить кошка, то каждый представит свое: кошка домашняя спящая или играющая, абстрактная кошка -силуэт, кошка как концепт, тактильные ощущения от взаимодействия и так далее. Мозг умеет вызывать картинки. И именно это используется для генерации эмоций, когда представляете кошку, эмоции появляются, хотя не у всех.
</p><p>Светофор. Большинство людей, переходя на красный свет испытывает дискомфорт. Хотя светофор — безобиден. Но есть правило в голове: на красный не ходи. Представим: я, дорога, за ней ларек с шаурмой, вы ее хотите, но красный светофор говорит «не сейчас». Что делает психика для остановки по светофору? Она включает переживание — страх. Еще останавливает отвращение, но это — гораздо более редкая эмоция.
</p><p>Как эмоция запускает страх? Закройте глаза и представьте: лето, гуляете по парку, вышли из него, широкая дорога, 4 полосы в каждую сторону, посмотрели направо и налево, там пусто до горизонта, но напротив красный светофор. И вы начали переходить, и в какой-то момент возник страх. Скорее всего у вас появился видеоряд, который страх и вызвал. Экспресс-опрос зала — у многих реально возник. Обычно машина слева, и люди могут вспомнить ее цвет, в зале — вспоминали. Не ролик четкий как в фильме, машина может быть смутной. И не обязательно это машина, к кому-то подходил большой милиционер.
</p><p>То есть вы были в ситуации, где никакой опасности, но психика проэмулировала видеоряд с конкретной опасностью, и этот ролик и создал страх. И в 90 % ситуаций в жизни эмоции не связаны с реальностью, они связаны с картинкой в голове.
</p><p>Идет красивая девушка познакомлюсь — опасности нет, ну, скажет что не знакомлюсь. А мозг подсовывает: она отвергнет, все увидят что ты лох и другие ужасы.
</p><p>Можно сказать, что вы идете по улице и у вас очки дополненной реальности. И там виртуальные люки — вы их обходите, а где-то может быть асфальт на месте люка — и тогда вы провалитесь.
</p><p>Но реакция меняется. Представьте. Утро. Текущие новости. Президент: времена тяжелые, выезд запрещен, счета заморожены, курс фиксированный 300р и так далее. И тут внизу «вы смотрите трейлер сериала выживание» И вы «тьфу, фигня». Что изменилось? Ведь эмоция была, кортизол выработали. Но вы поняли: это не реальность, а реклама.
</p><p>Все, что показывает мозг — не реальность, а реклама. Совпадает случайно. Хотя если перебежать МКАД с движением — то да, может совпасть.
</p><p>У мозга нет цели предсказать будущее! Он не умеет. Вы думаете мозг реагирует на запрос «нарисуй реалистично» и он работает — это неправда, реально запрос «мозг, сделай ролик для эмоций».
</p><p>Я тут хочу прокомментировать. Мозг в целом и механизм эмоций в частности эволюция все-таки создавала именно для предсказаний. И он позволял работать эффективно, а эти ролики воспроизводили воспоминания с эмоциональными маркерами, за счет которых обучение опасным ситуациям происходило с первого раза, а не после многократного повторения. Но, как Евгений и говорил в начале доклада, это было давно и для дикой природы, а в нынешних условиях механизм сбоит и подсовывает воображаемые опасности, или картины из прошлого, которые были виртуальной детской опасностью. То есть хотя механизм создавался для предсказаний, сейчас он реалистичных предсказаний чаще не дает.
</p><p>Таким образом, у вас непрерывный ролик с рекламой и вы не знаете, что реклама, и нельзя переключить. И это влияет на поведение. Кока-кола ставила эксперимент «нас и так знают, выключим рекламу» — нет, продажи падали.
</p><p>Вообще механизм роликов работает не только для страха. Он побуждает действовать, например, вы предвкушаете: сейчас сделаю завтрак и вкусно позавтракаю, а потом встаете, делаете завтрак и вкусно завтракаете, еще и потому, что сами предвкушали это. Влезать в этот механизм надо только когда ваше поведение вас не устраивает. Отменять страх перехода на красный, наверное, не целесообразно. А вот если у тебя в голове вкусный бутерброд, который тебе нельзя и ты страдаешь — это стоит менять.
</p><p>Представьте ситуацию. Вы что-то не делаете: не отправляете резюме, не начинаете задачу, не звоните заказчику. Представьте эту ситуацию, поймайте сопротивление и ответьте — что крутится в голове, желательно домотать до видеоряда. Ролик может быть из прошлого, может быть это школьная учительница вас ругает. И если это засекли, то вы уже понимаете, что ролик не имеет отношения к реальности: вы будете говорить с заказчиком, никакой учительницы там нет.
</p><p>И даже если ролик про настоящее, то подумайте, какая вероятность того, что это осуществится? Скорее всего, маленькая. В мире за год десятки человек погибают от удара молнии — но вы не боитесь выходить на улицу. И даже если в ролике реалистичное будущее, то насколько оно повлияет? Когда готовишься к экзамену — оценка важна, на самом экзамене — очень важна, а потом? Будет ли влиять через месяц или через год. Часто картинки в голове не повлияют на будущее серьезно.
</p><p>Закрываем глаза, вернулись к вспомненному ролику, и дальше в образе переключаем тот вариант на реальность. Стало легче? Часто ролик не один, с каждым поведением связано 3-5 роликов из прошлого и один из будущего. Это таблетка для выхода из матрицы. С травмой такой техникой тоже можно работать, но долго.
</p><p>Если ролик не появляется, это нормально, мы проходим экспресс-вариант, многим людям надо час-полтора, чтобы поймать. Потому что видео ярко появляется первый раз, а потом мозг подсовывает ссылку, и оно быстро прокручивается до наработанной реакции. Это как ты когда-то мечтал о встрече со знакомой в ответ на появление в мессенджере, или вспоминал реальную прогулку с ней, и если это несколько раз повторить, то эмоция начинает возникать сразу в ответ на появление ника, без промежуточного ролика. Вспомните, если у вас было, когда вы были влюблены или вас кто-то обидел, вы ходили и представляли какие-то картины, там часто ролики громадные, часами. А тут короткие ролики, они скомпилированы.
</p><p>Есть ли те, у кого видео отсутствует? За последний год было около 1000 клиентов, и для этого использовал вскрытие автопилота. Опыт показывает, что способны, она не всегда как в фильме, может быть смутной. Может, клиент лишь говорит, что видит картинку — в голову не залезешь. Но если он вскрывает образ и ему становится легче — то результат получен.
</p><p>Это же использует реклама — она вкладывает картинки, видеоряд. Но не вся визуализация работает. Человек не делает зарядку. Он может представить себя спортивного и прокаченного, но все равно не делает зарядку, потому что мозг — хитрый, он думает — вот пусть этот прокаченный и делает зарядку. И представление ламборджини не побудит работать, что работать, если ламборджини уже есть. Но можно крутить в голове, что ты делаешь упражнение — мозг представляет и переобучается.
</p>
<h1><span class="mw-headline" id=".D0.94.D0.B0.D1.80.D1.8C.D1.8F_.D0.92.D1.8C.D1.8E.D0.BD.D0.BE.D0.B2.D0.B0._.D0.9F.D0.B0.D1.82.D1.82.D0.B5.D1.80.D0.BD.D1.8B_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BE.D0.B1.D1.89.D0.B5.D0.BD.D0.B8.D1.8F:_.D0.BA.D0.B0.D0.BA_.D1.81.D0.BA.D0.B0.D0.B7.D0.B0.D1.82.D1.8C.2C_.D1.87.D1.82.D0.BE_.D1.82.D1.8B_.D0.B4.D1.83.D0.BC.D0.B0.D0.B5.D1.88.D1.8C_.D0.BD.D0.B0_.D1.81.D0.B0.D0.BC.D0.BE.D0.BC_.D0.B4.D0.B5.D0.BB.D0.B5.2C_.D1.82.D0.B0.D0.BA.2C_.D1.87.D1.82.D0.BE.D0.B1.D1.8B_.D0.BE.D1.82_.D1.82.D0.B5.D0.B1.D1.8F_.D0.BD.D0.B5_.D1.80.D0.B0.D0.B7.D0.B1.D0.B5.D0.B6.D0.B0.D0.BB.D0.B8.D1.81.D1.8C">Дарья Вьюнова. Паттерны проектирования общения: как сказать, что ты думаешь на самом деле, так, чтобы от тебя не разбежались</span></h1>
<p>Дарья — тренер и архитектор обучения в онлайн-школе OTUS. Идея доклада в том, что есть много стереотипов коммуникации, многие из которых мы восприняли из детства, которые вызывают эмоциональную реакцию, обесценивают и демотивируют. И это часто не является целью коммуникации, ее цель — поиск конструктивного решения в ситуации в рациональном, а не эмоциональном обсуждении. А такие стереотипы могут цеплять эмоции и выводить из конструтива.
</p><p>Такие стереотипы формируются в детстве, Дарья полагает, что они встроены в культуру: russian feedback, красная ручка в школе, много указаний на ошибок и мало похвалы в школе и так далее. Я думаю, что привязка к русской культуре неверна, судя по количеству западных книг, где объясняется примерно тоже самое, так что проблема общая, хотя культурный контекст, естественно, накладывает свои акценты. И такая привязка обесценивает культуру в целом. Тезисы из зала — что есть опыт западных компаний, где перегибы в другую сторону.
</p><p>Но истоки — это вторично, потому что проблема объективно есть. И дальше были конкретные рекомендации по формулировкам, которые не дадут эмоциональной реакции. В виде практического упражнения, во взаимодействии с залом. И это — очень полезно, это приземляла теоретический материал доклада на практику. Потому что теорию знают многие. Что еще важно: эти фразы не должны быть формальной пудрой, это внутри должно быть так.
</p><p>Ключом для изменения является вопрос: что я хочу достигнуть в коммуникации, и помогаю я этому своими формулировками или мешаю.
Общие рекомендации, чтобы убрать эмоциональную реакцию:
</p>
<ul><li> Оценивать работу, а не личность</li>
<li> Исключить личные местоимения</li>
<li> Переключить смысл с прошлого на настоящее и будущее.</li>
<li> Надо было -> Можно. Мы все что-то должны, это смягчает коммуникацию.</li>
<li> Негатив предмет давать очень предметно.</li>
<li> Заменять «но» на «и» и «лишь» и «только» — ценить усилия, а не обесценивать.</li></ul>
<p>Дальше те формулировки, с которыми работали, и варианты изменений
</p>
<ul><li> Вы допустили ошибку -> У нас проблема, Произошла нештатка, Ой как интересно получилось, Можем сделать по-другому. Переключить смысл с прошлого на будущее.</li>
<li> Вы выбрали неудачное решение -> мы что-то не учли, есть вариант лучше, из каких вариантов мы выбирали, давайте еще подумаем</li>
<li> Вы не выполнили -> Работа не доделана, Согласно требованиям, этого недостаточно…, Планируется что-то доделать? В работе отсутствует…</li>
<li> Нужно было выбрать другое решение -> В следующий раз нужно; стоит пересмотреть; предлагаю попробовать</li>
<li> Я сделал бы совсем по другому — это переход на личности, и из прошлого в будущее -> Как смотришь на то, чтобы сделать вот так, Рассмотрим альтернативы, А как можно еще это сделать? Можно сделать так…</li>
<li> Ты работаешь как все; за воротами миллион — обесценивает.</li>
<li> Вы конечно правы, но … -> Я частично согласен… Есть другая точка зрения … Я в работе сталкивался… Вы правы, и в то е время …</li>
<li> Позитив: Спасибо, сделано верно, и предлагаю сделать еще что-то…</li></ul>
<p>В презентации был очень забавный слайд с переводом рекламы из будущего в прошлое — можно развлекаться в метро и на улицах, забавно.
</p><p>Как общаешься сам с собой? Такими формулировками или нет? Ты даже не моешь встать рано замените на «предлагаю завтра встать пораньше».
</p><p>Интересная формулировка от заказчика «Проделана большая работа …». формально это — правильная оценивающая фраза, но для меня это канцеляризм, прикрывающий очень мало сделанного. И, судя по реакции зала — не только для меня.
</p><p>Сообщение: Привет, что там с задачей? Паника и напряженка, излишний контроль. У нее пример: руководитель спрашивает «Мы за последние полгода nps считали …» — эмоции. Потому справилась спросила — а что? — Инвестор запросил, если есть — отправим. Рабочая ситуация. Тут идея — до вопроса дать контекст. Я вспомнил, что тут была такая задача, что с ней происходит. Или что-то еще.
</p><p>В конце был слайд, озаглавленный как Итоги. Хотя это — не итоги доклада, это способы мышления, которые призваны исключить негативную эмоциональную реакцию, которую тебе надо сдерживать в коммуникации, и тогда эти стереотипы, возможно, вообще не всплывут. А может, все равно всплывут, ведь ситуация, когда новичок предлагает решение и ошибается — вполне рабочая, и эту ошибку надо исправить конструктивно. Вот эти тезисы:
</p>
<ul><li> Другой — поставщик полезного опыта.</li>
<li> Разнообразие может создавать устойчивость команды.</li>
<li> Со всеми ОК.</li>
<li> Каждый всегда делает наилучший из возможных выборов.</li></ul>
<p>Я бы в целом суммировал, что у каждого есть свои спусковые крючки эмоций, среди которых есть распространенные. Они выводят коммуникацию из конструктива, и их лучше не задевать случайно. При этом многое зависит от культуры компании и команды, вопрос «как задача» воспринимается как рабочий вопрос, а не скрытый упрек «почему не сделал» — то его нормально задать. Просто восприятие человека узнать непросто.
</p>
<h1><span class="mw-headline" id=".D0.AF.D0.BD.D0.B0_.D0.A4.D1.91.D0.B4.D0.BE.D1.80.D0.BE.D0.B2.D0.B0._.D0.98.D0.BC.D0.B0.D0.94.D0.96.D0.A3.D0.9D.D0.B0.D1.80.D0.B8.D1.83.D0.BC.C2.A0.E2.80.94_.D0.BF.D1.80.D0.B5.D0.B4.D1.81.D1.82.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B4.D0.B6.D1.83.D0.BD.D0.BE.D0.B2_.D0.BE_.D0.BB.D0.B8.D0.B4.D0.B0.D1.85">Яна Фёдорова. ИмаДЖУНариум — представление джунов о лидах</span></h1>
<p>Яна пришла в тестирование из преподавания английского. Она умеет работать с обратной связью от учеников, и применила это для джунов. Реальное исследование, анонимный опрос 100 джунов и обработка результата, именно этим доклад интересен. Джуны — актуальная тема: 120 курсов по 100 джунов в месяц — 12к новичков на рунке. В курсах рассказывают, что с руководителем легко и можно классно пообщаться, и новички из ВУЗов приходят с этим ожиданиями. Если меняют специализацию, то легче, уже есть понимание, что происходит.
</p><p>Чувство новичка — эмоциональные качели: страх, неуверенность, стресс, радость. И ожидают, что тимлид — придет и успокоит. А реально у тимлида — в календарях встречи, контроль выполнения задач, работа по проекты и так далее. Поэтому тимлид хочет опыта, джун получает очередной отказ, расстраивается, но, наконец, его берут — и тут у него ожидания, что все будут рады и будут помогать. У джуна нет опыта, есть богатое воображение и куча статей, которые о н прочитал о прекрасных тимлидах. А руководитель при этом думает, где взять столько времени, надо будет отвечать на вопросы, все проверять, а календарь и так полон. То есть ожидания различаются очень сильно.
</p><p>В исследовании 100 джунов рассказали кейсы взаимодействия с руководителем в ответ на открытый вопрос.
</p>
<ul><li> 17 % — супер-тимлид</li>
<li> 26 % — не взаимодействую с тимлидом, созвоны раз в месяц</li>
<li> 44 % — работать невозможно, терплю ради стажа, избегаю взаимодействия</li>
<li> 13 % — прекратили сотрудничество, не сработались</li></ul>
<p>Позитивный опыт: ожидания меньше или совпали с реальностью. Радость, восторг, счастье, вовлеченность. Из отзывов: собеседование — круто; спрашивает коротко и по делу; следит за всеми и может показать; познакомил с командой, ввел в курс дела, предупредил, что ошибки будут и это нормально.
</p><p>Нейтральный опыт: как-то у нас без тимлида, может уволился, а я не знаю, работают и нем могут сказать — хорошо или нет. Мне кинули задачу, справился — работай. Нет лида — нет проблем, лид-невидимка, разработчик, не трогает QA. И одни говорят — хорошо, а другие — жаль. Эта категория появилась в процессе исследования.
</p><p>Негативный: ожидания были выше реальности: обида, страх, разочарования., беспомощность. Лидам нет дела для подчиненных, хамство, убедилась, что хороших руководителей нет даже в ИТ. Руководители не боятся обидеть, нет дела до других чувств и это сильно ранит сотрудников. Увольнение без фидбэка.
</p><p>Есть кейсы «богатое воображение» — когда ожидания за гранью реальности. И тоже есть эмоции. Там примеры ожиданий: офис не такой, или я ничего не делаю, потому что мне ничего не сказали.
</p><p>Как джуны оценивают лидов:
</p>
<ul><li> Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.</li>
<li> Душа компании. Весельчаки, заводные. Но если постоянно весело — пропадает серьезность, и подчиненные перестают всерьез работать, про задачи — отшучиваются</li>
<li> Бабушка. О тебе всегда заботятся, на 1:1 хочется закутаться в пледик</li>
<li> Токсичный лид: токсик — современный мем. Считает, что делает одолжение, что ты работаешь, отпускает шутки. Много новеньких, потому что старенькие не задерживаются, новенькие тоже уходят, и потом читаем в интернете «ужасная компания», а не «ужасный Иван Иванович»</li></ul>
<p>Руководители про джунов
</p>
<ul><li> Ботаник. Читает пользовательское соглашение, читает все требования, работают тщательно, но очень долго</li>
<li> Проактивный. Первые в очереди на выгорание, давайте все, готовы работать все время. За ними надо следить — могут сгореть.</li>
<li> Виноват не я! Так сложилось. Стремятся переложить не только ответственность, но и задачи.</li>
<li> Младенец. Хотят прямой ответ на вопрос, не любят исследовать, пояснения, наставления, все показать.</li>
<li> Память золотой рыбки: пришел-спросил-забыл. Спросил кого спросить — не спросил, забыл. Что делал вчера — не помнит.</li></ul>
<p>Каждый руководитель выбирает джунов под себя. Чтобы было комфортно всем. Когда команде не комфортно — снижается уровень мотивации, люди уходят. Не только джуны.
</p><p>Тимлид — как препод. Джуны — как студенты первого курса. Они обычно приходят с горящими глазами, и дальше зависит от того, как выстроен процесс.
</p><p>Что делать? Общаться словами через рот. Коммуницируйте.
</p><p>Что важно новеньким?
</p>
<ul><li> Обратная связь: ты пришел новенький работаешь, и не понимаешь: то ли все так плохо, что завтра уволят, или наоборот все хорошо. Обратная связь — не только оценка, это проявление интереса как твои задачи, это создает интерес нужности.</li>
<li> Обсуждение допущенных ошибок: ошибки допускают все. Очень часто джун воспринимает ошибку как последнюю, которую разрешено допустить, проговорите явно: что не уволят за любую ошибку, что надо быстро сказать.</li>
<li> 1:1 — это не просто возможность услышать обратную связь, это возможность сказать в комфортной безопасной обстановке по рабочим делам.</li></ul>
<p>Выводы.
</p>
<ul><li> Работать с ожиданиями, чтобы не было кейсов переоценки, рассказывайте что вы ждете</li>
<li> «Все хорошо» — не значит, что все хорошо, люди не всем делятся, особенно когда нет доверия и ощущения безопасности</li>
<li> Коммуникация — ключевое слово в построении отношений</li>
<li> Ваше общение влияет на карьеру. Руководитель накосячил — фидбэк на компанию. Не закапывайте человека и не убивайте самооценку, даже если не сложилось</li>
<li> Мы все джуны, мы приходим в новые компании и команды.</li>
<li> Тимлид — важный человек, от него многое зависит.</li></ul>
<h1><span class="mw-headline" id=".D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.AF.D0.BD.D1.8B.D0.BA.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.A1.D0.B1.D0.B5.D1.80.D0.9C.D0.B0.D1.80.D0.BA.D0.B5.D1.82:_.D0.9A.D0.B0.D0.BA_.D0.B8_.D0.B7.D0.B0.D1.87.D0.B5.D0.BC_.D1.82.D0.B8.D0.BC.D0.BB.D0.B8.D0.B4.D1.83_.D1.80.D0.B0.D1.81.D1.82.D0.B8_.D0.B2.D1.8B.D1.88.D0.B5_.D0.BF.D0.BE_.D0.BA.D0.B0.D1.80.D1.8C.D0.B5.D1.80.D0.B5">Сергей Яныкин из СберМаркет: Как и зачем тимлиду расти выше по карьере</span></h1>
<p>Возможный путь из тимлида — в руководители многих команд и дальше в CTO/CPO/CFO и так далее. Для начала надо решить, стоит ли по нему идти?
</p><p>Демотиваторы.
</p>
<ul><li> Точно надо будет больше работать. Пример календаря — у него сихрон 2 часа, 2-3 часа с семьей, потом разгребает все что нужно.</li>
<li> Вы всегда будете плохим. Вы вне команды, где-то начинаете закручивать гайки на перформанс, ребята видят, что вы поменялись — стали плохим. А если наоборот, комфортно для подчиненных, то плохой для руководителя.</li>
<li> Неопределенность процессов. Для команды понятно — scrum, kanban, ретро, дейли. Выше фреймвоков обычно нет, есть большая специфика.</li>
<li> Работа с зарплатами и бюджетом. И кейсы, когда подчиненные получает больше. Дали 50к на повышение зарплат на 10 человек — как поделить, и кто-то будет недоволен, скажет что так мало.</li></ul>
<p>Мотиваторы.
</p>
<ul><li> Возможность делать изменения, чем выше — тем больше шансов решить проблему или принести идею. У него в команде всегда были проблемы с инфраструктурой и стейджами. Когда вырос — вспомнил про проблему, наверное у разных команд собрал, посмотрели влияние на команды, пошел к техдиру — решили</li>
<li> Нетворкинг — с техдиром, директором по продукту, основателями компании — возрастает</li>
<li> Деньги, но это вилки, все бывает, деньги начинают быть завязаны на результат и быть не гарантированы.</li>
<li> Развитие и интересные задачи — те задачи, которые не решал, управление менеджерами, а не просто инженерами</li></ul>
<p>Как сделать level up?
</p><p><b>1. Подготовить себя</b> — будет больше переключений контекста и другие задачи, к этому надо готовиться.
</p>
<ul><li> Управление проектами и командами. Где-то есть проджекты, а где-то нет — и надо вести проекты, делать арбитраж, искать бюджеты, фасилитация встреч и так далее. Книги: Larson An elegant puzzle. Том Демарко Deadline. Голдратт Цель.</li>
<li> Многозадачность, и много входов по задачам: ИБ, инфра, HR, смежники. Книга — Максим Дорофеев Джедайские техники.</li>
<li> Ситуационное руководство. Direct-Coaching-Support-Delegating</li>
<li> Продукт. Цель миссия и стратегия компании. Если у компании нет — плохо. Понимание, какими метриками оперирует компания. Книги: Cagan Inspired. Румельт Хорошая стратегия, плохая стратегия.</li>
<li> Техника. Алгоритмы и паттерны проектирования. Мартин Чистая архитектура.</li></ul>
<p><b>2. Подготовить команду</b>. Зачем: вас промоутят, команда без руководителя — она перестала так же перформить.
Метрики: velocity plan-fact; cumulative diagram — поиск bottleneck, predict lead time — предсказание поставок и срока ожидания.
</p><p>Как я определяю собственную эффективность?
</p>
<ul><li> Если команда эффективна, то я эффективен</li>
<li> Меньше моих эскалаций на руководителя.</li>
<li> У вас есть большинство ответов на вопросы руководителя. Если у вас нет — вопрос к себе, почему не задано</li>
<li> Ваш руководитель НЕ участвует в задачах в вашей зоне ответственности — в том числе на встречах высокого уровня говорите вы, а не он</li></ul>
<p>Автономность
</p>
<ul><li> Выпишите свои задачи и функции</li>
<li> Выпишите для каждой, кто может заменить</li>
<li> Кто встречается чаще других, вероятно, преемник</li>
<li> Надо спросить — хочет ли он роста.</li>
<li> И дальше — на него делегировать новое.</li></ul>
<p>Кейс после отпуска:
</p>
<ul><li> команда работает также — премия</li>
<li> команда работала хуже — как улучшится</li>
<li> команда работала лучше — уволили, вы руководитель мешал</li></ul>
<p><b>3. Подготовить руководителя</b>
</p>
<ul><li> быть ответственным: брать обещания по задачам, делать в срок, задавать вопросы, если неясно</li>
<li> брать инициативу и быть проактивным</li>
<li> заявить о желании роста — могут не догадываться</li></ul>
<p>Почему могут не повышать?
</p>
<ul><li> Руководитель не знает — заявляем</li>
<li> Руководитель знает и не хочет — понять причину.</li>
<li> Руководитель знает и хочет — может быть нет места для роста, надо ждать или идти на рынок.</li></ul>
<p>Итак
</p>
<ul><li> Определяем, точно ли хотим</li>
<li> Автономность и эффективность команды</li>
<li> Все время поднимаем руку «давай что-то сделаю»</li>
<li> Инициируем желание на рост руководителю</li>
<li> На бойтесь по пути поменять дорогу</li></ul>
<h1><span class="mw-headline" id=".D0.A0.D1.83.D1.81.D0.BB.D0.B0.D0.BD_.D0.A1.D0.B0.D1.84.D0.B8.D0.BD_.D0.B8.D0.B7_Byndyusoft:_.D0.A0.D0.B0.D0.B7_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B0.C2.A0.E2.80.94_as_Code.2C_.D0.BF.D0.BE.D1.87.D0.B5.D0.BC.D1.83_.D0.B1.D1.8B_.D0.B5.D1.91_.D0.BD.D0.B5_.D0.BF.D0.BE.D0.BA.D1.80.D1.8B.D1.82.D1.8C_.D1.82.D0.B5.D1.81.D1.82.D0.B0.D0.BC.D0.B8.3F.21">Руслан Сафин из Byndyusoft: Раз архитектура — as Code, почему бы её не покрыть тестами?!</span></h1>
<ol><li> Teamlead проходит вместе с #KnowlegeConf и #Techlead, и этот доклад — про архитектуру. Тесты архитектуры могут обеспечить актуальность архитектуры и проверить соблюдение принципов архитектуры. В докладе были примеры и инструменты, которые они выложили в open source.</li></ol>
<p>Architecture As Code. Архитектура определяет принципы, на которых строится взаимодействие между сервисами. Это не просто картинка взаимодействующих сервисов. Картинка — наглядна, но принципов на ней нет. Картинка хороша для коммуникации, но у нее нет версионирования, и нельзя сделать сравнение. Поэтому и появился Architecture As Code: описываем схемы на языке, картинка строится автоматически. Распространенные инструменты: PlantUML и Structurizr, есть и другие. Когда описываем взаимодействие сервисов в PlantUML, описываем сервисы и их взаимодействие.
</p><p>Проблемы архитектур:
</p>
<ul><li> не актуальность — при чем часто еще сложно разобраться,</li>
<li> декларативность: показывает, что есть business logic — repository — db. А можно ли напрямую?</li>
<li> контроль — есть договоренность, что напрямую нельзя, но новичок не знал — и сделал</li></ul>
<p>Решение проблем — через автоматизацию, тесты по архитектуре.
</p>
<ol><li> Актуальна ли архитектура проду?</li>
<li> Соблюдает ли архитектура выбранные принципы.</li></ol>
<p>Дальше разбор на примере, в котором есть внешние сервисы и внутренний периметр, разделенные предохранительным уровнем, а внутри база данных с обращением через репозитории.
</p><p>Откуда брать происходящее на проде
</p>
<ul><li> Service mesh и реальный трафик. Действительно реальность. Но: (1) нет редких связей, сложно симулировать и потому долгая обратная связь — только с прода</li>
<li> Infrastructura as code — она дает знания о возможных связях: конфиги кубера с обращениями, топики кафки и так далее. Информации там больше. Можно проверить надежность — сколько подов запущено, действительно ли они на разных нодах. Мы из обоих источников формируем списки сервисов и структуру связей и сравниваем. B в докладе — пример сравнения, он сделал open source реализацию такого сравнения.</li></ul>
<p>Проверка принципов.
</p>
<ul><li> anti corruption level — на границе есть адаптеры, и с внешними сервисами общение только через них. Помечаем адаптеры и внешние сервисы тегам, и проверяем, что внешние сервисы только через них.</li>
<li> DB пассивна, а обращение к ней — только через репозитории — тоже разметка сервисов-репозиториев, и проверка, что из репозитория единственная исходящая связь через базу данных, а в базе данных — только входящая из репозитория.</li>
<li> Внешние REST — только через API gateway — тип связи</li>
<li> Операции записи — только через оркестратор бизнес-процессов, так как у него механизм компенсирующих транзакций — красим связи чтение-запись, и проверяем, что запись только у оркестратора.</li></ul>
<p>Для проверки принципов мы раскрасили сервисы и атрибуты — важно, чтобы эта раскраска сопоставлялась с конфигами на проде и проверялась тестами соответствия проду. Иначе в архитектуре пометили связь read only, а в конфиге открыты любые обращение — контроля нет.
</p><p>Тесты включаются в общую систему тестов. Если на этапе разработки поправили конфиг так, что архитектура нарушена, то при разворачивании на СI/CD тест упадет. Принципы архитектуры могут нарушаться случайно и сознательно. Тесты отсеют изменения по незнанию. А для соблюдения принципов нужно approve архитектора на изменения тестов.
</p><p>Трудоемкость: 2 чел-нед архитектора + 2 чел-нед разработчика + 0.5 чел-нед девопса.
</p><p>Результат: актуализировали архитектуру, привели к единым конвенциям, нашли топики кафки, куда только писали и не читали, нашли неиспользуемые зависимости в конфигах и коде, актуализировали понимание внешних систем, измерили и зафиксировали архитектурный техдолг, переключили на api gateway все необходимые зависимости, убрали дублирование в конфигах и архитектуре
</p><p>Бонус для монолита. Другая команда у них посмотрела доклад — и написала проверку для архитектуры модульного монолита. Тоже в open source, можно брать.
</p>
<h1><span class="mw-headline" id=".D0.9D.D0.B0.D1.82.D0.B0.D0.BB.D0.B8.D1.8F_.D0.A1.D0.BC.D0.B8.D1.80.D0.BD.D0.BE.D0.B2.D0.B0._.D0.9A.D0.B0.D0.BA_.D0.BF.D0.BE.D0.B4.D0.B3.D0.BE.D1.82.D0.BE.D0.B2.D0.B8.D1.82.D1.8C_.D0.B8.D0.B4.D0.B5.D0.B0.D0.BB.D1.8C.D0.BD.D1.83.D1.8E_.D0.B2.D1.81.D1.82.D1.80.D0.B5.D1.87.D1.83_.D0.B2_.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.82.D0.B5_.D0.B1.D1.80.D0.B5.D0.B9.D0.BD.D1.88.D1.82.D0.BE.D1.80.D0.BC.D0.B0">Наталия Смирнова. Как подготовить идеальную встречу в формате брейншторма</span></h1>
<p>Метод известен давно, но попытка провести часто заканчивается без результата: появляется множество идей, с которыми непонятно что делать, или идут бесконечные споры без результата. Наталья рассказывала о формате, который позволяет получить результат.
</p><p>Брейншторм придумал Alex Osborn. Правила: не критикуем идеи; больше идей богу идей; любые идеи приветствуются, идеи порождают другие и снимают опасения сказать глупость; комбинируем идеи для получения новых.
</p><p>Но дальше есть опасность: получить множество идей, с которыми неясно что делать. Есть динамика встречи: идет генерация, расходящееся мышление, в какой-то момент мы достигаем максимума и выход в зону стонов. И в этот момент надо зафиксировать ситуацию, и перевести группу в конструктивное русло отбора и оценки идей, но не разрушить безопасность.
</p><p>Как действовать. (1) Организационный план: Цель, Продукт встречи, Люди, Возможные проблемы на встрече. (2) Фасилитационный план обсуждения.
</p><p>Цель фокусирует встречу. Например, идеи для понижения затрат для продвижения рекламы, или идеи для нового сегмента пользователей. Фокус есть, пошел поток идей. Что по итогам? Сколько идей забрать, какие критерии хорошей идеи? Например топ-10 с плюсами и минусами. Или отсортировать по затратам. Приглашенные участники, их опыт. Круто позвать с разным опытом — чтобы была новизна. Необычная локация: за город, если есть бюджет, другая переговорка, что-то креативное в знакомой переговорке. Проблемы: проговорили всю встречу, проспорили, ушли внутрь и не вернулись.
</p><p>Проблемы призван снимать фасилитационный план. 4 фазы встречи, для каждого — форматы и примеры.
0 — легализация креативного мышления без критики. Модельное упражнение, например, встреча в лесу — что можно сделать со мхом, идея — можно орать, не стесняясь.
1. Сбор данных и генерация идей с выходов в зону стонов. Сначала каждый генерит любые идеи индивидуально. Потом делим на малые подгруппы, в каждой — своя тема, например, сегменты рынка или портреты пользователей, потом обсуждаем. Как обсуждать не критикуя? Вопросы только на понимание.
</p>
<dl><dd> 1а. Формат 1-2-4-все или 1-3-6-все (если 12). Сначала каждый свое, потом объединяет, кластеризует, комбинирует.</dd>
<dd> 1б. World cafe. Сначала генерация по столикам, а потом — переход, знакомимся с идеями и порождаем новые. Зона стонов может быть уже здесь. В конце владельцы плакатов рассказывают всем.</dd></dl>
<p>2. Перевести из зоны стонов в сходящееся решение. Голосование как выбор предпочтительных идей. Без критики. В world cafe можно по разному правила, за что голосовать — за плакат или идеи на нем.
</p><p>3. Выработать решение. У вас есть, например, 5 идей и надо почеленджить.
</p>
<dl><dd> 3а — Классифицируем. Разделить про ресурсам и ценности.</dd>
<dd> 3б — Сценарии: что будет, если сделать, и что, если не сделать. Две группы, одна по позитивным сценариям, другая — по негативным</dd>
<dd> 3в — Три направления мышления: оптимисты, пессимисты, и как сделать</dd>
<dd> 3г — Ценность — для компании, для клиентов, для партнеров — тоже работа в группах.</dd></dl>
<p>В этой части можно использовать один формат или несколько, в зависимости от целей встречи.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80_.D0.9A.D0.BE.D1.80.D0.BE.D1.82.D0.BA.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A2.D0.B8.D0.BD.D1.8C.D0.BA.D0.BE.D1.84.D1.84._.D0.90.D0.B2.D1.82.D0.BE.D0.BC.D0.B0.D1.82.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F_.D0.B1.D0.B5.D0.B7_.D0.B1.D0.B5.D0.B4._.D0.9A.D0.BE.D0.B3.D0.B4.D0.B0_.C2.AB.D0.B4.D0.B0.C2.BB.2C_.D0.B0_.D0.BA.D0.BE.D0.B3.D0.B4.D0.B0_.C2.AB.D0.BD.D0.B5.D1.82.C2.BB.3F">Александр Коротков из Тинькофф. Автоматизация без бед. Когда «да», а когда «нет»?</span></h1>
<p>Основной тезис доклада: процессы важнее автоматизации, потому что автоматизация работает только при регулярных процессах, если у вас хаос, то автоматизация не поможет. Более того, побочные эффекты автоматизации могут нарушить отлаженный процесс, например, отвалить существенную часть. Например, при изменении автоматизации workflow задач случайно отвалили интеграцию с ботом, который напоминал о review — и время ревью выросло с нескольких часов до пары дней, потому что разработчики привыкли, что о review напоминает бот и эти задачи смотреть не надо. Для оценки упорядоченности процесса используется Кеневин фреймворк. Но хаос в процессе может быть скрытым, был пример, когда тестировщики массово скипали красные тесты, потому что они краснели из-за нехватки CPU.
</p><p>И в конце — общий алгоритм работы.
</p>
<ol><li> Убедиться что мы в ordered-зоне — то есть процессы отлажены</li>
<li> Определить узкое место в процессе. Если можно расшить — расшиваем, если нет — болевую точку справа</li>
<li> Прикидываем профит и как оцениваем</li>
<li> Принимаем решение</li>
<li> Автоматизируем по возможности MVP</li>
<li> Оцениваем результат.</li>
<li> Переводим автоматизацию в complicated|obvious — чтобы не свалиться в chaotic.</li></ol>
<p>Я отмечу, что в целом все рассказанное разумно, но если пойти в область enterprise-разработки, то там часто невозможно стабилизировать процесс до его автоматизации из-за эффекта масштаба. Конечно, бизнес понимает, что автоматизация — это относительно жестко, и старается пропустить какие-то тестовые прогоны процесса с поддержкой на Excel и другими подручными средствами, но это не всегда возможно, и по-любому воспроизводство на масштабе всегда меняет процесс. Особенно это касается, когда новый процесс оптимизирует старый. И автоматизация процесса в темпе его становления — отдельная увлекательная задача, которую я решал. Но в целом — все верно.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B0.D1.81.D1.82.D0.B0.D1.81.D0.B8.D1.8F_.D0.93.D1.80.D0.B0.D1.84._.D0.91.D0.B0.D0.B7.D0.B0_.D0.B7.D0.BD.D0.B0.D0.BD.D0.B8.D0.B9.C2.A0.E2.80.94_.D0.BA.D0.BE.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BA.D1.82.D0.BE.D1.80.2C_.D0.B8.D0.BB.D0.B8_.D0.9A.D0.B0.D0.BA_.D1.83.D0.B3.D0.BE.D0.B4.D0.B8.D1.82.D1.8C_.D0.B2.D1.81.D0.B5.D0.BC">Анастасия Граф. База знаний — конструктор, или Как угодить всем</span></h1>
<p>Последний доклад первого дня #Teamlead я слушал на треке #KnowledgeConf. Практический доклад по созданию базы знаний в небольшой компании Maxim Technology — это разработка платформы для Taxi Maxim, третий агрегатор в России. У Анастасии команда 7 человек технических писателей, которые на входе все были джунами, сейчас каждый вырос. Задача — решить вопрос с документацией, создав базу знаний.
</p><p>Общие требования:
</p>
<ul><li> Легко делиться знаниями, каждый может написать статью. Тогда люди делятся, чтобы второй раз с вопросом не приходили</li>
<li> Понятный язык, без перевода с ит-шного на бухгалтерский</li>
<li> Легко найти, нет библиотекаря, который весь день отвечает на вопрос «где найти статью»</li>
<li> Все материалы достоверны и актуальны</li></ul>
<p>Написали, принесли читателям, реакция: у вас много лепестков и не одного цветка. Интересно, но использовать не получается. Они провели анализ и доработали.
</p>
<ul><li> Людей пугал конфлюенс — сделали много инструкций на повседневные задачи.</li>
<li> Требование понятного языка дополнили: статьи отвечают целям и задачам пользователя</li>
<li> Надо не просто легко найти, а быстро собрать подборку документов по теме и желательно самостоятельно.</li>
<li> И нужна методология оценки актуальности статей полуавтоматом.</li></ul>
<p>Для этого использовали принципы:
</p>
<ul><li> Классификация контента, стабильные типы.</li>
<li> Принцип единого источника: если контент нужен в нескольких местах, мы не копируем, а вставляем, так что при правке изменяется сразу везде.</li>
<li> Шаблоны и отчеты для создания и пересборки контента</li>
<li> Понятный принцип определения статуса разработки контента и его актуальности.</li></ul>
<p>Как это реализовано технически?
</p><p>Классификация контента.
</p>
<ul><li> Глоссарий. Иначе война. Определение терминов, которое везде.</li>
<li> Справочник — один короткий вопрос. Как только статья разрослась и отвечает на несколько вопросов — делим</li>
<li> Старица книги. На входе была задача про две книги: для бизнеса — что делает и для разработчиков — как сделано и почему.</li></ul>
<p>Принцип единого источника — переиспользование информации. Поэтому итоговый документ всегда набор справочников и терминов, собранная вручную, или подборка, создаваемая с помощью отчетов.
</p><p>Шаблоны. Сделали для глоссария и для страницы справочника — включает чек-лист. История изменений — спрятана, есть в режиме редактирования, там ссылки на задачи и договоренности. Страница книги — тоже есть шаблон с договоренности, в нем набор стандартах заголовков с чеклистами. Контент — в справочниках. Поскольку документы сборные, история страницы не показывает изменения. Поэтому новости публикуются на отдельном канале.
</p><p>Отчеты confluence — подборка по меткам и по свойствам страницы. Отчет по свойствам — метки и фильтры. Общий и тематический глоссарии делают из них. Три типа меток.
</p>
<ul><li> Метка статуса — готовность документа: В работе — ревью — Опубликована — На корректировку.</li>
<li> Тематические метки, для ограничения поиска</li>
<li> Технический метки — классификация по назначению, например «термин»</li></ul>
<p>Макросы: сделать подборку (поиск), сделать термин, отчет по свойствам страницы для сборки глоссария, содержимое по меткам.
</p><p>У них нет секретов, смотреть можно все. Это особенность. Если права есть появляется сложность: вы готовить отчет, но коллега может не видеть. Переиспользование контента позволяет обновлять максимально быстро. А отчеты дают тематические выборки, поэтому можно обновлять или проверять по темам, когда что-то изменилось.
</p><p>Как только сделали — в компании начали использовать. Возможность делать подборки, которые всегда актуальны — ценно. Новую статью заводят с помощью макроса, если не умеют — то без него, техписы видят обновления и дальше дорабатывают: редактируют, ставят метки, чтобы органично включилось в систему.
</p><p>Они используются только доступный из коробки функционал. И в вопросах пришла очень интересная инфа: оказывается, плагин плагин confluence, который используется для создания словарей, сливает все словари в облако разработчикам в Германию…
</p>
<h1><span class="mw-headline" id=".D0.95.D0.BB.D0.B5.D0.BD.D0.B0_.D0.9F.D0.BE.D0.BF.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_Directum._.D0.9E.D0.B1.D1.83.D1.87.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8E:_.D0.B0.D0.BD.D0.B0.D0.BB.D0.B8.D1.82.D0.B8.D0.BA.D0.B8_.D0.B8_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.87.D0.B8.D0.BA.D0.B8.C2.A0.E2.80.94_.D0.B5.D1.81.D1.82.D1.8C_.D0.BA.D0.BE.D0.BD.D1.82.D0.B0.D0.BA.D1.82">Елена Попова из Directum. Обучение проектированию: аналитики и разработчики — есть контакт</span></h1>
<p>Проектирование интеграции и развития продукта — зона совместной работы аналитиков и разработчиков, так как в обоих случаях существенны как требования заказчика и взаимодействие с ним, так и технические аспекты. Требовалось организовать обучение, в ходе которого аналитики и разработчики научатся это делать совместно. Обучение организовано в группах, при этом внутри группы аналитики и разработчики разбиты на пары, которые будут работать совместно. Обучение — практикум, в которых люди разрабатывают проекты решения конкретных кейсов и обосновывают их. Эталонное решение для кейса тоже есть, его разбирают после представления своих, но нет интенции, что оно единственно правильное.
</p><p>Обучение основано на цикле Колба. Теория — Эксперимент — Конкретный опыт — Рефлексия — Теория. В обучении часто с теории, но реально можно начинать с любой фазы. Важно замкнуть в цикл.
</p><p>Для обучения надо сделать теорию — описать процесс проектирование, разделение труда в нем. Теорию можно собирать по компании, но Эксперты не могут объяснить, почему принимают какое-то решение. Но можно собирать опыт и выявлять закономерности. А еще опираться на внешние источники, по интеграции у них как раз один из сотрудников проводил внешний курс, где был алгоритм, и они скомбинировали эту теорию с опытом компании, и получили теорию для курса.
</p><p>Workflow практикума: Теория — постановка задачи — самостоятельная проработка — практика. Обучение по группам, в которых несколько пар аналитик+разработчик, у каждой группы — куратор, он играет роль заказчика. Каждая группа представляет свое решение, и потом куратор показывает и объясняет эталонное. Для работы над разными кейсами группы миксуют, сохраняя пары, и меняют куратора, поэтому получается разное взаимодействие.
</p><p>Получилось удачно, участники рекомендуют. А собранная теория интеграции — завирусилась, ее пересылают и используют в проектах.
</p><p>Естественно, после первого цикла провели рефлексию.
</p>
<ul><li> Эталонное решение после демо групп слушать тяжело — поэтому эталон записали и отдали на самостоятельное знакомство в спокойной обстановке с последующим обсуждением на встрече.</li>
<li> Предполагают, что на постановке задачи будут вопросы по теории, их нет — всем понятно, а практика показывает, что не понятно. И потому сами подготовили вопросы ребятам и маленькие учебные кейсы.</li></ul>
<p>Практикум нарабатывает умение создавать несколько вариантов решений на основе стандартных вариантов, выбирать один и его обосновывать. Навык генерить и сравнивать варианты — полезный, это подтверждается практикой. Хотя они могут быть уродливее, чем первый попавшийся, часто именно они ложатся в основу решения. А требование выбора из вариантов повышает их осознание, облегчает аргументацию заказчику. Практикум включают режим исследования у обучающихся: не оценка правильно или нет — а оценка и аргументация.
</p><p>Проектирование совместно с разработчиком, а не в режиме челночной дипломатии аналитика — сокращает трудоемкость, были реальные кейсы.
</p><p>В конце — чек-лист, как повторить путь, там теория, концепция практикумов, подготовка кейсов, выбор кураторов… Кураторы нужны квалифицированные, и это не так просто. Но реально трудоемкость — это на этапе подготовке практикума и кейсов, один кейс — до 40 часов. А встреча для обучения — всего 4 часа, их можно выделить в операционке без проблем. Кураторов привлекают возможностью поиздеваться над обучаемыми :)
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-11-29:_Highload-2023_-_%D0%B7%D0%B0%D0%B3%D0%BB%D1%8F%D0%BD%D1%83%D0%BB_%D0%B2_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B82023-11-29: Highload-2023 - заглянул в технологииMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-11-29T14:34:11Z2023-11-29T15:30:10Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Прошел #Highload. Я был только первый день, как обычно, публиковал заметки с докладов, но успел не все. Поэтому решил быстро собрать и опубликовать отчет. Highload вернулся в кампус Сколково из Крокуса. Участников - много, 3600+, это в полтора с лишним раза больше, чем было на нем в Сколково в предыдущий раз, когда организаторы подумали, что тесно и надо менять место. Но эксперимент с Крокусом не получился - там нельзя сделать столько маленьких залов, и в одном секторе там тоже уже становится тесно, а брать два или большое помещение для выставок дорого.
</p><p>Про место могут быть разные оценки. Лично я считаю, что 11 параллельных треков - преимущество конференции, а сумбурная геометрия Сколково дает дополнительный позитивный штрих к атмосфере. В целом конференция - удалась.
</p><p>У меня на этом Highload получилось погрузиться в технологические доклады, раньше так получалось только на Питерском highload. Наверное, помог обучающий трек. Кстати, на многих его докладах было переполнение зала. В общем, переполнение зала - типичная проблема конференций, но тут, возможно, организаторам стоит учесть, что многие участники на конференции хотят заглянуть в какие-то технологии на уровне общего понимания, услышать об этом интегрированное мнение от докладчика, сравнить со своим.
</p><p>Дальше - мои заметки по докладам в ходе конференции, часть была опубликована постами на канале, а несколько - только здесь. При таком количестве треков это - точно не репрезентативный отбор. И на некоторых таймслотах я зависал в общении - на конференции много знакомых, и некоторых встречаешь там после длинного перерыва.
</p><p>Заметки - в том порядке, что я слушал. Но я хочу отметить два доклада: про CQRS, там было удачное сочетание концептов и практичности, и про китайский open source дистрибутив linux OpenEuler, для которого сделали нашу open source локализацию OpenScaler. На конференции было еще несколько докладов про китайский open source, там интересная модель соборной разработки софта в рамках страны.
</p><p>Еще последним слотом был Fail meetup, было интересно послушать про чужие фейлы и вспоминать свои. Хотя, строго говоря, в рассказах не фейл, там аварии. связанные с человеческим фактором, которые, тем не менее, успешно разгребли и восстановили. Реальный фейл восстановления не предполагает, ну или это делают другие люди в другом проекте. Но все равно, рассказы были любопытны. Заметок оттуда не будет - там были откровенные рассказы без записи и трансляции, на эту часть конференции надо ходить лично.
</p><p>Итак, доклады.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Прошел #Highload. Я был только первый день, как обычно, публиковал заметки с докладов, но успел не все. Поэтому решил быстро собрать и опубликовать отчет. Highload вернулся в кампус Сколково из Крокуса. Участников - много, 3600+, это в полтора с лишним раза больше, чем было на нем в Сколково в предыдущий раз, когда организаторы подумали, что тесно и надо менять место. Но эксперимент с Крокусом не получился - там нельзя сделать столько маленьких залов, и в одном секторе там тоже уже становится тесно, а брать два или большое помещение для выставок дорого.
</p><p>Про место могут быть разные оценки. Лично я считаю, что 11 параллельных треков - преимущество конференции, а сумбурная геометрия Сколково дает дополнительный позитивный штрих к атмосфере. В целом конференция - удалась.
</p><p>У меня на этом Highload получилось погрузиться в технологические доклады, раньше так получалось только на Питерском highload. Наверное, помог обучающий трек. Кстати, на многих его докладах было переполнение зала. В общем, переполнение зала - типичная проблема конференций, но тут, возможно, организаторам стоит учесть, что многие участники на конференции хотят заглянуть в какие-то технологии на уровне общего понимания, услышать об этом интегрированное мнение от докладчика, сравнить со своим.
</p><p>Дальше - мои заметки по докладам в ходе конференции, часть была опубликована постами на канале, а несколько - только здесь. При таком количестве треков это - точно не репрезентативный отбор. И на некоторых таймслотах я зависал в общении - на конференции много знакомых, и некоторых встречаешь там после длинного перерыва.
</p><p>Заметки - в том порядке, что я слушал. Но я хочу отметить два доклада: про CQRS, там было удачное сочетание концептов и практичности, и про китайский open source дистрибутив linux OpenEuler, для которого сделали нашу open source локализацию OpenScaler. На конференции было еще несколько докладов про китайский open source, там интересная модель соборной разработки софта в рамках страны.
</p><p>Еще последним слотом был Fail meetup, было интересно послушать про чужие фейлы и вспоминать свои. Хотя, строго говоря, в рассказах не фейл, там аварии. связанные с человеческим фактором, которые, тем не менее, успешно разгребли и восстановили. Реальный фейл восстановления не предполагает, ну или это делают другие люди в другом проекте. Но все равно, рассказы были любопытны. Заметок оттуда не будет - там были откровенные рассказы без записи и трансляции, на эту часть конференции надо ходить лично.
</p><p>Итак, доклады.
</p>
<h1><span class="mw-headline" id=".D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.91.D0.B5.D1.80.D0.B5.D0.B6.D0.BD.D0.BE.D0.B9._.D0.AD.D0.B2.D0.BE.D0.BB.D1.8E.D1.86.D0.B8.D1.8F_.D1.81.D0.B5.D1.80.D0.B2.D0.B8.D1.81.D0.BE.D0.B2_.D0.B8_.D1.81.D1.80.D0.B5.D0.B4.D1.81.D1.82.D0.B2_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.BA.D0.B8">Сергей Бережной. Эволюция сервисов и средств разработки</span></h1>
<p>В докладе история технологий интернета примерно с 1997 года по площади - операционки, редакторы, базы данных, средства разработки и так далее, и мне эта история очень откликается, вызывает воспоминания и некоторую ностальгию. К сожалению, эволюции, то есть логики развития, а не просто истории фактов, в докладе нет, просто сборка логотипов. Это жаль, было бы очень интересно. В вопросах было: почему Яндекс ушел с FreeBSD на Ubuntu? Ответ - эксплуатационные характеристики для управления большим количеством машин в кластере. А смысл доклада - вспомнить именно open source решений, и таким образом показать их вклад в развитие ИТ, общность разработчиков, которые не зависит от конкуренции между компании. И анонс инициативы Яндекса по грантам для Open Source разработки.
</p>
<h1><span class="mw-headline" id=".D0.95.D0.B2.D0.B3.D0.B5.D0.BD.D0.B8.D0.B9_.D0.9A.D1.83.D0.BB.D1.8C.D0.B3.D0.B8.D0.BD_.D0.B8.D0.B7_CDEK._Mattermost_.D0.BD.D0.B0_.D1.81.D1.82.D0.B5.D1.80.D0.BE.D0.B8.D0.B4.D0.B0.D1.85:_.D0.BA.D0.B0.D0.BA_.D0.BC.D1.8B_.D0.B7.D0.B0.D0.BF.D1.83.D1.81.D1.82.D0.B8.D0.BB.D0.B8_.D0.B8_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D0.B2.D0.B0.D0.B5.D0.BC_.D0.BA.D0.BE.D1.80.D0.BF.D0.BE.D1.80.D0.B0.D1.82.D0.B8.D0.B2.D0.BD.D1.8B.D0.B9_.D0.BC.D0.B5.D1.81.D1.81.D0.B5.D0.BD.D0.B4.D0.B6.D0.B5.D1.80">Евгений Кульгин из CDEK. Mattermost на стероидах: как мы запустили и развиваем корпоративный мессенджер</span></h1>
<p>Был телеграм, slack, skype для видео, проблемы что несколько мессенджеров и внешних, при этом slack - снаружи, нет контроля за работой сотрудников и помнит только 10к сообщений. Плюс важно держать мессенджер под контролем: он встраивается в бизнес-процессы, и отрубание их крэшит - поэтому решили развернуть локально mattermost. RocketChat тоже пробовали, но оказался нестабильным. И дальше был технический рассказ о проблемах, которые они решали: отказоустойчивость, хранение изображений, ограничение доступа к каналам, сервис, чтобы увидеть просмотр сообщения в виде привычных галочек и так далее. Они остаются на бесплатной версии и делают сервис подключаемыми плагинами, работают с подключением elastic search вместо собственного индексатора и своих уведомлений. Mattermost часть из этого дает в платной версии, но там, по отзывам, оно неудобно, например, для настройки доступа к каналам надо идти в консоль, для проверки что прочитали - жать кнопки, это не появляется как галочки и так далее. Поэтому все равно нужна собственная разработка. Делает все это один разработчик, который больше решает задачи devops. Если задумаетесь про mattermost - доклад точно полезен. Свои доработки они планируют публиковать без кодов (готовили к выступлению, не успели), а если будет интерес - подумают, как открыть доступ к кодам.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.B8.D0.BA.D1.82.D0.BE.D1.80_.D0.91.D1.83.D1.80.D1.86.D0.B5.D0.B2_.D0.B8.D0.B7_.D0.AF.D0.BD.D0.B4.D0.B5.D0.BA.D1.81._.D0.A1.D0.BB.D0.B8.D1.88.D0.BA.D0.BE.D0.BC.E2.80.A6_.D0.BC.D0.BD.D0.BE.D0.B3.D0.BE.E2.80.A6_.D0.B0.D1.81.D0.B8.D0.BD.D1.85.D1.80.D0.BE.D0.BD.D1.89.D0.B8.D0.BD.D1.8B.E2.80.A6">Виктор Бурцев из Яндекс. Слишком… много… асинхронщины…</span></h1>
<p>На что обращать внимание при работе с фичей из десятка сервисов, обрабатывающих 15 000 асинхронных задач в секунду. Поверх основного функционала Яндекс-такси есть функционал live activity - обновление состояния на клиенте, включая активность разных плашек. Все это обеспечивается большим количеством сервисов асинхронной работы, которые, преимущественно, работают по таймеру, а не по событиям - чтобы сбалансировать нагрузку. И рассказ был о том, как перестраивать архитектуру, чтобы обеспечить нужную производительность. Например, запрос от задачи в core-сервис создает недопустимую нагрузку - поэтому делаем промежуточное redis-хранилище, в котором обновление по событиям, а уже к нему идет обращение за данными. В докладе был ряд конкретных кейсов, без обобщений и выделения шаблонов. Их интересно осмыслить, если вы решаете такие задачи, может, появятся идеи уже для ваших задач. И общие рекомендации, прежде всего логи и мониторинг, при чем не общий по hardware, а внутри конкретных задач. А по организации взаимодействия - понимайте, что возможны падения и самые разные ответы смежных сервисов, это надо обрабатывать и вести себя разумно, не создавая дополнительной нагрузки.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B4.D1.80.D0.B5.D0.B9_.D0.A6.D0.B2.D0.B5.D1.82.D1.86.D0.B8.D1.85_.D0.B8.D0.B7_.D0.A2.D0.B8.D0.BD.D1.8C.D0.BA.D0.BE.D1.84.D1.84:_.D0.AD.D0.B2.D0.BE.D0.BB.D1.8E.D1.86.D0.B8.D1.8F_.D0.B8_.D0.BC.D0.B8.D1.84.D1.8B_CQRS">Андрей Цветцих из Тинькофф: Эволюция и мифы CQRS</span></h1>
<p>Доклад на стыке концептов и практики. Концептуально CQRS был придуман, когда запросов чтения много больше, чем запросов изменения данных. В этом случае логично отделить чтение от изменения данных, чтобы по-разному их масштабировать. Но для этого надо разделить запросы на чтение - query и изменение - command. И при этом единый класс, который обрабатывает конкретную сущность, делится, как минимум, на два обработчика: для запросов и для команд, а в перспективе для каждой команды и запроса появляется свой обработчик.
</p><p>Тут было интересное концептуальное утверждение, что такое разделение классов на множество отдельных обработчиков для каждой команды и запроса, упрощает код, делает компактные процедуры, вместо нескольких тысяч строк получаются сотни. Но при этом общее количество кода не меняется, он просто ложится в разные обработчики и файлы. Это интересно, потому что фактически получается откат с ООП-парадигмы на предыдущую, процедурную парадигму разработки. ООП, когда его придумывали, как раз говорил, что объединение всей логике, связанной с отдельным доменом или сущностью в один класс как раз облегчает понимание кода, обеспечивая инкапсуляцию и скрытие внутренней логики, позволяет менять реализацию, сохраняя интерфейс за счет инкапсуляции и так далее. Это интересно обдумать...
</p><p>Дальше был рассказ о практической реализации, в том числе решении задач по выделению общих частей обработки команд, которые в классике реализуются за счет приватных методов. А в этом случае их делают как отдельные сервисы, но надо заблокировать обращение снаружи, в C# это internal. Первый этап - просто разделить методы в коде и работать на общей базе, и это можно делать постепенно. Когда методы разнесены. можно распилить один сервис на два: на чтение и запись, это Андрей сказал уже в ответах на вопросы. И тут не обязательно разделять код, можно начать со специализации экземпляров. Дальше можно разнести базы для чтения и запросов, настроив репликацию master-slave и по-разному масштабируя, но у этого есть понятная обратная сторона - появляется замедление обновления данных при чтении. В коде при этом возникают два соединения, в одном запрещено обновление. В коде важно для обновлений читать предыдущее состояние из write-базы, а не из read. А следующим шагом можно вместо master-slave делать разные структуры данных, оптимизированные на запись и на чтение, с трансформацией при передаче данных. Модель для чтения может обновляться синхронно, если она носит характер кэша, но, как правило, это делают асинхронно. Асинхронное обновление не дает задержки, но нарушается консистентность и повышается сложность, надо разбираться с нарушением порядка сообщений, и вообще с ошибками обновления, которые рассинхронизируют write и read базы.
</p><p>Следующая часть - мифы CQRS. Они реально мешают применению.
</p>
<ul><li> Query не может менять состояние и даже писать логи. Это неверно, нельзя лишь меняем основную модель. А логе, метрики и кэши - меняем. И логи - это важно, потому что работу надо мониторить.</li>
<li> Query может читать только read-модель. Это не так, если нет проблем с производительностью - читайте основную, так что в read-модель можно выгружать не все.</li>
<li> Command не может читать read-модель. Это действительно так, потому что в ней не актуальные данные, и можно пропустить обновление. </li>
<li> Command не может возвращать значение. Это не так. Если мы создаем сущность, можно вернуть ее ключ, если что-то обновляем, то можно вернуть данные. Однако, это требует синхронной обработки команды. Если вы захотите потому перейти на асинхронное взаимодействие, то это не получится. То есть формально можно будет новый асинхронный запрос обернуть таймером до обработки, но это может отменить эффект перехода на асинхронное взаимодействие. Хотя есть разные кейсы.</li></ul>
<h1><span class="mw-headline" id=".D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9_.D0.92.D0.B0.D1.80.D0.B5.D0.BD.D0.BE.D0.B2:_.D0.9E.D0.BF.D1.8B.D1.82_.D0.B8.D0.B7.D1.83.D1.87.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BF.D0.B5.D1.80.D0.B5.D0.B4.D0.BE.D0.B2.D1.8B.D1.85_.D0.BA.D0.B8.D1.82.D0.B0.D0.B9.D1.81.D0.BA.D0.B8.D1.85_.D0.A1.D0.9F.D0.9E-.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D0.B9_.D0.B4.D0.BB.D1.8F_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B5.D0.BD.D0.B8.D1.8F_.D1.81.D0.BB.D0.BE.D0.B6.D0.BD.D1.8B.D1.85_I.D0.A2-.D0.B8.D0.BD.D1.84.D1.80.D0.B0.D1.81.D1.82.D1.80.D1.83.D0.BA.D1.82.D1.83.D1.80_.D0.BD.D0.B0_.D0.B1.D0.B0.D0.B7.D0.B5_.D0.B5.D0.B4.D0.B8.D0.BD.D0.BE.D0.B9_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.BD.D0.BE.D0.B9_.D0.BF.D0.BB.D0.B0.D1.82.D1.84.D0.BE.D1.80.D0.BC.D1.8B_OpenScaler.2FOpenEuler">Дмитрий Варенов: Опыт изучения передовых китайских СПО-решений для построения сложных IТ-инфраструктур на базе единой программной платформы OpenScaler/OpenEuler</span></h1>
<p>В Китае централизованное управление open source - OpenAtom, и это стимулируется и отчасти регулируется государством. И в применении конкретно дистрибутивам linux это регулирование требует, чтобы все китайские компании, которые создают свои дистрибутивы linux, вели единую кодовую базу Open Euler. Поэтому все доработки, патчи безопасности и многое другое попадает во все дистрибутивы. получается соборная модель разработки в масштабах страны. В то время как на западе и в России политика принципиально другая: каждая компания-создатель дистрибутива ведет собственную кодовую базу, и они развивают по-разному.
</p><p>Благодаря общей кодовой базе в Open Euiler много ценных технических фич, часть из них спикер перечислил. И они решили принести все это в Россию, сделали OpenScaler - локализованный российский вариант, под нужды российского enterprise. За 1.5 года 6 версий для x86 и ARM. Тоже open source, под той же лицензией, на основе которого тоже любая компания может создавать платные дистрибутивы. Основная сложность - отсутствие документации. Код - хороший, но документация в лучшем случае на китайском, а а часто отсутствует, надо взаимодействовать с сообществом, которое тоже далеко не все говорит по-английски.
</p><p>Особенности дистрибутива и некоторые инновации.
</p>
<ul><li> Кросс-платформенность: OpenScaler как Open Euler собирается подо все - очень много разнообразных архитектур железа.</li>
<li> A-Tune оптимизация производительности с помощью ИИ статическая и динамическая оптимизация</li>
<li> Kernel Live Update - смена ядра ОС без перезагрузки сервера или виртуалки. При этом можно заморозить исполнение процессов без потери данных, и разморозить после замены ядра.</li>
<li> SysCare - готовить патчсеты для запущенного сервиса и обновлять без остановки</li>
<li> KubeOS - упрощение управления обновлениями ОС. Умеет обновлять узлы платформы кластерной виртуализации так, что каждое обновление - новый образ, защищенный от записи. Обновили, перегрузили, пошло не так - откатили</li>
<li> NestOS - минималистичная ОС для узлов контейнерной виртуализации - выпилено много функционала. И там image, используете, хотите добавить - перезаберите образ. То есть вы можете заточить под вашу безопасность и среду.</li>
<li> tMem - гибкие политики управления подкачкой. Для приложений, где много ОЗУ но с ограниченным числом обращений к ней - можно настроить политики.</li>
<li> ОС для embeded-устройств. Ядро реального времени и много еще функционала для них.</li>
<li> iSula - своя реализация контейнерной виртуализации. Совместима с kubernetes, но переписана с нуля и более производительная. Они исследовали по сравнению с Docker 18 и 24, и podman 3.4.4. Сделали инструмент сообщества OpenEuler для ключевых операций - create, start, stop, remove, run. Выигрывает у docker 18 и podman, с docker 24 - есть выигрыши и проигрыши на разных операциях. B будут проводить тестирование на реальных конфигурациях.</li></ul>
<p>Дальше была техническая часть, как это использовать, с деталями и скринами, это надо смотреть презентацию.
</p>
<h1><span class="mw-headline" id=".D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9_.D0.92.D0.BE.D0.BB.D0.BA.D0.BE.D0.B2_.D0.B8.D0.B7_Okko._.D0.9F.D0.BE.D0.B4_.D0.BA.D0.B0.D0.BF.D0.BE.D1.82.D0.BE.D0.BC_.D0.B1.D1.8B.D1.81.D1.82.D1.80.D0.BE.D0.B3.D0.BE_.D1.81.D0.BF.D0.BB.D0.B8.D1.82.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D1.82.D1.80.D0.B0.D1.84.D0.B8.D0.BA.D0.B0_.D0.B4.D0.BB.D1.8F_.D0.90.2FB-.D1.82.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F:_.D0.BE.D0.BF.D1.82.D0.B8.D0.BC.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F_.D0.BF.D1.80.D0.BE.D0.B8.D0.B7.D0.B2.D0.BE.D0.B4.D0.B8.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.B8_.D0.B8.D0.BD.D1.84.D1.80.D0.B0.D1.81.D1.82.D1.80.D1.83.D0.BA.D1.82.D1.83.D1.80.D0.BD.D1.8B.D0.B5_.D1.83.D1.80.D0.BE.D0.BA.D0.B8">Дмитрий Волков из Okko. Под капотом быстрого сплитования трафика для А/B-тестирования: оптимизация производительности и инфраструктурные уроки</span></h1>
<p>На платформе идет параллельно много экспериментов, и есть задача: поделить пользователей на группы так, чтобы каждый участвовал только в одном эксперименте, и для каждого эксперимента можно было получить контрольную группу. Для каждого эксперимента определяются правила - какие участники там нужны, в зависимости от атрибутов пользователя и параметров его системы, потому что эксперименты - разные, какие-то про дизайн интерфейса, какие-то связаны с рекомендациями контента и так далее.
</p><p>Архитектурное решение: реализовать для этого отдельный сервис, который бы определял категорию пользователей в динамике, а не рассчитывать эту категорию заранее - потому что очень большая база пользователей, в моменте соединяется лишь небольшая часть. При этом динамика правил - высокая, продукты все время придумывают новые фичи и хотят их протестировать. Пересчитывать каждый раз по всей базе - дорого.
</p><p>Этот сервис разработали, получили ответ в 15мс при целевом 10мс, поэтому дальше решали задачу оптимизации, об этом и был основной рассказ.
</p>
<ul><li> Валидация запроса - 15%, но сервис - внутренний - там не надо валидировать, это исключили.</li>
<li> Расчет сегмента - 60-70% работы сервиса. Расчет - алгоритмическое выражение, ты его пишешь на json и идет расчет с подстановкой конкретных значений.
<ul><li> В правилах сегментах есть общие выражения - по платформам, например. Но оценки показывают, что прирост от их вынесения на их количестве правил будет небольшим.</li>
<li> Правила - логический формулы с условиями и-или и можно считать не все операнды, если значение определено без них. Но тут оценки тоже дают небольшой прирост.</li></ul></li>
<li> json - дерево. его в python байт-код и компилятор - решили транслировать в AST и откомпилировать, и это дало ускорение вычисления выражения вдвое.</li>
<li> А дальше идея глобальной оптимизации: не вычислять правила по-одному, а построить очень большое выражение, которое бы сразу вычисляло все правила. Это сработало, правило построили на json, а затем - откомпилировали. </li>
<li> В результате вычисление группы сильно ускорилось и в результате занимает всего 28% профиля, и это дало ускорение вдвое.</li></ul>
<p>Но при этом на графике производительности сохранилась дисперсия и остались не очень понятные импульсы. Анализ показал, что это связано со сборкой мусора: в python два механизма: подсчет ссылок и сбор по поколениям, потому что подсчет ссылок не работает при циклических ссылках между объектами. посмотрели статистику по сборке мусора, выяснили, что сборка по поколениям регулярно происходит для объектов, которые создает Kafka. Kafka используется для
</p><p>Еще в python есть сборщик мусора. Подсчет ссылок + поколенья. Ссылки - не работает для циклические ссылки. Поколенья - маленький стоп. Выгрузили логи, посмотрели время - сколько идет сбор поколений. И они начали искать, где создаются такие объекты. Оказалось, что в потоке Kafka, через который отправляют логи и что-то еще.
</p><p>А еще python - однопоточный, и в реализации за место под солнцем борется основной поток и поток с кафкой. И тут важно, чтобы кафка не мешала основному процессы. Поток кафки вынесли в отдельный процесс, и начали передавать через unix pipe. B это дало очень приятный прирост - снизили время ответа и дисперсию. Потому что еще и сборка мысора в основном процессе стала эффективнее.
</p><p>Еще один анализ - распределение запросов по подам. Обнаружили, что оно не равномерно. Почему так? Оказалось, что на нодах поднято несколько ingress, каждый из которых балансировал независимо, и поэтому получался эффект неравномерной нагрузки. Поскольку маршрутизация запроса дешева, то ее перевели на один из ingress, а остальные два работают в active standby режиме - и нагрузка стала равномерной.
</p><p>Еще одна проблема - фон таймаутов, которые случаются в одно время: 18, 25, 5, 35, 55. Оказалось это рестарт подов и джобы обновления конфигурации внутреннего балансировщика и сканирование безопасности. В теории это можно разнести по времени на разных нодах и учесть в балансировщике, но это - сложно. Применили простое решение: на ingress-контроллере снизили таймаут до 7мс и сделали retry: если запрос попал туда, где в моменте напряженно - оправим его в другое место. И это сработало, фон ушел.
</p><p>Уроки.
</p>
<ul><li> Влияние алгоритма - даже выше, чем язык. Надо сразу смотреть.</li>
<li> Если у вас высокие требования - проверьте, что инфраструктура в принципе может с ними справится и что для этого нужна, на какой-нибудь тривиальной реализации. Если бы они это сделали, то проблемы были бы обнаружены сразу, а не при выкатке, и над ними можно было бы работать параллельно с основной разработкой. </li>
<li> Над оптимизацией работали в devops-инженеры, и у них были гипотезы про потенциальные проблемы. Можно было придти к ним на этапе проектирования и учесть. Это потенциально преждевременная оптимизация. но в данном случае понятно, что требования к сервису очень жесткие. </li></ul>
<h1><span class="mw-headline" id=".D0.9D.D0.B8.D0.BA.D0.B8.D1.82.D0.B0_.D0.A0.D1.8C.D1.8F.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A2.D0.B8.D0.BD.D1.8C.D0.BA.D0.BE.D1.84.D1.84._.D0.9A.D0.B0.D0.BA_.D1.81_.D0.BF.D0.BE.D0.BC.D0.BE.D1.89.D1.8C.D1.8E_event_sourcing_.D0.BC.D1.8B_.D0.BE.D1.80.D0.B3.D0.B0.D0.BD.D0.B8.D0.B7.D0.BE.D0.B2.D0.B0.D0.BB.D0.B8_.D0.BF.D0.BE.D1.81.D1.82.D0.B0.D0.B2.D0.BA.D1.83_.D0.B4.D0.B0.D0.BD.D0.BD.D1.8B.D1.85_.D0.B8_.D0.B0.D0.BA.D1.82.D1.83.D0.B0.D0.BB.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8E_.D1.81.D1.82.D1.80.D1.83.D0.BA.D1.82.D1.83.D1.80.D1.8B_.D0.B4.D0.BB.D1.8F_.D0.B1.D0.BE.D0.BB.D0.B5.D0.B5_2000_.D1.82.D0.B0.D0.B1.D0.BB.D0.B8.D1.86">Никита Рьянов из Тинькофф. Как с помощью event sourcing мы организовали поставку данных и актуализацию структуры для более 2000 таблиц</span></h1>
<p>На этом докладе тоже было переполнение зала, я слушал стоя, поэтому записать не получилось. Но доклад интересный, поэтому кратко напишу резюме. Идея в том, чтобы перейти от стандартного способа передачи данных в хранилище, основанном на change data capture к event sourcing для того, чтобы обеспечить возможность оперативного изменения структуры без остановки процесса, при очень большом количестве таблиц, которые непрерывно дорабатываются. При изменении данных возникает событие, которое хранит новый слепок данных, описываемый с помощью json. Сами структуры данных также описываются с помощью json и встраиваются в поток событий. И это дает возможность обработать эти изменения корректно. Решение интересное, так что если вы занимаетесь задачами передачи данных динамической структуры. не обязательно в хранилище - то стоит посмотреть.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-11-06:_%D0%9F%D0%98%D0%A0-2023_-_%D1%80%D0%B0%D0%B7%D0%B2%D0%B8%D1%82%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B4%D0%BE%D0%BB%D0%B6%D0%B0%D0%B5%D1%82%D1%81%D1%8F2023-11-06: ПИР-2023 - развитие продолжаетсяMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-11-06T11:31:02Z2023-11-15T13:46:04Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>В начале сентября, как обычно, был на <a rel="nofollow" class="external text" href="http://festpir.ru/"><b>ПИР</b></a> — большой конференции тренеров и коучей, на которой они встречаются друг с другом и с заказчиками и обмениваются опытом. Для меня эта конференция — чувствительный индикатор времени и место встречи с интересными людьми. Как всегда, насыщенная программа с 10 утра до 10 вечера, а потом — общение и песни до глубокой ночи.
</p><p>Как обычно, я публиковал заметки в ходе конференции, а теперь собираю их в отчет. По некоторым выступлениям я не успел опубликовать заметки в ходе конференции, в отчете они есть. И отчет будет дополняться: в этом году был отдельный трек online-выступлений, на котором было очень много интересных спикеров — они не смогли быть лично, я планирую часть из них посмотреть.
</p>
<pre>15.11 посмотрел <a href="#.D0.9C.D0.B0.D1.80.D0.BA_.D0.A0.D0.BE.D0.B7.D0.B8.D0.BD._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B5_.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.B0_-_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D0.BF.D0.B5.D1.81.D0.BD.D0.B8">#Марк Розин. Новые времена - новые песни</a>
</pre>
<p>А пока — про общее впечатление. Есть ощущение, что для России уход западных консультантов принес пользу. Потому активизировал собственное развитие. При этом идет синтез различных методов, собственных и западных, его делают с учетом особенностей культуры. Раньше это делали, но отчасти стеснялись, «мы тут докрутили, но совсем немного», а сейчас достаточно четко формулируют как собственное развитие. Ну и отношение тоже изменилось, если раньше западные методы представляли собой сияющее будущее, а неудача могла быть связана исключительно с криворуким применением, то теперь этот ореол поблек, идет трезвое рассмотрение. Я не хочу сказать, что описанного отношения раньше не было совсем. Естественно, оценки были самые разные. Но сейчас отчетливо сместилась медиана. Во всяком случае, по моим впечатлением, такие штуки плохо измеримы.
</p><p>Для меня важно, что это развитие происходит для Спиральной динамики — потому что я считаю эту систему наиболее адекватно описывающей ценностных изменений современности мира при переходе от индустриального общества к цифровому миру. На ПИР Сергей и Виктория Бехтеревы рассказывали свою интерпретацию, у них вышла книга. И они не одни в России, есть Марк Розин, у которого был интереснейший доклад об этом на прошлом ПИР и тоже выходят книги, есть Анатолий Баляев, и у меня тоже есть материалы, развивающие подход. И очень важно, что хотя эти ветки идут параллельно, взаимодействие между авторами идет в режиме взаимного обогащения идеями, а не выяснения, кто прав. Потому что целью является не теоретическая правота, а практическое применение.
</p><p>Отмечу, что уровни Спиральной динамики представляют собой согласованные между конструкции смыслов, которыми нагружаются одни и те же слова: ответственность, эффективность, справедливость и так далее. Пару лет назад у меня был доклад об этом на ПИР-2020 <a href="https://mtsepkov.org/%D0%9F%D0%B5%D1%80%D0%B5%D0%BE%D1%81%D0%BC%D1%8B%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D1%8F%D0%BC_%D0%A1%D0%BF%D0%B8%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D0%BA%D0%B8_(%D0%9F%D0%98%D0%A0-2020)" title="Переосмысление бизнес-понятий по уровням Спиральной динамики (ПИР-2020)">Переосмысление бизнес-понятий по уровням Спиральной динамики</a>. А на этом ПИР было довольно много докладов, которые как раз фокусировались на проблеме разного понимания одних и тех же слов, это — актуальная тема.
</p><p>На этом ПИРе я тоже выступал, мой доклад <a href="https://mtsepkov.org/%D0%AF_%D0%B8_%D0%BC%D0%BE%D0%B8_%D0%B0%D0%B2%D0%B0%D1%82%D0%B0%D1%80%D1%8B_%D0%B2_%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B0%D0%BA%D0%BB%D0%B5_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_(%D0%9F%D0%98%D0%A0-2023)" title="Я и мои аватары в спектакле жизни (ПИР-2023)"><b>Я и мои аватары в спектакле жизни</b></a> — развитие темы самоопределения, по которой у меня были доклады на прошлом ПИРе и дрцугих конференциях и написана серия статей, смотри <a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Категория:Самоопределение</b></a>. Для самоопределения нужны представления о самом себе, модель личности человека. Об этом и был доклад. Видео уже опубликовано.
</p><p>А теперь — про другие доклады. Сначала заметки, опубликованные в ходе ПИР, потом те, которые я слушал, но опубликовать не успел: Юлиана Слащева, Марина Починок, Аркадий Бондарь, Вячеслава Летуновский, Дмитрий Доценко и другие. А здесь я перечислю своих фаворитов.
</p>
<ul><li> <a href="#.D0.9C.D1.83.D0.B6.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.A2.D0.B0.D1.82.D1.8C.D1.8F.D0.BD.D0.B0._.D0.A1.D1.87.D0.B0.D1.81.D1.82.D1.8C.D0.B5_.2F_.D0.9B.D1.8C.D0.B7.D1.8F_.D0.BD.D0.B0_.D0.B3.D1.80.D0.B0.D0.BD.D0.B8_.D1.84.D0.BE.D0.BB.D0.B0">#Мужицкая Татьяна. Счастье / Льзя на грани фола</a>. Вау-доклад, искрометный и по делу. Как сделать, чтобы рассказанное доходило? Есть простая БЛЯ-модель из трех пунктов: Безумненько, Легко и Ясно.</li>
<li> <a href="#.D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2_.D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9.2C_.D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2.D0.B0_.D0.92.D0.B8.D0.BA.D1.82.D0.BE.D1.80.D0.B8.D1.8F._7_.D0.BF.D1.83.D1.82.D0.B5.D0.B9_.D0.B8_7_.D0.B2.D0.B5.D0.BB.D0.B8.D0.BA.D0.B8.D1.85_.D0.B8.D0.B3.D1.80:_.D0.BF.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B0_.D0.B0.D0.B4.D0.B0.D0.BF.D1.82.D0.B0.D1.86.D0.B8.D0.B8_.D1.81.D0.BF.D0.B8.D1.80.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B9_.D0.B4.D0.B8.D0.BD.D0.B0.D0.BC.D0.B8.D0.BA.D0.B8_.D0.B2_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B5_.D0.B8_.D0.B6.D0.B8.D0.B7.D0.BD.D0.B8">#Бехтерев Сергей, Бехтерева Виктория. 7 путей и 7 великих игр: практика адаптации спиральной динамики в бизнесе и жизни</a> — собственное развитие Сергеем и Викторией модели спиральной динамики и оригинальная интерпретация через игры, в которые играют люди.</li>
<li> <a href="#.D0.90.D0.BB.D1.84.D0.B5.D1.80.D0.BE.D0.B2_.D0.9F.D0.B0.D0.B2.D0.B5.D0.BB._.D0.9D.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5_.D0.BE.D1.81.D0.BE.D0.B1.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Алферов Павел. Национальные особенности управления</a> — роскошный доклад о национальных особенностях, с юмором и примерами. Которые поясняют, почему конструкции из книг не работают. И это не только личный опыт Павла, это исследования. В докладе каждую особенность разобрали отдельно, а в конце было — какая адаптация нужна проектному подходу, чтобы он за работал.</li>
<li> <a href="#.D0.AE.D1.80.D0.B8.D0.B9_.D0.9F.D1.80.D0.BE.D1.81.D0.BA.D1.83.D1.80.D0.BD.D1.8F._.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8_.D0.BF.D0.BE-.D1.80.D1.83.D1.81.D1.81.D0.BA.D0.B8:_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_5_.D0.B2.D1.81.D1.82.D1.80.D0.B5.D1.87">#Юрий Проскурня. Управление изменениями по-русски: модель 5 встреч</a>: модель интересна, а история про российское применение ADKAR — вообще превосходна.</li>
<li> <a href="#.D0.A6.D1.83.D0.BA.D0.B5.D1.80._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D1.88.D0.BA.D0.BE.D0.BB.D0.B0_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Цукер. Русская школа мышления</a> — суперинтересный доклад про русские школы мышления.</li>
<li> <a href="#.D0.9C.D0.B0.D1.80.D0.BA_.D0.A0.D0.BE.D0.B7.D0.B8.D0.BD._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B5_.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.B0_-_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D0.BF.D0.B5.D1.81.D0.BD.D0.B8">#Марк Розин. Новые времена - новые песни</a> - комплексное осмысление "нового мировоззрения" и его отличия от мировоззрения 20 века.</li>
<li> <a href="#.D0.94.D0.BE.D1.86.D0.B5.D0.BD.D0.BA.D0.BE_.D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9._.D0.AD.D1.82.D0.B0.D0.BB.D0.BE.D0.BD.D0.BD.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C:_.D0.BF.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.9F.D0.B8.D0.A0.D0.B5.D0.B2.D0.BE.D0.B4_.D0.B0.D1.83.D1.82.D1.81.D0.BE.D1.80.D1.81.D0.B8.D0.BD.D0.B3.D0.B0_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B9">#Доценко Дмитрий. Эталонная модель: правильный ПиРевод аутсорсинга бизнес-функций</a> — очень интересный взгляд на аутсорсинг ИТ компании, не просто аутсорсинг исполнения проектов автоматизации, а целиком, с управлением. Когда-то админ мог быть мастером на все руки и закрывать все потребности, а сейчас — нет, есть много узких специалистов, которым нужно квалифицированное управление и заказ. И поэтому для небольших компаний аутсорсинг — реальный выход, но ИТ — сложнее, потому что больше специфики.</li>
<li> <a href="#.D0.9A.D0.B8.D0.B7.D0.B5.D0.B5.D0.B2_.D0.92.D0.B5.D0.BD.D0.B8.D0.B0.D0.BC.D0.B8.D0.BD._.D0.9F.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B8_.D0.B8_.D1.82.D0.B5.D1.85.D0.BD.D0.BE.D0.BB.D0.BE.D0.B3.D0.B8.D0.B8_.D0.B4.D0.BB.D1.8F_.D1.83.D1.81.D0.BA.D0.BE.D1.80.D0.B5.D0.BD.D0.BD.D0.BE.D0.B3.D0.BE_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B0">#Кизеев Вениамин. Практики и технологии для ускоренного развития бизнеса</a> — замечательный рассказ о создании обучающего курса по проектному управлению с помощью ИИ. Использовалось несколько разных ИИ, с помощью которых курс был сделан полностью — содержание, тестовые задания, синтезирован образ и голос преподавателя, который его читал. Люди тоже участвовали: давали задания, проверяли курс и давали задания на доработку, интегрировали созданное разными ИИ. И занимает это неделю от задания до публикации вместо нескольких месяцев с преподавателем-человеком.</li>
<li> <a href="#.D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80_.D0.9F.D1.80.D0.BE.D1.85.D0.BE.D1.80.D0.BE.D0.B2._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Александр Прохоров. Русская модель управления</a>. Про два режима русского общества: (1) стабильность и застой и (2) авральный прорыв через вызовы я слышал много раз в разных контекстов. Но в этом докладе был замечательный исторический обзор истории России выделением этих режимов.</li>
<li> <a href="#.D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.91.D0.BE.D1.87.D0.B0.D1.80.D0.BE.D0.B2.2C_.D0.A1.D0.B5.D0.BD.D0.B5.D0.B6._.D0.A7.D0.B5.D0.BB.D0.BE.D0.B2.D0.B5.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_.D0.BA.D0.B0.D0.BF.D0.B8.D1.82.D0.B0.D0.BB_.D1.81.D1.82.D1.80.D0.B0.D0.BD.D1.8B">#Сергей Бочаров, Сенеж. Человеческий капитал страны</a> — многоплановые размышления о человеческом капитале страны: демография, образование, развитие госслужащих.</li></ul>
<p>А теперь — заметки с докладов.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>В начале сентября, как обычно, был на <a rel="nofollow" class="external text" href="http://festpir.ru/"><b>ПИР</b></a> — большой конференции тренеров и коучей, на которой они встречаются друг с другом и с заказчиками и обмениваются опытом. Для меня эта конференция — чувствительный индикатор времени и место встречи с интересными людьми. Как всегда, насыщенная программа с 10 утра до 10 вечера, а потом — общение и песни до глубокой ночи.
</p><p>Как обычно, я публиковал заметки в ходе конференции, а теперь собираю их в отчет. По некоторым выступлениям я не успел опубликовать заметки в ходе конференции, в отчете они есть. И отчет будет дополняться: в этом году был отдельный трек online-выступлений, на котором было очень много интересных спикеров — они не смогли быть лично, я планирую часть из них посмотреть.
</p>
<pre>15.11 посмотрел <a href="#.D0.9C.D0.B0.D1.80.D0.BA_.D0.A0.D0.BE.D0.B7.D0.B8.D0.BD._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B5_.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.B0_-_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D0.BF.D0.B5.D1.81.D0.BD.D0.B8">#Марк Розин. Новые времена - новые песни</a>
</pre>
<p>А пока — про общее впечатление. Есть ощущение, что для России уход западных консультантов принес пользу. Потому активизировал собственное развитие. При этом идет синтез различных методов, собственных и западных, его делают с учетом особенностей культуры. Раньше это делали, но отчасти стеснялись, «мы тут докрутили, но совсем немного», а сейчас достаточно четко формулируют как собственное развитие. Ну и отношение тоже изменилось, если раньше западные методы представляли собой сияющее будущее, а неудача могла быть связана исключительно с криворуким применением, то теперь этот ореол поблек, идет трезвое рассмотрение. Я не хочу сказать, что описанного отношения раньше не было совсем. Естественно, оценки были самые разные. Но сейчас отчетливо сместилась медиана. Во всяком случае, по моим впечатлением, такие штуки плохо измеримы.
</p><p>Для меня важно, что это развитие происходит для Спиральной динамики — потому что я считаю эту систему наиболее адекватно описывающей ценностных изменений современности мира при переходе от индустриального общества к цифровому миру. На ПИР Сергей и Виктория Бехтеревы рассказывали свою интерпретацию, у них вышла книга. И они не одни в России, есть Марк Розин, у которого был интереснейший доклад об этом на прошлом ПИР и тоже выходят книги, есть Анатолий Баляев, и у меня тоже есть материалы, развивающие подход. И очень важно, что хотя эти ветки идут параллельно, взаимодействие между авторами идет в режиме взаимного обогащения идеями, а не выяснения, кто прав. Потому что целью является не теоретическая правота, а практическое применение.
</p><p>Отмечу, что уровни Спиральной динамики представляют собой согласованные между конструкции смыслов, которыми нагружаются одни и те же слова: ответственность, эффективность, справедливость и так далее. Пару лет назад у меня был доклад об этом на ПИР-2020 <a href="https://mtsepkov.org/%D0%9F%D0%B5%D1%80%D0%B5%D0%BE%D1%81%D0%BC%D1%8B%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D1%8F%D0%BC_%D0%A1%D0%BF%D0%B8%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D0%BA%D0%B8_(%D0%9F%D0%98%D0%A0-2020)" title="Переосмысление бизнес-понятий по уровням Спиральной динамики (ПИР-2020)">Переосмысление бизнес-понятий по уровням Спиральной динамики</a>. А на этом ПИР было довольно много докладов, которые как раз фокусировались на проблеме разного понимания одних и тех же слов, это — актуальная тема.
</p><p>На этом ПИРе я тоже выступал, мой доклад <a href="https://mtsepkov.org/%D0%AF_%D0%B8_%D0%BC%D0%BE%D0%B8_%D0%B0%D0%B2%D0%B0%D1%82%D0%B0%D1%80%D1%8B_%D0%B2_%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B0%D0%BA%D0%BB%D0%B5_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B8_(%D0%9F%D0%98%D0%A0-2023)" title="Я и мои аватары в спектакле жизни (ПИР-2023)"><b>Я и мои аватары в спектакле жизни</b></a> — развитие темы самоопределения, по которой у меня были доклады на прошлом ПИРе и дрцугих конференциях и написана серия статей, смотри <a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D0%B0%D0%BC%D0%BE%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5" title="Категория:Самоопределение"><b>Категория:Самоопределение</b></a>. Для самоопределения нужны представления о самом себе, модель личности человека. Об этом и был доклад. Видео уже опубликовано.
</p><p>А теперь — про другие доклады. Сначала заметки, опубликованные в ходе ПИР, потом те, которые я слушал, но опубликовать не успел: Юлиана Слащева, Марина Починок, Аркадий Бондарь, Вячеслава Летуновский, Дмитрий Доценко и другие. А здесь я перечислю своих фаворитов.
</p>
<ul><li> <a href="#.D0.9C.D1.83.D0.B6.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.A2.D0.B0.D1.82.D1.8C.D1.8F.D0.BD.D0.B0._.D0.A1.D1.87.D0.B0.D1.81.D1.82.D1.8C.D0.B5_.2F_.D0.9B.D1.8C.D0.B7.D1.8F_.D0.BD.D0.B0_.D0.B3.D1.80.D0.B0.D0.BD.D0.B8_.D1.84.D0.BE.D0.BB.D0.B0">#Мужицкая Татьяна. Счастье / Льзя на грани фола</a>. Вау-доклад, искрометный и по делу. Как сделать, чтобы рассказанное доходило? Есть простая БЛЯ-модель из трех пунктов: Безумненько, Легко и Ясно.</li>
<li> <a href="#.D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2_.D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9.2C_.D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2.D0.B0_.D0.92.D0.B8.D0.BA.D1.82.D0.BE.D1.80.D0.B8.D1.8F._7_.D0.BF.D1.83.D1.82.D0.B5.D0.B9_.D0.B8_7_.D0.B2.D0.B5.D0.BB.D0.B8.D0.BA.D0.B8.D1.85_.D0.B8.D0.B3.D1.80:_.D0.BF.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B0_.D0.B0.D0.B4.D0.B0.D0.BF.D1.82.D0.B0.D1.86.D0.B8.D0.B8_.D1.81.D0.BF.D0.B8.D1.80.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B9_.D0.B4.D0.B8.D0.BD.D0.B0.D0.BC.D0.B8.D0.BA.D0.B8_.D0.B2_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B5_.D0.B8_.D0.B6.D0.B8.D0.B7.D0.BD.D0.B8">#Бехтерев Сергей, Бехтерева Виктория. 7 путей и 7 великих игр: практика адаптации спиральной динамики в бизнесе и жизни</a> — собственное развитие Сергеем и Викторией модели спиральной динамики и оригинальная интерпретация через игры, в которые играют люди.</li>
<li> <a href="#.D0.90.D0.BB.D1.84.D0.B5.D1.80.D0.BE.D0.B2_.D0.9F.D0.B0.D0.B2.D0.B5.D0.BB._.D0.9D.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5_.D0.BE.D1.81.D0.BE.D0.B1.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Алферов Павел. Национальные особенности управления</a> — роскошный доклад о национальных особенностях, с юмором и примерами. Которые поясняют, почему конструкции из книг не работают. И это не только личный опыт Павла, это исследования. В докладе каждую особенность разобрали отдельно, а в конце было — какая адаптация нужна проектному подходу, чтобы он за работал.</li>
<li> <a href="#.D0.AE.D1.80.D0.B8.D0.B9_.D0.9F.D1.80.D0.BE.D1.81.D0.BA.D1.83.D1.80.D0.BD.D1.8F._.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8_.D0.BF.D0.BE-.D1.80.D1.83.D1.81.D1.81.D0.BA.D0.B8:_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_5_.D0.B2.D1.81.D1.82.D1.80.D0.B5.D1.87">#Юрий Проскурня. Управление изменениями по-русски: модель 5 встреч</a>: модель интересна, а история про российское применение ADKAR — вообще превосходна.</li>
<li> <a href="#.D0.A6.D1.83.D0.BA.D0.B5.D1.80._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D1.88.D0.BA.D0.BE.D0.BB.D0.B0_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Цукер. Русская школа мышления</a> — суперинтересный доклад про русские школы мышления.</li>
<li> <a href="#.D0.9C.D0.B0.D1.80.D0.BA_.D0.A0.D0.BE.D0.B7.D0.B8.D0.BD._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B5_.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.B0_-_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D0.BF.D0.B5.D1.81.D0.BD.D0.B8">#Марк Розин. Новые времена - новые песни</a> - комплексное осмысление "нового мировоззрения" и его отличия от мировоззрения 20 века.</li>
<li> <a href="#.D0.94.D0.BE.D1.86.D0.B5.D0.BD.D0.BA.D0.BE_.D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9._.D0.AD.D1.82.D0.B0.D0.BB.D0.BE.D0.BD.D0.BD.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C:_.D0.BF.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.9F.D0.B8.D0.A0.D0.B5.D0.B2.D0.BE.D0.B4_.D0.B0.D1.83.D1.82.D1.81.D0.BE.D1.80.D1.81.D0.B8.D0.BD.D0.B3.D0.B0_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B9">#Доценко Дмитрий. Эталонная модель: правильный ПиРевод аутсорсинга бизнес-функций</a> — очень интересный взгляд на аутсорсинг ИТ компании, не просто аутсорсинг исполнения проектов автоматизации, а целиком, с управлением. Когда-то админ мог быть мастером на все руки и закрывать все потребности, а сейчас — нет, есть много узких специалистов, которым нужно квалифицированное управление и заказ. И поэтому для небольших компаний аутсорсинг — реальный выход, но ИТ — сложнее, потому что больше специфики.</li>
<li> <a href="#.D0.9A.D0.B8.D0.B7.D0.B5.D0.B5.D0.B2_.D0.92.D0.B5.D0.BD.D0.B8.D0.B0.D0.BC.D0.B8.D0.BD._.D0.9F.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B8_.D0.B8_.D1.82.D0.B5.D1.85.D0.BD.D0.BE.D0.BB.D0.BE.D0.B3.D0.B8.D0.B8_.D0.B4.D0.BB.D1.8F_.D1.83.D1.81.D0.BA.D0.BE.D1.80.D0.B5.D0.BD.D0.BD.D0.BE.D0.B3.D0.BE_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B0">#Кизеев Вениамин. Практики и технологии для ускоренного развития бизнеса</a> — замечательный рассказ о создании обучающего курса по проектному управлению с помощью ИИ. Использовалось несколько разных ИИ, с помощью которых курс был сделан полностью — содержание, тестовые задания, синтезирован образ и голос преподавателя, который его читал. Люди тоже участвовали: давали задания, проверяли курс и давали задания на доработку, интегрировали созданное разными ИИ. И занимает это неделю от задания до публикации вместо нескольких месяцев с преподавателем-человеком.</li>
<li> <a href="#.D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80_.D0.9F.D1.80.D0.BE.D1.85.D0.BE.D1.80.D0.BE.D0.B2._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">#Александр Прохоров. Русская модель управления</a>. Про два режима русского общества: (1) стабильность и застой и (2) авральный прорыв через вызовы я слышал много раз в разных контекстов. Но в этом докладе был замечательный исторический обзор истории России выделением этих режимов.</li>
<li> <a href="#.D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.91.D0.BE.D1.87.D0.B0.D1.80.D0.BE.D0.B2.2C_.D0.A1.D0.B5.D0.BD.D0.B5.D0.B6._.D0.A7.D0.B5.D0.BB.D0.BE.D0.B2.D0.B5.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_.D0.BA.D0.B0.D0.BF.D0.B8.D1.82.D0.B0.D0.BB_.D1.81.D1.82.D1.80.D0.B0.D0.BD.D1.8B">#Сергей Бочаров, Сенеж. Человеческий капитал страны</a> — многоплановые размышления о человеческом капитале страны: демография, образование, развитие госслужащих.</li></ul>
<p>А теперь — заметки с докладов.
</p>
<h1><span class="mw-headline" id=".D0.AE.D1.80.D0.B8.D0.B9_.D0.9F.D1.80.D0.BE.D1.81.D0.BA.D1.83.D1.80.D0.BD.D1.8F._.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8_.D0.BF.D0.BE-.D1.80.D1.83.D1.81.D1.81.D0.BA.D0.B8:_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_5_.D0.B2.D1.81.D1.82.D1.80.D0.B5.D1.87">Юрий Проскурня. Управление изменениями по-русски: модель 5 встреч</span></h1>
<p>Западные модели, прийдя в Россию, подвергаются суровой русификации. Например, ADKAR в классике: Awareness — понимание необходимости изменений; Desire — желание участвовать в изменениях; Knowledge — знание, что требуется сделать; Ability — умение/способность воплощать изменения; Reinforcement — подкрепление реализованных изменений.
</p><p>По-русски начинаем с конца, с подкрепления: руководство говорит "все применять продуктовое управление, отрапортовать. Люди как-то это воспринимают, пытаются что-то делать, получают способность, и рапортуют «мы изменились». И тут-то их начинают учить, они говорят «надо же, мы так и делаем, а вот тут что-то интересное, тоже надо». И от привычки действовать по-другому у них появляется желание. После чего руководство, наконец, всех собирает и рассказывает — зачем было все это. Весело, но не слишком эффективно.
</p><p>Особенность русской культуры в том, что у нас не аккуратная конструкция Run-Change, а два режима: Ахтунг и Релакс. Для успеха вовлечения должен быть режим Ахтунг, аврал — тогда появляется участие руководства и вовлечение команды. А иначе все спускается на тормозах, методы многообразны. В докладе было 10:
</p>
<ul><li> тени не отбрасываем, в зеркале не отражаемся — никаких переговоров с реформаторами</li>
<li> обещать не значить жениться — откладываем на неделю</li>
<li> 200 небольших замечаний — мы за, но надо же качественно</li>
<li> письма мелким почерком — в переписке</li>
<li> кинжал в спину — ходить за спиной инициатора к вышестоящему и говорить, что все не идет</li>
<li> Telegram-ОПГ. Чат противников для координации и слив инфы между.</li>
<li> По формальным признакам</li>
<li> Стрелочник</li>
<li> Балласт — на изменения самого неспособного</li>
<li> Шантаж</li></ul>
<p>Он задумался о методике с учетом русских особенностей. Придумал, применяет, рассказал. В ней 5 встреч, которые создают искусственные авралы в ключевых точках. К стандартному пути Решение топов — Пилот — Масштабирование добавлено две стадии. Экскурсия среднему менеджменту после решения топов, где покажут новый способ работы, пусть на бумаге и примерах. Главная цель — они должны скинуть все возмущение, главное — с ним не спорить, просто записать и предложить прислать замечания, в этом и цель — спустить возмущение в моменте. А после масштабирования обязателен Праздник, на котором фиксируется успех проекта и раздаются грамоты.
</p><p>Каждый этап начинается встречей, обязательно с топами, которая создает аврал. К встрече обязательно готовят материалы. Есть две хитрости: на совещании топов надо договориться о личном участии топов в вовлечении персонала, и назначить все остальные встречи, поставив их в календарь топов. Фиксация встреч как раз обеспечивает аврал: если кто не успевает, предлагают выйти на самый верх, чтобы сдвинуть, обычно люди не идут.
</p><p>Конструкция простая и понятная. И работает. В том числе на масштабе, они делали переход на 1С в компании из 80 филиалов в 8 макрорегионах на 10 тысяч пользователей — по регионам, оно взлетело. Темп встреч определяется той технической работой, которую надо между ними сделать. Методика не требует особой квалификации от тех, кто применяет, наверное, поэтому консультанты ее не слишком будут любить :)
</p>
<h1><span class="mw-headline" id=".D0.94.D1.80.D0.BE.D0.B7.D0.B4.D0.BE.D0.B2.D1.81.D0.BA.D0.B8.D0.B9_.D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80._.D0.A4.D0.BE.D1.80.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.B2.D0.B7.D0.B0.D0.B8.D0.BC.D0.BE.D0.B4.D0.BE.D0.BF.D0.BE.D0.BB.D0.BD.D1.8F.D1.8E.D1.89.D0.B5.D0.B9_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B_.D0.BB.D0.B8.D0.B4.D0.B5.D1.80.D0.BE.D0.B2_.D0.BD.D0.B0_.D0.BE.D1.81.D0.BD.D0.BE.D0.B2.D0.B5_.D0.B8.D0.B7.D0.BC.D0.B5.D1.80.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BD.D0.B5.D0.B9.D1.80.D0.BE.D0.B4.D0.B8.D0.BD.D0.B0.D0.BC.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D1.85_.D1.85.D0.B0.D1.80.D0.B0.D0.BA.D1.82.D0.B5.D1.80.D0.B8.D1.81.D1.82.D0.B8.D0.BA_.D1.83.D1.87.D0.B0.D1.81.D1.82.D0.BD.D0.B8.D0.BA.D0.BE.D0.B2_.D1.81.D0.BE.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.BD.D0.BE.D0.B9_.D0.B4.D0.B5.D1.8F.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D1.81.D1.82.D0.B8">Дроздовский Александр. Формирование взаимодополняющей команды лидеров на основе измерения нейродинамических характеристик участников совместной деятельности</span></h1>
<p>Очень любопытно. Дроздовский — ученик Ильина, который всегда выступал за использование в психологии точных методов, чтобы проверять тексты, опросы и прочий нарратив, и основой для точных методов полагал дифференциальную нейрофизиологию, нейродинамику. А Александр сделал конкретный шаг — прибор, который на основе мелкой моторики эту нейродинамику меряет, по 5 характеристикам: сила нервного процесса, подвижность возбуждения, подвижность торможения, внешний баланс и внутренний баланс, каждая оценивается по 3 баллам. Прибор придуман давно как отдельное устройство, а сейчас сделан аналог на планшете. На выходе измерения 5-значный код, который очень много говорит про потенциал человека и имеет разные применения.
</p>
<ul><li> Способности к спорту, этим пользуется Александр — он работает с подготовкой параолимпийской сборной.</li>
<li> Способности к профессиям, существенно завязанным на характеристики мозга — авиадиспетчеры, летчики, машинисты поездов. Обследование хороших и слабопригодных людей, сопоставление их профилей позволило выявить существенные характеристики для профессии, и далее — оценивать по ним кандидатов.</li>
<li> Проверено соответствие между нейрофизиологическим кодом и психологическими типами MBTI и Юнга на основе опросника Кейрси. Оказалось, что психотип определяется с высокой достоверностью. А значит, по результатам измерения можно выдать не просто код, а описание соответствующего психотипа. А поскольку типы Юнга еще коррелирует со стилями руководства Адизеса, то это тоже можно определить. Без всяких опросов и субъективных мнений.</li>
<li> Можно смотреть на совместимость людей, при чем как на похожесть, так и наоборот, на их дополняемость, прогнозировать взаимоотношения, собственно, как это делают на основе MBTI, только на основе кодов. Кодов сильно больше — 343 типа.</li>
<li> Комбинируя предыдущее, и учитывая потребность стиля руководства для компании на разных стадиях жизненного цикла компании и варианты типов в управленческой команде, которые строит Адизес, можно еще и подбирать людей в управленческую команду, понимая зоны конфликтов и области дополняющего сотрудничества.</li></ul>
<p>Все эти исследования опубликованы, а сами тесты — запатентованы. Таблицы соответствия были в презентации, а еще я быстро нашел <a rel="nofollow" class="external text" href="http://work-org-psychology.ru/engine/documents/document388.pdf">статью автора 2018 года</a>, где есть основные материалы. Так что вы сами можете оценить основания для методов, в частности репрезентативность выборки. У меня есть определенные сомнения, так как для соответствия с MBTI использовалась выборка из 500 студентов, и даже если корреляция была хорошей, надо смотреть на других группах. Потому что, хотя Юнг считал, что психотип — врожденная характеристика, реально она прокачивается, и повторные тесты по MBTI показывают, что тип меняется. С другой стороны, реактивность нейронов тоже тренируется. В общем тут стоит посмотреть глубже. Но как одно из средств оперативной типологии — почему нет? Тем более, что есть маппинг не только на эти типы, но и на ряд профессиональных профилей.
</p>
<h1><span class="mw-headline" id=".D0.A0.D1.83.D1.81.D0.B8.D0.BD.D0.BE.D0.B2.D0.B0_.D0.94.D0.B8.D0.BD.D0.B0._.D0.A1.D0.B8.D0.BB.D0.B0_.D0.B2.D0.BB.D0.B8.D1.8F.D0.BD.D0.B8.D1.8F_.D1.81.D0.BC.D1.8B.D1.81.D0.BB.D0.B0_.D1.81.D0.BB.D0.BE.D0.B2_.D0.BD.D0.B0_.D0.BF.D1.80.D0.B8.D0.BD.D1.8F.D1.82.D0.B8.D0.B5_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D0.B9_.D0.B8_.D1.84.D0.BE.D1.80.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.B2.D0.BD.D1.83.D1.82.D1.80.D0.B5.D0.BD.D0.BD.D0.B5.D0.B9_.D0.BC.D0.BE.D1.82.D0.B8.D0.B2.D0.B0.D1.86.D0.B8.D0.B8">Русинова Дина. Сила влияния смысла слов на принятие решений и формирование внутренней мотивации</span></h1>
<p>Дина — главный врач поликлиники, доцент факультета педиатрии, председатель московского союза педиатров. Рассказ — личный кейс работы сначала с собой, потом — с коллективом. Лет 20 назад ее заела рутина, и в ответ на причитания они от одной подруги получила: если готова меняться — есть средство, Фэн-Шуй. В практическом залоге — поехали к тебе, перестроим квартиру. Они что-то выбросили, переставили мебель — и это реально повлияло на ощущение жизни, пространство жизни стало нравится. Дальше она захотела разобраться, посмотрела книги. И нашла там простые вопросы: довольна ли ты тем, что окружает; приносит ли предмет энергетику; полезен ли он для меня. И начала спрашивать не только про предметы. но и про людей, и дальше разбираться с этим. Жизнь сильно изменилась.
</p><p>Тут был вопрос: а если живешь не один, и то, что хорошо тебе — плохо другому, то как? Ответ был — договаривайтесь, хотя это не просто. Из своего опыта хочу подтвердить — действительно договариваться реально непросто, но возможно. И если тебе что-то важно, то надо объяснять — почему и насколько, это помогает в поиске вариантов, которые устроят обоих.
</p><p>Второй такт — применить на работе. Когда принимала поликлинику, все врачи были отдельно, на общались. Она зашла к каждому и пожала руку, И для коллег это было грандиозно, а для нее это обычное действие. Первый год был сложный — подковерные игры и так далее. И искала формы: кофе с главным врачом с беседой на свободные темы, телеграм-канал и так далее. Старалась вдохнуть жизнь — и удалось. Сейчас кодовое слово — обнимашки. Первый раз предложила, была настороженность, а получилось — хорошо, стало регулярным.
</p><p>Меня эта история заставила задуматься вот о чем. Техники, о которых Лина говорила — простые, если коротко — это внимание к окружению и оценка его уместности. Почему же они явились откровением для взрослого человека? Это же не единичная история. Штука в том, что такому вниманию не учат в школе. А не учат по очень простой причине: подросток, если его научить так смотреть на жизнь, начнет активно убирать из окружения неприятных учителей, неприятные предметы, требовать смыслов. И станет неуправляемым. И кстати, если родители учат быть быть таким внимательным, то дальше им объяснять ребенку, как дальше жить и учиться в реальной среде. Взрослый то, особенно если пожил иначе — это понимает лучше.
</p><p>В телеграм было обсуждение с Evgeny Adamov.
</p>
<dl><dd> Evgeny Adamov: Есть много неприятных, но полезных вещей.</dd>
<dd> mtsepkov: Важно это оценивать и соблюдать баланс. Не должна быть жизнь только из неприятных вещей, да еще с уверенностью, что такая жизнь — естественна и иначе не бывает. Временные трудности при обучении новому неизбежны, но их надо отличать от вечной каторги. Есть отдельная культура преодоления трудностей, и есть диеты специально из невкусных вещей, чтобы ты еще гордился преодолением, а по факту жил мучеником.</dd>
<dd> Evgeny Adamov: Согласен. Поэтому многи практики советуют работу с наставником, так как в одиночку сложно это оценить или пройти сквозь зону дискомфорта</dd>
<dd> mtsepkov: Тут согласен. Только надо учитывать, что наставник будет транслировать свои представления о балансе, не факт, что они вам подходят. Тут, скорее, нужен коуч или ментор.</dd></dl>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80_.D0.9F.D1.80.D0.BE.D1.85.D0.BE.D1.80.D0.BE.D0.B2._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">Александр Прохоров. Русская модель управления</span></h1>
<p>Менеджменту — около 100 лет. Флагманом развития индустрии была Англия, а затем — Штаты и не удивительно, учебники менеджмента фиксируют именно эту модель управления и связанную с западным культурным кодом. В 70-к, когда японские автомобилестроители захватили рынок США, выяснилось, что эта модель — не единственная успешная, изучение дало Lean, систему Тойоты и другие составляющие японской модели. Концепт многих моделей завоевал жизнь, появилась скандинавская, континентальная, арабская, китайская и русская.
</p><p>Русская умеет работать в двух режимах: (1) стабильность и застой и (2) авральный прорыв через нестабильную ситуацию. Объясняется это особенностями развития России в период сельскохозяйственного общества: это зона северного земледелия с активным периодом 4-5 месяцев против 7-8 в Германии или Франции в районе Луары и круглогодичного на юге Европы. Плюс в полтора-два раза меньшая урожайность. В результате интенсивность труда крестьянина летом в 4-5 раз превышала интенсивность труда крестьянина в Европе. А в долгую зиму наоборот, лень чтобы мало двигаться и экономить энергию, но при этом надо не отупеть, а то летом не сможешь действовать — отсюда склонность к наукам и фольклор с длинными сказками, отсюда же и лень.
</p><p>Это закреплено персонажами русских сказок. Дед только посадил репку и дальше сразу проблема собрать урожай, которую решают привлекая всех-всех на помощь. Курочка Ряба — простому человеку не разбогатеть, прока не будет, а потерять — легко. Колобок — вы будете являться объектом мобилизации, и только хитростью уклоняться, и все равно сожрут. Сказок, подобных японским, где черепаха за счет тренировок пришла быстрее зайца, который все время отвлекался, у русских нет.
</p><p>Я хочу отметить, что в двух режимах развития, когда стабильность сменяется временем перемен, ничего специфично русского нет, это известная модель волнового развития с S-кривыми, периоды изменений свойственны всем странам. Другое дело, что модель управления в условиях стабильности просто проще, и именно ее разработали и зафиксировали первой. Но, вполне возможно, что благодаря особенностям России, русская модель управления ориентирована как раз на периоды изменений.
</p><p>Периоды в истории России всем известны: стабильность — ранние Романовы, Николай I и Александр III, Брежнев, Путин, перемены — Иван Грозный, Петр, реформы и отмена крепостного права, период революций и сталинские годы, 90-е. И Александр говорит, что сейчас снова начинается период изменений, хотя Путин по характеру больше склонен к стабильности.
</p><p>Режимы работы модели управления в двух режимах отличаются принципиально. Стабильность:
</p>
<ul><li> Уход конкуренции: сначала СМИ, потом выборы и политика, потом экономика. На входе в 2000-е была 70 рыночной, теперь 70 гос, кино то же. Как и при Брежневе. И при Александре III — коррупция великих князей и т. п.</li>
<li> Преобразования невозможны. только косметический — как милиция в полицию. 3 преобразования при Брежневе. Николай I три раза пытался крепостное право отменить.</li>
<li> Гуманное управление, за плохую работу не наказывают, выговор — наказание без наказания (это нельзя объяснить иностранцам).</li>
<li> Теряет значение идеология. При Брежневе никто не верил в коммунизм. Единая Россия — партия без программы.</li>
<li> Застой в кадровой политики: раз за плохую работу не выгоняют (только за кланы и нелояльность), то начальники долго сидят. Миллер остался главой Газпрома, несмотря на то что профукал сланцевую революцию. Так и было — Политбюро, Николай I выбирал министров навечно, боярская дума до Петра — съезд долгожителей боярства.</li>
<li> Улучшение материального уровня жизни большинства населения — одни зарабатывают, другие воруют.</li></ul>
<p>Нестабильность
</p>
<ul><li> Поощрение конкурентных отношений. Ельцин: множество партий, искусство, экономика. Сейчас тоже местами конкуренция, МО ЧВК Кадыров. Скоро придет в политику и промышленность. Сталин — нерыночная конкуренция, за выживание. Сталин «недоверие — хорошая основа для совместной работы». СП пересажал друг друга, а уклониться нельзя. Петр — впервые конкуренция в кадровую работу, до него не было вертикальных лифтов. А до Петра все места в приказах закреплены за родами и по старшинству — а Петр давал должности иностранцам и способным. И объявил, что знатность считать по способностям.</li>
<li> Появление социальных лифтов — легко сделать карьеру, прорваться к богатству. Времена Сталина, Ленина, Петра. Меньшиков — всем заправлял, был почетным членом Британской академии наук. Реформы Грозного — Адашев, и опричина.</li>
<li> Повышение роли идеологии в обществе. Без этого — не провернуть. Идеология Петра окно в Европу — разделялась молодежью. Идеология Филофея Москва — 3 Рим. Идеология коммунизма гражданской войны, размежевание общества по идеологии 90-х, даже внутри семей. Сейчас идеология требуется. Но СССР и 90-е дали такой иммунитет, вряд ли получится (его мнение).</li>
<li> Ужесточение наказаний. За плохую работу выгоняют, а то и сажают. Не выговор. Сейчас — обращение в суд.</li>
<li> Увеличение масштаба поощрений — симметрично с наказанием. Награды всех. 90-е годы рекорд — залоговые аукционы.</li>
<li> Активные преобразования структур управления.</li>
<li> Ускоренное обновление кадров, ротация</li>
<li> Гигантский перерасход ресурсов — плата за задержку назревших преобразований.</li></ul>
<h1><span class="mw-headline" id=".D0.9A.D1.83.D0.BB.D1.8C.D1.88.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.90.D0.BB.D0.B5.D0.BD.D0.B0._.C2.AB.D0.AF.D0.B7.D1.8B.D0.BA.C2.A0.E2.80.94_.D0.B4.D0.BE.D0.BC_.D0.BD.D0.B0.D1.88.D0.B5.D0.B3.D0.BE_.D0.B1.D1.8B.D1.82.D0.B8.D1.8F.C2.BB_.D0.B8.D0.BB.D0.B8_.D1.81.D0.B0.D0.BC.D0.BE.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5.C2.A0.E2.80.94_.D0.BA.D0.B0.D0.BA_.D1.81.D0.BB.D0.BE.D0.B2.D0.B0_.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D1.8F.D1.8E.D1.82_.D0.BD.D0.B0.D1.88.D1.83_.D1.80.D0.B5.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D1.81.D1.82.D1.8C">Кульшицкая Алена. «Язык — дом нашего бытия» или самопрограммирование — как слова определяют нашу реальность</span></h1>
<p>То, что мы говорим — определяет нашу реальность. Язык — ключ к творению бытия. Над языком надо работать:
</p>
<ul><li> Почистить речь — убрать слова, обороты, которые настраивают на то, что противоречит целям</li>
<li> Добавить слова, обороты, которые поддерживают продвижение к цели</li>
<li> Использовать по максимуму — не только думать и говорить осознанно, но и прописывать языковые коды</li></ul>
<p>Каждое слово — маленький акт творения. Золотое правило творения: где внимание — там и энергия. Дальше были кейсы, как изменение формулировок меняло жизнь и примеры таких изменений.
</p>
<ul><li> Работу работаю — неявный контекст рутины и негатива. Заменяем на конкретное дело, которое приносит результат и удовлетворение. Не работа, а созидание и творение.</li>
<li> Придешь — не могу (вежливо). Контекст слабости и бессилия. Правильно: не хочу или просто не приду — как решение. Ты управляешь в этом месте решением.</li>
<li> Вместо пока не сделал это — уже сделал вот эту часть</li>
<li> Вместо не получается — уже получается немного</li>
<li> Пока не сделаю это, не начну то — Начну то, как только закончу это</li>
<li> Мне не хватает — я ищу способы расширения</li>
<li> Я одинок — я ищу своего</li>
<li> Я болею — я выздоравливаю. Не поправляюсь, а стройнею и выздоравливаю.</li></ul>
<p>Частный случай этого — appreciate inquire, проект British Air: Не как терять багажа меньше, а как довозить больше.
</p><p>Практика спонтанного письма. Бумага и ручка в приятном окружении — и пишем слова, которые приносят удовольствие. 5-10 минут.
</p>
<h1><span class="mw-headline" id=".D0.97.D0.B5.D0.BC.D1.86.D0.BE.D0.B2.D0.B0_.D0.9C.D0.B0.D1.80.D0.B8.D1.8F._.D0.A3.D0.BC.D0.BE.D0.BC_.D0.A0.D0.BE.D1.81.D1.81.D0.B8.D1.8E_.D0.BD.D0.B5_.D0.BF.D0.BE.D0.BD.D1.8F.D1.82.D1.8C:_.D0.BA.D0.B0.D0.BA.D0.B8.D0.BC.D0.B8_.D0.BA.D0.B0.D1.82.D0.B5.D0.B3.D0.BE.D1.80.D0.B8.D1.8F.D0.BC.D0.B8_.D0.BC.D1.8B.D1.81.D0.BB.D0.B8.D1.82_.D1.80.D0.BE.D1.81.D1.81.D0.B8.D0.B9.D1.81.D0.BA.D0.B8.D0.B9_.D0.BF.D1.80.D0.B5.D0.B4.D0.BF.D1.80.D0.B8.D0.BD.D0.B8.D0.BC.D0.B0.D1.82.D0.B5.D0.BB.D1.8C.3F_.D0.A7.D1.82.D0.BE_.D0.BC.D0.B5.D1.88.D0.B0.D0.B5.D1.82_.D0.B5.D0.BC.D1.83_.D1.80.D0.B0.D1.81.D1.82.D0.B8_.D0.B8_.D0.BC.D0.B0.D1.81.D1.88.D1.82.D0.B0.D0.B1.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.3F">Земцова Мария. Умом Россию не понять: какими категориями мыслит российский предприниматель? Что мешает ему расти и масштабировать свой бизнес?</span></h1>
<p>Рассказ об ограничивающих убеждениях, которые мешают идти к целям. Я, правда, не слишком увидел именно российскую специфику, если сопоставлять с западными материалами, то эти там проблемы тоже есть. Но может быть другая частота, и другие детали. В любом случае. В докладе был конкретный список ограничивающих убеждений, и по каждому — комментарии. Ряд из них вызвал отклик аудитории и активные обсуждения.
</p>
<ul><li> Делать все самому. Хочешь хорошо — сделай сам, нехватка доверия и т. п.</li>
<li> Нехватка навыков управления. Не может выстроить систему. Учится (процессы, мотивация, продвижение, финансы), но может не сработать.</li>
<li> Негативный опыт: вложения без результата, реклама не сработала, поставщик кинул, партнер подвел — вдруг снова? Отмечу, что об этом хорошо говорит Валера Разгуляев: ребенок, столкнувшись с предательством друга говорит «больше не буду дружить», а взрослый знает, что люди встречаются разные, и начинает учитывать это в жизни. Но не все мыслят так по-взрослому.</li>
<li> Ограниченное видение роста. Только постепенно, маленькими шагами, не думаем про быстрые варианты</li>
<li> Состояние усталости и выгорания. Сдохший ослик не может идти. Надо фиксировать. Вместо постоянного «доделаю и отдохну»</li>
<li> Неверие в себя: вдруг не получится, долгие сомнения и взвешивания, страх ответственности и риска. Это реликты старой жизни с ограничениями.</li>
<li> Некорректная цель — не зажигает, не мотивирует, размножение на многие цели</li>
<li> Слишком долгие сроки — падает мотивация, откладываешь, отвлекаешься и вечная незавершенка. Сделай короткие этапы.</li>
<li> Мне и так достаточно, куда мне еще, вроде все хорошо — запрет на увеличение дохода. Зачем, если и так хорошо. Тут нюанс: чтобы зайти на гору, надо ее увидеть, а для этого — вылезти из ямы. Я: цель в зоне ближайшего развития</li>
<li> Чрезмерная забота о других: решение личных вопросов сотрудников, войти в положение, закрыть глаза на нарушение правил</li>
<li> Не повышать уровень жизни (хочу больше зарабатывать, а тратить не хочу, хорошая машина). Эта тема триггернула аудиторию, потому что в формулировках — следы модели, требующей безусловного рост потребления по мере подъема доходов, а эта модель сейчас сильно подвергнута сомнениям.</li>
<li> Постоянная экономия: можно обойтись без этого, можно сэкономить, не работают с помогающими специалистами.</li>
<li> Негативное отношение к успеху: ему просто повезло, попал в тренд, пришел инвестор</li>
<li> Нежелание платить за изменения: у меня нет времени, нет сил, это ж дорого, я пока изучу, попробую жить как есть</li></ul>
<p>Вообще список — достаточно известен, но штука в том, что проблема не исчезает, от того, что известна, с ней надо работать.
</p>
<h1><span class="mw-headline" id=".D0.A6.D1.83.D0.BA.D0.B5.D1.80._.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B0.D1.8F_.D1.88.D0.BA.D0.BE.D0.BB.D0.B0_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">Цукер. Русская школа мышления</span></h1>
<p>Суперинтересный доклад про русские школы мышления. Они включены в мировую повестку развития интеллектуальных навыков и технологий, но при этом имеют ряд особенностей, которые их существенно отличают. Но до особенностей — про истоки и опору этих школ.
</p>
<ul><li> Русская психологическая школа. Рубинштейн и Выготский. Дуализм мышление и деятельность</li>
<li> Тихомиров 1950е. Мышление как решение задач. Телеологическая природа мышления: когда он начинает решать задачу — он знает ответ, мозг не видит задачи, которые считает нерешаемыми. Сначала нашел решение, потом осознал. И утверждается, что нейрофизиологи подтверждают, хотя тут я бы хотел глубже познакомиться с методикой подтверждающих экспериментов.</li>
<li> Русская культурологическая школа. Бахтин, Генисаретский и др. Мы видим мир целостным, а затем его нарушаем, и от этого — несчастья.</li>
<li> Русская философская школа Лосева, продолжает Платона.</li>
<li> Русский космизм — мышление как часть космоса, единство</li>
<li> Русский марксизм = рефлексия, анализ деятельности</li>
<li> Московский методологический кружок. Щедровицкий, сращивание мышления и деятельности</li>
<li> Московский педагогический кружок. Анисимов. Как мозг учится, как перевести обучение в самообучение</li>
<li> Школа развивающего обучения Эльконина-Давыдова. Переходы из эмпирического в теоретическое и обратно</li></ul>
<p>А теперь — про особенности.
</p>
<ul><li> Поиск смысла: онтологизация любых операций и технологий, трансформация средств и инструментов в картину мира. Западные ищут инструменты и технологии, не картину мира. Мы уникальны — можем превратить в смысл любую технологию. Это делали СМД-подход, трансформационная стратегия, стратегия автоматизации, самоуправляемая организация (как смысл), CJM (не повышение NPS, а смысл обслуживание клиентов). Если смысла нет, а только алгоритмы — мы не понимаем что делать. И тут проблема переноса образования про технологии</li>
<li> Энергия в горе: акцент на фазе анализа, онтологизация проблемного поля. ОДИ (проблематизация — чем больше жопу осознали — тем больше смысла), технологии страт.сессий от перечня трудностей, инспектика</li>
<li> Направленность контроля преимущественно во вне, на территорию. Контроль и строительство внешних миров, великий авось, надежда на чудо, минимизация ответственности. В противовес осознанности и медитации. В западной традиции есть тема границ, у нас — тотально, потому что оттуда что-то придет. Прогностика, футуроогия, форсайты, проектирование будущего, сценирование рынков, гибкое стратегирование, моделирование клиентского пути. Нет моделирование собственного пути, только клиентский. Не саморазвитие менеджера, а развитие корпоративной культуры. В Англии и Азии наоборот, начинают с дизайна собственной траектории, фокус на себя.</li>
<li> Расшивание «нет». дифференциация пространства решений, работа с возможностями, сокращение невозможного. Да — предельно жесткое, обещали. А нет — это не совсем нет. У нас нет — начало игры. Европейская традиция — аналитические языки, она про жесткость нет, отсюда бизнес-процессы, табу, правовое регулирование; а да — условное, я сказал — я передумал. У нас нет инструментов прожимания «да» — оно гибкое, а там нет инструментов прожимания «нет». Практики прожимания нет — как обойти, выйти, школа нестандартного мышления, школа прорыва, школа вызова, нешаблонного мышления и креатива. Как в нет найти-таки да.</li>
<li> Строительство мы — опора на группу, коллектив, общие смыслы. Изначально думаем как вместе. А на западе — как сам. Там думают, как обеспечить свободу индивиду, а мы — как будем жить в таком мире. Школа ценностного мышления, корпоративной антропологии, школы сообществ и корпоративной культуры. Есть европейская и русская традиция антропологии, и тут разница.</li></ul>
<h1><span class="mw-headline" id=".D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2_.D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9.2C_.D0.91.D0.B5.D1.85.D1.82.D0.B5.D1.80.D0.B5.D0.B2.D0.B0_.D0.92.D0.B8.D0.BA.D1.82.D0.BE.D1.80.D0.B8.D1.8F._7_.D0.BF.D1.83.D1.82.D0.B5.D0.B9_.D0.B8_7_.D0.B2.D0.B5.D0.BB.D0.B8.D0.BA.D0.B8.D1.85_.D0.B8.D0.B3.D1.80:_.D0.BF.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B0_.D0.B0.D0.B4.D0.B0.D0.BF.D1.82.D0.B0.D1.86.D0.B8.D0.B8_.D1.81.D0.BF.D0.B8.D1.80.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B9_.D0.B4.D0.B8.D0.BD.D0.B0.D0.BC.D0.B8.D0.BA.D0.B8_.D0.B2_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B5_.D0.B8_.D0.B6.D0.B8.D0.B7.D0.BD.D0.B8">Бехтерев Сергей, Бехтерева Виктория. 7 путей и 7 великих игр: практика адаптации спиральной динамики в бизнесе и жизни</span></h1>
<p>У Сергея и Виктории вышла книга Спиральная динамика для бизнеса, они дорабатывают к изданию следующую — Спиральная динамика для жизни. Со спиральной динамикой они знакомы и применяют уже много лет, и их сообществу Бизнес со смыслом тоже уже больше семи лет, я о нем услышал на ПИР в 2017. Книга развивает и дает собственную интерпретацию системы на основе их практики. И это означает, что система живет и развивается, что меня очень радует. При чем они не одни в России, есть Марк Розин, Анатолий Баляев, и у меня тоже есть материалы. И очень важно, что хотя эти ветки идут параллельно, взаимодействие между авторами идет в режиме взаимного обогащения идеями, а не выяснения, кто прав. Потому что целью является не теоретическая правота, а практическое применение.
</p><p>В докладе авторы дали краткий обзор концептов. Часть из них в книге есть, а другие — будут только в будущей книге и пока не публиковались. Дальше пунктирные заметки.
</p><p>Каждому уровню соответствует своя игра. Игра в выживание, Игра в племя, Игра во власть, Игра в правила, Игра в успех, Игра в смысл и Игра в игру. Дальше будет подробнее.
</p><p>Есть ряд принципов развития по уровням
</p>
<ul><li> Маятник индивидуальный — коллективный, переключается на каждом уровне</li>
<li> Еще один маятник мужской — женский, тоже переключается на каждом уровне</li>
<li> каждый следующий включает и превосходит предыдущий, поэтому и говорим о развитии</li>
<li> 1 ярус — дуален, другие уровни оценивают как неверные. 2 ярус — интегрален (+турмалиновый и белый), желтая организация интегрирует всех сотрудников</li>
<li> у каждого уровня (до бирюзового?) есть светлая и темная сторона</li>
<li> падение — через один уровень</li>
<li> нижние уровни выдают себя за верхние. На них слабая рефлексия, нет адекватности. Мимикрия, часто не осознанная. «Мы не смогли выстроить регламенты и решили, что у нас самоуправление» :)</li>
<li> в каждом человеке — радуга если не всех, то нескольких кодов. В обществе и организации тоже. Есть доминанта — активный код.</li>
<li> оценивать надо по делам, а не по словам</li>
<li> сила организации определяется слабостью самого слабого звена</li>
<li> распаковка кодов идет с рождения человека и сообщества</li>
<li> больше всего осуждаем и критикуем уровень, переход на который нам предстоит. Уперлись, не пойду</li>
<li> к уровням, которые мы прожили и опыт которых присвоили, относимся уважительно и благодарно, понимаем и принимаем. Если человек не уважает правила — он на фиолетовым, а не на бирюзовом самоуправлении</li>
<li> война и революция обнуляют систему, сбрасывают в бежевый</li>
<li> не все рождаются на бежевом, может быть фиолетовый или красный. Я: это сомнительно, но можно быстро проскочить.</li></ul>
<p><b>Бежевый</b> — игра про выживание. Не работает эго, работает рептильный мозг. В тяжелые времена кто-то становится человечным, а у кого-то инстинкты. Уровень про тело, фундамент для остального. В организации — туалет, температура, комфорт на рабочем месте. Если проблемы — начинаем наводить порядок тут. Сообщение миру «Я имею право жить».
</p><p><b>Фиолетовый</b> — игра в племя, в отношения. Отношения, обнимашки. Люди не умеют обниматься. Забота о команде, забота о клиентах. 70 % людей даже фиолетового не идут. За жизнь человека отвечает кто-то: родители, вождь племени, руководитель организации. Светлая сторона: нам хорошо вместе, дополнительно к работе, встречи-болталки. Сообщение миру: «Я хочу быть с вами, в вашем сообществе».
</p><p>Фиолетовый — не умеет принимать критические решения, не умеет выгонять паразитов. Потому что если Васю выгнали, завтра мня выгонят. Для этого нужен Вождь.
</p><p><b>Красный</b> — игра во власть, вождь, лидер. Выгонять паразитов, отвечать за выживание племени. Но неконтролируемый огонь — сжигает, для контроля нужны правила.
</p><p><b>Синий</b> — игра в правила. Начальная школа — научить ритм, дисциплину, принимать правила. Ритм работы и отдыха, очень важен. Если красную энергию научить работать по правилам — хватит энергии на многое.
</p><p><b>Оранжевый</b> — игра в успех. Снова эгоистичный. Красная энергия, прирученная синим — синтез уровней.
</p><p>Красный — результативность, синий — эффективность, оранжевый — успех.
</p><p><b>Зеленый</b> — игра во смысл. Как только мы умеем достигать целей, встает вопрос — во имя чего. И там появляется зеленый — смыслы, интеллектуальная духовность. Не надо путать с фиолетовым — там тоже говорят про смыслы и традиции, но они ничего не умеют достигать. Темная сторона — идеология и нетерпимость к инакомыслию. Светлый — хорошая ценность.
</p><p><b>Желтый</b> — игра в игру. Первый уровень, на котором мы свободны, можем выйти за пределы, посмотреть на себя адекватно. Если бы у тебя была волшебная палочка. Транссерфинг реальности, школа игры Вадима Демчога. Много священных текстов. Архетипы. Баба Яга (проводник между мирами), Дамблдор и Гэндальф, магистр Йода, черепаха Тортилла, русский скоморох, Мюнхгаузен Янковского, Бендер (Миронова — игра). Партнерское самоуправление возможно только на желтом.
</p><p>На первых уровнях, от красного до зеленого люди серьезны. Человек подчиняется закону роли. Закон ролевого захвата Понтия Пилата (из Булгакова). Если Понтий считает, что он — прокуратор и только ее носит, а потеря маски равносильна смерти, то у него нет права выбора, действует из роли. Желтый позволяет увидеть игры, в которые играют люди. В жизни сложнее, в организации проще. Желтый — путь алхимика — я меняю себя и это меняет мир. Желтый уровень — про интегральную организацию, твое-кратие. Ты никогда не будешь играть в игру, которую навязали, надо делать свою.
</p><p><b>Бирюзовый</b>. Женский. Желтый: я создаю реальность, я на нее влияю, я ее переделываю. А бирюзовый — интеграция, я понимаю что мир совершенен, принимаю мир как есть и следую своим путем. В организации: не человек плохой, он занимает не ту роль или не в том команде, и надо переместить. Желтый — ты над формой и формируешь мир, а на бирюзовым ты сам — форма. Бирюзовый — творческий принцип вселенной, и ты его постиг.
</p><p>В книге 40 принципов, 80 следствий. Если вы не видите матрицу — будете играть в чужую игру, сопровождая программы долга, вины, стыда. Каждый уровень дает возможность пострадать, а потом выйти на следующий уровень успешно.
</p><p>Каждый уровень — свои ценности, жесткий ролевой захват. Бежевый — выжить. Фиолетовый — стабильность, забота, уют. Красный — воля, настойчивость, власть. Синий — быть правильным, бюрократия. Оранжевый — достижения, стратегии, цели, победы. Зеленый — служение, любовь, справедливость. Желтый — творчество, игра, созидание, поток. Чтобы быть радостным — ничего не надо, берешь и делаешь здесь и сейчас. До желтого живут прошлым или будущим, есть идеал.
</p><p>Правила безопасной игры. В книге — больше.
</p>
<ul><li> все игры мира — священны.</li>
<li> Матрица — священна, ее не надо ломать, а эволюционно изменять</li>
<li> Имени Иешуа Га-Норцы. Все люди — добры.</li></ul>
<p>Осознанность 4 вопроса
</p>
<ul><li> Умение ответить, в какую игру играю, какой сценарий</li>
<li> Какова моя роль, что боится, что должна свершить</li>
<li> Насколько я кайфую в этой игре</li>
<li> Хочу ли я оставаться в игре, или хочу поменять роль или выйти из игры</li></ul>
<p>Для каждого уровня есть свой путь: аскета, ремесленника, воина, политика, предпринимателя, пророка, алхимика. Матрица устроена так, что вы попадаете на чужой путь, уровень среды не совпадает с вашим. Там, где уровень условий ниже уровня пути, роль жестко форматирует человека, ограничивая его. А там, где уровень окружения выше уровня пути — человек пытается подорвать систему. Кроме желтого окружения, которое интегрирует все пути. Алхимики — игра в игру, не борются с матрицей, они ее видят. Люди — рабы своей картины мира, и алхимики помогают развивать, выходя из матрицы.
</p><p>Хотя это проговаривали пунктиром, я до конца не понял, буду думать. И дальше были примеры этапов для каждого пути, одни мне понятны, для других нужны подробности, тоже буду разбираться.
</p><p><b>Путь предпринимателя (оранжевый)</b>: Стартапер; Рыночный торговец; Эксплуататор и барин; Производственник; Бизнесмен — строитель корпорации; Благотворитель или основатель секты, где люди получают смысл; Игрок и прорывной инноватор
</p><p><b>Путь жреца (зеленый)</b>: монах-послушник; брат, работник; священный деспот; политик из синода; создатель коммерческих продуктов церкви; жрец-фанатик; пророк — обновление веры и ритуалов
</p><p><b>Путь воина (красный)</b>: раб-воин; солдат; воин; офицер; полководец; крестоносец; завоеватель-игрок-распространитель культуры (Македонский, Суворов)
</p><p><b>Путь политика (синий)</b>: Акакий Акакиевич; клерк; взяточник; чиновник; политик — помощник предпринимателя; государственный деятель; ??? (не знают примеров)
</p><p>В обсуждении в телеграм был вопрос Evgeny Adamov: Макс, а какая то предикативность уже есть? Грубо говоря, сказать что делать уже могут?) Или только кто виноват?)).
</p>
<dl><dd> mtsepkov: Предикативность — есть. Как в любых типологиях, мы разделяем часть поведения, характерную для типа и индивидуальные поправки к ней, ив той мере, в которой поправки малы — получаем предсказательность. Пока для спиральной динамике поправки относительно малы, уровень относительно хорошо и быстро опознается по маркерным вопросам в коммуникации (только надо понимать распространенные мимикрии, они тоже типовые), и дальше ты понимаешь, как с человеком эффективно взаимодействовать, какие паттерны мышления ожидаются. Но понятно, что это — статистика, это как с предсказательностью медицины, валидностью типовых протоколов диагностики и лечения — оно срабатывает не всегда, но в целом нормально. Подтверждение — использование модели практиками, перед которыми стоит задача достичь результата, а не объяснить, почему не получилось.</dd>
<dd> Evgeny Adamov. Хм, мне скорей про организации интересно. Пока я вижу только «вой на болотах» в профильных чатиках, на тему "ну что вы хотели они же красные/синие и.т.п — в общем всех кроме бирюзы, и не встречаю — а я понял, что они красные, поэтому вот таким образом 1,2,3 реализовал проект.</dd>
<dd> mtsepkov: Про организации тоже работает, это часть диагностики на входе и выбор соответствующих культуре способов коммуникации и действий. Тут у Розина много кейсов в книгах, он знаком со Спиральной динамикой уже больше 10 лет, хотя в старых проектах не афишировал ее применение, а просто использовал. У меня личный опыт — взаимодействие с заказчиками при реализации проекта, понимаешь, на каком языке разговаривать, и как надо брендировать свои действия. Понятно, что можно без этого, индивидуально, но типология ускоряет, если поправки малы.</dd></dl>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D1.84.D0.B5.D1.80.D0.BE.D0.B2_.D0.9F.D0.B0.D0.B2.D0.B5.D0.BB._.D0.9D.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5_.D0.BE.D1.81.D0.BE.D0.B1.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F">Алферов Павел. Национальные особенности управления</span></h1>
<p>Роскошный доклад о национальных особенностях, с юмором и примерами. Которые поясняют, почему конструкции из книг не работают. И это не только личный опыт Павла, это исследования.
</p><p>В докладе каждую особенность разобрали отдельно, а в конце было — какая адаптация нужна проектному подходу, чтобы он за работал.
</p><p><b>1) АНКА: Авось, Небось, Как-нибудь, а если не сработало — Аврал</b>. Злейший враг любой системной деятельности. Все системные изменения проваливаются сквозь это. Придумывать, исполнять — зачем, само сделаем. А для аврала — слишком сложно.
</p><p>Наблюдение Ву Андерсона, шведа, который руководил ГАЗом, потом АвтоВАЗом. То, что в Европе занимает неделю, в России можно сделать за день. И если дать задачу на неделю, все равно будут делать в последний день.
</p><p>Модель Ананьина. 3 модели работ с неожиданностями.
</p>
<ul><li> Японская модель: надо напряженно думать, чтобы их не допускать. Много сил и денег на планирование. Условия формирования: Стабильные правила, основанные на национальной традиции.</li>
<li> Американская — да, подумаем. 5-10 рисков. Остальное неважно, как возник — решаем. Уважение к правилам игры, к изменению правил все быстро приспосабливаются</li>
<li> Российская: пока не возник кризис — не смотрим, а когда возникло и не рассосалось — делают. И две кучки: часть отползает, другие не могут отползли — решают, и надо решить до катастрофы. — Правила меняются, правовой нигилизм</li></ul>
<p>Каждая родилась в своих условиях и работает в своих.
</p><p>Фукусима. Нештатка, не предусмотренная сценарием: затопило дизель-генераторы. И Японцы думали, наши им говорили «делать надо, сейчас взорвется», а они так не могли.
</p><p>В чем проблема подхода? Если половина времени тушим пожары — то все планы идут нафиг. И если пожары все время, то не планируют. Наиболее успешно практики работают там, где руководство понимает, что надо уходить от тушения пожаров, делают профилактику. У нас цикл PDSA не замыкается.
</p><p><b>2) Авторитарный стиль</b>. Полномочия, ответственность сверху не дают, снизу — не хотят брать.
</p><p>Наиболее эффективной российской управленческой технологией остается пинок животворящий. На том стояли и стоять будем. — это Шумков, Губернатор Курганской области. И разделяется многими.
</p><p>Книга Exploring Culture. IBM 70-е. Жесткий дресс-код. Все одинаковы, но дела идет по-разному. Начал исследовать: В России Дистанция власти 93 из 100, одна из самых больших.
</p><p>Игра Ну погоди: менеджер ловит яйца, которые сотрудники-курочки подкидывают.
</p><p>Почему подчиненные подходят к вопросами? Перевесить ответственность. Проекты работают, но только при участии первых лиц. Крупная компания подала на управление проектами. По книге — все правильно. Поехали проверять. Дальний завод на востоке. Собрал руководителей, спрашивает: какие решения вы как руководители проекта можете принять? Никакие, идем к генеральному. Нельзя выстроить цепочку делегирования. А проектное управление построено на этом.
</p><p><b>3) Византийская система, ориентация на личные взаимоотношения.</b>
</p><p>Игра про эмоциональный интеллект. ИТ директора. Вы очень умные, скрывать не умеет. Это проблемы. Они приносят критерии, выбрали. А поговорить? А выяснить интересы сторон?
</p><p>Что скажет княгиня Марья Алексевна? — Грибоедов. Или «нельзя отказывать Кузьмичу» — особенности национальной охоты.
</p><p>Эрин Мейер. Culture map. Для России — высокая дистанция власти, принятие решений сверху-вниз, доверие на основе отношений.
</p><p>Доверие на основе задач или на основе отношений. Ничего личного, просто бизнес — это в основе западного подхода. Если двух профи поставили на задачу — они ее решают. У нас когда поставили на задачу — надо разобраться: ты человек нормальный? А что профи — не очень важно.
</p><p>Схема. Идеал: Сбор данных, анализ, решение. Реально часто кажется. что между анализом и решением — эмоциональный рандомайзер, и решение не следует из данных. Но реально там не хаос, а порядок, который мы не понимаем.
</p><p>До ковида была история: Проектный олимп, конкурс проектного управления, он ездил на аудит. Одна российская компания ввела на 50 тыс. человек систему расчета зарплаты на основе грейдов, выравнивания и так далее, крутая штука. У них чеклист и там управление заинтересованными сторонами. Показывают большой лист А4, список. А как работали? Мнутся. А потом руководитель показывают только ему реестр заинтересованных сторон в Excel, и там написано то, что никому показывать нельзя. И эта таблица вскрывает эмоциональный рандомайзер.
</p><p>Западные практики там, где вопрос профессионализма решает.
</p><p><b>4) Несоблюдение правил</b>. В России закон — не указатель, это совет. Островский Горячее сердце. Городничий: «Как судить? Если по закону — законы строгие. По ним или по душе?» — «По душе». Всемирный банк. Верховенство закона — Россия 146 место из 180.
</p><p>Все работают активно, пишут регламенты. Они не работают. Работает управление по поручением. 2019: Президент РФ за 7 лет выпустил 17500 поручений. Все в ручном режиме. Все практики предполагают установку правил. А тут — ручной режим. Асхат Уразбаев. Что больше всего влияет на Agile? Как раз этот пункт. Все считают, что Agile — хаос. Нет Agile — правила, которые команда принимает и должна действовать. А она не действует.
</p><p><b>5) Консерватизм и недоверие</b>. Петр I: «Ибо сами знаете: что добро и надобно, а без принуждения не сделают». Круги доверия: семье, знаете лично, встреча в первый раз, другая национальность, всем. Россия — почти только семья.
</p><p>Проектное управление. Главбух. Я ей «проектное управление…, а она — ты НДС за лучевые трубки поможешь возвращать? Я не про это — иди отсюда.»
</p><p>Больше всего беспокоит авторитарный стиль и то, что ответственность не берут. То, что не дают — сейчас уменьшается.
</p><p><b>Все рассказанное, это НЕ болезни, а особенности</b>. Анекдот: стоят двое смотрят на рыб, говорят «я бы так не смог, холодно, мокро» Рыбы «а что такое вода?» Вы все в этом живете.
</p><p><b>Как сделать в этих условиях успешное проектное управление?</b>
</p>
<ul><li> Драматически важен сильный лидер проекта, пробивать головой</li>
<li> Заинтересованный топ-куратор, который включен</li>
<li> Упаковка проекта, первая первичная. 5 вопросов: зачем и для кого, результат, с кем пойдем и когда</li>
<li> Стартовое совещание обязательно. Баста, кончились танцы, куратор и первое лицо должны сказать: со всех спрошу</li>
<li> Работа с заинтересованными сторонами внутри</li>
<li> Фокус на формальных и неформальных обязательствах</li>
<li> Контрольные точки. Разбор красных: что сделать, чтобы успели</li>
<li> Каждую неделю статус обязательный.</li>
<li> Для сложных: управляющий комитет вовлеченных топов и статус на нем.</li></ul>
<p>Литература. Прохоров, Ананьев, Аузан Культурные коды экономики, Хазин Лестница в небо, McKinsey От орг.эффективности к успеху, Эрин Мейер Culture map
</p>
<h1><span class="mw-headline" id=".D0.9C.D1.83.D0.B6.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.A2.D0.B0.D1.82.D1.8C.D1.8F.D0.BD.D0.B0._.D0.A1.D1.87.D0.B0.D1.81.D1.82.D1.8C.D0.B5_.2F_.D0.9B.D1.8C.D0.B7.D1.8F_.D0.BD.D0.B0_.D0.B3.D1.80.D0.B0.D0.BD.D0.B8_.D1.84.D0.BE.D0.BB.D0.B0">Мужицкая Татьяна. Счастье / Льзя на грани фола</span></h1>
<p>Вау-доклад, искрометный и по делу. Как сделать, чтобы рассказанное доходило? Есть простая БЛЯ-модель из трех пунктов: Безумненько, Легко и Ясно. Дальше пунктирные заметки, что успевал записывать.
</p><p>Татьяна — психолог, бывший инженер — НЛП оно оттуда. Когда маленькая — активно мыслящий ребенок. Это прокачала мама. Станция, отменили электричку, и надо на станции 40 минут активно. Мама играла в задачки. Например — почему буквы не падают. Хотя шевелятся. Или — как внутрь карамельки попала начинка? Как это сделано, в чем формула.
</p><p>Эксперимент. Посмотрите вокруг, найдите желтые предметы, а потом откройте глаза — вспомните розовые. А не помнят, потому что сознание про другое работало. Поэтому вопрос — ценнее ответа. В чем смысл жизни? — Мальчик, у тебя такой хороший вопрос, а ты хочешь поменять его на ответ. Однообразие — враг сексуальных отношений, когда все понятно, известная схема — никакой магии.
</p><p>Пирожок: Олег несет добро и счастье, его увидевши жена кричит: куда ты это тащишь, и так весь дом говном забит!
</p><p>Чтобы увидеть новое — надо вылезти за пределы своего мирка. Не обязательно зону комфорта покинуть — можно форточку открыть.
</p><p>Три врага, которые мешают восприятию выступления, мешают сделать своим, интериоризировать.
</p><p>1) Скука. Как поставить цель — о, понятно, тут будет смарт. Хотя там может быть что-то другое. Как только человек понимает, что его зовет в игру эксперт — ученик: интерес пропадает. Запускаем на другой стороне критика. Он уверен, что сам все знает.
</p><p>2) Сложность. Употребляет сложную терминологию, а людям-то непонятно.
</p><p>В МГУ была преподавательница Ждан, учебник по истории психологии, и только ее история — правильная. Но пришла на экзамен очень подготовленная: взяла обои, нарисовала дерево психологии по ее учебнику и другим. Она посмотрела и говорит «заберите», а она не забрала, до сих пор жалеет. Сказала ей «Я простила советскую психологию за бесчеловечное отношение к людям» — Это как? — Последний, кто писал русским языком, был Выготский, потом Павлов, а потом — все. Анекдот про темы диплома: «Чем дальше в лес — тем больше дров» меняем на «О нарастании топливных ресурсов с продвижением вглубь лесного массива»; «Нафига попу гармонь» на «О роли музыкальных инструментов в жизни служителя культа». Почему так? Потому что Выготский умер молодым в 1938, остальные — не дураки, они поняли, что надо писать так, что была наука.
</p><p>Сейчас — сленг. Замьютим, забуким митинг и прочий птичий язык. Особенно у детей история. Если читаете худлит с планшета, с которого работаете — не делайте. Потому что провоцирует переключение, организм переключается. Разделять контексты. Мозг не дурак «дофамин — рядом, мы с этой штуки смотрели порнушку, тик-ток не смотрен».
</p><p>3) Отсутствие четкого критерия прогресса.
</p><p>С Карнеги у нее не сложилось, когда прочла «Даже если человек не нравится — просто полюбите искренне. Как? Начните интересоваться жизнью». Это вызвало возражения: как, он и так не нравится — и еще интересоваться.
</p><p>Кнопка включение обаяния. Смотрите прямо в глаза, вы напротив. И чуть-чуть вперед, к человеку — это считывается. Индикатор: корпус к спикеру или от него. На переговорах поэтому опасно напротив — потому что отстранение — и это считывается, люди бегут. И через экран тоже работает.
</p><p>Когда делаю правильно — надо сказать, что сделал правильно, четко и не загрязняй фон. Если проходишь классическую терапию, прогресс есть? При чем тут мой дедушка? А фитнес — там понятно.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:PIR-2023.jpg" class="image"><img alt="PIR-2023.jpg" src="https://mtsepkov.org/images/thumb/6/69/PIR-2023.jpg/400px-PIR-2023.jpg" width="400" height="300" srcset="https://mtsepkov.org/images/thumb/6/69/PIR-2023.jpg/600px-PIR-2023.jpg 1.5x, https://mtsepkov.org/images/thumb/6/69/PIR-2023.jpg/800px-PIR-2023.jpg 2x" /></a></div>
<p>Компактная модель, как с этим быть. БЛЯ.
</p>
<ul><li> Б — безумненько. Времена жесткого дресс-кода, идет на тренинг в серьезном костюме, но на шее — платочек с маленькими черепом и костями, знает кто-то увидит, опознает — есть жизнь. Пирожок: Нет в шоколаде шоколада, давно нет мяса в пирожке и мне становится тревожно — а вдруг и в людях нет людей. Безумненькое рождает надежду, что люди остались. ПИР — соответствует. Не обязательно хулиганство, руководитель бежит Айронмен. Но не безумно!</li>
<li> Л — должно быть легко. Чтобы сразу начало получатся, чтобы человек понял. Знак судьбы — понятно. Люди замечают хреново, и не замечают, что хорошо. Искусство перевода на человеческий и обратно. Презентация — объяснить визуальными образами сложную информацию. Прирост процента. Автомобиль весит как член кита. Это запоминается без записывания даже.</li>
<li> Я — ясные критерии. Как поймем, что продвигаемся. Шкала оценки, куда продвинулись. При чем без трактовок, не «качество жизни улучшится»: вы думали «больше хорошего настроения», а он «ну и где мои бабки?» Дети хорошо учатся, когда ты показываешь прогресс.</li></ul>
<p>Ребенку: ставим таймер на 45 минут, сколько успеем — столько сделаем. — А если ничего — Ничего, получишь двойку. Дальше делать -мне скучно. И дети сами включались, им было интересно — сколько они успеют за 45 минут. Жаль, я не знал такого метода…
</p><p>Компания вышла на выставку, не было денег: взять модели, и мужики будут играть. И машины связать с характером. Они: это де неправда — а это не страшно, начнется диалог. Я тут хочу подтвердить, на Teamlead на стендах разные развлекухи для завлечения ИТ-шников, чаще интеллектуальные, и год назад вау-эффект вызвала штука, где мягкие ракетки бросали в корзину, как в баскетболе: два дня стояла очередь. Сейчас подобные вещи на половине стендов.
</p>
<h1><span class="mw-headline" id=".D0.9A.D0.B8.D0.B7.D0.B5.D0.B5.D0.B2_.D0.92.D0.B5.D0.BD.D0.B8.D0.B0.D0.BC.D0.B8.D0.BD._.D0.9F.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D0.BA.D0.B8_.D0.B8_.D1.82.D0.B5.D1.85.D0.BD.D0.BE.D0.BB.D0.BE.D0.B3.D0.B8.D0.B8_.D0.B4.D0.BB.D1.8F_.D1.83.D1.81.D0.BA.D0.BE.D1.80.D0.B5.D0.BD.D0.BD.D0.BE.D0.B3.D0.BE_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D0.B0">Кизеев Вениамин. Практики и технологии для ускоренного развития бизнеса</span></h1>
<p>Наиболее интересное сообщение доклада: что у WINbd получилось успешно подготовить курс обучения посредством ИИ, занимает это неделю вместо нескольких месяцев с реальным преподавателем, и они планируют развивать этот опыт.
</p><p>Но сначала было о трендах развития, и здесь важно впечатление с лекции профессора в американском университете, который говорил слушателям: поймите, глобализация закончилась, сейчас нужна локализация в страну. То есть то, что по-нашему называется импортозамещением. И всем нужно сделать департамент по взаимодействию с государствам. В зале, кроме американцев, были европейцы, китайцы, он — русский. И на реплику китайцам «у вас друзей нет», те тут же ответили «Путин наш друг». Был ряд слайдов с трендами, но это надо смотреть презентацию детально, подробно не рассказывали. Единственное — про роботизацию. Уровень роботизации производства очень высокий, в России тоже есть отдельные примеры, например, на КАМАЗе, где 85 % операций по сборке кабин делают роботы. Но в целом статистика печальна: 8 роботов на 10 тыс. рабочих в то время как Южная Корея — 932, Китай и Тайвань — 200+, и даже Болгария — 23.
</p><p>Теперь про ИИ. CharGPT активно проникает в жизнь. Знакомый HR уволил человека, который составляет вакансии, потому что ChatGPT делает лучше. Через 2 недели уволили ее саму. CharGPT умнеет. Сейчас искусственно притормозили, потому что такой как ChatGPT-4 по планам был только 2027, а он появился сейчас.
</p><p>Они попробовали полностью сделать курс по проектному управлению с помощью различных ИИ. Потому что преподаватели-эксперты замучили: болеют, капризиничают. ИИ сделал все: создал контент, нарисовал слайды, создал аватара, который прочитает лекции, сделал тестовые задания, сделал лендинги для курса. Там есть работа человека: надо дать задания ИИ, надо собрать то, что сделали разные ИИ, в единый курс с лендингом, но это не требует специальных знаний и больших трудозатрат. Эксперт тоже нужен: он должен смотреть, что получается, и показывать места, где лажа — дальше ИИ эту лажу исправляет. Фишка в том, что создание курса занимает неделю от задания до публикации, в то время как обычный курс создается несколько месяцев. И создавать можно на бесплатной версии, затраты 30$ на курс вместо обычных 30 тыс. за занятие эксперту. Конечно, проверка и работа людей тоже стоят, но несоизмеримо меньше, происходит это все гораздо быстрее, создание курса и поиск эксперта для проверки идут параллельно. В планах — использование платных версий, тогда можно взять фотки и голос конкретного эксперта, который согласитьcя на такое сотрудничество, и курс будет читать его аватар с его интонациями, это у них в планах.
</p>
<h1><span class="mw-headline" id=".D0.92.D1.8B.D1.81.D1.82.D1.83.D0.BF.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B5.D1.8F_.D0.A1.D0.B8.D1.82.D0.BD.D0.B8.D0.BA.D0.BE.D0.B2.D0.B0">Выступление Алексея Ситникова</span></h1>
<p>Выступление — осмысление текущей ситуации. Оно очень содержательное, но преимущественно повторяет прошлогоднее выступление Алексея, конспект которого можно прочитать в моем отчете <a rel="nofollow" class="external free" href="https://mtsepkov.org/PIR-2022">https://mtsepkov.org/PIR-2022</a> (надо по оглавлению найти). Что не удивительно — big picture ситуации поменялся слабо. Эту часть я повторно излагать не буду.
</p><p>Но есть дополнение. То что произошло — вызов. А стимуляция для лидера. И пока преодоление вызовов идет удовлетворительно: экономика не упала, российские компании успешно занимают освободившиеся ниши, российские подразделения иностранных компаний, освободившись от головной конторы, начали развиваться более разнообразно, головные офисы ограничивали. И после выступления было два конкретных кейса: Nikoliers (бывшая Collers, лидеры в России) и Вкусно и точка — бывший Макдональдс. А вообще опыт показывает, что вызов — лучшая стимуляция для лидера. А умения — дело наживное, статистика говорит, что выпускники различных лидерских школ не достигают особо крутых результатов по сравнению с теми, кто в школе не учились.
</p>
<h1><span class="mw-headline" id=".D0.AE.D0.BB.D0.B8.D0.B0.D0.BD.D0.B0_.D0.A1.D0.BB.D0.B0.D1.89.D0.B5.D0.B2.D0.B0._.D0.A1.D0.BE.D1.8E.D0.B7.D0.BC.D1.83.D0.BB.D1.8C.D1.82.D1.84.D0.B8.D0.BB.D1.8C.D0.BC.C2.A0.E2.80.94_.D1.82.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D1.8F_.D1.81_.D0.BE.D0.BF.D0.BE.D1.80.D0.BE.D0.B9_.D0.BD.D0.B0_.D1.82.D1.80.D0.B0.D0.B4.D0.B8.D1.86.D0.B8.D1.8E">Юлиана Слащева. Союзмультфильм — трансформация с опорой на традицию</span></h1>
<p>Рассказ о восстановлении студии Союзмультфильм. Она была практически разрушена в 90-е, а права на коллекцию мультфильмов оказались у самых разных лиц. По понятным причинам: студия всегда финансировалась государством, и когда финансирование прекратилось — начался развал. При этом мультипликация финансируется государством практически во всем мире, исключение — несколько американских студий. А когда-то, в 50-е — 60-е она была крупнейшей в Европе и конкурировала в Европе с Диснеем.
</p><p>В 2017 Юлия пришла на студию после 30 лет развала с задачей вернуть бренд. И дальше был рассказ о достигнутых результатах и о том, как это происходило.
</p><p>Сначала про достигнутый результат.
</p>
<ul><li> Когда-то было 30 фильмов в год. Сейчас — 300 эпизодов, в 10 раз больше. 17 сериальных проектов и 1 крупный.</li>
<li> Планшет и смартфон у детей с 2 лет, и дети сами выбирают контент, клиповое смотрение. Они пытаются перестроить восприятие детей на то, что считают адекватным. Линейки контента для разных возрастов. от 2-4 до 7-9. Подростковая анимация в России отсутствует, дети идут во взрослый — но они будут работать с этим.</li>
<li> Сейчас Союзмультфильм 800 человек производство. Еще мультимедиа-парк — ВДНХ и Казань. Интерактив с героями.</li>
<li> Продажи: медиаправа и лицензии на мерч, собственный канал с международным вещанием — продолжают, дружественные страны</li>
<li> Собственный факультет в Синергии и ВУЗы в регионах</li>
<li> Мультфильмы
<ul><li> 100-я серия Простоквашина, Новый Чебурашка</li>
<li> Новое Ну погоди — очень спорный проект, потому что там 3d и нельзя гоняться, чтобы съесть — новые стандарты, только соревнование. И Волк не может курить или пинать урну даже в России, а в международном прокате — еще много ограничений. Идут письма: нам очень не нравится новое Ну погоди, но спасибо. что вчера было о чем весь вечер поговорить с детьми, сравнивая.</li></ul></li></ul>
<p>Пришла на Союзмультфильм с СТС-медиа. Обратилась к государству. Исторически, и во всей Европе, Азии (Китай, Корея), Канаде — поддержка государством, только США сами. Проекты независимых студий в 2017 были — но мало, по сравнению с ТВ и рынком других стран. Поддержка — комплексная, не только деньги — экспортная программа, образования и так далее. Сейчас анимация для государства — одна из флагманских индустрий.
</p><p>Как идут из прошлого, опираются на традиции?
</p>
<ul><li> Энтузиазм, команда которая горит.</li>
<li> Возвращение прав — золотая коллекция была распродана и роздана. Судебная и досудебная работа.
<ul><li> Например, были компании, которые купили, но не продавали</li>
<li> Права на Чебурашку и Простоквашино. Успенский зарегистрировал на себя, но у него книги, а образы — у Союзмультфильма</li>
<li> Продолжение Простоквашина — договорились с Даноном, приличные деньги. Но Успенский хотел половину денег — а им-то производство нужно</li>
<li> Два года договаривались о сумме, Простоквашино выкупили еще при жизни</li>
<li> Наследники Успенского — вернули Чебурашку</li>
<li> Права на Чебурашку в Японии: Успенский продал за 3 млн, а Союзмультфильм с той же компании — год за 30 тыс. с автопродлением на 7 лет до 2023</li>
<li> Контракт был заключен в суде по японскому праву, а там — культовый персонаж</li>
<li> Ну погоди — торговая компания</li>
<li> Умка — косметическая компания</li>
<li> Думала, что все поборола, но нет, есть международные компании, приходится судиться…</li></ul></li>
<li> Для господдержки — надо было сначала погасить долги — зарплата, налоги, авторские.</li></ul>
<p>Как восстанавливала?
</p>
<ul><li> Новое здание — в Минкульте сказали, что здание строится. Только не доделано. А нужен опыт.</li>
<li> И вопрос зарплат, по сравнению с телевидением и рекламой — на те зарплаты не собрать вообще, гендиректор получает зарплату помощника</li>
<li> Позвала людей, они потеряли в зарплате, но под личное обещание, что через 3 года будут хорошо зарабатывать</li>
<li> Не все смогли 3 года выдержать на те деньги. Но с рынка приходили те, кто мечтал работать в Союзмультфильме.</li>
<li> Первый год — ощущение, что бьется головой. Но все-таки получилось.</li>
<li> Через 3 года — стратегический инвестор, дочка со Сбером и инвестициями от него.</li>
<li> Два года работала на своем опыте — медиа, реклама, тв. Потом появились деньги, позвала консультантов, те проанализировали российский и американский, европейский, азиатский опыт. Получили много ценного и комплексная стратегия.</li>
<li> Сейчас — лидеры на российском рынке анимации, опередили конкурентов.</li>
<li> Звезды 1-2 на студии, в Союзмультфиьме было 6-7 в лучшие годы. Котеночкин, Бардин, Норштейн, Качанов, Вано… Сегодня — не так.</li>
<li> Пластилиновую анимацию — только в Союзмультфильме, единственное в мире — сохраняют. Кукольная анимация. Но это точки, не массово.</li>
<li> Но мейнстрим — массовые технологии</li>
<li> Все мэтры критикуют — что бизнес и технологии, а не искусство.</li>
<li> 10-12 авторских короткометражек, авторская полнометражки, но мало — традиционная.</li></ul>
<p>Один из факторов ее решения придти — 3 детей, хотелось качественный контент, и чтобы гордились. Идеологическая составляющая. Внешнего влияния нет, контент для детей до 12 — традиции, ценности и здравому смыслу. Ценности содержательные посылы — из старого.
</p>
<ul><li> Доброта, уважение к старшим, любовь к стране, что дети — разные и отличаются надо уважать, полноценная семья.</li>
<li> Минимум техники, у Федора — ноут для дистанционного обучения, и разбитый телефон у Шарика — блоггер и все. У остальных мультов — нет. Телефон разбитый у Шарика — по обратной связи от родителей, в 1 серии был хороший</li></ul>
<p>Компания, где Чебурашка — талисман. Расслоение компании: для одних — круто, для других — архаизм. Креативщики придумывают. Будет ли Чебурашка взрослеть? Нет, Чебурашка будет как был, не повзрослеет. Но есть стайлирование в образах — игра престолов, анимешные и так далее.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.B0.D1.80.D0.B8.D0.BD.D0.B0_.D0.9F.D0.BE.D1.87.D0.B8.D0.BD.D0.BE.D0.BA._.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D1.8F.D0.B9_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5.D0.BC.C2.A0.E2.80.94_.D1.81.D0.BE.D0.B7.D0.B4.D0.B0.D0.B2.D0.B0.D0.B9_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D1.80.D0.B5.D0.B7.D1.83.D0.BB.D1.8C.D1.82.D0.B0.D1.82.D1.8B">Марина Починок. Управляй мышлением — создавай новые результаты</span></h1>
<p>Доклад о наблюдении и управлении за своим мышлением, работой мозга, чтобы убрать стресс, навязчивые мысли и другие факторы не эффективности. При этом речь шла не просто о практических приемах, а использовались нейрофизиологические модели. Отмечу, что на ИТ-конференциях такие доклады я слышу уже больше пяти лет, а вне ИТ-сообщества такое глубокое погружение в устройство мозга только начинает появляться. При этом надо понимать, что комплексной модели мозга у современной науки нет, есть много частичных исследований, касающихся отдельных механизмов, результаты которых далеко не всегда сопряжены друг с другом.
</p><p>Начало вполне традиционное — с исследований о том, что больше 40 процентов людей испытывают беспокойство и стресс, массовой причиной которых является неопределенность будущего и воображаемые негативные сценарии. Но есть и другая сторона: именно неопределенность будущего дает интерес к жизни. Так что задача — не полное снаятие неопределенности, а исключение страха и стресса, за которые на уровне нейрофизиологии отвечают механизмы в миндалине (amigdala), и это оценка происходит до сознательной оценки информации. При этом существует целая индустрия опасений. основанная на том, что люди массово не умеют управлять собой.
</p><p>Дальше был разбор механизмов стресса. Есть физические причины, связанные с травмами, химические, связанные с болезнями, различными нарушениями химии организма и эмоциональный. Прежде чем работать с эмоциональным уровнем стоит с помощью исследований исключить предыдущие.
</p><p>Стресс рассматривается как выход из гомеостаза, стабильного состояния психики и, как целевая функция — возвращение этого гомеостаза. Я тут хочу отметить, что согласно модели Хелен Фишер, счастье в размеренной жизни — лишь один из четырех нейрофизиологических механизмов, основанный на серотонине. Есть еще три: дофамин — счастье поиска, тестостерон — счастье борьбы и победу и окситоцин — счастье социальных взаимодействий. Окситоцин тоже можно отнести к гомеостазу, а дофамин и тестостерон — точно нет. У каждого есть все четыре, но они работают в разную силу в силу предыдущего опыта и это меняется со временем. Так что чисто серотониновая теория счастья и стремление к размеренной жизни как средство борьбы со стрессом — лишь часть правды. И среди ИТ-шников и среди других творческих профессий помимо выгорания стресса есть выгорание скуки с аналогичными последствиями. Просто выгорание стресса — оно характерно для менеджеров, а к ним — больше внимания в силу социального положения. Правда, тут есть еще один момент: дофамин и тестостерон для реализации требуют определенного уровня энергии, и восстановление после излишнего переутомления действительно требует размеренной жизни. Но есть принципиальная разница между временным восстановлением и целевым образом жизни. Возвращаюсь к докладу.
</p><p>Еще один спорный момент доклада — тезис о том, что у животных нет состояния стресса. Конечно, он есть. Когда животное пугают или наказывают, или оно лишается привычного окружения, образа жизни стресс — есть. Все хозяева кошек и собак. наблюдавшие их при изменении обстановки, напрмиер, при переезде, не говоря уж о потере хозяина это знают. Насколько эти механизмы аналогичны тем, которые работают у человека — вопрос открытый, надо смотреть исследования. Но мнение о том. что животные умеют жить «здесь и сейчас», а человек сам загоняет себя в стресс — оно неверное.
</p><p>Но вот то, что люди замечательно загоняют себя в стресс — это верно. Способов, которыми человек это делает — много: постоянные воспоминания о негативных историях прошлого, с низкой оценкой настоящего, в котором мало платят и никто не понимает, с низкой самооценкой типа «я плохая мать», со страшными сценариями будущего. И этот цикл раскручивается, мы постоянно давим на педаль стресса, осознанно и не осознанно.
</p><p>Это отнимает энергию. Задача — замечать такие привычные сценарии мышления и менять их. И надо именно поменять способ мышления и жизни. Потому что приходит человек со словами «я замотан на работе, хочу worklife баланс», с ним . Он выделяет время 2 часа или дет в отпуск — а ему не комфортно.
</p><p>Что делать? Учимся рационально управлять своими мыслями, снижаем аналитическую нагрузку на мозг, анализируем, чтобы не пропускать новые негативные программы. Выявляем свои ограничивающие убеждения и привычки, и работаем с этим. Первый шаг — остановиться.
</p><p>Отмечу, что звучит это хорошо, но реально тут много важных деталей. Во-первых, если у вас жесткий стресс, то ресурсов для рационального мышления просто нет. И надо работать с восстановлением. Во-вторых, привычки — они просто так не останавливаются, психологи, которые работают с клиническими случаями хорошо это знают, в литературе много всяких случаев описано. Вообще привычка — она же не просто так возникла. Это стереотипный способ сделать что-то. Например, курение может быть привычным способом взять паузу и подумать. И ты должен научиться брать паузу и думать иными способами, понять по какому поводу у тебя возникает этот способ действия и заменить его на другой. Это если в конструктиве. Но, кстати. дальше в примерах было как раз изменение формулировок, а вовсе не остановка, по поводу которой в докладе был показан жесткий ролик.
</p><p>Примеры Марины из своей жизни.
</p>
<ul><li> Мысль «не хватает времени» поменяла: «на важное у меня хватает время, и план дня под контролем»</li>
<li> У нее были сложные отношения со свекровью, и негатив при одной мысли. Тоже переформулировала.</li></ul>
<p>Метафорически это можно выразить: что поливаем, то и растет, если поливаем негатив — он растет. Я тут отмечу, что с точки зрения нейрофизиологии, всякое прохождение мысли по некоторому пути подкрепляет этот путь — так устроен мозг, именно за счет этого обеспечивается его обучение в повторяющихся ситуациях.
</p><p>Еще кейс. Начинающий дизайнер, коуч, ему не дают много денег. Просто потому, что есть неявные предвкушения «я недостойна», и это сказывается при обсуждении суммы. И для начала просто надо представить, что берешь больше. И попытаться решить «не беру дешевые заказы» — даже если дорогих нет, чтобы культивировать «я достойна». Три месяца она ждала, потому что это другая ценовая ниша, но потом клиент появился.
</p><p>Это от рационального, над водой. А под водой — состояние, когда аналитический мозг не возбужден. Ей помогает калейдоскоп. Смотреть на небо. Медитации. Я тут отмечу, что это все — работа с лимбической системой, которая как раз отвечает за эмоции человека. При этом прямое воздействие невозможно, это другие участки мозга. И там есть разные техники успокоения. подходящие для разных ситуаций. Это — индивидуально. и надо накапливать свой набор методов, но при этом важно различать, какого характера у тебя беспокойство сейчас, чтобы отвечать адекватно.
</p><p>И последнее, что было в докладе: в жизни всего 27740 — дней. Поэтому не надо ждать подходящего момента, время уходит. Надо жить! Самое главная сила — мы сами. Уделяйте внимание себе.
</p>
<h1><span class="mw-headline" id=".D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9_.D0.97.D0.B0.D1.85.D0.B0.D1.80.D0.BE.D0.B2._.D0.A1.D0.BF.D0.B8.D0.BA.D0.B5.D1.80.D0.91.D1.83.D1.81.D1.82.C2.A0.E2.80.94_.D0.BC.D0.B0.D1.81.D1.82.D0.B5.D1.80.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D1.80.D0.BE.D0.B4.D0.B2.D0.B8.D0.B6.D0.B5.D0.BD.D0.B8.D1.8F_.D1.8D.D0.BA.D1.81.D0.BF.D0.B5.D1.80.D1.82.D0.BE.D0.B2_.D0.BD.D0.B0_.D1.80.D1.8B.D0.BD.D0.BA.D0.B5">Дмитрий Захаров. СпикерБуст — мастерство продвижения экспертов на рынке</span></h1>
<p>Боль рынка — мероприятия ради мероприятий, много упакованных не-экспертов с маркетингом. Профи не умеют себя продавать, а те, кто умеют продавать — не в смете заказчика. И много ситуаций, когда на мероприятие не согласовывают малоизвестного профи, а берут известную пустышку.
</p><p>Цель — помочь твердым экспертам занять место на рынке. Программа спикербуст.
</p>
<ul><li> Модуль 1 — упаковка на рынке, редизайн и т. п.</li>
<li> Модуль 2 — основа продаж и работы с командой (поддержки) — когда продажи уже пошли</li>
<li> Модуль 3 — мастерство на сцене и за сценой. Учат избегать фатальных ошибок. Логика заказчика. И повторные продажи.</li>
<li> Модуль 4 — имидж и репутация — соцсети и прочее</li></ul>
<p>Это все для работы с госсекторами и корпорациями, не b2c — там другие программы.
</p>
<h1><span class="mw-headline" id=".D0.91.D0.BE.D0.BD.D0.B4.D0.B0.D1.80.D1.8C_.D0.90.D1.80.D0.BA.D0.B0.D0.B4.D0.B8.D0.B9._.D0.9F.D1.80.D0.B8.D1.80.D0.BE.D0.B4.D0.B0_.D0.92.D0.BB.D0.B0.D1.81.D1.82.D0.B8._.D0.A6.D0.B5.D0.BD.D0.B0_.D0.B8_.D1.82.D0.B5.D1.85.D0.BD.D0.BE.D0.BB.D0.BE.D0.B3.D0.B8.D0.B8">Бондарь Аркадий. Природа Власти. Цена и технологии</span></h1>
<p>К сожалению, я не увидел в докладе не было целостной картины, объясняющей природу власти. И классификации типов власти тоже не было, хотя начиная с Аристотеля есть различные классификации устройства общества или организации и соответствующие им разные типы власти. Было лишь довольно большое количество разных тезисов про власть, которая представлялась интуитивно-понятным и однородным явлением. При этом власть рассматривалась идеализированно, в том смысле что реальная жизнь дает самые разные примеры людей, обладающих властью, но это во многих тезисах оставалось за кадром. В любом случае, тезисы — любопытные, и некоторые из них их интересно покрутить в голове, понять ваше отношение, поэтому я их публикую с некоторыми комментариями.
</p><p>Мы видим то что знаем. Созвездия видишь, если знаешь о них. Это, в том числе, касается устройства власти.
</p><p>Что нас ограничивает по пути вверх? Уровень в системах и обществе — определяется способностью жить в стрессе. С подъемом стресс возрастает, потому что все больше людей зависит, больше ответственность за решения. Я тут отмечу, что возрастание стресса вовсе не обязательно связано с ответственностью, в некоторых системах власти возрастает страх наказания. А есть конструкции, где наоборот, ответственность размывается, и там стресс не увеличивается.
</p><p>Развитие компании — внутренние вызовы, готов ли войти в большую систему с новыми вызовами, или хочешь остаться в своей нише. Я ms тут тоже отметил, что дихотомия привычное или масштаб — ложная, масштаб не обязательно означает качественное изменение работы, с другой стороны, компания может перестраиваться и рушить привычное без всякого роста.
</p><p>Путь героя. Власть — то, к чему истинный лидер не стремится. Просто ему доверяют и он оказывается в позиции. Как король Артур, вытянув меч. Отмечу, что формулировка — красива, но есть вопрос: а к чему же стремится этот истинный лидер, и почему вдруг ему доверяют. И стоит ли оказываться истинным лидером, если власть тебе не нужна. Без рассмотрения этих вопросов это — лишь общие слова.
</p><p>Древний Рим: Цезарю многое запрещено, потому что позволено все. Самоограничения. Ловушка власти для слабой личности — иллюзия вседозволенности. Тот у кого реальная власть. Отмечу, что про тезис про самоограничение — красивый, но реальная история римских императоров дает очень разные примеры, в основном там никаких ограничений не было.
</p><p>Вообще принципиальный вопрос как раз в том, хочет ли лидер чего-то сделать с помощью власти, и что именно. И самоограничения часто — не потому что получил власть, они оказываются нужны для того, чтобы достичь своих целей. Или не нужны, цели достигнуты — и тогда их нет. Но тема целей вообще не затрагивалась в докладе.
</p><p>Стресс, связанный с властью часто снимают через алкоголь и секс, а это путь в никуда. Многие проблемы возникают в бизнесе, когда достиг успеха, развелся с женой, завел молодую. И это — проблема вседозволенности. А реальный путь для принимающих ответственные решения — саморазвитие, постоянное обучение. Я бы сказал, что тут есть разные варианты, что есть не единичные кейсы, когда саморазвитие приводит людей к отказу от власти и уходу из бизнеса, хотя спиваться действительно не вариант.
</p><p>Власть: управление, организация, манипуляция, лидерство. Это близкое, но разное.
</p><p>История — наука о борьбе за власть (о смене власти). Но в школе так не говорят. Задача истории — объяснять людям, что нынешняя власть — легитимная и лучшая из возможных. Первая литература — жизнеописания правителей. Медицина, география — потребителями были военные и власть.
</p><p>Руссо: высшая задача власти — быть незаметной. Отмечу, что это опять из идеальной картины.
</p><p>Как только мы допускаем, что под чьей-то властью — негативная реакция, включаются подростковые паттерны. Тут я не согласен, это вопрос культуры и стереотипов, коннотаций, связанных с термином «власть», они — разные.
</p><p>Концепт свободы: русский — воля, Европа — альтернативы и самостоятельный выбор, Украина — чтоб никто не указывал.
</p><p>Когда у людей в компании иллюзия, что власти нет — люди забываются. Надо напоминать — внеплановые проверки «как дела».
</p><p>Решения на уровне руководства экономически не самые эффективные и странные. Но если добавить управляемость компании — объяснимо. Но я бы отметил, что слово «управляемость» тут — неверное, правильно формулировать, что у руководителей есть собственные интересы, которые не всегда явно озвучены, и решение принимают с их учетом.
</p><p>Для чего люди стремятся к власти?
</p>
<ul><li> чем выше в пирамиде — тем больше ресурсов</li>
<li> самоутверждение</li>
<li> служение</li></ul>
<p>И тут я отмечу, что в зависимости от этих стремлений человек будет осуществлять власть, властвовать сильно по-разному, при этом вариант с ресурсами тоже скрывает разнообразие — зачем человеку нужны ресурсы в распоряжении. И было бы интересно услышать анализ вариантов.
</p><p>Обсуждают кандидата: «Что не рвется к власти — хорошо, важно решать задачи, а не самореализовываться», на это возражение «Скромность — признак больших амбиций».
</p><p>Власть — необходимое условие для реализации прорывных идей, личных стратегий. Я скажу, что это — сильно от идеи зависит, и от выбранного способа реализации. Власть — один из способов.
</p><p>Весной 2022 в крупных компаниях лидерское поведение продемонстрировали не те, кто был в кадровом резерве, кого учили. Я бы считал, что это — естественно, отбор вели, имея ввиду совершенно другие сценарии.
</p><p>Удержание, сохранение власти. Надо показывать результат.
</p><p>Самый первый закон, который правят новые избравшиеся ребята — закон о выборах чтобы закрыть использованные ими дыры другим. Это было бы интересно услышать с анализом.
</p><p>Ум полководца. Почти постоянное лавирование. Судьба Жукова: слушаем линию штаба, но работаем по месту. Сверхпопулярность — он отдал лавры.
</p><p>Инструмент удержания власти — иметь адекватную картину реальности. Иллюзорная картина — основа неверных решений, недовольство и т. д. Сеть независимых информаторов. Гораций. Власть, лишенная разума, падает под тяжестью собственного века.
</p><p>Правитель не имеет права на ошибку. У одного коллеги была идея проводить переговорные турниры среди владельцев бизнеса перед сотрудниками. Все прислали замов. Акела промахнулся — последствия понятны.
</p><p>Книга Крестный отец — там логика альтернативных систем. Лучше фильма. И там есть эпизод, когда человек жалуется на проблемы, а ему отвечают: «Если бы ты помогал друзьям, проблем бы не было, а ты зазнался».
</p><p>Фильм Миллиарды — противостояние власти и гос.машины. У бизнеса есть деньги, но нет власти.
</p><p>Работа «Конец власти» — как раз про распределенность. Но! Сейчас у нас фаза реставрации власти.
</p><p>Паранойя — профдеформация во власти.
</p><p>Родительская власть. Опыт работы с подростками-спортсменами. Для подростков это бла-бла-бла из мира взрослых — от родителей, учителей, одноклассников.
</p><p>Компании корпоративный стиль — как сотрудник относится показывает лояльность.
</p><p>Способ поставить сотрудника на свое место — давать задачи, которые не справятся.
</p><p>Шахматы и карты. В картах — вариативность и блеф, в шахматах — открытая позиция. В неопределенности — самые большие страхи.
</p><p>Цена власти. Личность, паранойя, проверенные сценарии принятия решений — а они могу устареть. Пауки в банке, конкуренция за близость к телу, предательство ближнего круга — периодическая чистка команд как средство борьбы. Косяки фанатов переносятся на правителя.
</p>
<h1><span class="mw-headline" id=".D0.9B.D0.B5.D1.82.D1.83.D0.BD.D0.BE.D0.B2.D1.81.D0.BA.D0.B8.D0.B9_.D0.92.D1.8F.D1.87.D0.B5.D1.81.D0.BB.D0.B0.D0.B2._.D0.9E.D0.B1.D1.80.D0.B0.D0.B7.D0.BE.D0.B2.D0.B0.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.BF.D1.80.D0.BE.D0.B5.D0.BA.D1.82_.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B8.D0.B9_.D0.9F.D0.BB.D1.83.D1.82.D0.B0.D1.80.D1.85._.D0.92.D0.B5.D0.BB.D0.B8.D0.BA.D0.B8.D0.B5_.D0.B8.D0.BC.D0.B5.D0.BD.D0.B0_.D0.A0.D0.BE.D1.81.D1.81.D0.B8.D0.B8">Летуновский Вячеслав. Образовательный проект Русский Плутарх. Великие имена России</span></h1>
<p>Вячеслав известен методикой менеджмента, основанной на книге Суворова «Наука побеждать», и в начале доклада Вячеслав немного рассказывал про то, как она появилась. А потом была основная тема — серия исторических книг о великих именах России.
</p><p>Основное образование Вячеслава — психолог. Книга по диссертации, до сих пор курс читает. Потом была работа в Менатеп, тренинги в бельгийской компании, институт бизнеса и политики и лаборатория технологий сити-групп (к сити-банку отношения не имеет, совпадение названий случайное). И у него было желание сделать российскую методику, и в какой-то момент он понял, что Наука побеждать Суворова — вполне применима к менеджменту. Первый тренинг был в 2006, в 2009 — книга. С тех пор доработка 7 изданий.
</p><p>Книга по теме, которая заводит и которой занимаешься. 7 военно-деловых книг, моделирование сражений по суворовски.
</p><p>Бородино по-суворовски. Реальный сценарий: стоим и умираем, а Наполеон подвозит пушки и расстреливает. Суворов никогда не ждал, он нападал. А там был период разворачивания Наполеона — можно было бить. И вот — дают вводную и разработать диспозицию. Была игра, на следующий день стратегическая сессия, и вдохновленные игрой они сделали план, выполнили. И это — технология: выделение ключевых субъектов, ключевых факторов, сценарий победы. Это не анализ Исигавы, swot или другие подходы, это — оригинальное. И что важно: ты не выводишь стратегию, ты придумал сценарий, а потом можно проверить.
</p><p>Терапевтическо-смысловое фехтование. Не боевое искусство, терапевтическая практика. Адаптации 12+ и 7+
</p><p>Проект Русский Плутарх — великие имена России. Все великие 18 века воспитывались на Плутархе: Екатерина, Фридрих II, Потемкин, Суворов, Иосиф III и многие. При этом Плутарха обвиняли в недостаточной историчности, что он пишет про хорошее, а про плохое замалчивает. Его ответ — я воспитываю. И идея Вячеслава — сделать аналогичную Плутарху серию книг на русской истории, великих именах России. Потому что главный враг России — зажравшийся бюрократизм. Победить — только через воспитание, через описание героев. И это — русская элита.
</p><p>Для Суворова быть русским — быть лучшим. Не национальность — Милорадович, Багратион, Дерфельден. И они считали себя русскими. Серия Великие имена России. 10+ Много — Суворов, Петр, Румянцев, Потемкин, Скобелев, Брусилов. Суворов ставил Румянцева выше себя, никто не превзошел успех в первую турецкую. 300 тыс. турок против 30 тыс. своих. У Суворова 1:4. Про Румянцева не знают — потому что не был в образцах в речи Сталина.
</p><p>Дети читают — он нашел формат, увидел в детской книге о Суворове Сергея Алексеева: короткий рассказ на 1.5 страницы обязательно с интригой, примерами, и хорошие иллюстрации.
</p><p>Покрышкин. Тактика воздушного боя, тиражированная на страну, и тактика патрулирования группами. И подготовка летчиков. Он завоевал господство в воздухе.
</p><p>Адмирал Кузнецов. Командующий флота. Боевая готовность сразу. Прорыв в центре, на севере не двинулись, на юге — позже. И это обеспечивал флот. Флот не потерял ни одного корабля и ни одного самолета. Потому что была трехступенчатая система, и он привел в готовность к 22.06. и даже атаковал. И в августе 1941 бомбардировка Берлина. Про Кузнецова не знаем, потому что сложные отношения с Жуковым и когда Жуков при Хрущеве стал минобороны — уволили.
</p><p>В школе проводят уроки ВОВ. Но она надоедает — потому что все про одно. А есть конец 18 века — там другая культура победы. «Гром победы раздавайся». Жертвы, потом побеждаем. А в конце 18 веека Суворов, Ушаков — победы с малыми потерями.
</p><p>Сейчас новые издания книг, РВИО (российское военно-историческое общество) — вычищенные по историческим фактам.
</p><p>Про Кутузова не готов написать. Потому что конъюнктурщик: рядом с Суворовым — по-суворовски, а с Александром — слил Аустерлиц, и Бородино тоже. Хотя стратегически пустить Наполеона в Москву — правильно.
</p><p>Есть мысли продолжить русскими литераторами: Достоевский, Толстой, Чехов, Бунин, Пушкин… Учеными. Советскими полководцами: Василевский, Шапошников, Жуков, Конев, Рокоссовский, Кожедуб… И российскими предпринимателями Губонин, Третьяков, Демидова, Мамонтов, Морозов, Путилов, Абрикосов, Чижов…
</p><p>Откуда источник? Эксмо выпускали книги — сборники документы про великих. Он собирал. Петр, Ушаков и много других. Письма издавали, например, письма Суворова.
</p><p>Петр, воинский артикул. На первом месте: солдат должен быть верующим, а кто будет колдовать — предавать казни.
</p><p>Но РВИО — цензура не только историческая, но и политическая. Александр II пустил евреев в столицы, а Александр III — выслал. Ротшильд и другие обиделись, Александр пытался договориться, послал княгиню Витгенштейн в Париж неформально поговорить, Ротшильд ответил «слишком поздно и никогда с Романовыми». РВИО Эпизод потребовали убрать.
</p>
<h1><span class="mw-headline" id=".D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.9A.D1.83.D0.B4.D1.8C-.D0.A1.D0.B2.D0.B5.D1.80.D1.87.D0.BA.D0.BE.D0.B2.2C_.D0.B4.D0.B5.D0.B9.D1.81.D1.82.D0.B2.D1.83.D1.8E.D1.89.D0.B8.D0.B9_.D0.BA.D0.BE.D1.81.D0.BC.D0.BE.D0.BD.D0.B0.D0.B2.D1.82._.D0.9C.D0.B5.D1.82.D0.BE.D0.B4.D0.B8.D0.BA.D0.B0_.D0.BF.D0.BE.D0.B4.D0.B3.D0.BE.D1.82.D0.BE.D0.B2.D0.BA.D0.B8_.D0.BA.D0.BE.D1.81.D0.BC.D0.BE.D0.BD.D0.B0.D0.B2.D1.82.D0.BE.D0.B2">Сергей Кудь-Сверчков, действующий космонавт. Методика подготовки космонавтов</span></h1>
<p>Сергей рассказывал о методике подготовки космонавтов. И многое актуально не только для космонавтов, потому что основа — методы эффективного обучения и эффективной коммуникации в команде. Хотя экипажи космонавтов срабатываются долго, в компаниях, скорее всего такого не будет. И задачи они решают более сложные. Тем не менее, на методики полезно взглянуть в залоге практического применения.
</p><p>Космонавт — человек, который постоянно учится. И должны быть люди, которые умеют учиться. Когда отбирали первых космонавтов — это было в новую профессию. По физическим характеристикам подходили летчики-истребители. Работа на высоких скоростях, умение автономно принимать решение и так далее. Когда первые космонавты слетали, набор задач изменился. Летная подготовка есть обязательно, обучают даже тех, кто не был летчиком. Но кроме этого: техническая подготовка, психологическая кондиция. Требования по здоровью сейчас не столь критичны, хотя сейчас космонавты работают на станции 380 дней: мы знаем, как полеты влияют на здоровье и можем компенсировать. А вот по знаниям и работе — выше, потому что каждый день из года на станции распланирован почти по минутам, при этом задачи — очень разные, из совершенно разных областей.
</p><p>Как устроен отбор на земле?
</p>
<ul><li> Способность к обучению и самостоятельному обучению — быстрое освоение научной и технической информации, на отборе требуют освоить учебник по неизвестной системе за один день.</li>
<li> Все получаемые знания надо реализовать в навыках — обучение для программы полета. Теория, тренировка, практика каждый день.</li>
<li> Психологические и физический отбор.</li></ul>
<p>После отбора 2 года кандидат в космонавты. Около 130 экзаменов. Не болеть, сдавать на 4-5. Госэкзамен — технические специалисты спрашивают по всем предметам 1 час произвольные вопросы. Чтобы понять, что все знаешь.
</p>
<ul><li> Почему корабль как перевернутая фара?</li>
<li> Почему перегрузки на взлете 4 единицы, можно ли больше или меньше?</li>
<li> Как устроена схема электропитания и почему?</li></ul>
<p>Потом — продолжается. Уже в деталях. Если сначала — общие схемы двигателя, то потом — конкретика в деталях. Еще 2 года — допуск к полету. Пробных полетов нет, сразу полный полет.
</p><p>Назначают в экипаж — 1.5 года срабатывается. Так, чтобы вместе сделать программу. Экипажи — интернациональные. Официальный язык — английский, на практике аббревиатуры и микс. Закрыть дверь — close, запереть — lock, а еще прикрыть не запирая — по-русски «прикрыть», потому что по-английски длинно. В каждом экипаже свой сленг.
</p><p>Людей в экипаж подбирают не по совместимости, а по очереди. Все обучены. И надо уметь работать друг с другом. Объяснение позиции, избегать конфликтов и решать. Потому что 7 человек в замкнутом объеме год.
</p><p>И это — часть обучения — как объяснять. Нужно не только в полете. Но на Земле — много способов избежать, а тут — никак. Конфликт — крайнее выражение несогласия. А несогласие, различие точек зрения — нормально. А вот когда это ведет на эмоции и не дает решать ситуацию — получается конфликт. По его опыту наверху конфликтов не было. Спорные ситуации были — но они ищут общий язык и так далее. Потому что конфликты ставят крест на эффективности. Опыт гражданской жизни: 70 % финансов компании уходят корнями в конфликты.
</p><p>Вопросы.
</p><p>Гигиена — не проблема, есть разница в технике, это не слишком интересно. По сексу: полгода-год можно потерпеть, проблем нет. На Земле тоже многие терпят, например, полярники.
</p><p>На борту круглосуточный интернет и IP-телефония.
</p><p>Практики саморегуляции.
</p>
<ul><li> На этапе отбора психологи проверяют, что можешь контролировать — стрессоустойчивость и т. п.</li>
<li> У каждого есть свой предел, его надо знать. В подготовке — несколько видов тренировок-тестов, чтобы понимать пределы и возможность большего.</li>
<li> Парашютная подготовка: первое — чтобы спастись, а еще — стрессоустойчивость и работа в стрессе. 40 прыжков за сборы.</li>
<li> Как создать стресс? На тренажере — трудно. Прыжок с 4 км — физиологический стресс. И с 4 до 1 км у тебя минута решить задачу, которую тебе дают в закрытой бумажке, которую открываешь после стабилизации падения. И А в Б поезд с одной скоростью, навстречу — другой и так далее. Еще циферблат часов произвольно повернутый с одной риской. Решение — вслух проговариваешь, потом надо завершить решение и вернуться к управлению парашютом.</li>
<li> Культура — проговаривать все действия. И это тоже учится. С квитанциями. И все намерения озвучиваешься — чтобы все в курсе.</li>
<li> Записи сдаются. Психологи оценивают, и сами слушают. В стрессе кажется что все быстро, а слушая — видно что паузы.</li></ul>
<p>Зачем в космонавты? Все разные. Есть люди, которые любят вызовы. Есть регулярные, неопределенность — стресс. А ему наоборот, неопределенность, первому решить задачу, сделать вклад — это то, что нравится. Он — такой, и другие космонавты тоже.
</p><p>Протоколы на конфликтную ситуацию — нет. Есть негласная правило избегать конфликтов. А еще есть множество правил, как делать конкретные работы. И ЦУП для спорных вопросов — там эксперты. Переходя к Земле, если двое спорят — возможно, есть еще много дополнительных вариантов, надо спросить.
</p><p>Детей в космос не запускают, более витка. На суборбитальный полет — да, было 16 минут. Почему? Опасно, это объективно. А еще — физические перегрузки и перестройка организма от гравитации к невесомости — пока нет.
</p><p>МКС — до 2028 и Российская орбитальная станция после 2027, без перерыва в полетах.
</p><p>Про НЛО. Неопознанные были, но потом опознавались.
</p><p>Семья появилась до того, как стал космонавтом. Родителям не очень понравилось, переживали, но не препятствовали и поддерживали.
Гораздо больший стресс, когда готовишься, но не летишь — потому что годы прошли зря.
</p><p>Специализация и обучение. Космонавт — универсален, больше всего совмещений. Пилот-бортинженер, пилот космической станции, повседневная жизнь, обслуживание и ремонт полной автономной жизни, научные эксперименты — физические, биологические, химические и ты должен разбираться в экспериментах, взаимодействовать с учеными, и еще медик на случай непредвиденностей.
</p><p>Актуальные вызовы космонавтики. Сейчас интенсивное развитие. Экспедиции в год — регулярные, жить умеют. И хотят дальше. Исследование окружающего заложено генах человека. Ближайшие планы — новая российская станция, на которой будут полеты дальше.
</p><p>Дискуссия между пилотируемого и беспилотного изучение космоса. Как путешествие — личное или виртуально через гугл-карты и статьи.
</p><p>Управление марсоходами — говорил с оператором. Живой геолог сделал бы гораздо быстрее, чем дистанционно.
</p><p>О нештатных ситуациях думают заранее — побочные сценарии есть. И они на тренажерах отрабатывается. И профилактика до сигнализаций.
</p><p>Экипаж назначается за 1.5-2 года до старта. Может быть и меньше, когда были изменения у уже назначенного экипажа. Всегда основной и дублирующий экипаж. Было, что назначили за 1.5 года, а полетели через год. Есть учебный план по всему-всему до дня старта. Если время сокращается, часы не уменьшается.
</p>
<h1><span class="mw-headline" id=".D0.A1.D0.BA.D1.83.D0.BB.D1.8F.D0.B1.D0.B8.D0.BD.D0.B0_.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0._.D0.9F.D0.B5.D1.80.D0.B5.D0.B8.D0.BC.D0.B5.D0.BD.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D0.B9_.D0.B8_.D0.BF.D0.B5.D1.80.D0.B5.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BD.D0.B0.D0.B8.D0.BC.D0.B5.D0.BD.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B9._.D0.9F.D1.80.D0.B0.D0.BA.D1.82.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.BE.D0.B5_.D0.BF.D1.80.D0.B8.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5">Скулябина Ольга. Переименование определений и переопределение наименований. Практическое применение</span></h1>
<p>Рассказ о нарративных практиках, связанных с определением и изменением смыслов. Лингвисты многое знали еще в 50-е, психологи дошли до этого только в 70-х, а инженеры — еще позже. Она использовала многие практики как психолог, но многое поняла, когда начала заниматься искусственным интеллектом.
</p><p>Язык — Речь — Сознание. Язык — слова, значения и синтаксис. С конца 19 века включают психический компонент. Язык не может существовать без мышления, а наоборот, мышление без языка — может, через живопись, музыку и так далее. Кроме естественных языков есть много языков специальных целей, включая жаргоны и сленги.
</p><p>Речь — процесс, выражение себя с помощью языка. Речь формирует мышление, языковое мышление определяется языком. Языком занимаются не только лингвисты, но и поэты и писатели. Шалтай Болтай объяснял Алисе язык, на котором говорил.
</p><p>Основная функция сознания — отражение бытия.
</p><p>С языком связано много проблем. Семантика слов - закрепление некорректно. Сейчас в некоторых социальных группах козел — бывший, а не животное. Слово в сознании не имеет содержания, есть много абстрактных слов: Нормально, Редукционизм, Эффективность. И много других примеров.
</p><p>И есть много нарративных практик, которые специально меняют смыслы. Пересочинение — так создают учебники истории и мифы. Экстернализация — выносим внутреннее наружу, головная боль как отдельный объект, отвязанный от субъекта. Выявление доминирующих дискурсов (деконструкция и remembering) — неявные коды и установки, при этом у многих есть конкретные социальные интересанты. Их надо проявлять и понимать, кому это нужно. Рефрейминг контекста: ежик говорит: «я сильный», его пнули, он летит, но не отказывается: «я сильный, но легкий». И так далее.
</p><p>Был ряд других примеров, интересно послушать и оценить себя — насколько ты это видишь в рекламе, пропаганде и в деловых текстах, где часто используют те же приемы.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D1.8B.D1.80.D0.B5.D0.BD.D0.BA.D0.BE.D0.B2.D0.B0_.D0.98.D1.80.D0.B8.D0.BD.D0.B0._.D0.9A.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D0.BD.D1.8B.D0.B9_.D0.B8.D0.BD.D1.82.D0.B5.D0.BB.D0.BB.D0.B5.D0.BA.D1.82">Алыренкова Ирина. Командный интеллект</span></h1>
<p>Это рассказ про эксклюзивные нестандартные тренинги, которые она проводит для своей компании. Основной запрос бизнеса — максимальные результат минимальными ресурсами. Тренинг за два часа с немедленными результатами. Классический коучинг не работает — там сроки 9 месяцев, а за это время сейчас все меняется.
</p><p>Критерии эффективности — по Клаттербаху: цель и мотивация; доверительные отношения; внутренние процессы; внешние процессы; процессы развития. Она работает по Эриксону — там цели и ценности.
</p><p>Три вектора: бизнес, команда, личность. Сначала надо посмотреть типологии: по disc, mbti и по Белбину. А как рабочую схему использует интегральную карту, 4 квадрата: внутреннее — внешнее, личное — коллективное, по ней смотрит статистику квартальной работы.
</p><p>Тренера — совместители, кому интересно. Даже директора. Собственные тренеры гораздо дешевле внешних.
</p><p>Цели команды когда знаете — очень эффективно. Вопросы сотруднику перед сессией: сформулируйте цели компании и так далее — по Ленсиони.
</p><p>Чем активнее лидер, тем пассивнее команда. С этим тезисом не все участники согласились, и в обсуждении поняли, что для Ирины активный это доминирующий, а у других это слово значит разное.
</p><p>Лидерами не рождаются, они эволюционируют. Сегодня такой, а завтра — другой, растет вместе с командой.
</p><p>Дальше в презентации было много практик, в докладе все это рассказать подробно не успели.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.B0.D0.B7.D0.B8.D0.BA.D0.BE.D0.B2.D0.B0_.D0.98.D1.80.D0.B8.D0.BD.D0.B0._.D0.9A.D0.B0.D0.BA_.D1.81.D0.BB.D0.BE.D0.B2.D0.B0_.D0.BF.D0.BE.D0.BC.D0.BE.D0.B3.D0.B0.D1.8E.D1.82_.D1.82.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D0.B8_.D0.BB.D1.8E.D0.B4.D0.B5.D0.B9_.D0.B8_.D0.BA.D0.BE.D0.BC.D0.BF.D0.B0.D0.BD.D0.B8.D0.B9">Мазикова Ирина. Как слова помогают трансформации людей и компаний</span></h1>
<p>Слова и их коннотации надо принимать во внимание. И не достаточно просто определить слово, потому что коннотации все равно будут проявляться. Например, говорят, что один человек может управлять 15, если больший масштаб — нужна структура, процессы. Но эти слова — система, процессы — вызывают конкретные негативные коннотации: винтик, механизм, регламент. Или другие слова: управление по целям, KPI, результат — тоже коннотации: сухость, давление, напряжение, госконтракт, людей выжимают.
</p><p>А вот управление по ценностям — позитивные коннотации: миссия, доброе, светлое, самоуправление, спонтанность, творчество, человеческий капитал, каждый — личность. Впрочем, отмечу, что это — в аудитории, которая не помнит СССР, управление через идеологию, где все эти слова активно использовались так, что по их поводу формировался скепсис.
</p><p>Сотрудник — подчиненный. Надо чтобы слова не звучали заезжено, чтобы были их слова. KPI или показатель или метрика — важно.
При правильном ребрендинге слов — системы зазвучат по-другому. Надо вести осознанные коммуникации, которые соответствуют системе управления.
</p><p>Не говорить «ты ошибся», потому что человек сжимается, выпорет его.
</p><p>сначала что-то ляпнули, потом человек обиделся, саботирует. Потом приходит консультант «меняем систему управления, ваша не работает». А это не поможет, если коммуникация останется той же.
</p><p>Чтобы увидеть другого — надо увидеть себя. Она использует «Самоценность» — потому что у самооценки тоже негативные коннотации. Если вы хотите развить у подчиненных инициативу, то смените форму обращения, когда они пишут о будущих действиях: пусть они не запрашивают разрешение, а информируют о намерениях, это другое позиционирование. И отвечать надо соответственно: не «разрешаю», а «хорошо, принял к сведению», похвала тоже не помешает. При этом процедурно обе формы могут быть одинаковы: перед действием надо написать руководителю и получить положительный квиток. Форма — важна.
</p>
<h1><span class="mw-headline" id=".D0.90.D1.81.D0.B0.D0.B4.D1.87.D0.B0.D1.8F_.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0._.D0.9E.D0.B4.D0.BD.D0.BE_.D1.81.D0.BB.D0.BE.D0.B2.D0.BE_.D0.B8_100_.D1.81.D0.BC.D1.8B.D1.81.D0.BB.D0.BE.D0.B2.2C_.D0.BE.D1.82_.D1.87.D0.B5.D0.B3.D0.BE_.D1.82.D0.B0.D0.BA_.D0.BF.D1.80.D0.BE.D0.B8.D1.81.D1.85.D0.BE.D0.B4.D0.B8.D1.82_.D0.B8_.D0.BA.D0.B0.D0.BA_.D0.B2_.D1.80.D0.B0.D1.81.D0.BF.D0.BE.D0.B7.D0.BD.D0.B0.D0.BD.D0.B8.D0.B8_.D1.81.D0.BC.D1.8B.D1.81.D0.BB.D0.BE.D0.B2_.D0.BF.D0.BE.D0.BC.D0.BE.D0.B6.D0.B5.D1.82_.D1.81.D0.BF.D0.B8.D1.80.D0.B0.D0.BB.D1.8C.D0.BD.D0.B0.D1.8F_.D0.B4.D0.B8.D0.BD.D0.B0.D0.BC.D0.B8.D0.BA.D0.B0">Асадчая Ольга. Одно слово и 100 смыслов, от чего так происходит и как в распознании смыслов поможет спиральная динамика</span></h1>
<p>Доклад о том, что слова имеют разный смысл, и надо понимать, какими смыслами нагружены слова у твоего собеседника. В этом может помочь спиральная динамика, потому что ее уровни как раз задают типологию смыслов.
</p><p>Какие у вас ассоциации со словом «зеленый»: трава, яблоко и сопли? У всех — разное. И многие картины люди видят по-разному, в презентации была хорошая картина, на которой то ли женщина с шарами на быке, то ли лицо.
</p><p>Я разговариваю с очень разными в разных ролях, и слышат по-разному. Хотя я — вроде всегда одна. Я развиваюсь и меняю не только то, что делаю, но и то, как об этом рассказываю. И это вызывает разные реакции, мне говорят «что это ты — операционный директор — стервь, а как у костра пела». Ну да, пела, и сейчас могу, только это весело, а не эффективно.
</p><p>Сейчас на рынке сотрудники ванильных компаний, которые росли в иностранных компаниях, ушедших в 2022. Рафинированные в ожидании бережности отношений. Они вышли на рынок — и не устраиваются, потому что привыкли к обратной связи, а ее совсем по-другому выдают. Ей тоже недавно сказали: «ты результативная, но трындец токсичная», но для нее это — нормально.
</p><p>Вызов нашего времени — определить доминирующий цвет культуры. Понять ценности компании, сотрудников, лидеров на ключевых местах, соискателей. И гармонизировать эти цвета. Фигня, когда гендиректор встречается с продажниками на зарплате 30-100 и объясняет им что надо постараться на примере выбора Мальдивы-Бали при том, что у него 6 детей — такие примеры не воспримут.
</p><p>И надо понимать, что в корпоративной среде бывают очень разные конструкции. Например, зовут лидера изменений, который заранее жертва после запуска изменений, чтобы списать негатив. И это не всегда могут явно говорить на старте.
</p><p>В любой коммуникации структурируйте информацию: роль в которой собеседник сейчас, особенности функционала, корпоративная культура.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.BE.D0.BB.D0.BE.D0.B1.D1.83.D0.B5.D0.B2.D0.B0_.D0.90.D0.BD.D0.BD.D0.B0._.D0.94.D0.B8.D0.B0.D0.B3.D0.BD.D0.BE.D1.81.D1.82.D0.B8.D0.BA.D0.B0_.D0.B8_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D0.B5_.D1.81.D1.82.D0.B8.D0.BB.D1.8F_.D0.B2.D0.BE.D0.B2.D0.BB.D0.B5.D1.87.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BD.D0.B0_.D0.BE.D1.81.D0.BD.D0.BE.D0.B2.D0.B5_.D0.BC.D0.B5.D1.85.D0.B0.D0.BD.D0.B8.D0.B7.D0.BC.D0.B0_4_.D0.B4.D1.80.D0.B0.D0.B9.D0.B2.D0.B5.D1.80.D0.BE.D0.B2">Волобуева Анна. Диагностика и развитие стиля вовлечения на основе механизма 4 драйверов</span></h1>
<p>Практический доклад об оценке вовлечения и работе с ним.
</p><p>Есть 4 драйвера вовлечения: эмоции, смысл (зачем), видение (что), действие, и надо работать на все.
</p><p>Эмоции. Страх из-за неопределенности: неясно зачем, неясно что сделать, не получится — диагностировать относительно легко. Хотя за «не знаю чего начать» или «страшно» часто прячется отсутствие смысла.
</p><p>Спектр реакций на новое:
</p>
<ul><li> вовлеченные — да, подкрепленное действием;</li>
<li> последователи вовлеченных — да, но попозже);</li>
<li> противники — обоснованное нет с аргументацией, они ценны, потому что делают диагностику препятствий;</li>
<li> тихие саботажники (самая противная категория).</li></ul>
<p>Вовлеченность колеблется в зависимости от типа задачи.
</p><p>Стиль вовлечения зависит от руководителя. Не все умеют объяснять Зачем. Не все могут показать видение, или увлечь личным примером.
</p><p>Отсюда родилась идея опросника стиля вовлечения. 20 ситуаций и варианты действий руководителя. В варианты встроены конкретный способ вовлечения. Скорость заполнения 20-25 минут, ситуации не очень легкие. Результат — описание особенностей вашего стиля и краткие рекомендации.
</p><p>Важно, что 90 % проектов связано не с топами, а с мидлами. И именно они обеспечивают вовлеченность сотрудников. Поэтому им важно знать их стиль вовлечения, учитывать его, работая с сотрудниками.
</p>
<h1><span class="mw-headline" id=".D0.9B.D0.B0.D0.B4.D0.BE.D0.B3.D0.B0-.D0.AF.D1.87.D0.BC.D0.B5.D0.BD.D1.91.D0.B2.D0.B0_.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0._.D0.A1.D1.80.D0.B5.D0.B4.D0.B0_.D0.BA.D0.B0.D0.BA_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D0.BD.D1.8B.D0.B9_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81">Ладога-Ячменёва Ольга. Среда как командный ресурс</span></h1>
<p>Это рассказ о создании образовательной среды, способствующей креативности и формированию команд в корпоративных университетах. Источник концепции — <b>Ясвин «Образовательная среда»</b>. Среда — это коммуникации, система влияний и условий формирования личности, содержащая пространственный и социальный компонент. Чтобы была вовлеченность — надо говорить на языке среды.
</p><p>Векторное моделирование среды. Тест из 6 вопросов, чтобы начать диалог с заказчиком. Среда создается под участника, или наоборот, участник форматируется средой? Предполагается ли активность участников? Результаты — на схеме из 4 квадратов по двум осям: активность — пассивность и свобода — зависимость: карьерная — активность + зависимость (по правилам); догматическая — пассивность + зависимость; творческая — активность + свобода; безмятежность — пассивность и свобода. Как правило, все хотят в творческую среду: активность и свобода. Не осознавая рисков. Главное, что дает тест — чтобы заказчик увидел, что среда — это не что-то на уровне ощущений, а понятная конструкция, с характеристиками, с которой можно работать.
</p><p>Для описания используются параметры среды. И после этого можно мерить и управлять. Осознанность, интенсивность, широта (сколько форматов), устойчивость, социальная активность, доминантность (насколько важно обучение), мобильность (пересборка программы), эмоциональность, обобщенность (совместность курсов как целое), когерентность.
</p>
<h1><span class="mw-headline" id=".D0.A1.D0.B5.D1.80.D0.B3.D0.B5.D0.B9_.D0.91.D0.BE.D1.87.D0.B0.D1.80.D0.BE.D0.B2.2C_.D0.A1.D0.B5.D0.BD.D0.B5.D0.B6._.D0.A7.D0.B5.D0.BB.D0.BE.D0.B2.D0.B5.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_.D0.BA.D0.B0.D0.BF.D0.B8.D1.82.D0.B0.D0.BB_.D1.81.D1.82.D1.80.D0.B0.D0.BD.D1.8B">Сергей Бочаров, Сенеж. Человеческий капитал страны</span></h1>
<p>Многоплановый рассказ о человеческом капитале России и его формировании — проблемы рождаемости, образования и кадров для гос.службы.
</p><p>Человек в Москве, человек в провинции — фрейм жизни похож, но наполнение, возможности — разные. Человеческий капитал — это сумма всех. Способности человека реализуются в экономическом продукте — потому и капитал. Индивидуальный, корпоративный, национальный.
</p><p>Здесь много мифов. Вопреки представлением о пользе села и вреде города, смертность в сельской местности выше, чем в городах: качество питания, водка, смыслы жизни. Про госслужащих тоже есть мифы. Например, о всеобщей коррупции, при том, что только 5 % имеют доступ к деньгам.
</p><p>Миф, что госструктуры консервативны и не приемлют новое — реально многие хотят развиваться, но при этом на уровне муниципалитета бюджеты на развитие сотрудников — практически нулевые. Пример Сбера понятен, 10 лет рывка, но вложения в людей — гигантские. Но для госструктур тут засада: как только вкладываешь в сотрудников — тут же идет хайп, что чиновники за счет народа пляжатся. Но есть губернаторы, которые смогли сделать институты развития, и сейчас это тиражируется на всю страну.
</p><p>Знания о человеке: Петти (18 век, первое количественное измерение), Рикардо, Шульц и Беккер, Капелюшников и Гимпельсон. Беккер — просто посчитал и опубликовал. Сколько вкладывается, какая рентабельность. Инвестиции в образование — 12 % в год. Книга была диссонансом к гуманистической тенденции, которая призывала смотреть на образование без этих экономических аспектов, но именно она привела к усилению вклада в образование и решение социальных проблем.
</p><p>Образование стоит 150—300 тыс. в год. Если сравнить с зарплатой потом (если образование успешно конвертировалось), то это — выгодно. Я отмечу, что в современных российских условиях это — спорно, требует отдельного обоснования, а если смотреть на исторический опыт в масштабах мира, то в разных периодах и странах бывало по-разному. Но проблема — понятная: в моменте ему надо деньги взять, и кредит — это стремно, потому что риски. Есть образовательные сертификаты, но рынок не сформирован.
</p><p>С современными методами тоже сложно. Коучинг и ассесмент в госуправлении — стремно, для министров это как таро. Но когда прикрепляли коучей к директорам, губернаторам и их командам — отношение менялось. То есть пример — действует.
</p><p>По индексу человеческого развития Россия в группе стран с очень высоким рейтингом, больше 0.8, занимает 52. Это продолжительность жизни, образование и доход. Возможность самореализации сейчас 0.7, в нулевые было 0.3.
</p><p>Раздел Человеческий капитал в Стратегии национальной безопасности — там много направлений.
</p><p>Три типа людей:
</p>
<ul><li> эксперты, которые далеки от принятия решений</li>
<li> политики отвечают коммуникации</li>
<li> созидатели — на практике делают, агенты изменений, таких — единицы реально, особенно на госслужбе</li></ul>
<p>Все связано. Реальный кейс: в городе строится новый завод. Но в городе ничего не строилось с 2005, квартир, которые можно снять — всего 82. А надо 5000 на новых сотрудников. Получается, надо развивать город тоже, просто создать рабочие места — недостаточно.
</p><p>Направлений проектов — много. Например, учитель на несколько школ, например, по физике. Потому что все уехали, школы маленькие. Учителя надо довезти, и это — проект, это не просто нормативные документы.
</p><p>Межведомственность и территориальное разделение — проблемы. Реально у нас красная система с синим налетом, принцип: мои люди работают со мной, в соседний муниципалитет — не ездят, а при смене руководителя приходит новая команда.
</p><p>Рождаемость! Для воспроизводства надо 2.15 на женщину. Сегодня 1.35. Он падает во всем мире, и в России. И надо инвестировать в семьи с детьми, чтобы было много детей. Маткапитал как-то работает. Но вот комиссия патриарха по демографии, с женщинами разговаривают по абортам. И выясняется, что достаточно много делают аборты те, у кого уже двое детей.
</p><p>Госслужба. Исследование Марка Розина «лидер военного времени»: есть умозрительные представления о лидере, и есть те, кто реально стал лидером после 2014 на Донбассе. Александр Бек "Волоколамское шоссе: "Панфилов искал ресурсы в тех людях, которые есть.
</p><p>Как меняется подход на госслужбе? Конкурс лучших практик, школа резерва РАНХИГС, Лидеры России, ГосHR система управления кадрами, Ассоциация центров развития (Сенеж).
</p><p>Проект в рамках Россия страна возможностей «Это у нас семейное» — про лидерство.
</p><p>Опыт Нижнего Новгорода: на портале правительства региона открытые конкурсы, и это привлекает людей, дает возможность сделать очень сильную команду из людей из разных регионов: минобр из Питера, культнаследие — Самара.
</p><p>Госстарт: стажировки, диалог и другие практики, пилотируют, чтобы шла активная молодежь.
</p><p>Система заботы о сотрудников. Надо оформить ДМС, но если посчитать на всех — то цифра большая, ее надо озвучивать, и политики тут же встанут «с какой стати чиновникам ремонтировать зуб за счет остальных граждан». Эта та же проблема, что и с развитием госслужащих.
</p><p>Большинство госслужащих — женщины 45+. Пример Калуги — все мужики уехали в Москву, а женщины остались.
</p><p>Растет производительность, прибыль — когда люди вовлечены. И этим надо заниматься. Один работающий кормит 2 человек. Но где-то уже кормит 3. Безработица — низкая. И дефицит кадров, 60 % работодателей жалуются. В том числе для низкого слоя — кассиры, склад, водители. Я, правда, отмечу, что тут есть вопросы оплаты и вопросы корпоративной культуры, и стоит внимательно смотреть на разный опыт. При чем так было всегда, заводы, фабрики и другие предприятия были сильно разные и с разной культурой и привлекательностью, это можно ретроспективно посмотреть по литературе и мемуарам со второй половины 19 века, правда, со статистикой сложно. Но сейчас-то можно и померить.
</p><p>Кадровая стратегии региона. Первая в России — в Нижегородской области. При этом тренды и оценка движения, каждый год пересматривают. Центры профориентации в школе, закрепление СПО за якорными работодателями региона, создание единой онлайн-платформы с карьерными возможностями, маршрутизация входа в профессию.
</p><p>Самая уязвимая категория — те, кто закончил ВУЗ, пошел устраиваться — а он не нужен. Нужна маршрутизация входа, поддержка релокации в регион, проектный инклюзивный офис, повышение квалификации HR-кадров предприятий. Отмучу, что это — обратная сторона того, что система образования у нас не готовит самостоятельных людей, в советское время это было не нужно, государство маршрутизировало. Так что задачу стоит решать по двум направлениям: создавать соответствующую поддержку и воспитывать инициативность и самостоятельность, потому что современный мир требует именно этого, если играть в долгую за ведущее место в мире.
</p><p>Релокация из зоны СВО и поддержка — чтобы устроились на предприятия. Единицы результата, потому что есть страх релокации. Для релокации нужна инфраструктура, не только рабочие места — люди же едут с детьми, значит школы, десткие сады, поликлиники.
</p><p>Инклюзивность. 70 тыс. инвалидов, из них работает 20, потенциал есть.
</p><p>Квалификация кадровой службы на предприятия, на реальных заводах. Была идея воспользоваться опытом, а оказалось там справку получать — 5 недель, приехал из региона — 2 недели живи в общаге без зарплаты и так далее, их самих надо учить и перестраивать эту систему. Потому что процессы тоже формировались под местные кадры. когда у человека есть где жить, и две недели родители поддержат — поддерживали же все время учебы. Центры занятости в регионах. Инвесторы приходят в регион при условии, что есть люди, они готовы создавать производство и рабочие места, но не готовы сами еще и обеспечивать эти рабочие места людьми. А готовых людей — нет. получается замкнутый круг. его надо разомкнутью. Областное кадровое агентство, было на Сахалине, в Москве начинали, в Нижнем сделали.
</p><p>Ковид — была идея перебрасывать между предприятиями. Не подтвердилось, потому что есть недоверие к государству, лучше уволю по-тихому и заплачу 5тр штрафа за то, что не сказал.
</p><p>Воспроизводство кадрового капитала. Цикл Форммрование — Накопление — Сохранение — Развитие.
</p>
<ul><li> В Пятигорске — центр Машук, учат тех, кто учит.</li>
<li> В Крыму Меганом и Таврида, создали в чистом поле — про креативных</li>
<li> Мастерская управления Сенеж — про управленцев.</li></ul>
<p>И идея для ПИР: поехать не в Чад, а в Сенеж. Поработать с управленцами, министрами регионов. Их сейчас на ПИР нет, было бы полезно. Делать сильных людей России еще более сильными. Сенеж (это Солнечногорск) работает давно. Благоустроенная набережная 7 км. Лидерство в медицине. Наставничество. Центр компетенций Россия — страна возможностей — 90 центров в 50 субъектов.
</p><p>И в заключении — цитата Менделеева: богатство и капитал равно труду, опыту, бережливости — началу нравственному, а не экономическому.
</p>
<h1><span class="mw-headline" id=".D0.94.D0.BE.D1.86.D0.B5.D0.BD.D0.BA.D0.BE_.D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9._.D0.AD.D1.82.D0.B0.D0.BB.D0.BE.D0.BD.D0.BD.D0.B0.D1.8F_.D0.BC.D0.BE.D0.B4.D0.B5.D0.BB.D1.8C:_.D0.BF.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.9F.D0.B8.D0.A0.D0.B5.D0.B2.D0.BE.D0.B4_.D0.B0.D1.83.D1.82.D1.81.D0.BE.D1.80.D1.81.D0.B8.D0.BD.D0.B3.D0.B0_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B9">Доценко Дмитрий. Эталонная модель: правильный ПиРевод аутсорсинга бизнес-функций</span></h1>
<p>Очень интересный взгляд на аутсорсинг ИТ компании, не просто аутсорсинг исполнения проектов автоматизации, а целиком, с управлением. Отмечу, что есть печальный опыт аутсорсинга ремонтных служб с производства под флагом экономии, когда потом оказывалось, что внешние службы не могут обеспечить то же качество обслуживания, которое обеспечивали внутренние. Но это — для крупных предприятий, на которых свои ремонтные службы были. А вот когда мы говорим о мелких. где потребность невелика, то они успешно пользуются внешними сервисными центрами, а собственный для них невозможен, так как каждого типа оборудования у них мало, а специалисты по обслуживанию — узкие. С ИТ ситуация была иная, когда-то админ мог быть мастером на все руки и закрывать все потребности, а сейчас — нет, есть много узких специалистов, которым нужно квалифицированное управление и заказ. и поэтому для небольших компаний аутсорсинг — реальный выход, как и аусорсинг бухгалтерии или юристов. Но аутсорсинг ИТ — сложнее, потому что больше специфики. Обо всем этом был рассказ.
</p><p>Средний и малый бизнес. Почему не масштабируется? Потому что ты все делаешь сам, или сотрудниками, которые доступны. Ограничения по деньгам, и не только: крутым спецам эти масштабы могут быть не интересны.
</p><p>Кейс: владелец сыроварни, купил поставщика, надо организовать ИТ — они зовут спеца, чтобы поставить компы, сеть и в целом наладил. По сути он нанимает аутсорсеров как директора по ИТ исполнителю. Но, возможно, ты не слишком разбираешься в ИТ? Давай ты поставишь нам бизнес-задачу «автоматизировать поставщика» нам как ИТ-директору и мы ее сделаем?
</p><p>Проблема: нанимая в штат — ты готов мириться с тем, что люди болеют и уходят в отпуск. У аутсорсинга такого права нет. В большинстве аутсорсеров говорят «мирись» — аутстаффинг, и теряют преимущество, что специалист не в штате. Они работают иначе, выделяют коммуникатора, за которым команда — 26 позиций, специализированные, они за ним. При этом клиент не готов платить за такую команду. И в целом вопрос — как устроить такую услугу, чтобы экономика сходилась?
</p><p>ИТ-директор стоит 200-300тр, а менеджеры всего 50тр, и они работают не так много. Львиная доля работы топа малого и среднего бизнеса — рутина, которую некому передать. В большой компании для этого есть замы. И они могут рутину перебросить на менеджерский уровень, при этом менеджерам кайф, что работают в ИТ, и процесс сходится, потому что совмещение.
</p><p>На рынке история есть. Финдиректор увольняется из одной компании, и берет 3-5 мелких компаний в поддержку. Но у него не сходится экономика, потому что ему некому скинуть рутину.
</p><p>Бизнес существовал довольно давно, они реорганизовали так 150 ИТ-отделов компаний, назвали «эталонная модель ИТ». Так жили примерно до 2015 года, когда поняли, что эталонная модель — она не только про ИТ. Оно про взаимодействие с клиентом, когда ты для него поставщик услуги ИТ. И получается, что можно так же поставлять другой сервис, не только ИТ-функцию. И можно обеспечить другие функции: маркетинг, HR, логистики, финансы (бухгалтерия), безопасность. получается коммуникатор-директор: операционно у заказчика, а в штате — у подрядчика по услуге. А дальше: в большой компании у ИТ есть зам по бюджетированию, у а финансиста — зам по контролю бюджета, аналогично по HR и другим функциям. В маленьких компаниях зама нет, это — часть функций руководителя. Если компания аутсорсит несколько функций, то получается. что часть таких коммуникаций — тоже среди аутсорсеров, за пределами компании.
</p><p>Такой подход принципиально меняет аутсорсинг. В 2000 был аутсорсинг неважного дешево. А это — аутсорсинг не только исполнения, но и управления. Это стоит дороже, но неизмеримо лучше. Стоимость — ниже, результативность выше. Потому что люди заняты своим любимым делом — специализация. И мотивация у них правильная — его достижения понимают коллеги. А когда ты ИТшник в штате мед.учреждения — там не понимают, с чем ты боролся и что поборол.
</p><p>На западе есть бизнес-процесс-аутсорсинг. Мы можем сделать с нуля, но начисто. Почему эту модель не принесли с западными практиками консультанты? Потому что они сами занимались управлением, и эту часть отдавать не хотели. Поэтому принесли только аутсорсинг исполнения.
</p><p>И получается, что вокруг директора — совет директоров — совместителей, сообщество управленцев, которые работают в общей механике с понятным взаимодействием, срабатываемся заранее, там единый контур менеджмента, они умеют делать кросс-функциональные связи и проекты. Такой МФЦ для бизнеса.
</p><p>Когда они это поняли, они сначала попробовали сами все направления подмять, но дальше осознали: в пределе это значит, что я веду аутсорсинг всего вообще и лучше всех, а так не бывает. Поэтому идея поменялась на сообщество, ассоциацию.
</p><p>Есть сценарий, когда есть ИТ-директор в штате. Тогда конструкция не меняется — он докупает недостающие процессы и компетенции. Менеджеры и исполнители. Если есть персонал — то тоже не проблема. То есть граница между клиентом и подрядчиком в модели — подвижная. Они начинали с рутины: графики работ, отпуска, отчеты. И еще первая линия. Потому что в маленькой компании идет напрямую исполнителю, обычно дорогому, и он за свою зарплату отвечает «Это не ко мне, это к Леше», а Леша скажет: «Кто вам сказал, это не ко мне». Приоритизация проектов и отсечка невыгодных. Услуги технических работ. Были кейсы, когда ИТ-директор Заказчика переходил к ним (мы тратили на ИТ, теперь не тратим).
</p><p>Если компания варит сыр — ей не нужны сервера, ей надо чтобы почта и другой софт работал. Бухучет — чтобы налоговая не пришла, финансовый менеджмент — чтобы не было кассовых провалов. Понятные задачи, которые можно обеспечить комплексно, и там не так много работы.
</p><p>Исполнители могут быть разные: в штате, аутсорсеры, субподряд от заказчика, субподряд от исполнителя, уберизация. Координация работ — на них. Они не одни: нескучные финансы, Completo, маркетинг Домашенко, есть HR-компании.
</p><p>Они занимаются не только ИТ, но и смежными вопросами. Если приедет фура и там будут не те документы — это разрулят рутинным процессом.
</p><p>Что можно передать? 260+ обеспечивающих бизнес-функций. Включая продажи, и модно дублировать: одна внутри, другая снаружи.
</p><p>Каждый бизнес уникален, потому что уникален создатель. Но обеспечивающие — одинаковы. И их можно делать хорошо. В обеспечивающих различия суть несчастья. Что отдавать: принцип Микеланджело: отсечь лишнее, останется ядро.
</p><p>Разделение управления и исполнения. Не делаем плохого управленца, теряя хорошего слесаря или ИТшника. Мы все — часть чужого паззла, дополняет бизнес, который собирает кто-то. И это — служение, помогаем бизнесу стать великим.
</p><p>Универсальность обеспечивающих функций — хребет одинаковый, элементы различаются, и для клиента есть специфика. У клиента тоже была специфика, но у клиента каркас неполноценный, не хватало. Структура функции: вход, выход, нативные, смежные.
</p><p>HR: путь человека: HRB, найм, в компании и оценки, выход и след бывшего. Это все процессы-функции. И там есть процессы нативные (ИТ), и есть стыковка со смежниками.
</p><p>В презе схема, которую сделали 5 HR. У него было 13, на схеме было 42, и эта схема в свое время привлекла бывшего HRD Магнита Белоногова поработать, не взирая на разницу масштабов.
</p><p>Мы приходим в компанию, надо разобраться что нам. Для каждого смотрим: важность, объем, зрелость процесса, кто занимается сейчас. Результаты аудита дают план развития. Для сотрудника тоже можем нарисовать профили сотрудника в этих процессах, так мелко. И он будет заниматься, чем интересно.
</p><p>За управленцев конкурируют 350 тысяч компаний, в каждой 5-7 топов — это 2 млн человек, и на этот сегмент претендуют корпораты и госы. То есть явно на всех не хватит. 2/3 компаний работают в этом сегменте, и получается, что устроены плохо. Это — перспектива.
</p><p>Проблемы и преимущества — есть презентация. Деньги — эффективнее тратиться. А еще свобода принятия решений профи — заказчик не рассказывает реализацию.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.B5.D1.82.D0.BD.D0.B8.D1.86.D0.BA.D0.B0.D1.8F_.D0.9C.D0.B0.D1.80.D0.B8.D1.8F._.D0.92.D0.BB.D1.8E.D0.B1.D0.BB.D1.91.D0.BD.D0.BD.D1.8B.D0.B5_.D0.B2_.D0.BC.D0.B0.D1.82.D1.80.D0.B8.D1.86.D0.B5">Ветницкая Мария. Влюблённые в матрице</span></h1>
<p>Это рассказ — о текущих особенностях, ситуация сейчас изменилась, Мария делилась своим опытом. Были примеры запросов, их много разных. Руководителей сейчас бомбит, кто-то хочет контролировать до мелочей, и его не хватает. Или у руководителя есть идея, он понимает, что просто с помощью указания ее не сделать, а продать подчиненным не умеет.
</p><p>Изменения современного этапа.
</p>
<ul><li> Матрица функции — проекты стала кубиком. Продукты — Функции — Платформы или сквозные процессы. Минимум три измерения, бывает больше.</li>
<li> Люди выбирают свободу вместо иерархии и правил, руководители сталкиваются с сопротивлением, апатией, текучкой</li>
<li> Кросс-функциональные команды, хаос нарастает, контроль не работает.</li></ul>
<p>Agile. Придумано давно, и это классный ответ на неопределенность. Но берут фрагментарно, делают какие-то митинги, но не собирают целостно и оно не работает. Быть Agile и делать Agile — это разное. Ценности, Agile-манифест: зачем, принципы, поведение.
</p><p>Работала в компании, перед выходом в декрет — собрала топовых людей, разговор про жизнь. Хотят все одинакового хорошего. А что должно быть? Гипотеза-миссия — превосходить ожидания клиентов. И она заработала как аргумент в коридоре.
</p><p>Пришел лид «приоритизировать бэклог». Она сопротивлялась, но заказчик хотел сессию. Собрали. Карточки распечатали. Человек начинает зачитывать и его прошибает пот — «какая хрень».
</p><p>Стержень: Миссия — Видение — Стратегия — Цели — Проекты — Задачи. Если его нет, то фрагменты, типа приоритизации бэклога — не работают. Вертикальный стержень, структуризация по горизонтали, прозрачность на перспективу. Это комплексно, а часто пытаются взять фрагменты.
</p><p>При чем здесь влюбленность? Есть очень разные кейсы. Собственник: а можно структуру и KPI сделать без ценностей и миссии? Ну или пусть будет какая-нибудь миссия, «чтобы было как у всех». А про ценности миссию: вы сейчас время потратите, а все же быстро меняется, деньги будут выброшены. Роли и границы ответственности возникают в моменте, серые зоны, все нестабильно. Как можно делать стратегию, если ресурсы нестабильны?
</p><p>Это все грустные команды: потеря смысла, неясная программа руководителя, потеря мотивации. К картине надо подойти структурно, но при этом — не подавить. И вот здесь играет влюбленность в дело, которая у нее есть.
</p><p>Когда непонятно все, что можем делать — сокращаем период планирования. Agile-практики как раз для высокой неопределенности. Сейчас многие вынуждены делать годовое-пятилетнее, потому что так было принято, а по факту горизонт 1-3 месяца.
</p>
<ul><li> Планирование на короткий горизонт</li>
<li> Прогресс-собрание еженедельно</li>
<li> Празднование успехов — еженедельно, профилактика выгорания</li>
<li> Ретроспектива. Обязательно перед планированием, учет выводов.</li></ul>
<p>Но с коротким горизонтом проблемы: многие процессы разворачиваются дольше. Например, для ремонтов: уверенное планирование на месяц, а по запчастям приход заказа на 4 месяца. И с этим надо разбираться. Не давить сверху, а давать прорастать инициативе.
</p>
<h1><span class="mw-headline" id=".D0.9A.D0.BE.D1.80.D1.87.D0.B0.D0.B3.D0.B8.D0.BD.D0.B0_.D0.9E.D0.BB.D0.B5.D1.81.D1.8F._.D0.9A.D0.B0.D0.BA_.D1.81.D0.BE.D0.B7.D0.B4.D0.B0.D0.B2.D0.B0.D1.82.D1.8C_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.BD.D1.8B.D0.B5_.D0.BE.D1.82.D0.BD.D0.BE.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B4.D0.BB.D1.8F_.D0.B4.D0.BE.D0.BB.D0.B3.D0.BE.D1.81.D1.80.D0.BE.D1.87.D0.BD.D0.BE.D0.B3.D0.BE_.D0.BF.D0.B0.D1.80.D1.82.D0.BD.D0.B5.D1.80.D1.81.D1.82.D0.B2.D0.B0._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B9_.D1.83.D1.80.D0.BE.D0.B2.D0.B5.D0.BD.D1.8C_.D0.BE.D1.82.D0.BD.D0.BE.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D1.81_.D0.BB.D1.8E.D0.B4.D1.8C.D0.BC.D0.B8">Корчагина Олеся. Как создавать ресурсные отношения для долгосрочного партнерства. Новый уровень отношения с людьми</span></h1>
<p>Рассказ о построении рабочих взаимоотношений с эмоциональной, а не только рациональной составляющей, это и есть новый уровень отношения с людьми. Эмоции может дать только человек человеку.
</p><p>Долгосрочные отношения с людьми: удовольствие, окситоцин, безопасность, возможности вместе сделать. Человеку нужен человек. Бизнес делают люди для людей. Окружение — часть успеха, возможности, информация и ресурсы приходят от людей. Успех и изобильность — это количество и качество людей, с которыми моно построить успешную коммуникацию. Деньги — следствие.
</p><p>Я отмечу, что тут есть заблуждение, деньги не являются прямым следствием. Более того, в короткую это вообще неверно, есть исследования Белбина об отсутствии прямой корреляции между командным духом и результатами команды, и примеры команд, которые достигали победы, разругавшись вдрызг, и команд, которые дружно и весело шли к поражению. Но надо понимать, что у Белбина был ограниченный срок командной работы, и что командная работа была совмещением с основной образовательной программой. А вдолгую — да, эмоциональные факторы, взаимоотношения в коллективе важны, но не менее важна и нацеленность на результат и техническое обеспечение движения, которое часто заставляет делать не комфортные вещи. В общем, многофакторная история.
</p><p>Барьеры для командного взаимодействия:
</p>
<ul><li> объективные: технические, временные, языковые</li>
<li> субъективные: разный контекст, интерпретация и картина мира, этика, стереотипы, эмоции, стресс</li></ul>
<p>Ассертивность. Умение отстоять свои права, не наступая на права другого. Мы часто считаем, что потребности окружающих важнее наших, другие могут влиять. И другая сторона: когда мы считаем наши права важнее прав других людей, хотим чтобы другие подстроились, были похожи.
</p><p>Пассивное поведение, активное и ассертивное. Ассертивность: активно слушать, спрашивать собеседника и так далее.
</p><p>Техника айкидо. Выслушать — присоединиться — исследовать — ответить.
</p>
<ul><li> Выслушать: записи и пометки, ключевые слова и фразы, зрительный контакт, невербалика.</li>
<li> Присоединиться: распознать ценности, поддержать собеседника, разделяйте его ценности и состояние. Есть запрос сотрудника: хочу, дайте — это может быть детской позицией, но с этим надо работать.</li>
<li> Исследовать: сохраняйте партнерскую позицию, задавайте вопросы, используйте активное слушание</li>
<li> Ответить: вести конгруэнтно — слова совпадают с действиями и мыслями; давайте ответы; предлагайте альтернативы</li></ul>
<p>Коммуникация. Начало, Основная часть, Завершение. Зрительный контакт, приветствие, цели. Аргументы свои, собеседника, контраргументы. Зафиксируйте договоренности.
</p><p>Главное не то, что вы сказали, а то, что люди запомнили.
</p>
<h1><span class="mw-headline" id=".D0.A2.D0.B8.D1.82.D0.BE.D0.B2.D0.B0_.D0.95.D0.BB.D0.B5.D0.BD.D0.B0._.D0.97.D1.80.D0.B5.D0.BB.D0.B0.D1.8F_.D0.BB.D0.B8.D1.87.D0.BD.D0.BE.D1.81.D1.82.D1.8C._.D0.A2.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.BD.D0.B0.D1.8F_.D0.B3.D1.80.D1.83.D0.BF.D0.BF.D0.B0._.D0.A7.D0.B5.D1.80.D0.B5.D0.B7_.D0.B2.D0.BD.D1.83.D1.82.D1.80.D0.B5.D0.BD.D0.BD.D0.B8.D0.B5_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BA_.D0.B2.D0.BD.D0.B5.D1.88.D0.BD.D0.B8.D0.BC">Титова Елена. Зрелая личность. Трансформационная группа. Через внутренние изменения к внешним</span></h1>
<p>Рассказ о том, что такое — зрелая личность. С опорой на работы Нэнси МакВильямс.
</p>
<ul><li> Способность любить партнера, как он есть</li>
<li> Способность работать — любить свое дело, найти свое дело, получать удовольствие</li>
<li> Способность играть — символизировать, использовать метафоры, получать удовольствие. Сейчас люди не играют, а наблюдают</li>
<li> Безопасные отношения. Классификация: нормальный, тревожный (прилипает), избегающий (легко отпустить с тревогой внутри), дезорганизованный (прилип и кусает).</li>
<li> Способность к автономии, опора на себя</li>
<li> Способность оставаться в контакте с собой, принять все стороны своего Я, не обесценивать свою конструкцию. Но это и ограничение роста, потому что для роста нужен вызов «я не такой, а стану таким», так что тут надо сложнее формулировать.</li>
<li> Восстановление после стресса. Выход из быстрых реакций бей-беги-замри</li>
<li> Реалистичная самооценка. Одни часто себя ругают и карают, другие — переоценивают как балованные дети.</li>
<li> Система ценностных ориентиров. Понимать нормы, их смысл, быть гибким в использовании. Отмечу, что гибкость — она разная.</li>
<li> Способность выдержать накал эмоций</li>
<li> Способность смотреть на себя со стороны, рефлексия</li>
<li> Ментализация — воображаемый процесс понимания другого человека, его опыта. Почему он обиделся, его ход мышление</li>
<li> Владение защитными механизмами, не пользоваться только одним. Не только рационализировать</li>
<li> Баланс между тем, что делаем для себя и что для других. Тут я бы говорил не о балансе, а о синергии, не или-или, а и то и другое и больше, так строить жизнь, диалог с миром, чтобы обе стороны получали выгоду.</li>
<li> Способность чувствовать себя живым, не только функционирующим — играть, любить</li>
<li> Способность принимать то, что не способны изменить, принимать утраты и их последствия, продолжать жизнь несмотря на</li></ul>
<h1><span class="mw-headline" id=".D0.9F.D0.B5.D1.81.D0.BE.D1.86.D0.BA.D0.B0.D1.8F_.D0.98.D1.80.D0.B8.D0.BD.D0.B0_.D0.B8_.D0.9A.D1.83.D1.85.D0.B0.D1.80.D1.81.D0.BA.D0.B0.D1.8F_.D0.9F.D0.BE.D0.BB.D0.B8.D0.BD.D0.B0._.D0.91.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D0.BF.D0.B5.D1.80.D0.B5.D0.B2.D0.BE.D0.B4.D1.87.D0.B8.D0.BA.D0.B8:_.D0.B0.D0.BA.D1.82.D1.83.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D0.BE.D0.BF.D1.8B.D1.82_.D1.82.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D0.B8_.D0.BA.D0.BE.D0.BC.D0.BF.D0.B0.D0.BD.D0.B8.D0.B9_.D0.B8_.D0.B1.D1.80.D0.B5.D0.BD.D0.B4.D0.BE.D0.B2">Песоцкая Ирина и Кухарская Полина. Бизнес-переводчики: актуальный опыт трансформации компаний и брендов</span></h1>
<p>Это два доклада о трансформации русских подразделений международных компаний, которые ушли с рынка в СВО от топовых руководителей российских подразделений, которые организовывали их трансформацию. Ирина Песоцкая рассказывая про опыт Nikoliers — брокерская компания, консультанты в сфере недвижимости, были частью Collers, крупнейшая в России, вторая в Мире. Они сделали новый бренд, да еще стали международными, появился офис в Дубаях. А Кухарская Полина — про Макдональдс, который стал «Вкусно и точка», и тоже сохранился и развивается. При этом там была пауза, когда про судьбу компании вообще было неясно, но получилось договориться с головным офисом. Новый бренд «вкусно и точка» — результат компромисса с головной компанией, там очень жестко хотели, чтобы «никаких намеков».
</p><p>Истории — разные, но похожие. В обоих случаях были юридические аспекты, вопрос нового бренда, проблемы сохранения команды, проблемы ИТ, потому что его обеспечивала головная компания своими международными решениямИ, и надо было не только уйти с этого софта, но и построить свое ИТ-подразделения, потому что раньше вся поддержка была за головным офисом. Задачи — успешно решили.
</p><p>В Nikoliers важно было в начале трансформации выйти в диалог с клиентами, придумали новые услуги. И сохранить персонал и систему мотивации. пообещали, что обойдутся без сокращения и уменьшения зарплаты.
</p><p>Ценности:
</p>
<ul><li> Свобода — дух предприимчивости во всем, неважно кто ты по должности</li>
<li> Ответственность — каждое действие подразумевает ответственность за результат</li>
<li> Справедливость — справедливая оценка результатов работы</li></ul>
<p>Когда есть любовь и мотивация — никакой дисциплины навязывать не надо.
</p><p>У «Вкусно и точка» был интересный опыт по команде: пока компания была в подвешенном состоянии, четверть (или треть) сотрудников ушли, потому как у всех разные ситуации, а открыться на прежних площадях надо было в краткие сроки — и они обратились к сотрудникам, которые работали раньше, многие откликнулись.
</p><p>Так что в целом в обоих компаниях трансформация прошла успешно. А после преодоления переходного периода в обоих компаниях открылись новые перспективы, которые раньше закрывал головной офис, контролируя позиционирование. Так что компании еще и развиваются.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.B0.D1.80.D0.BA_.D0.A0.D0.BE.D0.B7.D0.B8.D0.BD._.D0.9D.D0.BE.D0.B2.D1.8B.D0.B5_.D0.B2.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.B0_-_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B5_.D0.BF.D0.B5.D1.81.D0.BD.D0.B8">Марк Розин. Новые времена - новые песни</span></h1>
<p>Марк Розин в своем докладе размышляет о новом мировоззрении, которое сейчас уже отчетливо проявилось. Он говорит, что за последние 6-7 лет, общаясь со своими детьми, отчетливо фиксирует, что мировоззренческая разница увеличивается, при том, что психологически происходит сближение. А его знакомые на Западе зафиксировали, что в Ковид мировоззрение молодежи сменилось радикально. Отдельные тренды нам всем известны, о них Марк говорит в начале доклада: Гендеры, Деколонизация, Феминизм, Раса, BLM, Me too, Богатые должны делиться, Боди-позитив (принимать всех), Нет угнетению, нет спорту высоких достижений, опасность всемирного потепления, ЛБГТ, Социальная справедливость. Но за новыми трендами лежит именно новое комплексное мировоззрение, описывающее мир целиком, которое дает навигацию во всех аспектах жизни. И Марк в докладе размышляет именно о комплексной картине, сопоставляя ее с комплексной ценностной картиной уходящего 20 века. Тема - важная, я сначала дам конспект выступления, а в конце - свое осмысление.
</p><p>Для начала он отмечает, что это мировоззрение не укладывается в привычную картину. Если смотреть из привычного спектра взглядов правые - левые, то есть впечатление, что левая часть сильно расширилась, так что "старые левые" оказались в середине. Тут Марк ссылается на Илона Маска. Денис Давыдов, изобретатель игры в мафию и сторонник новой повестки, с которым Марк знаком еще по университету и который преподает в Штатах, дает самоназвание "пробудившиеся".
</p><p>Что в новом мировоззрении лежит на поверхности - это повышенное внимание к собственным чувствам. Чувства оказываются важнее процесса обучения, студенты начали ссылаться на них как на уважительную причину для каких-то своих действий, вернее, бездействий в учебном процессе. Они не делают задания, потому что они слишком трудны, будущие юристы отказываются от изучения законов об изнасиловании и другом насилии, потому что погружение в эти подробности слишком ужасно и так далее. И общее ощущение, что у всех есть травмы, их надо прорабатывать, без этого никто не сможет вести себя адекватно - доходит до того, что 80% девушек в тиндере отказываются от первого свидания, если мужчина не проходит терапию.
</p><p>Есть тренд, что новая повестка (или ее часть) активно продвигается для детей, тут Марк ссылается на Анну Старобинец, ее опыт работы с продюсерами по сериалу Зверский детектив. Требуют такие посылы: должен быть небинарный персонаж, волк должен дружить с совой, нельзя есть насекомых. Там была религия, в которой есть небесный медведь м медвежонок, и гром - это мама сердится, а дождь - это медвежонок плачет, так вот такое - нельзя, это абьюз. И что курица - глупое животное, тоже нельзя, а то так и людей начнут делить на глупых и умных.
</p><p>Марк попробовал найти книгу, которая бы отражала новое мировоззрение, и нашел - Бакмана "Тревожные люди":
</p>
<ul><li> Все симпатичные, трогательно, злые поступки совершают травмированные люди, и потому они не виноваты, это их травма.</li>
<li> Любовь и отношения важнее любых достижений</li>
<li> Все кроме внутреннего мира - не всерьез, в мире нет реального зла. грабеж и захват заложников - игра. Хотя банки и деньги - злом остаются.</li>
<li> Реально печально - смерть, это финальная непереносимая трагедия, бесконечная грусть.</li>
<li> Радостно - это контакт между людьми. Любовь - не страстная, а понимающая и жалостная.</li></ul>
<p>А дальше Марк сравнивает новое мировоззрение с тем, которое было у него, которое он получил от родителей-шестидесятников и которое не получилось передать детям. Как манифест этого мировоззрения он берет гимн шестидесятников Окуджавы:
</p>
<dl><dd> Неистов и упрям,</dd>
<dd> Гори, огонь, гори,</dd>
<dd> На смену декабрям</dd>
<dd> Приходят январи.</dd>
<dd> Нам все дано сполна:</dd>
<dd> И радости и смех,</dd>
<dd> Одна на всех луна,</dd>
<dd> Весна одна на всех.</dd>
<dd> Прожить этап до тла,</dd>
<dd> А там пускай ведут</dd>
<dd> За все твои дела</dd>
<dd> На самый страшный суд.</dd>
<dd> Пусть оправданья нет,</dd>
<dd> Но даже век спустя</dd>
<dd> Семь бед — один ответ,</dd>
<dd> Один ответ — пустяк!</dd></dl>
<p>И по строкам пишет новый контрапункт
</p>
<ul><li> Неистов и упрямый -- Осознанный и сбалансированный</li>
<li> Гори, огонь, гори -- нет, надо журчать как вода, она - вечна, а огонь - прогорает</li>
<li> На смену декабрям приходят январи -- не спеши в январь, живи медленно и размеренно </li>
<li> Нам все дано сполна -- нет, ресурс ограничен, его не хватает людям на планете, не хватит будущим</li>
<li> И радости и смех -- Радуйся умеренно</li>
<li> Луна у всех одна, весна одна на всех -- Луна только одна, а мы можем замусорить и придет ли весна для наших детей</li>
<li> Веди здоровый образ жизни</li>
<li> А там пускай ведут за все твои дела на самый страшный суд -- Держи свою жизнь под контролем, поступай этично, будешь отвечать перед потомками</li>
<li> Пусть оправданья нет, но даже век спустя семь бед — один ответ, один ответ — пустяк! -- Нет, будь в ладу с самим собой сейчас, чтобы век спустя не случилось беды, к этому надо относиться серьезно</li></ul>
<p>Марк выписывает старые и новые ценности.
</p>
<ul><li> Страсть - Осознанность</li>
<li> Смелость - Забота о себе </li>
<li> Яркие поступки - Этичные поступки</li>
<li> Полнота быстрой жизни - Долгая жизнь</li>
<li> Достижения - Внутренняя гармония</li>
<li> Воля - Поток</li>
<li> Свобода - Обязательства</li>
<li> Индивидуализм - Согласованность</li></ul>
<p>А далее Марк отражает это на менеджмент, выписывает и противопоставляет соответствующие принципы управления принципы управления.
</p>
<ul><li> Страсть - Осознанность: вместо погони за сверхцелью - выполнять социальную миссию, улучшая мир</li>
<li> Смелость - Забота о себе: вместо инициативного предпринимательства на собственной энергии - безрисковое "предпринимательство" в комфортных условиях созданных зон безопасности </li>
<li> Яркие поступки - Этичные поступки: Вместо стремления быть первым и яркого PR с погоней за достижениями - ESG-повестка (Environment, Social, Governance) улучшения жизни сотрудников и социума </li>
<li> Полнота быстрой жизни - Долгая жизнь: вместо горящих глаз и трудоголизма - баланс работы и личной жизни, поощрение реализации в хобби </li>
<li> Достижения - Внутренняя гармония: вместо мотивации личных достижений - медитации и работа с психологом на работе, движение к осознанности важнее достижения результатов</li>
<li> Воля - Поток: вместо иерархии, транслирующей и навязывающей волю - плоские гибкие структуры и метод проб и ошибок </li>
<li> Свобода - Обязательства: вместо свободы в личных отношениях, в том числе служебных романов - запрет личных отношений на работе </li>
<li> Индивидуализм - Согласованность: вместо индивидуального управления по целям, идущего сверху - согласованность действий с коллегами </li></ul>
<p>В заключении Марк начал было рассказывать о том, как это соотносится со Спиральной динамикой, которая для него - рабочая схема. Но время закончилось и он перешел к вопросам.
</p><p>Теперь что я думаю о той картине, которую нарисовал Марк? В целом картина достаточно точная, и в этом ее ценность. Но, если говорить о сопоставлении, то оно представляется не совсем корректным: сопоставляется идеал 60-х в России с современным идеалом, который приходит с Запада. Впрочем, чтобы зафиксировать разрыв поколений, этого может быть достаточно. Хотя тут нужна более репрезентативная картина идеалов, мне кажется, что студенческий гимн шестидесятников разделяется далеко не всеми.
</p><p>Еще один важный аспект, который остался за рамками сфокусированного рассмотрения - это вопрос о целях и смысле деятельности - ради чего жить и действовать? Его нет ни в гимне шестидесятников, ни в понимании современного мировоззрения, как о нем говорит Марк. Но, мне представляется, что гимн шестидесятников подразумевал большие, сильные цели, Марк и сам это говорит: Страсть подразумевает сверхцель. Но формально это - не обязательно, и вполне может быть страсть без такой цели. А новая повестка в трендах большие цели содержит: предотвратить глобальное потепление, обеспечить социальную справедливость и более равномерное распределение богатства, но получается, что они остаются некоторым фоном для сбалансированного течения жизни, поводом поныть - их нельзя поставить как цель. А это - важный вопрос, если больших целей нет, то страсть и напряжение жизни действительно теряет смысл, ну или превращается в потворствование собственным сиюминутным капризам, что точно не полезно.
</p><p>А если говорить в терминах спиральной динамики, то зафиксированная картина соответствует общественному сознанию зеленого уровня, как он сформировался на Западе в третью волну зеленого, в 1960-х: темы экологии, внимания к чувствам, лозунг "любовь, а не война" - возникли именно тогда, но тогда их придерживались отдельные люди, и их надо было придерживаться умеренно, а теперь они стали явлением массовым. Спиральная динамика зафиксировала происходящее в общественном сознании, именно оно - источник уровней. А логику изменения общественного сознания можно посмотреть, например, у Валлерстайна в "После либерализма". В своей статье <a href="https://mtsepkov.org/%D0%A4%D0%BE%D1%80%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5%D0%B9_%D1%81%D0%BF%D0%B8%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D0%BA%D0%B8_%D0%B2_%D0%BE%D0%B1%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%BC_%D1%81%D0%BE%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B8" title="Формирование уровней спиральной динамики в общественном сознании" class="mw-redirect">Формирование уровней спиральной динамики в общественном сознании</a> я провожу сопоставление логики развития, как она описана у Валлерстайна, со Спиральной динамикой.
</p><p>Отмечу, что это - не тот действующий зеленый уровень, о котором говорит Марк Розин в книге "Восхождение по спирали", а тот, для которого совместное действие и взаимное внимание - главное, а результат деятельности - не слишком важен. Поэтому Марк для компаний он не конструктивен, и Марк его пропустил, объявив зеленым вариант желтого, а у Фредерика Лалу этот уровень показан хорошо. Я анализировал это в <a href="https://mtsepkov.org/%D0%9C%D0%B0%D1%80%D0%BA_%D0%A0%D0%BE%D0%B7%D0%B8%D0%BD._%D0%92%D0%BE%D1%81%D1%85%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%BE_%D1%81%D0%BF%D0%B8%D1%80%D0%B0%D0%BB%D0%B8" title="Марк Розин. Восхождение по спирали" class="mw-redirect">рецензии на книгу Марка</a>.
</p><p>Внимание к собственным чувствам в массовом масштабе, естественно, привело к перегибам, породило такое явление, как <a rel="nofollow" class="external text" href="https://en.wikipedia.org/wiki/Snowflake_(slang)">люди-снежинки (snowflake generation)</a>. Почувствовав силу, они травят профессоров, которые недостаточно проявляют внимания к их тонким чувствам, Естественно, игнорируя при этом чувства самих профессоров. Во многом это сохранение инфантилизма, детского взгляда на мир у взрослых людей. Об этом явлении можно почитать любопытную <a rel="nofollow" class="external text" href="https://www.maximonline.ru/longreads/get-smart/_article/new-generation/">статью Таты Олейник</a> и другую <a rel="nofollow" class="external text" href="https://www.maximonline.ru/longreads/_article/stradatelnyi-zalog-uspekha-pochemu-stalo-modno-byt-neschastnym-i-obizhennym/">ее статью</a>, про книгу описывающую эту культуру как закономерный этап развития социума. Но это - крайние пределы, образ. который рисует Марк - более оптимистичен.
</p><p>Важно, что это - результат воспитания и распространения такого отношения, сначала такая нетерпимость была вовсе не со стороны студентов, навязывание такой толерантности и других отношений шло в более старших слоях. Кен Уилбер столкнулся с этом в жизни и разбирает явление в книге Бумерит и других.
</p><p>И вот здесь мы как раз подходим к рассмотрению причин изменения мировоззрения. При этом оно перестает быть целостным, отмечу, что в анализе ценностей Марка отражены ценности не всех, из перечисленных им же в начале выступления известных трендов. С моей точки зрения, тут произошло следующее: протестный и инициативный характер движения опасен для общественно-политической жизни, поэтому его решили, с одной стороны, поднять на флаг обязательности, а с другой - приглушить, убрав большие цели у человека и воспитав, по сути, взрослый инфантилизм. Застойные последствия такого подхода были показаны Зиновьевым в Глобальном человейнике.
</p><p>Но это - искусственный, управляемый путь. А через него прорастает естественный, созидательный и сфокусированный на инициативе желтый уровень. У Валлерстайна в книге этого нет, потому что на момент описания проявлений еще не было, а в более позднем сборнике «Does Capitalism Have a Future» (2013) он фиксирует это в общественно-политической жизни.
</p><p>Что касается развития компаний, то там конструктивные варианты желтого зафиксированы Фредериком Лалу, который собрал из них идеальный образ компаний будущего. И внимание к индивидуальности отдельного человека, его чувствам в этом образе присутствует, Лалу посвящает ему достаточно много материалов в своей книге.
</p><p>Но это - мое восприятие. Я не исключаю, что моя призма Спиральной динамике искажает картину. Поэтому и постарался в первой части дать конспект Марка без комментариев и оценок, а вынес их отдельно.
</p><p><br />
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-10-29:_AnalystDays_-_%D1%81%D1%82%D0%B0%D0%B1%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D0%B5_%D0%B4%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%D1%8B_%D0%B8_%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B52023-10-29: AnalystDays - стабильно хорошие доклады и качественное общениеMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-10-29T06:23:51Z2023-11-15T10:02:22Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Два дня был и выступал на конференции AnalystDays. Было много общения и хорошее содержание докладов. В этот раз на конференции было почти 900 очных участников и еще более 300 online. Как обычно, я публиковал заметки в ходе конференции, и сразу собираю их в отчет, дополнив еще несколькими докладами, заметки с которых отдельно опубликовать не успел.
</p><p>Заметки — в том порядке, в котором я слушал доклады, а здесь я хочу те, которые представляются мне наиболее интересными.
</p>
<ol><li> Нескромно начну со <b><a href="#.D0.9C.D0.BE.D0.B9_.D0.B4.D0.BE.D0.BA.D0.BB.D0.B0.D0.B4_.D0.A0.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.B8_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC.D0.BD.D0.BE.D0.B5_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B0.D1.81.D1.82.D0.B5.D1.80-.D0.BA.D0.BB.D0.B0.D1.81.D1.81_.D0.98.D1.80.D1.8B_.D0.A1.D1.83.D1.80.D0.BE.D0.B2.D0.BE.D0.B9_.D0.BA_.D0.BD.D0.B5.D0.BC.D1.83">своего доклада Рациональное и системное мышление</a></b> и мастер-класса Иры Суровой к нему - в обсуждении на конференции многие отмечали, что это было актуально и полезно, несмотря на то. что часть материала я не успел рассказать подробно.</li>
<li> <a href="#.D0.90.D0.BD.D0.B0.D1.82.D0.BE.D0.BB.D0.B8.D0.B9_.D0.9B.D0.B5.D0.B2.D0.B5.D0.BD.D1.87.D1.83.D0.BA._.D0.98.D0.BD.D1.82.D0.B5.D0.BB.D0.BB.D0.B5.D0.BA.D1.82-.D1.81.D1.82.D0.B5.D0.BA_.D0.B4.D0.BB.D1.8F_.D0.B8.D0.BD.D0.B6.D0.B5.D0.BD.D0.B5.D1.80.D0.BE.D0.B2_.D0.B8_.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.B5.D1.80.D0.BE.D0.B2">#Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров</a> — комплексное представление о наборе дисциплин/умений/практик мышления, которые требуются для эффективной деятельности, позволяют строить модели и обеспечивать изменения в реальном мире на их основе.</li>
<li> <a href="#.D0.A1.D0.B2.D0.B5.D1.82.D0.BB.D0.B0.D0.BD.D0.B0_.D0.94.D0.B5.D1.80.D0.B3.D0.B0.D1.87.D0.B5.D0.B2.D0.B0._.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5_.D0.A2.D0.A0.D0.98.D0.97_.D0.B4.D0.BB.D1.8F_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B7.D0.B0.D0.B4.D0.B0.D1.87_.D1.81_.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D1.8C.D0.BD.D1.8B.D0.BC_.D1.83.D1.80.D0.BE.D0.B2.D0.BD.D0.B5.D0.BC_.D0.BD.D0.B5.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8">#Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности</a> — лучший доклад про применение ТРИЗ в ИТ из тех, что я слышал на разных конференциях.</li>
<li> <a href="#.D0.92.D0.B0.D0.BB.D0.B5.D1.80.D0.B8.D0.B9_.D0.A0.D0.B0.D0.B7.D0.BD.D0.BE.D0.BC.D0.B0.D0.B7.D0.BE.D0.B2._.D0.9E.D0.B1.D1.8A.D0.B5.D0.BA.D1.82.D0.BD.D0.BE-.D0.BE.D1.80.D0.B8.D0.B5.D0.BD.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.BD.D1.8B.D0.B9_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4_.D0.B2_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B5.D0.BD.D0.B8.D0.B8_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D1.8B_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D0.B9">#Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений</a> — глубокий доклад о применении DDD, противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы. Опора на объекты лучше, так как они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного «важные, ключевые решения»: система — большее, чем совокупность отдельных фич, и архитектукра — это то, за счет чего система работает как целое.</li>
<li> <a href="#.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9F.D0.BE.D0.B4.D0.BE.D0.BB.D0.B8.D0.BD.D0.B0._.D0.A0.D0.B0.D1.81.D1.88.D0.B8.D1.80.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D1.82.D0.B0.D1.86.D0.B8.D0.B8_BPMN:_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D1.81.D0.BE.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.BD.D0.BE_.D1.81_DMN_.28.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8.29_.D0.B8_CMMN_.28.D0.BA.D0.B5.D0.B9.D1.81-.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.BC.D0.B5.D0.BD.D1.82.29">#Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент)</a> — нотации, позволяющие наглядно представлять бизнес-функции, которые не являются процессами, а организованы иначе.</li></ol>
<p>Еще хочу отдельно отметить два доклада, на которых я не был.
</p>
<ol><li> <b>Мария Яковлева. Как написать свою первую спецификацию на REST API</b>. Он занял первое место на конференции.</li>
<li> <b>Максим Шаломович и Евгений Асламов. Долой SQL! Или краткий обзор мира нереляционных данных</b>.</li></ol>
<p>На этом перехожу к конкретным докладам.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>Два дня был и выступал на конференции AnalystDays. Было много общения и хорошее содержание докладов. В этот раз на конференции было почти 900 очных участников и еще более 300 online. Как обычно, я публиковал заметки в ходе конференции, и сразу собираю их в отчет, дополнив еще несколькими докладами, заметки с которых отдельно опубликовать не успел.
</p><p>Заметки — в том порядке, в котором я слушал доклады, а здесь я хочу те, которые представляются мне наиболее интересными.
</p>
<ol><li> Нескромно начну со <b><a href="#.D0.9C.D0.BE.D0.B9_.D0.B4.D0.BE.D0.BA.D0.BB.D0.B0.D0.B4_.D0.A0.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.B8_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC.D0.BD.D0.BE.D0.B5_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B0.D1.81.D1.82.D0.B5.D1.80-.D0.BA.D0.BB.D0.B0.D1.81.D1.81_.D0.98.D1.80.D1.8B_.D0.A1.D1.83.D1.80.D0.BE.D0.B2.D0.BE.D0.B9_.D0.BA_.D0.BD.D0.B5.D0.BC.D1.83">своего доклада Рациональное и системное мышление</a></b> и мастер-класса Иры Суровой к нему - в обсуждении на конференции многие отмечали, что это было актуально и полезно, несмотря на то. что часть материала я не успел рассказать подробно.</li>
<li> <a href="#.D0.90.D0.BD.D0.B0.D1.82.D0.BE.D0.BB.D0.B8.D0.B9_.D0.9B.D0.B5.D0.B2.D0.B5.D0.BD.D1.87.D1.83.D0.BA._.D0.98.D0.BD.D1.82.D0.B5.D0.BB.D0.BB.D0.B5.D0.BA.D1.82-.D1.81.D1.82.D0.B5.D0.BA_.D0.B4.D0.BB.D1.8F_.D0.B8.D0.BD.D0.B6.D0.B5.D0.BD.D0.B5.D1.80.D0.BE.D0.B2_.D0.B8_.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.B5.D1.80.D0.BE.D0.B2">#Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров</a> — комплексное представление о наборе дисциплин/умений/практик мышления, которые требуются для эффективной деятельности, позволяют строить модели и обеспечивать изменения в реальном мире на их основе.</li>
<li> <a href="#.D0.A1.D0.B2.D0.B5.D1.82.D0.BB.D0.B0.D0.BD.D0.B0_.D0.94.D0.B5.D1.80.D0.B3.D0.B0.D1.87.D0.B5.D0.B2.D0.B0._.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5_.D0.A2.D0.A0.D0.98.D0.97_.D0.B4.D0.BB.D1.8F_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B7.D0.B0.D0.B4.D0.B0.D1.87_.D1.81_.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D1.8C.D0.BD.D1.8B.D0.BC_.D1.83.D1.80.D0.BE.D0.B2.D0.BD.D0.B5.D0.BC_.D0.BD.D0.B5.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8">#Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности</a> — лучший доклад про применение ТРИЗ в ИТ из тех, что я слышал на разных конференциях.</li>
<li> <a href="#.D0.92.D0.B0.D0.BB.D0.B5.D1.80.D0.B8.D0.B9_.D0.A0.D0.B0.D0.B7.D0.BD.D0.BE.D0.BC.D0.B0.D0.B7.D0.BE.D0.B2._.D0.9E.D0.B1.D1.8A.D0.B5.D0.BA.D1.82.D0.BD.D0.BE-.D0.BE.D1.80.D0.B8.D0.B5.D0.BD.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.BD.D1.8B.D0.B9_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4_.D0.B2_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B5.D0.BD.D0.B8.D0.B8_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D1.8B_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D0.B9">#Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений</a> — глубокий доклад о применении DDD, противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы. Опора на объекты лучше, так как они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного «важные, ключевые решения»: система — большее, чем совокупность отдельных фич, и архитектукра — это то, за счет чего система работает как целое.</li>
<li> <a href="#.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9F.D0.BE.D0.B4.D0.BE.D0.BB.D0.B8.D0.BD.D0.B0._.D0.A0.D0.B0.D1.81.D1.88.D0.B8.D1.80.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D1.82.D0.B0.D1.86.D0.B8.D0.B8_BPMN:_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D1.81.D0.BE.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.BD.D0.BE_.D1.81_DMN_.28.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8.29_.D0.B8_CMMN_.28.D0.BA.D0.B5.D0.B9.D1.81-.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.BC.D0.B5.D0.BD.D1.82.29">#Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент)</a> — нотации, позволяющие наглядно представлять бизнес-функции, которые не являются процессами, а организованы иначе.</li></ol>
<p>Еще хочу отдельно отметить два доклада, на которых я не был.
</p>
<ol><li> <b>Мария Яковлева. Как написать свою первую спецификацию на REST API</b>. Он занял первое место на конференции.</li>
<li> <b>Максим Шаломович и Евгений Асламов. Долой SQL! Или краткий обзор мира нереляционных данных</b>.</li></ol>
<p>На этом перехожу к конкретным докладам.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.BE.D0.B9_.D0.B4.D0.BE.D0.BA.D0.BB.D0.B0.D0.B4_.D0.A0.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.B8_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC.D0.BD.D0.BE.D0.B5_.D0.BC.D1.8B.D1.88.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B0.D1.81.D1.82.D0.B5.D1.80-.D0.BA.D0.BB.D0.B0.D1.81.D1.81_.D0.98.D1.80.D1.8B_.D0.A1.D1.83.D1.80.D0.BE.D0.B2.D0.BE.D0.B9_.D0.BA_.D0.BD.D0.B5.D0.BC.D1.83">Мой доклад Рациональное и системное мышление и мастер-класс Иры Суровой к нему</span></h1>
<p>Я выступал с докладом <a href="https://mtsepkov.org/%D0%A0%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%B8_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5:_%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B8_%D0%B8_%D0%BA%D0%BE%D0%BC%D0%BF%D0%B5%D1%82%D0%B5%D0%BD%D1%86%D0%B8%D0%B8_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_(AnalystDays-2023)" title="Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)"><b>Рациональное и системное мышление: практики и компетенции аналитика</b></a>. По отзывам многих участников — удачно, даже несмотря на то, что у меня сильно не хватило времени, чтобы рассказать про системное мышление. И это было прогнозируемо по результатам прогона, но было не понятно, что сокращать, а выяснилось это когда просить дополнительный слот было поздно. Зато теперь у меня есть относительно подробный доклад о рациональном мышлении: разметки текстов, структурировании мира и деятельности. А в презентации есть примеры, которые позволяют приземлить материал доклада на материал. Подробно разобрать их не получилось. но вы можете попробовать подумать над ними самостоятельно, а при необходимости — меня спросить.
</p><p>А я на следующей AnalystDays продолжу тему, начав именно с системного мышления и доработав часть про него, дав взгляд на популярные ИТ-модели, такие как c4 model через призму системного мышления. А про рациональное буду рассказывать лишь в необходимом для понимания доклада объеме, делая ссылки на этот доклад.
</p><p>А <b>Ира Сурова сделала к моему докладу мастер-класс</b>, где участники могли попробовать разметить тексты, почувствовать разницу между существительными и объектами и отношениями, которые могут быть более сложными, попробовать совместить свою модель с другой, готовой. И даже увидеть немного процессы, которые были оставлены за рамками мастер-класса, но неявно присутствовали: модельным материалом была система контроля версий, а она ведь поддерживает именно процесс изменений каких-либо артефактов. Надеюсь, мастер-класс Иры тоже будет иметь продолжение.
</p>
<h1><span class="mw-headline" id="Polina_Latypova_.D0.B8.D0.B7_Evocargo._.D0.9A.D0.B0.D0.BA_.D0.BC.D1.8B_.D1.81.D1.82.D0.BE.D0.BB.D0.BA.D0.BD.D1.83.D0.BB.D0.B8.D1.81.D1.8C_.D1.81_.D1.82.D1.89.D0.B5.D1.81.D0.BB.D0.B0.D0.B2.D0.BD.D0.BE.D0.B9_.D0.BC.D0.B5.D1.82.D1.80.D0.B8.D0.BA.D0.BE.D0.B9_.D0.B8_.D0.BF.D0.BE.D0.B1.D0.B5.D0.B4.D0.B8.D0.BB.D0.B8_.D0.B5.D1.91._.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F_.D0.B8.D0.B7_.D0.BC.D0.B8.D1.80.D0.B0_.D0.B1.D0.B5.D1.81.D0.BF.D0.B8.D0.BB.D0.BE.D1.82.D0.BD.D0.BE.D0.B9_.D0.BB.D0.BE.D0.B3.D0.B8.D1.81.D1.82.D0.B8.D0.BA.D0.B8">Polina Latypova из Evocargo. Как мы столкнулись с тщеславной метрикой и победили её. История из мира беспилотной логистики</span></h1>
<p>Очень интересный доклад по предметной области — беспилотные грузовики, которые уже активно работают на закрытых территориях, обычно складах. Автономные, электрические, 2 тонны, средняя скорость 20 км/ч, зарядка от розетки 6 часов на 200 км. На той же площадке могут ездить трактора, управляемые людьми, и ходить люди. Хотя грузовики — автономные, в особых ситуациях требуется вмешательство оператора с диспетчерского пункта. Речь не идет о срочной остановке, просто машина по какой-либо причине не может продолжать движение из-за каких-то препятствий и, например. может запросить разрешение на объезд по встречной полосе или сигнализировать о проблеме. В докладе были примеры и для других автороботов, например, застрявший в сугробе доставщик или массовый сбой Cruise, когда много машин приехали в одно место создали пробку.
</p><p>Метрика disengagement rate — число вмешательств оператора на км. И это метрика, в которой соревнуются компании. Был график с сайта therobotreport.com — в Калифорнии публикация этих данных обязательна. И они тоже начали собирать эту метрику. Однако, в исходном виде — число вмешательств на км — ничего не говорит. Уменьшение значения — не говорит, что технология стала лучше. Кроме того, автомобили — в разных погодных условиях, поэтому сравнение этих метрик по разным складам или разным дням тоже не информативно. Потребовалась дополнительная аналитика, в частности деление по причинам вмешательства: ошибка автопилота, физическая неисправность, изменение задачи уже в процессе движения и внешние обстоятельства, например, полная блокировка разрешенного участка дороги. При этом есть нюанс квалификации. Машины умеют объезжать препятствия. Но могут быть тупики, когда автомобиль окружили фуры, и проехать реально нельзя. Далее Обогащение данных: время вмешательства, в какой режим из автоматического переключаешься, что использовал оператор для вмешательства, версия релиза и так далее, и не только из автопилота, но и из других систем. И на обогащенных данных получилась возможность ловить реальные проблемы и разбираться. В докладе было несколько примеров, связанных с частыми остановками или ручными вмешательствами в определенном месте. И дальше выявляется и устраняется причина. В одном случае это был маленький человечек на разметке, которого автопилот принимал за человека, в другом — после обновления автопилот перестал доезжать несколько сантиметров до гейта, а на конкретном складе это было важно и потребовалось дообучить, и так далее. В целом это аналогично любому анализу инцидентов, но сама предметная область — интересная.
</p>
<h1><span class="mw-headline" id=".D0.9F.D0.B0.D0.B2.D0.B5.D0.BB_.D0.93.D0.B5.D1.80.D0.BC.D0.B0.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.9D.D0.9E.D0.A2.D0.90._.D0.9F.D0.BB.D0.B0.D0.B3.D0.B8.D0.BD.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F._.D0.92.D1.8B.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B9_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC.D1.8B_.D0.B2_.D0.BF.D0.BE.D0.B4.D0.BA.D0.BB.D1.8E.D1.87.D0.B0.D0.B5.D0.BC.D1.8B.D0.B5_.D0.BF.D0.BB.D0.B0.D0.B3.D0.B8.D0.BD.D1.8B">Павел Германов из НОТА. Плагинизация. Выделение функций системы в подключаемые плагины</span></h1>
<p>Основная идея — вынести изменяемый и дополнительный функционал системы в плагины. В общем, давно известная конструкция, в массовых продуктов она появилась, наверное, в Mozilla Firefox, в котором с самого начала было множество плагинов, в отличие от IE. А в enterprise типичным плагином является форма печати, которые даже часто отдаются клиентам, потому что там есть большое разнообразие и механизмов настройки по шаблонам часто не хватает. Они выделяют плагины в своих системах, но их разработку держат сами, клиентам не отдают. При этом основа процесса остается в core-системы. И в этом отличие подхода плагинов от подхода оркестрации сервисов или компонентов внешним средством, как это делает comunda или аналогичные движки. К сожалению, глубокого погружения в выделение плагинов не было, был лишь слайд с принципами выделения.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B0.D1.82.D0.BE.D0.BB.D0.B8.D0.B9_.D0.9B.D0.B5.D0.B2.D0.B5.D0.BD.D1.87.D1.83.D0.BA._.D0.98.D0.BD.D1.82.D0.B5.D0.BB.D0.BB.D0.B5.D0.BA.D1.82-.D1.81.D1.82.D0.B5.D0.BA_.D0.B4.D0.BB.D1.8F_.D0.B8.D0.BD.D0.B6.D0.B5.D0.BD.D0.B5.D1.80.D0.BE.D0.B2_.D0.B8_.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.B5.D1.80.D0.BE.D0.B2">Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров</span></h1>
<p>Интеллект стек — комплексное представление о наборе дисциплин/умений/практик мышления, которые требуются для эффективной деятельности, позволяют строить модели и обеспечивать изменения в реальном мире на их основе. Конечно, это не стек, а сложный граф с зависимостями, но там есть логическая последовательность базовых практик, над которыми далее вырастают практики инженера, практики менеджера, как это показано на слайде, и еще практики инженерии личности, которые пока не нарисованы.
</p><p><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:AnalystDays_17_ailev-4.jpg" class="image"><img alt="AnalystDays 17 ailev-4.jpg" src="https://mtsepkov.org/images/thumb/6/62/AnalystDays_17_ailev-4.jpg/800px-AnalystDays_17_ailev-4.jpg" width="800" height="450" srcset="https://mtsepkov.org/images/thumb/6/62/AnalystDays_17_ailev-4.jpg/1200px-AnalystDays_17_ailev-4.jpg 1.5x, https://mtsepkov.org/images/6/62/AnalystDays_17_ailev-4.jpg 2x" /></a>
</p><p>А на этом слайде — раскрытие названий практик, которые представлены на предыдущем слайде. И по ним надо брать современное содержание, потому что развитие ИИ опрокинуло многие старые представления, касающиеся языка и мышления, стало ясно, что устроено все сильно не так.
</p><p><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:AnalystDays_17_ailev-5.jpg" class="image"><img alt="AnalystDays 17 ailev-5.jpg" src="https://mtsepkov.org/images/thumb/6/65/AnalystDays_17_ailev-5.jpg/800px-AnalystDays_17_ailev-5.jpg" width="800" height="450" srcset="https://mtsepkov.org/images/thumb/6/65/AnalystDays_17_ailev-5.jpg/1200px-AnalystDays_17_ailev-5.jpg 1.5x, https://mtsepkov.org/images/6/65/AnalystDays_17_ailev-5.jpg 2x" /></a>
</p><p>Дальше были комментарии к отдельным практикам. Школа этим практикам не учит, вернее учила лишь косвенно. В теории детей надо подготовить к жизни, чтобы они могли себя прокормить, но на этом в школе фокуса нет, и в ВУЗе тоже. Раньше жизни учила улица и подъезд, а сейчас эта часть социальной жизни отвалилась, так что все — сами.
</p><p>Но сначала — совершенно роскошная метафора. Очень многие люди, почему-то не думают о воплощении модели в реальном мире, они считают, что написали документ, сделали модель — и мир изменится сам. Это — магическое мышления, подобное магу вуду, который полагает, что достаточно воткнуть булавки в куклу — модель человека и у реального человека что-то изменится. Практика говорит, что это — не так.
</p>
<ul><li> <b>Понятизация</b>. Картинка — дайте имя объекту. И эо когда вы приходите к клиенту — и каждые два дня понимаете, что имя не то и объект не тот. А можно ощутить дребезг в теле, кинестетика, ощущение. И у всех кто на высоком уровне есть та или иная телеска для того, чтобы чуять — правильно или нет. Что ты выделяешь, когда смотришь на оратора. Можешь ли поменять фигуру и фон.</li>
<li> <b>Собранность</b>. Кривая забывания и компьютерная память. Мнемотехники. Удержания понятий. Список работает до 400 строк, а дальше — заведи базу данных. А до 400 — все равно написать, начиная с 2 строк, а лучше — с одной. У организации тоже есть собранность: либо коллектив помнит, каким проектом занимался вчера, или не помнит.</li>
<li> <b>Понятия — математика, предметы окружающего мира — физика</b>. Математическому мышлению не учат, учат отраслям математики. Так же как и физическому мышлению вообще.</li>
<li> <b>Семантика</b>. Нагружение знаков смыслом, связь их с реальным миром.</li>
<li> <b>Теория понятий</b> — теория прототипов или образцов, и это экспериментально подтверждено. Логики там нет. Объяснить нейросети, что такое двуручный меч?</li>
<li> <b>Онтология — машинка типов</b>. 5 уровней: foundation ontology — типы систем, практик — типы объектов труда, деятельности — типы объектов прикладных дисциплин — модель экземпляров объектов.</li>
<li> <b>Алгоритмика</b>. 1.0 — то, что все делают, 2.0 — ИИ и обучение, 3.0 — когда онтологии и программы пишут нейронные сетки.</li>
<li> <b>Логика</b>. А чо такова? Реагировать на ошибки в рассуждениях. 2*2=5 — ну и что?</li>
<li> <b>Рациональность</b>.</li>
<li> <b>Эстетика</b>, как естественная наука.</li>
<li> <b>Этика</b> — многоуровневая.</li>
<li> <b>Риторика</b> — должна быть этична. И переводит между разными теориями понятий.</li>
<li> <b>Методология</b> — схема, как устроено предприятие. Она дает объекты внимания, альфа, которые меняются в ходе проекта.</li>
<li> <b>Системная инженерия</b>, то есть обобщенная инженерия систем. С 2017 года требований нет, архитектура — нечто другое. Инженерия платформ вместо devops.</li></ul>
<p>А дальше пошли надстройки: инженерия конкретных систем, менеджмент — инженерия организация и инженерия личности.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.B9.D0.B3.D1.83.D0.BB.D1.8C_.D0.93.D0.B0.D0.B1.D0.B4.D1.80.D0.B0.D1.85.D0.B8.D0.BC.D0.BE.D0.B2.D0.B0._.D0.A1.D1.82.D1.80.D0.B5.D1.81.D1.81.2C_.D0.B0.D0.B4.D0.B0.D0.BF.D1.82.D0.B0.D1.86.D0.B8.D1.8F.2C_.D0.B3.D0.B8.D0.B1.D0.BA.D0.BE.D1.81.D1.82.D1.8C:_.D0.BA.D0.B0.D0.BA_.D0.B0.D0.BD.D0.B0.D0.BB.D0.B8.D1.82.D0.B8.D0.BA.D1.83_.D1.81.D0.BE.D1.85.D1.80.D0.B0.D0.BD.D0.B8.D1.82.D1.8C_.D0.BD.D0.B5.D1.80.D0.B2.D1.8B_.D0.B8_.D0.BC.D0.BE.D0.B7.D0.B3.D0.B8">Айгуль Габдрахимова. Стресс, адаптация, гибкость: как аналитику сохранить нервы и мозги</span></h1>
<p>Доклад из двух частей: стресса и про теорию множественного интеллекта Говарда Гарднера. И у меня этот доклад вызвал печальку по поводу современного уровня мышления, это как раз иллюстрация того, о чем говорил Левенчук и я в своих докладах. И я хочу разобрать, с чем эта печалька связана.
</p><p><b>Первое</b>. Про стресс, со ссылкой на научпоп модель было сказано, что он возникает как реакция на изменения, естественный, и ничего с ним сделать нельзя. Но стоит проверить физиологию, потому что связан уровнем кортизола, и он может просто плохо выводиться почками. И стоит посмотреть на базовые потребности по Маслоу, потому как если вы стабильно не высыпаетесь, что-то в жизни надо менять. Так вот, современная наука знает о стрессе достаточно много, там 5-6 разных вариантов, со своими причинами и способами управления. И надо сначала диагностировать, что именно у вас, а потом — работать над устранением конкретных причин. Как при любых нарушениях. Если кому интересны подробности, то можно посмотреть доклады Обуховой, у нее их много, она профи — среди ее шести высших есть биология и нейрофизиология.
</p><p><b>Второе</b>, тоже про стресс. Спикер — аналитик, но эту лапшу про стресс из книги приняла как теорию. Хотя эта лапша аналогична следующему ответу разработчиков на претензии по поводу большого количества инцидентов в программе: инциденты связаны с ошибками, а ошибки могут возникать при любых изменениях в программах, и потому всегда будут если программы развивать, а еще может быть ненадежная связь с сервером, вы проверьте, у вас сетевой кабель хорошо воткнут или нет. Понятно, что это — непрофессиональный ответ, что с инцидентами надо разбираться: кластеризовать, выявлять распространенные и проводить анализ их причин, а затем — придумывать, как их можно исключить. И вот тут то же самое: получен фиговый ответ общего характера, значит надо искать другие ответы. Конечно, он получен в чужой области, но критическое мышление — оно от области не очень зависит, его стоит применить.
</p><p><b>Третья печалька — про теорию множественных интеллектов</b>, которая признана как актуальная теория в современной педагогике. Говард Гадрнер выделил 9 видов интеллекта: Внутриличностный, Вербальный (или лингвистический), Логико-математический, Экзистенциальный, Пространственный, Музыкальный, Межличностный, Телесно-кинестетический, Природоведческий, позднее добавил еще несколько. Причина появления этой теории понятна — социальный заказ объяснить, что все люди — ценны, независимо от их IQ. Он выполнен, IQ меняет только 3 из них, а есть вот еще сколько.
</p><p>Но дело в том, что эта классификация — это <a rel="nofollow" class="external text" href="https://ru.wikipedia.org/wiki/Классификация_животных_(Борхес)">типология Борхеса</a>, она не имеет оснований. Если смотреть на реальные конструкции, то надо исследовать системы мозга и обосновывать. И как-то отделать системы нейронов в мозгу, ответственные за конкретные типы интеллекта. Восприятие целостно, это хорошо иллюстрирует восприятие фрагмента От улыбки станет всем светлей, которому еще подтанцовывали — там музыка, движения тела, текст, да еще культурный контекст. При этом культурная составляющая играет существенную роль. В той же музыке — западная музыка, основанная на приятном нотном стане сильно отличается от имеющих другие лады. Да и языковые интеллект карты у китайцев сильно отличаются от западных, арабских и других алфавитных письменностей, потому что в Китае сильное влияние описывают конструкции иероглифов из конкретных образов. Отдельная вишенка на торте тут экзистенциальный интеллект, который отвечает за осознание смысла жизни, а вкладывают в него умение наслаждаться текущим моментом, достигаемое через медитации, направленные на осознание своих ощущений. Понятно, что это тоже социальный заказ, человек, реально задумывающийся о смысле жизни в деятельном залоге, стремящийся сделать мир лучше — опасен для современного общества. Поэтому объявим правильным смыслом жизни умение наслаждаться текущим моментом. Отмечу, что тут к спикеру — никаких претензий, она адекватна изложила теорию, я погуглил другие краткие изложения и сопоставил.
</p>
<h1><span class="mw-headline" id=".D0.A1.D0.B2.D0.B5.D1.82.D0.BB.D0.B0.D0.BD.D0.B0_.D0.94.D0.B5.D1.80.D0.B3.D0.B0.D1.87.D0.B5.D0.B2.D0.B0._.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5_.D0.A2.D0.A0.D0.98.D0.97_.D0.B4.D0.BB.D1.8F_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B7.D0.B0.D0.B4.D0.B0.D1.87_.D1.81_.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D1.8C.D0.BD.D1.8B.D0.BC_.D1.83.D1.80.D0.BE.D0.B2.D0.BD.D0.B5.D0.BC_.D0.BD.D0.B5.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8">Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности</span></h1>
<p>Тема ТРИЗ на ИТ-конференциях возникает регулярно, я слушал много докладов и хочу отметить, что это — замечательный доклад. Он — на основе большого практического опыта, а не просто на основе первоначального знакомства. При этом достигнуть такого уровня у Светланы получилось только с третьего раза, на первых попытках отпугивала инженерная сложность и приземление на совершенно другой материал — ведь подход Альтшулер создавал в 50-е. Но потом появилась сложная задача — определять, читерит ли студент на экзамене, при том, что нейронные сетки выдавали ответ с достоверностью 50 %, там ТРИЗ помог и пошло развитие. Еще я отдельно хочу отметить оформление презентации и сквозной игровой пример с канарейкой, которой надо добыть еду зимой — это наряду с примерами из ИТ.
</p><p>ТРИЗ — ощущение тупика, когда мы не знаем куда идти. Теодюль Рибо в своих исследованиях показал, что креативность линейно растет с возрастом ребенка, достигает пика в 12-15, а потом идет на спад. Дети умеют рисовать картинки, которые не видели в реальной жизни, а инженеры уже преимущественно копируют. Я тут хочу отметить, что есть зефирный эксперимент (marshmallow Peter Skillman, <a rel="nofollow" class="external text" href="https://manage-it.livejournal.com/64382.html">русское описание</a>), который показал, что креативность падает не сама по себе, ее подавляет система образования.
</p><p>Проблемы на пути поиска решения.
</p>
<ul><li> Полное отрицание новой идеи</li>
<li> принятие на веру положений, высказанных авторитетом</li>
<li> применение старых принципов действия в новых устройствах</li>
<li> не умение перенести в новую область</li>
<li> использование предметов только по назначению</li></ul>
<p>Что рекомендует ТРИЗ.
</p><p>Для начала перейти от проблемы к задаче. Проблема — тупик: «нет еды» — ложись и умирай. «где птице достать еду зимой» — уже задача. Методы: Отказ от терминов, если мешают и переформулировать с акцентами на выхлоп, на процесс, на актора.
</p><p>Акцент на выхлоп — когда нужен результат: Идеальный финал, экстра-результаты 2-3 известных фактора, ограничения. Не «у нас нет пользователей» а «в нашем приложении за полгода нужен двухкратный прирост пользователей, в идеале — приходили и покупали платную подписку при ограниченном бюджете…»
</p><p>Акцент на актора — работа с ресурсами, с простоями (нет задач у тестировщиков), с мотивацией, подход к людям в маленькой компании. Изолируем ресурс, расписываем как систему, 3 сильные стороны, формулировки «существует в среде», как добиться ситуации.
</p><p>Акцент на процесс — оптимизация, бутылочное горлышко (архитектор-тимлид), стимуляция к поиску. Изолировать главный процесс, описать пошагово: кто — что делает — с кем, как устранить препятствия.
</p><p>Дальше — поиск решения.
</p><p>Системное мышление. Хороший инженер видит объект и вариации, а АРИЗ-инженер видит надсистему — систему — подсистему, все это в прошлое-настоящее-будущее и еще антиподы систем. И в презентации был хороший пример, эволюция faq -> чат-бот -> AI-помощник с соответствующей эволюцией надсистемы и подсистемы.
</p><p>Поиск противоречия — несколько видов
</p>
<ul><li> Нужно что-то сделать, а как — неизвестно — административное</li>
<li> Улучшения одной части ухудшает другую — техническое</li>
<li> К одной части системы противоположные требования — физическое.</li></ul>
<p>Другое деление: явное — пришли пользователи, авторизация упала, неявное — хотим сделать.
</p><p>Для формулирования противоречий хорошо помогает SWOT-анализ, их формулируют слабости и угрозы .
</p><p>Способы решения противоречия:
</p>
<ul><li> Симбиоз с системой. Что надо изменить внутри, чтобы соответствовать надсистеме, что в надсистеме мешает развитию, что надо изъять. Задача про экзамен студента — надо подружиться с LMS, а они все разные. Оказалось, что LMS не любят открывать в iframe. Они написали плагин, он изолирует и разрешает, и заодно куки решили.</li>
<li> Обратная связь. Если обратная связь есть — изменить ее, если она не решает проблему.</li>
<li> Конструктор — соединение разные элементы. Когда ломается узел, уходит человек, сложно заменить — представим его по частям, а не целиком.</li>
<li> Применяем роль — де Боно взглянуть на задачу как ученый (факты), художник (эмоции), критик (риски), оптимист (плюсы), креатор (нестандартно, начальник (координация).</li>
<li> Метод одноразового стаканчика — заменяем дорогой набором дешевых. Worker — их можно запускать много.</li>
<li> Экстрадетализация. Когда нет никаких идей. Просто расписываешь задачу как маньяк, синонимы, прилагательные, глаголы, ассоциации — пока не щелкнет.</li>
<li> Вред в пользу: использовать вредные факторы для положительного эффекта, устранить вредный за счет сложения с другим вредным, усилить вредный, чтобы перестал быть вредным. У них — 5 нейросетей-распознавалок до 300 мб (лицо, голос и так далее). Они перенесли загрузку на самое начало и пустили параллельно с административными шагами — проверить оборудование, сфотографировать документ и т. п. И они в конце вставили экран с правилами, и пока человек читает, кнопка «продолжить» не горит, они дают время человеку и себе.</li>
<li> Инверсия. Глаголов, прилагательных, смыслов, меняем объекта и субъекта, инверсия актора, цели, порядка действий в процессе… Freemium и trial версии — сначала пользуйся, потом плати.</li>
<li> Посредник — использовать промежуточный объект передающий или переносящий действие, на время присоединить легко удаляемый объект. Вынесение частей из монолитов.</li>
<li> Дробление — декомпозиция: разделить на части, выполнить разборным, увеличить степень дробления. Модульность, микросервисы</li>
<li> Вынесение лишнего. Отделить мешающее или выделить нужное. Живо-чат — вынесли чат из сервис-деска и можно прикрепить куда угодно, и еще контекст пишешь.</li>
<li> Чуть меньше или чуть больше, если трудно точно нужное. Готовые библиотеки, пусть там есть не нужное, или наоборот, не хватает, но мало.</li>
<li> Самообслуживание: объект должен сам себя обслуживать, выполняя вспомогательные или ремонтные операции. Использовать отходы.</li></ul>
<p>Интеграция — когда даем клиенту сделать все самому.
</p>
<ul><li> Копирование. Вместо недоступного сложного дорогого использовать дешевые копии. Использовать изменение масштаба.</li>
<li> Сумасшедший микс — де Боно. Накидываем самые разные слова по ассоциациям, случайные. Накидали производных слов — кенгуру — накидали всплывашки «сделай перерыв — есть приложение для медитации». Или автомобиль — фиксация что пользователь в автомобиле, за рулем и что-то адаптируем.</li>
<li> Замена. Замещаем актора: делают не разработчики, а дети, алкоголики или врачи. Замещаем других акторов: разработка делает интерфейс совместно с конкурентами. Можно замещать среду, объект, цели</li>
<li> Выше скорость — меньше ям. Ускорить негативные процессы, адекватно оценить как ускорить. Фаст-фуды — снижение качества пищи в обмен на скорость. Картинка в плохом качестве на плохом интернете. Скелетон первой страницы, если там долгая загрузка элементов.</li>
<li> Метод вируса — подселение агента во враждебную часть среды, чтобы сделать управляемой. Выписать агенты проблемной зоны — акторы, субъекты живые и неживые, можно ли заменить? Удаленный рабочий стол.</li></ul>
<p>Дальше Отбор идей. Как генерить — методы ТРИЗ. Линия рациональности — выгоды против затрат.
</p><p>Подводя итог. Мнемоника ЗППП: Задачи из проблемы; Подсистемы (и надсистемы); подбираем метод; приоритизируем фичи. И в конце довольно большой список литературы по ТРИЗ и смежным темам.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.B0.D0.BB.D0.B5.D1.80.D0.B8.D0.B9_.D0.A0.D0.B0.D0.B7.D0.BD.D0.BE.D0.BC.D0.B0.D0.B7.D0.BE.D0.B2._.D0.9E.D0.B1.D1.8A.D0.B5.D0.BA.D1.82.D0.BD.D0.BE-.D0.BE.D1.80.D0.B8.D0.B5.D0.BD.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.BD.D1.8B.D0.B9_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4_.D0.B2_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B5.D0.BD.D0.B8.D0.B8_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D1.8B_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D0.B9">Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений</span></h1>
<p>Глубокий доклад о применении DDD. И в нем противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы, которые автор называет «функциональным подходом» (от бизнес-функций). Аргумент за объект — они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного «важные, ключевые решения»: система — большее, чем совокупность отдельных фич, и архитектура — это то, за счет чего система работает как целое. За это — отдельное спасибо Валерию.
</p><p>Дальше конспект. Потребность в архитектуре порождается семантическим безумием, многообразием и вариативностью представления данных в разных системах. И как средство от этого — корпоративная архитектура данных, единый язык. Раньше это было относительно просто, на основе EBS и Global business objects by IBM — он давал общий формат xml ваших данных. А сейчас при построении экосистем на основе open api требуется объединить очень разное, например, продажу бургеров, онлайн кинотеатр и выдачу кредитов. А грядет интернет вещей, где объединять все со всем. Он астрофизик, и мыслит аналогиями: смысл сущностей — новая гравитация, туманность сведений о заемщике и галактика продуктов.
</p><p>Доклад был на двух примерах: Событийно-ориентированная производственная систем Amanita, для которых был предварительный анализ и CRM психологов — понятная практика, в ней было рамочное пожелание заказчика без предварительного анализа.
</p><p>Основой является разметка бизнес-объектов предметного поля — получение онтологии, которая будет основой для DDD. ООП ставит в основу бизнес-объекты и связи между ними, процессы и правила строят вокруг них. В отличие от функционального подхода, когда сначала выделяем процессы и функции, а объекты и правила их обслуживают и выделяют внутри них. Преимущества ООП: набор объектов и субъектов мы можем предсказать, и кластеризовать тоже. А процессы — нет, там больше разнообразие. Поэтому стартуем с объектов, а не процессов.
</p><p>Теорема бизнес-анализа: любой бизнес-процесс можно представить как описание связей между субъектами и объектами которые могут участвовать в других бизнес-процессах. Задача бизнес-аналитика — определять это. Системный аналитик далее делает отражение в реализацию.
</p><p>Есть два варианта развития проектов: от бизнеса к ИТ и наоборот, от ИТ к бизнесу. Внедрение вендорского решения — от ИТ к бизнесу, перекраиваем бизнес под возможности ИТ. Бизнес может рухнуть, примеры есть. SaaS — тоже самое, натягиваем одно решение на другое.
</p><p>Первоначальные требования: легаси, существующий проект или новый проект.
</p>
<ul><li> Легаси — чужое. И часто без комментариев, и с атрибутным хранением.</li>
<li> Если проект есть — можно сделать лингвистический анализ и частотный — можно построить граф.</li>
<li> Принципиально новый проект, а заказчик не очень понимает что делает — то agile и UI/UX макетирование — можно стартовать.</li></ul>
<p>Декомпозиция: как из первоначальных требований строить архитектуру. Если идею разделить на мелкие фичи — но дальше надо слепить в целое, бизнес-архитектура — и дальше ИТ-архитектура.
</p><p>Онтология — не патентуется, а воплощение в виде классов — патентуется. Бизнес-объект: DTO, Json (xml), таблица как проекции друг друга. Платформа дает json, а интеграция — xml с xsd.
</p><p>При реализации событийно-ориентированная производственная система Amanita опирались на производственные журналы в цехах — там готовая модель событий, его можно сразу переносить в данные.
</p><p>А у психологов: надо сопровождать клиентскую практику, что — неясно. Они сначала рисовали карандашами, потом Figma — и там они сами рисовали, и дальше сделали и оно заработало. Психологи сами смогли разобраться и навести порядок в своей практикой.
</p><p>Ontology driven MSA. Границы микросервиса — границы домена. Микросервисы и цитадели: в цитаделях те объекты, которые относительно статичны и изменения не меняются. Еще в цитадель попадают данные, которые надо защищать.
</p><p>Объектно-ориентированные RESTfull — привязываем к объектам. И дальше SCRUD.
</p><p>Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное
</p><p>Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.
</p><p>Amanita. Мониторинг брака — видеокамера — json — обработка данных — и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ — большая разница, зависит от того, нужна ли будет обработка.
</p><p>Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика — не SQL, а Java. Декомпозиция бизнес-идеи — выделяем субъекты и объекты — строим граф — строим json-схему — строим базу данных.
</p><p>Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.
</p>
<h1><span class="mw-headline" id=".D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9F.D0.BE.D0.B4.D0.BE.D0.BB.D0.B8.D0.BD.D0.B0._.D0.A0.D0.B0.D1.81.D1.88.D0.B8.D1.80.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BD.D0.BE.D1.82.D0.B0.D1.86.D0.B8.D0.B8_BPMN:_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D1.81.D0.BE.D0.B2.D0.BC.D0.B5.D1.81.D1.82.D0.BD.D0.BE_.D1.81_DMN_.28.D1.83.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC.D0.B8.29_.D0.B8_CMMN_.28.D0.BA.D0.B5.D0.B9.D1.81-.D0.BC.D0.B5.D0.BD.D0.B5.D0.B4.D0.B6.D0.BC.D0.B5.D0.BD.D1.82.29">Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент)</span></h1>
<p>BPMN хорошо описывает процессы, особенно если дополнять его описанием орг.структуры и объектов данных, для которых есть отдельные нотации. Но есть отдельные этапы процессов, исполнение которых плохо описываются с помощью BPMN, потому что не представляют собой структурированный процесс. Диаграммы получаются запутанными и не проясняют содержание. И для отражения таких функций можно использовать две другие нотации.
</p><p>Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя — и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN — decision model and notation. В простейшем варианте такое решение — просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений — и они, во-первых, должны быть в системе а, во-вторых — представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.
</p><p>Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение — на усмотрение ответственного. И в финале тоже есть опциональная часть — обращение в суд. Для этого хорошо подходит нотация CMMN — Case management model notation. В ней акцент — не на процессе, а на информации по конкретному случаю. Цель процесса — ясна, а путь — вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка «Проведение проверки». (2) Входные критерии — с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап — не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, дальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом — финальный обязательный этап — акт проверки, и снова дискреционный — работа с судом, а дальше выходные критерии.
</p><p>В презентации были примеры диаграмм, их опубликуют быстро — можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.
</p>
<h1><span class="mw-headline" id=".D0.AF.D1.80.D0.BE.D1.81.D0.BB.D0.B0.D0.B2_.D0.9A.D1.83.D1.87.D0.B5.D1.80.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.93.D0.B0.D0.B7.D0.BF.D1.80.D0.BE.D0.BC.D0.B1.D0.B0.D0.BD.D0.BA.D0.B0._.D0.9C.D0.B0.D1.82.D1.80.D0.B8.D1.86.D0.B0_.D1.81.D1.86.D0.B5.D0.BD.D0.B0.D1.80.D0.B8.D0.B5.D0.B2.C2.A0.E2.80.94_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81-.D0.B0.D0.BD.D0.B0.D0.BB.D0.B8.D0.B7.D0.B0">Ярослав Кучеров из Газпромбанка. Матрица сценариев — инструмент бизнес-анализа</span></h1>
<p>Матрица сценариев — способ представить варианты реализации. Мы выбираем бинарные параметры, которые конфигурируют поведение приложения, и дальше для каждого варианта приложения с их помощью определяем конфигурацию. Например, если надо сделать систему лояльности, то параметрами будет реализация конкретных фич: начислить баллы, списать баллы, посмотреть свои баллы, предложить клиенту списать баллы. И дальше для каждого канала взаимодействия с клиентом: авторизованный заказ на сайте, быстрый заказ без авторизации, мобильное приложение, официант в ресторане, колл-центр — определяем, какие сценарии в них должны быть реализованы. Получаем матрицу, согласуем с заказчиком и именно это делаем. Матрица дает наглядное представление, и в презентации было несколько вариантов и примеров из реальных проектов, помимо модельного.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80.D0.B0_.D0.94.D1.8F.D0.B3.D0.B8.D0.BB.D0.B5.D0.B2.D0.B0._.D0.9A.D0.B0.D0.BA_.D0.BC.D1.8B_.D0.BD.D0.B5.D1.83.D0.B4.D0.B0.D1.87.D0.BD.D0.BE_.D0.B2.D0.BD.D0.B5.D0.B4.D1.80.D0.B8.D0.BB.D0.B8_.D1.80.D0.B5.D0.B2.D1.8C.D1.8E_.D1.82.D1.80.D0.B5.D0.B1.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B9_.D0.B8_.D0.B8.D1.81.D0.BF.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D0.B8.D1.81.D1.8C">Александра Дягилева. Как мы неудачно внедрили ревью требований и исправились</span></h1>
<p>В команде были проблемы с недостаточным качеством требований — много задач приходят на доработку уже после реализации, пост-анализ говорит, что проблема в именно в требованиях: они не полны. противоречивы или неоднозначно трактуются. Для решения проблемы решили делать ревью. И в сначала решили, что ревью будет делать тимлид, как самый опытный, плюс у него будет полное представление обо всех изменениях, это плюс. Но тимлид быстро стал узким горлом, что достаточно ожидаемо — ведь других обязанностей с него не снимали, включая постановки по сложным задачам, которые он делал в силу опыта. Поэтому подход поменяли. На проекте функциональная область приложения была поделена по темам. и за каждой закреплен аналитик. И помимо аналитика за каждой областью закрепили своего ревьюера. Это несколько усложнило конструкцию, но убрало перегрузку тимлида.
</p>
<h1><span class="mw-headline" id=".D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.90.D0.B7.D0.B8.D0.BC.D0.B1.D0.B0.D0.B5.D0.B2.D0.B0._Discovery._.D0.A7.D0.B5.D1.81.D1.82.D0.BD.D0.B0.D1.8F_.D0.B2.D0.BD.D1.83.D1.82.D1.80.D1.8F.D0.BD.D0.BA.D0.B0.C2.A0.E2.80.94_.D1.81.D1.82.D0.BE.D0.B8.D0.BC.D0.BE.D1.81.D1.82.D1.8C.2C_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81.D1.8B.2C_.D1.8D.D0.B2.D0.BE.D0.BB.D1.8E.D1.86.D0.B8.D1.8F_.D0.BF.D0.BE.D0.B4.D1.85.D0.BE.D0.B4.D0.BE.D0.B2_.D0.BD.D0.B0_.D0.B6.D0.B8.D0.B2.D1.8B.D1.85_.D0.BF.D1.80.D0.B8.D0.BC.D0.B5.D1.80.D0.B0.D1.85">Ольга Азимбаева. Discovery. Честная внутрянка — стоимость, процессы, эволюция подходов на живых примерах</span></h1>
<p>Discovery в этом докладе — проектирование и оценка реализуемости концепции, обычно через прототип или какую-то еще разработку. Рассмотрено три подхода к формированию команды, которая делает discovery-фазу нового проекта: набор из числа свободных ресурсов, привлечение экспертов по необходимости с частичной занятостью и сработанная команда квалифицированных экспертов. Первый способ работает лишь для несложных проектов, потому что эксперты редко бывают свободными, обычно получается привлечь лишь джунов и мидлов, а они сложный проект не сделают. Привлечение экспертов с частичной занятостью увеличивают доступную сложность, но для сложных проектов временно привлекаемых экспертов недостаточно. Сработанная команда лучше всего справляется со сложными проектами, но для того способа нужен постоянный поток проектов, иначе люди начинают простаивать. Был пример состава сбалансированной команды: Solution Architect, BA expert, 3 senior dev и 2 junior BA для документирования. Кроме этого, было рассказано несколько историй выполнение discovery — фазы в различных вариантах с анализом результата.
</p>
<h1><span class="mw-headline" id=".D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.97.D1.83.D0.B1.D0.BA.D0.BE.D0.B2.D0.B0._.D0.98.D0.B3.D1.80.D0.B0_.D0.BA.D0.B0.D0.BA_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82_.D0.B4.D0.BB.D1.8F_.D0.B8.D1.81.D1.81.D0.BB.D0.B5.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D1.80.D0.B5.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D1.85_.D0.BA.D0.B5.D0.B9.D1.81.D0.BE.D0.B2">Ольга Зубкова. Игра как инструмент для исследования реальных кейсов</span></h1>
<p>Игра — имитация деяятельности, из которой играющие извлекают нечто полезное. Целью игры может быть обучение или решение реальных задач. В чем преимущество игры? В игре у человека есть право на ошибку, она дает другой взгляд и вариативность решений, возможность изменить решение — в реальной ситуации эти возможности ограничены. Еще она позволяет оттачивать навыки и оценить компетентность команды: готовы ли к компромиссам, могут ли отстаивать свое мнение, могут ли осознать неправильность решения.
</p><p>Естественно, у игры есть свои ограничения. Когда играть не стоит? Незаинтересованность участников; высокая концентрация информации — в игре нет времени; высокий уровень абстракции — в игре убирают детали, и не все так могут; игра проходит поверхностно и не для всех задач это подходит.
</p><p>И дальше в докладе был обзор набора задач, которые можно решать с помощью игры, с примерами конкретных игр:
</p>
<ul><li> планирование карьеры и профессиональное развитие</li>
<li> развитие лидерских навыков, запрос на рост</li>
<li> развитие креативности и инновационного мышления</li>
<li> развитие способностей к адаптации и гибкости</li>
<li> улучшение коммуникационных навыков</li>
<li> улучшение отношений</li>
<li> развитие предпринимательского интеллекта</li>
<li> развитие саморефлексии и самосознания</li>
<li> навыки презентации и общения с топ-менеджерами</li>
<li> разработка стратегий управления изменениями</li>
<li> оценка компетентности команды</li>
<li> разбор первопричины проблем</li>
<li> эмуляция запуска чего-то</li>
<li> поиск инструментов</li>
<li> исследование конкретных бизнес-задач</li></ul>
<p>Игра может дать неожиданный эффект, в Кошелек проводили игру для приоритизации фичей, и пришли к решению, что вообще ничего не надо улучшать.
</p><p>Естественно, игру надо готовить: определить контекст, где и зачем будет игра, подготовить участников, определить их роли и модераторов, выработать правила. А после игры — оценить результаты, не те, что достигнуты внутри игры, а те, ради которых проводилась игра.
</p><p>Цели и результаты в ходе игры, и цели, ради которых проводилась игра могут сложно соотносится. Например, в компании проводят игру. в ходе которой производственники стали продажниками, а продажники — производственниками, и достигли при этом каких-то результатов. Но цель была в том, чтобы почувствовав себя в шкуре другого, они изменили рабочие отношения, и именно это надо оценивать, сначала сразу после игры. а потом — наблюдая за изменением отношений. Другой кейс: для запуска agile в одной из компании с традиционной культурой была проведена игра: сотрудники целый день играли другую компанию, которая живет по agile. И им понравилось, ушло предубеждение, после этого получилось начать запуск agile в самой компании. И оценивать в этом случае надо именно готовность к запуску. Но при этом игра может быть двухслойная: не только увеличить готовность к запуску. но и попробовать разные вариации agile-методов.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-10-26:_High_Performance_Systems_-_%D0%B7%D0%B0%D0%B3%D0%BB%D1%8F%D0%BD%D1%83%D1%82%D1%8C_%D0%B2_%D0%BC%D0%B8%D1%80_enterprise2023-10-26: High Performance Systems - заглянуть в мир enterpriseMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-10-25T22:29:20Z2023-10-26T10:27:46Z<div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>На этой неделе прошла конференция <a rel="nofollow" class="external text" href="https://hps-conference.ru/"><b>High Performance Systems</b></a>. Планировался оффлайн, перенести в online. Интересные рассказы о том, что сейчас происходит в развитие ИТ корпораций сейчас, когда надо быстро изменять ИТ-ландшафт. В целом контент конференции — содержательный и полезный. Мои фавориты среди докладов:
</p>
<ul><li> <a href="#.D0.90.D1.80.D1.82.D0.B5.D0.BC_.D0.9A.D0.B0.D0.BB.D0.B5.D0.B4.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.91.D0.B8.D0.BB.D0.B0.D0.B9.D0.BD._.D0.9B.D0.B8.D0.B4.D0.B5.D1.80.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D0.BE_.D0.BC.D0.B5.D1.82.D0.BE.D0.B4.D1.83_.D0.BD.D0.B0.D0.B4.D0.B5.D0.B6.D0.BD.D0.BE.D0.B9_.D0.B1.D0.B0.D0.B7.D1.8B_.E2.80.94_.D0.BA.D0.B0.D0.BA_.D1.8D.D1.84.D1.84.D0.B5.D0.BA.D1.82.D0.B8.D0.B2.D0.BD.D1.8B.D0.B9_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81_.D1.80.D1.83.D0.BA.D0.BE.D0.B2.D0.BE.D0.B4.D1.81.D1.82.D0.B2.D0.B0_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B_.D0.B2_.D1.83.D1.81.D0.BB.D0.BE.D0.B2.D0.B8.D1.8F.D1.85_.D0.BE.D0.B3.D1.80.D0.B0.D0.BD.D0.B8.D1.87.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.BE.D0.B2">#Артем Каледин из Билайн. Лидерство по методу надежной базы — как эффективный процесс руководства команды в условиях ограниченных ресурсов</a>. В докладе выделено два известных вида лидерства: классическое и трансформационное, и им противопоставлено <b>лидерство надежной базы</b> — подход, который сформулировал <b>Джордж Колризер</b>. Концепция кажется мне интересной и требует осмысления.</li>
<li> <a href="#.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9B.D0.B0.D1.82.D1.8B.D0.BF.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_.D0.A1.D1.83.D1.80.D0.B3.D1.83.D1.82.D0.BD.D0.B5.D1.84.D1.82.D0.B5.D0.B3.D0.B0.D0.B7.D0.B0._.D0.A2.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D1.8F_.D0.B2_.D1.81.D1.82.D1.80.D0.B5.D0.BC.D0.BB.D0.B5.D0.BD.D0.B8.D0.B8_.D0.BA_.D0.98.D0.A2-.D1.81.D1.83.D0.B2.D0.B5.D1.80.D0.B5.D0.BD.D0.B8.D1.82.D0.B5.D1.82.D1.83._.D0.A7.D1.82.D0.BE_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE.3F">#Ольга Латыпова из Сургутнефтегаза. Трансформация в стремлении к ИТ-суверенитету. Что нового?</a> — Это рассказ о новом ИТ-ландшафте, который строит Сургутнефтезаз, решая задачу импортозамещения.</li>
<li> <a href="#.D0.A0.D1.83.D1.81.D1.82.D0.B0.D0.BC_.D0.9A.D1.83.D1.80.D0.B0.D0.BC.D1.88.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.93.D0.B0.D0.B7.D0.BF.D1.80.D0.BE.D0.BC_.D0.98.D0.94._.D0.9A.D0.B0.D0.BA_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82.D1.8B_.D0.B1.D1.8B.D1.81.D1.82.D1.80.D0.BE.D0.B9_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.BA.D0.B8_.D0.BD.D0.B0_Java_.D0.BC.D0.BE.D0.B3.D1.83.D1.82_.D0.BF.D0.BE.D0.BC.D0.BE.D1.87.D1.8C_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D1.83">#Рустам Курамшин из Газпром ИД. Как инструменты быстрой разработки на Java могут помочь бизнесу</a>. Рассказ о lowcode инструментах Java с демонстрацией примеров.</li>
<li> <a href="#.D0.90.D0.BD.D0.B4.D1.80.D0.B5.D0.B9_.D0.A1.D1.83.D1.85.D0.BE.D1.80.D1.83.D0.BA.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.9B.D0.B0.D0.B1.D0.BE.D1.80.D0.B0.D1.82.D0.BE.D1.80.D0.B8.D0.B8_.D0.9A.D0.B0.D1.81.D0.BF.D0.B5.D1.80.D1.81.D0.BA.D0.BE.D0.B3.D0.BE._.D0.98.D0.BC.D0.BF.D0.BE.D1.80.D1.82.D0.BE.D0.B7.D0.B0.D0.BC.D0.B5.D1.89.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B8.D0.B3.D1.80.D0.B0.D1.86.D0.B8.D0.B8_.D0.BE.D0.B1.D0.BB.D0.B0.D0.BA.D0.BE.D0.B2_.E2.80.93_.D1.81.D0.BA.D0.B0.D0.B7.D0.BA.D0.B8_.D0.BD.D0.B0_.D0.BE.D0.B1.D0.BE.D1.87.D0.B8.D0.BD.D0.B5">#Андрей Сухоруков из Лаборатории Касперского. Импортозамещение и миграции облаков – сказки на обочине</a>. Доклад о граблях, с которыми связан переезд в облака. И мне понравились заключительные тезисы: (1) облако — не тренд, а один из вариантов, может быть он вам подходит, а может и нет; (2) для переезда в российские облака, надо иметь большую силу духа.</li>
<li> Интересная пара докладов про kubernetis — <a href="#.D0.9B.D0.B5.D0.B2_.D0.A5.D0.B0.D0.BA.D0.B8.D0.BC.D0.BE.D0.B2_.D0.B8.D0.B7_Wildberries._.D0.A1.D0.BA.D0.B0.D0.B7_.D0.BE_.D1.80.D1.83.D0.BB.D0.B5.D0.B2.D0.BE.D0.BC_.D0.B8_.D0.BF.D1.80.D0.BE.D1.80.D0.B5.D1.85.D0.B0.D1.85_.D0.BD.D0.B0_.D0.BF.D0.B8.D0.B4.D0.B6.D0.B0.D0.BA.D0.B5._.D0.9A.D0.B0.D0.BA_.D0.B7.D0.B0.D1.89.D0.B8.D1.82.D0.B8.D1.82.D1.8C_kubernetes">#Лев Хакимов из Wildberries</a> и <a href="#.D0.9A.D0.BE.D0.BD.D1.81.D1.82.D0.B0.D0.BD.D1.82.D0.B8.D0.BD_.D0.90.D0.BA.D1.81.D0.B5.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A4.D0.BB.D0.B0.D0.BD.D1.82._.D0.9A.D0.B0.D0.BA_.D1.83.D1.81.D0.BF.D0.B5.D0.B2.D0.B0.D1.82.D1.8C_.D0.B1.D0.BE.D0.BB.D1.8C.D1.88.D0.B5_.D0.B7.D0.B0_.D0.BE.D0.B4.D0.B8.D0.BD_.D1.81.D0.BF.D1.80.D0.B8.D0.BD.D1.82:_.D0.B2.D1.8B.D1.81.D0.B2.D0.BE.D0.B1.D0.BE.D0.B6.D0.B4.D0.B0.D0.B5.D0.BC_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D1.8B_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.87.D0.B8.D0.BA.D0.BE.D0.B2_.D1.81_.D0.BF.D0.BE.D0.BC.D0.BE.D1.89.D1.8C.D1.8E_Kubernetes-.D0.BF.D0.BB.D0.B0.D1.82.D1.84.D0.BE.D1.80.D0.BC.D1.8B_Deckhouse">#Константин Аксенов из Флант</a>.</li></ul>
<p>В докладе Константина Аксенова была любопытная схема трассировки от технологических преимуществ к показателям бизнеса (производительность команды и компании) и благополучию персонала (удовлетворение от работы, уменьшение выгорание, увеличение продуктивности), я ее запомню как способ объяснять преимущества технических решений для бизнеса.
</p><p>Рассказ о конференции я начну со своего доклада, а далее пойду по порядку. Помимо докладов, было два круглых стола: «Разработка и DevOps с использованием ИИ» и «Параллельный импорт помогает или тормозит технологический суверенитет?» с любопытными мыслями, но пересказывать их — безнадежно, разговор шел причудливыми путями.
</p><div style="float:right; font-size:small; border-radius: 8px; padding: 0 0.5em; margin: 0 0 0 0.5em; background: Aquamarine"><a href="https://mtsepkov.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8" title="Категория:Конференции">О других конференциях</a></div>
<p>На этой неделе прошла конференция <a rel="nofollow" class="external text" href="https://hps-conference.ru/"><b>High Performance Systems</b></a>. Планировался оффлайн, перенести в online. Интересные рассказы о том, что сейчас происходит в развитие ИТ корпораций сейчас, когда надо быстро изменять ИТ-ландшафт. В целом контент конференции — содержательный и полезный. Мои фавориты среди докладов:
</p>
<ul><li> <a href="#.D0.90.D1.80.D1.82.D0.B5.D0.BC_.D0.9A.D0.B0.D0.BB.D0.B5.D0.B4.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.91.D0.B8.D0.BB.D0.B0.D0.B9.D0.BD._.D0.9B.D0.B8.D0.B4.D0.B5.D1.80.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D0.BE_.D0.BC.D0.B5.D1.82.D0.BE.D0.B4.D1.83_.D0.BD.D0.B0.D0.B4.D0.B5.D0.B6.D0.BD.D0.BE.D0.B9_.D0.B1.D0.B0.D0.B7.D1.8B_.E2.80.94_.D0.BA.D0.B0.D0.BA_.D1.8D.D1.84.D1.84.D0.B5.D0.BA.D1.82.D0.B8.D0.B2.D0.BD.D1.8B.D0.B9_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81_.D1.80.D1.83.D0.BA.D0.BE.D0.B2.D0.BE.D0.B4.D1.81.D1.82.D0.B2.D0.B0_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B_.D0.B2_.D1.83.D1.81.D0.BB.D0.BE.D0.B2.D0.B8.D1.8F.D1.85_.D0.BE.D0.B3.D1.80.D0.B0.D0.BD.D0.B8.D1.87.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.BE.D0.B2">#Артем Каледин из Билайн. Лидерство по методу надежной базы — как эффективный процесс руководства команды в условиях ограниченных ресурсов</a>. В докладе выделено два известных вида лидерства: классическое и трансформационное, и им противопоставлено <b>лидерство надежной базы</b> — подход, который сформулировал <b>Джордж Колризер</b>. Концепция кажется мне интересной и требует осмысления.</li>
<li> <a href="#.D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9B.D0.B0.D1.82.D1.8B.D0.BF.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_.D0.A1.D1.83.D1.80.D0.B3.D1.83.D1.82.D0.BD.D0.B5.D1.84.D1.82.D0.B5.D0.B3.D0.B0.D0.B7.D0.B0._.D0.A2.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D1.8F_.D0.B2_.D1.81.D1.82.D1.80.D0.B5.D0.BC.D0.BB.D0.B5.D0.BD.D0.B8.D0.B8_.D0.BA_.D0.98.D0.A2-.D1.81.D1.83.D0.B2.D0.B5.D1.80.D0.B5.D0.BD.D0.B8.D1.82.D0.B5.D1.82.D1.83._.D0.A7.D1.82.D0.BE_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE.3F">#Ольга Латыпова из Сургутнефтегаза. Трансформация в стремлении к ИТ-суверенитету. Что нового?</a> — Это рассказ о новом ИТ-ландшафте, который строит Сургутнефтезаз, решая задачу импортозамещения.</li>
<li> <a href="#.D0.A0.D1.83.D1.81.D1.82.D0.B0.D0.BC_.D0.9A.D1.83.D1.80.D0.B0.D0.BC.D1.88.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.93.D0.B0.D0.B7.D0.BF.D1.80.D0.BE.D0.BC_.D0.98.D0.94._.D0.9A.D0.B0.D0.BA_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82.D1.8B_.D0.B1.D1.8B.D1.81.D1.82.D1.80.D0.BE.D0.B9_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.BA.D0.B8_.D0.BD.D0.B0_Java_.D0.BC.D0.BE.D0.B3.D1.83.D1.82_.D0.BF.D0.BE.D0.BC.D0.BE.D1.87.D1.8C_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D1.83">#Рустам Курамшин из Газпром ИД. Как инструменты быстрой разработки на Java могут помочь бизнесу</a>. Рассказ о lowcode инструментах Java с демонстрацией примеров.</li>
<li> <a href="#.D0.90.D0.BD.D0.B4.D1.80.D0.B5.D0.B9_.D0.A1.D1.83.D1.85.D0.BE.D1.80.D1.83.D0.BA.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.9B.D0.B0.D0.B1.D0.BE.D1.80.D0.B0.D1.82.D0.BE.D1.80.D0.B8.D0.B8_.D0.9A.D0.B0.D1.81.D0.BF.D0.B5.D1.80.D1.81.D0.BA.D0.BE.D0.B3.D0.BE._.D0.98.D0.BC.D0.BF.D0.BE.D1.80.D1.82.D0.BE.D0.B7.D0.B0.D0.BC.D0.B5.D1.89.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B8.D0.B3.D1.80.D0.B0.D1.86.D0.B8.D0.B8_.D0.BE.D0.B1.D0.BB.D0.B0.D0.BA.D0.BE.D0.B2_.E2.80.93_.D1.81.D0.BA.D0.B0.D0.B7.D0.BA.D0.B8_.D0.BD.D0.B0_.D0.BE.D0.B1.D0.BE.D1.87.D0.B8.D0.BD.D0.B5">#Андрей Сухоруков из Лаборатории Касперского. Импортозамещение и миграции облаков – сказки на обочине</a>. Доклад о граблях, с которыми связан переезд в облака. И мне понравились заключительные тезисы: (1) облако — не тренд, а один из вариантов, может быть он вам подходит, а может и нет; (2) для переезда в российские облака, надо иметь большую силу духа.</li>
<li> Интересная пара докладов про kubernetis — <a href="#.D0.9B.D0.B5.D0.B2_.D0.A5.D0.B0.D0.BA.D0.B8.D0.BC.D0.BE.D0.B2_.D0.B8.D0.B7_Wildberries._.D0.A1.D0.BA.D0.B0.D0.B7_.D0.BE_.D1.80.D1.83.D0.BB.D0.B5.D0.B2.D0.BE.D0.BC_.D0.B8_.D0.BF.D1.80.D0.BE.D1.80.D0.B5.D1.85.D0.B0.D1.85_.D0.BD.D0.B0_.D0.BF.D0.B8.D0.B4.D0.B6.D0.B0.D0.BA.D0.B5._.D0.9A.D0.B0.D0.BA_.D0.B7.D0.B0.D1.89.D0.B8.D1.82.D0.B8.D1.82.D1.8C_kubernetes">#Лев Хакимов из Wildberries</a> и <a href="#.D0.9A.D0.BE.D0.BD.D1.81.D1.82.D0.B0.D0.BD.D1.82.D0.B8.D0.BD_.D0.90.D0.BA.D1.81.D0.B5.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A4.D0.BB.D0.B0.D0.BD.D1.82._.D0.9A.D0.B0.D0.BA_.D1.83.D1.81.D0.BF.D0.B5.D0.B2.D0.B0.D1.82.D1.8C_.D0.B1.D0.BE.D0.BB.D1.8C.D1.88.D0.B5_.D0.B7.D0.B0_.D0.BE.D0.B4.D0.B8.D0.BD_.D1.81.D0.BF.D1.80.D0.B8.D0.BD.D1.82:_.D0.B2.D1.8B.D1.81.D0.B2.D0.BE.D0.B1.D0.BE.D0.B6.D0.B4.D0.B0.D0.B5.D0.BC_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D1.8B_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.87.D0.B8.D0.BA.D0.BE.D0.B2_.D1.81_.D0.BF.D0.BE.D0.BC.D0.BE.D1.89.D1.8C.D1.8E_Kubernetes-.D0.BF.D0.BB.D0.B0.D1.82.D1.84.D0.BE.D1.80.D0.BC.D1.8B_Deckhouse">#Константин Аксенов из Флант</a>.</li></ul>
<p>В докладе Константина Аксенова была любопытная схема трассировки от технологических преимуществ к показателям бизнеса (производительность команды и компании) и благополучию персонала (удовлетворение от работы, уменьшение выгорание, увеличение продуктивности), я ее запомню как способ объяснять преимущества технических решений для бизнеса.
</p><p>Рассказ о конференции я начну со своего доклада, а далее пойду по порядку. Помимо докладов, было два круглых стола: «Разработка и DevOps с использованием ИИ» и «Параллельный импорт помогает или тормозит технологический суверенитет?» с любопытными мыслями, но пересказывать их — безнадежно, разговор шел причудливыми путями.
</p>
<h1><span class="mw-headline" id=".D0.9C.D0.B0.D0.BA.D1.81.D0.B8.D0.BC_.D0.A6.D0.B5.D0.BF.D0.BA.D0.BE.D0.B2._.D0.93.D0.BE.D1.82.D0.BE.D0.B2.D1.8B_.D0.BA_.D0.B8.D0.B7.D0.BC.D0.B5.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F.D0.BC:_.D0.B0.D0.B4.D0.B0.D0.BF.D1.82.D0.B8.D0.B2.D0.BD.D0.B0.D1.8F_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B0_.D0.BA.D0.B0.D0.BA_.D1.87.D0.B0.D1.81.D1.82.D1.8C_.D0.98.D0.A2-.D1.81.D1.82.D1.80.D0.B0.D1.82.D0.B5.D0.B3.D0.B8.D0.B8">Максим Цепков. Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии</span></h1>
<p>Мой доклад — обобщение 25-летнего опыта Enterprise-разработки. Он говорит о том, что потребности в срочных изменениях в ИТ-ландшафте появились не в 2022 и даже не в 2020, они были всегда. И часто их решением является временный модуль, который решает проблему. Его часто делают, срезая углы и на ручной интеграции, но решение задач бизнеса он обеспечивает. Дальше этот модуль дальше живут своей жизнью, и тут возможны два сценария: либо надо доработать функционал, интеграцию и эргономику, чтобы в системе появился еще один небольшой модуль, либо в .тот модуль постепенно переводят функционал какой-либо из legacy систем, и тогда он становится полноценной системой. Договариваться о сценарии стоит сразу: в острой ситуации бизнес восприимчевее к изменениям.
</p><p>Важно правильно оценивать такой подход. Этот путь не забивание костылей, а пилоты с дальнейшим развитием. Верная метафора: гибкие ростки, которые найдут дорогу, а не тростник на ветру.
</p>
<div class="floatright"><a href="https://mtsepkov.org/index.php?title=%D0%A4%D0%B0%D0%B9%D0%BB:AdaptiveArch-HPS-2023-Tsepkov-CUSTIS.pdf&page=5" class="image"><img alt="AdaptiveArch-HPS-2023-Tsepkov-CUSTIS.pdf" src="https://mtsepkov.org/images/thumb/4/42/AdaptiveArch-HPS-2023-Tsepkov-CUSTIS.pdf/page0005-600px-AdaptiveArch-HPS-2023-Tsepkov-CUSTIS.pdf.jpg" width="600" height="338" /></a></div>
<p>Какой же должна быть архитектура ИТ-ландшафта, чтобы такое развитие было возможным и эффективным? Для этого надо следовать следующим принципам:
</p>
<ul><li> Согласиться, что сложный мозаичный ИТ-ландшафт разномасштабных решений — норма. Сейчас так и есть, но я помню время, когда целевой картиной представлялось комплексное решение от одного вендора, быть может с дополнительными модулями.</li>
<li> Выделение в системах двух уровней: базы основных исполнительных систем, поверх которого распологаться специализированные рекомендательные и управляющие системы.</li>
<li> Постепенное развитие временных и промежуточных решений в полноценные, наращивая функционал: сначала база, реализующая основные сценарии и позволяющая особые случаи обработать вручную, а затем автоматизируем их по необходимости.</li>
<li> В системах должна быть устойчивая интеграция для создания и изменения документов и справочников, тоже двух уровней: через ручную загрузку-выгрузку и через API. Ручные загрузки и выгрузки часто могут служить основой для временной интеграции, позволяя преобразовывать данные на Excel.</li>
<li> Очень помогает сквозной мониторинг уровня бизнес-процессов для обеспечения целостности. Современные средства позволяют его сделать в мозаичном ландшафте и подключать новые компоненты.</li>
<li> Желательна база для быстрой разработки: документооборот, учёт, интерфейсы naked objects. Это могут быть low-code решения или решения на базе какого-то фреймворка.</li></ul>
<p>И дальше в докладе были кейсы, которые иллюстрировали такой подход. Многие из них — достаточно старые, и в перспективе нескольких лет можно оценивать, что созданные решения не были времянками, на их основе действительно выросли полноценные системы.
</p><p>Презентация — на странице доклада <b><a href="https://mtsepkov.org/%D0%93%D0%BE%D1%82%D0%BE%D0%B2%D1%8B_%D0%BA_%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%D0%BC:_%D0%B0%D0%B4%D0%B0%D0%BF%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%BA%D0%B0%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D1%8C_%D0%98%D0%A2-%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8_(HPS-2023)" title="Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии (HPS-2023)">Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии (HPS-2023)</a></b>.
</p>
<h1><span class="mw-headline" id=".D0.9E.D0.BB.D1.8C.D0.B3.D0.B0_.D0.9B.D0.B0.D1.82.D1.8B.D0.BF.D0.BE.D0.B2.D0.B0_.D0.B8.D0.B7_.D0.A1.D1.83.D1.80.D0.B3.D1.83.D1.82.D0.BD.D0.B5.D1.84.D1.82.D0.B5.D0.B3.D0.B0.D0.B7.D0.B0._.D0.A2.D1.80.D0.B0.D0.BD.D1.81.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D1.8F_.D0.B2_.D1.81.D1.82.D1.80.D0.B5.D0.BC.D0.BB.D0.B5.D0.BD.D0.B8.D0.B8_.D0.BA_.D0.98.D0.A2-.D1.81.D1.83.D0.B2.D0.B5.D1.80.D0.B5.D0.BD.D0.B8.D1.82.D0.B5.D1.82.D1.83._.D0.A7.D1.82.D0.BE_.D0.BD.D0.BE.D0.B2.D0.BE.D0.B3.D0.BE.3F">Ольга Латыпова из Сургутнефтегаза. Трансформация в стремлении к ИТ-суверенитету. Что нового?</span></h1>
<p>В Сургутнефтегазе 30 лет формировался интегрированный ИТ-ландшафт на основе SAP. И это — не только софт, это еще и соответствующие методологии: стандарты, порядок управления проектами на PMBOK и ASAP, и управления изменениями на основе ITIL, проектно-методические группы по направлениям деятельности, порядок выполнения работ по заявкам.
</p><p>Сейчас есть задача трансформации, ухода с SAP, и сделать это надо достаточно быстро. Поэтому монолит поделили на 18 проектов трансформации, дали полномочия руководителям дорожных карт, а координирует это совет по импортозамещению и архитектурный комитет. Определены принципы — private cloud, kubernetes, devops, релизная политика.
</p><p>Уже выбрано 14 разных решений, на слайде они были. Правда замена ядерного решения на SAP, которое обеспечивает расчет себестоимости — пока не выбрано. Что интересно — 1С в числе выбранных решений нет. Оно было на первом этапе, когда для каждого проекта составляли списки кандидатов, его рассматривали для капстроя, казначейства и чего-то еще наряду с другими решениями. Но дальше был этап, когда они сделали постановки на небольшие контрольные примеры и предложили вендорам реализовать — и получилось, что для 1С нужна разработка с нуля, готового взять нельзя. После этого он отвалился. Следующий этап — системы развернули у себя, настроили интеграцию и провели нагрузочное тестирование.
</p><p>Следующий этап — пилоты, которые, как предполагается, пойдут в промышленную эксплуатацию. Планы были запустить в январе 2024, но есть проблемы с поставкой железа для облака, так что ожидается запуск к лету. Проекты идут параллельно, разработан комплексный план релизов, но запуск в эксплуатацию может идти последовательно, например, кадры и спецодежду тестируют вместе, а запускать будут сначала кадры, а потом — спецодежду. Учатся работать с облаком, раньше надо было просто распределять имеющиеся ресурсы, а сейчас ставят на то. что ресурсы будут постепенно наращиваться по необходимости, и надо чтобы системы мониторинга это поддерживали.
</p>
<h1><span class="mw-headline" id=".D0.A0.D1.83.D1.81.D1.82.D0.B0.D0.BC_.D0.9A.D1.83.D1.80.D0.B0.D0.BC.D1.88.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.93.D0.B0.D0.B7.D0.BF.D1.80.D0.BE.D0.BC_.D0.98.D0.94._.D0.9A.D0.B0.D0.BA_.D0.B8.D0.BD.D1.81.D1.82.D1.80.D1.83.D0.BC.D0.B5.D0.BD.D1.82.D1.8B_.D0.B1.D1.8B.D1.81.D1.82.D1.80.D0.BE.D0.B9_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.BA.D0.B8_.D0.BD.D0.B0_Java_.D0.BC.D0.BE.D0.B3.D1.83.D1.82_.D0.BF.D0.BE.D0.BC.D0.BE.D1.87.D1.8C_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81.D1.83">Рустам Курамшин из Газпром ИД. Как инструменты быстрой разработки на Java могут помочь бизнесу</span></h1>
<p>Рассказ про LowCode инструменты разработки в Java-стеке: Spring Data REST для разработки бэк-энда и Jmix, ранее CUBA Platform jmix.io — единственный full stack framework для web-приложений. Java, Spring — open source, у Jmix — run time open source, плата только за средства разработки. Рассказ был с примерами простых приложений.
</p><p>Spring Data REST — LowCode для бэк-энд Rest API для редактирования записей базы данных: показ коллекций сущностей, фильтрация, в том числе через специальные end point, страницы, точки расширения, метаданные о сущностях ALPS и JSON Schema, JPA, Cassandra, MongoDB и другие базы данных. В примере: описываем класс репозиторий, помечаем аннотациями — и все, есть готовое приложение.
</p><p>Jmix, ранее CUBA Platform, jmix.io — единственный full stack framework для web-приложений. Java и Kotlin, российская разработка. Готовые визуальные компоненты. Безопасность из коробки: аутентификация, авторизация, ролевая модель, keycloak. Мягкое удаление, аудит изменений сущностей. Декларативное описание сущностей бизнес-домена, GUI-дизайнер для редактирование моделей интерфейса. Есть связь с BPMN — Comunda. И дальше пример разработки вместе с бизнес-логикой. И сразу получаем приложение с экраном входя и так далее. В качестве пилота они сделали админку для одного проекта, успешно — и пошли тиражировать.
</p>
<h1><span class="mw-headline" id=".D0.9D.D0.B8.D0.BA.D0.BE.D0.BB.D0.B0.D0.B9_.D0.9A.D1.83.D0.B2.D1.8B.D1.80.D0.BA.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.A0.D0.B0.D0.B9.D1.84.D1.84.D0.B0.D0.B9.D0.B7.D0.B5.D0.BD_.D0.91.D0.B0.D0.BD.D0.BA._.D0.A1.D0.B8.D1.81.D1.82.D0.B5.D0.BC.D0.B0_.D1.80.D0.B0.D1.81.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D1.91.D0.BD.D0.BD.D0.BE.D0.B9_.D0.BF.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.B2.D0.BE.D0.B9_.D0.BE.D0.B1.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.BA.D0.B8_.D0.BF.D0.BB.D0.B0.D1.82.D0.B5.D0.B6.D0.B5.D0.B9_StarkNG">Николай Кувыркин из Райффайзен Банк. Система распределённой потоковой обработки платежей StarkNG</span></h1>
<p>Рассказ про вынос compliance правил проверки платежей проверки платежей в отдельную систему. Исторически была система Stark — рабочее место compliance-офицера, по мере того, как платежей становилось больше, в нее вписывали автоматы обработки и принятия решений в виде хранимых процедур на MS SQL. Сложность и число платежей возрастали, и в какой-то момент решили вынести логику в отдельную систему StarkNG. Требования — Прозрачность и наблюдаемость, легкая модификация правил — схемы отмывания меняются. Ретро-тесты: проверка на старых платежах при изменении системы правил. Обновление без простоя, легкое масштабирования. И, что не тривиально, бизнес-логика — на python, потому что его понимают data scientist, а именно они ведут анализ и вырабатывают правила.
</p><p>Дальше были архитектурные схемы решения. Обработка платежа: получение данных, обогащение по разным базам (списки рисковых лиц и так далее), обработка моделью и ответ: одобрить, запретить или отправить на ручную обработку. Платформа обеспечивает получение платежей и обогащение. а сама модель — stateless. Два кластера: Apache Ignite для выборки из разных списков и Open Search — поиск по текстовым полям, это часто необходимо при обработке валютных платежей (как я понимаю потому, что там часто цепочка платежей через банки-корреспонденты и конечные получатели упакованы в назначении платежа). Apach Active MQ (на него переходят), Activities, Kafka — стандратные технологии, типовой CI/CD, метрики Apache Ignite через jmx-prometheus. Мягкий переход в эксплуатацию: входную очередь дублируют на новую систему и сравнивают результаты по выходной очереди, и когда правила были отлажены — переключили выходную очередь.
</p><p>И был рассказ про две проблемы.
</p>
<ul><li> Массовые платежи одного клиента — система многопоточная, по клиентам есть лимиты, модель — stateless, все лимиты надо поднять на обогащении, а результат модели — сохранить. Поэтому если платежи попали в разные потоки, то возникает ожидание, и для больших клиентов типа Озона, Wildberries, которые раз в пару недель делают десятки тысяч платежей — они забивают все потоки. Сделали отложенную очередь и два счетчика: ClientFlight Counter и LockTime — они обеспечивают откидывание этих платежей.</li>
<li> Split Brain в Apache Ignine — кластер разваливается на два кластера, которые независимы — случается, если кластер по двум дата-центрам и нарушилась связь. И в момент развала платежи клиента пошли в разные половинки, то каждый платеж пройдет. В каждой половинке кластера к кэша полный набор партиций. Есть вероятность split brain для разных нод, и при 7+ нод — вероятность равна нулю. Борьба — только через логи, обработку операций, megre данных не работает (было 100, в одной списали 40, в другой — 50 — merge сделать нельзя, надо выполнить операции.</li></ul>
<p>Разработка была инициирована из-за санкций, импотрозамещение. И решение получилось не хуже зарубежных аналогов, потому что владеют исходным кодом.
</p>
<h1><span class="mw-headline" id=".D0.9B.D0.B5.D0.B2_.D0.9F.D0.B0.D0.BB.D0.B5.D0.B9_.D0.B8.D0.B7_WebmonitorX._API_Security_.D0.B8_API_Management._.D0.A7.D1.82.D0.BE_.D0.B1.D1.8B.D0.BB.D0.BE_.D0.B4.D0.B0.D0.BB.D1.8C.D1.88.D0.B5.3F">Лев Палей из WebmonitorX. API Security и API Management. Что было дальше?</span></h1>
<p>Обзорный доклад про API security. Рост API. Среды разработки на разработку API не ориентированы, хотя докрутить можно. Типовые проблемы, как всегда, связаны с человеческим фактором и которые, по-моему, свойственны любой разработке: отсутствие описаний, swagger можно порождать и контролировать, но не делают; на тесты на производительность нет времени; не делают мониторинг; считают, что раз api не публичный — можно не думать о безопасности, а это заблуждение, есть злоумышленники внутри, а еще внутреннее api могут частично прокинуть наружу; срезание углов, когда надо быстро выпустить релиз; не сделали полные тесты после последних исправлений; не убрали временный функционал или тестовую фичу.
</p><p>API и микросервисы. Микросервисы взаимодействуют по API, службы — тоже по API. Ingress Controller — еще одна точка сборки.
</p><p>Service Mesh: Control plane — Data plane. Маппинг протоколов к приложению, управление приложениями. Новый уровень абстракции — контейнеризация.
</p><p>В докладе — несколько слайдов с полезными ссылками. Open source системы для api: kong, gravitee.io, wso2 api microgateway. Есть ссылки на рейтинги и сравнения на хабре. Выигрывает gravitee, но он под сложные задачи, требует администрирования.
</p><p>Появился российский nginx — angie pro и Ingress controller ANIC, довольно быстрое обновление. API Firewall — быстро что-то заблокировать. Open source. Reverse proxy на Go, поставляется как контейнер, много чего умеет.
</p><p>Будущее: автоматическое создание swagger по трафику, автоконфигурация API-политик на gateway как тесты и нативная интеграция контекста api security в service mesh и api management, не только валидация.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B0.D1.81.D1.82.D0.B0.D1.81.D0.B8.D1.8F_.D0.9A.D0.B8.D1.80.D0.B8.D0.BB.D0.BE.D0.B2.D0.B0._DataLabs_.D0.9C.D0.B0.D0.B3.D0.BD.D0.B8.D1.82:_.D0.BD.D0.BE.D0.B2.D1.8B.D0.B9_.D1.83.D1.80.D0.BE.D0.B2.D0.B5.D0.BD.D1.8C_.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.8B_.D1.81_.D0.B4.D0.B0.D0.BD.D0.BD.D1.8B.D0.BC.D0.B8">Анастасия Кирилова. DataLabs Магнит: новый уровень работы с данными</span></h1>
<p>Магнит сам для себя является оператором фискальных данных и предоставляет эти услуги другим. А доклад был о том, что обработка чеков дает хорошую информацию для рекламных компаний, гораздо точнее определяя целевую аудиторию, а не работая по площадям. Гораздо лучшую, чем основанную на активности в интернете: человек может смотреть ролики про котиков и бывать на тематических сайтах, даже если кота у него нет, а вот если он регулярно покупает кошачий корм, то кот у него точно есть. А идентификация покупателя идет по дисконтной карте.
</p><p>Правда, для успеха надо уметь формулировать гипотезы о том, кто именно является вашей целевой аудиторией. При этом магнит не только сам проводит подобные компании, но и предоставляет такие возможности другим через сервис Datalabs, в том числе загружая собственные данные из CRM. Но нужна модель покупателя и товара, надо учитывать что какие-то товары покупают периодически, например, если человек только что купил стиральный порошок, то предлагать надо через некоторое время, а не сразу и так далее. У Магнита есть модель для выделения покупателей, склонных к промоакциям, есть модели предсказания покупок. Можно этим пользоваться, можно строить свое. Но в любом случае нужна собственная команда data scientist, которые умеют анализировать данные и создавать ML-модели, это — ограничение. И нужны аналитики, которые умеют переводить задачи от бизнеса на понятный data scientist язык. И бюджет.
</p><p>И в докладе были любопытные примеры успешных кейсов с гипотезами о целевых группах.
</p>
<ul><li> Мужской гель для душа: выбирали женщин, которые покупали подарочные наборы мужчинам за последние 12 месяцев. И не только по целевому бренду и набору, но и по сопутствующим.</li>
<li> Запуск нового продукта по йогуртам: сегмент тех, кто покупал йогурты и сегмент тех, кто часто приходит в магнит. Реклама на тех, кто часто приходит реклама новых продуктов хорошо работает.</li>
<li> Бытовая химия: среди людей, склонных к промо в среднем сегменте (высчитывается); и те, кто НЕ покупали бытовую химию из линеек, не участвующих в розыгрыше, за последний месяц — у них уже есть.</li>
<li> Шоколадные конфеты, увеличение продажи без скидок. Перед праздниками собрали тех, кто совершал набор перед праздниками любых наборов, не только конфет.</li></ul>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D1.82.D0.BE.D0.BD_.D0.91.D0.BE.D1.87.D0.BA.D0.B0.D1.80.D0.B5.D0.B2.2C_.D0.A2.D1.80.D0.B5.D1.82.D1.8C.D1.8F_.D1.81.D1.82.D0.BE.D1.80.D0.BE.D0.BD.D0.B0._.D0.9F.D1.83.D1.82.D1.8C_.D0.B8.D0.BD.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D1.86.D0.B8.D0.BE.D0.BD.D0.BD.D0.BE.D0.B9_.D0.B1.D0.B5.D0.B7.D0.BE.D0.BF.D0.B0.D1.81.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.B2_.D0.BA.D0.BE.D0.BC.D0.BF.D0.B0.D0.BD.D0.B8.D0.B8.C2.A0.E2.80.94_.D0.BE.D1.88.D0.B8.D0.B1.D0.BA.D0.B8.2C_.D0.B7.D0.B0.D0.B1.D0.BB.D1.83.D0.B6.D0.B4.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B8_.D0.BF.D1.80.D0.B5.D0.B4.D1.83.D0.B1.D0.B5.D0.B6.D0.B4.D0.B5.D0.BD.D0.B8.D1.8F">Антон Бочкарев, Третья сторона. Путь информационной безопасности в компании — ошибки, заблуждения и предубеждения</span></h1>
<p>Интересный взгляд на работу с информационной безопасностью через модель Кюблер-Рюсс 5 стадий принятия неизбежного: Отрицание — Гнев — Торг — Депрессия — Смирение. Неожиданно, что для описания ситуации, касающейся рационального принятия решений используется психологическая модель, разработанная для людей, которым надо принять инвалидность или неизлечимую болезнь. Но автору — виднее, он профессионально работает с этими вопросами, и считает модель адекватным описанием.
</p><p>Для начала был обзор угроз, с которыми работает безопасность. Выделяют 4 типа.
</p>
<ul><li> киберкриминалу (RaaS)</li>
<li> высококвалифицированным хактивистам — те, кто через взлом проводит лозунге</li>
<li> радикальный инсайдер — тот, кто готов совершить диверсию при обиде не компанию, в том числе при уходе</li>
<li> продвинутые угрозы (АРТ) — связка со спецслужбами и другими особыми организациями.</li></ul>
<p>Наиболее массовой угрозой является киберкриминал. И тут надо понимать, что это — целая отрасль со своим разделением труда, которая работает по модели RaaS — криминальный софт как услуга. Есть разработчики, который пишет вредносное ПО, например, шифрует данные. Он поставляет это ПО распространителями за комиссию и жертв. Распространители — заражают жертву. Выкуп получают третьи люди, которые торгуются, потом отмывают деньги и пересылают. Они лично друг друга не знают, через форумы и систему репутаций. Арест любого участника не помогает добраться до других. Схему успользуют десятки группировок в мире. И эта схема будет жить независимо от политики, хотя события последнего года ее активизировали просто потому, что ослабили международное сотрудничество в противодействии. Остальные вызовы возникли или обострились с 2022. Под атакой хактивистов может оказаться любая компания, просто потому, что уязвима, независимо от потенциальной выгоды.
</p><p>А дальше был главный тезис автора: работа с безопасностью неизбежна, и ей должна заниматься отдельная структура, не разработчики. Потому что иначе постоянный конфликт интересов будет решаться в ущерб безопасности. А реально надо соблюдать баланс, и принимать решения должен бизнес, так как при проблемах риски падают именно на него. И был рассказ о 5 стадиях принятия ИБ.
</p>
<ul><li> Отрицание: «нам это не надо». Работа — через известные примеры. Colonian pipeline — топливный кризис в США. Банки США в 2022 заплатили 1.2 млрд $. стадия заканчивается, когда руководство осознает неизбежность ИБ, готово принять, быть может в следствии инцидента или по другим причинам.</li>
<li> Гнев: стадия инцидента или внутрикорпоративного конфликта. Почему взломали именно нас? Зачем нам покупать такое дорогое? Тут надо выводить в рациональные аргументы, объяснять. что глупость вероятнее заговора, открыто проводить сравнение вариантов и рисков. Заканчивается, когда риски становятся понятными и эмоциональное противодействие уходит.</li>
<li> Торг. В компаниях часто экономят на маловажном, и ИБ оказывается в этом ряду. Мониторинг сделаем сами на открытом ПО, безопасность сделают наши разработчики. И здесь надо разъяснять, что ИБ — высокотехнологичная отрасль, где нужны профи. Софт же заказывают, не весь делают сами. При этом есть ситуации, когда собственная разработка оправдана, потому что надо что-то экзотическое, или актуальных угроз мало, а профессиональные разработчики есть. Хотя там тоже вопрос со стоимостью владения — ведь методы атак совершенствуются, это надо отслеживать. Перевешивать функции ИБ на ИТ — профи в обоих быть невозможно, потому что там всего очень много. Полезен аудит профи, но надо понимать, как проверять тех, кто проверяет вас. В любом случае экономия на страховке снижает ее эффективность. Стадия заканчивается, когда ИБ выделена как отдельная структура со своим бюджетом.</li>
<li> Депрессия. ИБ появилась, но есть внутреннее ощущение, что все равно не хватит штата, на текущих бизнес-процессах не заработает и так далее. Когда по ИБ есть документы, которые не работают и даже не читают. В этой ситуации важно делать лишь нужное, не делать документ ради документов. Не защищать все на 100 %, надо оказаться не самым низковисящим фруктом. Аутсорсинг и аутстаффинг дешевле, выгоднее, а иногда эффективнее. Достаточно директора по безопасности part time. Работать не по площади, а начиная со слабыми звеньев. Выход в следующую стадию — когда ИБ начинает реально влиять на процессы.</li>
<li> Смирение. ИБ начало действовать. Зачастую без плана и в рамках хоть какого-нибудь бюджета. И тут нужны roadmap, оценка рисков, business impact analysis, больше консультаций и внешних оценок аудиторов. Целевое идеальное состояние — Zero trust — все под контролем, идут только суперкрупные, а доходят единицы. Стадия завершается выходом в планомерное развитие.</li></ul>
<p>Таким образом, после смирения наступает конечное состояние — когда ИБ становится реально работающей структурой. При этом, однако, путь не является однонаправленным, запросто может произойти откат на любую из стадий, например, в ходе очередной компании за всеобщую экономию или после существенного инцидента.
</p>
<h1><span class="mw-headline" id=".D0.A5.D0.B0.D1.80.D0.B8.D1.82.D0.BE.D0.BD_.D0.9D.D0.B8.D0.BA.D0.B8.D1.88.D0.BA.D0.B8.D0.BD_.D0.B8.D0.B7_Secure-T._.D0.9F.D0.BE.D1.81.D0.BB.D0.B5.D0.B4.D1.81.D1.82.D0.B2.D0.B8.D1.8F_.D0.BD.D0.B8.D0.B7.D0.BA.D0.BE.D0.B9_.D0.BE.D1.81.D0.B2.D0.B5.D0.B4.D0.BE.D0.BC.D0.BB.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.BF.D0.B5.D1.80.D1.81.D0.BE.D0.BD.D0.B0.D0.BB.D0.B0_.D0.B8_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81_.D0.B0.D0.B2.D1.82.D0.BE.D0.BC.D0.B0.D1.82.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D0.B8_.D1.81_.D1.86.D0.B5.D0.BB.D1.8C.D1.8E_.D0.BA.D0.BE.D0.BD.D1.82.D1.80.D0.BE.D0.BB.D1.8F_.D0.B2.D0.BE.D0.B7.D0.B4.D0.B5.D0.B9.D1.81.D1.82.D0.B2.D0.B8.D1.8F_.D1.87.D0.B5.D0.BB.D0.BE.D0.B2.D0.B5.D1.87.D0.B5.D1.81.D0.BA.D0.BE.D0.B3.D0.BE_.D1.84.D0.B0.D0.BA.D1.82.D0.BE.D1.80.D0.B0_.D0.BD.D0.B0_.D0.98.D0.91">Харитон Никишкин из Secure-T. Последствия низкой осведомленности персонала и процесс автоматизации с целью контроля воздействия человеческого фактора на ИБ</span></h1>
<p>Основной тезис автора в том, что подавляющее большинство инцидентов происходят в результате человеческого фактора. Включая проникновение во внутреннюю сетку: это делают методами социальной инженерии, не взламывают защищенный периметр, а делают, чтобы изнутри сами открыли ворота врагу.
</p><p>Было несколько примеров
</p>
<ul><li> В 2019 на территории штата Гавайи была ядерная тревога, через 50 минут отменили. Сотрудник центра мониторинга ядерных угроз, и на фото на стикере был виден пароль от учебной записи сотрудника — кто-то залез и по приколу нажал кнопку. А сразу написать, что ложная тревога не смогли, потому что оповещение было через твитер, сотрудник от стресса забыл пароль.</li>
<li> Предприятие пищевой продукции в России — в сеть была выставлена запись администратора, подобрали пароль. Зашифровали данные, предприятие стояло 3 часа. Потребовали заплатить 500$ но платить тут бесполезно — как правило никто не расшифрует.</li>
<li> Крупный бельгийский банк. Сделали фишинг от имени директора, сделайте быстрый перевод 70 млн евро — и бухгалтер выполнила.</li>
<li> В России от имени ЦБ письмо в compliance-отделы банков с увеличить деньги на депозитах в ЦБ с реквизитами — часть банков исполнила, не обратив внимания на странные реквизиты.</li></ul>
<p>Автор предлагает бороться с этим с помощью обучения, с регулярным повторением и контролем. Законодатели — тоже, есть законы об обязательном обучении.
</p>
<ul><li> Очные лекции и тренинги, это довольно дорого.</li>
<li> Курс в СДО, это дешевле, но надо, чтобы СДО была, а курсы — проходили и была обратная связь.</li>
<li> Плакаты по офису — это работает, хотя звучит тупо: меняй пароль, проверяй адресата сообщение и так далее.</li>
<li> Проверять с помощью фишинга — письма сотрудникам. Есть как услуга, и можно самим, разобраться непросто, но за пару часов можно.</li></ul>
<p>Мне лично это не кажется эффективным, потому что проколы — очевидные: не пиши пароль на стикерах, не переводи деньги по первому требованию даже начальника, не выставляй а интернет админку, а если выставил — меняй пароли. Это как вводить обязательное обучение правилам движения для пешеходов, рассказывая про очевидные вещи, например. о правилах перехода улицы. Люди — знают, только не выполняют. Впрочем, я бы согласился, если бы была статистика, которая показывала бы эффективность обучения. А ее я в подобных докладах пока не слышал. Более того, автор приводит примеры, которые опровергают, у них сотрудник, который профессионально занимался противодействием фишингу, разрабатывал средства, сам на него попался, открыл ссылку — потому что суббота вечер, а он спешил. И в целом у них статистика, что есть две группы риска, и это — не бухгалтеры, а топы и ИТ. Топы считают, что они слишком заняты, чтобы об этом думать, поэтому открывают ссылки не глядя, а виновато у них всегда ИТ. А ИТ — для них надо правильно оформить фишинг, например, замаскировав на сообщение от miro и аналогичных систем, и тогда они тоже доверяют…
</p><p>В в целом в России с безопасностью решения хорошие, и это — не только Касперский. Берите отечественных вендоров, и они точно останутся с вами.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.B7.D0.B0.D0.BC.D0.B0.D1.82_.D0.96.D1.83.D1.80.D1.81.D0.B5.D0.BD.D0.BE.D0.B2_.D0.B8_.D0.94.D0.BC.D0.B8.D1.82.D1.80.D0.B8.D0.B9_.D0.90.D1.81.D0.BB.D0.B0.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A0.D0.BE.D1.81.D1.82.D0.B5.D0.BB.D0.B5.D0.BA.D0.BE.D0.BC._.D0.A0.D0.B0.D0.B4.D0.B8.D0.BA.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D1.83.D1.81.D0.BA.D0.BE.D1.80.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D0.B2.D0.BA.D0.B8_.D0.B1.D0.B8.D0.B7.D0.BD.D0.B5.D1.81_.D1.86.D0.B5.D0.BD.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D1.87.D0.B5.D1.80.D0.B5.D0.B7_.D0.BF.D0.BE.D1.81.D1.82.D1.80.D0.BE.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BA.D0.BE.D0.BD.D0.B2.D0.B5.D0.B9.D0.B5.D1.80.D0.B0_.D0.BD.D0.B5.D0.BF.D1.80.D0.B5.D1.80.D1.8B.D0.B2.D0.BD.D0.BE.D0.B9_.D0.BF.D0.BE.D1.81.D1.82.D0.B0.D0.B2.D0.BA.D0.B8._.D0.9E.D0.BF.D1.8B.D1.82_.D1.81.D0.BE.D0.B7.D0.B4.D0.B0.D0.BD.D0.B8.D1.8F_.D1.80.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F_.D0.91.D0.B0.D0.B7.D0.B8.D1.81">Азамат Журсенов и Дмитрий Асланов из Ростелеком. Радикальное ускорение доставки бизнес ценности через построение конвейера непрерывной поставки. Опыт создания решения Базис</span></h1>
<p>Система Базис — унифицированный CRM и биллинг. Делают 250 разработчиков, половина внутри, остальное — подрядчики. В условиях постоянного развития, появления новых продуктов.
</p><p>Основная задача ускорить доставку с полугода-года до месяца. Ее декомпозировали.
</p>
<ul><li> Единая система управления требованиями и задачами</li>
<li> Сильный состав Product Owner</li>
<li> Гибкое управление мощностью</li>
<li> Fast Track — быстрая доставка, в том числе для неожиданно появляющихся требований</li>
<li> Квартальное планирование — фиксация договоренностей с бизнесом</li>
<li> Релизный календарь и управление синхронизацией. Не раз в полгода, как было. Цель 2-4 недели для релизов без жесткой фиксации, так как окна ограничены.</li>
<li> Критерии качества для выкатки на прод: дефектов не больше чем порога, отсутствие критичных дефектов</li>
<li> Отдельное требование: процессы продажи в comunda не должны переходить через релиз, так как некоторые из продаж идут долго.</li></ul>
<p>Что для этого нужно? Структура команд и компонент, организовать планирование, сделать средства доставки со стендами для тестов и нагрузки. И еще разобрать накопившийся от прошлого большой бэклог.
</p><p>Новая структура команд. Были фиксированные команды и единственный способ маневра — переход человека из одной команды в другую с онбордингом в новой команде. Что сделали?
</p>
<ul><li> Крупная команда — фича-тимы, могут брать любые задачи</li>
<li> Кочующие сотрудники</li>
<li> Аутсорсеры, которые привлекаются по необходимости.</li></ul>
<p>В результате достигли 30 % уровня балансировки на любой команде — это маневр мощностью.
</p><p>Квотирование мощности команд: 65 % на основные задачи бэклога, 10 % — отпуска и болезни, эмпирически вычисленная цифра, 10 % на развитие и техдолг, 15 % дефекты с промышленной среды. Это распределение по умолчанию, оно плавает, например, число дефектов зависит от уровня стабилизации продукта.
</p><p>Ранее внедряли SAFe, но в некоторый момент внедрение остановили, начали делать гибридную конструкцию, добавляя Capacity Management, а из SAFe взяли только нужное. Квартальный pi-planing остался, но формат в результате сильно изменился, вместо 2-дневной сессии — 30 минутное окончательное увязывание планов.
</p><p>На входе в pi-планирование — ролевая модель и мощность команд с учетом участия: новички в первый месяц 0, админы 50 % и так далее. Загрузка на планировании с точностью 10 % — точнее не надо, так как все равно будут изменения. Результат pi-плана — Цели релиза, включая тех.долг и план релизов внутри квартала. Ретро в конце квартала — что достигли, как попали в оценки. Обязательно ведут списание трудозатрат на задачи и анализ в Power BI.
</p><p>Конвейер задачи: Исследования → Оценка (мин.ресурсами и в оптимизме) → PI-план + разработка → Отгрузки. Оценку надо сделать быстро и без обсуждения всей командой, для этого постепенно выделились типовые задачи, к этому шли постепенно.
</p><p>Инструментарий.
</p>
<ul><li> Оценки — это отдельный процесс в jira</li>
<li> Система для ведения состава команд, %занятости и роли</li>
<li> Планировщик, который позволяет распределять задачи по спринтам, сопоставляет с мощностью.</li>
<li> Гант по релизам</li>
<li> Синхронизация релизов на планировании — плагин в Jira, туда завели все компоненты, в том числе от внешних подрядчиков с интеграцией с их таск-трекерами или вручную.</li></ul>
<p>Результаты
</p>
<ul><li> Стабилизация релиза от 13 до 3 итераций, 1.5 недели</li>
<li> Не успели — переносим задачу, сырое — не льем.</li>
<li> Гибкость команд</li>
<li> Максимум тестов на средах разработки</li>
<li> Поэтапная отгрузка — feature toggle, ролью или продуктом</li>
<li> Бэклог 1500 -> 300</li>
<li> Время доставки 6м — 3w</li>
<li> SLA дефектов</li>
<li> PI plan — 2d — 20 min</li>
<li> Квартальный контракт 95 % — 55 %</li>
<li> Рост производительности 1.8</li></ul>
<p>Не все идеально. Есть команды с большим онбордингом. Много корректировок внутри периода, но сейчас это считают нормальным, научились с этим работать. Есть лишняя аналитика в будущее, которая протухает.
</p><p>Есть задача импортозамещения jira, в эту сторону начали работать. Смотрели много продуктов, пока смотрят на собственное решение Ростелекома — Яга. Kaiten — смотрели, но порекомендовать не могут.
</p><p>Я замечу, что реорганизация и достигнутые результаты — впечатляют. Но вот интересно, если бы на входе принять простое решение: «не успели — переносим задачу, сырое — не льем», то, возможно, этого было бы достаточно для сокращения времени стабилизации релиза и, как следствие, для достаточного увеличения их частоты? Потому что понятно, что если релиз стабилизируется 13 итераций, то часто такие релизы носить нельзя, а если всего 3 — то можно…
</p>
<h1><span class="mw-headline" id=".D0.9B.D0.B5.D0.B2_.D0.A5.D0.B0.D0.BA.D0.B8.D0.BC.D0.BE.D0.B2_.D0.B8.D0.B7_Wildberries._.D0.A1.D0.BA.D0.B0.D0.B7_.D0.BE_.D1.80.D1.83.D0.BB.D0.B5.D0.B2.D0.BE.D0.BC_.D0.B8_.D0.BF.D1.80.D0.BE.D1.80.D0.B5.D1.85.D0.B0.D1.85_.D0.BD.D0.B0_.D0.BF.D0.B8.D0.B4.D0.B6.D0.B0.D0.BA.D0.B5._.D0.9A.D0.B0.D0.BA_.D0.B7.D0.B0.D1.89.D0.B8.D1.82.D0.B8.D1.82.D1.8C_kubernetes">Лев Хакимов из Wildberries. Сказ о рулевом и прорехах на пиджаке. Как защитить kubernetes</span></h1>
<p>Мне понравилась фраза Льва, когда он рассказывал о себе: «DevOps — не работа, а состояние души».
</p><p>Kubernetes — как ядро linux. Это базовая технология, которая не очень самостоятельная. Чтобы работать безопасно — надо настроить достаточно много, в том числе сторонних программ. B дальше был рассказ о различных уязвимостях, которые требуют грамотного конфигурирования, а по умолчанию они открыты: создавали kubernetes разработчики для разработчиков.
</p><p>Дальше у меня телеграфная запись рассказа, она явно неполная и, скорее, для меня самого.
</p>
<ul><li> Уязвимая конфигурация подов — потому что по умолчанию поды конфигурирует любой. Контейнер — не VM, изоляция идет средствами ОС, и есть набор механизмов: linux namespaces, capabilities и другие.</li>
<li> Опасные разрешения: cap_sys_admin — монтируем файлы, в том числе host — и дальше можем править, cap_net_raw — перехват и замена трафика, cap_sys_module — ставим свои модули</li>
<li> Через конфигурацию можно отключить изоляцию, включить привилегированный режим контейнера, заставить разместить под на мастере, и еще игнорировать запрет админа на мастер, а потом подключить себе файловую систему host и начать работать с файлами.</li>
<li> Выводы: не запускать privileged, root недопустим, и разрешение недопустимо</li>
<li> Как контролировать: OPA gatekeeper, Kyverno. Есть и другие. Если gatekeeper знаком — можно им, kyverno проще, yaml. Для них есть настройки по умолчанию: cis benchmark, pod security standard</li></ul>
<p>Supply chain атаки.
</p>
<ul><li> целостность образов, которые стартуют — механизм подписи образов как часть деплоя cosign, notary, kyverno уже умеет</li>
<li> уязвимости библиотек — откуда они тянутся.</li>
<li> уязвимости open source продуктов</li></ul>
<p>Для контроля — Software bill of materials — список зависимостей SBOM — можно скормить Tryvy-сканеру или другому. Living of Land — атака с использованием легитимного ПО, а в нем есть дыры, поэтому рекомендуют на проде использовать облегченные образы.
</p><p>Роли
</p>
<ul><li> выключить автомаунт сервисных токенов</li>
<li> принцип наименьших полномочий</li>
<li> RoleBindings — только у доверенных систем</li>
<li> избегать роли cluster admin</li>
<li> RBAC аудит</li>
<li> контроль за ненужными ролями и аккаунтами, в том числе для сервисов</li>
<li> политики — настраиваем, и еще проверяем Admission controller</li></ul>
<p>Хранение секретов. В кубе — может быть небезопасно. Vault никто не отменял, но главное — не переусердствовать, иначе разработчики сделают свои дырки, типа пароля в текстовом файле, потому что все соблюсти будет не реально.
</p><p>Authentification — authorisation — admission control
</p>
<ul><li> не использовать authentification по сертификатам — их нельзя отзывать</li>
<li> двухфакторная авторизация</li>
<li> не использовать сервисные аккаунты для подключения извне, надо — выпишете короткоживущий токен</li>
<li> конфигурация железа: dev и prod — разные кластеры и др. Service Mesh можно попробовать — но дорого в прогреве.</li></ul>
<p>Не забывайте поглядывать за актуальными CVE (база данных уязвимостей) — не только когда кластер поставили.
</p><p>Есть сканеры, которые могут собрать все настройки в системе и выдать уязвимости и рекомендации.
</p>
<h1><span class="mw-headline" id=".D0.9A.D0.BE.D0.BD.D1.81.D1.82.D0.B0.D0.BD.D1.82.D0.B8.D0.BD_.D0.90.D0.BA.D1.81.D0.B5.D0.BD.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.A4.D0.BB.D0.B0.D0.BD.D1.82._.D0.9A.D0.B0.D0.BA_.D1.83.D1.81.D0.BF.D0.B5.D0.B2.D0.B0.D1.82.D1.8C_.D0.B1.D0.BE.D0.BB.D1.8C.D1.88.D0.B5_.D0.B7.D0.B0_.D0.BE.D0.B4.D0.B8.D0.BD_.D1.81.D0.BF.D1.80.D0.B8.D0.BD.D1.82:_.D0.B2.D1.8B.D1.81.D0.B2.D0.BE.D0.B1.D0.BE.D0.B6.D0.B4.D0.B0.D0.B5.D0.BC_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D1.8B_.D1.80.D0.B0.D0.B7.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.87.D0.B8.D0.BA.D0.BE.D0.B2_.D1.81_.D0.BF.D0.BE.D0.BC.D0.BE.D1.89.D1.8C.D1.8E_Kubernetes-.D0.BF.D0.BB.D0.B0.D1.82.D1.84.D0.BE.D1.80.D0.BC.D1.8B_Deckhouse">Константин Аксенов из Флант. Как успевать больше за один спринт: высвобождаем ресурсы разработчиков с помощью Kubernetes-платформы Deckhouse</span></h1>
<p>Еще один доклад про kubernetes, продолжающий предыдущий. В докладе, помимо фактуры — очень интересная схема трассировки от технологических преимуществ к показателям бизнеса (производительность команды и компании) и благополучию персонала (удовлетворение от работы, уменьшение выгорание, увеличение продуктивности).
</p><p>Флант — первый сертифицированный поставщик kubernetes в России, и № 1 контрибьютор в России. Deckhouse — 6 лет эксплуатации, более 1 млн кластеров.
</p><p>Контейнеры. Похожи на vm, но без виртуализации железа и ОС снаружи — сильно меньше ресурсов и размер меньше. Когда такой способ стал распространенным, появилась задача управления контейнерами на большом количестве серверов, системы оркестрации контейнеров. Их несколько, но самый популярный — kubernetes, за ним — open shift.
</p><p>Бизнес видит прямые и косвенные преимущества контейнеризации: рост эффективности, уменьшение стоимости, сокращение цикла разработки, была ссылка на исследования. Связь очевидна далеко не со всеми показателями, но тут как раз начинает работать схема: мы получаем скорость доставки приложений, гибкость инфраструктуры, которые дают производительность и надежность. А это, в свою очередь, влияет на бизнес-показатели и на благополучие персонала, например, надежность снижает беспокойство.
</p><p>Практики обеспечения надежности.
</p>
<ul><li> Отказоустойчивость — заложена. Контроллер компонентов следит за нужным количеством узлов и так далее, по описанию</li>
<li> Доступность — Холодный резерв и горячий резерв, кластеры и так далее. Восстановление после аварии</li></ul>
<p>Любую систему можно сломать и использовать неправильно. Но Kubernetes многое гарантированно восстанавливает после аварии. Скрипт разработчика удалил по ошибке worker-узлы кластера в продакшн конфигурации, потому что в одном каталоге лежали разные конфиги. Но есть декларативное описание целевого состояния — и продакшн он восстановился.
</p><p>Когда можно быстро откатиться — разработчики не боятся накатывать изменения на прод.
</p><p>Гибкая инфраструктура. Облачные вычисления растят ключевые показатели и благополучие продукта. Cloud smart — свобода использования окружения. Единая платформа с единым интерфейсом и настройками kubernetes.
</p><p>Артефакт — манифесты + образы. Разработчик не знает, где будет запущено, это делает платформа. Очень частый кейс: клиенты сталкиваются с проблемой роста — черные пятницы и распродажи в ритейле. Многие используют собственные датацентры, посчитали что так дешевле. Пришел пик, железа не хватает — и можно поднять часть подов в публичном облаке, а после окончания пика — отказаться. Но надо заранее подготовить сеть и возможность. Если без публичного облака — мы вынуждены держать запас по железу, или сворачивать тестовые и разработческие стенды на этот период. Инфраструктура должна снимать ограничения, а не ставить заборы. Без привязки к конкретному облаку. И быстрая конфигурация — на железе или в облаке на разных типах инстансов.
</p><p>Платформенный подход: для команды разработки можно просто получить все инструменты, можно переиспользовать готовые компоненты, минимум накладных расходов. Platform Engineering — в топ-10 по Gartner. Reusable component, developer tools, self-service developer portal. Пример от Nike: Платформа позволяет выделить нужные ресурсы БЕЗ механизма заявок, по одной кнопке.
</p><p>Основная проблема kubernetes — сложность технологии. Там надо много конфигурировать, чтобы сделать адекватно вашим задачам. Разъезжаются конфигурации кластеров, поддержка многих систем. Проблема отсутствия экспертизы и необходимого опыта, сложность найма специалистов. При этом интенсивное развитие, в год 3-4 релиза и патчи.
</p><p>Пример. Автомасштабирование — из коробки его нет. Есть open source компоненты. по cpu и памяти — metric servers, если еще по числу запросов и длинне очередей — свои средства. И таких вопросов — много. И для каждого — свои компоненты. Multicloud — всем нужен, но он увеличивает и сложность. Решают эту проблему kubernetes платформы, которые нужные свойства добавляют из коробки. Такие как deckhouse.
</p>
<h1><span class="mw-headline" id=".D0.90.D1.80.D1.82.D0.B5.D0.BC_.D0.9A.D0.B0.D0.BB.D0.B5.D0.B4.D0.B8.D0.BD_.D0.B8.D0.B7_.D0.91.D0.B8.D0.BB.D0.B0.D0.B9.D0.BD._.D0.9B.D0.B8.D0.B4.D0.B5.D1.80.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D0.BE_.D0.BC.D0.B5.D1.82.D0.BE.D0.B4.D1.83_.D0.BD.D0.B0.D0.B4.D0.B5.D0.B6.D0.BD.D0.BE.D0.B9_.D0.B1.D0.B0.D0.B7.D1.8B.C2.A0.E2.80.94_.D0.BA.D0.B0.D0.BA_.D1.8D.D1.84.D1.84.D0.B5.D0.BA.D1.82.D0.B8.D0.B2.D0.BD.D1.8B.D0.B9_.D0.BF.D1.80.D0.BE.D1.86.D0.B5.D1.81.D1.81_.D1.80.D1.83.D0.BA.D0.BE.D0.B2.D0.BE.D0.B4.D1.81.D1.82.D0.B2.D0.B0_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B_.D0.B2_.D1.83.D1.81.D0.BB.D0.BE.D0.B2.D0.B8.D1.8F.D1.85_.D0.BE.D0.B3.D1.80.D0.B0.D0.BD.D0.B8.D1.87.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.BE.D0.B2">Артем Каледин из Билайн. Лидерство по методу надежной базы — как эффективный процесс руководства команды в условиях ограниченных ресурсов</span></h1>
<p>Лидерство — искусство оказывать влияния на людей для достижения групповых целей. В докладе выделено два известных вида лидерства: классическое и трансформационное, и им противопоставлено лидерство надежной базы — подход, который сформулировал Джордж Колризер.
</p><p>Я, пожалуй, помещу тут пару слайдов из его презентации, которые раскрывают понятие и продолжу конспект.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png" class="image"><img alt="HPS-2023-Каледин-1.png" src="https://mtsepkov.org/images/thumb/d/d4/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png/500px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png" width="500" height="278" srcset="https://mtsepkov.org/images/thumb/d/d4/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png/750px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png 1.5x, https://mtsepkov.org/images/thumb/d/d4/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png/1000px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-1.png 2x" /></a></div>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png" class="image"><img alt="HPS-2023-Каледин-2.png" src="https://mtsepkov.org/images/thumb/b/b5/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png/500px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png" width="500" height="287" srcset="https://mtsepkov.org/images/thumb/b/b5/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png/750px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png 1.5x, https://mtsepkov.org/images/thumb/b/b5/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png/1000px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-2.png 2x" /></a></div>
<p>Зачем нужно лидерство? Объединение команды для достижения целей и передача ответственности. Но в жизни все равно люди увольняются, задачи не закрываются в срок, возникают конфликты. Лидерство по методу надежной базы это решает.
</p><p>Основа — безопасность и защищенность, которую должен создать лидер. Сотрудник должен быть уверен, что его действия не вызовут эмоциональной реакции, даже если повлекли какие-то негативные последствия. Лидер должен не повышать голос на сотрудников, не выражать недовольство через эмоции. Уметь сохранять спокойствие в разных ситуациях. И тогда люди не боятся идти на риск, потому что не боятся, что действия получат негативную эмоциональную окраску. Но при этом лидер даст конструктивная обратная связь.
</p><p>Лидер — товарищ, не коуч как в трансформационном подходе и не авторитет или дипломат, как в классике.
</p><p>Второе — лидер принимает и ценит в человеке его интеллектуальность. при подборе сотрудника он видит потенциал, а не только текущие скилы и соответствие ожиданиям. И это игра в долгую.
</p><p>Основной инструмент — активное слушание. Не отдаем приказы, не навязываем идеи. Слушать и понимать — не значит соглашаться, обратная связь нужна, но потом. Не диктовать, чем должны заниматься другие, а влиять на них.
</p><p>Лидер умеет формировать яркие образы, тезисы и цели. У него преобладает позитивное мышление, и он направляет позитивное мышление сотрудников. Тут есть нюанс. Чисто позитивное мышление — верный способ ничего не делать. Надо видеть недостатки, проблемы и вызовы, это — негативное мышление, оно дает стимул. Но дальше негатив надо сбросить и мыслить позитивно, ища решения.
</p><p>Видит пользу — цель, достигаемый результат, и учит сотрудников их видеть. Доверие, не токсичное осуждение, уважение.
</p><p>Поощрение готовности к риску. Самостоятельное принятие решений. Снижение контроля по конкретной задаче за счет прозрачности процессов. Внешняя мотивация, основанная на достижении результата за результатом.
</p><p>Важно предоставлять возможность поддержки, не отстраняться от сотрудников: они могут обратиться, несмотря на забитость календаря.
</p><p>В докладе были опросы о лидерстве в ИТ-блоке Билайн, и это интересно.
</p>
<ul><li> Важные характеристики: спокойствие в стрессе, надежность, прагматичность, мотивация. индивидуальный подход.</li>
<li> Лидеры готовы жертвовать своим временем, даже вне работы.</li>
<li> Участие в диалогах, погружение в проблематику.</li></ul>
<p>Про готовность пожертвовать временем есть важный нюанс. Это не должно быть постоянным, постоянные переработки ведут к выгоранию и другому негативу, а работа должна нравиться. А если задачи все время делают не в срок, значит есть системные причины с компетентностью сотрудников или с потоком нагрузки. не соответствующим ресурсам, и решать это надо системно.
</p>
<div class="floatright"><a href="https://mtsepkov.org/%D0%A4%D0%B0%D0%B9%D0%BB:HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png" class="image"><img alt="HPS-2023-Каледин-3.png" src="https://mtsepkov.org/images/thumb/f/f2/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png/500px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png" width="500" height="266" srcset="https://mtsepkov.org/images/thumb/f/f2/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png/750px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png 1.5x, https://mtsepkov.org/images/thumb/f/f2/HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png/1000px-HPS-2023-%D0%9A%D0%B0%D0%BB%D0%B5%D0%B4%D0%B8%D0%BD-3.png 2x" /></a></div>
<p>И в конце доклада — универсальный todo лист — простые практики. Надо знать с кем работаем, что их мотивирует. Jobs to be done. Его я тоже публикую, тем более, что там был QR-код для всех желающих.
</p><p>И хочу сказать, что концепция — интересная и требует обдумывания. В том объеме, в котором она изложена, я бы это кратко сформулировал в двух тезисах: (1) лидер должен быть взрослым человеком, а не импульсивным ребенком и (2) лидер должен видеть потенциал сотрудников и способствовать его раскрытию. Про первое все очевидно и верно, при этом все мы встречали руководителей, которые ведут себя не слишком по-взрослому. И безусловно важно позитивное и созидательное поведение этого взрослого. А вот со вторым — есть вопрос: не превращается ли лидер при этом в родителя для сотрудников? По идее нет, если он не только сам ведет себя как взрослый, но и учит сотрудников быть взрослыми. Взрослый человек, в том числе, умеет сам выбирать свой путь. Но вот этот аспект не раскрыт. И это — важно, потому что инфантилизм взрослых людей сейчас — относительно распространенное явление, оно вызвало даже такой феномен, как поколение снежинок (<a rel="nofollow" class="external text" href="https://en.wikipedia.org/wiki/Snowflake_(slang)">Snowflakes</a>). Но это — первая реакция, я еще об этом подумаю.
</p>
<h1><span class="mw-headline" id=".D0.90.D0.BD.D0.B4.D1.80.D0.B5.D0.B9_.D0.A1.D1.83.D1.85.D0.BE.D1.80.D1.83.D0.BA.D0.BE.D0.B2_.D0.B8.D0.B7_.D0.9B.D0.B0.D0.B1.D0.BE.D1.80.D0.B0.D1.82.D0.BE.D1.80.D0.B8.D0.BC_.D0.9A.D0.B0.D1.81.D0.BF.D0.B5.D1.80.D1.81.D0.BA.D0.BE.D0.B3.D0.BE._.D0.98.D0.BC.D0.BF.D0.BE.D1.80.D1.82.D0.BE.D0.B7.D0.B0.D0.BC.D0.B5.D1.89.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.BC.D0.B8.D0.B3.D1.80.D0.B0.D1.86.D0.B8.D0.B8_.D0.BE.D0.B1.D0.BB.D0.B0.D0.BA.D0.BE.D0.B2.C2.A0.E2.80.94_.D1.81.D0.BA.D0.B0.D0.B7.D0.BA.D0.B8_.D0.BD.D0.B0_.D0.BE.D0.B1.D0.BE.D1.87.D0.B8.D0.BD.D0.B5">Андрей Сухоруков из Лабораторим Касперского. Импортозамещение и миграции облаков — сказки на обочине</span></h1>
<p>Основной тезис доклада — реальность вовсе не такая, как это сформировано маркетинговыми материалами, где в облака можно переехать относительно легко и просто. В общем-то тезис очевидный, потому что любые маркетинговые материалы сильно преукрашивают реальность. Но доклад интересен тем, что акцентировал внимание на тех камнях, которые на этом пути встречаются и позволял подготовиться к ним.
</p><p>А еще мне понравились заключительные тезисы.
</p>
<ul><li> Облако — не тренд, а один из вариантов. может быть, он вам подходит.</li>
<li> На российские облака переезжать можно, но надо иметь силу духа. Проблемы — будут.</li>
<li> Облака — это классно, но у вас все равно нет выбора, пользуйтесь и ешьте.</li></ul>
<p>Доклад был о собственном опыте проектов по переезду в облако. Первый был 4 года назад, задача — миграция в российское синее облако, подключаются предприятия для реализации товаров. Важный нюанс: провайдер был выбран потому, что он дешевле, пригодность и готовность оценивали облака оценивала на каких-то примерах команда, которая в проекте не участвовала. Проект горит, он уже просрочен на год. При этом формально есть продуманная архитектура, готовое решение, только надо как-то добавить ИБ. И заменить devops аутсорс на свою команду.
</p><p>При этом у руководства была уверенность, что все можно сделать быстро, когда он говорил, что займет год — они не понимали почему.
</p><p>В чем же состоят грабли?
</p>
<ul><li> Реальная инфраструктура в облаке не будет соответствовать документациИ, особенно маркетинговой. Был обещан готовый open shift, и не так, чтобы его не было совсем, но он почти не работал. вообще продукты, предоставляемые облаком, например, базы данных, будут отличаться от оригинальных решений. Сетевых абстракций — больше, логика безопасности — другая и часто даже нет RBAC.</li>
<li> При этом все это в документации описано плохо, обычно там простые примеры, в которых все работает, а сложные вещи не описаны. И по сути 5 месяцев из года они разбирались с тем, что же на самом деле предоставляет облако и в каком виде.</li>
<li> И вот здесь критичную роль играет квалификация персонала devops: он должен разбираться в облачных технологиях на очень высоком уровне, чтобы прорываться через возникающие проблемы. А этого обычно нет, такие люди слабо доступны, их мало.</li>
<li> А дальше вопрос рабочих процессов в командах, которые дорабатывают сам продукт для переезда. Нужно общее понимание, куда едут, какие особенности с теми продуктами, которые предоставляет облако, в чем отличие от автономно устанавливаемых версий, например. нестандартный кубернетис. Синхронизация работ, совместное тестирование, инфраструктура для этого тестирования.</li></ul>
<p>Как легко догадаться, дешево такой процесс никогда не стоит. Потому что все эти пункты и противоречия добавляют стоимости. Мы просто перекладываем расходы из одной статьи в другую. Более того, поскольку многое зависит от специфики конкретного облака, а она у всех разное, переезд в другое облако снова потребует года. Ну или 6-8 месяцев, если архитектура окажется удачной и подходящей, а проблем — мало. Не меньше, потому что 5-6 месяцев — разбираемся в облаке и строим там базовую инфраструктуру.
</p><p>Типичный пример проблемы. Родительская организация выставляет требования к ИБ о том, что хранение персональных данных должно быть выделено в отдельный сегмент. Требование было давно, вместе с другими, но полгода системный архитектор его не замечает, он строит архитектуру, исходя из того что БД будут в одном сегменте и связь будет прямой. Коллизия выясняется на премке уже развернутой среды. Да. не фатально, но команды фронта и бэка садятся и пару недель перерабатывают приложения, а devops настраивают инфраструктуру, обеспечивающую связь между сегментами. И таких примеров — много.
</p><p>Базовые ошибки.
</p>
<ul><li> ошибка анализа и оценки — ее делали люди, не обладающие квалификацией, они ее делали в оптимистичном предположении, что все поедет.</li>
<li> Ключевые люди не участвуют в совместном проектировании, архитектор все делает сам без ИБ, девопс и сопровожденцев. И придумывает нереалистичные конфигурации.</li>
<li> Нехватка компетенций в рамках технологии и конкретного облака, которое купили закупщики выбрав по стоимости. Пилот часто проводит команда, которая не знает про детали продукта</li>
<li> Сделайте вчера.</li>
<li> Делаем тяп-ляп чтобы выпустить. Рассчитываем, что облако резиновое, оно растянется. А оно не растягивается, или растягивается дорого.</li></ul>
<p>Проблемы российских облаков
</p>
<ul><li> Очень слабый сервис. Это — норма. Это особенность нашего менталитета, относится не только к облакам. На входе сервиса чаще всего специалисты-передатчики. а не те. кто решает проблемы. Документация слаба.</li>
<li> Слабая информированность клиента об обновлении инфраструктуры облаков — и постоянные аварии из-за обновлений. Облако при этом заявляет, что оно не виновато, оно просто соответствует стандартам безопасности и накат обновления был обязателен.</li>
<li> Облака дорабатываются на клиентах. Они выпускают обновления, которые могут все ломать. И они не виноваты, они тоже заложники ситуации «надо вчера». Облака вольны выпускать обновления когда хотят, тестируют слабо, и вообще это обновление безопасности, и любое обновление можно так квалифицировать.</li>
<li> Российский облака — часто не понимают, что делают, нет концепции развития. Бери больше, кидай дальше. Акронимы, а не логика. И при этом хотят посадить потребителя на вендорлок.</li></ul>
<p>Иностранные — лучше. Потому что старше, потому что много вкладывались в развитие.
</p><p>И как вывод. На российские облака переезжать можно, но надо иметь силу духа. Проблемы — будут.
</p>
<h1><span class="mw-headline" id=".D0.92.D0.BB.D0.B0.D0.B4.D0.B8.D0.BC.D0.B8.D1.80_.D0.9F.D0.B0.D1.88.D0.BA.D0.BE.D0.B2.D1.81.D0.BA.D0.B8.D0.B9_.D0.B8.D0.B7_.D0.9C.D0.B0.D0.B3.D0.BD.D0.B8.D1.82_.D0.98.D0.A2._.D0.9C.D0.B5.D1.82.D1.80.D0.B8.D0.BA.D0.B8_.D0.BF.D1.80.D0.BE.D0.B8.D0.B7.D0.B2.D0.BE.D0.B4.D0.B8.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D1.8B">Владимир Пашковский из Магнит ИТ. Метрики производительности команды</span></h1>
<p>Метрики нужны, чтобы разбираться. Если команда приносит меньше — это аномалия и надо как-то это поправить. Если команда приносит больше — тоже интересно, чтобы этот опыт тиражировать.
</p><p>В докладе была важная мысль, чем команда отличается от группы разработчиков. Команда вся работает на продукт. Есть цель спринта, ее KPI — релиз. Я знаю, чем занимаются коллеги, а они знают, чем занимаюсь я. И каждый знает, как работает продукт. И в этом отличие от разработчика, который делает только свои задачи и знает только свой код.
</p><p>Метрики.
</p>
<ul><li> dev time: скорость, емкость, количество труда — можно брать из таск-трекера</li>
<li> t2m, частота релизов</li>
<li> предсказуемость: % выполнения целей спринта и роадмапа, таймлайн</li>
<li> качество: процент багов в спринте и их трудоемкость, доступность SLA</li>
<li> экономика</li>
<li> eNPS — удовлетворенность сотрудников.</li></ul>
<p>И был разбор, как отдельные практики влияют на метрики. Что важно, влияние обычно комплексное, практики влияют на несколько метрик и наоборот, одна метрика зависит от применения набора практик. Метрики дают индикатор проблем, а дальше надо смотреть причины и понимать, какими практиками их исправить.
</p><p>Например, если есть проблема с поставкой нужного функционала в срок, то причина может быть в том, что нарушена коммуникация с бизнесом и нет представления, какие фичи реально нужны, может быть перегрузка и недостаток ресурсов. а может быть недостаток конкретных компетенций. Надо разбираться и устранять. И недостаток компетенций можно устранять через найм сотрудника.а можно — через обучение.
</p><p>Важным фактором является agile-фреймворк, он влияет на все метрики, он определяет workflow снаружи, путь задачи в команду, и путь задачи внутри команды до релиза. Инженерные практики: git-flow, стандарты и практики, сервисы обработки. Качество: качество кода, техдолг, доступность SLA, зависимости. Качество — через стандарты написаняи кода, а не каждый как хочет.
</p><p>Удовлетворенность сотрудников (eNPS) зависит от двух факторов: коммуникации — с PO, TL/SM, бизнесом, и комфорт — без бюрократии, интерес к работе, рабочее место.
</p><p>Итого. Н
</p>
<ul><li> Декомпозиция верхнеуровневого запроса эффективности — но не слишком детализируйте.</li>
<li> Изучение командных, продуктовых и лояльности совместно — декомпозиция логическая, метрики связаны, а факторы влияют на многие</li>
<li> На эффективность влияет команда, компания и тех.стек</li></ul>
<p>И последнее. Если устроено так, что каждый сотрудник работает для себя, эффективность команды мерить глупо.
</p>
https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-10-19:_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_Up!date_%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%B5_Kazan_Digital_Week_-_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D1%8C%D0%BA%D0%BE2023-10-19: конференция Up!date в составе Kazan Digital Week - интересненькоMaksTsepkovhttps://mtsepkov.org/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MaksTsepkov2023-10-19T12:21:21Z2023-10-19T16:58:10Z<p>20 сентября участвовал и выступал в Казани на конференции <a rel="nofollow" class="external text" href="https://update-2023.ru/">Up!date</a>, проходящей в рамках форума <a rel="nofollow" class="external text" href="https://kazandigitalweek.ru/">Kazan Digital Week</a>. Отмечу, что форум - крупное событие федерального уровня, на пленаре было online-обращение от Мишустина, и выступало несколько спикеров уровня министров и замов. А Up!date - IT-конференция, которую в рамках форума организует группа Барс Груп, и помимо нее на форуме было много других секций. Аудитория форума - широкая и смешанная, много представителей власти и бизнеса, много молодежи, включая студентов и даже старших школьников. Помимо программы выступлений была большая выставка, на которую я не попал, и много секций, которые шли параллельно с Up!date. И я смог присутствовать только один день из трех.
</p><p>Программа - интересная. Заметки будут состоять из двух частей, про пленарное заседание и про Up!date, параллельно с которой шло еще несколько секций, в том числе и по ИТ-тематике. Помимо программы выступлений была большая выставка, на которую я не попал. И я смог присутствовать только один день из трех, так что заметки - не полные. Говорят, там тоже было интересно.
</p><p>20 сентября участвовал и выступал в Казани на конференции <a rel="nofollow" class="external text" href="https://update-2023.ru/">Up!date</a>, проходящей в рамках форума <a rel="nofollow" class="external text" href="https://kazandigitalweek.ru/">Kazan Digital Week</a>. Отмечу, что форум - крупное событие федерального уровня, на пленаре было online-обращение от Мишустина, и выступало несколько спикеров уровня министров и замов. А Up!date - IT-конференция, которую в рамках форума организует группа Барс Груп, и помимо нее на форуме было много других секций. Аудитория форума - широкая и смешанная, много представителей власти и бизнеса, много молодежи, включая студентов и даже старших школьников. Помимо программы выступлений была большая выставка, на которую я не попал, и много секций, которые шли параллельно с Up!date. И я смог присутствовать только один день из трех.
</p><p>Программа - интересная. Заметки будут состоять из двух частей, про пленарное заседание и про Up!date, параллельно с которой шло еще несколько секций, в том числе и по ИТ-тематике. Помимо программы выступлений была большая выставка, на которую я не попал. И я смог присутствовать только один день из трех, так что заметки - не полные. Говорят, там тоже было интересно.
</p>
<h1><span class="mw-headline" id=".D0.9F.D0.BB.D0.B5.D0.BD.D0.B0.D1.80.D0.BD.D0.BE.D0.B5_.D0.B7.D0.B0.D1.81.D0.B5.D0.B4.D0.B0.D0.BD.D0.B8.D0.B5">Пленарное заседание</span></h1>
<p>Как я отмечал, пленар был представительным, после приветственного обращения от Мишустина выступали: Шадаев - министр цифрофизации, Минниханов - раис Татарстана, Шпак замминистра промышленности и торговли, Баканов - замминистра транспорта, Наймушин - замдиректор департамента кинематографии и цифрового развития Минкульта, Герасимов - замминистра МЧС. Кроме них выступали представители бизнеса на уровне генеральных директоров: Нурутдинов из Таттелекома (компания Летай), Сергиенков из Headhunter, Хасьянова из Микрон, а также Уразов - гендиректор дивизиона Кадровый потенциал АСИ.
</p><p>Большинство докладов - отчетно, с цифрами и качеством достижений и планами на будущее. И в них был ряд интересных тезисов, характеризующих текущее состояние, их я отмечу.
</p>
<ul><li> Государственная программа цифровизации завершается в 2024 и не будет продляться. Ее заменит экономика данных. Это - у Шадаева и в других выступлениях. </li>
<li> <b>Управление данными вместо цифрового и проектного офиса</b>. У Нурутдинова была интересная ссылка на Шеллинга: значимая часть никем не руководимой деятельности индивидов приводит к совокупным результатам, которые почти также хороши, как если бы вы управляли каждым оптимально. Поэтому не принимаем решения, а устанавливаем правила, элементы преобразуются из хаоса в порядок через преимущества по отдельным направлениям, которые эти правила устанавливают. </li>
<li> Будет федеральное финансирование и со-инвестирование в импортозамещения для корпораций. При этом оно будет организовано так, чтобы права на софт оставались у ИТ-компаний, и решения можно было тиражировать.</li>
<li> Технологический суверенитет понимается не в смысле "все делать самим", а как организация международных коопераций, в результате которых каждая из сторон получает собственный суверенитет. Это любопытная формулировка. Основания понятны: для многих высокотехнологичных изделий локальный спрос - не велик и локального рынка не хватит для окупаемости. При этом технологический суверенитет хотят многие как гарантию сохранения собственных ценностей и идентичности, так что поле для кооперации - есть. </li>
<li> Идет многоплановое развитие логистики - беспилотники КАМАЗ, транспортные коридоры и стыковки мультимодальных перевозок, включая трансграничные, цифровизация и электронный документооборот вместо бумажного. Пока это - отдельные большие проекты, идут к комплексным. </li>
<li> Сергиенков и Уразов много говорили про кадровый потенциал и кадровый суверенитет. Гибкая занятость, самозанятые; повысить мобильность регионов и не только в центр - регионы разные, в том числе через удаленку; цифровизация навыков; цифровое образование и интеграция бизнеса, там пока много офлайн. При этом нельзя ограничиваться классическим подходом к подготовке кадров, потому что он фокусируется на профессиональных навыках, но оставляет за рамками мотивацию, лояльность и идентичность человека. А без работы с этим хорошо подготовленные люди - уйдут. Три фокуса работы с мотивацией: талантливость - то, что человек умеет и ему интересно; применение в интересах Родины - как он может применить свои умения, у на часто по умолчанию берут западные методики из парадигмы "нет пророка в своем отечестве"; мировые вызовы - ставить задачи мирового уровня, а не повторять и догонять.</li></ul>
<h1><span class="mw-headline" id=".D0.9A.D0.BE.D0.BD.D1.84.D0.B5.D1.80.D0.B5.D0.BD.D1.86.D0.B8.D1.8F_Up.21date">Конференция Up!date</span></h1>
<p>Начну я со своего выступления <a href="https://mtsepkov.org/%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D0%BA%D0%B0,_user_story,_use_case,_DDD:_%D0%BE%D0%B1%D0%B7%D0%BE%D1%80_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_(Up!Date-2023)" title="Классика, user story, use case, DDD: обзор методов (Up!Date-2023)"><b>Классика, user story, use case, DDD: обзор методов</b></a>. Оно развивало мое весеннее выступление <a href="https://mtsepkov.org/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%B8%D0%BB%D0%B8_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8_-_%D0%BA%D0%B0%D0%BA_%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C_%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8_(AnalystDays-2023)" title="Требования или модели - как писать постановки (AnalystDays-2023)">Требования или модели - как писать постановки (AnalystDays-2023)</a> с фокусом на выбор конкретных методов и взаимосвязь между ними.
</p><p>Доклад вызвал много вопросов, их вместе с моими ответами можно посмотреть в комментариях к <a rel="nofollow" class="external text" href="https://t.me/up_date2023/151">посту на канале конференции</a>, там получилось интересное обсуждение, вопросы очень разноплановые.
</p><p>Вообще обсуждение в телеграм на конференции было очень продуктивно организовано: на каждое выступление был отдельный пост с комментарием, и участников побуждали спрашивать, потому что спикер выбирал приз за лучший вопрос. А спикер мог ответить в телеграме, если на очный ответ не хватило времени.
</p><p>А дальше - пойдем по порядку. И, к сожалению. не полностью: после своего выступления я отвлекся на обсуждения.
</p>
<h2><span class="mw-headline" id=".D0.9C.D0.B8.D1.85.D0.B0.D0.B8.D0.BB_.D0.90.D0.B1.D1.80.D0.B0.D0.BC.D1.81.D0.BA.D0.B8.D0.B9_.28.D0.98.D0.A2.D0.98.D0.A1.29._.D0.9A.D0.B0.D0.BA_.D0.BF.D0.BE.D0.BB.D1.83.D1.87.D0.B8.D1.82.D1.8C_.D0.BC.D0.B0.D0.BA.D1.81.D0.B8.D0.BC.D1.83.D0.BC_.D0.BE.D1.82_.D0.BE.D0.B1.D1.80.D0.B0.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.B4.D0.BB.D1.8F_.D0.BA.D0.B0.D1.80.D1.8C.D0.B5.D1.80.D0.BD.D0.BE.D0.B3.D0.BE_.D1.80.D0.B0.D0.B7.D0.B2.D0.B8.D1.82.D0.B8.D1.8F">Михаил Абрамский (ИТИС). Как получить максимум от образования для карьерного развития</span></h2>
<p>Это доклад о современных изменениях в ИТ-образовании, как его дает ВУЗ. Он адресован молодежи, которая была на конференции: ВУЗ по-прежнему остается ведущим способом получить образование, особенно имея ввиду работу в корпорациях. При этом ВУЗы пробуют перестроиться, чтобы соответствовать современным вызовам, и надо понимать эти изменения, не ждать продолжения классики, которая не работает.
</p><p>Меняется не только ВУЗ, меняется все образование. Сейчас нельзя готовить к конкретному рабочему месте. особенно в ИТ - из за быстрого изменения технологий характеристики рабочего места размыты или отсутствуют. И профессию выбирают не на всю жизнь, а на 5-7 лет. И даже если ты продолжаешь быть в ИТ, ты занимаешься другим, это тоже смена профессии с точки зрения прежних критериев.
</p><p>Поколение Альфа - само выбирает, с детства в гаджетах, клиповое мышление, отрицание норм и традиций. И образование следует за этим, пробует учить нестандартно: перевернутый класс, онлайн-курс, проектное обучение. Нестандартные домашки: создать аккаунт, снять видео, сайт, аудиозапись, интерактивная презентация, деятельностное задание - собрать группу и что-то сделать, и так далее.
</p><p>Надо учиться учиться онлайн - это планирование времени, регулярность, занятия - вовлеченность и включенная камера. И это - самостоятельно!
</p><p>Если вы видите свое будущее в ИТ - познакомьтесь с профессиями в ИТ, их множество. Разберитесь, что такое - ИТ-проект. Командная деятельность, гибкие методологии (scrum), код-ревью, таск-трекер, учитесь оценивать трудозатраты. Вопреки расхожим представлениям, работа в ИТ - это коммуникация: разговоры, митинги, обсуждение.
</p><p>Если учитесь на не-ИТ специальностях - есть цифровые кафедры, можно туда пойти. Есть технологический студактив для внутренних разработок ВУЗов - можно там работать, получать опыт реальных проектов, которые будут использоваться. Приобщайтесь к проектам с открытом исходным кодом: делайте собственные версии, делайте запросы на изменения.
</p><p>Ставьте новые задачи на обучение через вакансии: смотрим, что нравится, сверяем с собой, видим точки роста.
</p><p>Разбирайтесь с ИИ. python, Jupiter, анализ данных, GPT. Избавьтесь от мифов про ИИ - он помогает, а не порабощает. Учите языки, осваивайте коммуникацию, самую разную: комментарии, запросы. Не бойтесь делиться знанием
</p><p>Читайте визионеров и фантастику. Они угадывали невероятное.
</p>
<h2><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B5.D0.B9_.D0.A4.D0.B0.D0.B4.D0.B5.D0.B5.D0.B2._.D0.90.D0.BB.D1.8C.D1.82.D0.B5.D1.80.D0.BD.D0.B0.D1.82.D0.B8.D0.B2.D0.BD.D0.B0.D1.8F_ORM_.D0.B4.D0.BB.D1.8F_.Net_.22LINQ_to_DB.22_.D0.B8_.D1.80.D0.B0.D1.81.D1.88.D0.B8.D1.80.D0.B5.D0.BD.D0.BD.D1.8B.D0.B5_.D0.B2.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.8B_.D1.81_PostgreSQL">Алексей Фадеев. Альтернативная ORM для .Net "LINQ to DB" и расширенные возможности работы с PostgreSQL</span></h2>
<p>Linq - это реализованный в C# 3.0 в 2008 способ работать с базой данных через естественные конструкции языка. До этого для работы с базой данных использовали либо прямое выполнение SQL-операторов, либо ORM, в частности Entity framework, который позволял представить записи базы данных в виде коллекций экземпляров классов. У обоих методов были проблемы. Прямое использование SQL - под ответственность разработчика, для компилятора эти операторы - просто текстовые константы, он не знает про структуру базы данных. А ORM ограничен, вы он работает с объектами в памяти и вы не можете использовать мощь SQl-операторов для массовой обработки и даже для выбора объектов, можете сделать не все, что в SQL. Особенно в PostgreSQL и его расширениях - там много интересных конструкций.
</p><p>Конечно, Entity framework тоже развивается, например. недавно сделали поддержку массивов, которые могут быть значением поля БД. Но PostgreSQL позволяет эффективный поиск по значениям таких полей за счет специального синтаксиса SQL, и это в Entity framework недоступно.
</p><p>Linq to DB снял эти ограничения. Вы используете конструкции C#, а они транслируются в SQL, в том числе - с использованием индексов и других возможностей базы данных. При этом можно писать свои расширения, задействуя дополнительные появляющиеся возможности, например, поиск по индексу для значения-массива или рекурсивные запросы.
</p><p>И дальше были конкретные примеры полезных функций, которые становятся доступными через расширения linq to db.
</p><p>В PostgreSQL полнотекстовый поиск встроен в БД. И можно сделать поле tsvector как конкатенацию всех текстовых полей, для этого специальный оператор @@. Его нет в стандартном linq to db, но можно написать метод расширения, который это добавит - sql-реализацию через псевдоатрибут.
</p><p>Встроенный полнотекстовый поиск - а нужен ли он, если есть elastic search? Он полезен, если хватает его возможностей: не надо ставить отдельную систему, не будет отставания по синхронизации данных.
</p><p>Поиск в двумерном пространстве: найти бар, школу, библиотеку. Первый вариант - берем прямоугольную область, бары в ней, сортируем. Но бары расположены неравномерно. В PostgreSQL есть оператор point(x,y) и есть индекс gist, если его строим по координате, то поиск ближайших идет по индексу. Оператор <->. Расширение PostGIS - правильные расстояния на земном шаре.
</p><p>JSONB - вложенные Json, преобразованные в бинарный поиск, индексируются. оператор @> - соответствие json --> - выбор по ключу. Его нет в ОРМ, но можно тоже написать расширения. И можно не только в PostgreSQL- так можно с обычными json работать.
</p><p>Расширение jquery - запросы по json. jsonpath - аналогичное расширение, только это стандарт.
</p><p>Агрегатная функция array_agg - собрать все значения в массив - очень круто! И есть агрегация в json - jsonb_object_agg как ключ-значение.
</p>
<h2><span class="mw-headline" id=".D0.9C.D0.B0.D1.80.D0.B8.D1.8F_.D0.A0.D0.B5.D0.B2.D1.8F.D0.BA.D0.B8.D0.BD.D0.B0_.28.D0.91.D0.90.D0.A0.D0.A1_.D0.93.D1.80.D1.83.D0.BF.D0.BF.29._.D0.9A.D0.B0.D0.BA_.D0.BF.D0.BE.D0.B2.D1.8B.D1.81.D0.B8.D1.82.D1.8C_.D1.8D.D1.84.D1.84.D0.B5.D0.BA.D1.82.D0.B8.D0.B2.D0.BD.D0.BE.D1.81.D1.82.D1.8C_.D0.B2.D0.B7.D0.B0.D0.B8.D0.BC.D0.BE.D0.B4.D0.B5.D0.B9.D1.81.D1.82.D0.B2.D0.B8.D1.8F_.D0.B2_.D0.BA.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D0.B5">Мария Ревякина (БАРС Групп). Как повысить эффективность взаимодействия в команде</span></h2>
<p>Рассказ про систему шаблонов для постановок, которая позволила существенно повысить эффективность коммуникации между аналитиками и разработчиками. Что важно - внедрялось относительно мягко, без обязательного использования. Просто у тех аналитиков, которые пользовались шаблоном уменьшалось количество проблем в процессе разработки и внедрения. И это было видно.
</p><p>Из своего опыта я могу сказать, что предлагаемая система шаблонов, безусловно, не решает всех проблем. Но в докладе есть много практик, которые, безусловно надо применять, некоторые из них, на мой взгляд, относятся к гигиеническому уровню. Например, у системы должно быть описание, которые не могут служить задачи в таск-трекере, и которое надо регулярно актуализировать. И шаблоны для постановок тоже полезны, если не пытаться с их помощью заставить все разжевывать до деталей: все равно не получится, а шаблон станет сильно громоздким и неудобным.
</p><p>Основная проблема коммуникации между аналитиками и разработчиками - двоякая трактовка. Она дает не адекватные оценки и неверную реализацию. Они пробовали фиксить через процесс коммуникаций, но не помогает: аналитик рассказывает, разработчик понял и оценил, а в реализацию взял другой. он не слышал рассказа. Пробовали оценивать все задачи всей командой, но это требует очень много времени.
</p><p>Разработчик хочет, чтобы объяснили. Аналитик хочет, чтобы было понятно сейчас, и было понятно потом, в том числе новичку. При этом доработки сделанного регулярны, надо понимать как поменять чтобы не испортить.
</p><p>Решение - вести по проекту базу знаний, а не только фиксировать задачи в таск-трекере. Словарь - все сущности со всеми атрибутами, при этом названия по-русски, по-английски, таблица в БД.
</p><p>Дальше был конкретный кейс, на котором показывали шаблон на разработку.
</p>
<ul><li> Общая информация - таск, местоположение в системе, задача кратко текстом</li>
<li> Модель данных - сущности и все атрибуты этой сущности</li>
<li> Валидация - те проверки ,которые каждый раз проводятся системой при обновлении базы данных</li>
<li> Права доступа - группируем в папки</li>
<li> Интерфейс - текстовом виде: панель инструментов; форма реестра; форма окна редактирования; (поля, типы, источник в БД и т.д.)</li>
<li> Функции - как работает система, что делает пользователь в формате сущность-атрибут</li></ul>
<p>Шаблон разработали 6 лет назад, начали внедрять. У тех, кто ставил по шаблоны - сокращалось время на оценку и реализацию, они занимались далее. А кто по-старому - возврат в доработку, да еще обосновывать, стресс накапливается - и переходят на шаблон.
</p><p>Работает для всех видов доработок. Если меняется что-то локально - то просто не все разделы шаблона заполняем. И по шаблону могут джуны.
</p><p>Все работало хорошо, пока было мало задач на доработку ранее сделанного функционала. Если доработок 5-7, то появляются проблемы с инкрементальным накоплением: надо их все прочитать, чтобы понять как есть сейчас. А еще тяжело, когда много задач в одной статье при параллельной работе.
</p><p>И они решили помимо описаний инкрементов собирать описание текущей реализации в том же шаблоне.
</p><p>Шаблон хорошо работает на новых проектах. На старых проектах основную статью собирать долго, но подъемно, если изменения описаны по шаблону.
</p><p>Плюсы:
</p>
<ul><li> коммуникация: разработчик понимает что нужно, аналитик получает что описал</li>
<li> социальная составляющая: отлаженный процесс, переходы аналитику</li>
<li> адаптация новичков</li></ul>
<p>Анализ показывает, что при внедрении шаблона время на постановку увеличивается на 30%, зато на 90% сокращается возврат задач, на 85% время поиска ошибки, на 85% время оценки, на 60% количество доработок, а время на документацию - на 25%. И это - очень интересная статистика. А еще уменьшилась текучесть сотрудников, у них работают по 5-6 лет.
</p>
<h2><span class="mw-headline" id=".D0.90.D0.BB.D0.B5.D0.BA.D1.81.D0.B0.D0.BD.D0.B4.D1.80_.D0.A1.D0.B5.D1.80.D0.BF.D0.B8.D1.87.D0.B5.D0.B2_.28AXENIX.29_.D0.9F.D0.BE.D1.87.D0.B5.D0.BC.D1.83_.D0.BD.D0.B5_.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D0.B0.D0.B5.D1.82_SRE_.D0.B2_Enterprise.3F">Александр Серпичев (AXENIX) Почему не работает SRE в Enterprise?</span></h2>
<p>Когда возникают проблемы с устойчивостью работы систем, то люди смотрят на передовой опыт, и обнаруживают SRE - Site reliability engineer от Google. B пробуют внедрить. Как правило, не удачно. И доклад как раз раскрывал проблемы, по которые SRE не работает в Enterprise.
</p><p>Проблема тут не столько в SRE как в методике, сколько в том процессе внедрения, который реализуют руководители. Их ожидания: нанять хороших спецов на рынке для адаптации практик, взять готовый kpi и вставить в должностную инструкцию, и по максимуму снять с себя самих задачу внедрения. Я бы сказал. что провал внедрения при таком подходе очевиден для любой методики, не зависимо от ее работоспособности.
</p><p>А в случае SRE есть еще одна идея: не менять ничего в разработке, потому что разработка делает полезные фичи, поэтому пусть SRE строят рядом. То, что именно разработчики сделали софт, которые работают неустойчиво, как-то ускользает из внимания.
</p><p>Типовые проблемы внедрения
</p>
<ul><li> Имплементация отдельных инструментов не дают улучшений</li>
<li> К жесткой блокировке разработки нового функционала при несоблюдении показателей, что жестко соблюдается в Google, оказываются не готовы</li>
<li> Для работы SRE надо хранить и анализировать данные - на это не рассчитывали.</li>
<li> Кроме продуктового бэклога начинает расти бэклог задач повышения доступности - этого тоже не ожидали.</li></ul>
<p>Реально к такому результату приходим потому, что по пути делали ряд ошибок.
</p><p>Команда разработчиков. И в эту команду добавляют SRE, который говорит "у меня для каждого есть задачи, чтобы продукт стал лучше". Всем, кроме менеджера все равно, они готовы, а менеджер против - потому что сроки плывут.
</p><p>Что же требуется для успешного внедрения?
</p>
<ol><li> Нанимаем спеца и говорим "давай мониторинг" - сделаем сбор данных и дашборды. Из мониторинга высыпается технический долг, если он показывает проблемы.</li>
<li> Надо понимать, что практики SRE требует трудозатрат для команды. Часто работы по настройке ложатся на SRE или идут с низким приоритетом. Трудозатраты команды на адаптацию инструментов аналитики и процессов работы с ними - не учитываются. Надо аллокировать ресурсы на доступность, надо выстраивать процесс анализа мониторинга. </li>
<li> Поддержка людей, принимающих решений. Для этого им надо показать профит: что заработаем или что не потеряем. Кейс: на одном из проектов заказчика не может получить на мониторинг, потому что он приходит говорит надо 3 рубля на мониторинг. А бизнес говорит: на фига, у меня все проблемы в том году стояли 1 рубль.</li>
<li> Надо перестраивать процессы по связанным сервисам, механизмы взаимодействия с техподдержкой и эскалации. Это надо прорабатывать. </li></ol>
<p>SRE решает проблемы через код. И дописать этот код надо даже в самом приложении. А в наших компаниях функциональная модель, она не позволяет без перестройки работать.
</p><p>Простой рецепт, который решает эти проблемы.
</p>
<ol><li> Определение метрик и способов измерения</li>
<li> Стабилизация - автоматизация выполняемых задач развертывания и эксплуатации для улучшения показателей</li>
<li> Развитие культуры работы с ошибкой, работа с бюджетом ошибок</li>
<li> Эволюция - автоматизированная проверки сервисов, симуляция по прошлым post morten, масштабирование. </li></ol>
<p>Часто начинают с последнего этапа, не пройдя предыдущее, не создав условия.
</p><p>Как оценить зрелость команды?
</p>
<ul><li> Компетенции SRE - как осознают и используют</li>
<li> Метрики доступности - не просто меряем, на что она влияет</li>
<li> Уровень автоматизации типовых операций - инженер или кнопка. Например, после восстановления по сбою</li>
<li> Управление доступностью - по анализу инцидентов.</li></ul>
<p>SRE живет в подготовленной среде - метрики, компетенции, взаимодействие. Не перешагивайте через своей уровень зрелости
</p><p>И последнее - как искать людей? Главное - люди должны быть с желанием, опыт - вторичен. Но при этом у людей должно быть желание изучить чужой опыт, а не обязательно строить свое оригинальное.
</p>