Что такое команда?
Начнем с того, что сформулируем определение команды:
- Команда – это небольшая группа людей ( от пяти до девяти человек);
- С дополняющими навыками – это не просто куча 1С-программистов, а аналитики и другие люди с различными навыками, которые нужны для того, чтобы добиться общей цели;
- С общей целью;
- Стремящаяся улучшить свою производительность;
- И чувствующая ответственность по отношению друг к другу.
Если что-то из этого вашей команде не подходит – у вас не совсем команда.
Нужна ли командная работа на самом деле, какую ценность она несет?
Сейчас очень много шума на тему того, что надо работать в команде и т.д. Но само определение команды – спорное. Почему командная работа лучше, чем просто куча народа, которая пишет код? Я попробую дать свой ответ на этот вопрос, а вы посмотрите, как это выглядит.
Варианты командной работы
Смысл в том, что если вы хотите донести какую-то ценность до вашего конечного пользователя и заказчика, вам нужно, чтобы разные люди сделали разную работу. Если мы говорим про проект автоматизации какого-то бизнеса, то это, чаще всего:
- Инженер-программист, без которого не обойтись;
- Тот, кто проверяет работу инженера-программиста. Обычно это тестировщик. По идее, это не должен быть заказчик, хотя я знаю, что в мире 1С все устроено по-другому;
- Тот, кто думает, что и как именно нужно сделать – обычно это аналитик или представитель заказчика/сам заказчик.
У нас есть три таких человека, и ими можно управлять по-разному.
Функциональная организация
Если вы находитесь не в компании, которая разрабатывает программное обеспечение, а, например, в какой-нибудь крупной Enterprise-корпорации, то вполне возможно, у вас будет такая структура – три отдельных подразделения:
- Отдел бизнес-анализа;
- Отдел разработки;
- И отдел тестирования.
Как выглядит процесс управления такой структурой?
- Менеджер проекта выбивает ресурсы – он бегает по разным подразделениям и говорит: «Дайте мне человека».
- Задачу этому человеку ставит начальник его отдела.
- Командной работы нет по определению – это просто люди, которых координирует менеджер проекта.
- Время, потраченное от начала работы до конца работы получается очень большое, потому что координировать нужно долго.
На слайде показана классическая картинка из книги Джеральда Вайнберга. Красным цветом представлены потери времени, которые возникают, если вы находитесь на пяти проектах одновременно.
Какая здесь основная проблема?
Поскольку в функциональной организации задачи распределяет соответствующий руководитель, то один специалист одновременно оказывается на большом количестве проектов. Он вполне может быть загруженным на 30% по одному проекту, на 15% по-другому и т.д. В результате производительность такого специалиста падает. И основную долю будут занимать потери времени.
Проектная организация
А что будет, если мы попытаемся ускорить этот процесс? Мы можем попробовать собрать единую команду, где задачи раздает руководитель, тимлид. Это может быть временная команда, которая на 100% занимается этим проектом, пока он не закончится. Там понятие команды уже имеет смысл, потому что у этих людей действительно общая цель, они действительно могут чувствовать ответственность по отношению друг другу и т.д.
- Допустим, у вас в команде 7 человек. Шесть разработчиков (два 1С-разработчика, два фронтэнд-разработчика какого-нибудь портала, два тестировщика) и вы – их руководитель. Чтобы добиться итогового бизнес-результата, ваши подчиненные должны делать свои задачи последовательно.
- И вот вы хотите поставить им задачу и проконтролировать ее выполнение. На какой срок можно комфортно ставить одну задачу? Один день – тяжело. У вас 6 человек, это огромный объем работы по коммуникации и координации. Большинство менеджеров ставят задачу примерно на 3-5 дней. А потом в конце нужно проконтролировать ее выполнение. В результате срок реализации подобной работы получается минимум 9 рабочих дней.
- А если учесть, что таких задач много, они прилетают с разных концов и все время конкурируют друг с другом за внимание, то на практике это растягивается примерно до 2-3 недель.
Так можно делать только приоритетные задачи. А задачи среднего приоритета при такой организации работы будут сильно растягиваться по времени из-за того, что их будут выбивать приоритетные задачи.
Agile-команда
Смысл Agile-команды в том, что мы пытаемся все это еще больше «зажать».
- Мы говорим – давайте сделаем это еще быстрее.
- Процессом управляет скрам-мастер, но фактически координацией работы занимается сама команда.
- Задачи в Agile распределяются на временные промежутки длительностью примерно по одному дню.
- Каждый знает, кто чем занимается и может просто сам подойти к нужному человеку и сказать: «Мне кажется, что-то не работает, давай вместе подумаем, как это наладить».
- И скорость (от момента, как мы начали делать задачу для заказчика до момента, когда мы ее завершили) еще больше увеличивается. Скорость очень важна. Чем быстрее мы будем делать задачи и выводить их на заказчика, тем ниже вероятность, что требования за это время изменятся. Мы называем это периодом полураспада требований – пока вы их выполняете, они успевают немного «загнить». Надо быстро все это выводить в продакшен, пока они еще «горячие». Тогда потеря производительности будет меньше и «провалить» проект будет намного тяжелее.
Выглядит это примерно вот так. Внутри команды каждому отведена разная роль и каждый изо всех сил старается работать эффективно в течение одного короткого спринта. В этом смысл Agile-команды.
Классический тимлид vs скрам-мастер
Что произойдет, если мы в такую команду поставим классического тимлида, который будет ставить задачи и контролировать их выполнение?
- Он быстро становится «узким местом».
- Времени нет, очень маленький промежуток времени, трудно сбалансировать работу. Например, в этом спринте (в этом промежутке времени) у вас много работы на 1С-разработчике. А у фронтэнд-девелопера мало работы. Что он вам скажет как тимлиду? «Я никому помогать не собираюсь, я знаю свою конкретную работу, а в 1С ничего не понимаю и даже смотреть туда не хочу». В итоге получается низкий уровень взаимопомощи в команде.
- Еще одна проблема в высокодинамичном проекте – в отпуск уйти практически невозможно. Выпрыгиваешь из проекта – все начинает рушиться.
У скрам-мастера другая задача. Его задача – построить процесс, выстроить крутую, эффективную команду. Парадигма здесь меняется. Классный менеджер – это не тот человек, который может решать проблемы, а тот, кто может построить крутую команду, потому что крутая команда эффективно решает проблемы. Фокус смещается.
Как формируется команда
Это – известный график Такмана о том, как формируется команда.
- Когда вы собираете команду – это просто кучка людей, они формируются. Это – фаза Forming, когда вы друг друга еще не знаете, общаетесь друг с другом экстремально вежливо. Кто пришел недавно в компанию, может быть, помнит. «Не будете ли вы так любезны быть так добры». Письма друг другу пишут, хотя рядом сидят. «А почему ты голову не повернул, у него лично не спросил?». «Я думал, он занят» и т.д. Такого типа вещи. Это проходит довольно быстро, в течение недели-двух.
- А через неделю или две вы реально понимаете, что код – говно, девелоперы – тупые, архитектура – отстой, менеджер – дебил, заказчик – идиот. И есть только один человек, кто может все исправить. Кто? Ты сам, правильно? Ты же знаешь, как это сделать. И представь, таких – шесть человек. Когда они разговаривают, они друг друга не слушают. Эта фаза называется Storming, она, слава богу, проходит.
- Следующая фаза – это Norming. Потому что ты со всеми ругался-ругался и, наконец, понял кто чего стоит, кто круче, кто не круче, внутри выстроились социальные связи. И здесь начинается доверие и, возможно, консенсус. Люди умеют договариваться на этом уровне. И дальше, по Такману, производительность команды растет в бесконечность.
Как можно постоянно повышать эффективность?
Считается, что в среднем по индустрии скорость написания кода – это 100 строк в день. Да, есть производительные дни и дни, когда вы ничего полезного не сделали, но в среднем получается 100 строк кода и это ускорить невозможно – не существует способов мотивировать человека писать быстрее. Если человек вышел на свой нормальный уровень, больше он уже не напишет. Как же можно вывести производительность команды в бесконечность? За счет чего?
Если вы будете делать то, что нужно, и не делать то, что не нужно, тогда с точки зрения заказчика производительность будет высокая, даже несмотря на то, что вы ни одной строчки кода не написали. Вроде всем понравилось, все говорят – классный результат.
Было бы здорово, если бы мы с первого дня умели правильно делать нужные вещи. Но сначала нам нужно научиться. Нужно постоянно прокачивать свою команду, чтобы она повышала свою производительность с помощью цикла, который называется Plan-Do-Check-Aсt (цикл Деминга).
- Слева показан классический цикл Деминга, как он должен выглядеть:
- Мы сначала что-то планируем;
- Потом делаем;
- Потом проверяем, получилось или нет.
- А потом нам нужно заложить время, чтобы что-то улучшить.
- Но часто у нас нет времени что-то улучшать, потому что много других задач. И из-за этого никакое повышение производительности получить невозможно. Бывает так – надо срочно, быстро, изо всех сил, некогда думать, надо делать. В результате получается, как справа. Есть такие проекты, я в них даже сам участвовал и даже в качестве заказчика.
Цикл Деминга – это та вещь, которая действительно работает на повышение эффективности команд. Надо просто остановиться и подумать, всем вместе поговорить на эту тему.
- Ты спланировал;
- Сделал;
- У тебя не получилось;
- Почему, как ты думаешь?
- Наверное, потому что мы делаем не то, что нужно заказчику – давайте спросим у заказчика, как сделать то, что ему нужно.
- Или мы нашли не тех стекхолдеров – давайте найдем правильных стекхолдеров.
Но что же нужно, чтобы цикл Деминга работал и команда постоянно повышала свою производительность?
- Первое – вам нужна общая цель. Это, наверное, самая важная вещь, без этого вообще ничего не будет.
- Если у одного человека в команде задача сделать классный продукт, а у другого – уйти пораньше домой (противоположные цели), понятно, что договориться о чем-либо невозможно.
- Если эта цель явным образом не сформулирована или хотя бы не понимается правильно всеми одинаково, появляется еще одна беда – у всех свое представление. Поэтому, когда мы обсуждаем, что лучше, люди иногда говорят страшные с моей точки зрения вещи. Например: «а мне так удобнее». А как нужно с точки зрения достижения конечной цели? Чтобы это понимать, мы должны сначала для себя эту цель сформулировать.
- Следующая вещь, которая в Scrum есть в виде коротких спринтов в недельных планах – это наличие Challenges – вот таких коротких целей, к которым мы бежим. Без этого очень тяжело. Я вообще не понимаю, как в России работают проекты с длинными дедлайнами. Для меня это, например, никогда не работало. Когда я еще не знал про Agile, у меня в команде был разработчик, который, когда его спрашивали «что там с проектом», говорил: «да еще же два месяца, за это время можно Windows написать». Нет ощущения, что зима близко, что надо уже что-то делать, кажется, что времени много. Поэтому должны быть короткие Challenges (вызовы), когда мы себе ставим конкретную понятную цель. В Agile это достигается просто спринтом. Если вы не в Agile-команде, просто придумайте себе короткий, понятный дедлайн, который разделяет вся команда и старайтесь его добиться.
- Нужна постоянная обратная связь, мы должны спрашивать заказчика – это то, что нужно или нет. Потому что иначе у нас нет топлива для команды, команда не знает, как себя улучшать.
- И четвертый пункт – он, с моей точки зрения, самый важный, это дисциплина. Если у нас нет дисциплины, мы принимаем решения, но их не придерживаемся. Почему? Потому что концепция в голове уже поменялась. Вот эту дисциплину должен обеспечивать скрам-мастер.
Примеры обратной связи
Давайте поговорим про обратную связь. Мне очень нравится пример Пола Инглиша из компании KAYAK. Он говорит:
«Я купил красный телефон с громким звонком для нашего офиса. Всякий раз, когда пользователь набирает номер поддержки на нашем веб-сайте, этот телефон звонит. Сперва инженеры жаловались на него. Они говорили: “Как раздражает эта чертова штука». И я отвечал: “Есть действительно простое решение: отвечаете на чертов телефон и делаете то, что осчастливит пользователя!”».
С обратной связью бывают проблемы. Особенно в крупных организациях, когда разработкой продукта занимается одна команда, а поддержкой – другая. У разработчиков в голове всегда какой-то «космос», они в большинстве случаев имеют абсолютно странные представления о том, как конечные потребители используют их продукт. Мы иногда посылаем их к пользователям посмотреть, как те работают. В результате, разработчики удивляются: «А почему вы так странно делаете?». «Ну, нам так удобно, привычно, мы не знали, что можно по-другому». С точки зрения разработчика – это три притопа, два прихлопа, попытки обойти нормальную логику какими-то странными методами. А с точки зрения пользователя – это естественный рабочий процесс. Он просто не знал, что можно сделать по-другому. Поэтому такая обратная связь действительно очень важна.
Еще примеры обратной связи:
- Какие-то публичные демо внутри организации. Здесь вы можете себе позволить организовать показ того продукта, который вы сделали, тем потенциальным пользователям, которые у вас есть, и собрать с них обратную связь в публичном виде. Это хороший способ столкнуться с реальностью и довольно веселое мероприятие, обычно людям нравится.
- Стажировка в поддержке. Очень рекомендую разработчиков посылать в поддержку хотя бы иногда. Они оттуда прямо другими людьми возвращаются. У них глаза горят (от ужаса). Мы считаем, что у хорошей команды, у хорошего разработчика свет должен излучаться во всех направлениях. И глаза должны гореть и задница должна быть подожженная. По сути, мы сейчас говорим о том, как это обеспечить.
- Команда разработчиков меняется с командой поддержки. Вы разрабатываете какой-то продукт (инкремент продукта), выпустили его в релиз, а теперь идете его внедрять и поддерживать. А другая команда, которая до этого внедряла и поддерживала предыдущий релиз, теперь разрабатывает новый продукт. Это стирает грань между плохими и хорошими разработчиками. Обычно в поддержку посылают тех, кто помоложе, но это не очень правильно, потому что падает общая эффективность и снижается качество обратной связи
- Наблюдение за заказчиком в его работе – об этом мы уже говорили.
Давление равных
Давление равных.
- Code Review – лучший способ обучить молодого разработчика, как правильно кодить.
- Story Transition – это когда разработчик формально передает сделанную работу тестировщику. Тестировщик посмотрел, говорит: «это никак не запускается, исправляй». И программисту приходится исправлять.
- И Pairing – парная работа. Парное программирование – это для программистов, но программисты – не единственные люди на проекте, которые могут работать в паре — поэтому говорят pairing.
Как работать с мотивацией команды?
Все знают, что есть положительная мотивация. Например, вы сделали демо для какого-то важного заказчика и он вас похвалил. Это понравится команде, увеличит ее мотивацию. Вроде все хорошо.
А если он вас отругал? Представьте себе, вы показываете генеральному директору, а он сегодня с утра в плохом настроении, и начинает всех чихвостить. Вся команда расстраивается.
Вы – скрам-мастер такой команды. Что нужно сделать, чтобы увеличить ее мотивацию? Самое плохое, что вы можете сделать – это сказать: «идите, работайте», потому что все уйдут расстроенные. Команду формируют совместно пережитые эмоции, неважно, положительные они или отрицательные. Что значит «совместно пережитые эмоции»?
- Это означает, что как минимум, вы поговорили. Не нужно устраивать никаких сложных формальных встреч, вы можете просто спросить: «Что вы об этом думаете?». И люди выскажутся, выпустят пар, и рано или поздно, сами начнут находить в этой ситуации какие-то рациональные зерна.
- Поэтому следующее, что вы должны сделать – это спросить команду: «А как это можно исправить?».
- В результате этого разговора нужно создать план, который будет работать на мотивацию.
- И если этот план еще и будет претворен в жизнь команды – мотивация еще больше возрастет. И несмотря на то, что ее ругали, мотивация у команды получится выше.
Дисциплина
Для этого нужна дисциплина. Без дисциплины все это просто бессмысленно. С этим большая беда в очень многих командах. Да, мы молодцы, мы можем провести ретроспективу, у нас все весело, но потом соблюдать принятые решения нам некогда. Поэтому важно, что:
- Решения принимаются;
- Решения выполняются;
- Провалы анализируются.
Вот три простые вещи, которые должен обеспечивать скрам-мастер. Его задача – не наказывать людей, а следить за соблюдением всех этих действий.
Чем определяется эффективность команды?
Давайте поговорим еще про эффективность команды, как таковой. Смотрите – у меня есть:
- Крутая команда, ее эффективность растет до бесконечности;
- Команда, эффективность работы которой упала;
- И какая-то средняя команда на каком-то среднем уровне.
Как вы думаете, какая планка здесь обозначена пунктиром? Чем обусловлена работа «средней» команды? Почему производительность этой команды дорастает до какого-то уровня и там стабилизируется?
- «Средняя» линия – просто уровень толерантности к результату (ок или не ок). Он зависит не только от заказчиков или ваших потребителей, но и от самой команды.
- Насколько самой команде нравится то, что она сделала.
- Насколько мы эффективно взаимодействуем с заказчиком.
- Насколько качественно мы пишем код.
Это отношение команды – толерантна она к результату или нет. Например, если вы, как скрам-мастер, хотите, чтобы команда стала еще эффективнее, вы собираете команду и говорите: «Давайте еще что-нибудь улучшим?». И вам задают простой вопрос: «А зачем? Какую проблему мы при этом решаем? Заказчики довольны, бизнес прет, бабки идут и т.д. Нет ни одной причины, по которой мы должны улучшаться».
- А нижний график – это когда вами всё время все недовольны. В результате команда выгорает – она сама собой недовольна из-за того, что этой командой недовольно ее окружение.
- Но мы же хотим работать на «высоком» уровне. Поэтому нужно научиться поднимать планку, чтобы постоянно выдавать офигенный результат. Если мы умеем поднимать планку, наша команда будет все время развиваться.
Вот иллюстрация ситуации, когда команды отстают. Из-за чего это происходит?
Чаще всего команды начинают отставать из-за несоответствия ожиданий и реальности.
Например, вы, как скрам-мастер, собрали людей в команду и сказали им: «Вы будете Agile, вы элита, вы классные, вы сможете сделать продукт за месяц и т.д.». Это – сильно завышенные ожидания и все от команды будут ждать именно такого результата, но она никак не может этого добиться. У нее то одно не получается, то другое. Через какое-то время команда выгорает, просто ментально устает делать работу хорошо. Люди приходят на работу и весь день тупят – практически вся команда. Это – ситуация выгорания.
Что нужно сделать в этом случае?
- Здесь – как в ситуации с больным ребенком, нужно возвращать планку вниз. Давайте хоть что-нибудь сделаем до конца в следующем спринте. Одну маленькую вещь, но до конца. И отпразднуем это. Нам нужна ситуация успеха.
- И как с больным ребенком – постепенно учим. Да, я знаю, что все остальные уже бегают, а вы еще не ходите, но мы будем постепенно вас как-то развивать.
- Нужно постоянно давать команде возможность почувствовать хоть чуть-чуть успеха. Это не всегда удается вывести на хорошую производительность, но тем не менее, достаточно часто помогает.
Баланс между скоростью и безопасностью. Состояние «потока»
Чтобы все время поддерживать в своей команде эффективность, вам нужно обеспечить ей состояние «потока». Чиксентмихайи в своей книге «Поток» написал о том, что есть состояние «потока». Это когда вы играете в компьютерную игру и залипаете, не чувствуете времени. Прет. Ситуации, когда команду постоянно прет и ей офигенно – можно и нужно добиваться. Потому что тогда ее производительность эффективна. Это означает, что сложность задач должна постоянно расти.
- Если у команды задачи несложные, то ей слишком просто, скучно, неинтересно, провал маловероятен. Бывают команды выгоревшие просто от того, что им скучно. Представьте, вы набрали высококвалифицированных программистов и заставляете их делать какие-то очень простые вещи – отчеты, печатные формы. Что будет с этими программистами? У них будет низкая производительность, и они будут загоняться, будут все время придумывать какую-то никому не нужную ерунду. Потому что скучно.
- А есть другая крайность, когда сложно, трудно, провал вероятен. Туда тоже мы не хотим выпадать.
- Что нам нужно сделать? Нам нужно находиться посередине, в состоянии «потока», и обеспечить Success Rate на уровне 50%. Это означает, что примерно половина тех вещей, которые вы хотите попробовать, как команда, могут проваливаться.
- Если у вас всегда все успешно, эффективность будет недостаточно высокая.
- Если вы всегда неуспешны – то же самое.
- Поэтому вам постоянно нужно поддерживать баланс между скоростью и безопасностью.
Что значит «баланс между скоростью и безопасностью»? Например, вы решили попробовать парное программирование.
- Если вам скрам-мастер говорит: «все с завтрашнего дня работаем в паре», то провал высоковероятен, слишком много изменений. Вы так просто никогда не делали, не умеете. Это – перебор.
- Можно сделать попроще:
- Пусть два человека попробуют;
- Или один час в день;
- Или какой-нибудь один модуль в паре и т. д.
- Самый плохой вариант – нам на это не дают время. Очень часто говорят: «нам заказчик на это не дает времени». Такого не может быть! Заказчика спрашиваешь: «ты что, им времени не даешь?» – «Нет, даю» – «А почему вы считаете, что он вам не дает?». Нам кажется, что на это нет времени. На самом деле, это и снижает производительность.
- Для того чтобы поддерживать баланс между скоростью и безопасностью, нам нужен Slack Time – это в английском языке называется «время для того, чтобы улучшать свою производительность».
R03;R03;R03;R03;R03;R03;R03;
Переход на новый уровень
У крутой команды проблемы постепенно кончаются и появляются возможности выхода на новый уровень. Для этого вам на ретроспективах нужно постоянно придумывать что-нибудь новое: «давайте просто что-нибудь странное попробуем, дестабилизируем ситуацию, посмотрим, что из этого получится».
И тогда вы фактически выходите из точки равновесия, чтобы найти новую точку равновесия, где будет более эффективная производительность.
Попытки выхода на новый уровень необязательно должны быть связаны с решением текущих проблем – это может быть просто новый прием работы или новая технология.
Зоны роста
Как измерить эффективность команды? Есть ли какое-нибудь число, метрика, по которой можно сказать, что вот эта команда – крутая?
Никакого общего измерения эффективности команды не существует.
На практике у команды в каждый момент времени есть ровно одна самая главная проблема, с которой надо заниматься. И показатель эффективности определяется тем, насколько команда способна с этой проблемой справляться.
- Недовольный заказчик – это один фокус.
- А если много ошибок в коде, это будет другой фокус.
У каждой команды есть некоторые зоны роста, в которых ей нужно совершенствоваться. И эффективность команды определяется в соответствии с успехами в этих зонах.
Эффективная команда – это та, которая умеет решать проблемы. Эффективность означает, что каждые две недели ваша команда в той проблеме, которая для нее является фокусной, становится лучше.
После того, как вы определите главную проблему своей команды на данный момент, вам нужно понять, как это можно измерить.
- Например, качество можно измерить количеством дефектов, инцидентов и т.д.
- Довольного заказчика тоже можно измерить – устраивать для него опросы. Если ваш заказчик неудовлетворен, он должен постепенно становится все более и более удовлетворенным, вы можете это измерить, понять, что именно его не устраивает, поговорить с ним на эту тему, найти фокусные точки, и начать с ними работать.
Итоги
Подводя итоги того, что я рассказывал. Как сделать команду эффективной?
- Нам обязательно нужен Plan-Do-Check-Act. Нельзя работать просто хаотически.
- Чтобы цикл Деминга работал, нужны: Цель. Обратная связь. Challenge. Дисциплина.
- Эмоциональное обсуждение внутри команды, завершающееся планом – для этого тоже нужна дисциплина.
- Состояние потока с 50% успехом.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
