Перейти к контенту →

Scrum. Революционный метод управления проектами. Джефф Сазерленд. Краткое содержание

Как сделать свою команду суперэффективной

Проект проваливается: бюджет выходит за рамки, о соблюдении сроков речь уже не идет, сотрудники … так и хочется уволить всех! Ходят унылые, уверяют, что работают сутки напролет, ночуют на работе. А результата нет. Знакомая ситуация? Автор книги рассказывает о методике Scrum, которая рекомендует новый подход к проектной работе. Производительность работы по такому методу увеличивается в сотни раз. Узнайте, как Scrum работает на практике.

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

Традиционно проекты разработки программного обеспечения идут по каскадной модели. Сначала команда договаривается, что они именно она будет делать. Далее несколько месяцев (иногда даже более года) группа разработчиков составляет план, как именно проект будет двигаться к цели, кто, что и в какие сроки станет делать. Процесс планирования сопровождается рисованием разноцветных диаграмм Ганта, демонстрируемых руководству. На диаграммах все выглядит отлично, и начальники дают добро на реализацию плана. Однако в реальности ни один проект никогда не может соответствовать детально написанному плану: возникают незапланированные ошибки, затягивается решение проблем, меняется рыночная ситуация и пр. Сроки и бюджет никогда не соответствуют плану, превышая его на треть, а то на 50% и более. Часто клиент так и не получает заказанную систему. Если же получает, то результат не соответствует исходным пожеланиям или текущим потребностям.

Метод Scrum отвергает планирование всего проекта за один раз и в деталях. Гибкость подхода к выбору текущих задач по проекту, а также еще несколько секретов методики позволяют командам повышать производительность на 50, 100 и даже 400%, заканчивая проекты в суперкороткие сроки. Например, бригада строителей, применяя метод Scrum, сделала ремонт в доме ровно за отведенные на это шесть недель. А в точно таком же доме, расположенном по соседству, уже без метода Scrumаналогичный ремонт затянулся на три месяца, потребовав не только в два раза больше времени, но и в два раза больше денег.

Прочитав краткий обзор по книге «Scrum. Революционный метод управления проектами», вы узнаете:

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

Почему автор книги занялся проблемой эффективности проектов по разработке программного обеспечения

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

В 1983 году американское правительство урезало финансирование медицинских исследований. В том числе и того научного центра, в котором работал Сазерленд. Однако ему не пришлось долго думать, чем заняться дальше. По рекомендации его коллег к Сазерленду обратилась компания, обслуживающая 150 американских банков. Компания работала над созданием сети новых устройств – банкоматов. В то время снять деньги можно было только в банке по чеку. Чтобы система заработала, нужна была программа, благодаря которой каждый банкомат всегда бы «знал», сколько денег на счету любого клиента любого банка. С разработкой программы возникли трудности, и компания искала специалиста по работе сложных систем.

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

Почему методика так называется

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

Как робот вдохновил Сазерленда на создание методики

Офис одной из компаний, в которой трудился Сазерленд, находился рядом с Массачусетским технологическим институтом. Ученые из этого университета арендовали у компании комнату, так как в университетской лаборатории для их молодого бизнеса не нашлось места. Занимались ученые роботехникой.

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

На одной из вечеринок Сазерленд разговорился с ученым, руководителем молодой компании Родни Бруксом. Чтобы проиллюстрировать влияние этой беседы на развитие методики Scrum, стоит рассказать, что Брукс – тот человек, который придумал и возглавляет компанию iRobot, создавшую доступных домашних помощников – роботов-пылесосов и роботов-мойщиков полов.

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

Как определить, что вы верно используете методику

Команда, верно использующая метод, ежемесячно увеличивает продуктивность. Причем увеличение это очень наглядно – не на сотые доли, а на 20, 50, 100% и более. Если же производительность не меняется, то вы что-то делаете не так.

Яркий образ методики

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

Идут по дороге курица и свинья. Курица говорит свинье, что ее посетила гениальная мысль – им вдвоем нужно открыть ресторан! Свинья спрашивает, как они назовут свое заведение. У курицы уже готов вариант. «Как тебе «Яичница с беконом»?» спрашивает она свинью. «Нет, давай другое! А иначе мне придется посвятить себя проекту полностью, а тебе – только частично!»

