В Питере возобновился IT Global Meetup. Один день, 15 сообществ, 50+ спикеров, 1200+ участников. Для тех, кто не знает - это замечательное мероприятие, объединяющее IT-шников. Организуют его Питерские сообщества, которые объединены в сообщество сообществ http://piter-united.ru, проходит оно с 2013 года несколько раз в год. Но последний митап проходил еще до Ковида, в 2019 году. Я был на многих митапах, потому что тут очень интересная коммуникация. И в этот раз я встретил много знакомых.

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

Митап начинается поздно, в 12, так что докладов получается всего четыре слота. Некоторые поделены на два короткими докладами. Формат выступлений - разный, много интерактива и обсуждений. Все выступления, на которых я был - интересные и очень разные. Я унес с митапа интересный формат интерактива с залом, который был у Юрия Санникова и метод волшебных друидов для работы с ограничениями в TOC. А обсуждения нужны ли HR и нужны ли менеджеры дали фокусировку собственного понимания темы. Что интересно, оба обсуждения были не на профильных островках, а на других площадках, и, возможно, это делало обсуждение таким интересным.

Юрий Санников. Проектирование API. Сказ о аналитике и архитектуре. Островок аналитиков

Очень интересный формат. Участники проходят тест, отвечая на вопросы проектирования API по конкретным задачам. А потом Юра подробно разбирает ответы, при этом, что на экране - варианты, выбранные участниками. Вопросы - о вариантах взаимодействия, протоколах, есть продвинутые, например, о технологиях построения кэша (redis), и не везде правильный ответ - единственный. Построение API - серая зона, при этом зависит от культуры компании: в одних это отдано на откуп разработчикам, а в других - область ответственности аналитиков.

Владислав Архипов. Что еще надо знать аналитику при проектировании API. Островок аналитиков

Выступление началось с вопроса о том, почему API правильно проектировать именно аналитикам, а не отдавать это разработчикам? Ответ автора: потому что они знают бизнес-смысл операции, и бизнес-ограничения. Аналитик - связь разработки с бизнесом, он знает все продукты, фронт и бэк, понимает как это работает целиком. И нефункциональные ограничения - у него.

Я тут хочу заметить, что реально ответ на опрос зависит от разделения труда. Где-то именно аналитики интегрируют разные продукты в единое целое, а где-то это на стороне разработки, а аналитики работают на уровне UI. Проектирование API требует достаточно хорошего технического уровня, особенно для асинхронного взаимодействия. С другой стороны, часто обработка особых ситуаций, связанных с долгим ответом или падением соединения требует понимания бизнес-уровня, которого разработчикам не хватает, или проектирования взаимодействия с пользователем в этом случае. Разработчики, по опыту, слишком рассчитывают на то, что все будет хорошо и быстро.

А теперь вернемся к докладу. Что не должен делать аналитик? Он не должен проектировать техническую реализацию: языки, библиотеки. Архитектурный стиль тоже обычно задан архитектором: REST/SOAP/RPC и прочее выбирают они, и правила безопасности тоже.

Идеальный процесс разработки: требования - спецификация - тест на моках, особенно когда высоконагруженный API - передача в разработку - тестирование (может, силами тестировщиков)

Архитектуру делят на слои: корпоративный архитектор за ландшафт целиком и архитектор в команде.

1. Бизнес-архитектура целиком
2. Маппинг бизнес-функций на сервисы
3. Взаимодействие сервисов, правила и ограничения

На третьем уровне появляются ограничения от ранее разработанных сервисов - проект не в чистом поле. И надо сопрягать требования по нагрузке и скорости отклика от бизнеса с техническими ограничениями выбранных протоколов.

Ищем вдохновения для написания API. После декомпозиции - драфт спецификации. Если сложно или типовая задача - берем API соседей и подсматриваем. Например, аутенфикация - она везде есть. И всегда можно собрать синк с разработчиками и обсудить. Например, пакетные запросы: используем массив или пакуем в строку.

Для тестирования на моках - Swagger (ушел из России), Postman и ряд других средств. Postman поднимает моки хорошо.

Дружим с разработчиком. Он - друг аналитика. Он должен спецификацию проверить. И с тестировщикам. Если постман-коллекцию написали - пусть прогонит по своим тест-кейсам. Он тонкие месста проверит.

