7266
правок
Изменения
Новая страница: «Очередная конференция [https://teamleadconf.ru/moscow/2024 TeamleadConf] принесла любопытное наблюдение: в ряд…»
Очередная конференция [https://teamleadconf.ru/moscow/2024 TeamleadConf] принесла любопытное наблюдение: в ряде корпораций сейчас отказываются от функциональной организации и переходят к кроссфункциональным командам. Об этом говорили в нескольких TechTalks и докладах, как о большом прогрессе. Называют это продуктовым подходом, но это лишь брендинг. Потому что реальный продуктовый подход - это когда команда не только ведет разработку, но и сама определяет стратегию и тактику развития продукта, придумывает новые фичи и проверяет их на пользователях, а также держит экономику. А здесь фичи заказывают снаружи, а экономика, в лучшем случае, ограничивается затратной частью - чтобы более-менее попадать в оценки. Так что реально речь идет именно о кроссфункциональных командах, за которые Agile-методы топят уже более 20 лет. Конечно, это - позитивное изменение. Но вот зачем было строить плохо работающие функциональные конструкции по учебникам 30-летней давности?
А в целом конференция, как всегда - интересная, было много качественных содержательных докладов и хорошее общение. Для части докладов я выложил конспекты в ходе конференции, но многие требовали осмысления, поэтому я по горячим следам собираю отчет - пока доклады Highload не стерли контекст. И в отчете - малая часть, потому что на конференции было около 15 параллельных треков, включая Knowledge Conf и TechLead.
Кстати, онтико планирует в следующем году выделить эти треки снова в отдельные однодневные конференции, как было до ковида. И не только их, всего в планах 5-8 новых конференций: Knowledge, Apps мобильная разработка, GoLang, TechLead, CTO-conf - только для техдиров, TechFounders , DataInternals, 1C conf и уже прошедшие Industrial и AI++ - DataScience. Не факт, что все идеи реализуются в следующем году, следите за объявлениями.
А теперь доклады в том порядке, в котором я слушал, кроме моего - он начинает отчет. И большинство тех, что я слушал - прекрасны, поэтому я не хочу отдельно выделять конкретные доклады.
= Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем? =
Мой доклад [[Системное мышление — нужно ли оно в IТ и зачем? (Teamlead-2024)|Системное мышление — нужно ли оно в IТ и зачем?]] продолжал [[:Категория:Системное мышление|серию докладов]] на эту тему. Год назад я решил рассказать про системное мышление на AnalystDays: у аналитиков есть реальная боль по поводу приходящих джунов, многие из которых воспринимают тексты как нарратива, не умеют выделать объекты, типы, не понимают разницу между тем и другим, не умеют строить модели. И получил в отзывах, что системное мышление, конечно, мощный инструмент, но сложный, зачем его нужно знать и применять, когда есть более простые модели, типа BPMN или C4 model. И я понял, что надо не просто рассказывать про содержание, надо показывать место системного мышления в ходе проекта. Потому что авторы конкретных методов, включая ООП - знали системное мышление, и рассчитывали на его наличие у тех кто будет пользоваться. Все эти модели не предполагают применения по пошаговой инструкции или по аналогии.
Доклады не повторяют друг друга, в них различается содержание и акценты в зависимости от аудитории. Тема - необъятна, в слот доклада помещается лишь часть.
= Мария Щекочихина из CUSTIS. Делаем происходящее с персоналом предсказуемым =
Это рассказ о том, что надо технически делать, чтобы происходящее на масштабе 10 команд и 100+ человек было предсказуемым. Если кратко - то надо сценировать будущее, траектории развития сотрудников и других изменений - и ты оказываешься готов к различным вариантам развития ситуации. Для этого есть два инструмента: карта команд и работа с рисками, и еще - фидбэчница, фиксация истории взаимодействия. Но рассказ был построен не от инструментов, а от кейсов, инструменты проявлялись как средство, помогающее с этими кейсами разбираться. Потому что инструмент - универсален, как база знаний, применять его можно по-разному. Дальше - краткий конспект.
* Кейс-1. Ваня приходит с офером x2. Столько платить не можем, а он нужен. Но не можем. И человек ушел. Что делать? Надо планировать рост ключевых сотрудников заранее. На замену ведущим готовить людей из middle.
* Кейс-2. Есть люди, которые мониторят рынок. И спрашивают "а почему моя зарплата не соответствует". Надо следить самим за рынком зарплат. При этом вилки и медианы надо адаптировать на ситуацию в компании - у всех разные возможности. А дальше держим в зеленой зоне в районе медианы. Если границы - сложно работать: сотрудник на низкой границе придет с офером с большим повышением, и удержать будет сложно, а для сотрудника на верхней границы нет возможностей роста и это - риск, он уйдет в другую команду и компанию на другую позицию.
* Кейс-3. Растим миддла Васю на позицию ведущего. Индивидуальный план развития: что мы ожидаем для роста, и сроки выхода на позицию, это не пара месяцев. А вам как руководителю - надо обеспечить позицию ведущего и бюджет для нее. И встречи. Раз в пару недель - прогресс роста.
* Кейс-4. Сотрудник не соответствует позиции, но не признает. Такого не был, это всего один раз, это не говорили. Важно - фиксировать все, что было на ревью. Что вы говорили и вам отвечали. Не хочу быть лидом, а проводить собеседования - хочу. Дальше мы можем поднимать историю во взаимодействии.
* Кейс-5. Аналитик переросла позицию. И внутри команды не решается. Нужен вышестоящий руководитель или HR. Есть ли подходящая позиция в соседней команде? Если есть - идет туда. Но надо еще подготовить замену у себя - из соседней команды. Это надо делать заранее, но сотрудники в случае понятных перспектив обычно лояльно относятся к ситуации. Чтобы все это видеть - нужны карты персонала. Несколько команд, траектории и проблемы. Ведут в Miro, в презентации был пример.
* Кейс-6. В команде только один с конкретной специализацией. А второго нанять нельзя - нет денег и задач для него. Есть два варианта: (а) аналогичный специалист в другой команде и страховка друг друга и (б) рост кого-то во вторую специализацию. Помогают увидеть карты персонала. Они показывают дизайн команды: грейды внутри специализации и соотношение разных специализаций - балансировка мощности. Из карты видно, где проблемы - провалы и отсутствие возможности роста.
* Кейс-7. Два разработчика мидл активно развиваются. И у вас цепочка middle - senior - техлид. Все хорошо. Но приходит второй - а у вас нет третьей позиции senior, у вас она вообще одна. Надо заранее понимать - кого двигать. Карта рисков. Сотрудники: ценность и возможность развития. И Риски: как избегать и что делать в случае риска. Excel с раскраской.
* Кейс-8. 2022: 2 техлида и один ведущий ведущий уезжают, при чем ведущий страховал одного техлида. Смотрим на карту. Ищем других ведущих - не нашли. И открыла вакансию с перспективой роста, которую проговаривала на входе. За 2-3 месяца получилось подготовиться.
* Кейс-9. Тимлид Аня просит срочно согласовать вакансию аналитика в команду. Тут надо остановиться и подумать: много работы навсегда или это завал на 3 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.
Кейсы 10-14.
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.
Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо
Кейс 15-17. Те же инструменты могут использоваться для других целей.
* Оценка встройки на собеседованиях. Классный человек, но через полгода станет скучно - сразу делаем сценарий.
* Проект завершился - перераспределяем людей. Карта персонала.
* Сборка новой команды - тоже карта персонала. Людей надо как-то вытащить, в карте - есть замены и риски.
Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.
Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.
Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!
= Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителя =
Это был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору.
Рассказ сопровождала большая куча историй и законов, начиная с закона Мерфи: все, что можно сделать не так - сделают, который родился, когда на эксперименте команда техников прикрутила половину датчиков неверно. Расширенный вариант таков:
все, о чем можно подумать - вероятно, все вероятное - неизбежно, а когда есть варианты - случится худшее. Но Альберт - не пессимист, а реалист: если у нас половина стакана воды - надо дырку искать. То есть готовимся к рискам.
Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.
'''1. Люди'''. Мы нанимаем, работаем, увольняем.
Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.
Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.
После найма - онбординг, есть семь ступенек.
* Придти на работу
* Начать что-то делать - не все доходят до этого
* Делать хорошо, не вредить
* Хорошо и быстро - в темпе команды
* Хорошо, быстро и то, что нужно. А не сделать CRM чтобы MongoDB изучить.
* Хорошо и быстро то что нужно, и не только в своих интересах. Бывают эксцессы.
Как парировать риски лестницы?
* Главное - создать условия, потом требовать результата. Офис, рабочее место
* Дублировать и резервировать. Можно с аутстаффом договориться.
* Прозрачность - не пустое слово.
На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.
Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайшем будущем. Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.
Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.
Увольнение начинается с найма - проактивная позиция
* Вы должны быть готовы
* Озвучьте при найме правила увольнения, с вариантами (одним днем, две недели и так далее)
* Ведите сценарии на возможные риски увольнений
* Если сценария нет - вы полдня думаете, а ситуация может измениться, негатив.
Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
# Доступ получил, проект поднял
# Учебная задача
# Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.
'''2. Инструменты'''. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.
Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков
Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.
Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного
'''3. Работайте с надежностью системы'''. Люди - связи - процессы - изменение процессов во времени.
Проблема - степенная функция ненадежности. Надежность - что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность - степенная функция от надежности.
Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.
10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.
Связи. Ненадежность передачи информации, испорченный телефон.
Надо сокращать число элементов системы. Инструмент - выделение инкапсулированных элементов.
* Один специалист по React - он подчиняется тимлиду
* Их двое - одного ведущим, но кого? Он вводит дежурства, кто за старшего. Старший работает по ответственным задачам.
* Когда трое - он знает, кого назначить старшим. Когда четвера - заместитель, бас-фактор. Мини-группы по 3-6 человек. И они кристаллизуются естественно. А дальше делим пополам.
Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.
Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои HR, Техлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.
= Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) =
Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.
Я хочу отметить, что доклад по сути борется с основной ошибкой атрибуции, в просторечии "все уроды, а я д'Артаньян". Корень этой ошибки в том, что модель самого себя и модели других людей в мозгу разделены и слабо связаны.
А теперь - кейсы из доклада. Они - про ситуации, когда конфликт - это не отвлеченный спор, а когда в результате спора вам нужно что-то вместе сделать. И тут метафора деления пирога: все, что досталось ему - отнято от меня. Но часто есть возможность не делить маленький пирог, а найти пирог побольше. Всегда есть win-win. Выгодно в это верить. Потому что если верим - пойдем договариваться. А если не верим - то вообще не пойдем. А могут быть варианты.
1. Самый умный разработчик. Который, как казалось руководству не тщательно тестирует код, выкатывает с багами, пользователи жалуются. Итого, мы хотим, чтобы тестировал, а он - нет. А не хочет он потому что хочет быть самым умным. Но решили разобраться. И, оказывается, ему когда-то сказали, что самое важное - скорость выкатки фичи. Я проверяю основное, пользователи быстро ищут ошибки, мы исправляем. Скорость - важная. Но жалобы - тоже. И выяснили, что жалуются одни и те же - и из них сделали команду ранних последователей - и они перестали жаловаться, их замечаниям был другой статус.
2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.
3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.
4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.
С внедрением идей. Чаще всего не заходит не потому, что там - дураки, а потому что такое внедрение ставит под угрозу какую-то другую потребность системы. И с этим надо разобраться: нужно ли это изменение для системы и не не ухудшит ли оно что-либо.
Внедрение наполовину - какой-то компромисс, мы улучшили на половину, а риск не убрали. А еще хуже - заметание под ковер, просто редко здороваемся и забываем.
Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.
Реальные причины: (а) не договорились про критерии качества; (б) я не могу не делать брак - технология, компетентность, он случается; (в) я специально делаю браком - бывает, но очень редко. Штрафы - не эффективно, в последнем случае надо увольнять, а в двух первых - исправлять систему. Обвинить кого-то не значит найти решение.
Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.
= Александр Зиза (Aletheia Digital). 4 стратегии развития управленческого мастерства =
Александр показывал канвас, на котором можно работать со стратегими стратегического лидерства. И не только с ними, на нем можно работать с личным развитием и другими вопросами: канвас задает карту, между сегментами которой можно перемещаться при рассмотрении вопроса.
Карта - квадрат 2*2
* По горизонтали идет разделение между абстрактным (идеальными объектами) и материальным, включающим организации и поведение
* По вертикали идет разделение между индивидуальным, включая окружение - команду и общественным, взаимодействием с Другими, миром
Получается 4 квадрата:
* Слева вверху - собственные мысли человека, самопознание и самоопределение
* Слева внизу - поведение человека в команде или организации, область работы тимлида. Александр назвал это областью регулярного менеджмента, но, на мой взгляд, это неточно, потому что он включает регулярный менеджмент обечно предполагает классические подходы к управлению, а здесь речь идет о любых способах организации, но только в части операционной работы. Хотя, наверное, Александр опирался на каких-то авторов.
* Справа внизу - направление операционной деятельности, то есть стратегический менеджмент, а также управление изменениями и культура
* Справа вверху - проектирование стратегических изменений с помощью системного мышления и других технологий мышления
Задачи с помощью канваса
* освоение роли
* выбор и занятие новой роли
* создание новой структуры ролей - новая функция, которая сейчас все больше отходит тимлиду и команде
* создание инноваций перестройки системы разделения труда (СРТ) - предпринимательская, стартапы
Как они выглядят в нижнем слое? Стратегический менеджмент берет из верхнего слоя мысли, идеи, гипотезы, схемы и, главное, ставки. Ставка - это место, куда направляю фокус внимания. И за счет управления изменениями меняет регулярный менеджмент так, чтобы обеспечить удержание цели, формируя систему разделения труда, роли, процессы, коммуникации.
Стивен Деннинг в книге "Эпоха Agile" говорит, что сейчас нет разделения между регулярным (операционным) и стратегическим менеджментом, ими надо заниматься одновременно.
Проблема - недостаток смысла деятельности. В моменте она слаба, так как ситуация диктует импортозамещение и другие конкретные задачи, но раньше она была острой. и после решения текущих задач - вернется.
Регулярный менеджмент до 2000 включал делегирование, решение проблем, управление коммуникацией, плановые встречи и так далее. Добавилось: servant leadership, создание условий для самоорганизации, устранение препятствий, развитие компетенций, работа с клиентами и заинтереснованными лицами. Аналогично, стратегический менеджмент до 2000 года включал оргструктуру, процессы и регламенты, удержание смысла, создание ценности, инвестиции и прибыль, управление изменениями. Расширение - такое же, что как раз показывает, страние грани между ними.
Александр Залезник. Различение менеджеров и лидеров. Менеджеры делают задачи потому что должны, бесстрастно, следуя целям организации. А у лидеров - личное отношение к целям.
Я тут хочу сделать важное замечание. Классический взгляд исходит из того, что обязательно должен быть главный - менеджер. И когда он смотрит на Agile-команду, он тоже ищет в ней менеджера, как бы он не назывался. Собственно, замена скрам-мастера на тимлида - это именно такая трансформация. В классическом скраме в команде нет менеджера и product owner работает со свей командой по одним вопросам, scrum master - по другим, а команда - самоорагнизует свою работу. Постановка целей, удержание смысла, изменение способа работы через ретро - это все коллективные действия. А что касается sevant leadership, то эта концепция придумана, чтобы совместить концепт единоличного менеджера с новыми идеяеми о равенстве и совместной деятельности, дать смысл для менеджеров в этом мире. И, как таковая, она в значительной мере находится в мире идей, в верхней области схемы, а не материальном мире.
Верхняя область. Слева - как я думаю про себя, и что думают другие, с которыми я сталкиваюсь. Рефлексия, осознанность, мотивация, ограничивающие убеждения, эмоции, мораль, ответственность, раскрытие талантов, предназначение, амбиции и цели, волевые усилия, дисциплина. А справа - технологии мышления: стратегическое проектирование, понятия и представления, ценности, схема, онтологии, смыслы, идея, этика, системное мышление, критическое мышление, helicopter view, свобода.
Теперь посмотрим применение канваса на кейсах.
'''Мотивация много работать'''. Можно ее проводить индивидуально, с челвоеком, опираясь на его собственные желания. Это пряммой путь слева из верхнего квадрата в нижний. Александр Залезник говорит, что лидер - тот, кто умеет преобразовывать чувства и желания других в мотивацию.
Но можно идти косвенно, через правые квадраты, создание среды. Концепт: чтобы человек много работал, он должен много потреблять - и ему придется работать, чтобы обеспечить потребление. Реализация концепт дает современное общество потребления, где каждый много потребляет, и где каждое продвижение человека должно сопровождаться ростом этого потребления, чтобы он не стал работать меньше. Концепт прорабатывали Уайтхед, Шумпетер, Кейнс, Кондратьев, сделали это 100 лет назад. Я тут сильно сомневаюсь: Шумпетер, Контратьев и Кейнс работали над экономичекими моделями, а не над идеологическим концептом общества потребления. И это - существенно разное.
Путь в новое.
* Стартуем от текущего СРТ в левом нижнем квадрате.
* Поднимаемся наверх - самоопределение
* Придумываем конструкцию нового - правый верхний квадрат
* Реализуем изменения - правыый нижний
* В левом нижнем получается новое СРТ.
Но есть проблема, связанная с фрагментацией, целостно понимать все квадраты канваса - тяжело, часто не хватает каких-то элементов и шансов довсти изменения до успеха - мало.
Фрагментация возникает потому, что в каждом квадрате работает свой набор инструментов.
* Слева внизу - Навыковый тренинг и менторинг
* Слева вверху - коучинг, карьерный консалтинг, 1:1
* Справа вверху - Технологии мышления, образование
* Справа снизу - Бизнес-образование и бизнес-сопровождение
Каждый из инструментов - в руках специалистов. Поэтому и не связано в целую картину. Очень мало мастеров, которые бывали в разных местах. Если вы как начинающий предприниматель выбираете коуча, надо чтобы у него был свой бизнес и он не боялся вас потерять как клиента.
Самое большое количество инструментов - регулярный менеджмент, практические навыковые вещи. Все все слышали. Но не применяют. Самое дорогое - стратегическое проектирование. И сложное.
И дальше был разбор инструментов по квадратам. Что интересно, не только с точки зрения результатов, но и с точки зрения засад, которые препятствуют успеху. Главные засады связаны с эмоциями, здесь Александр опирается на модель Марвина Минский "Машина эмоций", которые рассматривал эмоции как некоторый переключатель режима для логики мышления.
Итак, левый нижний квадрант, обучение и подготовка, навыковый тренинг и менторинг. Преимущественно обучает действовать по регламентам и правилам. Важно: если вы хотите обучиться чему-то, например, стать мастером или руководителем, то надо находиться рефлексивно не только по поводу своей моей деятельности, и по поводу деятельности того, кем хотите стать. Джон Дюи говорил "Мы учимся не из опыта, а из рефлексии своего опыта".
А на массовом обучении рефлексию некому проводить. Поэтому появляется вместо конструктивной рефлексии появляется грусть и сожаление: надо было делать НЕ так. Пока нас накрывает грусть - обучиться невозможно. Поэтому тренеры борются с грустью, обучающие мероприятия превращаются в развлекательные, дают полозжительные эмоции, а вот результат такого образования - так себе.
Я тут хочу сказать, что от грусти и сожаления есть лекарство - протокол авторизации результата. Только не в позитивной форме, о которой кратко говорила Анна Обухова в своем выступлении, а в негативной, о которой она говорила в других. Почитать можно в моей статье [https://vc.ru/hr/1018029 Механизмы драйва и мотивации].
Левый верхний квадрант - личностный трек. Предпосылки: тоска на текущей роли, бесят другие, будущее не радует. Инструмент - коуч, другой об которого думать. Но мешает эгоцентризм - неумение учитывать и признавать разные точки зрения. Это когнитивное искажение, когда люди вообще не могут представить другую точку зрения. Здесь Александр ссылается на Пиаже. А еще мешает страх потери лица и потери статуса эксперта. И в результате коуч становится тем, кто просто принимает жалобы, а не коммуницирует критически. Кстати, этика коуча "нет обучения без запроса" этому способствует: коуч видит, что реального запроса на изменения нет и устраняется или превращается в утешителя. Тем более, если он работает в компании, и работодатели поставили задачу удержание сотрудника: реальный рост часто приводит к тому, что сотрудник уходит в другую компанию, где перспектив больше.
Правый нижний квадрат - Бизнес-образование, способы реализации предпринимательского замысла, стратегий, инициатив, внедрение лучших практик, управление изменениями. Цель - соответствие операционной деятельности целям и замыслам. Здесь конкретные фреймворки OKR, SWOT, Lean и так далее.
За рамками - мотивация участников к изменениям. Тут цитата из Кейнса: "Когда меняются факты. я меняю свою точку зрения. А вы?" И засада тут связана с недовольством, вызывающим гнев: рукоуводители недовольны исполнителями, не умеют восприниать обратную связь, а исполнители недовольны руководством. которое, к тому же, позвало консультанта, который "вообще не в теме", и сопротивляются изменениям. Консультант меж двух огней фокусируется на генерации идей, а не на их исполнении. или пытается провести изменения в собственных интересах, чтобы стать партнером.
Замечу, что очень часто говорят про страх изменений, это устойчивое выражение. А Александр эти части изменил: страх связан с квадратом личностного роста и связан с возможной потерей лица, а с изменениями организации связан гнев. Может быть, такое разделение оправдано, а может быть надо разбираться дитальнее, говорить о многомеррном пространстве, а не укладывать все в 4 квадрата.
И правый верхний квадрат - технологии мышления. Создание нового, изобретательство, предприниательство, выработка стратегий. И тут важно не оторваться от реальности операционной деятельности, а она за рамками рассмотрения.
Для широкого мышления важно не ограничиваться бизнесом, важно искусство, музыка. гуманитарные дисциплины: Пак Сонг Чжу из Южной Кореи полагает, что это надо преподавать в бизнес-школах, чтобы обеспечить широту мышления. А ограничением является отвращение к чужому мнению. Мы не любим, когда есть кто-то другой, который думает по-другому - идет борьба.
Целосная сборка для траектории развития.
* Нарашщиваю средства - левый нижний
* Вырабатываю план - левый верхний
* Мы видим мир по-разному и ищем что объединяет - правый верхний
* Из разных позиций строим деятельность на общих ценностях и смыслах - правый нижний.
Цитата из Сартра: "Человек, совершивший самоопределение - не только тот, быть которым он избрал, а еще законодатель, одновременно с самим собой избирающий человечество". Я рекомендую попробовать декодировать эту фразу самостоятельно. У меня получилось следующее: когда ты самоопределился, ты тем самым поменял весь мир. ибо смотришь на него по-другому. А что получится у вас?
= Анна Обухова (annaobukhova.ru). Как сделать так, чтобы команда наконец признала тебя лидом =
Рассказ о нейрофизиологических механизмах, которые лежат в основе признания лидером, то есть человеком, за которым стоит идти: прислушиваться к словам, поддерживать идеи, выполнять поручения и так далее. Общие нейрофизиологические механимы унаследованы человеком от приматов. И один из этих механизмов - определение лидера. Они действуют, и потому их надо учитывать. В докладе было 6 кейсов - вопросов, по которым вы могли увидеть разницу мышления лидера и не-лидера и оценить себя.
Есть эксперимент. Обезьянка. Научили доставать бананы из ящика и вернули в стаю. Учится ли стая? Зависит от статуса. Учатся только у высокоранговых. А низкоранговую гоняют как источник бананов. Приматы обучаются только у тех, кто стоит выше по лестнице. Опыт нижних игнорируется или их использут для поручений.
Как устроены эти механизмы? Есть два центра, которые вносят сильный вклад в регулирование наше поведение. Первый - миндалина - центр сильных эмоций. Она же оценивает социальные связи и там расположены зеркальные нейроны. Миндалина повреждается стрессом, стрессоустойчивосать - часть лидера.
Зеракльные нейроны. Мозг считывает состояние другого человека в коммуникации и интерпретирует - скука, интерес и так далее. Когда мы считываем влиятельного - меняется наше поведение. н видит это изменение - и идет реакция.
Второй центр - Хабенула. Проверяет, если вероятность - не 100%, то: ты ходил, там может быть больно, ты облажаешься - тебя съедят. Хабенула боится, когда есть социальный элемент: я предложу, они ен поддержат. Нам надо преодолевать, и насоклько эффективно делаешь - тем больше лидер.
Я тут хочу сделать важное замечание. Миндалина и Хабенула не реализуют встроенных алгоритмов, их нейроны тоже обучаются. Механизмы обучения, к которым в ходе эволюции природа перешла на млеопитающих от инстинктов и рефлексов, требуют, чтобы ребенок следовал за взрослым - на этом построено обучение. И ребенок должен определять: за кем следовать, и этому он тоже обучается: есть следование за родителями, а вот следовать ли за другими детьми, своего или старшего возраста, или другими взрослыми - он определяет самостоятельно, и есть возрастные динамики, связанные с тренировкой этого механизма. Включая переходный возраст, подростковый период 12-14 лет, когда закладываются убеждения. На этом эффекте, кстати, построена теория поколений, Анна говорила об этом в одном из предыдущих выступлений: подростки выбирают своих кумиров в этом возрасте, влияние родителей не велико, и потому следующее поколение отличается от предыдущего. Но дальше конкретную теорию построили на анализе однорожной социальной группы мамериканских менеджеров и произвольно распространили на всех, поэтому теория реально плохо применима. А если брать сильно дифференциированные общества в эпоху революций и общественного переустройства, как было в России в 90-е и 2000-е, то поколение получается неоднородным.
Итак, ребенок тренирует нейронную сеть, у кого стоит учиться, у кого - нет. А еще - кому надо подчиняться, а кому - нет. И это - разные вещи, которые исследователи часто произвольно объединяют в слово "статус". Это легко видно по школам: дети к разным учителям относятся сильно по-разному, и с точки зрения авторитета, и по подчинению, и между ними и учителями выстраивается сложная система, не сводимая к одному измерению статусом. Государство предпринимает специальные меры для поддержания формлаьной системы статусов, которая ему выгодна, к тому, чтобы все одинаково оцениваи героев литературы и фильмов и так далее. Сила влияния этого процесса зависит от силы конкретного государства. И этот социальный процесс, если мы ведем исследования механизмов нейрофизиологии, надо отделять. То есть смотреть проявления на разных социальных группах и в разных обществах и культурах. А в тех кейсах, которые далее приводила Анна, это не разделено, они относятся к конкретной американской культуре, да еще, я предполагаю, к относительно узкой группе американских менеджеров. Для которых статусы - линейны, и они на все смотрят именно таким образом. Поэтому, когда они смотрят на традицию восточных монахов, то они видят, что там монахи меряются скромностью, как менеджеры меряются айфонами и ролексами. Это было в ответах Анны, и, думаю, почерпнуто из исследований. А жизнь - богаче, и для понимания, что в нас из нейрофизиологии, а что - определено социумом, надо разделять. Только тогда можно делать перенос прикладных результатов между культурами.
Возращаюсь к докладу. Итак, кейсы. В каждом - несколько формулировок для самооценки и баллы лидераства. Это записано пунктиром, презентации скоро опубликуют, детали лучше смотреть там.
Кейс-1. Вертолет упал в тайге, все выжили - какое первое действие? Для баллов его надо классифицировать на 3 категории.
* Сделаю сам 0
* Дам задания другим +1: это отражает внутреннее право давать задания, предлагать, и принимать риск.
* Жду, когда мне скажут что сделать. -1
Кейс-2. Ты хочешь предложить идею команде. Что повлияет: предыдущий проект; ты выспался; с утра сделал несколько успешных дел. Ответ: это все работает на статус, но больше всего - то что произошло в предыдущие 6 часов. Если проект не вспоминали за это время - он забыт. Теплая рука в баскетболе.
Есть эксперимент с мышкой. У них статус - через драки, и они тоже оценивают вероятности. Если мышку подсодить к сильной альфе - она забьется в угол. Но можно предварительно посадить к слабым, она полезет драться, и если это повторить 6 раз, чтобы были победы, а потом подсадить к альфе - будут победы. Кстати, я думаю, что этот эксперимет ясно показывает: обезъянку из первого эксперимента могли научить не только открывать хитрый ящик, но и способу изменить свой статус через это преимущество, провести тренинг личностного роста. Но - не сделали.
Авторизация результата. Это методе получения уверенности, был как краткое упражнение. Анна много раз рассказывала о нем, потому что он прост и эффективен. У меня есть описание, собранное по ее докладам [https://vc.ru/hr/1018029 Механизмы драйва и мотивации]. А сам метод из 4 пунктов.
# Стартовая ситуация
# Что делал - активный глагол.
# Результат позитивный. Мурк. 14 единиц
# Для чего было нужно, как я использую на благо себе, в какую деятельность встраивается. Еще 20 единиц.
Кейс 3. Вы - лидер. появился человек или группа, которые оспаривают статус. Что поможет удержать?
* Хорошие отношения с девочками.
* Хорошие с мальчиками.
* Подружиться с тем, кто оспаривает.
* Привлечь соратника, с которым связан и за пределами команды.
Правильный ответ зависит от ситуации в команде. В хорошей ситуации надо дружить с девочками, когда все хорошо - девочки в обиду не дадут. А вот если в команде не очень хорошо, есть проблемы, то надо опираться на соратника. Потому что две обезьяны всегда забьют одну, на уровне нейрофизиологии восприятие такое. А вот вариант подружиться с тем, кто оспаривает - безопасно и соответствует представлениям о мире и сотрудничестве, но статус - роняет.
Кейс-4. Хорошо поработали, продукт успешен, делим прибыль.
* Много себе, немного другим +2
* все себе ничего другим +1
* мало себе много другим 0
* только другим у меня все есть -1
Скромность - не про власть. Больше любят, привлекает как к человеку но не характеризуют как лидера. У меня все есть - только когда однозначно считывается.
На мой взгляд, этот кейс наиболее подвержен влиянию той культуры, на которой проводили исследования. Известный американский афорищзм "победитель получает все" - он из этой культуры, и там такой способ представляется справедливым. А вот в японской и китайской культуре более распространена концепция справедливой длоли, и от лидера ждут такого поведения. В России - по всякому, потому как нынешнее общество сильно неоднородно по своим идеалам, в компаниях и командах разные идеалы смешиваются. Хотя какая-то часть уже осознает необходимость культурного выравнивания, и на входе проверяет соответствие. А справедливое деление вознаграждения - одна из существенных составляющих. Только не надо забывать, что в корпоративном мире распространено двеомыслие, разрыв между декларациями и фактическим положением дел.
Рыбки-гальяны, которые послужили формой крекеров, плывут стаями, одна куда все остальне. В стае не интересно, но не страшно. И находится рыбка, которой интересно и не страшно - и отплывает. Но вдруг понимает: "я одна, меня съедят" - и возвращается в стаю. Но находятся сумасшедшие, которые не возвращаются - и стая разделяется. Впрочем, на мой взгляд, это антропоморфизация, потому что у рыб нет эмоций, у них поведение управлется рефлексами и инстинктами, а эмоции появляются у млекопитающих.
У человека любопытство и отсутствие страха соответствет ситуации, когда много дофамина и мало кортизола, это видно по миндалине и хабенуле. Как это проявляется в поведении? Более спокоен, не боится неопределенности будущего, берет ответственность, есть план и уверенность в нем. Лидер видит дальше и может защитить. И это - иллюзия: раз сделал для себя - надеемся, что для нас тоже сделает.
Отмечу, это сильно зависит от культуры. В культуре силы, которай хорошо описана в легендах и мифах Древней Греции герою часто наплевать на спутников, он совершает подвиг. В более рациональных культурах сотрудники - ценный ресурс для достижения цели, и о нем надо заботиться. Но встречается отношение как к расходуемому ресурсу: люди - что дрова, от дождя укрыл, но когда потребовалось - кинул в костер. Заранее, конечно, об этом не говорят. А есть те, кто реально относится к сотрудникам как к партнерам, а не как к материалу. И хорошо бы это представлять.
Кейс-5. Как часто вы разговариваете про дальние перспективы?
* ежедневно +2
* раз в неделю +1
* реже 0
* только текучка -1
Смысл и цели деятельности важны, без него мозгу неприятно, возникает неопределенность. А без разговора люди не поймут. И чем важнее держать его в jarect? там чаще надо говорить, потому что активация нейронов держится примерно 6 часов, именно такое время смысл будет в активном контексте и будет влиять на принимаемые решения "по умолчанию", не требуя специального вспоминания.
Мышление. Для простых проблем достаточно внимания, фокусированного на реализации будущего. Для сложных нужно сложное мышление, выявление трендов, формулирование будущего, учет взаимных связей. Тут есть эффективный инструмент - факт карты бизнеса Курпатова.
Кейс-6. Воспринимают ли тебя как защитника на уровне нейрофизиологии, определяется ответом на вопрос о твоем стрессе:
* нет внутри и снаружи стресса не видно +2
* внутри в стрессе, но стараюсь показать +1
* нервничаю но не опух - 0
* уже опух -1
Опух - это объективная реакция на стресс, в нем почки работают по-другому.
А еще - блестящие волосы или лысина, холеность. Брюнетам повезло, более гладкие. Кудрявых блондинок - любят, но лидерами не считают.
Вождей отличают статусные аксессуары - можно потратить ресурсы на всякую хрень. У каждой социальной среды аксессуары свои. А еще суровый, а не любезный взгляд, недовольство окружающими. Впрочем, тут тоже проявляется влияние социальной среды при воспитании: если родители с придыханием смотрели на какие-то аксессауары как признаки сильного челоека, то дети тоже будут их искать, хотя набор статусных аксессуаров он может и сменить. А вот если родителям было реально, и они это явно транслировали, что так поступают лишь глупые гламурные особи, у которых других достоинств нет, и ржали над этим, то детям тоже будет безразлично. В России таких не мало, это наследство советского периода, хотя там тоже отношение к аксессуарам было разным. А вот американское общество - очень статусное, и даже при игре в хиппи важно купить прикид в правильном и дорогом магазине. Отсюда продвижение брендовых рваных джинсов, а пару лет - и рваных коготок от Gucci.
Кейс-6. Пришли на совещание, нужно предложить классную идею. Как сядете? Лидера отличает большое пространство, открытая поза, медленно и плавно двигаться. А еще есть нетривиальная штука. Правую половину поля зрения человек видят левым полушарием, рационально, а левую - правым, эмоционально, далее картинки совмещаются. И это можно учитывать, располагаясь в том поле, на реакцию которого ты рассчитываешь, а оппонента помещая в противоположное. Впрочем, по-моему, тут требуется прояснение, потому что представление, что левое полушарие связано с рациональным мышлением, а правое с эмоциями - опровергнуто, сама Анна рассказывала, что за эмоции отвечает внутренний котик, лимбическая система, расположенная под корой, а полушария отвечают за мышление. Хотя, исследования говорят, что разница все равно есть, но другая: левое отвечает за иерархию концепций и абстракций, в нем расположены речевые центры. а правое - за многобразные ассоциативные связи.
Как сделать себе мозг виятельного человека.
# Вызывать предлагать активности
# Авторизовывать результат, опора на себя
# Строить структуру поддержки своего статуса
# Брать себе лучший кусок
# Видеть, думать и обсуждать будущее
# Выглядеть здоровым, богатым и счастливым
# Больше влиять через эмоции людей
От себя добавлю - и помнить те оговорки, которые я сделал по поводу социально-культурного разнообразия людей и учитывать ту среду, в которой взрослели люди, с которыми вы работаете, потому что их нейронные сетки обучались на конкретных примерах этой среды.
В заключении хочу дать ссулку на сборник конспектов разных выступлений Анны Обуховой, а также других спикеров по темам, связанным с психологией и нейрофизиологией: [[Анна Обухова и другие про нейрофизиологию в работе]].
= Рита Канис (Just AI). Как убить всех зайцев: про управление знаниями исподтишка =
Это был рассказ про формат Just Talks, который был сделан "между делом", но привел ко многим позитивным сдвигам. Доклад - часть трека Knowledge Conf посвященного темам управления знаниями. Как я писал, со следующего года онтико планирует выделить этот трек и еще ряд тем в отдешльные однодневные конференции.
Рита работает в отрасли с высокой динамикой: меняются знания, технологии, сотрудники. Отвечает за обучение, внутреннее и внешнее, и за выступления на конференции. В условиях высокой динамики эффект от больших проектов обучения не слишком понятен. А есть желание этот эффект увидеть. В свое время она была на лекции, в которой ее поразила неформальная обстановка. И она решили попробовать сделать такой формат.
JustTalks. В пятницу 3 спикера по 15 минут под пиво. Для организации первого - просто подошла к знакомым коллегам. И не было задачи обучения, идея - просто веселиться. Поэтмоу три принципа.
* Добровольное участие спикеров и слушателей
* Свобода выбора тем - о том, что вдохновляет. Она может обсудить уместность конкретной темы - какую ценность она принесет людям. Но спектр пользы - свободный, он не ограничен работой.
* Все получает удовольствие - придумано ради этого
Но это же просто обычный митап, разве нет? Да, 1.5 года назад это были обычные митапы, отличающиеся тем, что после нее была вечеринка. Но она почувствовала, что что-то изменилось. Это трудно сформулировать, но ощущения, как от солнца в ноябре. Наиболее проявлено - что стало легче приходить к людям - выступать на конференциях, к партнерам и так далее. То есть поменялся имидж отдела обучения.
Тут сработал принцип добровольности: мы все приходим на конкретную роль, и пространство свобод ограничено этой ролью, а JustTalks стал реальным пространством свободы. И уже после второго - очередь желающих выступить.
Еще в обучении мы все время накручиваем фреймворки, делаем сложное. А тут - пошло замечательно.
И когда почувствовала, что проект - больше чем развличение, влияет на компанию - он стал больше, чем митап.
Но нужно управление, при чем мягкое. Метафора: зайцы в лодке деда Мазая, их надо подправлять, чтобы не выскочили.
Какие проблемы решает JustTalks
* Расфокус команд
* Сложные взаимоотношения с экспертами
* Проблемы с донесением информаици и обучением
* Низкий имидж отдела обучения
Теперь подробнее.
1. Расфокус команд. В хаосе сложно ориентироваться, если нужны люди. И ты просто наблюдаешь и запоминаешь. Но там столько проблем, что невозможно. Сейчас дела получше. Стало больше встреч, летом - популярный корпоратив. JustTalks объединил доклады из разных миров. Мешали доклады разных отделов, ребята знакомились. Больные темы, маректолог разработчикам "я знаю, что вы не верите, что маркетологи делают полезное". Доклады про жизнь, про бег. ВЫступление руководителей вместе с другими. Доверие - потому что общались на JustTalks и ты помнишь, как чел расскзывал про кроссовки.
2. Сложности с экспертами. Они прячутся в тени. Люди переходят между командами. Кто эксперт - непонятно. А если пришел - он говорит "я человек простой, особо ничего не знаю". Сейчас есть пополняемый пул экспертов - список с компетенциями и направлениями, куда направить. Тимлиды признают важность выступлений для экспертов, отпускают.
Эксперты - люди выстроились в очередь и даже сделали мем: если кто умничает, то "сделай JustTalks", или сам человек говорит "не зовите делать JustTalks".
Она поняла, что ответ "я простой человек" - это не страх. Это люди убеждены, что право выступать могут только особые люди. В любой области есть пирамида прошаренности, и ложное представление, что выступать могут только те, кто наверху. А это - не так, если выступление для тех, кто слабо разбирается в теме, им не интересно, что говорят суперумники, они их не понимают. И суперумникам не интересно рассказывать базу. И ты показываешь, что рассказ - не для экспертов, а для тех, у кого меньше опыта. Или столько же. Не только на JustTalks, но и на других площадках дело обстоит именно так.
А еще она привлекала новичков на выступления. Они пока не в курсе культуры, "так принято" - и они делают. И быстро интегрируются в культуру. Я тцт отмечу, что не только интегрируются, они ее делают и действительно становится принято выступать.
3. Донесение информации. Задача: донести знание про апельсин из А в Б. Все концентрируются на А и апельсине: как я расскажу то, что знаю. А релаьный вопрос про апельсин и Б - надо загрузить в голову, чтобы разобрался.
Проблемы
* Сложно говорить на языке бизнеса - на продуктовом демо. Экспериментировали миллион раз: перевернутый класс и так далее. Попытка написать техническую сложнсть просто - тяжело.
* Низкий уровень знаний о продукте в принципе
* Всем кажется, что обучение - это просто. Рассказали, практика, обратная связь и все.
Как изменилось? Мы стали чаще задавать вопрос "Зачем?", например, зачем проводим демо? Оказывается, что у всех разные мнения: отчет, обучающая встреча... То есть люди не договорились. А реально - демо для команды продаж, чтобы они лучше продавали лучше. И тогда следующий вопрос: как демо должно измениь команду продаж? Правда, тут же появляется еще один - а мы отвечаем за головы других людей?
Обучение требует не только подготовки структуры, но и проектирования опыта слушателя. Компания пришла "обучите". Они придумали классно, как расскажут. Но оказалось: обучение в 10 утра после майских. Провал. И теперь задают вопрос - что должно изменится у обучаемых.
Образование - не в том, чтобы наполнить ведро, а чтобы зажечь огонь.
Два вопроса для того, кто хочет выступить на JustTalks
* с какой мыслью выйдет слушателей после твоего доклада.
* В 10 словах объясни, что ты хочешь сказать.
Это сложно. Но мощно прокачикает.
Проектировать обучение доклад надо с конца. Что надо сказать, чтобы человек так изменился.
Они на основе опыта сделали фреймворк на 15 минут выступления: вступление, основная часть, выводы. Подробнее был на слайде.
4. Имидж команды обучения. Было: сам организуешь и все подтаскиваешь. Сейчас: отдыхаешь и наблюдаешь. Не только проект повлиял, но он - тоже.
Из обидного
* изменение культуры сложно посчитать
* хотели поплнять базу знаний - не получается, люди рассказывают про другое
* с сеньорами и руководителями - по-прежнему сложно
= Алена Рыжкова из ИТ-холдинг Т1. Как эффективно скоординировать работу 10 разношерстных команд для успешного закрытия проекта на примере реальных кейсов. Мой личный фреймворк организации проектной работы =
Это доклад о конкретном фреймворке, который сложился у Алены для управления проектами, выполняемые сборными командами сотрудников, работающих по совмещению. На мой взгляд, получился хороший легкий фреймворк, которым можно пользоваться. Тем более, что Алена хорошо расскрыла внутреннюю логику. А если представлять его место в других методологиях, то можно и обогощать другими элементами при необходимости - ведь фреймворк должен соответствовать тем проектам, а проекты у всех разные. Об этом я напишу в конце.
Типовая задача у Алены: вывести зи эксплуатации сервис X и заменить на другой сервис Y. Обычно высоконагруженный. Под задачу создается команда из разных специалистов, но ее участники работают не только над этим проектом, а основное подчинение - другое.
В фреймворке три основных элемента: инфополе, процессы и ценности, в каждом - свои составляющие.
'''1. Инфополе'''. У разных участников - разный контекст и понимание проекта. Был проект, где выводили вендорскую, и внедряли свою. Рядом с вендорской был доп.модуль, костылями и интеграцией. И они обрадовались, что он будет в новой системе. А оказалось, что команда разработки воспроизводила систему вендора как есть, без расширения. Обнаружили не сразу, договаривались долго.
Из чего состоит инфополе?
'''1а) 1-страничное описание'''. Цель, задачи - скоуп, заказчик, карта с вехами, зависимости и риски. Важно: задачи должны быть поняты всей командой. Для этого надо рассказать подробнее. Карта бизнес-процесса с системами и потоками. Формулировка - кратко, просто и понятно. И если спец.термины - нужно толкование, в команде разные участники. В сложных способах - еще и проверять понимание.
Заказчика надо знать в лицо и это тот, кому будем сдавать проект. Форма карты - зависит от проекта - масштаб, насколько проект знакомый, она показывала свой.
'''1б) Зоны ответственности'''. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.
DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.
По зонам надо предложить свое, собрать предложения, зафиксировать договоренности.
'''1в) Дорожная карта'''. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.
Получается общее информационное поле. Но просто сказать после этого "поехали" - не достаточно, надо реально стартовать работы. А то приходишь - а оказывается, что все заняты другими делами. Почему? Потому что делают те проекты, по которыем создается информационное давление - на статусах, от менеджеров и так далее.
'''2)''' Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.
'''2а)''' Основное - '''статус проекта'''. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.
'''2б) Рабочие группы по выявленным проблемам'''. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.
'''2в) Чат в мессенджере'''. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.
Статус, рабочие группы и чаты нужны в любых проектах, даже маленьких. Причины факапов чаще не технические, а организационные. Серые зоны ответственности и прочее.
'''3. Ценности и принципы'''. Нужна мотивация и понимание, в чем смысл - это отдельные блоки. Они зависят от проекта. Но еще есть принципы - верхнеуровневые праивла, которыми мы руководствуемся. Они определяют как поступать правилами, что держать в фокусе внимания. И не просто записать, а реально применять. Для этого надо приземлять принципы через паттерны и антипаттерны.
Ее принципы: Открытость, Поддержка и Лидерство. И были слайды, где для каждого были паттерны и антипаттерны.
'''Открытость''' - предоставление всей информации всей команде проекта. Нет отдельного чата разработки, приглашение на статусы всех заинтересованных. Она первой пригасила на статусы ИБ, сначала напряглись - потом пошло сотрудничество.
Открытость с руководством. Если пошли задержки - надо сразу говорить. Во-первых, они компетентны и заинтересованы и помогут. Во-вторых открытость рождает доверие, а оно критично при факапах.
'''Поддержка'''. Атмосфера, к которой не чувствует брошенным с проблеми, не боится быть осмеянным или обруганным. Это не значит, что он решит за команду - но он поддержит, поможет и направит.
'''Лидерство'''. Это не про то, как кто-то на белом коне ведет проект к успеху, это за ответственное отношение к результату, его должна показывать вся команда. Надо выдвигать аргументы и защищать. Не все умеют и считают уместным, но надо этому учить.
В целом получился легкий фреймворк. На мой взгляд, очень напоминающий то адаптивное управление проектами, которое продвигает Павел Алферов из своего опыта, сократив классику до необходимого минимума. Кстати, как источники, где можно посмотреть, Алена указывала PMBOK - там есть все, можно брать элементы. И фреймворк p3.express/ru. А я бы дополнил этот список практиками Kanban и социократии. Вопреки распространенному мифу, Канбан - это не упрощенный скрам для потока задач, это способ работы и совершенствования методов организации работы. И там много различных практик, а также технология определения узких мест в ходе проекта. А социократия - еще один подход, который можно использовать как источник для полезных практик. И организация рабочих групп для решения вопросов, которую Алена описала - одна из них. Ее, кстати, можно применять для решения проблем, которые выявили ретро, только там время работы больше, был интересный доклад Ростелекома об этом.
= Алексей Макаров (Xello). Команда разработки за свой счет =
Очень интересный доклад о том, как поменялся взгляд на разработку, когда Алексей стал одним из владельцев компании, открытой на собственные деньги, без внешних инвесторов. Произошло это три года назад. Ему всегда хотелось делать что-то свое, а тут пришел знакомый, принес идею, предложил вместе попробовать сделать. Они начали в режиме хобби, а потом был момент, когда надо или прекращать, или делать продукт командой. И они решили создать компанию на свои сбережения: посчитали в оптимизме, что с первой сделки окупится, но нет. Были ошибки с наймом, другие проблемы с организацией, ковид остановил многие инвест-программы у потенциальных заказчиков, а цикл сделки у них долгий, до 2 лет. И им приходилось брать кредиты на зарплату, выживать, в ряде обсуждений проблем как один из вариантов было "закрыть компанию". Сейчас уже стабилизировалось, компания успешно развивается. Но путь был трудный, и не факт, что зная его, он бы пошел. Сейчас он изменился, и вернуться в найм - точно не сможет.
Да, в конце был вопрос про инветоров, разные фонды. Ответ: по факту их нет. Они появились с предложениямИ, когда компания стала успешно развиваться, и их деньги, по сути не нужны. А когда были реальные трудности и не хватало финансирования из возможностей был только банковский кредит.
Итак, как меняется взгляд на разработку, когда ты - владелец компании, которую основал на свои деньги?
В большой компании всегда зависишь от людей и их решений - от тех, кто вверху, и от тех, кто внизу - тоже. В своей компании ты сам должен все решать. С одной стороны, за этим и шел, когда делал компанию. Но, с другой, в найме, когда есть проблемы - можно поделиться с руководителем. И это, как бы, прозрачность, а не не перекладка ответственности, и прозрачность - нужна, скрывать проблемы - плохо. Но по факту сущесвтенную часть отвественности ты при этом отдаешь.
В своей компании владелец - конечная точка принятия решений в сложных случаях. На обсуждении среди вариантов часто было: закрыть компанию, и старались придумать иной вариант. И ты перестаешь бояться ответственности, бояться непопулярных решений, не по best practice, странных решений.
А еще становишься прагматичным. Пять лет назад он собеседовался: два собеседования, тестовое задание, он реально вложился. А в итоге не взяли, потому что в интерфейсе несколько элементов сделал не по макетам - а там требовался кастомный элемент. Ему казалось, что они - придираются. Сейчас для него важно, чтобы выглядело как ожидается. Впрочем, на мой взгляд тут важно раскрыть тему. Потмоу как если кастомынй элемент удваивает стоимость разработки и поддержки, то в чем прагматика? Требования дизайна должны быть реально обоснованы, а не просто картинка, бездумное выполнение которой. в общим-то, частный случай подхода "ты начальник - я дурак".
Еще история. Собеседовали бэкенд. Кандидат топил, но не агрессивно, за DDD. На вопрос о минусах - просто надо уметь готовить. И его не взяли, потмоу что риск, что вместо обсуждения проблем они будут обсуждать DDD - насколько правильно его применять, что он будет постоянно его проталкивать. И такое же отношение к людям, который топят за чистую архитектуру, типизированные языки, брокеры сообщений вне контекста конкретной проблемы. В больших компаниях - много таких холиваров. Аннотации, архитектура, брокеры сообщений. Вообще, а не по месту.
Вопрос: на чем бы писали сервис с нуля. Кто-то выдает вариант, кто-то топит за знакомое. Как лид ты должен в эти холивары приходить и очерчивать правильную точку зрения. Потому что лид. И в найме он боялся нанимать людей сильнее себя - тебе не нужна конкуренция. Тем более, что видел примеры, когда увольняли сильных ребят, с формулировкой: самодеятельность и дестабилизация проекта.
В своей компании ему было сложно было собеседовать людей не в своей области: дизайнера, фронтэндера, рекрутера. И надо преодолеть идею, что лид - самый сильный. Ты не должен быть самым сильным, ты должен руководить сильными.
Когда у тебя небольшая команда, тебе нужно быть эффективным. Найм - дорого. Три месяца закрытие позиции, три месяца испытательный срок, стоимость - 6 окладов рекрутера, база кандидата 500-600к, CRM рекрутеру не дешевая. Еще собеседование, это 2 часа. если с фидбэком. Увольнение после испытательного срока - еще более дорогая штука. Выходное пособие, сроки, замена нового. Поэтому контрофер так эффективен - компания не хочет нести риски. Они допустили 5-7 ошибок, наняв неправильного человека - и это релаьные затраты.
А на старте их спасало, что нанимали друзей и друзей-друзей. Было доверие и лояльность. А не харды. А потом фокус на хардах привел к ошибкам. Когда работал в найме, то обо всем этом не думал: скорость и эффективность найма, стоимость...
Еще он не сталкивался с финансовым планированием. Для него оно кончалось оценкой проекта, и если оценки оказывались неверными, то как бы ничего страшного, ну, поругают. А тут: ставки под найм, премии, бонусы, бюджеты на тимбилдинг и корпоратив. И в отличие от burndown, который не сходился, финмодель должна сходиться. Без дефицита и кассовых разрывов. У них цикл сделки до 3 лет, в пессимистичном плане живешь медленнее. И в реалистичном тоже - можно поймать кассовый разрыв.
И это научило серьезнее относится к планированию задач. Потому как у кого-то нет права на ошибку, а у кого-то всегда обстоятельства. В найме - не было личных обязательнства по срокам. Он искренне стремился, и предупреждал, но не более. Сейчас он очень чувствует, что бизнесу нужны астрономические реалистичные сроки. И надо поток запросов обрабатыать. Приоритеты и оценка. Рефакторинг и смена фреймворка - этим можно пренебречь, заработать, и потом делать.
У них OnPremise решение для large enterprise - 3-4 релиза в год, регресс около месяца. Живут в канбане, 2-недельные спринты не интересны, задачи большие. Строят кумулятивные метрики, выявляют узкие места, например, накопление задач перед тестированием. И Control Chart - смотрят метрику рассеивания данных. Графики - способ искать аномалии: отличия разных команд, влияние увольнений. А сроки - дают лиды.
Я хочу отметить, что про сходимость модели не взирая на неточные оценки - это верно. Потмоу что есть засада: ошибки оценки статистически компенсируются только при нормальном распределении, а для задач в ИТ статистика показывает распределение с длинным хвостом: пуассоново или логнормальное. Об этом есть хороший [http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk доклад Андрея Бибичева «Пуассоново горение сроков»]. И чтобы попасть с оценкой в два сигма, оценка должна быть втрое выше матожидания, двухкратный резерв. А точно оценить можно, лишь наполовину сделав задачу. Это - объективно и да, фин.модель должна сходиться даже с учетом такой объективной неопределенности, как совладелец компании я это тоже хорошо понимаю. Как это делать - отдельная тема. Часть этой задачи можно возлагать на руководителей проектов или тимлидов, но если бы они были готовы полностью принять такую ответственность - у них бы были свои компании. А если просто жестко давить - они будут завышать оценки тем или иным образом.
= Евгений Идзиковский (Частная практика). Legacy-код в психике — как расплатиться со своим техдолгом =
Если рассматривать мозг как большой софт, то в нем много legacy-кода, который возник ситуативно. Это - хорошая аналогия, с той разницей, что код софта писали программисты, а код мозга был порожден в ходе обучения. Но в обоих случаях когда-то была приемлема решена какая-то локальная задача, а потом этот фрагмент сохранился. Этот механизм свойственен не только человеку, так же работает мозг кошки или собаки, которые вообще не мыслят, однако решают довольно сложные задачи обеспечения питанием, поиска партнера для размножения, социальных взаимодействий. А рефакторинг не предусмотрен, если только механизм не начал давать серьезные сбои. В дикой природе животным некогда заниматься рефакторингом, надо выживать.
А вот человек - он рефлексивен по отношению к своему поведению, и часто хочет изменить каки-то действия своего обученного автопилота, не доводя последствия до серьезных сбоев или просто узнав, что существуют другие, более эффективные способы действия. Провести рефакторинг. Именно этим занимаются психологи, и для этого наработано много методов терапии. При этом, однако, исследования показывают, что эффективность каждой конкретной - 25%. Но вот если действовать интегративно, применять их в комплексе с учетом конкретного человека и задачи, то коррекция возможна, при чем достаточно быстро, за 1-2-3 месяца. А если вы ходите два года и проблема не решается, значит к вам применяют неверные методы, учитывайте это при выборе специалиста.
Дальше в докладе был обзор методов психотерапии на понятном разработчикам языке работы с легаси. Это было устно, и я записывал в телеграфном стиле. Но на своем канале @idzikovsky_psy Евгений обещал в ближайшее время выложить подробную презентацию, где раскрыть содержание. Он - профи и знает много методов, чаще использует гипнотерапию, осознанность и НЛП совместно, дополняя другими по необходимости.
Итак, психотерапия как работа с legacy-кодом.
Для начала - архитектурная схема: есть входной сигнал, два канала обработки - эмоции и мысли, которые между собой взаимодействуют, и выход - поведение. И там возможны ошибки двух типов.
* Ошибки распознавание. Смотрим на собаку, которая бежит к нам, хочет сделать кусь, и у нас страх. Психика угадала - хорошо. Но может дать такой же ответ и на маленькую собачку. Получаются разные фобии. Не все страдают, они просто избегают этого. И там - проблемы. Хорошая девушка, хочу познакомитсья, но не подхожу - психика выбрала какой-то страх, а не предвкушение интересного знакомства.
* Второй тип ошибок - психика выбрала неправильное поведение. У человека инстинктов нет, все результат обучения. Два года, мозг сгенерировал какой-то шаблон, и если оказалось удачным - оно классное. Оставим. И все время мы копим какой-то код в мозгу. Время рефакторинга - не было. Потому что рефакторинг в дикой природе - нерационален. Надо еду добывать.
Формирование ошибочных шаблонов может идти тремя разными способами.
* Разовая ошибка, что-то сделал, она сделала кусь - и это зафикисровалось как негативный шаблон через эмоции.
* Мама говорила "ты лох" или "ты глуп" или "не высовывайся" - и ты следовал этому, потмоу как она говорила многократно.
* Родители не кричали, но показывали, что расстроены: мы любим, когда ты себя ведешь таким образом, а когда по-другому - не любим. Это тоже отпечатывается эмоционально, но по-другому.
* Подражание родитетелям заложено как способ обучения. И это правильно: родители же выжили, значит классные шаблоны. Но они выжили в других ситуациях.
Что можно сделать для рефекторинга сознания?
# Влезть в хардвер.
#* Волшебные таблетки и подобные штуки. Перформить на 80% лучше, чем сидеть в депрессии. Еще есть таблетки, которые выключают страх на время, например, вырубая страх выступлений - он накапливает опыт.
#* Обруч обратной связи - выводит на экран то что происходит в мозгу, ЭЭГ на сухих электронах. Видео шлем. Человек боится авиаперелетов - это надо протестировать. Запускают эмуляцию на очках, снимает с обруча страх. Потом провели терапию, и эксперимент повторяют, убеждаясь в эффективности. Не на словах, а экспериментом.
# Перехват кода. Контроль "не делай этого". Здесь все практики осознанности. Тренировки нужны, чтобы поднять порог эмоций, которые боимся. Напрмиер, подойти к краю, где высота. В 1980-е были эксперимент - есть ли свобода воли, или есть предписанные процессы. Снимали МРТ, оказалось, что за полсекунды приборы показали, будет ли он это делать. Вывод: свободы воли нет, все предопределено. А в 2015 - другие эксперименты, и они показали приборы фиксировали готовность, а мозг - управляет. И осознанность обеспечивает это управление. Но его надо нарабатывать, из коробки его не дают.
# Отредактировать код.
#* НЛП - оно создано для этого. Можно менять тембр головса или скорость речи и так далее.
#* Позитивная психотерапия - по-другому смотря на вещи, выбирать другие шаблоны.
#* Терапия частей, гипнотерапия, гештальт. Даем ТЗ на некоторый код, внедряем, и применяем в жизни.
# Мы внедрили новый код, запускаем его в модельной ситуации, а в жизни сетка запускает старый. Тут терапия осознанности и гипнотерапия, она перекодирует принятие решений. Пересобираем решения.
# Экзистециальная терапия: говорит - в жизни есть важное, его надо удерживать в фокусе, когда действуешь.
# Метапрограммирование систем. Средняя семья - клуб чудовищ, и можно работать с ними всесте как с системой. Семейная терапи или транзактный анализ. Пример: в семье ругались, дали предписание: нельзя ругаться в любое время, надо с 21 до 21:30, и обязательно орем друг на друга. Пару раз орать получилось, потом приходят: доктор, дайте другое предписание, не можем. Ругаться перестали.
Подходы можно варьировать, решая проблему косвенно.
* Руководитель боится ошибок, ему психика говорит "ошибаться - плохо", и он запускает гиперконтроль или пытается делать все сам.
** Можно изменить убеждения, сказать "ошибаться - нормально"
** А можно сказать: не делегировать - ошибка, делегируй.
* Боюсь обидеть - поэтому не провожу one2one. Причина может быть в детстве: мама часто показывала, как плохо, что она расстроена, это был ее способ воспитания и это - отпечаталось.
** Можно с этим разобраться, чтобы детские травмы не влияли на взрослую жизнь.
** А можно научиться давать обратную связь, где ты не обижаешься, дать альтернативную технологию.
* Тимлид вырос и стал токсичным. Почему? Он вырос в среде, где сильных гнобили слабых, и это было нормально. И когда он стал тимлидом, у него что-то перещелкнулось, сработал тот старый паттерн: я теперь сильный, значит должен гнобить. Не хочу, а должен. И он начал так делать. Шаблон надо выявить и перепрошить. Но надо понимать, что конкретно меняешь, причины могут быть различны.
* Человек много планируешь как супермен. Планы преувеличены, и они не выполняются, он это видит. но все равно планирует 10 дел, а выполняет одно-два. Почему планов много? У него убеждение: если план - всего одно дело, то он точно плохой, я не герой. А если 10 - то может получиться, есть шанс. Убеждение можно менять, но его тоже надо выявить.
Как со всем этим бороться? Осознанность. Если мы второй раз поступили неверно - это паттерн. Надо его зафиксировать, а потом с ним работать, менять то, что мы делаем.
= Екатерина Шашкова (ИнЭкс). Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки =
Это рассказ о том, как люди попробовали сделать регулярный менеджмент, основанный на регламентах, уронили этим качество, и изобрели lean для совершенствования процессов. История началась с того, что потребовалось быстро разработать некоторый продукт, и под это собрали команду специалистов из разных отделов из 5 человек, она работала не формально и эффективно, как часто бывает в небольших командах, по по мере роста появились проблемы. И когда она увеличилась до 18 человек обнаружили, что люди очень по-разному понимают, как у них устроена работа, например, одни считали, что при регрессе достаточно комплексно проверить новую фичу, а другие - что еще и остальной функционал, потому что его могли сломать. И они решили полечить это через описание процессов. Не проектировать, а просто описать что есть, потому что в целом оно работает.
Процесс описывали в линейной схеме, через этапы, для каждого - список действий, участвующие роли и критерии перехода к следующей фазе. Составлять описание начали с финала, которым у них является подписание акта, а не завершение разработки, этому предшествует выкатка на прод и выкладка доков и так далее. Идея была, что дальше процесс будут соблюдать, а там, где обнаружат проблемы - дорабатывать описание или сам процесс. В целом первый опыт был удачным, описание помолгало, его решили распространить на все команды компании. Команды не возражали, но каждая начала предлагать свою версию. А было стремление к унификации, поэтмоу ввели процесс защиты: инициатор предлагает изменения тимлиду, при успехе - надо защитить на совещании тимлидов и только тогда это распространяется на все команды, и это закономерно приводило к холиварам вокруг "правильного процесса".
Первичное опрозрачивание стоило 1-2 месяца, а дальше менеджеры еще полгода объясняли. Как это часто бывает при таком подходе, описания процессов и результатов получились большие и не работающие, разработчики в них путались. Это проявлялось в онбординге. Новичку давали простую задачу, и он вместе с куратором проходит по этапам процесса. И есть проблемы: разработчики не помнят, что скрывается за каждым пунктом, или говорят разное. И в целом это привело к падению качества, у них был период, когда каждую неделю ломали прод.
И у них пошел новый виток спирали. Они передали работу с процессом от менеджеров тем, кто их исполняет. Хотя централизация в каком-то виде сохранилась. Отказались от описания процесса как последовательности действий, перевели в критерии результата: тесты зеленые, документация выложена.
И запустили процесс регулярных обсуждений и улучшений. Это происходит на еженедельных соцещаниях. Совещания - по пятницам, 1-2 часа, всю неделю разработчики пишут пункты для обсуждения на совещании. У каждого совещания - владелец. Он, в том числе, отвечает за фиксацию результата, хотя не обязательно делает это сам. Фиксирующий шарит экран и записывает сразу.
Такая версия оказалась успешной. Мощность выросла от 3-5 до 20 в неделю. И еженедельные релизы по четвергам вместо месячных. Вовлеченность - процессы были в топе проблем в опросе, а сейчас 3.14 из 4.
Я тут хочу отметить, что хаос и неопределенность реально многих пугает, но вот стремление через детальные регламенты и процессы обеспечить предсказуемость и качество - наивно. То, что классический менеджмент по регламентам в ИТ не работает, выяснили 30 лет назад. Но, к сожалению, образование во многом транслирует иную точку зрения, и люди ходят по старым граблям.
= Руслан Карманов (IEEE Hong Kong Section). Китайские методологии IT-управления =
Руслан много лет работает в IEEE Hong Kong со стандартами связи - WiFi и Ethernet. Борется с вендорскими попытками выкрутить стандарт в свою сторону. И если кратко, то нет никаких специфических китайских методологий, китайцы заимствуют западные и японские. Но эти методологии накладываются на особенности китайского менталитета, и вот это необходимо учитывать. Эти особенности включают меритократию - власть умных, особое отношение к начальству, которого ждут и у контрагентов, способность комбинировать вместе, казалось бы, несовместимые воззрения, а также чувствительность к риску потери лица, которая ведет к ступору или разрыву взаимодействия в некоторых ситуациях. Это кратко, а теперь - подробнее.
Китай - большой, это материковый Китай плюс Сингапур плюс Гонконг, интегрированный во все западное, плюс Тайвань с идеями "почти японцы". И все массово применяются любые зарубежные модели. Японское DQM. Западные - там много фирм, которые были отделами западных фирм, особенно в Сингапуре. При этом никаких особых методологий "имени компартии" - нет. Даже в полузакрытых разработках, например, великий китайский файервол - MS Project.
Максимальная прагматичность в рамках существующих ограничений. Пупулярный на западе холивар open source - вендоры, и принятие решений по убеждениям - отсутствует. Поэтому зоопарк решений. На космодроме - Windows, Red Hat и много другого. Им безразлична любая идеология, необходимо, чтобы примеяемый подход решал задачу здесь и сейчас.
Особенность китайского менталитета - отсутствие привязки к дуализму черное-белое или добро-зло. которая есть у нас. Не или-или, а вместе, комбинация. Конфуцианство для социальной жизни, буддизм и философия даосизма уживаются в одной голове человека, который может быть еще и бизнесменом и членом компартии.
Меритократия. Конфуцианство - власть мудрых. Поэтому выберем самого умного, пусть он нами правит. Ведущий - свой по каждому вопросу. Если вы взаимодействуете с китайской командой, и ведущий с той стороны становится узким звеном и не справляется - они не поймут претензии. Они выделили лучшего. У них нет выборов и потому нет перевыборов.
Легенда о китайской дисциплине. Есть подмножество людей, которые думают, что в Китае свойственно все решать карами. Это не так. Однако, ответственность серьезно прокачано. Можно завалить работы за месяц, и получить штраф на стоимость шести месяцев работы.
Тяга к максимальному мастерству, гунфу сочетается со спокойным отношением к неудачам. И в ИТ важно достичь максимума в каком-то классе задач. Деление на две категории: есть те, кто освоил мастерство (кунфу) и кто просто делает. И отвечает и решает только тот, кто мастер.
Организационно за неудачи могут грызть, а по-человечески - спокойно "ну не смогли". Потом исправят. Те, кто играют в японцев или в западных людей так действуют, пока хорошо. Если есть проблемы - сваливаются в китайский шаблон.
Разумная меркантильность выплаты премий. Разные плюшки, не только деньги. Социалка, акции компании - объем этого может быть больше зарплаты. Еще бесплатные билеты, снимут квартиру и так далее. И выдают разную мотивацию разным людям. А премии могут быть большие, до 20 окладов за год не только у топов. Поэтому не надо ориентироваться только на уровни зарплат при каких-то взаимодействиях.
Специфика конфликтности
* Ступор при проблемах или даже намеках на них. Например, когда надо заполнить анкету и есть затруднения и девушка, которая ее дала не может ответить - она тут же кого-то зовет. Может показаться, что китайцы бесмысленно динамят, переключая стрелки. Нет, они осмысленно динамят, чтобы не ошибиться. Поэтому в контрактах прописать надо будет все и даже детальнее.
* Начальник больше чем начальник - следствие конфуцианства. В Японии начальник может пойти вместе с сотрудниками после работы. В Китае - нет, четкое разбиение на ранги. И от вас ждут того же. Если вы показываете, что "как в семье" - они увидят, что это - бардак. В Гонконге ждут, что белый человек их построит, скажут что делать, и они будут делать. Если китайца притащить в современную фирму с демократичным управлением и со слабо-формальными взаимоотношеними - у него будет взрыв мозга.
* Могут легко бросить дело в середине процесса. Если вы довели китайца до потери лица, он вас бросит. Публично показали другим китайцам, что он что-то не понимает - все, завтра закроет общение. Чтобы не повторить. Так и с командой. Если они в середине работы поймут, что не сделают во-время или провалят критерии качества - они отвалятся тут же. Если не привязать договоренностями. Устно прокатит только, если китайцы будут на позитиве и впереди будут доходы.
* Сверхтолерантность вне западного дуализма. Если у вас есть требования, чтобы подвести под сертификацию или что-то еще - пропишите. Можно обнаружить, что вместо nginx использовали какой-то форк, который непонятно как сопровождать. И библиотеки - будут тянуть китайскую кривенькую ssl просто потому, что в предыдущем проекте требовался китайский вариант.
* Сезонность. Западный Новый год, китайский, финасовый - разный. Жизнь - от китайского нового года до золотой недели октября. До этого все дела надо закрыть, остаток - это невнятный кусочек. Они подвязываются под эти даты.
* Перерегистрация юр.лиц, фирма может существовать лет 20, но перергистрируется каждый год. Даже не чтобы от налогов бегать, просто новый год принято начинать с чистого леста, и это - часть такой практики.
* В Китае запрещены азартные игры, иначе все проиграют. Макао - оборот в 10 раз больша Лас-Вегаса. Не надо стимулировать, потому что они выключают мозг и стремятся выиграть. Лотерея в конце проекта - нельзя, это запрещенка и не просто так.
* Заимствования методологий у коллег Япония-Тайвань-США - идеологически верный акт экспроприации. Грабь награбленное.
Итого
* База - на общеизвестных практиках. Нет коммунистической, нет даосской.
* Методологии - поверх своей культуры, корректируясь под нее. Чистота методологии не критична.
* Берите что работает, стремитесь к индустриальному мастерству, адаптируйте под себя.
В Японии важно что ты в одной компании. Если перешел - предатель. В Китае переходы были свободны, но сейчас эта тема тоже начинает подрастать.
У нас - напряжение, если прописываешь контракт на определенном уровне детализации: "Ты что, думаешь, что я тебя кинуть хочу, или что я совсем глупый?" У них - нет такого и надо прописывать до деталей.
Когда необходимо брать китайцев? Когда делаете мультимедиа или сайты, где оформление или сценарии для персонажей требуют учета китайской специфики.
А в целом конференция, как всегда - интересная, было много качественных содержательных докладов и хорошее общение. Для части докладов я выложил конспекты в ходе конференции, но многие требовали осмысления, поэтому я по горячим следам собираю отчет - пока доклады Highload не стерли контекст. И в отчете - малая часть, потому что на конференции было около 15 параллельных треков, включая Knowledge Conf и TechLead.
Кстати, онтико планирует в следующем году выделить эти треки снова в отдельные однодневные конференции, как было до ковида. И не только их, всего в планах 5-8 новых конференций: Knowledge, Apps мобильная разработка, GoLang, TechLead, CTO-conf - только для техдиров, TechFounders , DataInternals, 1C conf и уже прошедшие Industrial и AI++ - DataScience. Не факт, что все идеи реализуются в следующем году, следите за объявлениями.
А теперь доклады в том порядке, в котором я слушал, кроме моего - он начинает отчет. И большинство тех, что я слушал - прекрасны, поэтому я не хочу отдельно выделять конкретные доклады.
= Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем? =
Мой доклад [[Системное мышление — нужно ли оно в IТ и зачем? (Teamlead-2024)|Системное мышление — нужно ли оно в IТ и зачем?]] продолжал [[:Категория:Системное мышление|серию докладов]] на эту тему. Год назад я решил рассказать про системное мышление на AnalystDays: у аналитиков есть реальная боль по поводу приходящих джунов, многие из которых воспринимают тексты как нарратива, не умеют выделать объекты, типы, не понимают разницу между тем и другим, не умеют строить модели. И получил в отзывах, что системное мышление, конечно, мощный инструмент, но сложный, зачем его нужно знать и применять, когда есть более простые модели, типа BPMN или C4 model. И я понял, что надо не просто рассказывать про содержание, надо показывать место системного мышления в ходе проекта. Потому что авторы конкретных методов, включая ООП - знали системное мышление, и рассчитывали на его наличие у тех кто будет пользоваться. Все эти модели не предполагают применения по пошаговой инструкции или по аналогии.
Доклады не повторяют друг друга, в них различается содержание и акценты в зависимости от аудитории. Тема - необъятна, в слот доклада помещается лишь часть.
= Мария Щекочихина из CUSTIS. Делаем происходящее с персоналом предсказуемым =
Это рассказ о том, что надо технически делать, чтобы происходящее на масштабе 10 команд и 100+ человек было предсказуемым. Если кратко - то надо сценировать будущее, траектории развития сотрудников и других изменений - и ты оказываешься готов к различным вариантам развития ситуации. Для этого есть два инструмента: карта команд и работа с рисками, и еще - фидбэчница, фиксация истории взаимодействия. Но рассказ был построен не от инструментов, а от кейсов, инструменты проявлялись как средство, помогающее с этими кейсами разбираться. Потому что инструмент - универсален, как база знаний, применять его можно по-разному. Дальше - краткий конспект.
* Кейс-1. Ваня приходит с офером x2. Столько платить не можем, а он нужен. Но не можем. И человек ушел. Что делать? Надо планировать рост ключевых сотрудников заранее. На замену ведущим готовить людей из middle.
* Кейс-2. Есть люди, которые мониторят рынок. И спрашивают "а почему моя зарплата не соответствует". Надо следить самим за рынком зарплат. При этом вилки и медианы надо адаптировать на ситуацию в компании - у всех разные возможности. А дальше держим в зеленой зоне в районе медианы. Если границы - сложно работать: сотрудник на низкой границе придет с офером с большим повышением, и удержать будет сложно, а для сотрудника на верхней границы нет возможностей роста и это - риск, он уйдет в другую команду и компанию на другую позицию.
* Кейс-3. Растим миддла Васю на позицию ведущего. Индивидуальный план развития: что мы ожидаем для роста, и сроки выхода на позицию, это не пара месяцев. А вам как руководителю - надо обеспечить позицию ведущего и бюджет для нее. И встречи. Раз в пару недель - прогресс роста.
* Кейс-4. Сотрудник не соответствует позиции, но не признает. Такого не был, это всего один раз, это не говорили. Важно - фиксировать все, что было на ревью. Что вы говорили и вам отвечали. Не хочу быть лидом, а проводить собеседования - хочу. Дальше мы можем поднимать историю во взаимодействии.
* Кейс-5. Аналитик переросла позицию. И внутри команды не решается. Нужен вышестоящий руководитель или HR. Есть ли подходящая позиция в соседней команде? Если есть - идет туда. Но надо еще подготовить замену у себя - из соседней команды. Это надо делать заранее, но сотрудники в случае понятных перспектив обычно лояльно относятся к ситуации. Чтобы все это видеть - нужны карты персонала. Несколько команд, траектории и проблемы. Ведут в Miro, в презентации был пример.
* Кейс-6. В команде только один с конкретной специализацией. А второго нанять нельзя - нет денег и задач для него. Есть два варианта: (а) аналогичный специалист в другой команде и страховка друг друга и (б) рост кого-то во вторую специализацию. Помогают увидеть карты персонала. Они показывают дизайн команды: грейды внутри специализации и соотношение разных специализаций - балансировка мощности. Из карты видно, где проблемы - провалы и отсутствие возможности роста.
* Кейс-7. Два разработчика мидл активно развиваются. И у вас цепочка middle - senior - техлид. Все хорошо. Но приходит второй - а у вас нет третьей позиции senior, у вас она вообще одна. Надо заранее понимать - кого двигать. Карта рисков. Сотрудники: ценность и возможность развития. И Риски: как избегать и что делать в случае риска. Excel с раскраской.
* Кейс-8. 2022: 2 техлида и один ведущий ведущий уезжают, при чем ведущий страховал одного техлида. Смотрим на карту. Ищем других ведущих - не нашли. И открыла вакансию с перспективой роста, которую проговаривала на входе. За 2-3 месяца получилось подготовиться.
* Кейс-9. Тимлид Аня просит срочно согласовать вакансию аналитика в команду. Тут надо остановиться и подумать: много работы навсегда или это завал на 3 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.
Кейсы 10-14.
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.
Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо
Кейс 15-17. Те же инструменты могут использоваться для других целей.
* Оценка встройки на собеседованиях. Классный человек, но через полгода станет скучно - сразу делаем сценарий.
* Проект завершился - перераспределяем людей. Карта персонала.
* Сборка новой команды - тоже карта персонала. Людей надо как-то вытащить, в карте - есть замены и риски.
Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.
Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.
Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!
= Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителя =
Это был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору.
Рассказ сопровождала большая куча историй и законов, начиная с закона Мерфи: все, что можно сделать не так - сделают, который родился, когда на эксперименте команда техников прикрутила половину датчиков неверно. Расширенный вариант таков:
все, о чем можно подумать - вероятно, все вероятное - неизбежно, а когда есть варианты - случится худшее. Но Альберт - не пессимист, а реалист: если у нас половина стакана воды - надо дырку искать. То есть готовимся к рискам.
Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.
'''1. Люди'''. Мы нанимаем, работаем, увольняем.
Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.
Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.
После найма - онбординг, есть семь ступенек.
* Придти на работу
* Начать что-то делать - не все доходят до этого
* Делать хорошо, не вредить
* Хорошо и быстро - в темпе команды
* Хорошо, быстро и то, что нужно. А не сделать CRM чтобы MongoDB изучить.
* Хорошо и быстро то что нужно, и не только в своих интересах. Бывают эксцессы.
Как парировать риски лестницы?
* Главное - создать условия, потом требовать результата. Офис, рабочее место
* Дублировать и резервировать. Можно с аутстаффом договориться.
* Прозрачность - не пустое слово.
На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.
Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайшем будущем. Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.
Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.
Увольнение начинается с найма - проактивная позиция
* Вы должны быть готовы
* Озвучьте при найме правила увольнения, с вариантами (одним днем, две недели и так далее)
* Ведите сценарии на возможные риски увольнений
* Если сценария нет - вы полдня думаете, а ситуация может измениться, негатив.
Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
# Доступ получил, проект поднял
# Учебная задача
# Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.
'''2. Инструменты'''. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.
Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков
Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.
Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного
'''3. Работайте с надежностью системы'''. Люди - связи - процессы - изменение процессов во времени.
Проблема - степенная функция ненадежности. Надежность - что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность - степенная функция от надежности.
Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.
10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.
Связи. Ненадежность передачи информации, испорченный телефон.
Надо сокращать число элементов системы. Инструмент - выделение инкапсулированных элементов.
* Один специалист по React - он подчиняется тимлиду
* Их двое - одного ведущим, но кого? Он вводит дежурства, кто за старшего. Старший работает по ответственным задачам.
* Когда трое - он знает, кого назначить старшим. Когда четвера - заместитель, бас-фактор. Мини-группы по 3-6 человек. И они кристаллизуются естественно. А дальше делим пополам.
Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.
Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои HR, Техлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.
= Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) =
Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.
Я хочу отметить, что доклад по сути борется с основной ошибкой атрибуции, в просторечии "все уроды, а я д'Артаньян". Корень этой ошибки в том, что модель самого себя и модели других людей в мозгу разделены и слабо связаны.
А теперь - кейсы из доклада. Они - про ситуации, когда конфликт - это не отвлеченный спор, а когда в результате спора вам нужно что-то вместе сделать. И тут метафора деления пирога: все, что досталось ему - отнято от меня. Но часто есть возможность не делить маленький пирог, а найти пирог побольше. Всегда есть win-win. Выгодно в это верить. Потому что если верим - пойдем договариваться. А если не верим - то вообще не пойдем. А могут быть варианты.
1. Самый умный разработчик. Который, как казалось руководству не тщательно тестирует код, выкатывает с багами, пользователи жалуются. Итого, мы хотим, чтобы тестировал, а он - нет. А не хочет он потому что хочет быть самым умным. Но решили разобраться. И, оказывается, ему когда-то сказали, что самое важное - скорость выкатки фичи. Я проверяю основное, пользователи быстро ищут ошибки, мы исправляем. Скорость - важная. Но жалобы - тоже. И выяснили, что жалуются одни и те же - и из них сделали команду ранних последователей - и они перестали жаловаться, их замечаниям был другой статус.
2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.
3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.
4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.
С внедрением идей. Чаще всего не заходит не потому, что там - дураки, а потому что такое внедрение ставит под угрозу какую-то другую потребность системы. И с этим надо разобраться: нужно ли это изменение для системы и не не ухудшит ли оно что-либо.
Внедрение наполовину - какой-то компромисс, мы улучшили на половину, а риск не убрали. А еще хуже - заметание под ковер, просто редко здороваемся и забываем.
Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.
Реальные причины: (а) не договорились про критерии качества; (б) я не могу не делать брак - технология, компетентность, он случается; (в) я специально делаю браком - бывает, но очень редко. Штрафы - не эффективно, в последнем случае надо увольнять, а в двух первых - исправлять систему. Обвинить кого-то не значит найти решение.
Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.
= Александр Зиза (Aletheia Digital). 4 стратегии развития управленческого мастерства =
Александр показывал канвас, на котором можно работать со стратегими стратегического лидерства. И не только с ними, на нем можно работать с личным развитием и другими вопросами: канвас задает карту, между сегментами которой можно перемещаться при рассмотрении вопроса.
Карта - квадрат 2*2
* По горизонтали идет разделение между абстрактным (идеальными объектами) и материальным, включающим организации и поведение
* По вертикали идет разделение между индивидуальным, включая окружение - команду и общественным, взаимодействием с Другими, миром
Получается 4 квадрата:
* Слева вверху - собственные мысли человека, самопознание и самоопределение
* Слева внизу - поведение человека в команде или организации, область работы тимлида. Александр назвал это областью регулярного менеджмента, но, на мой взгляд, это неточно, потому что он включает регулярный менеджмент обечно предполагает классические подходы к управлению, а здесь речь идет о любых способах организации, но только в части операционной работы. Хотя, наверное, Александр опирался на каких-то авторов.
* Справа внизу - направление операционной деятельности, то есть стратегический менеджмент, а также управление изменениями и культура
* Справа вверху - проектирование стратегических изменений с помощью системного мышления и других технологий мышления
Задачи с помощью канваса
* освоение роли
* выбор и занятие новой роли
* создание новой структуры ролей - новая функция, которая сейчас все больше отходит тимлиду и команде
* создание инноваций перестройки системы разделения труда (СРТ) - предпринимательская, стартапы
Как они выглядят в нижнем слое? Стратегический менеджмент берет из верхнего слоя мысли, идеи, гипотезы, схемы и, главное, ставки. Ставка - это место, куда направляю фокус внимания. И за счет управления изменениями меняет регулярный менеджмент так, чтобы обеспечить удержание цели, формируя систему разделения труда, роли, процессы, коммуникации.
Стивен Деннинг в книге "Эпоха Agile" говорит, что сейчас нет разделения между регулярным (операционным) и стратегическим менеджментом, ими надо заниматься одновременно.
Проблема - недостаток смысла деятельности. В моменте она слаба, так как ситуация диктует импортозамещение и другие конкретные задачи, но раньше она была острой. и после решения текущих задач - вернется.
Регулярный менеджмент до 2000 включал делегирование, решение проблем, управление коммуникацией, плановые встречи и так далее. Добавилось: servant leadership, создание условий для самоорганизации, устранение препятствий, развитие компетенций, работа с клиентами и заинтереснованными лицами. Аналогично, стратегический менеджмент до 2000 года включал оргструктуру, процессы и регламенты, удержание смысла, создание ценности, инвестиции и прибыль, управление изменениями. Расширение - такое же, что как раз показывает, страние грани между ними.
Александр Залезник. Различение менеджеров и лидеров. Менеджеры делают задачи потому что должны, бесстрастно, следуя целям организации. А у лидеров - личное отношение к целям.
Я тут хочу сделать важное замечание. Классический взгляд исходит из того, что обязательно должен быть главный - менеджер. И когда он смотрит на Agile-команду, он тоже ищет в ней менеджера, как бы он не назывался. Собственно, замена скрам-мастера на тимлида - это именно такая трансформация. В классическом скраме в команде нет менеджера и product owner работает со свей командой по одним вопросам, scrum master - по другим, а команда - самоорагнизует свою работу. Постановка целей, удержание смысла, изменение способа работы через ретро - это все коллективные действия. А что касается sevant leadership, то эта концепция придумана, чтобы совместить концепт единоличного менеджера с новыми идеяеми о равенстве и совместной деятельности, дать смысл для менеджеров в этом мире. И, как таковая, она в значительной мере находится в мире идей, в верхней области схемы, а не материальном мире.
Верхняя область. Слева - как я думаю про себя, и что думают другие, с которыми я сталкиваюсь. Рефлексия, осознанность, мотивация, ограничивающие убеждения, эмоции, мораль, ответственность, раскрытие талантов, предназначение, амбиции и цели, волевые усилия, дисциплина. А справа - технологии мышления: стратегическое проектирование, понятия и представления, ценности, схема, онтологии, смыслы, идея, этика, системное мышление, критическое мышление, helicopter view, свобода.
Теперь посмотрим применение канваса на кейсах.
'''Мотивация много работать'''. Можно ее проводить индивидуально, с челвоеком, опираясь на его собственные желания. Это пряммой путь слева из верхнего квадрата в нижний. Александр Залезник говорит, что лидер - тот, кто умеет преобразовывать чувства и желания других в мотивацию.
Но можно идти косвенно, через правые квадраты, создание среды. Концепт: чтобы человек много работал, он должен много потреблять - и ему придется работать, чтобы обеспечить потребление. Реализация концепт дает современное общество потребления, где каждый много потребляет, и где каждое продвижение человека должно сопровождаться ростом этого потребления, чтобы он не стал работать меньше. Концепт прорабатывали Уайтхед, Шумпетер, Кейнс, Кондратьев, сделали это 100 лет назад. Я тут сильно сомневаюсь: Шумпетер, Контратьев и Кейнс работали над экономичекими моделями, а не над идеологическим концептом общества потребления. И это - существенно разное.
Путь в новое.
* Стартуем от текущего СРТ в левом нижнем квадрате.
* Поднимаемся наверх - самоопределение
* Придумываем конструкцию нового - правый верхний квадрат
* Реализуем изменения - правыый нижний
* В левом нижнем получается новое СРТ.
Но есть проблема, связанная с фрагментацией, целостно понимать все квадраты канваса - тяжело, часто не хватает каких-то элементов и шансов довсти изменения до успеха - мало.
Фрагментация возникает потому, что в каждом квадрате работает свой набор инструментов.
* Слева внизу - Навыковый тренинг и менторинг
* Слева вверху - коучинг, карьерный консалтинг, 1:1
* Справа вверху - Технологии мышления, образование
* Справа снизу - Бизнес-образование и бизнес-сопровождение
Каждый из инструментов - в руках специалистов. Поэтому и не связано в целую картину. Очень мало мастеров, которые бывали в разных местах. Если вы как начинающий предприниматель выбираете коуча, надо чтобы у него был свой бизнес и он не боялся вас потерять как клиента.
Самое большое количество инструментов - регулярный менеджмент, практические навыковые вещи. Все все слышали. Но не применяют. Самое дорогое - стратегическое проектирование. И сложное.
И дальше был разбор инструментов по квадратам. Что интересно, не только с точки зрения результатов, но и с точки зрения засад, которые препятствуют успеху. Главные засады связаны с эмоциями, здесь Александр опирается на модель Марвина Минский "Машина эмоций", которые рассматривал эмоции как некоторый переключатель режима для логики мышления.
Итак, левый нижний квадрант, обучение и подготовка, навыковый тренинг и менторинг. Преимущественно обучает действовать по регламентам и правилам. Важно: если вы хотите обучиться чему-то, например, стать мастером или руководителем, то надо находиться рефлексивно не только по поводу своей моей деятельности, и по поводу деятельности того, кем хотите стать. Джон Дюи говорил "Мы учимся не из опыта, а из рефлексии своего опыта".
А на массовом обучении рефлексию некому проводить. Поэтому появляется вместо конструктивной рефлексии появляется грусть и сожаление: надо было делать НЕ так. Пока нас накрывает грусть - обучиться невозможно. Поэтому тренеры борются с грустью, обучающие мероприятия превращаются в развлекательные, дают полозжительные эмоции, а вот результат такого образования - так себе.
Я тут хочу сказать, что от грусти и сожаления есть лекарство - протокол авторизации результата. Только не в позитивной форме, о которой кратко говорила Анна Обухова в своем выступлении, а в негативной, о которой она говорила в других. Почитать можно в моей статье [https://vc.ru/hr/1018029 Механизмы драйва и мотивации].
Левый верхний квадрант - личностный трек. Предпосылки: тоска на текущей роли, бесят другие, будущее не радует. Инструмент - коуч, другой об которого думать. Но мешает эгоцентризм - неумение учитывать и признавать разные точки зрения. Это когнитивное искажение, когда люди вообще не могут представить другую точку зрения. Здесь Александр ссылается на Пиаже. А еще мешает страх потери лица и потери статуса эксперта. И в результате коуч становится тем, кто просто принимает жалобы, а не коммуницирует критически. Кстати, этика коуча "нет обучения без запроса" этому способствует: коуч видит, что реального запроса на изменения нет и устраняется или превращается в утешителя. Тем более, если он работает в компании, и работодатели поставили задачу удержание сотрудника: реальный рост часто приводит к тому, что сотрудник уходит в другую компанию, где перспектив больше.
Правый нижний квадрат - Бизнес-образование, способы реализации предпринимательского замысла, стратегий, инициатив, внедрение лучших практик, управление изменениями. Цель - соответствие операционной деятельности целям и замыслам. Здесь конкретные фреймворки OKR, SWOT, Lean и так далее.
За рамками - мотивация участников к изменениям. Тут цитата из Кейнса: "Когда меняются факты. я меняю свою точку зрения. А вы?" И засада тут связана с недовольством, вызывающим гнев: рукоуводители недовольны исполнителями, не умеют восприниать обратную связь, а исполнители недовольны руководством. которое, к тому же, позвало консультанта, который "вообще не в теме", и сопротивляются изменениям. Консультант меж двух огней фокусируется на генерации идей, а не на их исполнении. или пытается провести изменения в собственных интересах, чтобы стать партнером.
Замечу, что очень часто говорят про страх изменений, это устойчивое выражение. А Александр эти части изменил: страх связан с квадратом личностного роста и связан с возможной потерей лица, а с изменениями организации связан гнев. Может быть, такое разделение оправдано, а может быть надо разбираться дитальнее, говорить о многомеррном пространстве, а не укладывать все в 4 квадрата.
И правый верхний квадрат - технологии мышления. Создание нового, изобретательство, предприниательство, выработка стратегий. И тут важно не оторваться от реальности операционной деятельности, а она за рамками рассмотрения.
Для широкого мышления важно не ограничиваться бизнесом, важно искусство, музыка. гуманитарные дисциплины: Пак Сонг Чжу из Южной Кореи полагает, что это надо преподавать в бизнес-школах, чтобы обеспечить широту мышления. А ограничением является отвращение к чужому мнению. Мы не любим, когда есть кто-то другой, который думает по-другому - идет борьба.
Целосная сборка для траектории развития.
* Нарашщиваю средства - левый нижний
* Вырабатываю план - левый верхний
* Мы видим мир по-разному и ищем что объединяет - правый верхний
* Из разных позиций строим деятельность на общих ценностях и смыслах - правый нижний.
Цитата из Сартра: "Человек, совершивший самоопределение - не только тот, быть которым он избрал, а еще законодатель, одновременно с самим собой избирающий человечество". Я рекомендую попробовать декодировать эту фразу самостоятельно. У меня получилось следующее: когда ты самоопределился, ты тем самым поменял весь мир. ибо смотришь на него по-другому. А что получится у вас?
= Анна Обухова (annaobukhova.ru). Как сделать так, чтобы команда наконец признала тебя лидом =
Рассказ о нейрофизиологических механизмах, которые лежат в основе признания лидером, то есть человеком, за которым стоит идти: прислушиваться к словам, поддерживать идеи, выполнять поручения и так далее. Общие нейрофизиологические механимы унаследованы человеком от приматов. И один из этих механизмов - определение лидера. Они действуют, и потому их надо учитывать. В докладе было 6 кейсов - вопросов, по которым вы могли увидеть разницу мышления лидера и не-лидера и оценить себя.
Есть эксперимент. Обезьянка. Научили доставать бананы из ящика и вернули в стаю. Учится ли стая? Зависит от статуса. Учатся только у высокоранговых. А низкоранговую гоняют как источник бананов. Приматы обучаются только у тех, кто стоит выше по лестнице. Опыт нижних игнорируется или их использут для поручений.
Как устроены эти механизмы? Есть два центра, которые вносят сильный вклад в регулирование наше поведение. Первый - миндалина - центр сильных эмоций. Она же оценивает социальные связи и там расположены зеркальные нейроны. Миндалина повреждается стрессом, стрессоустойчивосать - часть лидера.
Зеракльные нейроны. Мозг считывает состояние другого человека в коммуникации и интерпретирует - скука, интерес и так далее. Когда мы считываем влиятельного - меняется наше поведение. н видит это изменение - и идет реакция.
Второй центр - Хабенула. Проверяет, если вероятность - не 100%, то: ты ходил, там может быть больно, ты облажаешься - тебя съедят. Хабенула боится, когда есть социальный элемент: я предложу, они ен поддержат. Нам надо преодолевать, и насоклько эффективно делаешь - тем больше лидер.
Я тут хочу сделать важное замечание. Миндалина и Хабенула не реализуют встроенных алгоритмов, их нейроны тоже обучаются. Механизмы обучения, к которым в ходе эволюции природа перешла на млеопитающих от инстинктов и рефлексов, требуют, чтобы ребенок следовал за взрослым - на этом построено обучение. И ребенок должен определять: за кем следовать, и этому он тоже обучается: есть следование за родителями, а вот следовать ли за другими детьми, своего или старшего возраста, или другими взрослыми - он определяет самостоятельно, и есть возрастные динамики, связанные с тренировкой этого механизма. Включая переходный возраст, подростковый период 12-14 лет, когда закладываются убеждения. На этом эффекте, кстати, построена теория поколений, Анна говорила об этом в одном из предыдущих выступлений: подростки выбирают своих кумиров в этом возрасте, влияние родителей не велико, и потому следующее поколение отличается от предыдущего. Но дальше конкретную теорию построили на анализе однорожной социальной группы мамериканских менеджеров и произвольно распространили на всех, поэтому теория реально плохо применима. А если брать сильно дифференциированные общества в эпоху революций и общественного переустройства, как было в России в 90-е и 2000-е, то поколение получается неоднородным.
Итак, ребенок тренирует нейронную сеть, у кого стоит учиться, у кого - нет. А еще - кому надо подчиняться, а кому - нет. И это - разные вещи, которые исследователи часто произвольно объединяют в слово "статус". Это легко видно по школам: дети к разным учителям относятся сильно по-разному, и с точки зрения авторитета, и по подчинению, и между ними и учителями выстраивается сложная система, не сводимая к одному измерению статусом. Государство предпринимает специальные меры для поддержания формлаьной системы статусов, которая ему выгодна, к тому, чтобы все одинаково оцениваи героев литературы и фильмов и так далее. Сила влияния этого процесса зависит от силы конкретного государства. И этот социальный процесс, если мы ведем исследования механизмов нейрофизиологии, надо отделять. То есть смотреть проявления на разных социальных группах и в разных обществах и культурах. А в тех кейсах, которые далее приводила Анна, это не разделено, они относятся к конкретной американской культуре, да еще, я предполагаю, к относительно узкой группе американских менеджеров. Для которых статусы - линейны, и они на все смотрят именно таким образом. Поэтому, когда они смотрят на традицию восточных монахов, то они видят, что там монахи меряются скромностью, как менеджеры меряются айфонами и ролексами. Это было в ответах Анны, и, думаю, почерпнуто из исследований. А жизнь - богаче, и для понимания, что в нас из нейрофизиологии, а что - определено социумом, надо разделять. Только тогда можно делать перенос прикладных результатов между культурами.
Возращаюсь к докладу. Итак, кейсы. В каждом - несколько формулировок для самооценки и баллы лидераства. Это записано пунктиром, презентации скоро опубликуют, детали лучше смотреть там.
Кейс-1. Вертолет упал в тайге, все выжили - какое первое действие? Для баллов его надо классифицировать на 3 категории.
* Сделаю сам 0
* Дам задания другим +1: это отражает внутреннее право давать задания, предлагать, и принимать риск.
* Жду, когда мне скажут что сделать. -1
Кейс-2. Ты хочешь предложить идею команде. Что повлияет: предыдущий проект; ты выспался; с утра сделал несколько успешных дел. Ответ: это все работает на статус, но больше всего - то что произошло в предыдущие 6 часов. Если проект не вспоминали за это время - он забыт. Теплая рука в баскетболе.
Есть эксперимент с мышкой. У них статус - через драки, и они тоже оценивают вероятности. Если мышку подсодить к сильной альфе - она забьется в угол. Но можно предварительно посадить к слабым, она полезет драться, и если это повторить 6 раз, чтобы были победы, а потом подсадить к альфе - будут победы. Кстати, я думаю, что этот эксперимет ясно показывает: обезъянку из первого эксперимента могли научить не только открывать хитрый ящик, но и способу изменить свой статус через это преимущество, провести тренинг личностного роста. Но - не сделали.
Авторизация результата. Это методе получения уверенности, был как краткое упражнение. Анна много раз рассказывала о нем, потому что он прост и эффективен. У меня есть описание, собранное по ее докладам [https://vc.ru/hr/1018029 Механизмы драйва и мотивации]. А сам метод из 4 пунктов.
# Стартовая ситуация
# Что делал - активный глагол.
# Результат позитивный. Мурк. 14 единиц
# Для чего было нужно, как я использую на благо себе, в какую деятельность встраивается. Еще 20 единиц.
Кейс 3. Вы - лидер. появился человек или группа, которые оспаривают статус. Что поможет удержать?
* Хорошие отношения с девочками.
* Хорошие с мальчиками.
* Подружиться с тем, кто оспаривает.
* Привлечь соратника, с которым связан и за пределами команды.
Правильный ответ зависит от ситуации в команде. В хорошей ситуации надо дружить с девочками, когда все хорошо - девочки в обиду не дадут. А вот если в команде не очень хорошо, есть проблемы, то надо опираться на соратника. Потому что две обезьяны всегда забьют одну, на уровне нейрофизиологии восприятие такое. А вот вариант подружиться с тем, кто оспаривает - безопасно и соответствует представлениям о мире и сотрудничестве, но статус - роняет.
Кейс-4. Хорошо поработали, продукт успешен, делим прибыль.
* Много себе, немного другим +2
* все себе ничего другим +1
* мало себе много другим 0
* только другим у меня все есть -1
Скромность - не про власть. Больше любят, привлекает как к человеку но не характеризуют как лидера. У меня все есть - только когда однозначно считывается.
На мой взгляд, этот кейс наиболее подвержен влиянию той культуры, на которой проводили исследования. Известный американский афорищзм "победитель получает все" - он из этой культуры, и там такой способ представляется справедливым. А вот в японской и китайской культуре более распространена концепция справедливой длоли, и от лидера ждут такого поведения. В России - по всякому, потому как нынешнее общество сильно неоднородно по своим идеалам, в компаниях и командах разные идеалы смешиваются. Хотя какая-то часть уже осознает необходимость культурного выравнивания, и на входе проверяет соответствие. А справедливое деление вознаграждения - одна из существенных составляющих. Только не надо забывать, что в корпоративном мире распространено двеомыслие, разрыв между декларациями и фактическим положением дел.
Рыбки-гальяны, которые послужили формой крекеров, плывут стаями, одна куда все остальне. В стае не интересно, но не страшно. И находится рыбка, которой интересно и не страшно - и отплывает. Но вдруг понимает: "я одна, меня съедят" - и возвращается в стаю. Но находятся сумасшедшие, которые не возвращаются - и стая разделяется. Впрочем, на мой взгляд, это антропоморфизация, потому что у рыб нет эмоций, у них поведение управлется рефлексами и инстинктами, а эмоции появляются у млекопитающих.
У человека любопытство и отсутствие страха соответствет ситуации, когда много дофамина и мало кортизола, это видно по миндалине и хабенуле. Как это проявляется в поведении? Более спокоен, не боится неопределенности будущего, берет ответственность, есть план и уверенность в нем. Лидер видит дальше и может защитить. И это - иллюзия: раз сделал для себя - надеемся, что для нас тоже сделает.
Отмечу, это сильно зависит от культуры. В культуре силы, которай хорошо описана в легендах и мифах Древней Греции герою часто наплевать на спутников, он совершает подвиг. В более рациональных культурах сотрудники - ценный ресурс для достижения цели, и о нем надо заботиться. Но встречается отношение как к расходуемому ресурсу: люди - что дрова, от дождя укрыл, но когда потребовалось - кинул в костер. Заранее, конечно, об этом не говорят. А есть те, кто реально относится к сотрудникам как к партнерам, а не как к материалу. И хорошо бы это представлять.
Кейс-5. Как часто вы разговариваете про дальние перспективы?
* ежедневно +2
* раз в неделю +1
* реже 0
* только текучка -1
Смысл и цели деятельности важны, без него мозгу неприятно, возникает неопределенность. А без разговора люди не поймут. И чем важнее держать его в jarect? там чаще надо говорить, потому что активация нейронов держится примерно 6 часов, именно такое время смысл будет в активном контексте и будет влиять на принимаемые решения "по умолчанию", не требуя специального вспоминания.
Мышление. Для простых проблем достаточно внимания, фокусированного на реализации будущего. Для сложных нужно сложное мышление, выявление трендов, формулирование будущего, учет взаимных связей. Тут есть эффективный инструмент - факт карты бизнеса Курпатова.
Кейс-6. Воспринимают ли тебя как защитника на уровне нейрофизиологии, определяется ответом на вопрос о твоем стрессе:
* нет внутри и снаружи стресса не видно +2
* внутри в стрессе, но стараюсь показать +1
* нервничаю но не опух - 0
* уже опух -1
Опух - это объективная реакция на стресс, в нем почки работают по-другому.
А еще - блестящие волосы или лысина, холеность. Брюнетам повезло, более гладкие. Кудрявых блондинок - любят, но лидерами не считают.
Вождей отличают статусные аксессуары - можно потратить ресурсы на всякую хрень. У каждой социальной среды аксессуары свои. А еще суровый, а не любезный взгляд, недовольство окружающими. Впрочем, тут тоже проявляется влияние социальной среды при воспитании: если родители с придыханием смотрели на какие-то аксессауары как признаки сильного челоека, то дети тоже будут их искать, хотя набор статусных аксессуаров он может и сменить. А вот если родителям было реально, и они это явно транслировали, что так поступают лишь глупые гламурные особи, у которых других достоинств нет, и ржали над этим, то детям тоже будет безразлично. В России таких не мало, это наследство советского периода, хотя там тоже отношение к аксессуарам было разным. А вот американское общество - очень статусное, и даже при игре в хиппи важно купить прикид в правильном и дорогом магазине. Отсюда продвижение брендовых рваных джинсов, а пару лет - и рваных коготок от Gucci.
Кейс-6. Пришли на совещание, нужно предложить классную идею. Как сядете? Лидера отличает большое пространство, открытая поза, медленно и плавно двигаться. А еще есть нетривиальная штука. Правую половину поля зрения человек видят левым полушарием, рационально, а левую - правым, эмоционально, далее картинки совмещаются. И это можно учитывать, располагаясь в том поле, на реакцию которого ты рассчитываешь, а оппонента помещая в противоположное. Впрочем, по-моему, тут требуется прояснение, потому что представление, что левое полушарие связано с рациональным мышлением, а правое с эмоциями - опровергнуто, сама Анна рассказывала, что за эмоции отвечает внутренний котик, лимбическая система, расположенная под корой, а полушария отвечают за мышление. Хотя, исследования говорят, что разница все равно есть, но другая: левое отвечает за иерархию концепций и абстракций, в нем расположены речевые центры. а правое - за многобразные ассоциативные связи.
Как сделать себе мозг виятельного человека.
# Вызывать предлагать активности
# Авторизовывать результат, опора на себя
# Строить структуру поддержки своего статуса
# Брать себе лучший кусок
# Видеть, думать и обсуждать будущее
# Выглядеть здоровым, богатым и счастливым
# Больше влиять через эмоции людей
От себя добавлю - и помнить те оговорки, которые я сделал по поводу социально-культурного разнообразия людей и учитывать ту среду, в которой взрослели люди, с которыми вы работаете, потому что их нейронные сетки обучались на конкретных примерах этой среды.
В заключении хочу дать ссулку на сборник конспектов разных выступлений Анны Обуховой, а также других спикеров по темам, связанным с психологией и нейрофизиологией: [[Анна Обухова и другие про нейрофизиологию в работе]].
= Рита Канис (Just AI). Как убить всех зайцев: про управление знаниями исподтишка =
Это был рассказ про формат Just Talks, который был сделан "между делом", но привел ко многим позитивным сдвигам. Доклад - часть трека Knowledge Conf посвященного темам управления знаниями. Как я писал, со следующего года онтико планирует выделить этот трек и еще ряд тем в отдешльные однодневные конференции.
Рита работает в отрасли с высокой динамикой: меняются знания, технологии, сотрудники. Отвечает за обучение, внутреннее и внешнее, и за выступления на конференции. В условиях высокой динамики эффект от больших проектов обучения не слишком понятен. А есть желание этот эффект увидеть. В свое время она была на лекции, в которой ее поразила неформальная обстановка. И она решили попробовать сделать такой формат.
JustTalks. В пятницу 3 спикера по 15 минут под пиво. Для организации первого - просто подошла к знакомым коллегам. И не было задачи обучения, идея - просто веселиться. Поэтмоу три принципа.
* Добровольное участие спикеров и слушателей
* Свобода выбора тем - о том, что вдохновляет. Она может обсудить уместность конкретной темы - какую ценность она принесет людям. Но спектр пользы - свободный, он не ограничен работой.
* Все получает удовольствие - придумано ради этого
Но это же просто обычный митап, разве нет? Да, 1.5 года назад это были обычные митапы, отличающиеся тем, что после нее была вечеринка. Но она почувствовала, что что-то изменилось. Это трудно сформулировать, но ощущения, как от солнца в ноябре. Наиболее проявлено - что стало легче приходить к людям - выступать на конференциях, к партнерам и так далее. То есть поменялся имидж отдела обучения.
Тут сработал принцип добровольности: мы все приходим на конкретную роль, и пространство свобод ограничено этой ролью, а JustTalks стал реальным пространством свободы. И уже после второго - очередь желающих выступить.
Еще в обучении мы все время накручиваем фреймворки, делаем сложное. А тут - пошло замечательно.
И когда почувствовала, что проект - больше чем развличение, влияет на компанию - он стал больше, чем митап.
Но нужно управление, при чем мягкое. Метафора: зайцы в лодке деда Мазая, их надо подправлять, чтобы не выскочили.
Какие проблемы решает JustTalks
* Расфокус команд
* Сложные взаимоотношения с экспертами
* Проблемы с донесением информаици и обучением
* Низкий имидж отдела обучения
Теперь подробнее.
1. Расфокус команд. В хаосе сложно ориентироваться, если нужны люди. И ты просто наблюдаешь и запоминаешь. Но там столько проблем, что невозможно. Сейчас дела получше. Стало больше встреч, летом - популярный корпоратив. JustTalks объединил доклады из разных миров. Мешали доклады разных отделов, ребята знакомились. Больные темы, маректолог разработчикам "я знаю, что вы не верите, что маркетологи делают полезное". Доклады про жизнь, про бег. ВЫступление руководителей вместе с другими. Доверие - потому что общались на JustTalks и ты помнишь, как чел расскзывал про кроссовки.
2. Сложности с экспертами. Они прячутся в тени. Люди переходят между командами. Кто эксперт - непонятно. А если пришел - он говорит "я человек простой, особо ничего не знаю". Сейчас есть пополняемый пул экспертов - список с компетенциями и направлениями, куда направить. Тимлиды признают важность выступлений для экспертов, отпускают.
Эксперты - люди выстроились в очередь и даже сделали мем: если кто умничает, то "сделай JustTalks", или сам человек говорит "не зовите делать JustTalks".
Она поняла, что ответ "я простой человек" - это не страх. Это люди убеждены, что право выступать могут только особые люди. В любой области есть пирамида прошаренности, и ложное представление, что выступать могут только те, кто наверху. А это - не так, если выступление для тех, кто слабо разбирается в теме, им не интересно, что говорят суперумники, они их не понимают. И суперумникам не интересно рассказывать базу. И ты показываешь, что рассказ - не для экспертов, а для тех, у кого меньше опыта. Или столько же. Не только на JustTalks, но и на других площадках дело обстоит именно так.
А еще она привлекала новичков на выступления. Они пока не в курсе культуры, "так принято" - и они делают. И быстро интегрируются в культуру. Я тцт отмечу, что не только интегрируются, они ее делают и действительно становится принято выступать.
3. Донесение информации. Задача: донести знание про апельсин из А в Б. Все концентрируются на А и апельсине: как я расскажу то, что знаю. А релаьный вопрос про апельсин и Б - надо загрузить в голову, чтобы разобрался.
Проблемы
* Сложно говорить на языке бизнеса - на продуктовом демо. Экспериментировали миллион раз: перевернутый класс и так далее. Попытка написать техническую сложнсть просто - тяжело.
* Низкий уровень знаний о продукте в принципе
* Всем кажется, что обучение - это просто. Рассказали, практика, обратная связь и все.
Как изменилось? Мы стали чаще задавать вопрос "Зачем?", например, зачем проводим демо? Оказывается, что у всех разные мнения: отчет, обучающая встреча... То есть люди не договорились. А реально - демо для команды продаж, чтобы они лучше продавали лучше. И тогда следующий вопрос: как демо должно измениь команду продаж? Правда, тут же появляется еще один - а мы отвечаем за головы других людей?
Обучение требует не только подготовки структуры, но и проектирования опыта слушателя. Компания пришла "обучите". Они придумали классно, как расскажут. Но оказалось: обучение в 10 утра после майских. Провал. И теперь задают вопрос - что должно изменится у обучаемых.
Образование - не в том, чтобы наполнить ведро, а чтобы зажечь огонь.
Два вопроса для того, кто хочет выступить на JustTalks
* с какой мыслью выйдет слушателей после твоего доклада.
* В 10 словах объясни, что ты хочешь сказать.
Это сложно. Но мощно прокачикает.
Проектировать обучение доклад надо с конца. Что надо сказать, чтобы человек так изменился.
Они на основе опыта сделали фреймворк на 15 минут выступления: вступление, основная часть, выводы. Подробнее был на слайде.
4. Имидж команды обучения. Было: сам организуешь и все подтаскиваешь. Сейчас: отдыхаешь и наблюдаешь. Не только проект повлиял, но он - тоже.
Из обидного
* изменение культуры сложно посчитать
* хотели поплнять базу знаний - не получается, люди рассказывают про другое
* с сеньорами и руководителями - по-прежнему сложно
= Алена Рыжкова из ИТ-холдинг Т1. Как эффективно скоординировать работу 10 разношерстных команд для успешного закрытия проекта на примере реальных кейсов. Мой личный фреймворк организации проектной работы =
Это доклад о конкретном фреймворке, который сложился у Алены для управления проектами, выполняемые сборными командами сотрудников, работающих по совмещению. На мой взгляд, получился хороший легкий фреймворк, которым можно пользоваться. Тем более, что Алена хорошо расскрыла внутреннюю логику. А если представлять его место в других методологиях, то можно и обогощать другими элементами при необходимости - ведь фреймворк должен соответствовать тем проектам, а проекты у всех разные. Об этом я напишу в конце.
Типовая задача у Алены: вывести зи эксплуатации сервис X и заменить на другой сервис Y. Обычно высоконагруженный. Под задачу создается команда из разных специалистов, но ее участники работают не только над этим проектом, а основное подчинение - другое.
В фреймворке три основных элемента: инфополе, процессы и ценности, в каждом - свои составляющие.
'''1. Инфополе'''. У разных участников - разный контекст и понимание проекта. Был проект, где выводили вендорскую, и внедряли свою. Рядом с вендорской был доп.модуль, костылями и интеграцией. И они обрадовались, что он будет в новой системе. А оказалось, что команда разработки воспроизводила систему вендора как есть, без расширения. Обнаружили не сразу, договаривались долго.
Из чего состоит инфополе?
'''1а) 1-страничное описание'''. Цель, задачи - скоуп, заказчик, карта с вехами, зависимости и риски. Важно: задачи должны быть поняты всей командой. Для этого надо рассказать подробнее. Карта бизнес-процесса с системами и потоками. Формулировка - кратко, просто и понятно. И если спец.термины - нужно толкование, в команде разные участники. В сложных способах - еще и проверять понимание.
Заказчика надо знать в лицо и это тот, кому будем сдавать проект. Форма карты - зависит от проекта - масштаб, насколько проект знакомый, она показывала свой.
'''1б) Зоны ответственности'''. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.
DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.
По зонам надо предложить свое, собрать предложения, зафиксировать договоренности.
'''1в) Дорожная карта'''. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.
Получается общее информационное поле. Но просто сказать после этого "поехали" - не достаточно, надо реально стартовать работы. А то приходишь - а оказывается, что все заняты другими делами. Почему? Потому что делают те проекты, по которыем создается информационное давление - на статусах, от менеджеров и так далее.
'''2)''' Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.
'''2а)''' Основное - '''статус проекта'''. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.
'''2б) Рабочие группы по выявленным проблемам'''. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.
'''2в) Чат в мессенджере'''. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.
Статус, рабочие группы и чаты нужны в любых проектах, даже маленьких. Причины факапов чаще не технические, а организационные. Серые зоны ответственности и прочее.
'''3. Ценности и принципы'''. Нужна мотивация и понимание, в чем смысл - это отдельные блоки. Они зависят от проекта. Но еще есть принципы - верхнеуровневые праивла, которыми мы руководствуемся. Они определяют как поступать правилами, что держать в фокусе внимания. И не просто записать, а реально применять. Для этого надо приземлять принципы через паттерны и антипаттерны.
Ее принципы: Открытость, Поддержка и Лидерство. И были слайды, где для каждого были паттерны и антипаттерны.
'''Открытость''' - предоставление всей информации всей команде проекта. Нет отдельного чата разработки, приглашение на статусы всех заинтересованных. Она первой пригасила на статусы ИБ, сначала напряглись - потом пошло сотрудничество.
Открытость с руководством. Если пошли задержки - надо сразу говорить. Во-первых, они компетентны и заинтересованы и помогут. Во-вторых открытость рождает доверие, а оно критично при факапах.
'''Поддержка'''. Атмосфера, к которой не чувствует брошенным с проблеми, не боится быть осмеянным или обруганным. Это не значит, что он решит за команду - но он поддержит, поможет и направит.
'''Лидерство'''. Это не про то, как кто-то на белом коне ведет проект к успеху, это за ответственное отношение к результату, его должна показывать вся команда. Надо выдвигать аргументы и защищать. Не все умеют и считают уместным, но надо этому учить.
В целом получился легкий фреймворк. На мой взгляд, очень напоминающий то адаптивное управление проектами, которое продвигает Павел Алферов из своего опыта, сократив классику до необходимого минимума. Кстати, как источники, где можно посмотреть, Алена указывала PMBOK - там есть все, можно брать элементы. И фреймворк p3.express/ru. А я бы дополнил этот список практиками Kanban и социократии. Вопреки распространенному мифу, Канбан - это не упрощенный скрам для потока задач, это способ работы и совершенствования методов организации работы. И там много различных практик, а также технология определения узких мест в ходе проекта. А социократия - еще один подход, который можно использовать как источник для полезных практик. И организация рабочих групп для решения вопросов, которую Алена описала - одна из них. Ее, кстати, можно применять для решения проблем, которые выявили ретро, только там время работы больше, был интересный доклад Ростелекома об этом.
= Алексей Макаров (Xello). Команда разработки за свой счет =
Очень интересный доклад о том, как поменялся взгляд на разработку, когда Алексей стал одним из владельцев компании, открытой на собственные деньги, без внешних инвесторов. Произошло это три года назад. Ему всегда хотелось делать что-то свое, а тут пришел знакомый, принес идею, предложил вместе попробовать сделать. Они начали в режиме хобби, а потом был момент, когда надо или прекращать, или делать продукт командой. И они решили создать компанию на свои сбережения: посчитали в оптимизме, что с первой сделки окупится, но нет. Были ошибки с наймом, другие проблемы с организацией, ковид остановил многие инвест-программы у потенциальных заказчиков, а цикл сделки у них долгий, до 2 лет. И им приходилось брать кредиты на зарплату, выживать, в ряде обсуждений проблем как один из вариантов было "закрыть компанию". Сейчас уже стабилизировалось, компания успешно развивается. Но путь был трудный, и не факт, что зная его, он бы пошел. Сейчас он изменился, и вернуться в найм - точно не сможет.
Да, в конце был вопрос про инветоров, разные фонды. Ответ: по факту их нет. Они появились с предложениямИ, когда компания стала успешно развиваться, и их деньги, по сути не нужны. А когда были реальные трудности и не хватало финансирования из возможностей был только банковский кредит.
Итак, как меняется взгляд на разработку, когда ты - владелец компании, которую основал на свои деньги?
В большой компании всегда зависишь от людей и их решений - от тех, кто вверху, и от тех, кто внизу - тоже. В своей компании ты сам должен все решать. С одной стороны, за этим и шел, когда делал компанию. Но, с другой, в найме, когда есть проблемы - можно поделиться с руководителем. И это, как бы, прозрачность, а не не перекладка ответственности, и прозрачность - нужна, скрывать проблемы - плохо. Но по факту сущесвтенную часть отвественности ты при этом отдаешь.
В своей компании владелец - конечная точка принятия решений в сложных случаях. На обсуждении среди вариантов часто было: закрыть компанию, и старались придумать иной вариант. И ты перестаешь бояться ответственности, бояться непопулярных решений, не по best practice, странных решений.
А еще становишься прагматичным. Пять лет назад он собеседовался: два собеседования, тестовое задание, он реально вложился. А в итоге не взяли, потому что в интерфейсе несколько элементов сделал не по макетам - а там требовался кастомный элемент. Ему казалось, что они - придираются. Сейчас для него важно, чтобы выглядело как ожидается. Впрочем, на мой взгляд тут важно раскрыть тему. Потмоу как если кастомынй элемент удваивает стоимость разработки и поддержки, то в чем прагматика? Требования дизайна должны быть реально обоснованы, а не просто картинка, бездумное выполнение которой. в общим-то, частный случай подхода "ты начальник - я дурак".
Еще история. Собеседовали бэкенд. Кандидат топил, но не агрессивно, за DDD. На вопрос о минусах - просто надо уметь готовить. И его не взяли, потмоу что риск, что вместо обсуждения проблем они будут обсуждать DDD - насколько правильно его применять, что он будет постоянно его проталкивать. И такое же отношение к людям, который топят за чистую архитектуру, типизированные языки, брокеры сообщений вне контекста конкретной проблемы. В больших компаниях - много таких холиваров. Аннотации, архитектура, брокеры сообщений. Вообще, а не по месту.
Вопрос: на чем бы писали сервис с нуля. Кто-то выдает вариант, кто-то топит за знакомое. Как лид ты должен в эти холивары приходить и очерчивать правильную точку зрения. Потому что лид. И в найме он боялся нанимать людей сильнее себя - тебе не нужна конкуренция. Тем более, что видел примеры, когда увольняли сильных ребят, с формулировкой: самодеятельность и дестабилизация проекта.
В своей компании ему было сложно было собеседовать людей не в своей области: дизайнера, фронтэндера, рекрутера. И надо преодолеть идею, что лид - самый сильный. Ты не должен быть самым сильным, ты должен руководить сильными.
Когда у тебя небольшая команда, тебе нужно быть эффективным. Найм - дорого. Три месяца закрытие позиции, три месяца испытательный срок, стоимость - 6 окладов рекрутера, база кандидата 500-600к, CRM рекрутеру не дешевая. Еще собеседование, это 2 часа. если с фидбэком. Увольнение после испытательного срока - еще более дорогая штука. Выходное пособие, сроки, замена нового. Поэтому контрофер так эффективен - компания не хочет нести риски. Они допустили 5-7 ошибок, наняв неправильного человека - и это релаьные затраты.
А на старте их спасало, что нанимали друзей и друзей-друзей. Было доверие и лояльность. А не харды. А потом фокус на хардах привел к ошибкам. Когда работал в найме, то обо всем этом не думал: скорость и эффективность найма, стоимость...
Еще он не сталкивался с финансовым планированием. Для него оно кончалось оценкой проекта, и если оценки оказывались неверными, то как бы ничего страшного, ну, поругают. А тут: ставки под найм, премии, бонусы, бюджеты на тимбилдинг и корпоратив. И в отличие от burndown, который не сходился, финмодель должна сходиться. Без дефицита и кассовых разрывов. У них цикл сделки до 3 лет, в пессимистичном плане живешь медленнее. И в реалистичном тоже - можно поймать кассовый разрыв.
И это научило серьезнее относится к планированию задач. Потому как у кого-то нет права на ошибку, а у кого-то всегда обстоятельства. В найме - не было личных обязательнства по срокам. Он искренне стремился, и предупреждал, но не более. Сейчас он очень чувствует, что бизнесу нужны астрономические реалистичные сроки. И надо поток запросов обрабатыать. Приоритеты и оценка. Рефакторинг и смена фреймворка - этим можно пренебречь, заработать, и потом делать.
У них OnPremise решение для large enterprise - 3-4 релиза в год, регресс около месяца. Живут в канбане, 2-недельные спринты не интересны, задачи большие. Строят кумулятивные метрики, выявляют узкие места, например, накопление задач перед тестированием. И Control Chart - смотрят метрику рассеивания данных. Графики - способ искать аномалии: отличия разных команд, влияние увольнений. А сроки - дают лиды.
Я хочу отметить, что про сходимость модели не взирая на неточные оценки - это верно. Потмоу что есть засада: ошибки оценки статистически компенсируются только при нормальном распределении, а для задач в ИТ статистика показывает распределение с длинным хвостом: пуассоново или логнормальное. Об этом есть хороший [http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk доклад Андрея Бибичева «Пуассоново горение сроков»]. И чтобы попасть с оценкой в два сигма, оценка должна быть втрое выше матожидания, двухкратный резерв. А точно оценить можно, лишь наполовину сделав задачу. Это - объективно и да, фин.модель должна сходиться даже с учетом такой объективной неопределенности, как совладелец компании я это тоже хорошо понимаю. Как это делать - отдельная тема. Часть этой задачи можно возлагать на руководителей проектов или тимлидов, но если бы они были готовы полностью принять такую ответственность - у них бы были свои компании. А если просто жестко давить - они будут завышать оценки тем или иным образом.
= Евгений Идзиковский (Частная практика). Legacy-код в психике — как расплатиться со своим техдолгом =
Если рассматривать мозг как большой софт, то в нем много legacy-кода, который возник ситуативно. Это - хорошая аналогия, с той разницей, что код софта писали программисты, а код мозга был порожден в ходе обучения. Но в обоих случаях когда-то была приемлема решена какая-то локальная задача, а потом этот фрагмент сохранился. Этот механизм свойственен не только человеку, так же работает мозг кошки или собаки, которые вообще не мыслят, однако решают довольно сложные задачи обеспечения питанием, поиска партнера для размножения, социальных взаимодействий. А рефакторинг не предусмотрен, если только механизм не начал давать серьезные сбои. В дикой природе животным некогда заниматься рефакторингом, надо выживать.
А вот человек - он рефлексивен по отношению к своему поведению, и часто хочет изменить каки-то действия своего обученного автопилота, не доводя последствия до серьезных сбоев или просто узнав, что существуют другие, более эффективные способы действия. Провести рефакторинг. Именно этим занимаются психологи, и для этого наработано много методов терапии. При этом, однако, исследования показывают, что эффективность каждой конкретной - 25%. Но вот если действовать интегративно, применять их в комплексе с учетом конкретного человека и задачи, то коррекция возможна, при чем достаточно быстро, за 1-2-3 месяца. А если вы ходите два года и проблема не решается, значит к вам применяют неверные методы, учитывайте это при выборе специалиста.
Дальше в докладе был обзор методов психотерапии на понятном разработчикам языке работы с легаси. Это было устно, и я записывал в телеграфном стиле. Но на своем канале @idzikovsky_psy Евгений обещал в ближайшее время выложить подробную презентацию, где раскрыть содержание. Он - профи и знает много методов, чаще использует гипнотерапию, осознанность и НЛП совместно, дополняя другими по необходимости.
Итак, психотерапия как работа с legacy-кодом.
Для начала - архитектурная схема: есть входной сигнал, два канала обработки - эмоции и мысли, которые между собой взаимодействуют, и выход - поведение. И там возможны ошибки двух типов.
* Ошибки распознавание. Смотрим на собаку, которая бежит к нам, хочет сделать кусь, и у нас страх. Психика угадала - хорошо. Но может дать такой же ответ и на маленькую собачку. Получаются разные фобии. Не все страдают, они просто избегают этого. И там - проблемы. Хорошая девушка, хочу познакомитсья, но не подхожу - психика выбрала какой-то страх, а не предвкушение интересного знакомства.
* Второй тип ошибок - психика выбрала неправильное поведение. У человека инстинктов нет, все результат обучения. Два года, мозг сгенерировал какой-то шаблон, и если оказалось удачным - оно классное. Оставим. И все время мы копим какой-то код в мозгу. Время рефакторинга - не было. Потому что рефакторинг в дикой природе - нерационален. Надо еду добывать.
Формирование ошибочных шаблонов может идти тремя разными способами.
* Разовая ошибка, что-то сделал, она сделала кусь - и это зафикисровалось как негативный шаблон через эмоции.
* Мама говорила "ты лох" или "ты глуп" или "не высовывайся" - и ты следовал этому, потмоу как она говорила многократно.
* Родители не кричали, но показывали, что расстроены: мы любим, когда ты себя ведешь таким образом, а когда по-другому - не любим. Это тоже отпечатывается эмоционально, но по-другому.
* Подражание родитетелям заложено как способ обучения. И это правильно: родители же выжили, значит классные шаблоны. Но они выжили в других ситуациях.
Что можно сделать для рефекторинга сознания?
# Влезть в хардвер.
#* Волшебные таблетки и подобные штуки. Перформить на 80% лучше, чем сидеть в депрессии. Еще есть таблетки, которые выключают страх на время, например, вырубая страх выступлений - он накапливает опыт.
#* Обруч обратной связи - выводит на экран то что происходит в мозгу, ЭЭГ на сухих электронах. Видео шлем. Человек боится авиаперелетов - это надо протестировать. Запускают эмуляцию на очках, снимает с обруча страх. Потом провели терапию, и эксперимент повторяют, убеждаясь в эффективности. Не на словах, а экспериментом.
# Перехват кода. Контроль "не делай этого". Здесь все практики осознанности. Тренировки нужны, чтобы поднять порог эмоций, которые боимся. Напрмиер, подойти к краю, где высота. В 1980-е были эксперимент - есть ли свобода воли, или есть предписанные процессы. Снимали МРТ, оказалось, что за полсекунды приборы показали, будет ли он это делать. Вывод: свободы воли нет, все предопределено. А в 2015 - другие эксперименты, и они показали приборы фиксировали готовность, а мозг - управляет. И осознанность обеспечивает это управление. Но его надо нарабатывать, из коробки его не дают.
# Отредактировать код.
#* НЛП - оно создано для этого. Можно менять тембр головса или скорость речи и так далее.
#* Позитивная психотерапия - по-другому смотря на вещи, выбирать другие шаблоны.
#* Терапия частей, гипнотерапия, гештальт. Даем ТЗ на некоторый код, внедряем, и применяем в жизни.
# Мы внедрили новый код, запускаем его в модельной ситуации, а в жизни сетка запускает старый. Тут терапия осознанности и гипнотерапия, она перекодирует принятие решений. Пересобираем решения.
# Экзистециальная терапия: говорит - в жизни есть важное, его надо удерживать в фокусе, когда действуешь.
# Метапрограммирование систем. Средняя семья - клуб чудовищ, и можно работать с ними всесте как с системой. Семейная терапи или транзактный анализ. Пример: в семье ругались, дали предписание: нельзя ругаться в любое время, надо с 21 до 21:30, и обязательно орем друг на друга. Пару раз орать получилось, потом приходят: доктор, дайте другое предписание, не можем. Ругаться перестали.
Подходы можно варьировать, решая проблему косвенно.
* Руководитель боится ошибок, ему психика говорит "ошибаться - плохо", и он запускает гиперконтроль или пытается делать все сам.
** Можно изменить убеждения, сказать "ошибаться - нормально"
** А можно сказать: не делегировать - ошибка, делегируй.
* Боюсь обидеть - поэтому не провожу one2one. Причина может быть в детстве: мама часто показывала, как плохо, что она расстроена, это был ее способ воспитания и это - отпечаталось.
** Можно с этим разобраться, чтобы детские травмы не влияли на взрослую жизнь.
** А можно научиться давать обратную связь, где ты не обижаешься, дать альтернативную технологию.
* Тимлид вырос и стал токсичным. Почему? Он вырос в среде, где сильных гнобили слабых, и это было нормально. И когда он стал тимлидом, у него что-то перещелкнулось, сработал тот старый паттерн: я теперь сильный, значит должен гнобить. Не хочу, а должен. И он начал так делать. Шаблон надо выявить и перепрошить. Но надо понимать, что конкретно меняешь, причины могут быть различны.
* Человек много планируешь как супермен. Планы преувеличены, и они не выполняются, он это видит. но все равно планирует 10 дел, а выполняет одно-два. Почему планов много? У него убеждение: если план - всего одно дело, то он точно плохой, я не герой. А если 10 - то может получиться, есть шанс. Убеждение можно менять, но его тоже надо выявить.
Как со всем этим бороться? Осознанность. Если мы второй раз поступили неверно - это паттерн. Надо его зафиксировать, а потом с ним работать, менять то, что мы делаем.
= Екатерина Шашкова (ИнЭкс). Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки =
Это рассказ о том, как люди попробовали сделать регулярный менеджмент, основанный на регламентах, уронили этим качество, и изобрели lean для совершенствования процессов. История началась с того, что потребовалось быстро разработать некоторый продукт, и под это собрали команду специалистов из разных отделов из 5 человек, она работала не формально и эффективно, как часто бывает в небольших командах, по по мере роста появились проблемы. И когда она увеличилась до 18 человек обнаружили, что люди очень по-разному понимают, как у них устроена работа, например, одни считали, что при регрессе достаточно комплексно проверить новую фичу, а другие - что еще и остальной функционал, потому что его могли сломать. И они решили полечить это через описание процессов. Не проектировать, а просто описать что есть, потому что в целом оно работает.
Процесс описывали в линейной схеме, через этапы, для каждого - список действий, участвующие роли и критерии перехода к следующей фазе. Составлять описание начали с финала, которым у них является подписание акта, а не завершение разработки, этому предшествует выкатка на прод и выкладка доков и так далее. Идея была, что дальше процесс будут соблюдать, а там, где обнаружат проблемы - дорабатывать описание или сам процесс. В целом первый опыт был удачным, описание помолгало, его решили распространить на все команды компании. Команды не возражали, но каждая начала предлагать свою версию. А было стремление к унификации, поэтмоу ввели процесс защиты: инициатор предлагает изменения тимлиду, при успехе - надо защитить на совещании тимлидов и только тогда это распространяется на все команды, и это закономерно приводило к холиварам вокруг "правильного процесса".
Первичное опрозрачивание стоило 1-2 месяца, а дальше менеджеры еще полгода объясняли. Как это часто бывает при таком подходе, описания процессов и результатов получились большие и не работающие, разработчики в них путались. Это проявлялось в онбординге. Новичку давали простую задачу, и он вместе с куратором проходит по этапам процесса. И есть проблемы: разработчики не помнят, что скрывается за каждым пунктом, или говорят разное. И в целом это привело к падению качества, у них был период, когда каждую неделю ломали прод.
И у них пошел новый виток спирали. Они передали работу с процессом от менеджеров тем, кто их исполняет. Хотя централизация в каком-то виде сохранилась. Отказались от описания процесса как последовательности действий, перевели в критерии результата: тесты зеленые, документация выложена.
И запустили процесс регулярных обсуждений и улучшений. Это происходит на еженедельных соцещаниях. Совещания - по пятницам, 1-2 часа, всю неделю разработчики пишут пункты для обсуждения на совещании. У каждого совещания - владелец. Он, в том числе, отвечает за фиксацию результата, хотя не обязательно делает это сам. Фиксирующий шарит экран и записывает сразу.
Такая версия оказалась успешной. Мощность выросла от 3-5 до 20 в неделю. И еженедельные релизы по четвергам вместо месячных. Вовлеченность - процессы были в топе проблем в опросе, а сейчас 3.14 из 4.
Я тут хочу отметить, что хаос и неопределенность реально многих пугает, но вот стремление через детальные регламенты и процессы обеспечить предсказуемость и качество - наивно. То, что классический менеджмент по регламентам в ИТ не работает, выяснили 30 лет назад. Но, к сожалению, образование во многом транслирует иную точку зрения, и люди ходят по старым граблям.
= Руслан Карманов (IEEE Hong Kong Section). Китайские методологии IT-управления =
Руслан много лет работает в IEEE Hong Kong со стандартами связи - WiFi и Ethernet. Борется с вендорскими попытками выкрутить стандарт в свою сторону. И если кратко, то нет никаких специфических китайских методологий, китайцы заимствуют западные и японские. Но эти методологии накладываются на особенности китайского менталитета, и вот это необходимо учитывать. Эти особенности включают меритократию - власть умных, особое отношение к начальству, которого ждут и у контрагентов, способность комбинировать вместе, казалось бы, несовместимые воззрения, а также чувствительность к риску потери лица, которая ведет к ступору или разрыву взаимодействия в некоторых ситуациях. Это кратко, а теперь - подробнее.
Китай - большой, это материковый Китай плюс Сингапур плюс Гонконг, интегрированный во все западное, плюс Тайвань с идеями "почти японцы". И все массово применяются любые зарубежные модели. Японское DQM. Западные - там много фирм, которые были отделами западных фирм, особенно в Сингапуре. При этом никаких особых методологий "имени компартии" - нет. Даже в полузакрытых разработках, например, великий китайский файервол - MS Project.
Максимальная прагматичность в рамках существующих ограничений. Пупулярный на западе холивар open source - вендоры, и принятие решений по убеждениям - отсутствует. Поэтому зоопарк решений. На космодроме - Windows, Red Hat и много другого. Им безразлична любая идеология, необходимо, чтобы примеяемый подход решал задачу здесь и сейчас.
Особенность китайского менталитета - отсутствие привязки к дуализму черное-белое или добро-зло. которая есть у нас. Не или-или, а вместе, комбинация. Конфуцианство для социальной жизни, буддизм и философия даосизма уживаются в одной голове человека, который может быть еще и бизнесменом и членом компартии.
Меритократия. Конфуцианство - власть мудрых. Поэтому выберем самого умного, пусть он нами правит. Ведущий - свой по каждому вопросу. Если вы взаимодействуете с китайской командой, и ведущий с той стороны становится узким звеном и не справляется - они не поймут претензии. Они выделили лучшего. У них нет выборов и потому нет перевыборов.
Легенда о китайской дисциплине. Есть подмножество людей, которые думают, что в Китае свойственно все решать карами. Это не так. Однако, ответственность серьезно прокачано. Можно завалить работы за месяц, и получить штраф на стоимость шести месяцев работы.
Тяга к максимальному мастерству, гунфу сочетается со спокойным отношением к неудачам. И в ИТ важно достичь максимума в каком-то классе задач. Деление на две категории: есть те, кто освоил мастерство (кунфу) и кто просто делает. И отвечает и решает только тот, кто мастер.
Организационно за неудачи могут грызть, а по-человечески - спокойно "ну не смогли". Потом исправят. Те, кто играют в японцев или в западных людей так действуют, пока хорошо. Если есть проблемы - сваливаются в китайский шаблон.
Разумная меркантильность выплаты премий. Разные плюшки, не только деньги. Социалка, акции компании - объем этого может быть больше зарплаты. Еще бесплатные билеты, снимут квартиру и так далее. И выдают разную мотивацию разным людям. А премии могут быть большие, до 20 окладов за год не только у топов. Поэтому не надо ориентироваться только на уровни зарплат при каких-то взаимодействиях.
Специфика конфликтности
* Ступор при проблемах или даже намеках на них. Например, когда надо заполнить анкету и есть затруднения и девушка, которая ее дала не может ответить - она тут же кого-то зовет. Может показаться, что китайцы бесмысленно динамят, переключая стрелки. Нет, они осмысленно динамят, чтобы не ошибиться. Поэтому в контрактах прописать надо будет все и даже детальнее.
* Начальник больше чем начальник - следствие конфуцианства. В Японии начальник может пойти вместе с сотрудниками после работы. В Китае - нет, четкое разбиение на ранги. И от вас ждут того же. Если вы показываете, что "как в семье" - они увидят, что это - бардак. В Гонконге ждут, что белый человек их построит, скажут что делать, и они будут делать. Если китайца притащить в современную фирму с демократичным управлением и со слабо-формальными взаимоотношеними - у него будет взрыв мозга.
* Могут легко бросить дело в середине процесса. Если вы довели китайца до потери лица, он вас бросит. Публично показали другим китайцам, что он что-то не понимает - все, завтра закроет общение. Чтобы не повторить. Так и с командой. Если они в середине работы поймут, что не сделают во-время или провалят критерии качества - они отвалятся тут же. Если не привязать договоренностями. Устно прокатит только, если китайцы будут на позитиве и впереди будут доходы.
* Сверхтолерантность вне западного дуализма. Если у вас есть требования, чтобы подвести под сертификацию или что-то еще - пропишите. Можно обнаружить, что вместо nginx использовали какой-то форк, который непонятно как сопровождать. И библиотеки - будут тянуть китайскую кривенькую ssl просто потому, что в предыдущем проекте требовался китайский вариант.
* Сезонность. Западный Новый год, китайский, финасовый - разный. Жизнь - от китайского нового года до золотой недели октября. До этого все дела надо закрыть, остаток - это невнятный кусочек. Они подвязываются под эти даты.
* Перерегистрация юр.лиц, фирма может существовать лет 20, но перергистрируется каждый год. Даже не чтобы от налогов бегать, просто новый год принято начинать с чистого леста, и это - часть такой практики.
* В Китае запрещены азартные игры, иначе все проиграют. Макао - оборот в 10 раз больша Лас-Вегаса. Не надо стимулировать, потому что они выключают мозг и стремятся выиграть. Лотерея в конце проекта - нельзя, это запрещенка и не просто так.
* Заимствования методологий у коллег Япония-Тайвань-США - идеологически верный акт экспроприации. Грабь награбленное.
Итого
* База - на общеизвестных практиках. Нет коммунистической, нет даосской.
* Методологии - поверх своей культуры, корректируясь под нее. Чистота методологии не критична.
* Берите что работает, стремитесь к индустриальному мастерству, адаптируйте под себя.
В Японии важно что ты в одной компании. Если перешел - предатель. В Китае переходы были свободны, но сейчас эта тема тоже начинает подрастать.
У нас - напряжение, если прописываешь контракт на определенном уровне детализации: "Ты что, думаешь, что я тебя кинуть хочу, или что я совсем глупый?" У них - нет такого и надо прописывать до деталей.
Когда необходимо брать китайцев? Когда делаете мультимедиа или сайты, где оформление или сценарии для персонажей требуют учета китайской специфики.