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

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

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

Разнообразие культур

О деньгах и зарплатах

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

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

Наконец, есть корпорации, которые, конечно, стонут от стоимости IT-специалистов, но при этом то одна, то другая объявляет массовый набор с зарплатами +30% к рынку, надеясь, что достаточно нанять - а дальше они сами организуются и будут делать проекты. Надежды обычно не оправдываются, и через год-два идут массовые сокращения, и на рынке оказываются люди с завышенными ожиданиями по зарплате - потому что от них пару лет при высоких зарплатах не требовали эффективной работы. А корпорации умеют, и понимают, что помимо профессиональных навыков должно быть умение вписаться в их культуру, которое продемонстрировали те, кто остались - и на рынке появляются вакансии с еще более щедрыми предложениями, 50-70-100% за позицию, в которых, однако, неявно включен тот самый набор требований по совместимости с корпоративной культурой. Именно неявно, и потому визуально они слабо отличимы от прочих вакансий, что, естественно, влияет на стоимость специалиста.

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

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

О конфликтах

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

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

Разнообразие культур в целом

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

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

Об организации конференции

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

Вообще общение в кулуарах - очень ценная штука на конференции. Кулуары - это то, что отличает оффлайн формат. Очень жаль, что организаторы сочли чрезмерным риск по организации традиционной афтерпати, в этот раз его не было. Но это - вопрос их оценки рисков. Формально - эпидемия продолжается и ограничения действуют. Конечно, суровость российских законов компенсируется необязательностью их исполнения, но это - статистическая история, а в конкретной ситуации можно и попасть на проверки и санкции из-за нарушений. Да, на AgileDays вечеринка была, но там было не более 500 человек, а тут очно - почти 900, это разные классы мероприятий. Будем надеяться, что все-таки ситуация будет меняться и на будущих конференциях афтерпати возобновиться.

Вообще это - третья оффлайн-конференция, в которой я участвую этой весной - вслед за AgileDays и SQAdays. Лично мне живого нетворкинга сильно не хватало.

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

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

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

В посте о докладе Андрея Смирнова возникло обсуждение о ценности конференции, и, в частности, про сравнение с SoftwarePeople, очень интересной конференцией, которая была в начале 2010-х, а потом прекратилась. На моем сайте есть отчеты за 2011-2013 (смотри здесь), и, как всякое прекрасное прошлое может выступать эталоном. Тут я бы не сказал, что тимлид не дотягивает.

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

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

О докладах

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

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

Пост на FB Первый доклад - Alexander Orlov. В поисках энергии тимлида, или О пользе управленческого слабоумия. Основной фокус доклада - на поиск драйва и энергии, а вернее - на понимание процессов, которые могут давать энергию, а могут восприниматься как бесконечная рутина и повторение, и эту энергию отнимать. Александр столкнулся с этим в самом начале работы тренером: люди приходили уставшие и нервные, и хотели через обучение вернуть то состояние энергичного драйва, которое помнили по молодости, времени обучения в институте и освоения профессии. Он несколько удивлялся, что люди за этим приходят к ним учиться. Начали отправлять утомленных насильно в отпуск - и энергия появляться. А через пару лет он столкнулся с этим зам, запуск очередного образовательного проекта стал восприниматься как неизбежная рутина. Слава Панкратов, партнер, тогда оправил его в годовой отпуск. Через 8 месяцев он понял, что отдыхать ему нравится, а вкус к работе - не вернулся и пошел к коучам. Словил инсайты, его отношение к работе - изменилось, хотя сама работа - не сильно, и ему до сих пор работа дает драйв и энергию, хотя задачи есть разные. Он заинтересовался коучингом всерьез, получил образование и активно применяет.

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

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

В докладе была конкретная:

Директивный - делай как сказал
Харизматический - иди за мной
Отеческий - главное - люди
Демократичный - хочу услышать мнение
Эталонный - я - пример, делай как я

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

А еще все эти стили не способствуют развитию людей. Есть еще один стиль - коучинговый, который работает на развитие, про повышение осознанности и ответственности, и дальше был фокус на нем. С рассказом про Арку коучинга, которая строит мостик между реальностью и будущим, и в конце - присваивает полученный опыт. Там было много подробностей, которые Саша рассказывал через конкретные истории. Фокусируя как раз на моментах, когда люди не слышат другого, или часто предлагают решение вместо того, чтобы разобраться в целях и проблемах - а решения оказываются неверными. Я эти истории повторять не буду. Чувствуется, что за ними стоит определенное мышление, оно у Саши есть, при чем в осознанной компетентности, и это особенно ярко проявилось в ответах на вопросы из зала. Но при этом само мышление как система проявлено не было, оно осталось за кадром. С другой стороны, понятно, что за 15-20 минут изложить концепт коучинга - не реалистично, а истории - они могут пробудить интерес учиться самому. С другой стороны, по историям есть впечатление, что можно составить чеклист на 5-7 самых распространенных пунктов, которые всплывают на поверхность. Думаю, если бы такой чеклист был - было бы круто!

Татьяна Елистратова. Конфликт в команде: как сократить потери, извлечь выгоду и остаться в живых

