2021-12-19: сентябрьская Saint Teamlead - хороший контент и много общения

Короткая ссылка: TeamLeadConf-2021-Spb

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

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

Сентябрьская Saint Teamlead в Питере, как обычно, была замечательной. Хорошие доклады и много общения. Из интересного для меня - тема социократии. Это набор шаблонов для построения самоуправляемой организации. И, в отличие от многих других систем авторы не настаивают на использовании ее целиком. Наоборот, они говорят: "В любой организации есть проблемы. Вы можете попробовать отдельные шаблоны социократии для их решения, и если они помогут - применяйте их дальше". Про социократию был мой доклад, Дмитрий Зацепин, которому я осенью 2020 года рассказал про конференцию, рассказывал про практический опыт перехода на социократию в компании Oil energy. С этого я и начну свой отчет, а потом перейду к другим докладам, уже в том порядке, в котором их слушал на конференции и публиковал заметки в facebook. Но я хочу отдельно отметить доклад Филиппа Дельгядо - там много интересного.

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

Мой доклад: Социократия - хороший источник практик по организации IT-проектов

Как обычно, мой собственный доклад Социократия - хороший источник практик по организации IT-проектов остается без конспекта. Смотрите презентацию и видео.

Здесь лишь отмечу, что социократия была придумана в 19 веке Огюстом Контом, имплементирована в начале 20, потом в 1970-х перенесена для управления коммерческими компаниями в Голландии и получилась версия 2.0, а версия 3.0 пересобрана недавно с использованием новейших достижений - agile, холакратия, практики бирюзовых организаций. Поэтому когда открываешь список шаблонов, то половина - знакомые по agile-методам. А вот другая половина - из других источников и очень интересна.

И интересна очень интересна общая конструкция деятельности.

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

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

фото с доклада.

О докладе был пост Андрея Крылова: Потрясающий доклад про социократию от Максима Цепкова. В комментариях к моему репосту было обсуждение.

Константин Федоров. Ура! Очень интересно, ждем презентацию и видео! Подбиваю российское сообщество социократов самоорганизоваться на opensource разработку библиотеки паттернов, если сподобимся на это, изменим мир лет за 20 )) У гум/соцтеха с опенсорсом вообще беда-беда - отдельная большая тема, этот барьер почему то мало обсуждают. Признак слабого иммунитета цивилизации, я считаю.

Максим Цепков. Константин Федоров. Презентация уже на сайте. Видео - поделюсь. Паттерны - есть, в руководстве описаны. Половина - нам знакомы из по agile-методам, а другая половина - оригинальные и интересные.

Сергей Вакуленко. Со слайдов вовсе не очевидно, что это всё имеет отношение к программированию.

Александр Здрок. Serge Vakulenko, а оно точно имеет отношение не только к программированию ??

Сергей Вакуленко. Почти как моральный кодекс строителя коммунизма. Был такой 60 лет назад.

Дмитрий Калашников. Сергей Вакуленко а к программированию людей?

Максим Цепков. Сергей Вакуленко Это имеет отношение к организации ведения разработки. Там половина шаблонов - знакомые по agile-методам (бэклог, встречи и т.п.), а вторая половина - из других источников, интересные. И общая модель очень похожа на развитие продуктов через проверку гипотез. Когда agile-методы придумывали, продуктовой разработки с быстрым циклом было не так много, так что даже в том, как они переформулируют знакомое - есть определенная ценность. Что мне там нравится - все весьма прагматично, и потому на кодекс строителя коммунизма не похоже, хотя принципы так или иначе туда выведут. Не "жить надо честно", а "жить надо прозрачно", а дальше общество само решит - дать тебе в морду за такую жизнь, или нет.

Сергей Вакуленко. Дмитрий Калашников Программирование людей звучит пугающе.

Сергей Вакуленко. Maxim Tsepkov Да я как бы тоже в этом бизнесе, в разработке. Всё время поглядываю на твои посты в надежде надыбать полезное для себя и своей команды. Пока не надыбал.

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

