2024-11-21: MergeConf - теперь в Москве

Короткая ссылка: MergeConf-2024-Msk

Ссылки сюда (4) →

О других конференциях

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

Я выступал с докладом Системное мышление: что это и зачем нужно разработчику и аналитику?, продолжающим мою серию докладов по этой теме, начатую год назад на AnalystDays. Доклады не повторяют друг друга: тема - необъятна, а я меняю содержание и ставлю разные акценты. Кроме того, каждый доклад мне самому приносит новое понимание в процессе подготовки и обсуждения с ПК и участниками. Следующий доклад из этой серии будет на следующей неделе на Teamlead.

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

Владимир Лазарев из AML Crypto. Криптовалюты под прицелом: Как защититься от угроз и предугадать новые правила

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

Денис Цветцих из T-Bank. Эффективные DomainEvents из DDD

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

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

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

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

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

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

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

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

• Смотрю на мир через идеи.
• Мы живем в мире идей. MergeConf, выступления - все это было когда-то чьей-то идеей.
• Мы креативны по природе, вопрос лишь в том, насколько ярко мы проявляем эту креативность.
• Идеяспособность: состояние (в котором могу) + навыки и методы = образ мышления и свойство личности
• Идеи - не только на работе - идея занять ребенка тоже востребована. Заинтересовать.
• Установка: каждый может придумать идею
• Полюби процесс поиска идеи и решения задачи. Он сам не сразу к этому пришел
• толерантность к новому и неизвестному. Когда надо придумать - идей нет, и это нормально, я не тупой.
• Относится к проблеме как задаче, которая не решена. Или трудность не как препятствие, а как приглашение к поиску нового
• Знать свои творческие состояния. Коллекция состояний - у человека от 7 до 15 разных состояний. И среди них должны быть состояния, где можно придумывать идею. И надо понимать, в каком состоянии ты можешь.
• Надо понимать, что тебя вводит в это состояние. Может быть метафора, например, печка, пекущая пирожки. Включать может место, обстановка, ритуал, атрибуты, действия. У него: душ, салон самолета, музыка на повторе, прогулка с вопросом, размышления на тему. * Очень влияет музыка. Спокойная и медитативная - надо подбирать под занятие.
• Может быть простое действие, например, сказать "Так!"
• Наблюдательность. Приглядеться к окружающему миру. Липучка на кроссовке - инженер отдирал репей с собаки.
• Находчивость и изобретательность. Умение находить выход из ситуации. В Игре престолов мантии делали из ковриков Икеа, костюмер в интервью сказал - Икеа тут же сделала мануалы и начало продавать.
• Воображение. Сны - они в голове, ты придумал, увидел - воображение есть у всех. Деньги из листиков, секретики.
• Сегодня меня ждет день, в котором я никогда не был! Это - уникальный день! Призма меняет восприятие.
• Путешествия. Если нет возможности уехать - с чемоданом по Москве, уехать на выходные, переночевать в отеле. Но с чемоданом, как путешествие - это меняет восприятие.
• Сказать себе Ещё! Не останавливайтесь!
• Взгляд внутрь себя. Что для меня море, что для меня закат.
• Копилка идей. В записи куча разных идей. Они не запомнятся, пусть будут.
• Насмотренность. Это ингредиенты для приготовления идей. Чтобы складывать мозаику. Посмотри 1-2 даже если не смотришь
• Вдохновляться другими.
• Идействуй! Чтобы копилка идей не превратилась в кладбище. Пробуй, делай первый шаг.
• Пробовать новое. Загружать, делать это постоянно.
• Взгляд ребенка. Почему так, почему гром гремит, почему снег белый.
• Поле идей. Обменивайтесь, не держите внутри
• Футурологические прогнозы. Там часто фигня, но она будит фантазию. И можно читать старые.
• дИИалог. Дружба и сотрудничество с нейросетью. Потмоу что способ для быстрого рождения идей.

Что тормозит

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

И заключение.

• Креативность - это выбор. Выдайте себе патент на неограниченное творчество.
• Вдохновение от слова вдох. Не забывайте его делать.

Яна Шаклеина из Outline Tech. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей

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

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

В докладе была табличка характеристик сотрудников и шаблонов поведения, чтобы определить ее тип, и рекомендации по ситуациям. Эти слайды Яна не рассказывала, они для самостоятельной работы.

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

Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать

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

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

• Избегание: я код пишу, в совещаниях с заказчиком не участвую
• Беспомощность: не смог, не знал, мне не помогли
• Эффективная самореализация: делаем все что угодно, но не то что надо

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

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

Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса

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

Шаги поиска.

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

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

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

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

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

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

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

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

1. Сфокусировать компанию. Взять группы, которые про стратегию, и не засорять
2. Управлять целями, а не задачами. Задач - много, у них статусы и проблемы. Поэтому пусть люди идут
3. Отслеживать пульс - метрики, что компания не идет вразнос.
4. Выбирайте правильных людей, в зависимости от целей и задач.
5. Определите амбиции. Насколько можно инвестировать в конкретные направления в рамках стратегии.
6. Вовлекайте причастных. Их больше, чем ответственных, и они могут помочь или помешать. Никто не злой, но у причастных свои планы.

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

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

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

А если подробнее, то когда-то Питер Друкер характеризовал эффективного менеджера как того, кто создает стратегию, принимает риски, погружается в команду и управляет ей. Из тех времен пришла квалификация основных стилей управления на авторитарных с жестким управлением, либералов, которые за общую дружбу, как кот Леопольд и демократов, которые полагаются на команду, но при необходимости приходят на помощь, как Гэндальф. Судя по всему, это классификация Курта Левина (1939), правда у него либеральный стиль назывался попустительским (laissez-faire в оригинале). От себя отмечу, что у Белбина есть роли Шейпера и Координатора, которые в целом соответствуют авторитарному и демократическому стилю, при этом Белбин выделял свои роли экспериментально. А попустительство получится, если руководителем назначить Душу компании, есть у Белбина такая роль, очень полезная, но не руководящая. Впрочем, Анастасия не разбирала детали этой классификации, так что в контексте доклада все это не важно.

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

Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов.

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

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

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

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

Что делать

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

Техника

• три простых дела. Если запланировали 4 дела и 3 сделали, четвертое пойдет легко, мозг настроен
• fresh or fried - сложное утром, простое - вечером.
• smart. выучить китайский - но нет времени. Мобильное приложение и заниматься - и результат есть, smalltalks получились
• work life balance.

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

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

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

Эльвира Абзалова из Игрокрафт. Синхронизируй это! Как сделать команду сильной и слаженной на уровне ценностей

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

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

Как практически выяснять ценности сотрудников? Можно это делать в формате упражнений.

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

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

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

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

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

У меня к материалу доклада есть следующие дополнения.

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

Евгений Паромов из Evrone. FSD: 3 главных недостатка после 3 лет использования

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

Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои:

• app - приложение в целом
• pages - экраны
• widgets - целостные компоненты интерфейса
• features - реализация действий пользователя, use case
• entities - бизнес-объекты проекта
• shared - библиотеки, не привязанные к объектам бизнеса

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

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

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

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

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

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

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

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

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

1. Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
2. Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
3. Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
4. Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - на уровне page.

Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?

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

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

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

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 16:07, 21 ноября 2024 • нет комментариев