Пост на FB Tatyana Elistratova. Конфликт в команде: как сократить потери, извлечь выгоду и остаться в живых. Основная идея - о том, что конфликт - это нормально, его можно исследовать, им можно управлять, и вообще он конструктивен. Он вскрывает проблемы, позволяет выплеснуть накал, выясняет соотношение сил, создает правила игры и объединяет соперников. Это - при правильном ведении конфликта. Которого часто не происходит, особенно у технарей - горит текучка, не до психологии. И когда приходишь - то часто отторжение: "Ты кто - коуч? Ты же была HR - пойди лучше помоги с наймом. А у меня тут все горит." При этом ты знаешь, что у него - реальные проблемы, люди уходят по одной и той же причине.

В докладе было много историй разных конфликтов и примеров конструктивного решения. И теория тоже была, например, подход Эриксона.

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

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

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

Александра Шляхова. Как перезапустить отношения сотрудник-компания с помощью творческого отпуска

Пост на FB Александра Шляхова. Как перезапустить отношения сотрудник-компания с помощью творческого отпуска. Рассказ был про интересную практику МИФ - творческий отпуск. Его дают если человеку нравится компания в целом, но ему стала не слишком интересна текущая работа, и он не слишком понимает куда идти. На три месяца, но без оплаты, кроме оплаты неиспользуемой части отпуска. И дальше рассказ был о том, как организовать этот творческий отпуск с пользой. И для руководителя и, главное, для самого сотрудника. Главное - остановиться и оглядеться вокруг, увидеть новое в отрасли. Узнаешь много нового вширь. Потом наоборот, надо погрузиться и сфокусироваться, понять, что интересно именно тебе. Поучиться. Только не загонять себя, 6 курсов с 10 до 19 каждый день - не то, что нужно.

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

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

В комментариях к посту - обсуждение про репрезентативность доклада и уместность практики отпуска в целом с автором.

Michael Stepanov. Скорее всего не слишком эффективно это. Практика докладчика тому подтверждение. Нужно смотреть, что не устраивает. Для отдыха подойдет и обычный отпуск.

Алекс Шляхова. Михаил, привет! Не торопитесь с выводами) На рынке слишком мало кейсов, поэтому приходится набивать свои шишки — и это не значит, что творческий отпуск не работает. Даже в нашем случае оценивать статистику = попасться в ловушку малых чисел. А вот проанализировать этот опыт и провести работу над ошибками, вынести хорошие и плохие практики вполне можно. Если другие учтут наш опыт, скорее всего начнут удачнее.

P.S. О цели творческого отпуска Максим написал. Это не отдых.

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

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

Алекс Шляхова. Дмитрий Подлужный спасибо, что поделились мнением. Вижу по рынку (тем немногим компаниям, у которых можно подсмотреть), что творческий отпуск за свой счёт — скорее нормальная, частая практика, чем исключение. Но ваша обратная связь, как и ряда участников конференции, противоположная. Хороший повод задуматься, благодарю. Только не связывайте со статистикой, очень прошу. Не зная ни контекста, ни деталей, это как минимум некорректно.

Татьяна Суходолова. Топ-5 когнитивных искажений при планировании в IT

Пост на FB Tatyana Sukhodolova. Топ-5 когнитивных искажений при планировании в IT. Интересный доклад. Когда за типовыми ситуациями, распространенными в IT, показывают когнитивные искажения. Например, команда оценивает в оптимизме, при этом регулярно не успевает, за год только один успешный месяц был - и она все равно выдает оптимистичный срок и уверена, что он реалистичен, ведь ничего непредвиденного не произойдет. Это - когнитивное искажение. И есть методы борьбы: премортем - сессия фантазий на тему, если мы зафейлим - то почему; планирование от конца обратным счетом; попытка вписать срочное с учетом текущей загрузки.

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

Expert's problem - когда эксперт считает все очевидным и не объясняет, а команда - не понимает его мнения. Тут надо работать с экспертом, чтобы он вставал в позицию учителя, при непонимании.

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

Парные искажения: Self serfing attribution (успех - мой, провалы - из-за обстоятельств) и fundamental attribution error (когда я сделал неверно - это ошибка, а другие делают неверно по глупости и злобности). Правда, иллюстрировано не очень понятным примером, когда заказчик все время переписывал сделанные user story, и хотел переделок за те же деньги. Для меня это как-то плохо матчится с данным искажением, но тут может быть дело просто в способе рассказа, который не проявил мышление заказчика или самой команды в этом месте.

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

Да, всего искажений известно 175. В первой версии доклада было 10, не влезало. Получилось рассказать про 5 часто встречающихся.

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

Илья Кнопов. Интересно. Где можно побольше прочитать про искажения? Особенно в приложении к IT?

Филипп Дельгядо. Илья Кнопов, можно просто загуглить. Ну или https://ru.wikipedia.org/wiki/Список_когнитивных_искажений