В конце была часть о собеседованиях. Часто просят написать запрос на листочке или в простом редакторе, например, word. Он - против, так писать yaml - неудобно. А детали часто не помнишь. Но в целом можно идти по тем же правилам, что и в разработке. Не стесняемся задавать вопросы, вспомнинаем свой опыт. И заглянуть в спецификацию, в принципе, нормально, хотя это надо явно уточнять: ведь в рабочем контексте она - под рукой. И вообще взаимодействовать с интервьюером полезно, его задача - не завалить. А вместо листочка можно попросить использовать нормальный редактор типа VS code.

Иван Абашкин. Волшебные Друиды: прикладная конфликтология и принятие решений. Островок SPM Club

Волшебные друиды, magic druids - это официальное название новой технологии решения конфликтов от института TOC (TOCICO). Whitepaper вышел в 2020, Иван его перевел, разобрался, начал применять. Ссылки на его статьи и материалы выложены в телеграм-канале, сделанном для выступления. В выступлении был рассказ о методе и время, чтобы попрактиковаться. Инструмент - не простой, и то, что дальше - моя интерпретация по выступлению, которая вполне может содержать ошибки.

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

Вообще для решения подобных противоречий в TOC уже есть инструмент - Грозовая туча, но он - сложный. Волшебные друиды - проще.

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

Метод предлагает структурировать позицию каждой из сторон в следующем виде.

1. Предлагаемое поведение, способ действия
2. Нежелательный сценарий, если это действие не сделать
3. Локальные нежелательные последствия от нежелательного сценария
4. Системные нежелательные последствия от развития локальных, нарушение цели, беда

При этом есть завязка: каждый предлагает свое действие для того, чтобы избежать беды, о которой говорит оппонент.

Структура изображена на рисунке из статьи Ивана.

Например, для ситуации с выпуском роутера:

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

Нарушение цели тут одинаковое, только причины разорения компании оказываются разные.

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

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

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

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

Типичные ошибки.

• Начинаем описание не с действий, а сценариев или следствий
• Обвинения вместо утверждений (он плохо кодит, у нас нет архитектуры вместо исправить архитектуру)
• Нежелательность сценария перепутана с действием - ее сразу написали, без исхдного действия
• Действия не содержат противоположности - не видно, почему нельзя сделать одновременно
• Уход в сторону от проблемы

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

Михаил Байбус. Эйчары не нужны. Островок Менеджмент и люди

Михаил - Vice-CTO в Umbrella. Но доклад - личная точка зрения, не связана с компанией. Этот дисклеймер был официально заявлен в начале выступления.

Выступление - фиксация взаимного недовольства между тимлидами и менеджерами C-level с одной стороны и HR - с другой. Пункты, по которым есть недовольство были зафиксированы Михаилом через опрос на нескольких мероприятиях. Ситуации понятны, встречаются. Иногда достигают такого накала, что возникает мысль, что HR - лишний элемент компании. Но основной вопрос - почему эти ситуации складываются и как их избежать - был за пределами доклада. Основной тезис Михаила по эому поводу: складываются по разным причинам, главное - обсуждать, а не игнорировать проблему, делая вид, что все нормально. И это - правильно.

Многие претензиии вызвали недоумение со стороны HR из зала: "где вы взяли таких непрофессиональные HR", особенно это казалось претензий C-level. На мой взгляд, реакция объяснима: в зале были HR из сообщества, которое тоже делало свой островок, и там - профи. А в компаниях - разные. Так что можно послать HR в сообщество для повышения квалификациии, может, они просто не знают, что такая площадка есть. Но это подойдет, только есл есть осознание проблем и активная позиция. И есть риск, что повысив квалификацию - они сменят позицию HR, может быть со сменой компании, а на их место придут другие, с теми же недостатками. Вообще, если посмотреть с высоты, то это - часть системной проблемы цифрового мира, которой у меня посвящена отдельная статья "Реальность цифрового мира: проекты делает некомпетентная команда". В ней раскрыты причины ситуации, они объективны. И это надо принять как данность, и действовать соответственно.

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

Мысли начинающего руководителя к HR

• Объяснил бы кто, как сказать руководителю, что скоро порвусь
• Зачем заполнять этот очередной опрос
• Проще сделать самому, чем объяснить
• Чего вам всем надо?
• Как мне уволить Серегу, он не эффективен, но я не умею увольнять?
• Если ошибусь - меня уволят?

Кратко их можно поделить на две категории: "Я знаю сам, не мешайте" и "Я ничего не понимаю". HR либо не приходит, либо доносит решение верха по факту. Или приходит с формальностями - заполни опрос, заверши испытательный срок.

HR - не опора, а внешний раздражитель

• Вместо помощи отправляет руководителю
• Отвлекает на ненужные активности
• Основное для него - корпоратив с бюджетом, а на остальное наплевать
• Они притворяются друзьями, располагают - а дальше все сливают руководителю

