Алистер Коберн: Командная разработка и agile

в 14:26, , рубрики: agile, команда, проектирование, разработка, управление персоналом, Управление продуктом, управление проектами, управление разработкой

Сегодня день рождения одного из отцов-основателей Agile-манифестаАлистера Коберна. Предлагаю вашему вниманию перевод его выступления на TED про командную разработку.

image

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

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

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

Хороший способ — относиться к этому как к совместной игре. Поэтому сначала нам нужно немного поговорить об играх. В этой таблице представлены их разные виды: совместные игры, соревновательные игры и т.д. Сначала простые. Это соревновательные игры с определённой целью, такие как шахматы или теннис, где цель — это выиграть игру. Вы ведёте счёт и знаете, когда игра окончена.

image

Есть игры без счёта. Они заканчиваются, но финал остаётся открытым. Посмотрите на детей, играющих на природе в «царь горы» — они играют, пока не устанут. Они могут играть, пока не настанет время обеда или пока не стемнеет и мама не позовёт их. То же самое с покером, люди играют до звонка вроде: «Привет, дорогой, сейчас 1:30, как думаешь, может пора домой?» То есть в итоге вы всё же приходите к концу.

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

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

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

Алистер Коберн: Командная разработка и agile - 3

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

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

Интересно, что также в этой категории находится управление линейками продукции. Представьте, что выходит продукт, давайте его просто назовём версией 3. Сделаем вид, что вы достаточно неудачливы, чтобы оказаться на рынке мобильных телефонов пару лет назад. Тут Apple выпускает iPhone, и вы делаете релиз 3.12, который даёт вам время, чтобы сделать релиз 4. Этот выход релизов 3.1 — это ход в бесконечной игре, где вы пытаетесь купить время, чтобы оставаться в игре.

Возвращаясь назад, у нас есть командная версия игр с открытым концом вроде «царя горы» и покера. Здесь не очень много примеров. Джазовая музыка — это отличный пример. Джазовый музыкант не говорит: «Ребята, у нас всего 10 минут до того, как мне надо уйти. Давайте ускоримся. В последний раз мы играли 12 минут, давайте уложимся в 10». Что происходит в джазе? В джазе они играют, и играют, и играют, пока не закончат.

На перерыве кто-то сказал мне, что есть и другой пример — World of Warcraft. Это пример людей, которые играют в соревновательную игру, но играют командой и делают это до тех пор, пока не устанут. Так что есть другие подходы к совместным играм с открытым концом.

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

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

Алистер Коберн: Командная разработка и agile - 4
Здесь у нас очень простая таблица, где я указал количество людей, которых надо скоординировать по горизонтальной оси, а по вертикальной оси — критичность, или жизненный вред. И тут есть квадраты, где проставлены цифры исходя из этих двух параметров. Если у вас есть проект, в который вовлечены 6 или менее человек, то вы можете собрать их в одной комнате и дать поговорить друг с другом. Но когда у вас 20 человек, вы больше не можете все находиться в одной комнате. Возможно, вы уже смешиваете технологии. Если у вас 100 человек, у вас есть проблемы с согласованностью и взаимодействием.

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

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

В проекте Центрального банка Норвегии, где отслеживали межбанковские транзакции на территории страны, все относились к потерям свободных денег так, как будто это был проект из трёх человек. В один день я проснулся и сказал: «Это же межбанковские транзакции во всей Норвегии, там проходят десятки миллионов крон». Я поставил его на ступеньку выше. Мы расширили проект до 20 человек, некоторые были в Лиллехаммере, некоторые в Осло. Я поставил его выше снова. Суть была в том, что мы не меняли проект, мы меняли своё представление о нём.

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

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

Алистер Коберн: Командная разработка и agile - 5
Я испытал это вчера. Я репетировал вчера свою речь и в конце один из моих друзей сел и сказал: «Хочешь услышать отзыв?» Я подумал: «Нет, заткнись, я сделал её на 25 минут, я могу говорить быстрее и уложиться в 20 завтра». Но я сказал: «Да, конечно». И после очень вежливого и вдумчивого отзыва мы написали всю эту речь на сегодня прошлой ночью. Подумайте: вот мой друг, какой вид личной безопасности ему нужен, чтобы сказать: «Эй, Алистер, я знаю, что это будет на TED завтра. Это отстой. Знаешь, попробуй ещё раз». Это очень жёстко. И он сейчас в зале. Но это было очень хорошо. Это пример, как нужно передавать плохие новости быстро.

Алистер Коберн: Командная разработка и agile - 6
Последнее, о чём я скажу — это коммуникация. Тут быстрый тест. В использовании концепции совместной игры нужно быть способным посмотреть на оборудование офиса и то, где идеи проходят быстро и где — медленно. Здесь мы видим славный офис ThoughtWorks в Чикаго. Он очень современный. Когда я смотрю на него, я вижу покрытия, которые поглощают звук, я вижу высокие потолки, которые рассеивают звук и расширяют пространство. У них есть дугообразные столы, которые вообще-то довольно паршивы, потому что вы не можете привести коллегу и передвинуть экран вперёд. Но что я также заметил, и надеюсь, что и вы заметили, это двух людей, работающих рядом, у них очень интенсивная коммуникация, они обмениваются идеями невероятно быстро.

Я говорил об этом с очень известными человеком, Томом Демарко, и он сказал: «Коммуникация — это не парфюм. Она не становится сильнее, когда вы подходите ближе». Я подумал над этим и сказал: «Да она в точности как парфюм! Чем ближе ты находишься, тем лучше замечаешь движения глаз, ты можешь видеть, о чём они думают».

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

Или телефон: у вас всё ещё есть голосовые интонации и ответы на вопросы в реальном времени, но вы упускаете жесты и мимику. Вы заходите в чат и теряете всё, кроме ответов в реальном времени. Вы видите, как эта кривая опускается вниз. Это всё при ответах на вопросы в реальном времени.

Что вы делаете, если находитесь в разных временных зонах или занимаетесь архивной документацией? Вы копируете ту же кривую, и вы можете сделать видеозапись, как один человек объясняет дизайн другому человеку. 3-5-минутные ролики, которые люди сейчас делают на мобильные телефоны, цифровые камеры, выкладывают в сеть и люди в других временных зонах получают их. Вы можете пользоваться этим с клиентами, когда вице-президент по маркетингу говорит: «Вот, что мне надо». Запишите на видео, не перекладывайте на бумагу. И что мы постоянно используем? Бумагу! Вещь, которая наименее эффективна из всех. Пусть она электронная, тем не менее это бумага.

Алистер Коберн: Командная разработка и agile - 8
Последняя тема, которую я затрону — это стоимость расстояний. Я знаю, виртуальные команды повсюду, но в последней речи мы слышали, как кто-то назвал позором то, что мы отдаём на аутсорс все эти биотехнологические проекты, потому что у нас нет возможности построить команду на месте. Так что расстояния обходятся дорого. Исследование показывает, что люди не пройдут больше длины школьного автобуса, чтобы задать вопрос. Кривая коммуникации резко идёт вниз у отметки в 10 метров.

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

Автор: MagisterLudi

Источник

Поделиться новостью

* - обязательные к заполнению поля