2024-11-21: MergeConf - теперь в Москве
15-16.11 в Технопарке Сколково прошла MergeConf. Конференция впервые в Москве, до этого несколько раз проходила в Иннополисе, и весной я там был и выступал. На мой взгляд, площадка Технопарка — не слишком удобна для конференций. так как зоны стендов и докладов оказываются разнесены между собой, и нетворкинг не слишком получается. Впрочем, в спикерской нетворкинг был достаточно активный и несколько слотов я пропустил. Конференция шла два дня в восемь параллельных потоков докладов, на некоторых из них залы были переполнены. При этом записи не будет, так что пропущенные доклады ушли безвозвратно.
Я выступал с докладом Системное мышление: что это и зачем нужно разработчику и аналитику?, продолжающим мою серию докладов по этой теме, начатую год назад на AnalystDays. Доклады не повторяют друг друга: тема — необъятна, а я меняю содержание и ставлю разные акценты. Кроме того, каждый доклад мне самому приносит новое понимание в процессе подготовки и обсуждения с ПК и участниками. Следующий доклад из этой серии будет на следующей неделе на Teamlead.
Как обычно, я публиковал заметки о докладах прямо на конференции, и теперь их собираю в отчет. Несколько докладов — очень содержательные, конспект — длинный и не поместился в один комментарий телеграма. И я хочу пожелать организаторам успехов в развитии конференции.
Содержание
[убрать]- 1 Владимир Лазарев из AML Crypto. Криптовалюты под прицелом: Как защититься от угроз и предугадать новые правила
- 2 Денис Цветцих из T-Bank. Эффективные DomainEvents из DDD
- 3 Илья Баксанов. Идеяспособность: как думать креативно, адаптивно и продуктивно?
- 4 Яна Шаклеина из Outline Tech. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей
- 5 Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать
- 6 Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса
- 7 Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях
- 8 Анастасия Валуйская из VK. Эффективный менеджер как им не быть или все же быть?!
- 9 Эльвира Абзалова из Игрокрафт. Синхронизируй это! Как сделать команду сильной и слаженной на уровне ценностей
- 10 Евгений Паромов из Evrone. FSD: 3 главных недостатка после 3 лет использования
Владимир Лазарев из 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. Получил похожий список. Нужна ли архитектура, которая сама по себе работает лишь после череды дополнительных изменений? Кажется, навык придумывать новые архитектуры все ещё востребован…
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.