2023-03-05: TeamleadConf-2023 - как всегда вдохновляет и дает много ценного

Материал из MaksWiki
Перейти к: навигация, поиск
О других конференциях

На TeamleadConf-2023 я был только первый день, а потом уехал по своим делам. И это очень жалко, потому что во второй день наверняка было много интересных докладов, как и в первый. Более того, я пропустил доклад Анны Обуховой, потому что он шел параллельно с моим собственным. но, надеюсь, я посмотрю в записи хотя бы часть из докладов и тогда дополню отчет. А пока - отчет о тех докладах, которые я посмотрел. Среди них - великолепные доклады Макса Дорофеева и Филиппа Дельгядо. Еще хочу отметить доклад Андрея Грицевича о применении практик социократии в дочке Ростелекома для улучшения процесса, в дополнение к LeSS, используемому как основной организационный фреймворк.

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

Мой доклад Профстандарты и модели компетенций - желания и возможности

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

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

Максим Дорофеев. Слои сопротивления и логические обоснования

Как всегда у Макса, доклад сочетает содержательную информацию, практическую работу и множество юмора и историй. Макс работает как тренер и считает, что результат обучения - не знания, а новые поведения. А если люди послушали, но не делают, то обучение провалилось. Это проработано, есть схема мыслительных слоев сопротивления у Голдратта. Если один человек приходит к другому, объясняет что-то и говорит "давай делай", а тот не делает - он застрял на одном из слоев. Есть интерпретации от 4 до 9 слоев, самая популярная 6, а у него - 5.

Вот они, на примере практики "лежа в постели перед сном не упыриваться в смартфон".

  1. Я не понимаю, какую проблему мы решаем. Объясняешь: экран, синий свет, нарушает выработку мелатонина и рефлекс засыпания.
  2. У меня этого нет. Может быть действительно нет, так бывает. Есть люди, у которых нет ваших проблем. Повод поговорить: у тебя никогда не было, или была и ты решил. А может, не понимает, что симптомы - следствие проблемы. Глаз дергается и ненависть людей потому что ты плохо спишь. Нет, это люди уроды и я нервничаю. Дальше с этим работаешь.
  3. Проблема есть, но я Не согласен с путем решения. Может, не понимает, как предлагаемый способ ее решает - тогда надо объяснять. А может, у него другой способ - стоит обменяться, обсудить.
  4. Я признаю проблему и способ решения, но боюсь побочных эффектов от решения. Спросить: ты так думаешь или это твой эмпирический опыт? Поговорить. Может будет готов попробовать.
  5. Все понимаю, но прокрастинирую. Обычно это невербализуемый четвертый.

Очень полезный вопрос при обсуждении: "вы так думаете, или это ваш личный опыт?"

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

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

  1. Хорошо, когда связь звучит стройно и грамматически верно. Не "если занятия спортом, то здоровье"
  2. Надо, чтобы использовали только четкие и конкретные понятия. Часто используют мутные термины без смысла. Что такое "регулярный", "реже".
  3. Помимо если-то должна быть связка-обоснование "потому что" - почему одно следует из другого.
    1. В обосновании (потому что) должно быть третье понятие, которого нет ни в причине ни в следствии. С учетом синонимов. Иначе это - тавтология "Если мы внедрим CRM, то поднимем продажи, потому что CRM увеличивает продажи."
    2. Утверждение в обосновании должно быть истинным.
    3. Обоснование должно объяснять связь если-то.

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

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

Алексей Гусаков из Яндекса. Научный руководитель vs бизнес-менеджер: как управлять R&D

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

Инженерная культура + Продуктовая культура = культура Яндекса.

К сожалению, именно про баланс было не так много. Но был рассказ о работе по улучшениям существующего и по организации R&D, текущим трендам, которые они считают перспективными.

6-7 лет назад Алексей занимался нейросетями в поиске, тогда это был прорыв. Сейчас он не один, в его области 1000 человек. Как руководитель он опыляет команды, не забывая что в каждой из них есть более опытные. Ключевая задача - поиск баланса. Сохранять технологическое лидерство и обеспечивать технологии заказами от бизнеса.