Сергей Вакуленко. Maxim Tsepkov Я инженер, но не в этом суть. Я по жизни имел честь участвовать в разных проектах: больших и маленьких, успешных и неуспешных. Когда два-три человека делают замечательную разработку - это не удивительно, наблюдал много раз. Но когда попал в проект из 120 разработчиков (это был MIPS) - было удивительно, как они умудряются координировать процесс, причём не снижая темпа. Позже наблюдал противоположный случай, когда команда из 200 человек взяла на вооружение модный принцип OKR (ты его упоминал как-то), а через два года, проев $100млн инвестиций, разорилась и распалась. Мой вывод, упрощённо: универсального рецепта нет. Всё зависит от сыгранности ключевых людей в команде.

Дмитрий Зацепин. От людей всегда всё зависит. S3 помогает людям создавать сыгранные, гибкие и устойчивые к испытаниям команды.

Константин Федоров. Холакратия и социократия - набор скриптов и паттернов децентрализованного самоуправления. Кейсы из российской практики вот можно посмотреть в этом журнале (это журнал сообщества "Бизнес со смыслом", там много номеров, дотупны для скачивания).Также рекомендую книжечку Гуманократия, Хэмел. Всех интересующихся приглашаю в чаты телеграм по социократии и холакратии (так и называются), там живые сообщества, подскажут, помогут.

Алексей Шиндин. Maxim Tsepkov, насколько такая система функциональна и адекватна при наличии внешних угроз как значимых стимулов и анти-стимулов? Потому что IT-среда во многом существует в некоторых таких комфортных условиях, бычьем тренде на рост популярности ее услуг и доходов ее участников, и т.д. Если же мы берем ситуацию ВЫЗОВА (не только со знаком плюс, что минимальная планка - это не 0, а можно глубоко улететь в минус, плоть до полного исчезновения), то будет ли работать такая организация пространства и при каких условиях?

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

• Можно сослаться на исследования Белбина, который выделил два типа руководства: Координатор, дающий проявиться всем в команде и Шейпер, который ведет за собой. И проводил статистические сравнения. Результат - нет преимуществ одного стиля. Но при Шейпере команда проигрываете из-за ошибок лидерства, а при Координаторе - из-за менее быстрой реакции на изменения. То есть коллективный разум в сложных ситуациях выбирает путь лучше, но медленнее.
• А еще можно сослаться на Токвиля "Демократия в Америке" (середина 19 века), который писал, что государства с демократическим устройством не раз возникали в Европе, но их кушали сильные авторитарные соседи, а США выжило потому, что от них отделяли океаны.
• Но! Важно что социократия, в том числе, предполагает возможность временного возврата к единоличному лидерству, если такой лидер есть: он пишет соответствующий драйвер (кризис), предлагает инициативу, и дальше должны найтись аргументы, что такое решение принесет конкретный вред.

Алексей Шиндин. Maxim Tsepkov, ну да, я про это и подумал, про "кушали". А то IT-среда, как по мне сейчас, это "отдельно за океаном" и борются между собой только. Внешняя среда для этого сектора на подъеме, все для него. И ощущение складывается такое, что будет как со многими другими сферами, которые были перенасыщены в свое время людьми и инвестициями, что будут откаты и отказ от розовых облаков, встреча "с реальностью". Хотя тут цикл длится и длится пока еще...

Дмитрий Зацепин. Всем кому интересна S3 в практике, приглашаю приехать и изучить самим. http://www.visit.onrg.ru Обещаю, что интересно будет абсолютно всем.

Дмитрий Зацепин из Ойл Энерджи. Результаты трех лет тотального самоуправления на химическом производстве

Пост на FB Дмитрий Зацепин из Ойл Энерджи. Результаты трех лет тотального самоуправления на химическом производстве. Сегодня утром я рассказывал модель Социократии. А Дима рассказывал практику - устройство самоуправления в компании Oil Energy, а так же историю, которая привела его и компанию к самоуправлению и к передаче компанию в собственность своим сотрудникам. Вернее, не сотрудникам, как физическим лицам, а профсоюзу, в который входят все сотрудники - тут есть тонкость.

