2022-05-20: Teamlead - вдохновляющее продолжение Highload

Короткая ссылка: Teamlead-2022

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

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

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

В этот раз к TeamleadConf присоединился KnowledgeConf, конференция по управлению знаниями. Понятно, что оно нужно не только тимлидам. Но конференция - новая, первый раз была в 2019, а потом наступил ковид. В 2020 ее провели online, а в в этот раз решили объединить с Teamlead, потому что делать автономную конференцию - дорого, а перспективы собрать участников - неясны. Управление знаниями - проблемная область, потому как, с одной стороны, оно всем нужно и всем им по факту занимаются - когда сохраняют знания о проектах, онбордят сотрудников, передают знания от уходящих, налаживают обмен опытом, а, с другой стороны, это делают в рамках основной деятельности и обычно без выделенных позиций специалистов, наряду с прочим. И потому для потенциального участника конференция проигрывает по сравнению с профильными. А ведь управление знаниями - довольно старая дисциплина, в ней есть свои практики и методы, которые позволяют существенно ускорить решение всех этих задач, сделать их более уверенными.

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

Мой доклад

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

Алексей Обровец. Питательная среда для качественной коммуникации

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

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

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

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

• На Highload куча выступлений об использовании технологий. Все умеют. А вот с человеческими взаимоотношениями надо тоже самое.
• Разработчики хорошо знают как понимать английский язык, но не умеют разговаривать. Так вот, с русским - тоже самое.
• Детский сад Монтессори. Правила: перед обедом поем песенку и собираем игрушки - и садимся обедать. И на 2-3 день новые уже включаются - это атмосфера. Формируйте атмосферу.
• Если нет данных, чтобы подтвердить твою гипотезу на совещании - помолчи. Единственное - можешь спросить вдруг у кого есть данные. А так получается порождение гипотез и обсуждение неподтвержденных гипотез на совещании - и на это уходит много лишнего времени, потому что разговор ни о чем.
• Пару раз внедрял Agile в группах разработки. Вроде как он про общение. И именно поэтому не работает. Потому что надо сформулировать, получить обратную связь, не взорваться, сделать выводы - а этого не умеют.

Базовый инструмент: Вдох - Улыбка - Инвестиция

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

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

• 70 лет в нашей стране не было личности идентичности: о фигу кто ты, делай свою работу. Из этого наследия надо выгребать.
• Кризис успешного человека, который думал только про бизнес и коллег, а тут задумался: а ты сам кто, кому я передам то, что делаю.

У многих нет личной жизни, есть много работы - и это неправильно.

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

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

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

Каким тоном читаете письма руководства. И каким тоном читает руководство ваши письма. Как читаете письма любимых, когда расстроены. Прием: дисклеймер в начале письма "читай, представляя, что я пишу с улыбкой", и дальше текст "ты сделал такой косяк, подумай, как это исправить, потому что мне совсем не хочется "

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

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

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

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

Налаживание коммуникация и атмосферы - не помимо работы, это и есть работа. What's on your wall should be in the hall. Если на стене "мы друзья", а по факту "мы конкуренты" - получается отвратительное одиночество. В жизни, не только на работе - это распространяется. Тимлид - роль, как мама или папа.

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

Формирование культуры.

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

Николай Волынкин. Ландшафт коммуникаций

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

С этим лучше работать системно и Николай дает инструмент. Матрица 4*4, по строкам - виды знаний: Продукт, Процессы и инструменты, Бизнес и деньги, Культура и принципы; по столбцам - круги людей: Мы, сотрудники компании, Новые сотрудники, Кандидаты, Рынок труда. В ячейках - светофор про достаточность знаний и их содержание. И там, где есть недостаток - надо строить коммуникации. Достаточность знаний - если люди хорошо справляются со своими задачами - значит достаточно, а проявляются проблемы из-за отсутствия знаний - то недостаточно.

Задачи:

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

И было множество конкретных примеров, проблем и их решений.

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

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

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

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

Что интересно про культуру? За что поощряем, как относимся к ошибкам. Конкретно.

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

Такие вопросы часто не задают.

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

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

Алексей Пименов. Рабочий процесс как процесс накопления знаний

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

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

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

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

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

Принципиальная идея: посмотреть на процесс не как производственную (сборочную) линию, а как процесс накопления знаний. Координаты: % реализации против объема накопленных знаний. Но есть тонкости.

• Выполняемые активности и накапливаемые знания бывают разные
• Интенсивность накопления знаний со временем меняется. Сначала пачкой, потом выскребаем ложкой.

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