Все поле делится на три части

  • Существующие продукты и заказы от них - тут все понятно. Улучшения - по понятным метрикам, легко измерять, трекать прогресс и так далее.
  • R&D - уже инвестируем, но результат будет только через некоторое время. Можно надеяться, что будут использовать, но без гарантий
  • Зона, где не инвестируем, только мониторим статьи. Она очень большая, во все инвестировать нельзя

Хотя улучшения продукта понятно по результатам, в ней тоже интересно, там есть наукооемкие штуки. Пример - быстрые ответы в поиске. Там выбирают кусочек сайта. И если мало - нет доверия, а много - скучно и бесит. Задача: увеличить инфоплотность ответов. Разметка вручную - люди дают слова, которые можно срезать. Дальше обучение, и срезается. 17%

Его роль в улучшении:

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

С R&D сложнее. В бизнес-подходе невозможно появление штуки типа ChatGPT - она умеет очень многое, и стихи сочинять, и на вопросы отвечать и многое еще. Обосновать бизнесу - зачем мы это делаем, при отсутствии образа результата. И команду тоже сложнее мотивировать, потому что явного результата тут тоже нет. Но надо искать потенциальные ниши применения, при чем желательно с распространением на всю компанию. Если текстовая обработка - не только поиск, а везде где тексты. И картинки тоже везде, где мультимедиа.

В R&D надо следить за трендами и выбирать.

  • Сейчас - генерация изображений. Зачем? Сейчас - не знают, но диффузионные модели набирают обороты, и внутри них выучиваются новые представления о картинках, которые можно использовать. И нынешние картиночные тушки заменятся диффузионными. Да, мы не знаем, как сейчас использовать - есть нишевые стартапы (логотипы, аватарки) - оно взлетает и падает. Никто не применил такой подход, как ChatGPT в целом, только по частным нишам.
  • Синтез речи. 1.5 года назад начался, но пока не инвестировали. Обучаться не на малой выборкой, а на всем видеомассиве интернета.

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

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

Зона неизвестного. Тысячи статей в разных областях. Надо смотреть, можно видеть какие темы набирают обороты. Но вопрос - что взлетит - открыт. Ретроспективно - они неплохо справляются. Например, в Inforced learning atari games - не пошли, а вот в большие языковые модели - углубились. Тут они отстают от open.ai, но существенный задел есть. И он сожалеет, что не вкладывались сильнее. Но это - текущая оценка, через полгода может оказаться, что то, что не вложились в atari games было ошибкой.

Он выбирает баланс и тренды, но не один - идут семинары, разборы статей и обмен практиками использования и так далее.

Про баланс: пару год назад решили, что процесс R&D - fix capacity от общего объема. Но он работает над увеличением пропорции.

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

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

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

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

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

Критика: конструктивная и НЕ конструктиваняя, на иностранном языке. Надо вспомнить, кто критиковал конструктивно - и учиться быть таким ментором. У него личный пример - Илья Сегалович. Идешь с новой идеей, 20 минут разговариваешь - и уверен, что придумал новый стартап.

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

Был ученик, которого начал валить научный руководитель на защите. И это - травма, он классное делает в команде, но не умеет защищать. Такой корень можно удалить, 10 минут.

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

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

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

Мы не можем поднять зарплату, но наймем такого же кто будет делать тоже, а получать больше - не надо так.

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

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

Харды. На каком-то этапе инвестировать в научное сообщество - потому что оно цитадель для прорывов.

Какой уровень добра - определяйте сами. Какой хотите для себя.

Метрика - чем меряешь другого.

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

Софтскиллы: убедительность, умение слушать, публичные выступления, умение владеть собой, юмор.

Умение слышать: Кто задает вопросы - управляет беседой. Хотите возглавить совещание - начните вести протокол и задавать вопросы. Включая уточнения и корректировки. Только конструктивно: вдох - улыбка - вопрос конструктивный.

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

Убедительность. Убеждение против Принуждения. Доктор против Гопника. Доктор убеждает, гопник принуждает. Маленькая меритократия на работе. Только делиться властью, особенно если подчиненный умнее.

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

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

