Интересное в мире

2018-10-01: Опубликовано видео моего семинара по Agile и бирюзовым организациям 27.09 в Открытой школе бизнеса

Макс Цепков - блог - пн, 10/01/2018 - 13:10
Пост на FB

Благодаря оперативной работе Сергея Федорова запись моего семинара Гибкость, эффективность и вовлеченность: как их получить методами нового менеджмента (семинар в Открытой школе бизнеса 2018-09), который прошел в четверг 27.09 уже доступна на youtube, ссылка есть на странице доклада http://mtsepkov.org/NewMng-OBS-2018-09 у меня на сайте. К сожалению, на записи совсем засвечены слайды, поэтому следить надо самостоятельно по презентации, которая выложена там же. Я надеюсь, получится сделать монтаж вместе со слайдами, но для этого нужно время, поэтому пока опубликовал как есть.

Категории: Интересное в мире

2018-09-28: TeamLeadConf в Петербурге - актуальная повестка управления командами в IT

Макс Цепков - блог - пт, 09/28/2018 - 17:44
О других конференциях

24-25.09 в Петербурге прошла Saint TeamLeadConf - вторая из серии конференций для тимлидов команды Олега Бунина. Первая была в феврале в Москве, и я рад отметить, что качество конференции в Петербурге оказалось столь же высоким. Два дня очень насыщенных докладов, показывающих актуальную повестку управления командами в IT, включая лидерство, мотивацию и развитие персонала.

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

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

И, в частности, отмечу, что использование метрик для процесса и оценки команды, включая softskill является уже повседневным инструментом, при этом люди активно конструируют собственные наборы метрик с учетом специфики конкретной компании, подразделения или проекта. Используя при этом различные источники и литературу, но именно конструируя на их основе, а не механически перенося к себе прочитанное. И это делают тимлиды, а не только менеджеры высокого уровня или профессионалы из HR. Отмечу, кстати, что применяется термин "метрики" или "показатели", а не "KPI", потому что "KPI" достаточно сильно коннотирует с механическим использованием показателей для расчета зарплаты или оценки персонала и эта коннотация обесценила термин. При этом в IT такой механический расчет зарплаты точно не применим. Метрики и показатели должны оценивать здоровье команды и разворачивающихся процессов, сигнализировать о проблемах, а не служить однозначной оценкой.

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

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

Впечатляющая картина организации процесса вокруг ценностей была в докладе Евгения Пешкова из Додо-пиццы. Их пока немного, 60 человек и они рассчитывают, что LeSS, который они используют, позволит им управлять до 200-250 человек. А Юля Курапатенкава из Spotify рассказывала о структуре, которую они строят для компании, в которых счет племен из 100-200 человек сильно превышает десяток - появляется достаточно сложная структура. Подробнее об этом можно прочесть дальше, в моих заметках по докладам.

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

Дальше будут мои заметки, которые я публиковал во время докладов. Отдельно отмечу, что в них - только пловина докладов конференции, потому что она идет в два трека. И мне часто хотелось пойти на оба параллельных доклада. Так что не надо думать, что мои заметки показывают все содержание конференции. А еще я хочу поблагодарить Олега Бунин за высокую оценку заметок: "Если хочешь быть в курсе деталей лучших докладов самых крутых IT-конференций - подписывайся на Максим Цепков, его конспекты мы неоднократно использовали в своей работе!" А еще - пожелать дальнейших успехов Олегу Бунину и всей команде конференции!

Заметки с докладов

Пост на FB Yuliya Kurapatenkava Spotify. Превосходный рассказ про устройство spotify изнутри и его эволюцию в процессе роста. Рассказ на английском, потому что многие термины не переводятся на русский. И этот подход - правильный, в начале был словарь терминов, тоже по-английски, и эти объяснения вносят важные акценты, которые не сохраняются в переводных описаниях, которые я читал.

Они масштабируются, и структура реально сложная и многоуровневая:

  • Squad = кросс-функциональная команда-группа
  • Chapter = функциональное подразделение-сообщество, из разных команд-скводов
  • Tribe = большая продуктовая команда (100-200), имеющая mission
  • Alliance = несколько трайбов, работающих на бизнес-миссию компании
  • Mission = consumer mission - на core clients несколько альянсов/племен
  • business unit == свежая реорганизация, новый уровень из-за роста, supported by metrics
  • guild - сообщество по интересам или по знаниям, поперек всего

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

Для координации работы - многофокусное управление по целям, которое ведут разные лидеры:

  • chapter lead - синхронизация скводов по общему направлению
  • agile coach
  • technical owners
  • leadership team gives direction
  • mission leads align product

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

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