Филипп Дельгядо. Обидно, что самое важное для IT искажение не попала - "Ошибка выжившего". Ну и примеры говорят не столько про искажения, сколько про проблемы с процессами в компании, искажения там вторичны (

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

Андрей Степенко. Филипп Дельгядо искажения руководства создают проблемы с процессами

Филипп Дельгядо. Максим Цепков, по моему опыту большинство проблем в индустрии (плохие процессы, плохая архитектура, плохие решения) исходят из "такие-то попробовали и у них получилось", т.е. как раз из-за "ошибки выжившего". На конференциях этого особо хорошо заметно, почти никогда не встречается анализ "а какие границы применимости решения, а насколько оно существенно для успеха" и т.п.

Филипп Дельгядо. Андрей Степенко, в докладе в основном говорили про искажения разработчиков, а не менеджмента. Что тоже, гм, навевает грусть.

Андрей Степенко. Филипп Дельгядо как это непрофессионально. Разрабов надо хвалить. А руководство ругать. Чтобы так сказать исправить основное искажение самовлюбленности. То бишь гордыни. Христос воскрес мой тайный коллега по стратегическому и эвристическому!

Андрей Степенко. Никто не умеет хвалить! Я уж не говорю про диалектику или что-то архитектурное. А Макс отдувается за всех пропагандой дебилизма в докладах.

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

Tatyana Sukhodolova. Спасибо за замечания, Максим. Поняла, где надо было подсветить искажение подробнее. Self serfing attribution проявлялся, например, в том, что заказчик считал, что он - молодец, и поступает правильно со всеми командами, переписывая им ТЗ раз за разом. А fundamental attribution error - в том, что текущая команда считала, что справится с новой задачей, оптимистично полагая, что 4 команды до нее - не очень компетентные сотрудники, работали плохо и у них было мало экспертизы, "а вот мы - молодцы".

Дмитрий Ильенков. Как сохранить лидерство в команде

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

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

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

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

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

В комментариях - интересные обсуждения.

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

Максим Цепков. Инна Ситникова Потому что ответ "убиться ап стену" - не политкорректный. Не надо быть шершнем и проводить геноцид пчелок. А сдерживать развитие разработчиков и гробить команды в нынешнем IT-рынке - это гробить бизнес.

Инна Ситникова. Максим Цепков что значит "не надо быть шершнем"? Как будто шершень осознает, что он делает что-то плохое. Возможно, есть недопонимание роли шершня. Шершень не проводит геноцид среди всех пчёлок в биологическом мире и сравнение шершня с токсичными людьми, на мой взгляд, в принципе не корректно. Без особых усилий шершни способны уничтожать достаточно крупных насекомых, например саранчу, мух и ос, наносящих ощутимый ущерб пчелиным семьям после завершения медосбора. Нападают шершни и на пчёл, но не всегда, а лишь при выкармливании личинок. Атака чаще всего направлена на пчёл старых или больных. Пойманных пчёл шершни сразу же убивают и в пережёванном виде несут в гнездо. Учитывая тот факт, что шершни используют в качестве пищи вредителей садовых культур, а также старых и больных пчёл, их можно причислить к полезным насекомым.

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

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

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

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

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

Андрей Павленко. Galina, на 100% согласен, что настоящая команда (зрелая) сама отторгнет шершня. Но если это ещё не команда, а лишь рабочая группа, из которой мы хотим сделать команду - шершень её может убить раньше. Вот и стремятся лидеры спасать свои "будущие команды"

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

Anton Nikolaev. Galina Sartan ну так и конференция сама по себе такая. Про менеджеров снежинок.

Galina Sartan. Anton Nikolaev Да, в основном об этом. Это показатель развития рынка работы с командами. Был бы хорош для аналитики. Но руководители это все могут принимать как посыл к действию, к сожалению.

Андрей Павленко. Anton, про менеджеров снежинок или про менеджеров-снежинок?

Galina Sartan. Андрей Павленко Ну да, как усилить снежинистости:)))

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

Galina Sartan. Максим Цепков Жаль, что в начале не дают определение, что понимают хотя бы под командой. Об остальных уточнениях можно только мечтать:)

Андрей Павленко. Максим Цепков Разделение ответственности между лидером и командой скорее зависит от личностной зрелости и прокачки навыков принятия решений и принятия ответственности (как лидера, так и членов команды), чем от профессионализма.

Максим Цепков. Андрей Павленко Это конечно, просто я ответственность, лидерские качества и остальные софтскилл тоже включаю в профессионализм, наряду с хардскилл. Это чисто терминология.

Galina Sartan. Андрей Павленко Профессионализм смотря в чем. А все остальное - это технология взаимодействия руководителя с командой. Многие путают лидеров и руководителей, из за этого тоже получается смешение воздействий

Максим Цепков. Что касается снежинистости, то это, на мой взгляд, ни разу не про IT. Конечно, в конкретных компаниях бывает разное, но если говорить о конференции, то на мой взгляд про это явление нет ни докладов ни обсуждений в кулуарах. Конечно, можно модный лейбл лепить на все подряд, но снежинистость - достаточно определенное явление, у меня об этом был пост в декабре со ссылками https://mtsepkov.org/Snowflake Конечно, это - мой взгляд, я могу ошибаться. Anton Nikolaev, Galina Sartan, Андрей Павленко, давайте обсудим - но не на уровне наклеивания ярлыков, а по существу.

Galina Sartan. Максим Цепков Это про IT точно, проблемы есть. Посмотрите интервью на моем канале, послушайте, как много об этом Дорофеев говорит, и именно для IT.

Максим Цепков. Galina Sartan Интервью я, конечно, посмотрю, но хочу заметить, что люди-снежинки Дорофеева и showflakes как социальное явление - это про совсем разное. Дорофеев в интервью - он про какую снежинистость говорил? А еще тут в комментах люди говорили именно про снежинистость конференции - и мне бы тут хотелось бы фактуру.

Anton Nikolaev. Максим Цепков Снежинка в том смысле, что он координирует между собой разные функции в группе, пытаясь попасть в определенный свыше кем-то (продукт менеджером, чаще всего) результат. И зовут такую снежинку гордо тимлид)