Филипп Дельгядо. Команда как конструктор: сортируем детальки

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

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

Началось все с метафоры. Выбираем людей как машинку. Седан, пикап... пусть седан, средний класс middle, опции - SQL, стрессоустойчивость - не маркий. Так не работает. Наняли Java-разработчика, который замечательно пишет сложные алгоритмы по постановкам. А нам надо делать отчеты для ЦБ, там тоже есть сложные алгоритмы, но мало, зато сами постановки - мутные, надо работать со странными документами и общаться с людьми, которые за отчеты отвечают и тоже как-то пытаются в документах разбираться. Он это - совсем отдельные скиллы, разработчик этого не умеет.

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

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

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

У всех похожие проблемы:

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

Как нельзя использовать модели?

  • Нельзя использовать для предсказания поведения, качества коммуникации, эффективности
  • Нельзя делать основанием кадровых решений

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

Что дают модели?

  • Можно понять насколько разные
  • Можно разобраться в своих сильных и слабых сторонах
  • Эффективный язык для обсуждения - ссылаемся на язык
  • Помогают убеждать коллег: сотрудник закрывает Шейпера по Белбину - это нормальный аргумент для HR о пользе сотрудника.

У него - собственная модель Инфономика, в ней три оси.

  • Enterprise people vs startup people
  • Придумать свое (NIH) vs взять библиотеку (github)
  • Процесс (отлаживаем, перфекционизм) vs выкатить быстрее

Enterprise NIH process позволить себе могут только google, потому что такие люди они никогда ничего завершенного не сделают

Роли в группе

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

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

Культура, которая ест стратегию. Что такое хорошо, что такое плохо. Мемы и шаблоны.

  • В одной команде давали 5-6 произведения Стругацких и этим выравнивали культуру.
  • В другой все были музыкантами, принести инструмент, обсуждение репетиций, тихонько посейшенить, и так далее. Его как-то терпели
  • На текущей работе - концерт Аквариума, и все подпевали. Про разделение общего важного.

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

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

Карта навыков: важное для выполняемой работы технологии, инструменты, корпоративные связи, регулирующие документы, история возникновения legacy (почему сделано так странно). С конкретикой, не SQL, а оптимизация запросов к авроре или на python

Кажется, самая простая карта, но почему-то вместо конкретных требуемых навыков получаются обобщенные компетенции.

Редкие навыки

  • Домовой эльф. Каждые две недели новый отчет для регулятора - может делать рутинную работу. Часто недооценивается, а при уходе - провал команды.
  • Книжный червь - умеет читать документ то, что написано. Прочитает 1000 страниц руководства или нормативки и извлекает смысл
  • Энциклопедист - знает все, пусть поверхностно. Важно: когда нужно быстро решать проблему, он часто дает верное направление
  • Траблшутер. Был проект на Java, написанный питонистом - умел локализовывать ошибки в жутком коде.

Их стоит уметь вычленять и активно думать, кто их закрывает у вас.

Как это соотносится с матрицей компетенций? Очень опосредованно. Матрица компетенций

  • про компанию, а не команду
  • про должности, а не про людей
  • про оценки, а не возможности
  • упрощает работу HR, а не приносит пользу тимлиду

Карты тимлида - про конкретную пользу, использование уникальности, без меряния крутостью.

Карта ответственности. За артефакты, за активности, за качество.

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

Карта проблем.

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

Это далеко не все карты.

  • Карты часовых поясов (и активности по часам). Например, нужен человек в Новой Зеландии или сова.
  • Карта циклов эффективности. Был UX, который одну неделю в месяц не могу выйти из дома (по разным причинам). У многих различается по временам года и так далее.
  • Карта активности - что умеет делать. Она не очень полезная - мы и так это умеем. Вопрос в том, что плохо умеем.

Польза не в том, чтобы встать и рисовать карты. Надо думать.

  • Рефлексировать работу команды, понимать чем занимаемся.
  • Проблематизировать
  • Собеседования - надо помнить про закрытие проблем сотрудниками. Вася - не трабшутер, но аналитик, снимет с Пети, тот займется качеством. Не просто писать код, а кого разгрузит. У него было, что был только один github, а NIH
  • Обучение. Не всех учить SQL, потому как нужно, а конкретно решение проблемы с постановками
  • Продвижение - логично объяснить, почему повышение.

