Изменения

15-16.11 в Технопарке Сколково прошла [https://skolkovo2024.mergeconf.ru/program '''MergeConf''']. Конференция впервые в Москве, до этого несколько раз проходила в Иннополисе, и весной я там был и выступал. На мой взгляд, площадка Технопарка - Технопарка — не слишком удобна для конференций. так как зоны стендов и докладов оказываются разнесены между собой, и нетворкинг не слишком получается. Впрочем, в спикерской нетворкинг был достаточно активный и несколько слотов я пропустил. Конференция шла два дня в восемь параллельных потоков докладов, на некоторых из них залы были переполнены. При этом записи не будет. так что пропущенные доклады ушли безвозвратно.

Я выступал с докладом [[Системное мышление: что это и зачем нужно разработчику и аналитику? (Merge-2024)|'''Системное мышление: что это и зачем нужно разработчику и аналитику?''']], продолжающим мою [[:Категория:Системное мышление| серию докладов по этой теме]], начатую год назад на AnalystDays. Доклады не повторяют друг друга: тема - тема — необъятна, а я меняю содержание и ставлю разные акценты. Кроме того, каждый доклад мне самому приносит новое понимание в процессе подготовки и обсуждения с ПК и участниками. Следующий доклад из этой серии [https://teamleadconf.ru/moscow/2024/abstracts/11969 будет на следующей неделе на Teamlead].

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

Если говорить коротко, то рассказ был о том, что в мире криптовалют все средства - средства — меченные. И если к вам по длинной цепочке пришли грязные деньги - деньги — то все ваши деньги могут быть объявлены грязные и заблокированы на бирже, не только этот кусочек. И правоохранители тоже могут придти. Есть прецеденты, когда источник грязных денег был на расстоянии 7-10 узлов. При этом разметку делают ретроспективно, ты можешь проверить в моменте получения, и будет чисто - чисто — а потом будет судебное решение. Есть кейсы штрафов бирж в 2024 за операции 2018. И отсюда рекомендации: проверяйте поступающие деньги, если заранее невозможно - невозможно — сделайте отдельный блокчейн адрес, документируйте все взаимодействия, лучше так, чтобы была доказательность. Для проверки есть скоринг, он работает по комбинации двух моделей: похожесть поведения владельца кошелька на заведомо преступные и история получения их средств. А еще используйте биржи и обменники которые идентифицируют контрагентов и их транзакции. Казалось бы, вы теряете анонимность. Но, оказывается, там, где анонимность формально есть, пользователь реально идентифицируется по сетевым следам, и правоохранители при нужде это устанавливают, есть прецеденты. А так в докладе - докладе — много фактуры.

Денис начал с того, что механизм Domain Events - Events — полезен, но в литературе упоминается вскользь и противоречиво: автор одновременно пишет, что событие локально принадлежит ограниченному контексту и тут же указывает, что события используются для связи контекстов. То же касается транзакций - транзакций — пишут, что этот механизм аналогичен триггерам БД и обеспечивает консистентность, и тут же упоминают про асинхронную отправку через сообщения. И дальше Денис подробно рассказывает о шаблонах применения событий.

В основе - основе — c4 model. В ней бизнес - бизнес — это вообще контекст исполнения. А дальше есть уровни: контейнеры - компоненты - контейнеры — компоненты — код. И все бизнес-содержание в этой модели опущено на уровне кода, DDD применяется именно там, и Domain Events - Events — этого уровня. А для интеграции используются DTO и Application Events, они очищены от доменной специфики.

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

И если подразумевать этот шаблон приложения, то примеры из доклада, как применять события вместо явного вызова команд, становятся понятными. Domain Events требует инфраструктуры - инфраструктуры — записи событий и их обработки. Отрабатывать можно перед commit на механизмах ORM. B создавать события их можно не только явно в коде, но и на механизмах ORM. Шаблонов и примеров было много, с кодом, так что пересказывать их сложно. Но можно посмотреть презентацию.

= Илья Баксанов. Идеяспособность: как думать креативно, адаптивно и продуктивно? =

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

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

* Мы живем в мире идей. MergeConf, выступления - выступления — все это было когда-то чьей-то идеей.

* Идеи - Идеи — не только на работе - работе — идея занять ребенка тоже востребована. Заинтересовать.

* толерантность к новому и неизвестному. Когда надо придумать - придумать — идей нет, и это нормально, я не тупой.

* Знать свои творческие состояния. Коллекция состояний - состояний — у человека от 7 до 15 разных состояний. И среди них должны быть состояния, где можно придумывать идею. И надо понимать, в каком состоянии ты можешь.* Надо понимать, что тебя вводит в это состояние. Может быть метафора, например, печка, пекущая пирожки. Включать может место, обстановка, ритуал, атрибуты, действия. У него: душ, салон самолета, музыка на повторе, прогулка с вопросом, размышления на тему. * Очень влияет музыка. Спокойная и медитативная - медитативная — надо подбирать под занятие. * Может быть простое действие, например, сказать "Так«Так!"»* Наблюдательность. Приглядеться к окружающему миру. Липучка на кроссовке - кроссовке — инженер отдирал репей с собаки.* Находчивость и изобретательность. Умение находить выход из ситуации. В Игре престолов мантии делали из ковриков Икеа, костюмер в интервью сказал - сказал — Икеа тут же сделала мануалы и начало продавать. * Воображение. Сны - Сны — они в голове, ты придумал, увидел - увидел — воображение есть у всех. Деньги из листиков, секретики.* Сегодня меня ждет день, в котором я никогда не был! Это - Это — уникальный день! Призма меняет восприятие.* Путешествия. Если нет возможности уехать - уехать — с чемоданом по Москве, уехать на выходные, переночевать в отеле. Но с чемоданом, как путешествие - путешествие — это меняет восприятие.

* Взгляд внутрь себя. Что для меня море, что для меня закат.

* Взгляд ребенка. Почему так, почему гром гремит, почему снег белый.

* Футурологические прогнозы. Там часто фигня, но она будит фантазию. И можно читать старые. * дИИалог. Дружба  Дружба и сотрудничество с нейросетью. Потмоу что способ для быстрого рождения идей.

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

И заключение. * Креативность - Креативность — это выбор. Выдайте себе патент на неограниченное творчество.

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

# Не уверенные в себе - себе — вчерашние студенты, или люди, раньше долго работавшие в других областях. У них могут быть нужные умения, но нет уверенности. И руководитель должен быть защитником, эту уверенность поддерживать. Не фокусироваться на ответственности, даже если задача важная - важная — сотрудник и так боится.# Сотрудники, которые привыкли работать по указаниям, не могут самостоятельно сделать задачу. Не обязательно им надо детальную инструкцию, может быть направление действий, или ожидаемая форма результата. Им нужен руководитель-воин, который всегда знает, что делать, может выдать инструкцию. # Сотрудники-эксперты, которые требовательно относятся к своей компетенции. Тут работает руководитель-друг, который полагается на эксперта, не лезет в его работу. Такому сотруднику нельзя говорить "у «у тебя ошибка"ошибка», особенно публично, лучше сказать "тут «тут сложный функционал, давай еще раз вместе проверим"проверим».

Но главная соль доклада - доклада — не конкретные типы сотрудников и руководителей, а метод. Яна его открыла, когда работала с детьми, а потом применила и для руководства командами. Идея в том, что ты наблюдаешь за человеком, понимаешь его характер и понимаешь характер персонажа, который бы с ним хорошо взаимодействовал. В любой группе есть ребенок-шалун, и ты видишь, что с ним хорошо будет действовать пират. Или разбойник. И ты просто отыгрываешь во взаимодействии этого персонажа. Так и со взрослыми. Персонажей - Персонажей — много, но реально спектр разнообразия - разнообразия — не слишком велик, это описывают психологические модели, например, архетипы Юнга. Так что полезно персонажей объединять в такие группы. Для сотрудников и руководителей у нее получилось всего три архетипа, которые она рассказывала. Но дальше ты вспоминаешь про разнообразие персонажей, и можешь дополнительно подстроиться. А еще ты сам не просто взаимодействуешь определенным образом, ты тоже отыгрываешь подходящего персонажа, и это - это — проще.

Основной фокус доклада - доклада — про провокацию как способ перевести сотрудника в состояние "делаю «делаю то, что нужно компании" компании» из состояния "у «у меня все нормально"нормально». Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент конструктивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.

Есть три распространенные причины безответственности:

В основе такого поведения лежат убеждения: что что-то - то — не мое дело, что мне должны помогать, что я делаю что хочу и компания должна приспособиться. Задача провокации - провокации — поколебать эти убеждения. Способ - Способ — придумать преимущество и довести до абсурда. Например, "конечно«конечно, ты не умеешь решать такие сложные задачи, и это - это — выгодно, мы не будем их тебе давать"давать». Тут надо нащупать точку, где такое как бы присоединение к позиции будет конфликтовать с другими внутренними убеждениями, например, с тем, что все делают общее дело, или что сотрудник - сотрудник — профессионал, способный делать сложные задачи, поэтому такое доведение до абсурда вызовет у него внутренний протест. Но важно делать это корректно и лучше - лучше — с юмором. Задача - Задача — не уйти в конфликт, а пошатать эти убеждения, чтобы потом развернуть в желаемую сторону. В презентации и докладе были конкретные примеры.

Что я хочу отметить? Провокация - Провокация — инструмент, который работает для детей. И то - то — ограничено. То, что он продолжает работать и для взрослых - взрослых — фича современного мира. И тут несколько факторов. Если вспомнить времена трех мушкетеров или даже 19 век, то там за неудачную провокацию можно было получить дуэль с неясными последствиями, и это - это — останавливало. С детьми-то безопасно. И в компании руководитель чувствует относительную безопасность. А с другой стороны, реклама и политтехнологии активно используют инструменты манипуляции и провокации на различные действия - действия — покупку товаров, поддержку нужных инициатив. И в этом причина, почему противостоять этому не учат в школе. Противостоять этому, кстати, достаточно просто - просто — нужна уверенная самооценка, не зависшая от внешней похвалы. И методы обучения тоже есть, Анна Обухова рассказывает очень простой протокол авторизации результата, который служит именно для этого. Она его нашла в методичках педагогического университета имени Герцена для работы с детьми с отставанием в развитии. А вот при обучении обычных детей его не применяют. Почему? Есть версия, что класс, где все ученики им владеют, становится не управляемым для учителей и родителей - родителей — с ними можно взаимодействовать только из взрослой позиции, а система образования так не умеет. Но это уже - уже — про исправление мира. Пока мы работаем в реальном мире, с теми людьми, которые в нем есть. И можно использовать их особенности для достижения рабочих задач. Помня про этику, но это отдельная не очевидная тема.

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

Шаги поиска. # Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - главное — как будем встраивать, готов ли заказчик, часто - часто — владелец или директор, тратить время на встройку. # Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации. # Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - пообщаться — значит какой-то шанс есть. Вопрос - Вопрос — понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - обычно — не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.

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

Но если делать самим, то надо понимать, что в технологии инструменты - 20инструменты — 20 %, а остальное - остальное — коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - помочь — они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - моменте — используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - это — существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - компаний — то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - проекта — уже через знакомых.

У технологии есть ограничения, она бесполезна, когда заказчик - заказчик — не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - времени — у HR и у собственника.

В воронке может быть 30-50 кандидатов, нанимают одного, бывает что вообще не нанимают. И процесс дает много дополнительного профита: получаешь знакомство с рынком, спектр вознаграждения, многое узнаешь о работе других компаний, получаешь сетку теплых контактов, которые не подошли к конкретной позиции, но могут подойти к другим. Или сейчас не готовы менять работу, но это может измениться. Самая долгая история контакта была около двух лет - лет — человек устойчиво работал на своем месте, а потом в его компании началась реорганизация. Или, в другом кейсе, человек ушел из компании делать свое дело, а оно не полетело. А вот жесткий хантинг - хантинг — не работает, если человек доволен своим местом - местом — то он не уйдет. А если уходит - уходит — значит были какие-то реальные причины.

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

Проблема, что операционка кушает все время - время — распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 6 пунктов.

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

Если говорить про конкретные техники, то примером может быть распределение ресурсов. Например, для ИТ - ИТ — договаривайтесь, сколько команда работает на перспективу, enabler; сколько - сколько — делает бизнес-фичи; сколько тратит на эксплуатацию, поддержание системы. Enabler может быть разный - разный — можно смотреть на технологии, можно изучать клиентский опыт - опыт — и это тоже надо взвешивать и планировать. Или каденции - каденции — ритм работы: определяем годовые цели с декомпозицией на кварталы, каждую неделю - неделю — статус движения, раз в квартал - квартал — коррекция целей с учетом продвижения и изменений внешнего окружения. Про все техники и примеры я рассказывать не буду.

= Анастасия Валуйская из VK. Эффективный менеджер как им не быть или все же быть?! =

Если кратко, то доклад о том, что понятие "эффективный менеджер" «эффективный менеджер» сейчас имеет резко отрицательные коннотации, которые основаны на реальных фактах. И потому не надо таким менеджером становиться, а надо управлять иначе.

А дальше тема доклада резко развернулась в то, что сейчас эффективный менеджер - менеджер — это менеджер, который пришел и провел неуместные реорганизации ради достижения каких-то показателей, которые испортили работу команды. Пример, с которым она сталкивалась сама - сама — пришел эффективный менеджер и убрал отдел тестировщиков, да еще практически до выпуска крупной фичи. Они выкатились с багами и несколько месяцев их правили. Анастасия не рассказала продолжение, эффективные менеджеры иногда еще успевают получить премию за реорганизацию или свалить с повышением, а разгребают другие. При этом реорганизация часто - часто — из лучших побуждений, в соответствии с учебниками, просто побочные эффекты не посчитаны. Книги по менеджменту содержат громадное количество примеров, ИТ тут не исключение. И есть мемы, Анастасия приводила комиксы сова - сова — эффективный менеджмент, есть замечательная серия комиксов Дильберта на ту же тему.

Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов. * Заслуги - Заслуги — вам, провалы - провалы — подчиненным. Кейс - Кейс — присвоили заслуги.* Максимально нагружайте людей, особенно непонятными задачами. Чем больше загружен - загружен — тем эффективнее результат* Усильте контроль, эффективный контроль - контроль — залог успеха, поставьте микроменеджемнт

* Не вникайте в предметную область. Кейс - Кейс — человек в ИТ не знал, что есть фронт, бэк и дизайн. Отмечу, что этот вредный совет - совет — основа английской управленческой практики 19 века: джентльмен может управлять чем угодно, ему не надо специально учиться. И именно такой подход лег в основу MBA. В отличие от немецкой традиции 19 века, воспринятой тогда же в России, где знание предмета считалось обязательным.

* Тайм-менеджмент. Но! СБС - СБС — синдром бесполезных совещаний, практически эпидемия.* Содержание. Пришла в ВК, маркировка рекламы - рекламы — погрузилась, и в продукты

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

* эффективность - эффективность — не самоцель, работайте в балансе.

* fresh or fried - fried — сложное утром, простое - простое — вечером.* smart. выучить китайский - китайский — но нет времени. Мобильное приложение и заниматься - заниматься — и результат есть, smalltalks получились

Я в заключении конспекта хочу сказать, что феномен эффективного менеджера имеет много разных причин. Бывают искренние заблуждения и вера в теорию, бывает погоня за KPI, которые устроены так, что интересы компании не важны, и многое другое. Доведение до абсурда в форме вредных советов высмеивает, но не устраняет феномен, так же как фильм "Карнавальная ночь" «Карнавальная ночь» не устранил многочисленных директоров домов культуры, которые вели себя подобно Огурцову. А самый интересный тут вопрос - вопрос — о чем думал тот, кто назначал такого эффективного менеджера, зачем он выбрал именно его. Это может быть ошибка, а может - может — ценностное заблуждение, и во втором случае ситуации будут регулярно повторяться...повторяться…

У меня в блоге был любопытный комментарий Lilia Hlebnikova: "Интересно«Интересно, конечно, слышать такое от представителей VK, где недавно такие "эффективные" „эффективные“ сократили кучу народу, а потом так же лихорадочно стали нанимать на их место новых людей..." людей…»

Мой ответ: "Ну«Ну, спикер же не из топов VK, не она нанимала этих менеджеров. Она рассказывает про свой опыт. А кейсы рассказывала без указания компании, где они были - были — у нее опыт не только VK. Конкретно про VK она сказала, что сейчас стиль топов меняется на авторитарный, но она считает, что это - это — временные изменения, что топы не будут или не смогут отстраивать вертикаль до низу, а то, что в команде управление в команде устроено иначе, помогает им пережить. Поживем - Поживем — увидим. Я знаю кейсы, когда в ИТ эффективных менеджеров нанимали не подумав про всякие эффекты, или вообще не поняв размеры культурного несоответствия, а проблемы вскрывались не сразу, и да, люди уходили. Потому что многие эффективные менеджеры - менеджеры — они знают про ценности, но воспринимают их как риторику. которую необходимо соответствовать, а не как руководство к действию. И умеют ее имитировать."»

Ценности - Ценности — это не менее важно, чем цели. А, возможно, и более. Потому что за поведением сотрудника, его действиями, стоят принципы, которыми он руководствуется в действии, а за принципами стоят ценности. Поэтому, работая с поведением - поведением — надо понимать, что для сотрудника важно. Если он вдруг выполняет свою работу "на отвяжись"«на отвяжись», либо его штормит и идет длинная неконструктивная переписка вместо работы, то, вполне возможно, какие-то из его ценности нарушены, а принципы говорят, что в этих случаях правильно вести себя именно таким образом. И надо вскрыть эти причины и далее работать с этим.

* Moving Motivators - Motivators — выявление личных мотиваторов. Доска, сотрудники получают карточки и располагает по линии важности. Порядок, свобода, мастерство... мастерство… А затем - затем — насколько это удовлетворяю в работе, получаю ли.* Culture design canvas. Картирование культурного кода команды. Как празднуем, как звучит в обучении, как лидерство на их основе. Netflix разработал документ по культуре - культуре — принципы работы, и сотрудники на них ориентируются.

* Диагностика ценностей команды. Опираемся на историю, которая позволяет шкалировать.

И для начала - начала — взять ценности, которые есть. Раскидать по уровням, чтобы это подвергалось оценке. И дальше оценить: насколько это важно для человека и насколько проявляется в работе, построить розочку. Для каждого человека, для команды в целом. Для оценки можно использовать готовые модели. Эльвира говорила про книгу Потенциал команды, Филлип Сандал и Алексис Филлипс, в которой ценности поделены на две группы: продуктивность и атмосфера, важны - важны — обе.

И в завершении рассказа были два кейса, success story, когда за счет изменения ценностей, атмосферы получалось добиться впечатляющих изменений. Первый - Первый — крупная компания, там владелец говорил о низкой прибыли, а директор - директор — что для прибыли нужно расширяться, без этого ничего нельзя сделать, а людей и так не хватает. Ключевым изменением было то, что директору был назначен наставник с очень высокой внутренней планкой качества. полученной на одном из прежних мест работы, принцип "делай «делай лучше всех или не делай"делай». И он сумел личным примером такого отношения вдохновить директора, от того такое отношение перешло к топам. И в результате удалось существенно изменить ситуацию без расширения. Второй кейс - кейс — служба обращение во ЖКХ, единое окно, где сотрудники были полностью демотивированы, замучены разбором жалоб, поток которых не иссякал. И у них сложилась культура вообще не реагировать, а при этом каждая жалоба повторялась многократно, ситуация усугублялась, люди начали разбегаться. Тут в проекте работал психолог с высоким чувством личной ответственности, которое он тоже смог передать - передать — и оказалось, что с жалобами вполне можно разбираться, так что поток вторичных жалоб начал сокращаться. Люди увидели свет в конце тоннеля, отношение изменилось.

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

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

# Эльвира назвала самую распространенную причину, почему ценности компании остаются пустой декларацией. Она в том, что руководство написало их для подчиненных, а не для себя. И не руководствуется ими при принятии решений: при выборе нового проекта, при распределении премий и иного вознаграждения, при назначении на должности. Люди видят, как к ценностям относится руководство - руководство — и поступают соответственно. # Люди по-разному понимают слова "ответственность"«ответственность», "справедливость"«справедливость», "эффективность"«эффективность», не говоря уже о тех, которые содержат оценку, например "хорошая работа" «хорошая работа» или "успешный проект"«успешный проект». Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех «Успех без стратегии"стратегии»: для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антипаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел «пришел на встречу во время" время» означает "опоздал «опоздал не больше 3 минут"минут», а для другого "пришел «пришел за 3 минуты, чтобы подготовиться"подготовиться», не говоря о более сложных конструктах, таких как качественный проект. И все инструменты, типа ранжируй ценности, корректно работают только после того, как о содержании договорились. Проблема многих моделей и тестов в том, что они не учитывают эту разницу смыслов. Модель Спиральной динамики говорит, что есть восемь принципиальных конструкций ценностей, которые согласованным образом переопределяют смыслы понятий. У меня об этом есть несколько докладов и статей, если интересно - интересно — дам ссылки. # Если берешь чужую модель ценностей - ценностей — надо понимать, в какой культуре она создавалась, какой смысл там вложен в слова, каковы представления про идеальную компанию и сотрудника. И сравнить это с вашей компанией. Я не знаю, какая модель заложена в книге "Потенциал команды"«Потенциал команды», о которой говорила Эльвира, я ее не читал, но я анализировал многие известные модели ценностей - ценностей — карту культур Хофстеде, модель Шнайдера, карту Инглхарта-Венцеля, и даже психологические модели DISC и Big Five, и они как раз показывают соответствие идеал, при чем выработанный на материале западной культуры. Об этом у меня тоже есть статьи (https://vc.ru/hr/1228187) (по ссылке - ссылке — последняя).

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

Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - шаблон — простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - других — для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои: * app - app — приложение в целом * pages - pages — экраны* widgets - widgets — целостные компоненты интерфейса* features - features — реализация действий пользователя, use case * entities - entities — бизнес-объекты проекта* shared - shared — библиотеки, не привязанные к объектам бизнеса

Каждый слой делится на срезы - срезы — slice, это модули. А slice делится на сегменты, тут типичный пример UI - model - UI — model — api. Есть ограничение: реализация нижележащего слоя не должна обращаться ни к вышележащему, кроме того ни к смежным частям одного слоя, то есть один объект не может вызывать другой.

Евгений познакомился с FSD три года назад, успешно приносил и применял в командах, видел позитив. Потом он пришел в команду, где FSD начали применять до него, и обнаружил там множество очень маленьких фич, а еще активно живущий UI kit в нижнем слое, что порождало неустойчивость проекта. Он задумался: это особенности внедрения подхода в проекте, или какие-то проблемы заложены в самом подходе? Анализ выявил три проблемы.

Первая проблема - проблема — слишком изменчивый shared. Это происходит не всегда, а только в случаях. когда проект опирается на активно развиваемые библиотеки. Типичный кейс - кейс — развиваемый UI kit. И в результате надо либо сохранять совместимость, и тогда в UI kit множатся объекты, появляется button1, button2, button3, либо нужен частый рефакторинг при изменении shared-уровня, либо возникают фасады вместо конкретных классов, и это усложняет использование.

Тут как альтернативу можно посмотреть на шаблон Clean Architecture. В отличие от FSD, по нему есть книжка, где подробно объяснен не только сам шаблон, но и его основания. В нем слои другие: WebUI - infrastracture - application - WebUI — infrastracture — application — domain. То есть инфраструктура поднята выше приложений, и потому она может активно развиваться. Но там мы не можем в реализацию сущности (domain) включить UI,иначе чем через dependency injection, а это сложно и потому во фронте - фронте — не прижилось.

Вторая проблема: entities не позволяет описать бизнес-модель. Потому что модель - модель — это не только объекты, но и связи между ними. И важно отделить бизнес-модель от всего остального. А тут объекты не могут вызывать друг друга, связи, следуя шаблону, приходится выносить на уровень features, где они смешиваются с действиями пользователя. В этом отличие слоя entities FSD от domain в Clean architecture.

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

Простое решение - решение — разрешить связи - связи — не работает. Потому что объекты включают UI и в результате тянут не просто данные другого объекта, но и все интерфейсы. Получается такая сильно связанная конструкция, а остальные слои вырождаются. Евгений такой вариант пробовал.

Третья проблема. На уровнях Widgets + Features + Entites - Entites — слишком много связей между модулями. Там пример TodoList - TodoList — он размазывается по всем уровням, на уровне features превращается в множество команд. А рядом UserList - UserList — тоже много классов и файлов. И это все путается.

# Entities - Entities — не объект, а группа связанных сущностей, например, user=user+session+profile# Features - Features — не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.

# Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - реализацией — на уровне page. Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?

Я хочу начать свой комментарий к докладу с ответа на этот вопрос. Но он будет длинным. Есть такая штука - штука — парадигмы программирования: процедурная, объектная, реляционная, функциональная и другие. Процедурная восходит к книге Николаса Вирта "Алгоритмы «Алгоритмы + Структуры данных = Программы"Программы», это 1976. Позднее добавился UI. B весь старый enterprise - enterprise — 1С, SAP и многое другое сделан именно в процедурной парадигме, хотя уже на объектных языках. Потому что объектные языки появились с C++, в 1980, объектно-ориентированное проектирование (OOAD) -  — только через 10-15 лет, а его окончательное оформление в DDD - DDD — вообще в 2003. И если почитать шаблоны корпоративного приложения Фаулера или другие книги, то он пишет, что шаблон RichObjects, объекты предметной области - области — он сложный, проще работать на DTO или использовать другие аналогичные шаблоны. Отличие объектного подхода - подхода — объединение данных и поведения в одном объекте с инкапсуляцией внутреннего устройства. А в FSD данные, слой entities, отделены от поведения. оно в features, подобно алгоритмам и структурам данных у Вирта. Отсюда и сложности, если мы пробуем использовать FSD, держа в голове еще и концепцию модели предметной области DDD - DDD — она-то сделана в объектной парадигме. А изменения, которые предлагает Евгений - Евгений — в рамках этого направления. Так что, на мой взгляд, получилось нечто иное.

Но это - это — концептуальный ответ. А есть еще прагматический. Если речь идет про объяснения новичкам, то практичнее говорить про FSD с изменениями - изменениями — есть референс и известный подход, ты не говоришь про велосипед. А вот если есть амбиции больше - больше — то можно говорить про альтернативу. Представить свой подход на международных конференциях, написать книгу. Тогда лучше позиционировать как новый подход. например. полученный в результате синтеза FSD и Clean Architecture или гибрид FSD и богатой доменной модели DDD, или что-то подобное.

Комментарий от Mike Spencer. Мне эта тема очень интересна. Когда попробовал FSD, сразу на бумагу начал выписывать, что можно было бы поменять в FSD. Получил похожий список. Нужна ли архитектура, которая сама по себе работает лишь после череды дополнительных изменений? Кажется, навык придумывать новые архитектуры все ещё востребован...востребован…