Максим Цепков. Anton Nikolaev О, а это еще одно определение что такое снежинка - это такой центр коммуникаций получается. О нем я вообще не подумал. Круто, буду иметь ввиду!

Андрей Смирнов. Карьерные уровни Soft Skills

Пост на FB Андрей Смирнов. Карьерные уровни Soft Skills. Любопытный доклад. Он призван дать некоторый детальный взгляд на софтскилл. Потому что это часто оценивают в неопределенных характеристиках "странный человек", "не сработаемся" и тому подобных. В докладе было 40 soft skill в 4 областях - собственное развитие, коммуникации, мышление, лидерство. Они путем опроса были распределены между квалификациями junior-middle-senior-teamlead-руководитель. И дальше речь шла о том, как их можно проверить на собеседовании. Для джуна проверяются просто, для остальных навыков больше, но все равно проверяемо через собеседование почти все. А дальше была часть где навыки выстроены в некоторые вертикальные линейки, и еще построена зависимости между разными линейками. Презентация шла очень динамично, и я успевал заметить только фрагменты. На них мне будет интересно посмотреть и подумать. Соотнести с известными схемами софтскиллов и ролей в других теориях. Потому что схема-то оригинальная и из практики.

Слайд 89 из презентации Андрея Смирнова

При подготовке этого отчета я посмотрел презентацию, она есть в программе конференции, плюс Андрей кинул в комменты ссылку свою публикацию https://sandark7.github.io/TeamLeadConf2021/. И по этому поводу у меня ряд тезисов.

Формулируются вектора развития, а не компетенции. Управление эмоциями, например, или критическое мышление или эмоциональный интеллект - владение ими может быть на очень разном уровне. А когда мы начинаем приписывать их уровням сотрудников, то надо как-то говорить об уровне владения. Это предполагается интуитивно-ясным, а на самом деле требования сильно различны. То же самое управление эмоциями - очень широкий спектр от условного уровня двухлетнего ребенка (условного - потому что дети очень разные) до не менее условного уровня профессионального актера. Junior - на каком уровне должен владеть?
Кластеры - явно разнородны, особенно это касается собственного развития. И в целом, выделение мышления, коммуникации и лидерства из собственного развития - тоже весьма проблемная штука, это разнородные понятия. Разбиение на несколько вертикальных столбцов - улучшает ситуацию. Мне нравятся те, которые на слайдах 88-89, на рисунке - слайд 89. А вот последующее именование столбцов условными ролями мне не сильно нравится, потому что названия - сильно трактуемы, а рисовка создает впечатление, что речь идет о карьерной лестнице не только снизу вверх, но и слева-направо. И к такой рисовке у меня возникает много вопросов. Которые невозможно обсуждать без определений - а их нет.
В целом весь этот набор софтскилл довольно хорошо покрывается курсами школы системного менеджмента Анатолия Левенчука. В них начинают с базовых вещей - управления вниманием и целеполаганием, отношением к саморазвитию как к проекту, за которыми идут онтологика и коммуникация, системное мышление и так далее. Группировка более крупная, но она соответствует курсам, которые доступны для освоения. Правда, курсы по управлению вниманием, целеполаганию и лидерству - в разработке, но практически это значит, что их фрагменты сейчас включены в другие курсы, и системной проработки пока нет. Правда, тут есть сложные вопросы, касающиеся таких скиллов, как эмоциональный интеллект или нетворкинг. В каком-то объеме они входят в ролевое (стейкхолдерское) мастерство, присутствующее в нескольких курсах, а дальше надо разбираться. Но при этом курсы увязаны между собой в целостную систему, а если говорить об отдельных тренингах по софтскилл, например, по эмоциональному интеллекту, то такую связь с остальными представлениями о мире придется делать самостоятельно.

На этом, пожалуй, все.

В обсуждении поста неожиданно появился тред о ценности конференции как таковой.

Anastasia Totok. Интересно про собеседование. Проблема в том, что у проверяемого у самого должны быть очень развиты данные качества. Зачастую это не так, особенно когда рассматриваются руководящие позиции.

Максим Цепков. Anastasia Totok Да, должны быть развиты. И IT как раз в эту сторону интенсивно работает - классифицируя качества, обучая людей их различать и так далее... Отсюда и интерес.

Anastasia Totok. Максим Цепков ко мне обратились с запросом помочь в такой классификации. Тесты сделать не проблема, сейчас достаточно социальных данных, но это один из этапов, т к расшифровать тест тоже надо уметь - это раз, и второй момент, столкнулась сама прям на днях. Когда скилы и навыки навыки кандидата сильно выше hrа. А если принимать во внимание, что на подборе персонала большой процент людей с нешироким развитием, то здесь мы получаем узкое горлышко. Интересная задача, сама такую сейчас решаю, но пока в ручном режиме, хотя и используем тестирование, но оно не является панацеей.

Максим Цепков. Anastasia Totok Да, в докладе звучало, что основная проверка навыков идет не через HR на предварительном собеседовании, а на последующих этапах в ходе технического собеседования и знакомства с руководителем. При чем без тестов, ты это вплетаешь в основное собеседование и держишь такой фокус... Что, конечно, повышает требования к тем ,кто собеседование ведет. С другой стороны, предполагается, что собеседование ведут люди соразмерной или более крутой квалификации, а значит они обладают этими софтскилл навыками и умеют их различать у других.