Итого

  • ИТ всегда предполагает обучение
  • Разные команды требуют разных карт
  • Все карты постоянно меняются
  • Собеседование бесполезно без лидера команды - только он знает карты

Литература. Щедровицкий. Оргуправленческое мышление. Тяжелая, философская.

Карты в документированном виде - не очень полезны, потому что быстро меняются. Плюс для этого ярлыки надо делать политкорректным, это сложно. Так что тут надо понимать выгоду. Плюс какие-то карты появляются на собеседовании. Можно как результат выдать: набор скилов которых не хватает.

Форма - как любишь. Он любит списки. Есть любители майндмапов, таблиц, зеттелкастена.

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

Эффективность против простоты управления.

  • Его подход усложняет набор команды, повышая ее эффективность.
  • А можно упрощать набор и управление командами, снижая их эффективность

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

Вопрос: Если один человек взял ответственность - как бороться с бас-фактором. Ответ: это складывается, кому-то нравится, и он неформально берет, и не всегда согласен взять формально. Но это не значит, что только он может. А если она критична - то поручать кому-то еще, а лучше - поручать работать в паре.

Вопрос: Что делать, когда звезда, и остальные чувствуют неполноценность. Отчет: это реально возникает, это бывает грустно. И общего ответа у него нет, это надо по месту.

Никита Дубко из Яндекса. Мастер D&D как стиль управления командой

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

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

