Текст книги "Искусство Agile-разработки. Теория и практика гибкой разработки ПО"

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

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

Техники, представленные ниже, помогут вам создать атмосферу безопасности в ваших командах.

Моделирование поведения, которое вы хотели бы видеть

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

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

Будьте конкретны касательно своих ожиданий

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

Не уклоняйтесь от конфликта

Безопасность не означает, что люди всегда получают то, чего хотят. Она подразумевает, что все мнения принимаются во внимание.

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

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

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

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

См. также

Динамики команды (глава 11)

Ложная гармония и групповое мышление – обычные проблемы команд, находящихся на стадии развития, называемой нормализацией. Больше информации об этом вы найдете в пункте «Стадия нормализации: мы – № 1» главы 11.

Упражнение на построение взаимоотношений в команде

Это забавное упражнение вы можете использовать для налаживания взаимопонимания в вашей команде. Оно хорошо работает как самостоятельное упражнение, а также может быть частью вашей начальной сессии согласования при разработке устава проекта (см. раздел «Согласование» далее в этой главе).

Цель этого упражнения – показать членам команды, что у них гораздо больше общего, чем им кажется. Если вы работаете в общем помещении, то найдите в офисе большое открытое пространство, в котором можно свободно передвигаться. Если команда работает удаленно, то попросите каждого загрузить свое фото на общую виртуальную белую доску. (Готовьтесь, это будет весело!) Затем, когда будете готовы, повторяйте шаги, указанные ниже.

1. Один человек делает заявление о себе: «Я люблю собак».

2. Каждый, кто согласен с этим заявлением, подходит и становится рядом с этим человеком. Удаленные команды передвигают свое фото.

3. Следующий человек делает свое заявление: «Мой любимый язык программирования – Perl». И т. д.

Продолжайте, пока время не истечет. Люди могут поделиться всем, чем захотят, многим или немногим.

Что бы я ни делал, один из членов команды не хочет высказываться. Как я могу ему помочь?

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

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

Еще один вариант для такого человека – проговорить свои идеи с приятелем в команде. Это позволит заранее отрепетировать то, что он хочет сказать, или он может попросить приятеля представить его точку зрения.

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

Это зависит от сложности ситуации и от того, чувствуете ли вы себя в достаточной безопасности, чтобы действовать самостоятельно.

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

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

Разве мы не проведем время с большей пользой, занимаясь своей работой, а не обсуждая свои чувства?

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

Вспомните выводы проекта «Аристотель». Безопасность была показателем номер один производительности команд Google. И даже если это не так, работа – огромная часть нашей жизни. Разве вы не хотите, чтобы она проходила в обстановке, в которой вы и ваши коллеги могут выражать себя без страха?

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

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

Когда в вашей команде царит атмосфера психологической безопасности:

• члены команды говорят о своих ошибках и чему они их научили;

• они конструктивно выражают несогласие;

• они выносят на общее обсуждение идеи и проблемы;

• команда создает лучшие продукты, содержащие больше идей;

• легче нанимать и удерживать людей с разнообразным опытом.

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

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

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

См. также

Ретроспективы (глава 11)

Один из способов начать – проводить ретроспективы на тему безопасности. Обсудите, что вы заметили в отношении безопасности в своей команде и в других, и выберите несколько экспериментов, которые можно провети.

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation and Growth[39]39
  Эдмонсон Э. Работа без страха. Как создать в компании психологически безопасную среду для максимальной командной эффективности.


[Закрыть] [Edmonson2018] – новая книга Эми Эдмонсон, профессора Гарвардской школы бизнеса. Это хорошая книга о многих аспектах психологической безопасности, которую исследовала автор.

Building a Psychologically Safe Workplace [Edmonson2014] – выступление Эми Эдмонсон на TEDx; легкое, быстрое погружение в тему.

Time to Think: Listening to Ignite the Human Mind [Kline2015] посвящена тому, как создать пространство и время для размышлений на работе. Книга содержит практические советы, которые я использую на большинстве встреч.

Аудитория