Кстати, энтропия - играет. Доклад был по скайпу - Юля заболела и не смогла приехать. В начале доклада связь вырубилась, была пауза. И в ходе ответов на вопросы ряд критических фраз пропадало. Следуя за Стругацкими (За миллиард лет до конца света) это свидетельствует о ценности доклада.

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

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

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

Договоренности срываются. Внезапно и на финише. Виды срывов: провал, формальное выполнение, подмена. Но мы не всегда регистрируем это как сорванную договоренность.

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

Каждодневный контроль требует много времени. И плохо работает в IT - он вымрет.

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

Мощная метафора: разработчик как бизон. Уздечки не существует, он должен хотеть пойти в нужном направлении.

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

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

Пост на FB Александр Зиза Коммуникации. Национальная коммуникация. Вокруг - мир.

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

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

Принципы эффективной коммуникации.

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

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

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

Психология: любое предложение прежде всего рассматривается с точки зрения "а не служит ли оно целям моей эксплуатации". Книга "Человек и ситуация".

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

Тренинг по продажам для разработчиков. В результате разработчики научились торговаться за сроки выполнения задачи. А в замысле было совсем другое :)

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

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

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

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

Пост на FB Jane Goleva Обучение в IT. Схема.

  • Проблемы заказчика.
  • Результат заказчика. Решает ли он проблему, Фокусировка скоупа.
  • Аудитория - следует из результата.
  • Проблемы аудитории - почему она действует так, что у Заказчика проблемы. Надо найти мотивацию для решения проблемы. Решит ли их лекция.

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

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

Пост на FB Alexey Kataev. Метрики команды. Skyeng 2015 - он один из 5 разработчиков. Сейчас - 15 команд и 68 разработчиков. И все работают удаленно. Одна команда была сапсаном, которая везла в прод. А сейчас есть вопросы.

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

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

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

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

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

Пост на FB Max Babich. Управление знаниями через модели компетенций. Прикольное и содержательное введение в работу компетенциями на примере фильма Матрица, когда Тринити и Нео планировали с Пифией как вытащить Морфеуса.

Оценить уровень владения. Баллы, простые уровни. Чтобы не запутаться :) Например: не знаю, слышал, есть теория, есть практика. Хотите запутаться - добавьте "могу обучить"  :)

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

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

Да, чтобы компетенции оценивать - надо иметь матрицу компетенций, ее надо создать. В докладе ссылок не было, но я знаю минимум одну развивающуюся систему, которую можно использовать для старта https://sfia-online.org Еще есть российские проф.стандарты, но они гораздо менее удобны.

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

Пост на FB Светлана Новикова и Константин Кафтан - очень интересный доклад про матрицу компетенций из одной компании но двух совершенно разных подразделений: одно на техподдержке, другое - разработка на Lua, которые работают в разных business unit. И общая канва наполнена сильно разными примерами, которые как раз позволяют оценить спектр возможных путей, показать их разнообразие. В команде Lua разработчикам нужна знать бизнес-предметку, и они погружали нового человека полгода, а хотелось - быстрее. Составление матрицы компетенций в результате позволило сократить этот срок до 2 месяцев, пересмотрев программу подготовки и выделив core-часть. А еще - нашли энтузиастов и драйверов по разделению знаний, и только 1 из 40, кто не хотел делиться своими уникальными компетенциями. И, совершенно неожиданно, нашли профит для кодирования: функционал, который надо вынести в серверные библиотеки и не изобретать велосипеды.

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

А по фактуре - они небольшие, 60 человек, у них сейчас LeSS, который обеспечивает организацию, и они полагают, что до 200-250 человек он потянет. Они быстро растут вместе с компанией, это период по Адизесу называется "Давай-давай", когда результативность важнее эффективности, и на стоимость процесса не сильно обращают внимание. Много практик XP, очень любят парное и коллективное программирование, особенно для функционала, который делается "по-новому" - чтобы все понимали реализацию. Общее владение кодом. Обязательна работа в полях - в пиццериях, на кухне и курьерами, используя свои приложения и понимая все косяки, и это - общий подход в Додо для всех руководителей тоже.

В комментариях состоялось интересное общение и Димой Безуглым.