Дальше - тезисы.

  • Как и в игре, у члена команды должна быть Карта персонажа с его характеристиками. И нам нужна сбалансированная команда: Танк, ДД () делает задачи, Маг, Хилер (техдолг и т.п.).
  • Команде надо давать проекты по силам. Низкоуровневым командам рано идти на Тараска. И надо прокачивать персонажей.
  • Как и в игре, игроки сами выбирают путь своего героя. Они редко спрашивают мастера, куда качаться. Но при этом мастер должен создать условия, иначе игрок уйдет из игры. Новые навыки приходят с опытом. Можно добавлять, не обязательно задачами из проекта.
  • Снаряжение. С правильными артефактами игроки лучше проходят квесты, хотя гарантий артефакты не дают. В ИТ это платная IDE, удобные стулья и так далее.
  • Мультиклассирование. Если на первом уровне - варвар, на каком-то можно выбирать барда. Мультиклассирование делает команду сильнее. Разаработчик попробует QA, дизайнера научить верстать... Они сами выбирают путь, но попробовать могут и по рекомендации.
  • Новые игроки. Летопись игры помогает новичкам проще вливаться в приключение. Документируйте историю проекта.
  • Старички часто помогают новичкам. И тут важно не формализовать и не перейти на микроменеджмент, это вызывает сопротивление, но при этом присматривать, чтобы под опеку взяли.
  • Понятная история. Если персонажи не понимают куда идти и какой выбор - игра сгнивает. Так и в работе: если приносите задачу - объясните результат, зачем делать. А не как набор действий, которые надо выполнить.
  • Неписи - те, кто помогают команде пройти путь. Их вводит в игру мастер и отыгрывает. В реальной жизни это - внешние стейкхолдеры, эксперты и другие люди. Они из жизни, но мастер знакомит с ними, дает контакты. Надо уметь ходить и общаться с неписями, это отдельные компетенции.
  • Приключение. Хорошо бы давать время на подготовку. Побродить, поспрашивать что делаем. Если неделя - хотя бы день. А не резко в путь.
  • Боевка - занимаются все. Организована по раундом, 1 раунд - 6 секунд, хотя может длиться час. И это аналогия со спринтами. Задача мастера - дать возможность команде сделать за раунд максимум.
  • Помехи и преимущества. Игроки стараются использовать, если они их видят. И в команде их часто достаточно подсвечивать, не надо пушить.
  • Ускоряем cycle time и счастье команде
  • В D&D есть реакции - возможность на какие-то действие извне совершить свое. И в работе тоже. Игроки - забывают. Хорошо бы обвешаться мониторингами. И подсветить, что можно отреагировать.
  • Подготовленные действия: сейчас не делаю, но в следующий ход сделаю это, если произойдет это. Готовимся. Если человеку нечего делать, можно подготовиться к будущему.
  • Концентрация. Маги держат, заклинание - одно. Они - одни из самых мощных в игре. В разработке - тоже самое. Не дергать, а ждать окончания задачи.
  • Свитки. Многие маги их таскают, не изучая заклинания. Некоторые заклинания нужны редко. Это аутсорс, внешние эксперты.
  • В процессе игры. Вы создаете мир, игроки идут. Игроки не любят, когда их ведут по рельсам. В разработке - так же. Разработчики должны принимать решения, которые влияют на проекты.
  • В D&D игроки любят влиять на мир. И разработчики любят влиять на проект. При этом мастер должен просчитывать влияние на мир. И негатив и позитив. Формула "Да, но..." Когда игрок предлагает дичь, не говорите нет. Говорите про препятствия. Ты сделаешь так, что получится, обсудим плюсы и минусы.
  • Персонажи переоценивают силы, идет не так. Их съел дракон, он перестал играть. Уход должен быть эпичным, запоминающимся. Может он захочет вернуться. Так и в команде, когда уходят.
  • Усталость. Люди устают делать однотипное. Переключаются на Ваншоты. В D&D игра может быть несколько лет, у них 2.5 года. А это - на 4 часа. На работе могут быть хакатоны или какие-то небольшие прикольные проекты.
  • Сайд-квесты - дополнительные проекты, которые помогают текущему. Сходите на тот маяк, пригодится, н не обязательный.
  • Игроки любят находить плюшки - тайники, золото, артефакты. Команду надо награждать.
  • Хорошее настроение. Даже подрались персонажи - но важно, чтобы атмосфера была хорошей. Чтобы не было "вот опять нам с ними на созвон...". Тогда надо что-то делать.
  • Обратная связь. Мастера спрашивают "а как игра". И рассказывают, что не сделал. Так и в команде ретроспективы. Ходить и слушать чтобы понимать - полезно или нет.
  • Мастеру полезно играть. Чтобы понимать, что игроки делают. Постоянно кодить не обязательно, но какие-то задачи делать - чтобы понимать проблемы.
  • Импровизация. Мастеру команда обязательно преподнесет что-то. Поэтому опорные точки, а не сценарий целиком - команда не пошла. Так и тут, вы продумали проект, декомпозировали. А через месяц направление сменилось.
  • Знание мира - важно. Хороший мастер знает религию, политику, устройство города и так далее. Так же и на проекте. Блокнот с заметками. Носишь и все записываешь.
  • Цель приключений. У игроков обычно есть цель и мотивация. Вы можете считать, что команда хочет запустить проект, но попробуйте узнать, зачем разработчики в команде. Они за разным - есть кто за деньгами, есть кто за изменением мира. И это надо понимать и учитывать.
  • Мотивация и отыгрыш. Как игрок справляется со своей ролью. Игроки не любят, когда у них перехватывают контроль. Они придумали, а мастер все равно по-своему. Так и в работе.
  • Первый закон Паркинсона. Работа выполняется столько, сколько времени отведено. Как и в игре. Если сутки - найдут способ. Дедлайны должны быть.
  • Игрокам интереснее играть, когда игроки сами описывают свои действия. Ударил топором - как? В работе - так же. Разработчики сами рассказывают, что делали на демо. У них - меняется выступающий на демо.
  • Правила можно менять, чтобы игра становилась интереснее.
  • Учитесь у других мастеров.
  • Как поделить лут из дракона, Правила должны быть заранее, а не в момент деления. У них - review, и правила объясняют заранее, да еще внутри говорят с теми, где могут быть проблемы.

Дмитрий Неверов из X5 Tech. Команда как продукт тимлида

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

Дмитрий 8 лет был ИБ, сейчас 5 лет в ИТ прокачивает команды. У него в команде был взрывной рост: в 2020 - 3 человека, 1 джун, 1 направление, 2021 уже 13, из них 8 джунов, сейчас 2023 - 28.