Это продолжение и приквел прошлогоднего доклада в Питере про доски.

Татьяна Гаврилова. Моя твоя непонимай: когнитивные аспекты обмена знаниями в мире online

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

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

Когнитивная психология (cognitive sciencies, во множественном числе) изучает это, и центральным является понятие когнитивного стиля, который понимается как позиционирование на некоторой шкале. 10 таких шкал, касающихся преимущественно структурированию знаний, извлечение структур из потока информации, были рассмотрены в докладе. И стоит задуматься над своим позиционированием и над развитием соответствующих способностей.

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

Но до рассказа о когнитивных стилях надо было обрисовать ландшафт и современные изменения.

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

Но пока ничего страшного не случилось.

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

Основной источник - Марина Холодная. Шкалы.

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

Важно чувствовать когнитивный стиль говорящего и подстраиваться.

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

• Правило Альберта Меграбяна И Уинстона (1971). 7 - слова, 38 - тон, 55 - через движение. Но это - когда диссонанс, когда слова противоречат выражению лица и в других подобных ситуациях.
• Проблемы удаленности: тексты асинхронно, особенно большие - теряют информацию. Аудио и видео - получше. А еще - приватность. Говорящий с экрана - вторгается в твою комнату.
• Проксемика - как расставлять столы, чтобы не вторгаться в личное пространство. Оптимум 0.5-1.5 метра. Но сейчас выбросили в астрал, и все по-другому.

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

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

Слайд про типологии многозначности. Это - отдельный доклад.

Выходить из проблем понимания можно за счет визуальных картинок. Картинка показывает связь отдельных слов. Например mindmap "чем занимаюсь". Чтобы рисовать - надо учиться. В инете куча примеров неправильных карт, а с правильными - беда, не смогла найти хороших примеров. От цветов и типографики, до типологической однородности объектов. И надо понимать, что многозадачность снизила число удерживаемых объектов: 7+2 поменялось на 5+2. Слайд с когнитивными аспектами дизайна бизнес-диаграмм - из гештальт-психологии. Однако, даже плохая картинка лучше, чем слова.

Но тут я хочу сказать, что есть альтернативный путь: учить людей качественно структурировать нарратив, создавать в мозгу "машинку типов". Она - более общая, чем рисование картинок. Этим занимается Пион Медведева в Школе Левенчука на курсах Онтологики. Она по опыту преподавания говорит о том, что на входе машинка типов есть у 20% абитуриентов - и это при достаточно продвинутой социальной группе, которая идет к Левенчуку учиться. Но они это как компетенцию ставят. И в любом случае, пока такое образование не стало массовым - картинки помогают.

А в в конце был очень добрый слайд о том, что 2% думают; 3% думают, что думают; 95% скорее умрут, чем будут думать.

Григорий Петров. Прогреваем кэш мозга: что дает разработчикам власть над кодом и как ее (не) потерять

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

Что такое сознание? Современная нейрофизиология не знает. Есть интересные теории и гипотезы.

• Когнитом - дерево смыслов (Анохин). Группы нейронов, которые образуют смыслы и которые активируются в ответ на смысл. Ког = cog (игра слов). В мозгу - миллионы когов. У ребенка есть топология, но он не понимает ничего. Мозг обрабатывает информацию и пытается распознать. Тень, тепло и т.п. - коги для языка и далее, огромное дерево смыслов.
• Внимание - Активация когов. По входящим сигналам, например, картинки из глаз, по внутренним сигналам от других когов, и по памяти - например, можно поднять образ зала, который только что видел. Активация когов может включить исполнительный механизм. Динамики внимания - обученный механизм думания. Динамика условно-однозадачно: либо голос либо слайды. Хотя периферия есть.
• Рабочая память - 5 секунд, кошелек Миллера, 7+2 (подтверждено функциональной МРТ), активированные коги. Затухает за секунды. Есть еще другие виды памяти - кратковременная, долговременная.

Художник рисует мазками и может отойти на шаг назад, окинуть картину целиком. Разработчик пишет код мазками - но он не может отойти на шаг назад, посмотреть код 1к строк целиком. Software complexity problem. Максимум 5 когов - и при этом тысячи строк кода. Как?

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

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

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

Если есть стандарт профессии, то есть общий язык. В ИТ нет науки как писать код. Computer Science - не об этом, там численные методы. Я тут не согласен, парадигмы (ООП, функциональное программирование, SQL) - часть competer science. Но это не так важно, потому что мультипарадигмальные языки не освоены, с микросервисной моделью с активными сервисами тоже беда, науки про эффективный код действительно нет.

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

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

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