Со стороны HR

• 10 раз объясняли лиду, как давать обратную связь
• Сколько раз повторять: нельзя строить семейные отношений с командой
• Господи, это изменение необходимо, чтобы сделать работу команды эффективнее, а команды легче
• Цитата дня: "где наша кола зеро?"

C-level (это chief чего-нибудь). HR фигово объясняет свои предложения: так надо, так принято, так было у меня в предыдущей компании. Не привязывает его к ситуации в компании, не объясняет эффект. И это выливается в раздражение.

• Ты хочешь 10 млн на корпоратив, а что это даст
• Зачем ДМС, если половина за границей
• Что там с моим запросом, котрый был 3 месяца назад
• Performance review - круто, только у нас не согласован рост ФОТ

Тезис про корпоратив вызвал очень неоднозначную реакцию зала. Были реплики: зачем нужн корпоративы, на которых напиваются и бьют морду.

Ожидания руководителя понятны: говорит на языке бизнеса, обосновывать приоритеты, управляет ожиданиями, не теряет фокус в потоке операционки. Только хочу заметить, что если HR всему этому научится, то, возможно, это будет уже не HR. Или HR в более крупной компании, а не у вас.

Раздражение HR от c-level

• Опять придумали, хоть бы объяснили - почему и зачем...
• Молодцы придумали, только личка от возмущенных сотрудников разрывается у меня, а не у вас
• Да найдите же 30 минут в расписании - я же хочу на ваши же вопросы ответить
• Но ведь договаривались совсем о другом?

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

Способы преодоления кризиса - каким путем преодолевается кризис

• Признание проблемы - другие могут думать, что все нормально
• Формулировки и аргументы - диалог
• Договоренность о пересмотре договоренностей - гибкость
• Совместная приоритизация - единственный фокус в момент времени
• Совместный план, короткие итерации, быстрые победы - доверие
• Регулярные емкие коммуникации, явная демонстрация результатов, системность

Говорить словами через рот. Если видите проблемы - не факт, что видит другой. А если другой видит - то точно не таким образом.

Нужны ли менеджеры - круглый стол на островке Delivery Community

На сцене было четверо участников, из них - двое менеджеров. При этом менеджер защищали точку зрения, что менеджеры не нужны, а не-менеджеры - что нужны. Зал активно подавал реплики, а как раз там было много сторонников менеджеров.

Дальше некоторый конспект обсуждения, наверняка неполный.

В начале дискуссии получилась забавная попытка апелляции к разумности сложившихся практик: "Подумайте, если руководители нанимают менеджеров, значит они подумали и увидели, что менеджеры полезны!" На это немедленно последовала реплика: "Руководители - и подумали? Вы всерьез?!"

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

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

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

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

Зачем же менеджеры полезны?

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

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

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

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

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

Был кейс из зала, который сводился к тезису, что команда 23-летних не сможет общаться с заказчиком 50+ из-0за разницы в опыте и ценностях, нужен менеджер-посредник, у которого 10+ лет опыта хотя бы. Я тут хочу сказать, что "по умолчанию" возраст ничего не значит, люди - очень разные. И действительно опытные люди 50+ нормально общаются с молодежью. А посредник нужен там, где возраст фактически оставил человека в прошлом, его 20-30 лет опыта - это многократно повторенный старый опыт, к которому он, почему-то требует уважения. И тут есть о чем подумать.

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

Я тут хочу заметить, что аргументы сторонников менеджеров, особенно из зала, носят некоторый отпечаток уверенности в избранности менеджеров. Корни такого отношения - в истории. В 19 веке в Англии было деление на джентльменов и всех остальных простолюдинов. И четкая уверенность, что джентльмен в силу своего происхождения может управлять чем угодно и хорошо с этим справится. Отпечаток этого до сих пор несет политическая система Англии, где министрами назначают не специалистов, а членов победившей партии. А из Англии такое отношение к менеджерам перекачивало в Штаты. Происхождение по пути заменили на правильное образование, но вся концепция MBA основана на том, что окончивший этот курс может управлять чем угодно. Противоположна ей германская концепция, в которой руководителей назначали ихз числа профессионалов, и именно она была воспринята в Российской империи, откуда унаследована в СССР. А в 90-е пришла американская концепция, так что сейчас - смесь воззрений, которую часто не осознают.

На этом я завершаю отчет с ITGM и надеюсь, что перерыв закончился и встречи будут продолжаться, как и раньше.

Еще обо мне…
Мои доклады
Мои статьи