Anastasia Totok. Максим Цепков реальность такова, что большинство не обладает и не умеет различать. Почему - долгий разговор с ясными фундаментальными причинами. Но т.к. нет этого пункта, рушится вся система, которая в Теории выглядет складно.

Максим Цепков. Anastasia Totok Не рушится. Потому что раз большинство не обладает и не различает нужные навыки софтскилл - значит это надо принять и начать учить, чтобы обладало и различало. И IT этим сейчас интенсивно занимается. Так что будут обладать и различать. Я уже писал как-то, что если мерить по уровню докладов на тимлиде, сравнивая с ПИР, он в IT очень высок, сопоставим с неплохими тренерами и очень продвинутыми HR. А тимлид - это массово, это руководитель группы в 6-10 человек, при этом многие доклады адресованы даже не им, а разработчикам. Ну да, это замер по лидеру, но за ними интенсивно бегут и меняется средняя ситуация, при этом хвост будет еще долго подтягиваться - я это по освоению Agile в динамике наблюдал по отрасли, тут тоже самое идет.

Anastasia Totok. Максим Цепков не спорю с тобой, лишь обозначаю, что улучшить качество доклада - месяц, прокачать гибкие навыки у человека - от 9 месяцев и выше (так меняется психика человека) и никуда от этого не уйдешь. Поэтому говорить "ит этим занимается поэтому все скоро измениться" не верно, т к скоро все не измениться и массово уровень гибких навыков не вырастит.

Максим Цепков. Anastasia Totok Скоро или нескоро - мы увидим на практике. Я думаю, лет через пять уровень понимания софткилл, который был в докладе, станет нормой отрасли. Но могу ошибаться.

Anastasia Totok. Максим Цепков безусловно есть практика. Но мы не первые, кто это практикует, поэтому надо смотреть историю и понимать скорость изменения индивидуального и группового мышления и восприятия.

Илья Кнопов. Таки читаю ваши посты и понимаю, что таки зря не пошёл на тимлидконф (

Дмитрий Подлужный. Илья Кнопов не жалей )

Илья Кнопов. Дмитрий Подлужный ты уже сходил ? )))

Дмитрий Безуглый. Илья Кнопов Поддерживаю Дмитрий Подлужный . Максим всегда трансформирует понимание доклада по своему и добавляет смысла. Плюс ему . Но в результате происходит создание иллюзии ценности конференции. Что далеко не всегда соответствует реальности.

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

Дмитрий Безуглый. Илья Кнопов Зависит от целей. Я поставил крест на Бунинских проектах т. к. главная ценность команды дать не полезный, а развлекательный контент. Практически каждый докладчик сталкивается с требованием упростить или адаптировать контент под среднестатистическую квалификацию. В общем если сменить вывеску на НЕПРОФЕССИОНАЛЬНУЮ конференцию то все Ок. По темам не дотягивает даже до уровня Software People 10 летней давности . В проф. среде такие конференции называются BootCamp . Что начинающие думают о профессии , какие шишки собирают и т.д.

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

И вот тут не стоит путать требование сделать сложные концепты понятными аудитории с требованием не вводить вообще сложные концепты в рассказ. Это - разные требования. Позиция ПК - рассказывать понятно. Сделать сложное понятным не упрощая - вызов к докладчику.

Если сравнивать с SoftwarePeople, то я бы не сказал, что тимлид не дотягивает. Конечно, на SWP были топовые доклады, например, доклад Влада Балина про применение для постановки целей подходов, выработанных германским генштабом в 19 веке я до сих пор помню, и действительно не могу назвать соразмерных. С другой стороны, пара докладов от ivi на предыдущих конференциях о внутренней трансформации были тоже круты, просто по-другому. На этой тоже были интересные доклады, хотя реальных инсайтов и вау-эффектов я, наверное, не поймал.

Дмитрий Безуглый. Максим Цепков Да уровень приблизительно тот-же,10 лет спустя ... собственно об этом и речь. Не профессиональный уровень. А презентация или видео Влада есть ?

Олег Бунин. Дмитрий Безуглый серьезно? А мы думали, что это мы решили больше не приглашать тебя из-за грубого нарушения Code of Conduct. Вот как интересно, оказывается.

Олег Бунин. Дмитрий Безуглый Ну а то, что ты пишешь про требования к докладчикам, просто неправда. "Практически каждый докладчик" - это слишком громкое обобщение. Но в спор о качестве контента вступать не буду - на вкус и цвет товарищей нет, это можно оценивать только метриками опросов. Как они будут - расскажу.

Дмитрий Безуглый. Олег Бунин Ты считаешь что разбираешься в этике , а я считаю что разбираюсь в теме профессионального в Архитектуре , Разработке, Развитии команд и управления продуктами. Меня может занести в плане коммуникации. Но продуктовая направленность на непрофессиональный контент на твоих мероприятиях это системный выбор. У меня за спиной более 70 докладов работа в ПК десятка конференций. И должен отдать должное профессионализму твоей Эвент команды. Вы молодцы. Вы делаете лучший продукт с точки зрения эвента. Но за профессиональными знаниями к вам лучше не ходить. Это моё мнение как инженера системотехника реализовавшего более 10 систем и консультанта работавшего и работающего более чем с 20 передовымм компаниями. Справедливости ради нужно отметить что большинство массовых конференций строят свою бизнес модель на контенте ориентированном на ту самую усредненнкю массу.

Максим Цепков. Дмитрий Безуглый Презентации уже выложены в программе конференции. Видео, как обычно, в общем доступе будет, но не сразу. Я думаю, к осенней TeamLead в Петербурге, но могу ошибаться.