Дмитрий Безуглый Максим в этой компании катострофически не зрелая разарботка. Для понимания - 5 или 6 полных остановок обслуживания всех клиентов менее чем за 2 года. Уход в рефакторинг на год и опять падение ... При этом нагрузочное тестирование еще в процессе запуска …. А о супер культуре Agile компания трубит уже года 2 или 3.
Поэтому было бы хорошо добавить к этим ценностям Честность(хотя бы самим с собой).
P.S. Не буду указывать событие и честного человека, который рассказал о ситуации с трибуны без прикрас. Потому что что то мне подсказывает что в дивном мире честным людям не здоровится.
Евгений Пешков И честны, и открыты. Видим проблемы и точки роста.
Дмитрий Безуглый Евгений Пешков Исходя из имеющихся публичных фактов текущая культура больше похожа не на дивный мир, а на мир "Чипа и Дейла". На предмет честности и осознанности. В докладе рассмотрено как текущая культура привела к весеннему "военному положению" ?
Евгений Пешков Нет, не рассмотрено. Считаю, что не культура привела, но именно культура помогла преодолеть.
Дмитрий Безуглый Евгений Пешков Культура компании и разработки не может быть не связана с такого масштаба фейлом. С точки зрения аудитории это сокрытие информации. Это Не Честность в том числе с собой. В целом это хорошая тема ( о влиянии культуры) для обсуждения.
Максим Цепков Дима, а мир Чипа и Дейла ведь дивный :) И его увидеть в реальности, а не мультике - довольно неожиданно.
Та культура, которую я услышал, действительно несет риски описанных тобой провалов, и она же позволяет с ними справиться, тут две стороны. При этом я не думаю, что Евгений или Додо в целом - НЕ честные. Связь культуры с рисками описанных ситуаций может быть не очевидна для всех. И при этом могут срабатывать психологические механизмы, уводящие проблему в слепую зону. Но, я думаю, Додо справится.
Дмитрий Безуглый Максим Цепков Мир "Чипа и Дейла ", должен быть там где ему место - в безоответсвенном детстве )))

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

Максим Цепков Дмитрий Безуглый Тут мы с тобой не сходимся в mindset. Я в свое время очень близко принял тезис о том, что детство - это время прекрасных приключений, и это отношение стоит сохранять и во взрослом мире, не переходя к скучной серьезности. Ребенок - ответственный, просто ему не хватает знания устройства мира, но неправильно, когда увеличение этого знания снижает непосредственность восприятия жизни.
А обесценивание этого через образ "слабоумие и отвага" (у Димы была картинка в коменте) придумали поскучневшие взрослые, завидующие этому. Это к ним обращался Мюнхгаузен в фильме "Улыбайтесь, господа! Все глупости на свете делались с серьезным выражением лица!"
Если по фактуре, то по впечатлению от моего общения с Евгением с инженерными практиками обеспечения качества, в частности тестированием, у них - в порядке: они знают и понимают их место. И их гипотеза о том, что инциденты - это проявление проблем быстрого роста вполне может быть справедливой.

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

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

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

Пост на FB Евгений Кот. Рассказ о ситуации, когда ведущий разработчик становится тимлидом и становится несчастным - и как с этим справиться. Был роскошные перформанс под музыку о том, как наступает Адъ. Наваливаются совсем другие дела, а потом ты слышишь от разработчиков "Зачем ты смотришь код, ты же его уже не пишешь...".

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

Дальше были антипаттерны тимлидов, которые часто проявляются в жизни "сами собой". Такие тимлиды руководят, но являются тупиком в смысле развития. И они подробно разобраны, почему это так, и как именно можно иначе. Советы начального уровня - ограничь или исключи технические работы, это теперь не твое; структурируй работу; ограничь синхронные взаимодействия и открой канал асинхронных; прочти Дорофеева про time management.

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

Пост на FB Тимур Павлов, Positive Technologies. Рассказ о том, как выпуская года назад релиз они не уложились в сроки на 2 месяца. Анализ показал, что много времени ушло на исправление багов, и разработчики не успели сделать функциональные фичи. Из этого были извлечены уроки и Тимур рассказывал о пути, который они прошли за два года, внедренных практиках и решенных проблемах - там было несколько этапов процесса.

Пост на FB Серёжа Попов. Рассказ о компании, которая действует как школа обучения. Берут студентов-джуниоров, прогоняют их через проекты, они через 2-3 месяца выпускаются, приходят следующие. Делают верстку. В команде 3 джуна, тестировщик и наставник, они делают проект, 15 проектов сейчас. Начинали с другой структуры, и тестировщик появился не сразу. В управлении еще есть руководитель проекта, который снимает с Сергея часть задач, и тимлид команды наставников. В целом успешно развиваются.

Они не не зависимы, а ассоциированы с html-академией. Но работают как отдельный бизнес по экономике.