Взрывной рост в 2021 привел к постоянным возвраты с дефектами, внутри ссорятся, проблемы вываливается до СТО и других топов.

Причины понятны.

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

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

Что рекомендует теория? One2one с каждым, лучше по паре часов - а на 13 человек это 26 часов в неделю. Индивидуальный подход, потому что люди - разные, он смотрел MBTI - там 16 типов как люди думают, а в DISC, который про взаимодействие - типов еще больше. Получается, что Вову проще уволить, чем разбираться, а лучше уволиться самому.

Он пошел к HR, а она спрашивает: какой у тебя CVP (customer value proposition) для компании& B он понял, что не хочет быть PO в доставке, хочет работать с метриками и развивать людей.

И он пошел от продуктового подхода, там метрики понятные. CSI (customer satisfaction index) для команды меряют HR по своей методике, а он начал мерить персональный. ТТМ (time to market), возвраты из релиза, эскалации инцидентов и проблем, возвраты в анализ из разработки и с демонстраций, когда сделали не то.

Продуктовый подход - необходимый результат оптимальным способом.

  • Фокус на ключевых действиях
  • Польза для потребителей - что команда дает компании. value
  • Работа с гипотезами. Нет таблетки. Разные модели обратной связи - что-то взлетит
  • MVP - CSI команды 5 баллов вместо 4, а дальше будем думать.
  • Тимлид отвечает за максимизацию ценности - значит ценность команды надо растить каждый день.

Продуктовый подход работает через ценность, метрики и гипотезы.

Как начать изменения

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

Чтобы раскачать - надо показать ад: собрать команду, накидают красные стикеры. Он собирал ретроспективу, было 50 красных, 20 желтых, 10 зеленых. И на обсуждении были активисты, с ними потом 1:1 за пару дней и 4 человека включил в продуктовую команду изменений.

Роли в команде изменений - по аналогии с обычной продуктовой командой.

  • Product Owner - не уйти в закат, порождать ценность.
  • Менеджер продукта - отвечает за сроки тестирования гипотез, планы раскатки и отката изменений
  • Маркетолог-аналитик - работа с метриками, красный и зеленый флажки
  • Scrum master. Список задач, смотреть как идет, одергивает менеджера продукта, а то он не остановится
  • Дизайнер-интервьюер. Проводит интервью, делает лендинг.

Я хочу отметить, что это - очень детальное разделение ролей. Если рассматривать в метафоре пути, то PO отвечает за образ цели, менеджер продукта проектирует путь к ней, SM обеспечивает движение по пути, а маркетолог-аналитик - сопоставляет план-факт движения.

Дальше

  • Видение. Сделали, пришли к ребятам - 170 новых идей.
  • Jira или kaiten - работа с бэклогом. Обычный канбанчик.
  • Гипотеза. Защита команды от экспериментов. формулировка Если - то - тогда. Ключевая и ближайшая метрика, критерии успеха; текстом описано что нудно сделать; посчитать затраты команды в часах на действия.

Мы в продукте

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

Интересные кейсы из процесса.

  • Когда Ване 7 раз рассказывали про продуктовый подход - его трясло. А потом его затащили в команду изменений - и он отсекает плохие гипотезы.
  • Обсуждение фейлов. Гипотеза: если ребята будут рассказывать про фейлы, то другие ребята не будут их повторять. 30-40 минут, пришли к формату презентации. Проклятие знания, Эффект авторитета.
  • Симулятор для экспертов, первоначально назывался бойцовский клуб. Позвать людей из производства, они будут защищать видение, мы думаем. Первый раз, ребята накидали стикеров. У джунов все меняется в лучшую сторону, а вот мидл и сеньор - без изменений. Получился инструмент онбординга.

Выиграли больше 4 единиц в CSI.

Надо:

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

Как зафейлить

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

Заключение. Если вы чувствуйте боль - ретро. Обсудить. Сделайте команду. Гипотезы, проверка с метриками.

Андрей Грицевич. Можно ли взращивать бирюзовые практики самоуправления при разработке продуктов в дочке Ростелекома, не будучи топ-менеджером?

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

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

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

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

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

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

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