Про знания - как я писал, вопрос в уровне участника, который приходит за знаниями. Многим конференция знания дает - я это оцениваю по разговорам в кулуарах, а организаторы - по анкетам и другой обратной связи. Но да, это - не для топовых специалистов. Хотя знания по трендам и углублении контекста отрасли я лично - получаю.

Что касается сравнения с Software People, то фишка в том, что изменений в контексте отрасли, больше, чем углубления. При этом сейчас IT в России более-менее выровнен с мировым, а в тот период - выравнивалось, и потому шло сильное углубление понимания, которое давало концептуальные доклады. Как-то так. Можно об этом как-нибудь устно поговорить.

Александр Ларьяновский из Skyeng. Как и почему понимание языка заказчика влияет на доход разработчиков

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

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

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

Обсуждение в комментариях.

Андрей Шорин. Так и хотелось выкрикнуть с места: учитесь позиционной коммуникации, найдите в себе способность смотреть на ситуацию глазами другого!

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

Galina Sartan. Александр профи и практик, и отлично структурирует свои мысли. Брала у него интервью для своего канала об управлении персоналом. Очень ценные рекомендации дал для руководителей.

Максим Цепков. В вопросах - девушка из Касперского задавала вопросы из другой модели - там решили задачу по-другому, поставив между технарями и бизнесом системных аналитиков для перевода. Это - другая схема, какую выбирать - вопрос компании. У Касперского очень высокие требования к тех.скилам разработчиков, и найти таких с бизнесовым мышлением не реалистично совсем - поэтому аналитики, хотя промежуточное звено в целом усложняет конструкцию и снижает КПД. А у skyeng требования к разработчикам пониже, поэтому они пытаются без этого. Кстати, мы в свое время (лет 10 назад) решая аналогичную проблему у нас в компании тоже выбрали путь с аналитиками, потому что разработчиков, готовых глубоко вникать в бизнес заказчиков - очень мало.

Anastasia Totok. Максим Цепков давно же рынок пророчет новую профессию - переводчик между ит и бизнесом.

Alexey Vasilyev. Maxim Tsepkov вовлечённости хотят больше, а платить как обычно. Бизнес всегда хочет больше.

Egor Doronin. Maxim Tsepkov таких специалистов, кто и в инженерную и бизнес-деятельность одинаково хорошо умеет - исчезающе малое количество. Поэтому я спокоен за свою job security)

Максим Цепков. Anastasia Totok Переводчик между IT и бизнесом есть и называется Аналитиком (IT-аналитиком). Там есть еще специализации бизнес-аналитика (IT-бизнес-аналитика, BABOK и другие стандарты профессии) и системного аналитика, но реально границы специализаций в конкретных компаниях проводят очень по-разному.

Максим Цепков. Alexey Vasilyev Не совсем так. Во всяком случае в примерах Александра. Он хочет не вовлеченности ,а именно понимания языка бизнеса. И если ты за счет этого можешь решать задачи - то бизнес готов за это платить, в том числе кратно больше (ну, тут от задач зависит). И это явно было в докладе - освойте язык бизнеса и оплата возрастет сильно. Да, была оговорка что не во всех компаниях это так, есть old school подходы. Но это уже выходишь на рынок и ищешь. И находишь, потому что, как верно заметил Egor Doronin, таких спецов очень мало.

Дмитрий Вострецов. Вот тут как мне кажется похожее. Как человек вынудил разработчиков смотреть глазами бизнеса - https://t.me/RossNazarenko/327 + 2 следующих сообщения в канале.

Константин Кучугурин. Это огромная проблема. С командой нужно постоянно работать. Зарплату платят и норм. А как зарабатываются деньги компанией, мало кого интересует. И как его собственная работа сыграет на результат (и какой он вообще будет) ... да пофик

Максим Цепков. Константин Кучугурин Я об этом слышал много разных докладов на разных конфах. Если кратко: если понятно рассказывать про бизнес - то становится интересно. При чем независимо от того, есть ли прямая трассировка между успехами бизнеса и доходами, или такой прямой трассировки нет (но какие-то премии, разделение успеха при этом все равно должно быть). Но ключевое тут - рассказывать понятно, надо понимать этот понятийный разрыв и его сокращать. Потому что врубаться в непонятное - отдельные затраты для человека, и немаленькие.

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

Инна Ситникова. Это должна быть двухсторонняя работа по повышению осознанности подхода к разработке, а не только "пусть разработчики вникают в бизнес".

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

Yuri Veretelnikov. Верно подмечено, что разработчику и так норм. Судя по тому, что тимлиду платят всего на 10-20% больше при том, что он отвечает за работу 10+ сотрудников, бизнес делиться успехом не согласен, и такой руководитель, автономная единица ему особо не нужен, а нужен на самом деле - пилот корпоративной машины, который будет послушно жать на врученные педали и крутить врученный руль, а бизнес (на словах) постарается решить все "руководческие проблемы", от ресурсного обеспечения до карьерного трека и мотивации. Фактически, конечно, все это не решается, так что днём такая самоходная разработческая единица бегает по верхней палубе, вечером растыкивает тикеты за тех, кто "просто пришел кодить". А код? А код он по ночам фигачит, потому что обязанность по выработке с него никто и не снимал. Вопрос - точно после такого хочется на верхнюю палубу залезать? Есть альтернативные варианты - на удаленке работать на 2х работах, не вкладываться душой, но делать такой минимум, чтобы не выгнали - рынок такой, встречал это не один раз уже. Как думаете, где больше денег?

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