Замечу, что я рассказал Диме про конференцию осенью 2020 года на экскурсии в компанию (мои впечатления OilEnergy-1 и OilEnergy-2). Конференция дДиме понравилась, он слушал доклады, осваивал контекст и проблематику ИТ. И обещал на следующие конференции приехать не только сам, но и сагитировать других сотрудников - говорит, име сть что ценного рассказать по этим проблемам. А если тема интересна, то есть доклады Димы о компании на других конференциях, записи выложены, ищите на youtube и смотрите.

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

Сама компания - химическое производство для нефтянки, оборот с 2016 более 1 млрд (в 2017 был кризис, было несколько меньше).

Далее Дима перешел к истории. Личные драйверы создания компании:

• Купить хорошую задачу в Москве
• Делать лучше, чем другие в отрасли
• Создать место работы, откуда бы не увольнялись такие как я

Первые два выполнены, и компания - реальный лидер в России в своем сегменте, с выходом на международный рынок.

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

Компания не всегда была на самоуправлении. Основана в 2010 (или 2012, не помню). Сначала она была маленькая, был драйв и энергия, все были вместе и хотя формально самоуправления не было, по факту его было много, как во многих стартапах. Потом она росла, и по выручке и по количеству народа и в какой-то момент Дима начал строить пирамидку менеджеров.

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

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

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

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

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

Социократия основана на принципах.

Прозрачность. Записывайте всю информацию. Тут характерный диалог:

• Давайте по максимуму открывать
• А вдруг попадет конкурентам...
• И что?
• А вдруг они сделают что-то плохое?
• А что плохое?
• Мы не знаем...
• Тогда давайте открывать.

В результате все открыто. Дима перечислял 3 закрытые вещи (химические формулы, ключевые поставщики и что-то еще).

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

Равноценность: привлекайте к участию к решений тех, кто влияет.

• Часто топ имеет идеи, и говорит "делайте так". И спускается решение. А они видят фигню.
• А так - идут возражения, объяснения зачем. И люди понимают смысл. И мотивируются.

Ответственность. Не за кусочек, а за движение команды и потом - организации.

• Контрпример: В одной компании (в докладе была названа) юристы так позаботились о безопасности, что уже 3 месяца никто не может заключить ни одного контракта.

Эмпиризм, Постоянное развитие - в ИТ понятно.

Результативность - только то, что приближает к цели.

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

Супер-патерны социократии. Mindset

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

Цифры.

• В 2017 - еще строим пирамидку. Людей все больше и убыток.
• В 2018 начинаем строить самоуправление. Выручка выросла, а число людей и ФОТ снижается
• В 2020 выручка еще больше, людей и ФОТ меньше. При этом ушли высокооплачиваемые топы и часть мидлов - зарплату увеличились.
• В 2021 году: выручка чуть меньше, а прибыль - сильно больше. Ушли низкорентабельные.

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

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

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

Oleg Klimenko. Максим Цепков - а что за аудит они проводят? Для кого?

Максим Цепков. Oleg Klimenko К ним приходят из всяких налоговых и других регуляторов и проверяют. В последнее время - несколько раз, они участвуют в каких-то госконтрактах или госпрограммах, там какая-то аккредитация еще. В докладе Дима подробно не рассказывал, я по разговорам во время экскурсии помню, он рассказывал, что налоговая доначислила налоги по каким-то сделкам 3-5 летней давности со словами "ваши недобросовестные партнеры не исчезли, наверное, вы им тоже не платили, не было этих расходов", они отбивались. У них схема самоуправления с кругами и распределение прибыли закреплено нормативно и проводится в белую, для налоговой это не привычно. А они работают в нескольких регионах и у них - несколько ЮЛ, бизнесы выделены.

Динамика увольнений.

• 2016-2017 уволилось 6
• В 2018 - ушло 24, и это он увольнял сам
• В 2019 - увольнялись сами и увольняли команды
• В 2020 - 20, команды учились онбордить, ошибались
• В 2021 был прогноз 10, сейчас - 7.

Переход на самоуправление в целом стоил полкоманды, 44 человека.

Настоящее.