Предсказательная сила теорий

• Факты не отвечают на "почему "и "что делать"
• Студент забывает все после сдачи экзамена - знали, и понятно почему.
• Автор кода разбирается лучше, чем новый разработчик - тоже знали и понятно.

Теории проверяются предсказательной силой.

• Если человека отвлечь от текущей задачи - сбросится кэш, удерживающий внимание. И мы это наблюдаем.
• Если человек работает с кодом меньше месяца (2-3 дня), а потом вернулся через несколько месяцев - он не помнит, да
• Если работает много месяцев или лет, то при возвращении будет преимущество, знания не исчезает - они в долговременной памяти
• Разные пути в коде.

Практика. Как быстро разобраться в коде.

• Быстро осознаем, если похоже на то, что делали (знакомые шаблоны)
• Недостаточно просто знать синтаксис - это малый набор фигур
• Просто "читай код" - не работает.
• Code ownership и code review - работает, потому что формируется понимание нужных шаблонов. Знакомство с частями кода. Но для этого надо ревьюить систематично одну часть проекта, а не случайными блужданиями - тогда не запоминает. Это можно отслеживать через git, и формировать карту понимания кода.
• Стандарт кодирования. Синхронизирует когнитом команды. Пользу приносит через месяцы. Но на входе идет сопротивление - потому что перестройка своих когнитомов.
• Переключение между похожими задачами сбрасывает кэш. Нет многозадачности.
• Если покурить - не-похожая задача - то только ближайшая часть кэша. А вот если ты собираешь кэш для новой задачи, то отвлечение его сбрасывает.
• Небольшое отвлечение - снижает уровень стресса, можно найти решение в душе - начинается складывание в другие картины. Но это - когда нет вытеснения другими задачами.

Мозг - материален. Есть законы, если изучить - можно взять.

• Гигиена сна. Новые коги создаются во время сна.
• Уровень стресса
• Система подкрепления

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

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

Анастасия Артамонова. Отцы и дети в ИТ: часики-то тикают

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

Есть два возрастных периода: 18-30 и 30-45.

• 18-30 - самоопределиться понять что происходит. Что я такое.
• 30-45 - самореализовываться - сделать что-то полезное. Зачем все это.

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

Кризисы.

• 25 лет - кризис четверти жизни. Первая самостоятельность - первые разочарования. Взрослая жизнь - не такая как думал раньше. Осознания себя как члена общества.
• 30 - кризис смысла жизни.
• 40 - кризис среднего возраста

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

Решение кризиса:

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

Как обнаружить

• Человек не работает, перестает откликаться
• Обостряются противоречия. Пытается понять "кто он", а не "лучше-хуже"

Что делать:

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

Обнаружить в команде - там тоже бывает. Одному 25, а другому 30.

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

Что делать в команде

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

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

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

Итого. Кризисы случаются со всеми. Задачи одного возраста решаются за счет другого. Ответственность тимлида - команда. Начните с порядка в своей голове.

Сандра Урядова из НН. Что остается важным при управлении знаниями на масштабе нескольких компаний

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

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

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

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

• Привычные форматы взаимодействия тиражировать по всем компаниям - долго и дорого
• Совсем не учитывать - неумно
• Надо выделять общее, что есть в командах. Например, доска.
• Не множим усилия - уже знакомое (jira) или интуитивно понятное (miro)
• Доступность и безопасность. Легкий доступ для всех участников из разных компаний. Но закрыто снаружи по безопасности.
• Надо позиционировать обе команды/компании как равных коллег. Даже если одна сильно больше другой.

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

1. Алгоритм старта.

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

2. Создание поля понимания

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

3. Поддержание поля понимания

• Встречи - инструмент создания и управления пониманием. Работаем по документам. Если возражение - говорите сейчас или молчите вечно
• Поддерживаем соблюдение правил, качество и скорости коммуникации
• Чаты - как операционная база знаний. Тредики, темы - нужен каталог и т.п.
• Занимаемся просвещением. Важное надо доносить 5-10-15 раз. К этому надо спокойно относиться.

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

Инструменты

• Инструменты ради дела, а не наоборот. Не процессы меняем под jira, а jira настраивается.
• Уметь легко отказаться. Попробовали notion, не взлетело, вернулись в confluence
• Не мудрствуем с процессами. Если не один инструмент не покрывает - с процессом, вероятно, фигня
• Используем встречи как инструмент понимания.

Отношения с людьми

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

Как понять, что все хорошо работает

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

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

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

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

— Максим Цепков • 16:44, 20 мая 2022 • нет комментариев