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 - процессы выбирает сама команда. А сами команды - распределенные и многие удаленные, включая тимлидов.