Любопытен список проблем у джунов, который они выявили и решают.

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

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

Из уроков: что нельзя делать:

  • Доверять, но не проверять
  • Бросать все на плечи джуна и думать, что он сам вытянет
  • Относиться к джуну, как к мидлу
  • Брать джуна работать бесплатно
  • Использовать только кнут (воспитательные беседы), надо хвалить и интерес делать

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

В общем "тяжело в учении - легко в бою" здесь работает.

Пост на FB Виктор Никишин из tinkoff.ru рассказывал про то, как они выделяли тимлидов из мидл-разработчиков. Интересно, что они во многом переоткрыли разделение ответственности менеджера в Scrum на Product Owner и Scrum Master, компетенции тимлида - не в hard skill, а в soft skill. Однако, они использовали другую модель - стили руководства Адизеса, и посмотрев на потребности пришли к тому, что тимлид должен иметь компетенции AI, а не PE, и именно так выбирали кандидатов. В целом - успешно, за полгода получилось, начав с команды в 10 человек получить 7 команд, в которых только один тимлид пришел готовым, остальные выросли внутри. При этом процессы в командах разные: Scrum, Kanban, Scrumban, без Agile - процессы выбирает сама команда. А сами команды - распределенные и многие удаленные, включая тимлидов.

Категории: Интересное в мире

И. Стюарт. «Математика космоса». Глава из книги

newtonew научпоп - ср, 09/26/2018 - 04:31
Имеет ли распределение планет нашей системы какое-то математическое обоснование? Или они могли в принципе расположиться вокруг Солнца любым желаемым образом, на любых расстояниях? В этой главе автор рассуждает о закономерностях в расположении и движении планет и об их математическом и физическом объяснении (например, о правиле Тициуса — Боде). Что представляют собой эти законы — совпадение, проявление какой-то неизвестной закономерности или то и другое одновременно?
Категории: Интересное в мире

2018-09-22: Фокусы поддержки кроссфункциональной команды

Макс Цепков - блог - сб, 09/22/2018 - 09:22

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

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

Итак, фокусы поддержки.

  1. Эффективная коммуникация в группе. Умение слышать и слушать друг друга, во-время убирать эмоции. Здесь работают различные техники фасилитации, и, в целом, эти практики достаточно проработаны. Хотя распространенность их далеко не такая хорошая, как хотелось бы и эффективность совещаний во многих компаниях оставляет желать лучшего. При этом одного фасилитатора недостаточно, компетенция должна быть у большинства участников команды.
  2. Умение действовать командой, продвигаясь к общей цели. Здесь работают техники тимбилдинга и командообразования, проведения команды по пути от группы до команды. Здесь модели и практики тоже проработаны. Но в современных условиях есть несколько «но».
    • Большинство подходов рассчитаны на то, что команду притирают достаточно долго, месяц-другой, а потом она долго и эффективно работает. И раньше было все хорошо — были длинные проекты. А теперь все больше коротких проектах, на пару месяцев, а то и на пару недель. При этом команда над ними должна работать совместно, желательно как команда, а не группа, с синергетическим эффектом от совместного творческого решения задач.
    • А еще подходы рассчитаны на стабильную команду. А даже в проектах, которые идут год и более, состав команды часто меняется. Не кардинально, но кто-то приходит, кто-то уходит, это — рабочий процесс. В теории после этого команда вываливается в storming, а на практике это не допустимо, потому что время performing становится слишком маленьким.
    • В современных командах появляются люди с неполной занятостью, которые, тем не менее, несут необходимые компетенции. И чем дальше, тех их будет, по-видимому, больше — а во всех теориях этот фактор выступает как крайне нежелательный.
  3. Достаточный набор компетенций в группе. Это как раз вопрос формирования состава команды, и хотя в теории это вообще не является проблемой: выпиши нужные компетенции, и привлеки людей, практически тут далеко не так просто.
    • Если собирать людей для того, чтобы покрыть всю функциональную область сложного междисциплинарного проекта, быстро оказывается, что нужно очень много людей, нарушается предел эффективных коммуникаций в 7-9 человек. А еще надо ведь обеспечить кроссфункциональность команды, то есть работоспособность ее в ситуации, когда кто-то из участников заболел или ушел в отпуск. Теоретический выход — включайте только ключевых — не слишком реализуем на практике. Практический подход — сложно структурировать команду проекта, выделять ядро и ассоциированных участников, и по-разному организовывать взаимодействие, учитывать это в командообразовании.
    • Надо проверять не только функциональную полноту компетенций, но и использовать другие ролевые модели, например, модель Белбина, фиксируя провисающие или конфликтные фокусы, ослабляющие команду и предпринимая действия для их компенсации. При этом использовать критерии хорошей команды по Белбину в условиях дефицита квалифицированных сотрудников, скорее всего, не получится, надо именно предусматривать компенсирующие механизмы.
    • Парадоксальный вывод из дефицита квалифицированных сотрудников: большинство проектов будет выполняться некомпетентными командами. Компетентные люди могут быть — но они, с большой вероятностью, предпочтут знакомым задачам другие проекты, которые несут для них вызов. В лучшем случае они доступны частично, как эксперты. Такая вот ситуация. Отмечу, что Agile-подходы это могут обеспечить, потому что формировались именно в таких условиях: с появлением персоналок резко выросла потребность в разработчиках софта, а подготовка специалистов не увеличилась, и разработку пришлось вести некомпетентным командами. С этим Scrum справился. Это — на Западе, в России в это время куча народа из разваливающейся оборонки пришли в IT, и это компенсировало ситуацию
  4. Совместное мышление, обсуждение и выработка решений в условиях, когда различные участники команды имеют собственные онтологии и картины мира. Здесь речь идет не о коммуникативных навыках, а об умении быстро строить онтологии и участников коммуникации и «переводить с русского на русский». Фасилитации тут недостаточно, необходимо разбираться в содержании обсуждаемых вопросов, потмоу что каждый говорит из своего профессионального контекста. Типичный пример — коммуникация между менеджером, отстраивающим процессы исполнения заказов, и маркетингом, озабоченным удовлетворенностью клиентов и репутацией компании — они говорят на разных языках. Если к ним добавить еще юристов, бухгалтеров и службу безопасности, то можно представить себе спектр различий в моделях мира. Профессиональные компетенции в этой области есть у IT-аналитиков, и есть даже подход Domain Driven Design, в котором как обязательная часть предполагается построение единого языка проекта, с сопряжением его с другими понятийными системами и онтологиями. Есть также современные подходы у философов-рационалистов или в системном мышлении. И в команде должна присутствовать эта компетенция, желательно у нескольких участников.