• Прошли 3 внешних проверки
• Научились делить дивиденты в кругах
• Закрыли направление с 0.5 млрд выручки
• Запущены 5 новых направлений вне нефтянки - пластик и другое
• Система самоуправления уникальна
• Компания стала больше, чем основатель

Вопрос про найм. Он сам последнего нанял в 2018. До этого нанимал на других ценностях. Часть покинуло. Другие - трансформировались. Либо они были зажаты и просто проявилось. Хотя проявилось разное. Когда нанимают команды - они чувствуют ценности человека. Хотя этому надо научить. Нельзя прокачать компанию, можно прокачать людей.

До конца года он перестанет быть владельцем. Зарегистрировали некоммерческий профсоюз, куда вошли все сотрудники. Почему? Потому что профсоюз не сможет продать и не сможет выводить прибыль. Они думали, что Дима подарит 90% компании профсоюзу, но оказался риск - могут попросить налоги за получение подарка, при чем в будущем, задним числом. Поэтому он продаст компанию профсоюзу с рассрочкой на 30 лет, это не обремерительно для компании.

Вопрос после доклада: а когда вы переходили на самоуправление - как вы относитесь к тому, что сотрудники что-то делают не так?

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

Потом было еще много вопросов и ответов в цифровых кулуарах, но я уже не конспектировал.

Екатерина Пуданова из Wrike. Как управлять креативной командой и выжить, если ты принцесса

Пост на FB Первый доклад #SaintTeamLeadConf2021 Екатерина Пуданова из Wrike. Как управлять креативной командой и выжить, если ты принцесса. Это не IT, а дизайнеры, которые делают самый разный дизайн - презентации, офисы, футболки. В докладе - рефлексия собственного пути и его фейлов. У Екатерины всегда получалось хорошо организовывать людей, с детского сада. В 2014 она пришла в ИТ, в 2015 стала тимлидом со словами "сама найми себе команду". Она наняла, трех человек, они работали и по результатам - неплохо, получали награды. А потом в 2018 Екатерина впервые ушла в отпуск - а по возвращении узнала, что вся команда решила уволиться "мы не хотим видеть тебя и твою работу". Шок. Она же очень старалась, прошла все тренинги, и результаты были хорошими. Уволилась сама вслед за командой. И решила, что никогда не буду работать с людьми, дауншифт в Москву на меньшие деньги, время осмысления. Оно не прошло впустую, и когда в 2019 ей Wrike предложил вернуться в IT, то она решила попробовать. И теперь с учетом уроков - ведт себя иначе. О чем и рассказывала.

Ошибок - много.

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

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

Основной урок: задача тимлида не тащить все самому, с жестким пушингом других, а создавать экосистему, где все члены команды могут проявиться. Фокусы: Люди, Результат, Ты.

Люди. Общаться качественно. Это - сложно. Общаться качественно не только с командой, а со всеми. С мамой.

Плохо общались - поставила one2one для каждого по часу. Встречи никому не нравились, откладывались и сокращались. То есть было много времени (у нее - 720 минут на трех человек), и мало пользы.

Сейчас 15 минут с каждым (7 человек), но быстренько и концентрировано. Для ребят, и когда встретиться - они решают. 420 минут на всех. Но знает гораздо лучше что происходит в команде. В том числе потому, что встречи распределены по неделе, а не сконцентрированы в одном дне. Делать "день общения" - распространенная ошибка.

То что one2one сейчас хороший - есть данные, они сравнивали по опроснику разные встречи в команде, и one2one оценен хорошо.

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

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

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

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

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

По результатам - индексы эффективности: Stakeholder, Production, Designer. Определяют опросом, вопросы на слайде были. Придумывала не она, в команде оказался человек, которого драйвит задача. В целом у них результаты хорошие, но индексы дают провалы, и можно в этом направлении работать. Были примеры.

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

Еще приемчики про результат.

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

Устал - Отдохни.