Продакт-менеджеры, коучи

Мы понимаем, ради чего работаем.

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

В практике «Цель» объясняется, как сделать так, чтобы каждый понимал общую картину, а не только детали.

Прежде чем у продукта появляется команда, у кого-то в компании рождается идея. Предположим, это некто в компании Wizzle-Frobitz (выдуманное название). «Эй! – восклицает он (или она), в порыве воодушевления смахивая свой кофе со стола. – Мы могли бы frobitz наши wizzle намного лучше, если бы у нас было ПО, которое сначала сортировало бы wizzle!»

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

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

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

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

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

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

См. также

Вовлечение реального заказчика (глава 8)

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

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

Разработка несколькими командами

Если ваша команда – часть горизонтально масштабированной группы команд (см. главу 6), то цель вашей команды будет отличаться от общей цели продукта или портфеля продуктов. Она будет связана с общей целью, но сосредоточена на специфической роли вашей команды.

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

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

Для вертикально масштабированных команд в этом нет необходимости. Они работают все вместе над общей целью.

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

Проект документа о цели – первый примерный набросок в документировании этого обсуждения. Он используется для того, чтобы развивать дискуссию. Формат документа зависит от стандартов вашей компании. Некоторые компании любят использовать ключевые показатели эффективности (Key Performance Indicators, KPIs) или подход OKR (Objectives and Key Results – цели и основные результаты). Каким бы ни был формат, вам в конечном итоге нужно ответить на три вопроса.

1. Ви́дение. Почему работа команды ценная? Опишите, как мир (или, по крайней мере, его маленькая часть) изменится, когда команда добьется успеха. Поясните, почему это важно для компании и ее заказчиков. Думайте о долгосрочной перспективе и сосредоточьтесь на ценности.

2. Миссия. Как команда может реализовать концепцию в следующие 3–6 месяцев? Опишите, что, по ожиданиям, команда должна выполнить и что лежит за пределами объема работ, но на высоком уровне. Оставьте больше пространства команде для проработки деталей. Сосредоточьтесь на итогах и ценности до результатов. Может быть полезным сначала подумать о конкретных результатах, но двигаться в обратном направлении, то есть начать с «почему», а не «что».

3. Показатели. Как члены команды узнают, что они на верном пути? Опишите до пяти кратких показателей успеха. Будьте конкретны и недвусмысленны. Избегайте разговоров о конкретных функциональностях (например, «поставить функциональность Х к дате Y»). Вместо этого пишите о коммерческих результатах, которых ожидают стейкхолдеры. Объясните, как понять по показателю, что ценность миссии была достигнута. Если это трудно сделать, то, вполне возможно, ваша миссия не сфокусирована на ценности.

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

Вспомните Манифест Agile: «Сотрудничество с заказчиком важнее согласования условий контракта». Документ о цели описывает механизм сотрудничества, а не является контрактом. В процессе работы и по мере накопления командой знаний о рынке цели будут меняться.

Пример цели

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

(Обратите внимание, ви́дение фокусируется на ценности в долгосрочной перспективе.)

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

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

(Обратите внимание, что миссия начинается с ценности, затем переходит к деталям конечного продукта.)

Показатели

1. Мы представим первый макет и план для как минимум 20 потенциальных заказчиков. Мы будем считать, что достигли успеха, если 70 % из них скажут, что это решает их проблемы с взаимодействием. Так мы узнаем, является ли наш подход жизнеспособным.

2. Мы проведем демонстрацию ранней версии на стенде во время отраслевого мероприятия. Мы будем считать, что достигли успеха, если минимум 100 человек остановятся и проявят интерес и по меньшей мере 50 подпишутся на бета-версию. Это будет означать, что люди заинтересованы в продукте.

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

4. Через четыре месяца после запуска бета-версии продукта мы будем считать, что достигли успеха, если минимум 100 команд будут оплачивать продукт и пользоваться им регулярно, что будет определяться как минимум одной авторизацией и изменением в течение каждых двух недель. Это будет означать, что продукт полезен в реальной жизни.

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