На этом все. Сама встреча была интересная. Сообщество очень живое, профессиональное и хорошего уровня, а встречи проходят в неформальной обстановке, с активным общением участников и работе в группах. Меня позвали как эксперта, но формат предполагает не монологи экспертов, а активное включение их в работу групп. Для себя, помимо общего знакомства с сообществом и многих мыслей я вынес ссылку на книгу Six Simple Rules о работе со сложностью и модель хорошей команды, на краткое описание которой обещали позднее прислать ссылку с авторством :) Я попробовал ее быстро найти по запомненному контексту, не получилось, зато наткнулся на сайт, где командообразование достаточно систематично изложено и характеристики команды похожи на те, что рассказывали (но их сильно больше, и это снижает ценность).

Так что спасибо организаторам за приглашение.

Категории: Интересное в мире

Л. Подымов. «Псевдонаука». Глава из книги

newtonew научпоп - чт, 09/20/2018 - 02:31
Подкреплены ли ваши доказательства обширной статистикой? Статистика может оказаться как хорошим подтверждением, так и хорошим способом ввести в заблуждение. В главе подробно разбирается этот мощный исследовательский инструмент и его роль в разных областях науки.
Категории: Интересное в мире

2018-09-19: с 22.09 и до 30.09 я в Петербурге - много мероприятий и общения

Макс Цепков - блог - ср, 09/19/2018 - 11:46
Пост на FB

Всем питерцам и петербуржцам, кто меня читает. С этой субботы я буду в вашем городе до следующего воскресенья, и у меня много публичных мероприятий. В субботу 22.09 - на конференции Точка сборки у СПб СоА (Сообщество аналитиков Санкт-Петербурга), где буду говорить о развитии аналитиков, в понедельник-вторник 24-25.09 - на конференции Saint TeamLead Conf с рассказом о практиках бирюзовых организаций для IT, в среду 26.09 - читаю благотворительную лекцию по Спиральной динамике в Лекторий тут рядом, в четверг 27.09 - провожу бесплатные семинар по новым методам управления в Открытая Школа Бизнеса и лекцию по сравнению Agile, игрофикации и бирюзовых подходов в Точка кипения - Санкт-Петербург.

Приходите, будем общаться. И, несмотря на насыщенную программу, меня можно зазвать на другие мероприятия или просто встретиться.

Категории: Интересное в мире

Вход на сайт