7324
правки
Изменения
Новая страница: «{{Conf-Ref}} 15-16.11 в Технопарке Сколково прошла [https://skolkovo2024.mergeconf.ru/program MergeConf]. Конференция впер…»
{{Conf-Ref}}
15-16.11 в Технопарке Сколково прошла [https://skolkovo2024.mergeconf.ru/program MergeConf]. Конференция впервые в Москве, до этого несколько раз проходила в Иннополисе, и весной я там был и выступал. На мой взгляд, площадка Технопарка - не слишком удобна для конференций. так как зоны стендов и докладов оказываются разнесены между собой, и нетворкинг не слишком получается. Впрочем, в спикерской нетворкинг был достаточно активный и несколько слотов я пропустил. Конференция шла два дня в восемь параллельных потоков докладов, на некоторых из них залы были переполнены. При этом записи не будет. так что пропущенные доклады ушли безвозвратно.
Я выступал с докладом [[Системное мышление: что это и зачем нужно разработчику и аналитику? (Merge-2024)|'''Системное мышление: что это и зачем нужно разработчику и аналитику?''']], продолжающим мою [[:Категория:Системное мышление| серию докладов по этой теме]], начатую год назад на AnalystDays. Доклады не повторяют друг друга: тема - необъятна, а я меняю содержание и ставлю разные акценты. Кроме того, каждый доклад мне самому приносит новое понимание в процессе подготовки и обсуждения с ПК и участниками. Следующий доклад из этой серии [https://teamleadconf.ru/moscow/2024/abstracts/11969 будет на следующей неделе на 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. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей =
Если отжать содержание доклада до сухого остатка, то он - о том, что есть три типа сотрудников, и руководителю надо быстро их диагностировать и вести себя соответственно. Вот они.
# Не уверенные в себе - вчерашние студенты, или люди, раньше долго работавшие в других областях. У них могут быть нужные умения, но нет уверенности. И руководитель должен быть защитником, эту уверенность поддерживать. Не фокусироваться на ответственности, даже если задача важная - сотрудник и так боится.
# Сотрудники, которые привыкли работать по указаниям, не могут самостоятельно сделать задачу. Не обязательно им надо детальную инструкцию, может быть направление действий, или ожидаемая форма результата. Им нужен руководитель-воин, который всегда знает, что делать, может выдать инструкцию.
# Сотрудники-эксперты, которые требовательно относятся к своей компетенции. Тут работает руководитель-друг, который полагается на эксперта, не лезет в его работу. Такому сотруднику нельзя говорить "у тебя ошибка", особенно публично, лучше сказать "тут сложный функционал, давай еще раз вместе проверим".
В докладе была табличка характеристик сотрудников и шаблонов поведения, чтобы определить ее тип, и рекомендации по ситуациям. Эти слайды Яна не рассказывала, они для самостоятельной работы.
Но главная соль доклада - не конкретные типы сотрудников и руководителей, а метод. Яна его открыла, когда работала с детьми, а потом применила и для руководства командами. Идея в том, что ты наблюдаешь за человеком, понимаешь его характер и понимаешь характер персонажа, который бы с ним хорошо взаимодействовал. В любой группе есть ребенок-шалун, и ты видишь, что с ним хорошо будет действовать пират. Или разбойник. И ты просто отыгрываешь во взаимодействии этого персонажа. Так и со взрослыми. Персонажей - много, но реально спектр разнообразия - не слишком велик, это описывают психологические модели, например, архетипы Юнга. Так что полезно персонажей объединять в такие группы. Для сотрудников и руководителей у нее получилось всего три архетипа, которые она рассказывала. Но дальше ты вспоминаешь про разнообразие персонажей, и можешь дополнительно подстроиться. А еще ты сам не просто взаимодействуешь определенным образом, ты тоже отыгрываешь подходящего персонажа, и это - проще.
= Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать =
Основной фокус доклада - про провокацию как способ перевести сотрудника в состояние "делаю то, что нужно компании" из состояния "у меня все нормально". Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент конструктивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.
Есть три распространенные причины безответственности:
* Избегание: я код пишу, в совещаниях с заказчиком не участвую
* Беспомощность: не смог, не знал, мне не помогли
* Эффективная самореализация: делаем все что угодно, но не то что надо
В основе такого поведения лежат убеждения: что что-то - не мое дело, что мне должны помогать, что я делаю что хочу и компания должна приспособиться. Задача провокации - поколебать эти убеждения. Способ - придумать преимущество и довести до абсурда. Например, "конечно, ты не умеешь решать такие сложные задачи, и это - выгодно, мы не будем их тебе давать". Тут надо нащупать точку, где такое как бы присоединение к позиции будет конфликтовать с другими внутренними убеждениями, например, с тем, что все делают общее дело, или что сотрудник - профессионал, способный делать сложные задачи, поэтому такое доведение до абсурда вызовет у него внутренний протест. Но важно делать это корректно и лучше - с юмором. Задача - не уйти в конфликт, а пошатать эти убеждения, чтобы потом развернуть в желаемую сторону. В презентации и докладе были конкретные примеры.
Что я хочу отметить? Провокация - инструмент, который работает для детей. И то - ограничено. То, что он продолжает работать и для взрослых - фича современного мира. И тут несколько факторов. Если вспомнить времена трех мушкетеров или даже 19 век, то там за неудачную провокацию можно было получить дуэль с неясными последствиями, и это - останавливало. С детьми-то безопасно. И в компании руководитель чувствует относительную безопасность. А с другой стороны, реклама и политтехнологии активно используют инструменты манипуляции и провокации на различные действия - покупку товаров, поддержку нужных инициатив. И в этом причина, почему противостоять этому не учат в школе. Противостоять этому, кстати, достаточно просто - нужна уверенная самооценка, не зависшая от внешней похвалы. И методы обучения тоже есть, Анна Обухова рассказывает очень простой протокол авторизации результата, который служит именно для этого. Она его нашла в методичках педагогического университета имени Герцена для работы с детьми с отставанием в развитии. А вот при обучении обычных детей его не применяют. Почему? Есть версия, что класс, где все ученики им владеют, становится не управляемым для учителей и родителей - с ними можно взаимодействовать только из взрослой позиции, а система образования так не умеет. Но это уже - про исправление мира. Пока мы работаем в реальном мире, с теми людьми, которые в нем есть. И можно использовать их особенности для достижения рабочих задач. Помня про этику, но это отдельная не очевидная тема.
= Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса =
Для тех, кто не в теме, executive search - поиск редкого специалиста, обычно на позицию топ-руководителя или эксперта, с уникальными требованиями профиля. Такие специалисты могут существовать, но они не ищут работу, у них вообще не может быть резюме. При этом с ростом дефицита на рынке ИТ все больше позиций - архитекторы, аналитики высоких уровней или с конкретным опытом все больше становятся объектом такого поиска. В докладе был алгоритм и конкретные кейсы.
Шаги поиска.
# Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
# Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
# Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
# Офер. Исходя из того, что узнали на 3.
# Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.
Искать можно самим или через агентство. Но, по опыту, с такими нестандартными вакансиями работает только топ-5 агентств, они все работают по предоплате, хотя бы частичной, которую не возвращают при отказе от проекта, а полный гонорар до 30% от годового дохода специалиста. А еще их надо погружать в контекст и вопросы взаимодействия внутри компании, включая встройку, тоже остаются. И у них есть большая сетка теплых контактов. А самим получается дешевле, бизнес-контекст уже знают, и можно проговорить особенности кандидата и обеспечить сопровождения, если решили брать кандидата, не смотря на это.
Но если делать самим, то надо понимать, что в технологии инструменты - 20%, а остальное - коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - уже через знакомых.
У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.
В воронке может быть 30-50 кандидатов, нанимают одного, бывает что вообще не нанимают. И процесс дает много дополнительного профита: получаешь знакомство с рынком, спектр вознаграждения, многое узнаешь о работе других компаний, получаешь сетку теплых контактов, которые не подошли к конкретной позиции, но могут подойти к другим. Или сейчас не готовы менять работу, но это может измениться. Самая долгая история контакта была около двух лет - человек устойчиво работал на своем месте, а потом в его компании началась реорганизация. Или, в другом кейсе, человек ушел из компании делать свое дело, а оно не полетело. А вот жесткий хантинг - не работает, если человек доволен своим местом - то он не уйдет. А если уходит - значит были какие-то реальные причины.
При найме важны не только хард, но и culture fit. Если понимаете, что по хардам - хорошо, а по культуре - не подходит, то явно обсуждает риск с кандидатом. И кандидат явно говорит - есть риск или нет. А дальше смотрят, что по бизнесу. И да, бывает, что кандидат не вписывается. Бывает, что идут на риск, тогда важна отстроить границы. Если кто-то не включает камеру на зумах никогда - проговаривается особенность. И строят модель взаимодействия с их учетом, такие кейсы тоже есть.
= Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях =
Проблема, что операционка кушает все время - распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 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, когда за счет изменения ценностей, атмосферы получалось добиться впечатляющих изменений. Первый - крупная компания, там владелец говорил о низкой прибыли, а директор - что для прибыли нужно расширяться, без этого ничего нельзя сделать, а людей и так не хватает. Ключевым изменением было то, что директору был назначен наставник с очень высокой внутренней планкой качества. полученной на одном из прежних мест работы, принцип "делай лучше всех или не делай". И он сумел личным примером такого отношения вдохновить директора, от того такое отношение перешло к топам. И в результате удалось существенно изменить ситуацию без расширения. Второй кейс - служба обращение во ЖКХ, единое окно, где сотрудники были полностью демотивированы, замучены разбором жалоб, поток которых не иссякал. И у них сложилась культура вообще не реагировать, а при этом каждая жалоба повторялась многократно, ситуация усугублялась, люди начали разбегаться. Тут в проекте работал психолог с высоким чувством личной ответственности, которое он тоже смог передать - и оказалось, что с жалобами вполне можно разбираться, так что поток вторичных жалоб начал сокращаться. Люди увидели свет в конце тоннеля, отношение изменилось.
А в конце была игра, всем раздали карточки с ценностями, предложили у кого совпало с личными - выйти и рассказать, а если не совпало - посмотреть у соседей, поменяться. И примерно десять историй, очень разных мы услышали.
В целом доклад - понятный, содержание ценностей действительно важно. Хотя для многих менеджеров и владельцев это является открытием, все-таки точка зрения, что у всех нормальных людей более-менее одинаковые ценности и они совпадают с моими - очень распространена, для людей бывает открытием, насколько люди разные. Хотя, казалось бы, в школе он это видел у одноклассников. Но почему-то забыл.
У меня к материалу доклада есть следующие дополнения.
# Эльвира назвала самую распространенную причину, почему ценности компании остаются пустой декларацией. Она в том, что руководство написало их для подчиненных, а не для себя. И не руководствуется ими при принятии решений: при выборе нового проекта, при распределении премий и иного вознаграждения, при назначении на должности. Люди видят, как к ценностям относится руководство - и поступают соответственно.
# Люди по-разному понимают слова "ответственность", "справедливость", "эффективность", не говоря уже о тех, которые содержат оценку, например "хорошая работа" или "успешный проект". Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех без стратегии": для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антипаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел на встречу во время" означает "опоздал не больше 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 - тоже много классов и файлов. И это все путается.
Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
# Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
# Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
# Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
# Для связывания разных объектов используется 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. Получил похожий список. Нужна ли архитектура, которая сама по себе работает лишь после череды дополнительных изменений? Кажется, навык придумывать новые архитектуры все ещё востребован...
{{wl-publish: 2024-11-21 16:07:09 +0300 | MaksTsepkov }}
15-16.11 в Технопарке Сколково прошла [https://skolkovo2024.mergeconf.ru/program MergeConf]. Конференция впервые в Москве, до этого несколько раз проходила в Иннополисе, и весной я там был и выступал. На мой взгляд, площадка Технопарка - не слишком удобна для конференций. так как зоны стендов и докладов оказываются разнесены между собой, и нетворкинг не слишком получается. Впрочем, в спикерской нетворкинг был достаточно активный и несколько слотов я пропустил. Конференция шла два дня в восемь параллельных потоков докладов, на некоторых из них залы были переполнены. При этом записи не будет. так что пропущенные доклады ушли безвозвратно.
Я выступал с докладом [[Системное мышление: что это и зачем нужно разработчику и аналитику? (Merge-2024)|'''Системное мышление: что это и зачем нужно разработчику и аналитику?''']], продолжающим мою [[:Категория:Системное мышление| серию докладов по этой теме]], начатую год назад на AnalystDays. Доклады не повторяют друг друга: тема - необъятна, а я меняю содержание и ставлю разные акценты. Кроме того, каждый доклад мне самому приносит новое понимание в процессе подготовки и обсуждения с ПК и участниками. Следующий доклад из этой серии [https://teamleadconf.ru/moscow/2024/abstracts/11969 будет на следующей неделе на 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. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей =
Если отжать содержание доклада до сухого остатка, то он - о том, что есть три типа сотрудников, и руководителю надо быстро их диагностировать и вести себя соответственно. Вот они.
# Не уверенные в себе - вчерашние студенты, или люди, раньше долго работавшие в других областях. У них могут быть нужные умения, но нет уверенности. И руководитель должен быть защитником, эту уверенность поддерживать. Не фокусироваться на ответственности, даже если задача важная - сотрудник и так боится.
# Сотрудники, которые привыкли работать по указаниям, не могут самостоятельно сделать задачу. Не обязательно им надо детальную инструкцию, может быть направление действий, или ожидаемая форма результата. Им нужен руководитель-воин, который всегда знает, что делать, может выдать инструкцию.
# Сотрудники-эксперты, которые требовательно относятся к своей компетенции. Тут работает руководитель-друг, который полагается на эксперта, не лезет в его работу. Такому сотруднику нельзя говорить "у тебя ошибка", особенно публично, лучше сказать "тут сложный функционал, давай еще раз вместе проверим".
В докладе была табличка характеристик сотрудников и шаблонов поведения, чтобы определить ее тип, и рекомендации по ситуациям. Эти слайды Яна не рассказывала, они для самостоятельной работы.
Но главная соль доклада - не конкретные типы сотрудников и руководителей, а метод. Яна его открыла, когда работала с детьми, а потом применила и для руководства командами. Идея в том, что ты наблюдаешь за человеком, понимаешь его характер и понимаешь характер персонажа, который бы с ним хорошо взаимодействовал. В любой группе есть ребенок-шалун, и ты видишь, что с ним хорошо будет действовать пират. Или разбойник. И ты просто отыгрываешь во взаимодействии этого персонажа. Так и со взрослыми. Персонажей - много, но реально спектр разнообразия - не слишком велик, это описывают психологические модели, например, архетипы Юнга. Так что полезно персонажей объединять в такие группы. Для сотрудников и руководителей у нее получилось всего три архетипа, которые она рассказывала. Но дальше ты вспоминаешь про разнообразие персонажей, и можешь дополнительно подстроиться. А еще ты сам не просто взаимодействуешь определенным образом, ты тоже отыгрываешь подходящего персонажа, и это - проще.
= Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать =
Основной фокус доклада - про провокацию как способ перевести сотрудника в состояние "делаю то, что нужно компании" из состояния "у меня все нормально". Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент конструктивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.
Есть три распространенные причины безответственности:
* Избегание: я код пишу, в совещаниях с заказчиком не участвую
* Беспомощность: не смог, не знал, мне не помогли
* Эффективная самореализация: делаем все что угодно, но не то что надо
В основе такого поведения лежат убеждения: что что-то - не мое дело, что мне должны помогать, что я делаю что хочу и компания должна приспособиться. Задача провокации - поколебать эти убеждения. Способ - придумать преимущество и довести до абсурда. Например, "конечно, ты не умеешь решать такие сложные задачи, и это - выгодно, мы не будем их тебе давать". Тут надо нащупать точку, где такое как бы присоединение к позиции будет конфликтовать с другими внутренними убеждениями, например, с тем, что все делают общее дело, или что сотрудник - профессионал, способный делать сложные задачи, поэтому такое доведение до абсурда вызовет у него внутренний протест. Но важно делать это корректно и лучше - с юмором. Задача - не уйти в конфликт, а пошатать эти убеждения, чтобы потом развернуть в желаемую сторону. В презентации и докладе были конкретные примеры.
Что я хочу отметить? Провокация - инструмент, который работает для детей. И то - ограничено. То, что он продолжает работать и для взрослых - фича современного мира. И тут несколько факторов. Если вспомнить времена трех мушкетеров или даже 19 век, то там за неудачную провокацию можно было получить дуэль с неясными последствиями, и это - останавливало. С детьми-то безопасно. И в компании руководитель чувствует относительную безопасность. А с другой стороны, реклама и политтехнологии активно используют инструменты манипуляции и провокации на различные действия - покупку товаров, поддержку нужных инициатив. И в этом причина, почему противостоять этому не учат в школе. Противостоять этому, кстати, достаточно просто - нужна уверенная самооценка, не зависшая от внешней похвалы. И методы обучения тоже есть, Анна Обухова рассказывает очень простой протокол авторизации результата, который служит именно для этого. Она его нашла в методичках педагогического университета имени Герцена для работы с детьми с отставанием в развитии. А вот при обучении обычных детей его не применяют. Почему? Есть версия, что класс, где все ученики им владеют, становится не управляемым для учителей и родителей - с ними можно взаимодействовать только из взрослой позиции, а система образования так не умеет. Но это уже - про исправление мира. Пока мы работаем в реальном мире, с теми людьми, которые в нем есть. И можно использовать их особенности для достижения рабочих задач. Помня про этику, но это отдельная не очевидная тема.
= Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса =
Для тех, кто не в теме, executive search - поиск редкого специалиста, обычно на позицию топ-руководителя или эксперта, с уникальными требованиями профиля. Такие специалисты могут существовать, но они не ищут работу, у них вообще не может быть резюме. При этом с ростом дефицита на рынке ИТ все больше позиций - архитекторы, аналитики высоких уровней или с конкретным опытом все больше становятся объектом такого поиска. В докладе был алгоритм и конкретные кейсы.
Шаги поиска.
# Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
# Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
# Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
# Офер. Исходя из того, что узнали на 3.
# Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.
Искать можно самим или через агентство. Но, по опыту, с такими нестандартными вакансиями работает только топ-5 агентств, они все работают по предоплате, хотя бы частичной, которую не возвращают при отказе от проекта, а полный гонорар до 30% от годового дохода специалиста. А еще их надо погружать в контекст и вопросы взаимодействия внутри компании, включая встройку, тоже остаются. И у них есть большая сетка теплых контактов. А самим получается дешевле, бизнес-контекст уже знают, и можно проговорить особенности кандидата и обеспечить сопровождения, если решили брать кандидата, не смотря на это.
Но если делать самим, то надо понимать, что в технологии инструменты - 20%, а остальное - коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - уже через знакомых.
У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.
В воронке может быть 30-50 кандидатов, нанимают одного, бывает что вообще не нанимают. И процесс дает много дополнительного профита: получаешь знакомство с рынком, спектр вознаграждения, многое узнаешь о работе других компаний, получаешь сетку теплых контактов, которые не подошли к конкретной позиции, но могут подойти к другим. Или сейчас не готовы менять работу, но это может измениться. Самая долгая история контакта была около двух лет - человек устойчиво работал на своем месте, а потом в его компании началась реорганизация. Или, в другом кейсе, человек ушел из компании делать свое дело, а оно не полетело. А вот жесткий хантинг - не работает, если человек доволен своим местом - то он не уйдет. А если уходит - значит были какие-то реальные причины.
При найме важны не только хард, но и culture fit. Если понимаете, что по хардам - хорошо, а по культуре - не подходит, то явно обсуждает риск с кандидатом. И кандидат явно говорит - есть риск или нет. А дальше смотрят, что по бизнесу. И да, бывает, что кандидат не вписывается. Бывает, что идут на риск, тогда важна отстроить границы. Если кто-то не включает камеру на зумах никогда - проговаривается особенность. И строят модель взаимодействия с их учетом, такие кейсы тоже есть.
= Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях =
Проблема, что операционка кушает все время - распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 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, когда за счет изменения ценностей, атмосферы получалось добиться впечатляющих изменений. Первый - крупная компания, там владелец говорил о низкой прибыли, а директор - что для прибыли нужно расширяться, без этого ничего нельзя сделать, а людей и так не хватает. Ключевым изменением было то, что директору был назначен наставник с очень высокой внутренней планкой качества. полученной на одном из прежних мест работы, принцип "делай лучше всех или не делай". И он сумел личным примером такого отношения вдохновить директора, от того такое отношение перешло к топам. И в результате удалось существенно изменить ситуацию без расширения. Второй кейс - служба обращение во ЖКХ, единое окно, где сотрудники были полностью демотивированы, замучены разбором жалоб, поток которых не иссякал. И у них сложилась культура вообще не реагировать, а при этом каждая жалоба повторялась многократно, ситуация усугублялась, люди начали разбегаться. Тут в проекте работал психолог с высоким чувством личной ответственности, которое он тоже смог передать - и оказалось, что с жалобами вполне можно разбираться, так что поток вторичных жалоб начал сокращаться. Люди увидели свет в конце тоннеля, отношение изменилось.
А в конце была игра, всем раздали карточки с ценностями, предложили у кого совпало с личными - выйти и рассказать, а если не совпало - посмотреть у соседей, поменяться. И примерно десять историй, очень разных мы услышали.
В целом доклад - понятный, содержание ценностей действительно важно. Хотя для многих менеджеров и владельцев это является открытием, все-таки точка зрения, что у всех нормальных людей более-менее одинаковые ценности и они совпадают с моими - очень распространена, для людей бывает открытием, насколько люди разные. Хотя, казалось бы, в школе он это видел у одноклассников. Но почему-то забыл.
У меня к материалу доклада есть следующие дополнения.
# Эльвира назвала самую распространенную причину, почему ценности компании остаются пустой декларацией. Она в том, что руководство написало их для подчиненных, а не для себя. И не руководствуется ими при принятии решений: при выборе нового проекта, при распределении премий и иного вознаграждения, при назначении на должности. Люди видят, как к ценностям относится руководство - и поступают соответственно.
# Люди по-разному понимают слова "ответственность", "справедливость", "эффективность", не говоря уже о тех, которые содержат оценку, например "хорошая работа" или "успешный проект". Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех без стратегии": для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антипаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел на встречу во время" означает "опоздал не больше 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 - тоже много классов и файлов. И это все путается.
Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
# Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
# Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
# Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
# Для связывания разных объектов используется 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. Получил похожий список. Нужна ли архитектура, которая сама по себе работает лишь после череды дополнительных изменений? Кажется, навык придумывать новые архитектуры все ещё востребован...
{{wl-publish: 2024-11-21 16:07:09 +0300 | MaksTsepkov }}