• Когда она начинала работать в ИТ - ей нравилось, она работала до 3 ночи, у нее не было личной жизни (потому что окна в 40 минут, потом у меня звонок - ты тут подожди...). Первый отпуск через 3 года - и тогда все ушли. Теперь - учится отдыхать. Вроде получается.
• Найдите с кем поговорить. Думала, что не должна просить помощи, справляться сама. Она доверяет маме, но мама не понимает что она делает. Во wrike она нашла HR, который помогал. И ее менеджер - тоже. Это нужно, чтобы не сдаться/сломаться.
• Ищите таланты в команде. Была узким горлом в команде, которая распределяла команды. Сейчас у них настройка потоков по типам задач на разных людей, которые дальше маршрутизируют. Эксперимент этого года, и большую часть они не видели на входе.
• Если у вас много контактов в zoom - то сделайте одну ссылку, виртуальную приемную - и всех будут приходить, можно не следить за временем.

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

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

Филипп Дельгядо. Ваши процессы попахивают. Как это понять и что делать?

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

Запах "Нерадивые сотрудники". Есть кто-то. кто не пишет комментарии, коммитит в мастер, опаздывает на 2-3 минуты на любую встречу, или приходят на собеседование не те. Часто проблема не в сотруднике, а в процессах - что-то не удобно. Или проблема в онбординге.

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

Запах "Лишний труд". Совещания больше часа в день, длинное планирование. На посторонние задачи - 8-10% уже много. Код ревью 5 людьми. 100% покрытия кода. Насколько оно оправдано, насколько ценность этой практики больше затрат?

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

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

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

Причины запахов.

• Ритуалы. Когда-то смысл был, быть может у менеджера, который внедрял. Но сейчас смысл есть, а ритуал остался. Надо смысл найти.
• Ложь. Когда рассказываешь смысл ритуала - надо давать правду. Если у вас посещаемость для КЗОТ, а реально будут смотреть для оценки - то люди не будут верить. Так же и про то, влияют ли OKR на бонусы.
• Коммуникации. "Я выпущу за неделю" у разработчиков и менеджеров значит разное, у одного "первая версия точно не раньше" у другого "будет на проде".
• Неудобство. Когда заказ виртуалки - заявка на 25 полей в жире. Очень часто делают железобетонный процесс - и никто не ходит. Тотальная архитектура с тяжелым инструментом.
• Карго-культ. Построение имитации, без понимания смыла.
• Культура. Мантра о самоорганизующихся командах рассчитаны на определенные культурные особенности компании, которые не так часто встречаются. А их далеко не всегда формулируют и проверяют.

Запахи на этапе внедрения изменений.

• Любая сложная задача имеет простое, легкое для понимания неправильное решение. Где светло, а не где потерял. Пример - запрет релизов в пятницу при падениях без решения проблем регулярных падений.
• Безальтернативность. Так часто внедряют скрам и многие другие практики.
• Сделаем как гугл из той книжке. При этом вы - не гугл, 90% не имеют отношения. А еще коммерческий успех и качество процессов - разные.
• "Так сказал Кент Бек" - когда аргументы идут из веры в авторитеты. А так делать не стоит, надо думать.
• Я так сказал! - СТО или кто-то сверху.

Практики, которые попахивают почти всегда. Тут были провоцирующие штуки.

• Code review with pull request. Пропагандировалась только для open source, и там - оправдана, потому что запрос действительно неизвестно откуда. Нужна ли она вам?
• Системные аналитики - API, Дата модели, описание экранов. Проблема в системе: качественная работа требует хорошей квалификации разработчика за зарплату мидла. Так не бывает, они стараются, но часто получается лишнее коммуникационное звено.
• Scrum - внедрят "как получится"

Что делать? Первое - ТРИЗ. Из него любит две штуки.

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

Как освоить - книга "Месяц под звездами фантазии" Злотин и Зусман. Она достаточно для нетехнической штуки.

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

STATIK в Kanban. Можно использовать для всех процессов.

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

Философия.

• Метод рационального сомнения Декарта
• СМД-методология Щедровицкого. Базис как думать
• Гегель, Энгельс, Платон, Витгенштейн, Богданов ...

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

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

Алексей Пименов. Workflow и Визуализация процессов