Yuri Veretelnikov. Maxim Tsepkov Спасибо за пояснение. Если у компании есть возможность организовать для команды подходящее операционное окружение, это хорошо.

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

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

Глеб Свечников. Maxim Tsepkov я не демонизирую, рассказал что наблюдаю. Тогда такой вопрос, а чем плох подход разделения ответственности когда есть бизнес, ТЗ и инженер? Когда никто не пытается лезть в доменную область другого, а всё общение строится на базе общего языка?

Максим Цепков. Глеб Свечников Ну, собственно, доклад и был о том, что общего языка - нет. Разработчики мыслят на своем, техническом, а бизнес - на своем. И агитация за то, чтобы разработчики осваивали язык бизнеса.

Aleksandr Kosolapov. Обычно, над разработчиком, который понимает/непонимает что требуется бизнесу еще слой менеджмента, который тоже должен что-то понимать. Если менеджмент понимает, то разработчики быстро перестраиваются. Если менеджмент не понимает, разработчику крайне сложно понять, либо что-то сделать понятое. Диктат обоюдный и комфортный. Особенно обостряет ситуацию то, что в ситуации непонимания у пытливых разработчиков есть склонность к сублимации в область оверинжиниринга системы.

Максим Цепков. Aleksandr Kosolapov Да, если менеджмент не понимает, что нужно бизнесу, но при этом активно управляет - ситуация тяжелая. Это встречается местами в крупных корпорациях. Призыв понимать бизнес в докладе был всеобъемлющ и относился ко всем уровням, не только разработчиков. А еще замечу, что в IT достаточно распространен другой варианте организационной схемы, когда разработчики напрямую работают с бизнесом, решая задачи, а их менеджмент обеспечивает чисто организационно-техническую составляющую - найм персонала, распределение по командам и т.п. Хотя явно это не проговаривалось.

Артем Расскосов из Skyeng. 9 кругов Канбана: от простой визуализации до эффективного процесса

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

Анна Абрамова из РБК. Agile: как мы переходили на гибкие методологии с неклассической структурой команд

Пост на FB Anna Abramova из РБК. Agile: как мы переходили на гибкие методологии с неклассической структурой команд. Рассказ про успешную Agile-трансформацию во времена эпидемии. Это разработка РБК, нагрузка пользователей выросла, разработка наоборот пошла в уныние, потому что пошли пожары. А бизнес ставил задачи по переходу от тушения пожаров к развитию, поставки новых фич. На старте была исторически сложившаяся конструкция - около 60 разработчиков в 10 командах на 30 технологически разнородных продуктов, обеспечивающих работу сайта и медиахолдинга в целом. Одни команды организованы по технологиям, другие - по продуктам, системы интегрированы и многие бизнес-фичи требуют доработок в нескольких системах. Анна определила стартовое состояние как "стихийный менеджмент", который достиг пределов своего развития и потому пора переходить к более регулярному менеджменту. И Agile для нее как раз и выступил как адекватный способ сделать регулярное управление.

Начала она с продажи руководству - управляемость, TTM, прозрачность, развитие большого числа продуктов. И обещала что эффект будет измеримым. Бизнес дал добро. А дальше надо было убедить команды, при чем исторически сложившиеся и поддерживающие систему - поэтому большинство состава надо было сохранить, никаких революций. Выгода команд - решения по техдолгу, по нехватке ресурсов, решение проблем разработки. По техдолгу - получилось согласовать с бизнесом квоту в 20%, исходя из накопленных рисков. Ресурсы - прозрачность Agile, процесс планирования реально показывал места, где ресурсов не хватает и позволил принимать обоснованные решения. А решение проблем - через ретро.

А еще были две болевые точки: взаимодействие бизнес-продуктов с проектным офисом, который проектировал решения и передачу из проектного офиса в разработку. Первая была решена через перевод задач из мессенджеров, звонков и другой ситуативной коммуникации в jira - чтобы требования были фиксированы и оставались следы. А вторую как раз решил Agile в минимальном объеме для разработки - планирование, синхро-встречи и ретро. Был трехмесячный пилот, в котором был проектный офис, тестирование - оно комплексное и 2-3 команды разработки, а после успеха - распространение на всех. В процессе было много проблем, которые выявляли и решали. Например, планирование - продуктов много, им пришлось участвовать в планировании всех команд, они взвыли из-за количества встреч. Это решили через проектных менеджеров, которые стали единым окном, собирали требования, урегулировали взаимные приоритеты. Функционально это Product Owner в Scrum, но термин "продукт" был занят за владельцем бизнес-продукта. Появилась техника груминга для декомпозиции сложных задач. затрагивающих много команд, с неоднозначными архитектурными решениями на задачи для отдельных команд. И так далее.

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

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

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

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

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

Пожалуй, на этом я закончу свой конспект доклада. История - интересная.

Михаил Грачев из Evrone. Взращивание культуры Open Source в компании: о чем не пишут в Интернете