Элементы метода Scrum

Элемент №1. Спринт

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

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

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

Элемент №2. Конкретные задачи

Неизменный атрибут scrum-команды – доска или часть стены (бывает, что и все стены в помещении), обклеенная стикерами с задачами. На каждом стикере записана одна конкретная задача. Например, «просверлить отверстие для рейки», «установить внутреннюю обшивку кресла» и пр. В начале спринта команда выбирает задачи, которые собирается и способна выполнить за это время. Стикеры с этими задачами переносят в поле «в работе» на scrum-доске. Если какая-то задача слишком долго задерживается в этом поле, не переходя в зону «сделано», все члены команды видят это и помогают исполнителю: обсуждают, в чем причина задержки, как ее устранить, какой способ выполнения лучше выбрать и т.д. Важно, что задача в зоне «сделано» означает, что это уже опробованная и одобренная клиентом часть программы или того, что делает команда. Сделали – показали клиенту, как работает выполненная часть. Клиент одобрил – задачи переходят в зону «сделано».

Как сформулировать конкретные задачи

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

Сазерленд собрал сотрудников в конференц-зале. Стол был завален всеми написанными для проекта документами: планами, расчетами, заданиями и пр. Тысячи страниц! Выяснилось, что в зале нет никого, что прочитал бы их все. Сазерленд задал этот вопрос не потому, что не знал на него ответ. Конечно, знал. Он хотел, чтобы все осознали, каким ложным путем шли.

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

При движении к цели дважды становилось ясно, что имеющийся объем задач к сроку выполнить невозможно. Тогда все снова собирались, анализировали оставшиеся задачи и удаляли из списка те, которые не создают для проекта ценности. И оставляли те, про которые можно было точно сказать, что они принесут проекту максимальную ценность. Подумайте о программе Word. В этом текстовом редакторе масса функций, о которых вы даже не подозреваете. Однако кто-то когда-то решил, что они важны. И люди тратили время на их разработку и тестирование. А пригодились ли они в реальности хотя бы 10% пользователей? Во время работы над программой никто не задал своей команде этот вопрос.

Элемент №3. Объем задач в единицу времени

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

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

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

Как определить, сколько времени команда потратит на задачу

Сазерленд рассказывает, какой отличный и наглядный образ выбрал его друг, чтобы определять время выполнения задачи. Это метод измерения сложности задач в собаках. Да-да, в собаках. Для тех подчиненных, кто не разбирается в собаках, друг автора книги составил список пород с картинками. Из списка видно, что дог – крупная собака, овчарка – средняя, но ближе к крупной, бульдог – средний, но ближе к маленькой, а такса самая мелкая собака из списка.

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

Позже друг автора книга перевел собак в цифры. Такса стала единицей, дог – тринадцатью, а бульдог – тройкой. Всего категорий задач получилось шесть: со сложностью в 1, 2, 3, 5, 8 и 13. Это последовательность Фибоначчи – порядок чисел, в котором каждое следующее – сумма двух предыдущих. Например, 8=5+3, а 13= 8+5.

Человеку сложно отличить 3 от 4 или 13 от 14, если речь идет об оценке сложности или масштабности чего-либо с помощью цифр. А вот 3 от 13 отличить легко. Как вы себя чувствуете, на 3 или 13? Легко ответить, что на 3, если болен, и что на 13, если почти выздоровел. А вот как быть, выбирая между 3 и 4? Сложно. Поэтому для оценки задач стоит выбирать значения числовой последовательности Фибоначчи. Или оценивать все в собаках – как вам больше нравится.

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

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

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

Элемент №4. Ежедневные собрания на ходу

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

— что делал вчера для достижения цели команды;

— что будет делать сегодня для достижения цели команды;

— какие видит препятствия на пути к цели для всей команды.

 

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

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

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

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

Элемент №5. История

Задача проекта – не просто описание того, что следует сделать. Задача проекта – это то, что принесет пользу конкретному человеку. Значит, и смотреть на задачу нужно глазами того, для кого вы ее делаете. В чем потребность клиента? Что человек станет делать, получив то, что вы для него разрабатываете?

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

Элемент №6. Встречи в конце спринта

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

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

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