Пост на FB Алексей Пименов. Workflow и Визуализация процессов. Как сделать правильно и не выстрелить себе в ногу. Основная мысль про доски: доска должна показывать существующий процесс, а не нормативно его диктовать. Очень часто на доске рисуют какой-то нормативный процесс, и пытаются его навязать без явной артикуляции. И так не работает, люди просто игнорируют доски. Возникают ситуации, когда на доске одно, в трекере - другое, а реально - третье.

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

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

Рабочий элемент - фича для заказчика. Подзадачи - декомпозиция, и эта работа распознается специалистом. Как разместить на доске?

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

Есть этапы когда идет работа, и когда работа ждет. И тогда можно собирать статистику. Если у вас нет буферных состояний, то вы все время принимаете за работу. А дальше эти данные - можно использовать для улучшения. Эффективность потока. Очень часто эффективность потока по клиентским задачам - от 1 до 15% Всего. Если на доске нет буферов - то это не собирается.

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

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

Совмещение несовмещаемого. Например, короткие выгрузки из БД, большие фичи и консультации.

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

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

Итоги

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

Физическая доска хороша для старта - потому что переделать доску в jira часто тяжело. А через месяц-другой по-любому идешь в online. Далеко не все трекеры дают достаточно визуализации. jira - нет. Есть sweet kanban (Индия), kanbanize (Болгария), kaiten (Россия). Есть еще для облачной jira - GetNave, он к ней цепляется и показывает. Для jira Тиньков делает бесплатный плагин. Названия тут с голоса, не точные.

Андрей Булов. Пошаговый алгоритм создания самоорганизующейся команды

Пост на FB Андрей Булов. Пошаговый алгоритм создания самоорганизующейся команды. Тут действительно пошаговый алгоритм отношения к созданию команды как к проекту: постановка цели, ограничения, дизайн, люди которые подойдут, план динамики развития. В целом это все подходит к любой команде, не только самоорганизующейся.

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

Команда живет в системе, система этих людей формирует, надо ее создать и запустить людей.

Шаг-1 - Цель. Когда пришел менеджер и говорит "бери команду", то первый вопрос - зачем. Если у команды есть путеводный маяк - она двигается. А без этого - просто работу работают. Надо найти вижн. Надо спросить не только менеджера, но и заказчика. Цели могут отличаться, это надо совместить. Цель должна вас зажигать. Если вас не зажигает - не работает.

Примеры:

• Надо поставить команду на рельсы. Поставка раз в 3 недели, 80% успешности (раз в 5 спринтов)
• Держи команду, чтобы все работали и люди не текли.

Шаг-2 - Ограничения.

• Корпоративные - бизнес-домен, внутренние правила
• Проект - бюджет, сроки. контракт
• Люди
• Техника.

Пример. Цель - миграция легаси на новые технологии за 2 года.

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

Выявление - через интервью, контракты и так далее.

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

Шаг-3 - Дизайн системы - команды

• Фреймворк
• Структура команды
• Люди, которые есть и которых нужно нанять.
• ...

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

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

Дальше - запуск/вход в команду. Основные задачи

• Дать понять, что стартовали
• Транслировать цели и ограничения
• Рассказать/установить правила
• ...

Проводит серию встреч, где рассказываем.

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

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

И важно на последних этапах уважать решение команды.

Сандра Урядова. Контринтуитивная роль тимлида: дать право на ошибку и возможность быть человеком

Пост на FB Сандра Урядова. Контринтуитивная роль тимлида: дать право на ошибку и возможность быть человеком.

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

Что надо делать практически? Во-первых, усиление софтов.

• Базовая установка на открытость
  • Обучение и эксперименты
  • Слушать и действовать
• Человек не равен своим действиям и своей работы. Персона (профессиональный) и Личность.
  • Разделение помогает отрабатывать рабочий контекст.
• Рефлексия - открытость самому себе. Открыт сам себе.
• Мотивируешь других - мотивируй себя
• Работа менеджера и тимлида - процесс, а не немедленный результат сделанных задач. Дофаминовая просадка. Успех на долгих задачах. И к этому надо адаптироваться.

Инструменты

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