Пост на FB Михаил Грачев из Evrone. Взращивание культуры Open Source в компании: о чем не пишут в Интернете. Open Source - хорошо, все используют. Возникает ситуация доработок, можно сделать fork - но там проблема merge новых версий. Поэтому продуктивнее pull request для доработок. И вот тут оказывается, что это вовсе не так просто, ты делаешь pull request, а его не принимают по разным причинам, часто без объяснений. После пары прецедентов желание контрибутить исчезает. А ошибки - относительно типовые, например, не соблюдение guide line, или разработка нового функционала без постановки issue, который еще должен быть одобрен как полезный продукту, или включение в pull request вместе с новой фичей какого-то рефакторинга - рефакторинг нужно делать отдельно, и еще согласовать - считают ли такой рефакторинг полезным.

Чтобы это решить, они сделали свой open source проект, который будет contribution friendly и на котором разработчики обучатся. Взяли dotenv-linter - хранение переменных окружения в текстовых файлов. И сделали на Rust - чтобы его можно было использовать во всех собственных проектах на разных платформах, и чтобы разработчики попробовали интересную им технологию, им было интересно работать с таким проектом наряду с основными.

Михаил рассказывал, что для этого нужно:

Реальная польза
roadmap
все по-английски
issue для задач
нужен входной guide line по технологии и пример для входа - потому что контрибуторами будут не знающие технологию
change log - видимость развития и труда разработчиков
Публично писать об участии в проекте.
Хороший readme по проекту - чтобы пользователи приходили и использовали
Логотип. Опционально, но привлекает
Пиарить проект для сообщества.

В целом у них получилось. Проект взлетел, набрал популярность, сейчас есть 70 контрибуторов, из которых внутри только 15, и они уже сами не пишут, а обрабатывают внешние pull request. И, кстати, понимают, насколько это может быть сложно - но по-прежнему объясняют контрибуторам, уже внешним, в чем те не правы. Но это получилось не сразу, и он отдельно останавливался на вопросах пиара и продвижения в профессиональном сообществе. И это - не единственный open source проект компании, есть и другие.

Компания помогает делать такие проекты - есть ответственные, которые научат и помогут начать контрибутить в open source, оплачивает часы, помогает продвижению, в частности писать и размещать статьи. Зачем это самой компании? Это HR-бренд и интерес разработчиков. И репутация для заказчиков, некоторым это важно. Окупаемость тут считать сложно, потому что конкретно этот проект используется другими проектами компании, эта библиотека, которую бы они и так делали, и тут сложно разделить затраты. Но в целом компания основана разработчиками, у которых изначально позитивное отношение к open source. Такая история.

В комментариях.

Oleg Sharov. У нас в Uploadcare богатая история работы с open source, и пишем свое, и контрибьютим. В обоих случаях дело не особо благодарное. В первом случае предлагаем библиотеки по интеграции с сервисом. Контрибьютеров не находим, похоже они рассматривают эти библиотеки как часть сервиса, поэтому пишут только о проблемах с интеграцией. Во-втором, отправив PR в любой из проектов, который мы используем в системе, сталкиваемся с правилами этого проекта (а они везде разные), и PR мурыжится годами. Там где мы участники проекта, конечно проще, но не похоже на коммерческое программирование.

Максим Цепков. Oleg Sharov Да, об этих проблемах тоже говорили. Проект, который приводили в пример, взлетел потому что он получился достаточно автономный и самодостаточный, не связанный с конкретными сервисами компании. А то что PR могут годами мурыжить по разным причинам - да, это звучало, Михаил давал рекомендации, на что стоит смотреть, чтобы этого не было, одна из них - сначала предлагаем фичу, а только потом - ее реализовываем - если приняли. И все равно, есть кейсы, когда это отвергается, в том числе, по политическим соображениям: держатели проекта считают неправильным поддерживать Россию...

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

Александр Поломодов из Tinkoff. SOLID'ный тимлид, или Основы менеджмента для технарей

Пост на FB Александр Поломодов из Tinkoff. SOLID'ный тимлид, или Основы менеджмента для технарей. Взгляд на команды и сотрудников через принципы ООП - абстракцию, инкапсуляцию, наследование и полиморфизм, и SOLID-принципы - single responsibility, Open/Close principle, Liskov Substitution, Dependency inversion/Inversion of control. Техническая формулировка, переформулирование для менеджмента, примеры из жизни, и про нарушение принципов и при их восстановление. В целом любопытно, как всякий альтернативный взгляд, он расширяет представления и позволяет лучше понять разные аспекты.

В докладе был интересный пример про Архитектора - две карьерные траектории, для Разработчика и для Системного аналитика заканчиваются одной и той же позицией Архитектора. И дальше это вызывает проблемы, так как мы имеем неполное наследование: Архитектору из аналитиков часто не хватает технических разработческих скилов, а архитектору из разработчиков - навыков общения с Заказчиком. И взгляд через ООП говорит, что? раз так, то это должны быть разные позиции - software architect и solution architect - и тогда оно сходится.

В комментаниях.

Olga Tsyganova. По мне так лучший доклад конфы. Как про закон Конвея, только про солид:)

Максим Цепков. Olga Tsyganova Как метафора "а давай те так подумаем" - оно любопытно, а вот в практическом залоге что это сопоставимо с законом Конвея - я сильно не уверен. Для этого нужна репрезентативная выборка... Хотя отдельные иллюстрации, например, про архитектора - интересны.

Olga Tsyganova. Максим Цепков ну да, выборка нужна хоть какая-то)

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

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

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

— Максим Цепков • 16:48, 3 мая 2021 • нет комментариев

2021-05-03: TeamLeadConf - почувствуй разнообразие культур компаний вживую