Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 656 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru |
Последний постОчередная конференция 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Т и зачем? продолжал серию докладов на эту тему. Год назад я решил рассказать про системное мышление на AnalystDays: у аналитиков есть реальная боль по поводу приходящих джунов, многие из которых воспринимают тексты как нарратива, не умеют выделать объекты, типы, не понимают разницу между тем и другим, не умеют строить модели. И получил в отзывах, что системное мышление, конечно, мощный инструмент, но сложный, зачем его нужно знать и применять, когда есть более простые модели, типа BPMN или C4 model. И я понял, что надо не просто рассказывать про содержание, надо показывать место системного мышления в ходе проекта. Потому что авторы конкретных методов, включая ООП — знали системное мышление, и рассчитывали на его наличие у тех кто будет пользоваться. Все эти модели не предполагают применения по пошаговой инструкции или по аналогии. Доклады не повторяют друг друга, в них различается содержание и акценты в зависимости от аудитории. Тема — необъятна, в слот доклада помещается лишь часть. Мария Щекочихина из CUSTIS. Делаем происходящее с персоналом предсказуемымЭто рассказ о том, что надо технически делать, чтобы происходящее на масштабе 10 команд и 100+ человек было предсказуемым. Если кратко — то надо сценировать будущее, траектории развития сотрудников и других изменений — и ты оказываешься готов к различным вариантам развития ситуации. Для этого есть два инструмента: карта команд и работа с рисками, и еще — фидбэчница, фиксация истории взаимодействия. Но рассказ был построен не от инструментов, а от кейсов, инструменты проявлялись как средство, помогающее с этими кейсами разбираться. Потому что инструмент — универсален, как база знаний, применять его можно по-разному. Дальше — краткий конспект.
Кейсы 10-14.
Рисков — много, список будет дополняться. В презе — список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
Кейс 15-17. Те же инструменты могут использоваться для других целей.
Основа работы Performance review: есть цикличность и сроки. Раз в полгода — зависит от динамики команды.
Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория — не замкнут в команде. Для тимлида — картинка сверху, проблемные места и планы по ним. Набор инструментов — для 50+ Для 5-10 можно использовать отдельные инструменты. Важно — работа с рисками, сценарии «а что если». Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать! Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителяЭто был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору. Рассказ сопровождала большая куча историй и законов, начиная с закона Мерфи: все, что можно сделать не так — сделают, который родился, когда на эксперименте команда техников прикрутила половину датчиков неверно. Расширенный вариант таков: все, о чем можно подумать — вероятно, все вероятное — неизбежно, а когда есть варианты — случится худшее. Но Альберт — не пессимист, а реалист: если у нас половина стакана воды — надо дырку искать. То есть готовимся к рискам. Альберт — CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система. 1. Люди. Мы нанимаем, работаем, увольняем. Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма. Как парировать риски найма.
После найма — онбординг, есть семь ступенек.
Как парировать риски лестницы?
На найме — показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос. Второй закон Чизхолма: если дела идут хорошо — что-то случится в ближайшем будущем. Закон Падлера: Все, что хорошо начинается — кончается плохо, а что начинается плохо — кончается еще хуже. Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее. Увольнение начинается с найма — проактивная позиция
Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
Позволяет 90 % рисков найма и увольнения снимает. И можно в любой момент разорвать. 2. Инструменты. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди — а люди ошибаются. Проблемы с инструментами.
Инструменты — экономят время. А время — деньги. Работа, которая делается зря — muda из Канбан. Инструменты должны время сокращать, а не красть. Про инструменты.
3. Работайте с надежностью системы. Люди — связи — процессы — изменение процессов во времени. Проблема — степенная функция ненадежности. Надежность — что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность — степенная функция от надежности. Ракета Н1 — 30 двигателей с надежностью 95 % на первой ступени. Для неотработанной техники — прекрасно. Но общая надежность — 21 %, только один из 5 — успешен. Запускали 4 раза и она 4 раза взорвалась. 10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все — не высокая. Связи. Ненадежность передачи информации, испорченный телефон. Надо сокращать число элементов системы. Инструмент — выделение инкапсулированных элементов.
Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных. Из ответов на вопросы.
Право зеркального 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 — по другим, а команда — самоорганизует свою работу. Постановка целей, удержание смысла, изменение способа работы через ретро — это все коллективные действия. А что касается servant leadership, то эта концепция придумана, чтобы совместить концепт единоличного менеджера с новыми идеями о равенстве и совместной деятельности, дать смысл для менеджеров в этом мире. И, как таковая, она в значительной мере находится в мире идей, в верхней области схемы, а не материальном мире. Верхняя область. Слева — как я думаю про себя, и что думают другие, с которыми я сталкиваюсь. Рефлексия, осознанность, мотивация, ограничивающие убеждения, эмоции, мораль, ответственность, раскрытие талантов, предназначение, амбиции и цели, волевые усилия, дисциплина. А справа — технологии мышления: стратегическое проектирование, понятия и представления, ценности, схема, онтологии, смыслы, идея, этика, системное мышление, критическое мышление, helicopter view, свобода. Теперь посмотрим применение канваса на кейсах. Мотивация много работать. Можно ее проводить индивидуально, с человеком, опираясь на его собственные желания. Это прямой путь слева из верхнего квадрата в нижний. Александр Залезник говорит, что лидер — тот, кто умеет преобразовывать чувства и желания других в мотивацию. Но можно идти косвенно, через правые квадраты, создание среды. Концепт: чтобы человек много работал, он должен много потреблять — и ему придется работать, чтобы обеспечить потребление. Реализация концепт дает современное общество потребления, где каждый много потребляет, и где каждое продвижение человека должно сопровождаться ростом этого потребления, чтобы он не стал работать меньше. Концепт прорабатывали Уайтхед, Шумпетер, Кейнс, Кондратьев, сделали это 100 лет назад. Я тут сильно сомневаюсь: Шумпетер, Контратьев и Кейнс работали над экономическими моделями, а не над идеологическим концептом общества потребления. И это — существенно разное. Путь в новое.
Но есть проблема, связанная с фрагментацией, целостно понимать все квадраты канваса — тяжело, часто не хватает каких-то элементов и шансов довести изменения до успеха — мало. Фрагментация возникает потому, что в каждом квадрате работает свой набор инструментов.
Каждый из инструментов — в руках специалистов. Поэтому и не связано в целую картину. Очень мало мастеров, которые бывали в разных местах. Если вы как начинающий предприниматель выбираете коуча, надо чтобы у него был свой бизнес и он не боялся вас потерять как клиента. Самое большое количество инструментов — регулярный менеджмент, практические навыковые вещи. Все все слышали. Но не применяют. Самое дорогое — стратегическое проектирование. И сложное. И дальше был разбор инструментов по квадратам. Что интересно, не только с точки зрения результатов, но и с точки зрения засад, которые препятствуют успеху. Главные засады связаны с эмоциями, здесь Александр опирается на модель Марвина Минский «Машина эмоций», которые рассматривал эмоции как некоторый переключатель режима для логики мышления. Итак, левый нижний квадрант, обучение и подготовка, навыковые тренинги и менторинг. Преимущественно обучает действовать по регламентам и правилам. Важно: если вы хотите обучиться чему-то, например, стать мастером или руководителем, то надо находиться рефлексивно не только по поводу своей моей деятельности, и по поводу деятельности того, кем хотите стать. Джон Дюи говорил «Мы учимся не из опыта, а из рефлексии своего опыта». А на массовом обучении рефлексию некому проводить. Поэтому появляется вместо конструктивной рефлексии появляется грусть и сожаление: надо было делать НЕ так. Пока нас накрывает грусть — обучиться невозможно. Поэтому тренеры борются с грустью, обучающие мероприятия превращаются в развлекательные, дают положительные эмоции, а вот результат такого образования — так себе. Я тут хочу сказать, что от грусти и сожаления есть лекарство — протокол авторизации результата. Только не в позитивной форме, о которой кратко говорила Анна Обухова в своем выступлении, а в негативной, о которой она говорила в других. Почитать можно в моей статье Механизмы драйва и мотивации. Левый верхний квадрант — личностный трек. Предпосылки: тоска на текущей роли, бесят другие, будущее не радует. Инструмент — коуч, другой об которого думать. Но мешает эгоцентризм — неумение учитывать и признавать разные точки зрения. Это когнитивное искажение, когда люди вообще не могут представить другую точку зрения. Здесь Александр ссылается на Пиаже. А еще мешает страх потери лица и потери статуса эксперта. И в результате коуч становится тем, кто просто принимает жалобы, а не коммуницирует критически. Кстати, этика коуча «нет обучения без запроса» этому способствует: коуч видит, что реального запроса на изменения нет и устраняется или превращается в утешителя. Тем более, если он работает в компании, и работодатели поставили задачу удержание сотрудника: реальный рост часто приводит к тому, что сотрудник уходит в другую компанию, где перспектив больше. Правый нижний квадрат — Бизнес-образование, способы реализации предпринимательского замысла, стратегий, инициатив, внедрение лучших практик, управление изменениями. Цель — соответствие операционной деятельности целям и замыслам. Здесь конкретные фреймворки OKR, SWOT, Lean и так далее. За рамками — мотивация участников к изменениям. Тут цитата из Кейнса: «Когда меняются факты. я меняю свою точку зрения. А вы?» И засада тут связана с недовольством, вызывающим гнев: руководители недовольны исполнителями, не умеют воспринимать обратную связь, а исполнители недовольны руководством. которое, к тому же, позвало консультанта, который «вообще не в теме», и сопротивляются изменениям. Консультант меж двух огней фокусируется на генерации идей, а не на их исполнении. или пытается провести изменения в собственных интересах, чтобы стать партнером. Замечу, что очень часто говорят про страх изменений, это устойчивое выражение. А Александр эти части изменил: страх связан с квадратом личностного роста и связан с возможной потерей лица, а с изменениями организации связан гнев. Может быть, такое разделение оправдано, а может быть надо разбираться детальнее, говорить о многомерном пространстве, а не укладывать все в 4 квадрата. И правый верхний квадрат — технологии мышления. Создание нового, изобретательство, предпринимательство, выработка стратегий. И тут важно не оторваться от реальности операционной деятельности, а она за рамками рассмотрения. Для широкого мышления важно не ограничиваться бизнесом, важно искусство, музыка. гуманитарные дисциплины: Пак Сонг Чжу из Южной Кореи полагает, что это надо преподавать в бизнес-школах, чтобы обеспечить широту мышления. А ограничением является отвращение к чужому мнению. Мы не любим, когда есть кто-то другой, который думает по-другому — идет борьба. Целостная сборка для траектории развития.
Цитата из Сартра: «Человек, совершивший самоопределение — не только тот, быть которым он избрал, а еще законодатель, одновременно с самим собой избирающий человечество». Я рекомендую попробовать декодировать эту фразу самостоятельно. У меня получилось следующее: когда ты самоопределился, ты тем самым поменял весь мир. ибо смотришь на него по-другому. А что получится у вас? Анна Обухова (annaobukhova.ru). Как сделать так, чтобы команда наконец признала тебя лидомРассказ о нейрофизиологических механизмах, которые лежат в основе признания лидером, то есть человеком, за которым стоит идти: прислушиваться к словам, поддерживать идеи, выполнять поручения и так далее. Общие нейрофизиологические механимы унаследованы человеком от приматов. И один из этих механизмов — определение лидера. Они действуют, и потому их надо учитывать. В докладе было 6 кейсов — вопросов, по которым вы могли увидеть разницу мышления лидера и не-лидера и оценить себя. Есть эксперимент. Обезьянка. Научили доставать бананы из ящика и вернули в стаю. Учится ли стая? Зависит от статуса. Учатся только у высокоранговых. А низкоранговую гоняют как источник бананов. Приматы обучаются только у тех, кто стоит выше по лестнице. Опыт нижних игнорируется или их используют для поручений. Как устроены эти механизмы? Есть два центра, которые вносят сильный вклад в регулирование наше поведение. Первый — миндалина — центр сильных эмоций. Она же оценивает социальные связи и там расположены зеркальные нейроны. Миндалина повреждается стрессом, стрессоустойчивость — часть лидера. Зеракальные нейроны. Мозг считывает состояние другого человека в коммуникации и интерпретирует — скука, интерес и так далее. Когда мы считываем влиятельного — меняется наше поведение. н видит это изменение — и идет реакция. Второй центр — Хабенула. Проверяет, если вероятность — не 100 %, то: ты ходил, там может быть больно, ты облажаешься — тебя съедят. Хабенула боится, когда есть социальный элемент: я предложу, они не поддержат. Нам надо преодолевать, и насколько эффективно делаешь — тем больше лидер. Я тут хочу сделать важное замечание. Миндалина и Хабенула не реализуют встроенных алгоритмов, их нейроны тоже обучаются. Механизмы обучения, к которым в ходе эволюции природа перешла на млекопитающих от инстинктов и рефлексов, требуют, чтобы ребенок следовал за взрослым — на этом построено обучение. И ребенок должен определять: за кем следовать, и этому он тоже обучается: есть следование за родителями, а вот следовать ли за другими детьми, своего или старшего возраста, или другими взрослыми — он определяет самостоятельно, и есть возрастные динамики, связанные с тренировкой этого механизма. Включая переходный возраст, подростковый период 12-14 лет, когда закладываются убеждения. На этом эффекте, кстати, построена теория поколений, Анна говорила об этом в одном из предыдущих выступлений: подростки выбирают своих кумиров в этом возрасте, влияние родителей не велико, и потому следующее поколение отличается от предыдущего. Но дальше конкретную теорию построили на анализе однородной социальной группы американских менеджеров и произвольно распространили на всех, поэтому теория реально плохо применима. А если брать сильно дифференцированные общества в эпоху революций и общественного переустройства, как было в России в 90-е и 2000-е, то поколение получается неоднородным. Итак, ребенок тренирует нейронную сеть, у кого стоит учиться, у кого — нет. А еще — кому надо подчиняться, а кому — нет. И это — разные вещи, которые исследователи часто произвольно объединяют в слово «статус». Это легко видно по школам: дети к разным учителям относятся сильно по-разному, и с точки зрения авторитета, и по подчинению, и между ними и учителями выстраивается сложная система, не сводимая к одному измерению статусом. Государство предпринимает специальные меры для поддержания формальной системы статусов, которая ему выгодна, к тому, чтобы все одинаково оценивали героев литературы и фильмов и так далее. Сила влияния этого процесса зависит от силы конкретного государства. И этот социальный процесс, если мы ведем исследования механизмов нейрофизиологии, надо отделять. То есть смотреть проявления на разных социальных группах и в разных обществах и культурах. А в тех кейсах, которые далее приводила Анна, это не разделено, они относятся к конкретной американской культуре, да еще, я предполагаю, к относительно узкой группе американских менеджеров. Для которых статусы — линейны, и они на все смотрят именно таким образом. Поэтому, когда они смотрят на традицию восточных монахов, то они видят, что там монахи меряются скромностью, как менеджеры меряются айфонами и ролексами. Это было в ответах Анны, и, думаю, почерпнуто из исследований. А жизнь — богаче, и для понимания, что в нас из нейрофизиологии, а что — определено социумом, надо разделять. Только тогда можно делать перенос прикладных результатов между культурами. Возвращаюсь к докладу. Итак, кейсы. В каждом — несколько формулировок для самооценки и баллы лидерства. Это записано пунктиром, презентации скоро опубликуют, детали лучше смотреть там. Кейс-1. Вертолет упал в тайге, все выжили — какое первое действие? Для баллов его надо классифицировать на 3 категории.
Кейс-2. Ты хочешь предложить идею команде. Что повлияет: предыдущий проект; ты выспался; с утра сделал несколько успешных дел. Ответ: это все работает на статус, но больше всего — то что произошло в предыдущие 6 часов. Если проект не вспоминали за это время — он забыт. Теплая рука в баскетболе. Есть эксперимент с мышкой. У них статус — через драки, и они тоже оценивают вероятности. Если мышку подсадить к сильной альфе — она забьется в угол. Но можно предварительно посадить к слабым, она полезет драться, и если это повторить 6 раз, чтобы были победы, а потом подсадить к альфе — будут победы. Кстати, я думаю, что этот эксперимент ясно показывает: обезьянку из первого эксперимента могли научить не только открывать хитрый ящик, но и способу изменить свой статус через это преимущество, провести тренинг личностного роста. Но — не сделали. Авторизация результата. Это методе получения уверенности, был как краткое упражнение. Анна много раз рассказывала о нем, потому что он прост и эффективен. У меня есть описание, собранное по ее докладам Механизмы драйва и мотивации. А сам метод из 4 пунктов.
Кейс 3. Вы — лидер. появился человек или группа, которые оспаривают статус. Что поможет удержать?
Правильный ответ зависит от ситуации в команде. В хорошей ситуации надо дружить с девочками, когда все хорошо — девочки в обиду не дадут. А вот если в команде не очень хорошо, есть проблемы, то надо опираться на соратника. Потому что две обезьяны всегда забьют одну, на уровне нейрофизиологии восприятие такое. А вот вариант подружиться с тем, кто оспаривает — безопасно и соответствует представлениям о мире и сотрудничестве, но статус — роняет. Кейс-4. Хорошо поработали, продукт успешен, делим прибыль.
Скромность — не про власть. Больше любят, привлекает как к человеку но не характеризуют как лидера. У меня все есть — только когда однозначно считывается. На мой взгляд, этот кейс наиболее подвержен влиянию той культуры, на которой проводили исследования. Известный американский афоризм «победитель получает все» — он из этой культуры, и там такой способ представляется справедливым. А вот в японской и китайской культуре более распространена концепция справедливой доли, и от лидера ждут такого поведения. В России — по всякому, потому как нынешнее общество сильно неоднородно по своим идеалам, в компаниях и командах разные идеалы смешиваются. Хотя какая-то часть уже осознает необходимость культурного выравнивания, и на входе проверяет соответствие. А справедливое деление вознаграждения — одна из существенных составляющих. Только не надо забывать, что в корпоративном мире распространено двеомыслие, разрыв между декларациями и фактическим положением дел. Рыбки-гальяны, которые послужили формой крекеров, плывут стаями, одна куда все остальные. В стае не интересно, но не страшно. И находится рыбка, которой интересно и не страшно — и отплывает. Но вдруг понимает: «я одна, меня съедят» — и возвращается в стаю. Но находятся сумасшедшие, которые не возвращаются — и стая разделяется. Впрочем, на мой взгляд, это антропоморфизация, потому что у рыб нет эмоций, у них поведение управляется рефлексами и инстинктами, а эмоции появляются у млекопитающих. У человека любопытство и отсутствие страха соответствует ситуации, когда много дофамина и мало кортизола, это видно по миндалине и хабенуле. Как это проявляется в поведении? Более спокоен, не боится неопределенности будущего, берет ответственность, есть план и уверенность в нем. Лидер видит дальше и может защитить. И это — иллюзия: раз сделал для себя — надеемся, что для нас тоже сделает. Отмечу, это сильно зависит от культуры. В культуре силы, которая хорошо описана в легендах и мифах Древней Греции герою часто наплевать на спутников, он совершает подвиг. В более рациональных культурах сотрудники — ценный ресурс для достижения цели, и о нем надо заботиться. Но встречается отношение как к расходуемому ресурсу: люди — что дрова, от дождя укрыл, но когда потребовалось — кинул в костер. Заранее, конечно, об этом не говорят. А есть те, кто реально относится к сотрудникам как к партнерам, а не как к материалу. И хорошо бы это представлять. Кейс-5. Как часто вы разговариваете про дальние перспективы?
Смысл и цели деятельности важны, без него мозгу неприятно, возникает неопределенность. А без разговора люди не поймут. И чем важнее держать его в фокусе, тем чаще надо говорить, потому что активация нейронов держится примерно 6 часов, именно такое время смысл будет в активном контексте и будет влиять на принимаемые решения «по умолчанию», не требуя специального вспоминания. Мышление. Для простых проблем достаточно внимания, фокусированного на реализации будущего. Для сложных нужно сложное мышление, выявление трендов, формулирование будущего, учет взаимных связей. Тут есть эффективный инструмент — факт карты бизнеса Курпатова. Кейс-6. Воспринимают ли тебя как защитника на уровне нейрофизиологии, определяется ответом на вопрос о твоем стрессе:
Опух — это объективная реакция на стресс, в нем почки работают по-другому. А еще — блестящие волосы или лысина, холеность. Брюнетам повезло, более гладкие. Кудрявых блондинок — любят, но лидерами не считают. Вождей отличают статусные аксессуары — можно потратить ресурсы на всякую хрень. У каждой социальной среды аксессуары свои. А еще суровый, а не любезный взгляд, недовольство окружающими. Впрочем, тут тоже проявляется влияние социальной среды при воспитании: если родители с придыханием смотрели на какие-то аксессуары как признаки сильного человека, то дети тоже будут их искать, хотя набор статусных аксессуаров он может и сменить. А вот если родителям было реально, и они это явно транслировали, что так поступают лишь глупые гламурные особи, у которых других достоинств нет, и ржали над этим, то детям тоже будет безразлично. В России таких не мало, это наследство советского периода, хотя там тоже отношение к аксессуарам было разным. А вот американское общество — очень статусное, и даже при игре в хиппи важно купить прикид в правильном и дорогом магазине. Отсюда продвижение брендовых рваных джинсов, а пару лет — и рваных коготок от 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
Это сложно. Но мощно прокачивает. Проектировать обучение доклад надо с конца. Что надо сказать, чтобы человек так изменился. Они на основе опыта сделали фреймворк на 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 — смотрят метрику рассеивания данных. Графики — способ искать аномалии: отличия разных команд, влияние увольнений. А сроки — дают лиды. Я хочу отметить, что про сходимость модели не взирая на неточные оценки — это верно. Потмоу что есть засада: ошибки оценки статистически компенсируются только при нормальном распределении, а для задач в ИТ статистика показывает распределение с длинным хвостом: пуассоново или логнормальное. Об этом есть хороший доклад Андрея Бибичева «Пуассоново горение сроков». И чтобы попасть с оценкой в два сигма, оценка должна быть втрое выше матожидания, двухкратный резерв. А точно оценить можно, лишь наполовину сделав задачу. Это — объективно и да, фин.модель должна сходиться даже с учетом такой объективной неопределенности, как совладелец компании я это тоже хорошо понимаю. Как это делать — отдельная тема. Часть этой задачи можно возлагать на руководителей проектов или тимлидов, но если бы они были готовы полностью принять такую ответственность — у них бы были свои компании. А если просто жестко давить — они будут завышать оценки тем или иным образом. Евгений Идзиковский (Частная практика). Legacy-код в психике — как расплатиться со своим техдолгомЕсли рассматривать мозг как большой софт, то в нем много legacy-кода, который возник ситуативно. Это — хорошая аналогия, с той разницей, что код софта писали программисты, а код мозга был порожден в ходе обучения. Но в обоих случаях когда-то была приемлема решена какая-то локальная задача, а потом этот фрагмент сохранился. Этот механизм свойственен не только человеку, так же работает мозг кошки или собаки, которые вообще не мыслят, однако решают довольно сложные задачи обеспечения питанием, поиска партнера для размножения, социальных взаимодействий. А рефакторинг не предусмотрен, если только механизм не начал давать серьезные сбои. В дикой природе животным некогда заниматься рефакторингом, надо выживать. А вот человек — он рефлексивен по отношению к своему поведению, и часто хочет изменить каки-то действия своего обученного автопилота, не доводя последствия до серьезных сбоев или просто узнав, что существуют другие, более эффективные способы действия. Провести рефакторинг. Именно этим занимаются психологи, и для этого наработано много методов терапии. При этом, однако, исследования показывают, что эффективность каждой конкретной — 25 %. Но вот если действовать интегративно, применять их в комплексе с учетом конкретного человека и задачи, то коррекция возможна, при чем достаточно быстро, за 1-2-3 месяца. А если вы ходите два года и проблема не решается, значит к вам применяют неверные методы, учитывайте это при выборе специалиста. Дальше в докладе был обзор методов психотерапии на понятном разработчикам языке работы с легаси. Это было устно, и я записывал в телеграфном стиле. Но на своем канале @idzikovsky_psy Евгений обещал в ближайшее время выложить подробную презентацию, где раскрыть содержание. Он — профи и знает много методов, чаще использует гипнотерапию, осознанность и НЛП совместно, дополняя другими по необходимости. Итак, психотерапия как работа с legacy-кодом. Для начала — архитектурная схема: есть входной сигнал, два канала обработки — эмоции и мысли, которые между собой взаимодействуют, и выход — поведение. И там возможны ошибки двух типов.
Формирование ошибочных шаблонов может идти тремя разными способами.
Что можно сделать для рефекторинга сознания?
Подходы можно варьировать, решая проблему косвенно.
Как со всем этим бороться? Осознанность. Если мы второй раз поступили неверно — это паттерн. Надо его зафиксировать, а потом с ним работать, менять то, что мы делаем. Екатерина Шашкова (ИнЭкс). Как мы перестали говорить «у нас так принято» и стали описывать процесс разработкиЭто рассказ о том, как люди попробовали сделать регулярный менеджмент, основанный на регламентах, уронили этим качество, и изобрели 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 окладов за год не только у топов. Поэтому не надо ориентироваться только на уровни зарплат при каких-то взаимодействиях. Специфика конфликтности
Итого
В Японии важно что ты в одной компании. Если перешел — предатель. В Китае переходы были свободны, но сейчас эта тема тоже начинает подрастать. У нас — напряжение, если прописываешь контракт на определенном уровне детализации: «Ты что, думаешь, что я тебя кинуть хочу, или что я совсем глупый?» У них — нет такого и надо прописывать до деталей. Когда необходимо брать китайцев? Когда делаете мультимедиа или сайты, где оформление или сценарии для персонажей требуют учета китайской специфики. |
Блоги друзей |
