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

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

Содержание

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

StTL2021-promo.jpg

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

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

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

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

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

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

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

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

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

Александр Здрок. Serge Vakulenko, а оно точно имеет отношение не только к программированию ??
Сергей Вакуленко. Почти как моральный кодекс строителя коммунизма. Был такой 60 лет назад.
Дмитрий Калашников. Сергей Вакуленко а к программированию людей?
Максим Цепков. Сергей Вакуленко Это имеет отношение к организации ведения разработки. Там половина шаблонов - знакомые по agile-методам (бэклог, встречи и т.п.), а вторая половина - из других источников, интересные. И общая модель очень похожа на развитие продуктов через проверку гипотез. Когда agile-методы придумывали, продуктовой разработки с быстрым циклом было не так много, так что даже в том, как они переформулируют знакомое - есть определенная ценность. Что мне там нравится - все весьма прагматично, и потому на кодекс строителя коммунизма не похоже, хотя принципы так или иначе туда выведут. Не "жить надо честно", а "жить надо прозрачно", а дальше общество само решит - дать тебе в морду за такую жизнь, или нет.
Сергей Вакуленко. Дмитрий Калашников Программирование людей звучит пугающе.
Сергей Вакуленко. Maxim Tsepkov Да я как бы тоже в этом бизнесе, в разработке. Всё время поглядываю на твои посты в надежде надыбать полезное для себя и своей команды. Пока не надыбал.
Максим Цепков. Сергей Вакуленко Ну, понимаешь, ты же крутой инженер. И поэтому у тебя все может быть и так организовано сильно по уму. С другой стороны, я для себя периодически что-то интересное и полезное нахожу в разных областях. Сейчас вот решил разобраться с социократией, и тоже нашел. Не так чтобы супер-открытия, но схема деятельности нарисована классно, и различение Напряжение - Драйвер - Эксперимент с гейтами - важное, важно не слеплять. Или процедурное различение обратной связи на человека и на его игру роли. Или принцип, что обратную связь организует сам получатель, а не кто-то снаружи.
Сергей Вакуленко. Maxim Tsepkov Я инженер, но не в этом суть. Я по жизни имел честь участвовать в разных проектах: больших и маленьких, успешных и неуспешных. Когда два-три человека делают замечательную разработку - это не удивительно, наблюдал много раз. Но когда попал в проект из 120 разработчиков (это был MIPS) - было удивительно, как они умудряются координировать процесс, причём не снижая темпа. Позже наблюдал противоположный случай, когда команда из 200 человек взяла на вооружение модный принцип OKR (ты его упоминал как-то), а через два года, проев $100млн инвестиций, разорилась и распалась. Мой вывод, упрощённо: универсального рецепта нет. Всё зависит от сыгранности ключевых людей в команде.
Дмитрий Зацепин. От людей всегда всё зависит. S3 помогает людям создавать сыгранные, гибкие и устойчивые к испытаниям команды.

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

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

Максим Цепков. Алексей Шиндин Смотри, самоуправление по социократии явно сильнее традиционной демократии, так как дает больше поля для личной инициативы. При условии, что люди умеют этим пользоваться. Понятно, что пока не умеют - они слабы, но это проблема с любым инструментом. Если сравнивать с авторитарным лидерством, то тут вопрос сложный.
Алексей Шиндин. 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 закрытые вещи (химические формулы, ключевые поставщики и что-то еще).

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

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

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

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

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

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

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

Цифры.

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

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

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

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

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

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

Настоящее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Философия.

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

Инструменты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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