Кстати, возможно именно о модели из книги "Кругом одни идиоты" рассказывал Anton Morev на TeamLeadConf-2020 в Москве (мой конспект) - он услышал модель на тренинге, и не знал ссылку.

Менеджерские навыки.

• Делегирование - я вам доверяю общий результат. Это не просто про задать задачу
• Находить и регулярно работать с конструктивной критикой.
• Косвенные симптомы - упала удовлетворенность стейкхолдеров, ругань внутри - повод разобраться.
• Забыть шаблон "начальника". Я для команды - клей и мотор, я не сверху.

Инструменты

• Ясность ожиданий: OKR, backlog, Roadmap
• Потоки ценности по правилам. Поменяли дейли с формата скрам на формат канбан (разговор по задачам, а не по людям) - стало лучше.
• Продуктовое мышление тимлида - понимание продукта и связи с бизнесом

Илья Любимов. Что делать с командными проблемами

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

Конфликты. Для частей системы они - проблема, а для системы - решение. При конфликтах не надо копаться в частных случаях, а искать повторяющиеся конфликты, смотреть на распространение. А дальше - определить уровень системы, на котором конфликт является решением.

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

Примеры - были.

Свойства живых систем.

• Фокус на выживание.
• Система - часть большей системы.
• Части системы служат целому. Как волосы - ты их стрижешь.
• Целое больше чем сумма частей.
• Свойства целого отражаются в частях. Предположим, проблема здесь решена. Где возникнет такая же?
• Система - это саморегуляция. Если вы спровоцируете проблему - система сама решит, как ответить на воздействие.
• Система - в постоянном обмене. Если обмена нет - часть отмирает.
• Все живые системы в каждый момент делают выборы: обновиться или оставить как есть. Постоянные обновления - гибель, не хватит энергии. Неизменность - гибель из-за отсутствия адаптации к миру.
• Целостность. В контакте со своим происхождением, признание всей своей истории, есть место всему, что принадлежит. Черные страницы - их нельзя заметать под ковер.
• Обмен в справедливом балансе. И это - не только деньги, это еще признание.
• Достижение точки своего назначения. Это то, для чего система была создана изначально.

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

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

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

Комментарий Anton Polisski. Отзывается. Но что касается конфликтов, меня когда-то учили, и я согласен, что:

• они неизбежны
• они как раз и являются точками роста.

Важно правильно ими управлять.

Максим Цепков. Anton Polisski Да, именно так, согласен. Но точками роста они являются, только если там синтез решений, а это возможно только, когда оба участника вышли в надсистему, а не остаются в той области, которая сформировала их точку зрения.

Anton Polisski. Maxim Tsepkov а это как раз задача руководителя - выводить конфликты в надсистему. И организовывать коммуникации так, чтобы конфликты разрешались конструктивно

Комментарий Виктор Вальчук. Я для этой цели - нахождение корневого конфликта Команды и его преодоления - использую мыслительные процессы ТОС

Кирилл Анастасин. Флибустьерская система управления и найма

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

В рассказе было много деталей и примеров, как все это проявляется, довольно резко контрастируя с современным мягким политкорректным стилем управления и, мне кажется, основным посылом было как раз то, что так - бывает, работать в таких проектах - круто. Я тут хочу сказать, что так действительно бывает, я вижу проекты с жесткими сроками вокруг, и я сам делал такие проекты, три из них - в памяти, потому что это было очень непросто. АБС с нуля за полгода, потому что нормативка менялась так, что старая АБС не могла работать. Система платежей ЖКХ, которую потребовалось стартовать "завтра", а не через 3-4 месяца, как было в планах, потому что сработала закладка, оставленная в коде разработчиком предыдущей системы, и остановила ее работу. Система оперативной диспетчеризации приходящих товаров на складе, потому что заказчик неожиданное понял, что входящий поток существенно превышает возможности склада, и придумал решение, которое потребовалось поддержать софтом за пару недель.

Но это не только я наблюдаю вокруг, о таких проектах есть замечательная книга Эдварда Йордана "Смертельный марш" - о проектах, в которых сроки и бюджеты в несколько раз меньше оптимистичных оценок. Он пишет в начале, что уже более тридцати лет в IT, было несколько культур, и каждое новое поколение пишет, что уж оно-то не будет делать такие проекты. А они все есть. Книга о том, как жить в таком проекте и зачем имеет смысл туда идти. Собственно, доклад - признание таких проектов и один из действующих способов их реализации. Один из способов - потому что управление вовсе не обязательно авторитарное с единственным лидером. Часто есть разделение ролей, за каждый круг вопросов отвечает отдельный человек и именно он принимает решения по этому кругу вопросов. В наших проектах обычно 2-3 лидера: отношения с заказчиком, архитектура, организация разработки, технологии держат разные люди, получается мозаика.

Михаил Саламатов из Dell. Почему тимлиду нужно сотрудничать с ВУЗами

Пост на FB Mikhail Salamatov из Dell. Почему тимлиду нужно сотрудничать с вузами, или Немного о Team Value Management. Две цели сотрудничества с ВУЗами: получить способных студентов и еще в процессе обучения дать студентам знания о современных технологиях, которые не может дать ВУЗ, дополнить его образование. В докладе был рассказ о нескольких формах сотрудничества.

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

• Студенты второго курса пишут заявку-эссе, о чем бы хотелось поговорить.
• Наставник один семестр (весенний) раз в неделю 1 час встречается и обсуждает.
• Ментор - не всегда топовый эксперт. Наоборот, ментор - на 1-2 ступеньки выше студента. И для ментора важен нетворкинг. Они поддерживают студента, даже если он идет в другую сторону, например, в игровую индустрию. У ментора тут не всегда есть знания, но часто есть социальные связи, например, чтобы организовать экскурсию в компанию или беседу со специалистом.
• Произвольные пары - плохо. Подбираем анкетами, заявок больше менторов - тогда есть выбор.
• Назначать менторов в программу - плохо. Должно быть добровольно, ментор должен видеть пользу для себя. Например, отточить навык передачи знаний или коммуникации.

Во-вторых, преподавание.

• Не надо преподавать то, что без нас. Он умеет математику, С++ и ОС.
• А вписывание к нам - кубернетес, CI/CD, Go, Тестирование
• Курс без практических заданий - плохо. Но проверка заданий - серьезная нагрузка, и это надо учитывать. Может быть преподаватель и группа поддержки.
• Работает Спецкурс
• Работает Перевернутый класс: список литературы + практическое задание. И дальше обсуждаем, что получилось.
• Помогает: академический опыт, опыт выступлений на конференциях, подготовка преподавателей, "второй пилот" для преподавателей
• Если вы - преподаватель, то можете смотреть на студентов в массе, и это - интересно.

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

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

• Не стоит проекты и лаборатории ставить вокруг сложного софта, особенно проплиетарного, и вокруг процесса, который сложно воспроизвести. Не стоит строить вокруг специфического железа - его у студента не будет.
• Перспективное направление - проекты с открытым исходным кодом. И тут преимущественно не создание своего проекта, а использование, склеивание разных продуктов, модификация и развитие существующих проектов. Дополнительный бонус для студента - он светится в сообществе.
• Они ведут студенческую лабораторию в СПБГУ, где сделали инфраструктуру для интернета вещей, с open source софтом.
• Важен фокус не только на технологиях, но и на организации. Стоит сделать рабочее окружение проекта, похожее на то, которое есть в вашей компании - slack и т.п.

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

Отметим, что поступление в Питерские ВУЗы по программной инженерии - около 400 студентов, а если брать все смежные специальности - около 1500. То есть их 50 человек - это 1/8 потока Питерского студентов по программной инженерии. Но кафедр с качественным образованием - не так много, они - известны и там довольно тесно от компаний, ищущих студентов. Так что ранняя работа дает преимущество. Но при этом возможно и сотрудничество, например, в том, чтобы разные курсы читали разные компании, в соответствии со своей специализацией - а студенты получали разносторонние знания. То же касается и лабораторий - у них могут быть разные специализации.

Их лаборатория с OpenSource есть в СПБПУ и в СПБГУАП.

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

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

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

— Максим Цепков • 14:23, 19 декабря 2021 • нет комментариев