Элемент №7. Постоянное совершенствование

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

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

Простой способ быстро улучшить командные результаты

Когда Сазерленд учился на последнем курсе в военной академии, его назначили инструктором роты. У инструктора нет полномочий командовать, раздавать приказы. Его задача – следить за строевой подготовкой роты, которая оценивается три раза в неделю после парадного марша всех рот на плацу. Оценку проводят все инструкторы, собираясь после парада. Рота, в которой учился Сазерленд, была худшей. А через несколько недель смогла занять почетное первое место. Что же сделал Сазерленд, не имея никакой власти?

Автор книги записывал на каждом собрании инструкторов все замечания в адрес своей роты, даже самые примитивные. Затем зарисовывал каждое замечание на отдельную карточку и подписывал ее. Например, «У Чарли сабля воткнулась в землю», «Джим развернулся позже остальных». Эти карточки Сазерленд вывешивал в казарме, чтобы все члены роты могли видеть их. Сокурсники Сазерленда стали обращать внимания на мелочи, изображенные на картинках, и внимательнее выполнять все действия во время парадного марша.

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

Пять важных вещей, которые нужно усвоить руководителю, если он хочет получить эффективную команду

№1. Личность сотрудника не важна

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

Профессор Йельского университета записывал, сколько каждый его студент тратит времени на выполнение заданий. Затем отправил эти данные вместе с информацией об отметках студентов коллеге из компании-разработчика программного обеспечения. Профессор попросил коллегу оцифровать и проанализировать данные. Оказалось, что нет никакой связи между затрачиваемым на подготовку заданий временем и оценками. Студенты получали одинаковые оценки, тратя разное время: просто кто-то был сообразительнее, а кто-то – медлительнее. Самые шустрые в десять раз быстрее выполняли задание, однако оценки получали такие же, как и самые нерасторопные.

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

Группа ученых изучила процесс выполнения почти четырех тысяч проектов в разных отраслях. Исследователей интересовали командные результаты. Выяснилось, что разница между лучшими и худшими командами несравнима с разницей между лучшими и худшими (по скорости) студентами. Если шустрые студенты в десять раз быстрее медленных сокурсников, то худшие команды медленнее лучших …в две тысячи раз. Это значит, что проект, который лучшая команда выполнит за неделю, худшая сможет закончить только за две тысячи недель, то есть тридцать восемь с половиной лет. Вдумайтесь в эти цифры: одна неделя и тридцать восемь с половиной лет.

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

№2. Исправлять ошибки нужно немедленно

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

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

№3. Работать надо меньше

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

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

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

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

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

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

№4. Любая, даже самая маленькая команда должна делать все сама от начала до конца

Никакого разделения труда. Именно разделение приводит к катастрофам. Например, начинает проект одно подразделение, потом передает его другому, третьему, четвертому для расчетов, анализа и пр. Затем для воплощения в жизнь проект, наконец, переходит к пятому подразделению, которое его в глаза не видело и чье мнение не спросили ни на одной из предыдущих стадий. Стоит ли удивляться, что все заканчивается крахом.

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

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

Это закон Брукса, названный по имени Фреда Брукса, автора книги «Мифический человеко-месяц», вышедшей в 1975 году. Верность этого закона доказал программист Лоуренс Путнэм. Он годами исследовал зависимость между сроком выполнения работы, ее объемом и численностью команды. Неизменный результат исследований показывал, что если в проекте участвует более двадцати человек, то работа над ним требует в пять раз больше усилий, чем было бы необходимо при меньшей численности команды.

Путнэм исследовал 491 проект по разработке программного обеспечения. Оказалось, если в группе от трех до семи человек, то она выполнит равный объем работ, тратя на 25% меньше усилий, чем команда численностью от девяти до двадцати человек.

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

Подсчитайте число коммуникационных каналов в вашей группе

Для этого число членов группы умножьте на это же число минус один, а результат разделите на два. Например, в команде 10 человек. Тогда число коммуникационных каналов в группе равно 10* (10-1)/2=45. Сорок пять каналов! Помните, что в кратковременной памяти человек может удержать лишь четыре объекта?

Не делайте ваши группы большими. Идеал – от трех до девяти человек.

Заключение

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

 

Опубликовано в Быстрый результат

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *