Скрам книга краткое содержание
Обновлено: 05.07.2024
Боевой и научный опыт
В 1967 году молодой военный летчик Джефф Сазерленд прибыл во Вьетнам. Самыми опасными заданиями были разведывательные полеты, которые и пришлось выполнять автору книги. “И нерешительность, и безрассудная храбрость могли стоить летчику жизни”. Летчиков учили простому алгоритму поведения: “наблюдать, ориентироваться, решать, действовать”. Именно этот профессиональный навык помогал Сазерленду быстро принимать решения в смертельно опасных ситуациях, а позже на всю жизнь определил его подход к работе.
“С самого первого дня я старался постичь удивительную тайну. Почему люди упираются в своем желании придерживаться привычной для них организации труда, хотя прекрасно осознают бесплодность и расточительность своей деятельности… Могу только предположить: им кажется, будто если так поступают все – значит, это наилучший способ”.
Вернувшись из Вьетнама, Сазерленд изучал статистику в Стэнфорде, а затем защитил докторскую диссертацию по биологической статистике в Колорадском университете. Он исследовал изменения состояния сложных адаптивных биологических систем, в частности процесс перерождения здоровой клетки в раковую. Тогда же он задумался о том, что организации и коллективы, которые тоже можно считать сложными адаптивными системами, при переходе из одного состояния в другое подчиняются тем же законам, что и клетки. Сазерленд задался вопросом, можно ли из этой параллели вывести простые правила, которые помогут организациям, изменяясь, добиваться стабильного состояния. Причем так, чтобы оно было лучше прежнего и чтобы были обеспечены условия для увлеченной, творческой деятельности.
“Команда, которой для того, чтобы уложиться в сроки, регулярно требуется проявлять героизм, работает не так, как следовало бы”.
“Компания внутри компании”
В 1983 году компания MidContinent Computer Services предложила Сазерленду, как специалисту по системам сбора и анализа данных, возглавить проект по созданию единой сети новых устройств, получивших название Automatic Teller Machines (банкоматы). Сазерленд обнаружил, что работа над этим проектом была организована по традиционной “каскадной” модели. Программисты никогда не укладывались в сроки. Бюджет не соблюдался. В коллективе царила пассивность, руководители занимались мелочным контролем, требовали проявлять максимум усилий и работать внеурочно. Никакие меры не помогали. Сазерленд убедил президента MidContinent выделить занятых в проекте сотрудников в новую автономную структуру. Группа придумала свой процесс разработки продукта со своими инструментами, собственную систему премиальных. Именно тогда появились общая концепция и термины, которые позже составят основу Скрама: “владелец продукта”, “бэклог”, “спринты”. Через полгода команда Сазерленда стала самой рентабельной структурной единицей компании.
“Мы не умеем концентрировать внимание, проводим в офисе намного больше времени, чем того требует дело. Мы из рук вон плохо оцениваем сроки работы. Сейчас я говорю обо всех людях – видимо, мы так устроены”.
“Мыслящие конечности” организма
Правила совершенствовалась с каждым очередным проектом, которым руководил Сазерленд. На новые идеи его наталкивали сотрудники софтверных компаний и коллективы ученых, разрабатывавших новые технологии. Одним из таких ученых стал Родни Брукс, специалист по робототехнике и искусственному интеллекту из Массачусетского технологического института (МТИ). Брукс рассказал Сазерленду, что попытки создания мыслящего робота с центральным мозгом ничего не дали, зато устройство, у которого каждая конечность обладала собственным “мозгом”, оказалось очень эффективным.
“В любой компании сначала нужно дать сотрудникам почувствовать себя свободными, а потом приучить их к ответственности, которая следует из этой свободы”.
Правила Toyota и айкидо
Другим источником вдохновения послужила для Сазерленда производственная система Toyota. В Toyota принято выделять три типа потерь: мури (потери из-за неблагоразумного обращения с ресурсами), мура (потери из-за неравномерного обращения с ресурсами), муда (любые потери, связанные с производственным процессом). Философию устранения потерь можно применить к любому виду деятельности. В приложении к разработке продуктов главные рекомендации будут звучать так. Не пытайтесь делать все и сразу; выполняйте за один раз только одну задачу, требующую особой концентрации. Сведите до минимума количество недоделок – в конце каждого этапа проекта не должно оставаться задач, выполненных наполовину. Немедленно исправляйте ошибки: потом это дороже вам обойдется. Не истощайте силы членов своей команды – они будут ошибаться и принимать неверные решения.
“Суть системы Скрама заложена в ритме деятельности. Для человека ритм имеет особое значение”.
Каждому, кто занимался айкидо, знакомо понятие сюхари: “соблюдать – прорываться – отделяться”. Сначала необходимо повторять за учителем все движения, ничего не меняя, затем – овладеть всеми приемами и научиться импровизировать. Наконец, приобретенное мастерство позволит освободиться от освоенных приемов и начать творить. Подобно айкидо, Скраму можно научиться лишь в процессе. (А все правила нужно сначала хорошо освоить, а потом о них можно забыть.)
“Команда может самоорганизоваться и решать проблемы, становящиеся очевидными благодаря открытости всех процессов”.
Вместо каскадной модели – параллельные процессы
Традиционный последовательный (или “каскадный”) подход к работе над проектами безнадежно устарел, как показало множество проектов, в особенности в области разработки ПО, закончившихся полным провалом. Среди первых, кто заговорил о несостоятельности каскадной модели, были японские экономисты Хиротака Такеучи и Икуджиро Нонака, опубликовавшие в 1986 году в журнале Harvard Business Review статью “Разработка нового продукта: новые правила игры”. На смену линейной модели, в которой процессы происходят последовательно, один за другим, утверждали Такеучи и Нонака, должна прийти более современная модель, в которой процессы разработки продукта идут параллельно.
“Сплоченная группа сама справится с вопросом производительности отдельных своих участников. Обычно в группе знают, чем кто занимается, кто может помочь, кто может все испортить, кто ведет команду вперед, кто ей вредит”.
Работу при такой организации труда ведут автономные многофункциональные проектные группы, наделенные свободой принятия решений. В этой модели сотрудники перестают руководствоваться только личными интересами, а руководители относятся к лидерству как к служению. Они видят свою основную задачу в том, чтобы устранять препятствия на пути своих команд. Такеучи и Нонака сравнивали работу таких команд с игрой в регби, в которой одним из приемов розыгрыша мяча является “схватка” (по-английски скрам): игроки группируются вокруг мяча и движутся по полю как единое целое. Так у системы подходов, которую разрабатывал Сазерленд, появилось название – Скрам. Командная работа над проектами, как регби, предполагает “слаженность, единство намерений и четкое понимание цели”. От участников требуются взаимное доверие и искреннее желание разобраться в причинах успехов и неудач.
“Я… укажу, каких потерь следует избегать в первую очередь, – потерь, связанных с нанесением ущерба имуществу; потерь, вызванных неправильным выполнением задания с первого раза; потерь от чрезмерного усердия; эмоциональных потерь, связанных с завышенным ожиданием”.
Автономная многофункциональная команда
Высокоэффективные команды имеют три общие черты:
- Стремление к постоянному совершенству. У выдающихся команд есть представление об общей цели. Они не останавливаются на стандартных решениях, высоко оценивают свои возможности и предъявляют строгие требования к себе и своей работе.
- Автономность. Им присущи черты самоорганизующихся и самоуправляемых систем.
- Многофункциональность. Они обладают всем необходимым, чтобы без внешнего вмешательства принимать решения и осуществлять их. Передавать проект поэтапно от одного специализированного отдела организации к другому гораздо менее эффективно, чем вести его одной командой, состоящей из разных специалистов.
Достичь высоких показателей способны только небольшие команды – от пяти до девяти человек. Скорость работы группы, в которой больше девяти человек, заметно падает. Об этом же говорит и закон Фреда Брукса, сформулированный им в известной книге “Мифический человеко-месяц”: “Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше”. Группы, начавшие использовать Скрам, повышали эффективность на 300 или 400%, а лучшие команды – даже на 800. Качество работы при этом тоже существенно возрастало. Их успехи показали, что сверхэффективности в работе можно достичь только при соблюдении следующих условий: режим автономности, постоянное совершенствование, атмосфера сотрудничества и взаимное обогащение знаниями и идеями.
“Каждая команда – над чем бы она ни работала – должна сама для себя определить критерий полезности и спрашивать результат с владельца продукта, поскольку именно он в ответе за то, чтобы ценность и стоимость продукта постоянно росли”.
Основные понятия и принципы Скрама
В самом начале проекта, который ведется по Скраму, команде необходимо составить максимально полный список требований к функциональным характеристикам продукта. Он называется “бэклог”. В нем могут быть записаны десятки и даже сотни задач – часть из них, естественно, никогда не будет решена. Первым делом отбираются приоритетные требования на основе нескольких критериев. Необходимо определить, какие задачи: “1) имеют самое большое значение для хода работ над проектом; 2) важнее всего для заказчика или будущего потребителя; 3) принесут максимальный доход; 4) проще всего осуществить”.
“Я все время пытаюсь объяснить главное: вместо того чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта”.
Работу над проектом принято делить на короткие, но законченные этапы, или “спринты” (по аналогии с бегом на короткую дистанцию). Принцип разделения проекта на короткие этапы с публичным обсуждением Сазерленд позаимствовал у лаборатории Media Lab при МТИ. Идея “спринта” состоит в том, чтобы за короткое время попытаться решить ограниченное число задач, а затем посмотреть на полученный результат. Продолжительность каждого “спринта” должна быть оговорена заранее: чаще всего это неделя или две и в любом случае меньше месяца. В начале каждого такого цикла члены группы отбирают задачи (“единицы работы”), а в конце – внимательно анализируют свои результаты, взаимодействие между участниками, процессы и возникшие помехи. Члены команды идентифицируют самое важное из препятствий, с которыми им пришлось столкнуться, и решают, как его устранить в следующем “спринте”. Так выполняется правило “непрерывного совершенствования” (по-японски кайдзен).
“Все дело в построении правильной системы с правильными стимулами. Нужно дать людям свободу, уважение и право делать свое дело самостоятельно”.
Промежуточные результаты нужно не только оценивать самим, но и обязательно демонстрировать заказчику, например раз в месяц. Заказчику показывается какой-то завершенный фрагмент: допустим, полностью разработанная функция компьютерной программы или “функциональный прототип” автомобиля – то, что он сможет опробовать в деле, не дожидаясь конца проекта. На основе пожеланий заказчика “бэклог” модифицируется.
Информация о ходе проекта размещается на большой белой доске. Доска делится на три столбца: “Нужно сделать”, “В работе”, “Сделано”. Каждое из действий или заданий, которые группа должна выполнить за один “спринт”, записывается на отдельном стикере. По мере их выполнения стикеры перемещаются членами команды из колонки в колонку. В “Cделано” попадает только то, что было уже протестировано клиентом. Исполнитель каждой задачи известен всем: это обеспечивает взаимопомощь, а значит, саморегуляцию деятельности группы.
Поддерживают работу группы два специально выделенных участника. Один из них – “скрам-мастер”. Это не руководитель, а играющий тренер, “что-то среднее между тренером и капитаном команды”. Основная его задача – отслеживать, как соблюдаются процедуры. Он помогает группе справляться с возникающими препятствиями, проводит ежедневные собрания, постоянно ищет ответ на вопрос, как сделать работу команды еще лучше. Еще одно важное действующее лицо – “владелец продукта” – формулирует концепцию проекта, общается с заказчиком и проясняет его требования, устанавливает основные функциональные характеристики продукта, ведет “бэклог” и помогает определить приоритетность задач. Опыт показал, что совмещать эти две роли одному человеку не под силу.
Оригинальное издание: 2014 год.
Первое руссокязычное издание: конец 2015 года.
Вьетнамский военный летчик, который подарил миру Scrum
Сегодня у нас в гостях Джеф Сазерленд с которым мы попробуем погрузиться с вами в чарующий мир скрама, аджайла, канбана и прочих, пока непонятных слов.
Собственно сам Джеф, некогда действующий программист, а до этого военный летчик с более чем 100 боевыми вылетами во Вьетнаме и автор аджайл манифеста, а также скрама — методики, которая, вот уже как несколько лет, пленила умы сначала разработчиков в IT-секторе, а потом перекочевала во все остальные? где имеет место быть два фактора: 1. непрерывный цикл разработки продукта 2. большое количество участников процесса.
Да-да, наивно полагать, что скрам — это что-то про компьютеры или интернет. Если вы строите дом, готовите к открытию ферму, пытаетесь наладить линию по производству платьев, сувениров или кожанных кошельков. Ну или просто сели с семьей собирать пазл на 10000 элементов — во всем этом должен помочь скрам.
Джеф утверждает, что именно он изобрел методику реализации проектов, которая лишеная недостатков классического управления. Так ли это? Давайте разбираться!
Краткое содержание книги в формате “10 фактов. 3 задачи”
Пару слов о том, что это за такой формат. У нас есть букнот: bukva.info/blog/buknot/. У вас его пока может не быть, но это просто вопрос времени :). Букнот помогает структурировать любые знания полученные из книг таким образом, чтоб потом, после прочтения, выделить самое главное и применить его на практике. Это самое главное записывается в 10 основных фактов и в 3 реальные задачи. Отсюда и название рубрики — “10 фактов. 3 задачи”. Если букнота нет, то такие записи можете делать в любом удобном вам формате: в тетради, на обоях или в телефоне. Итак, поехали…
Скрам — это фреймворк (набор базовых элементов правил и этапов: беклог — приоритезаци — спринт — ретроспектива, своего рода каркас, на котором строится процесс разработки), который помогает решать изменяющиеся в процессе работы задачи.
Аgile-методы — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения.
Недостатки классического способа управления проектами
По мнению Джефа Сазерленда, классическая каскадная модель, при использовании которой все участники занимаются поэтапным выполнением пунктов, является малоэффективной. Продвижение происходит медленно, возникают непредсказуемые сложности. Каскадный план представляет собой график с четко установленными задачами и сроками. Автор предлагает ориентироваться не на отчеты, а на фактические показатели в данный момент времени.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели.
Краткосрочные планы
По мнению автора, выполнять задачу нужно спринтами – небольшими циклами. Участников проекта собирают в группу, чтобы они оценили, какое количество работы смогут сдать за короткое время, например, в течение нескольких недель. Из списка выбираются первоочередные пункты, задачи распределяются между сотрудниками и записываются на стикеры.
По готовности сравнивается фактически выполненное количество. Такой способ позволяет эффективно управлять временем и в будущем брать количество работы, реальное к сдаче в срок.
Командная работа по методу Scrum
Писатель выделяет такие характеристики эффективного коллектива:
1. Непрерывное совершенствование. Команда постоянно стремится к улучшению показателей.
2. Самоорганизация. Сотрудники сами контролируют свою работу, отвечают за качество и сроки.
3. Взаимопомощь. Способность взаимодействовать внутри коллектива, общаться, замещать других.
Также скрам призван решать вопрос взаимодействия между заказчиком и исполнителем. Давайте разберем на примере. Есть отдел маркетинга в компании, которому нужно внедрить новую акционную механику на сайте. По классической модели разработки заказчик (маркетолог) описал бы задачу и отдал ее с помощью какого-нибудь таск менеджера на лида разработчиков. Дальше разработчики собрались бы и сгрузили эту акционную механику тому, кто сейчас не занят: Сережа, ты свободен? Пили для маркетологов возможность перечеркивать цены.
Сережа, пошел пилить, подумал, что, а вот так было бы лучше и вот так было бы лучше, завяз в задаче, сорвал сроки, хотел как лучше, но получилось как всегда.
Маркетологи тем временем накидали еще 10 задач и каждая третья из 10 была гораздо более важной, чем эта, уже никому не нужная акционная механика. Поэтому Сережу стали дергать и говорить: давай ты механику по акциям потом доделаешь, сейчас вот срочно отвалился функционал добавления в корзину — нужно починить. И Сережа чинил, матерился, но чинил. Задачи росли, пропорционально седым волосам у Сережи, счастья не предвиделось.
Пришел скрам мастер и если очень схематично, то собрал маркетологов с разработчикам и сказал. Первое, сейчас в беклог соберем все, чего вы можете хотеть в ближайший месяц — полгода — год. Дальше оценим это все в человеко-часах. У нас, например, их 100. Акционная механика съест 50, останется еще 50. Потом выбранные задачи зайдут в спринт — это временной промежуток в который команда разработчиков занимается только теми задачами, которые были определены. Их зона ответственности — выйти из спринта с готовым результатом.
Сроки переносить нельзя, отказываться нельзя, функционал дополнять нельзя. Результаты спринта обсуждаются на ретроспективе и так по кругу. В итоге задачи разбиваются на много мелких, четко описываются и реализовываются в рамках обозначенного временного промежутка. Все счастливы и особенно Сережа.
Многофункциональная команда
Автор приводит в пример отряд спецназа, в котором каждый специалист обладает своей сферой полномочий, при этом обучен заменить другого в случае непредвиденной ситуации. Так и сотрудники должны быть компетентны в нескольких сферах, разносторонне развиты, чтобы их можно было задействовать для более широкого спектра задач.
Закон Брукса
Численность команды не должна превышать 7 человек. По мнению писателя, эффективность команды с большим числом участников снижается. Прибавление рабочей силы не ускоряет процесс завершения работы, а наоборот, задерживает. Джеф рекомендует руководителям уделять внимание каждому сотруднику. Необходимо анализировать работу каждого и команды в целом, мотивировать людей к самосовершенствованию.
Все и сразу
Автор выступает против мультизадачности. По его мнению, человек способен хорошо сконцентрироваться только на одном действии. Если добавить число проектов, сроки их выполнения будут равны тому, если бы сотрудник выполнял их поочередно. При этом, качество работы ухудшается. Метод Сазерленда предполагает последовательное выполнение планов.
Управление потоком
На пути к счастью
Все люди желают счастья. Писатель утверждает, что оно заключается в активной жизни. Его методика способствует продуктивности в работе, а значит, достижению целей и самореализации личности. То же касается коллектива. Нельзя руководствоваться исключительно показателями продуктивности. Команда должна быть счастлива, тогда она будет работать еще лучше.
Прозрачность
Джеф предлагает пользоваться стикерами с задачами и этапами их выполнения на доске, которая будет видна всему коллективу. Он убеждает, что каждый член команды должен видеть свои и чужие результаты, в том числе и финансовые достижения.
За прозрачность очень хорошо отвечает канбан. Прозрачность в сроках, в оценке времени и в ценности внедрения.
Для того, чтоб узнать о наших персональных задачах, которые мы вынесли для себя из книги — обязательно посмотрите видео. А лучше, дочитывайте эту статью и принимайтесь за книгу…
Как присоединиться к команде Читай Быстро
Пусть у вас сформируются ваши персональные три задачи! Будем рады, если в этом вам поможет наш букнот :).
Давайте дружить
Проект “Читай быстро” — это про осознанное беглое чтение, как одно из основных навыков делающих вас более конкурентноспособным и в конечном итоге более счастливым. Проверяйте свою скорость чтения, подписывайтесь на наш канал на ютубе, делитесь этой статьей или многими другими в нашем блоге у себя в Facebook.
Наша цель: больше начитанных и осознанных людей. Читайте книги. Слушайтесь маму.
Писатель предлагает задействовать методику Scrum. Для начала необходимо разбить проект на
маленькие этапы. Каждый работник берет на себя ответственность за выполнение конкретных
действий. Никаких долгосрочных перспектив и грандиозных сверхзадач: только краткосрочные,
выполнимые планы. Это позволит делать работу качественно, в сроки, контролировать персонал.
Есть три способа: 1. Почитать наш обзор в текстовом формате. 2. Послушать подкаст с обзором на ютубе. 3. Овладеть беглым чтением и читать по книге за вечер. Начать учиться скорочтению можно с нашими рабочими тетрадями.
Если результат зависит от нескольких человек, они должны действовать согласованно. Писатель
предлагает, чтобы руководители не распределяли задачи самовольно, а предоставляли
участникам выбор. Общая цель должна окрылять всех, поэтому каждый должен знать и
коллективную, и собственную выгоду. Конкуренция имеет место быть не между участниками
команды, а среди разных групп.
Проект проваливается: бюджет выходит за рамки, о соблюдении сроков речь уже не идет, сотрудники … так и хочется уволить всех! Ходят унылые, уверяют, что работают сутки напролет, ночуют на работе. А результата нет. Знакомая ситуация? Автор книги рассказывает о методике Scrum, которая рекомендует новый подход к проектной работе. Производительность работы по такому методу увеличивается в сотни раз. Узнайте, как Scrum работает на практике.
Джефф Сазерленд создал методику Scrum для управления проектами по разработке программного обеспечения. Однако практика использования показала, что методика делает эффективным любой процесс от управления бизнесом до выполнения домашних дел.
Традиционно проекты разработки программного обеспечения идут по каскадной модели. Сначала команда договаривается, что они именно она будет делать. Далее несколько месяцев (иногда даже более года) группа разработчиков составляет план, как именно проект будет двигаться к цели, кто, что и в какие сроки станет делать. Процесс планирования сопровождается рисованием разноцветных диаграмм Ганта, демонстрируемых руководству. На диаграммах все выглядит отлично, и начальники дают добро на реализацию плана. Однако в реальности ни один проект никогда не может соответствовать детально написанному плану: возникают незапланированные ошибки, затягивается решение проблем, меняется рыночная ситуация и пр. Сроки и бюджет никогда не соответствуют плану, превышая его на треть, а то на 50% и более. Часто клиент так и не получает заказанную систему. Если же получает, то результат не соответствует исходным пожеланиям или текущим потребностям.
Метод Scrum отвергает планирование всего проекта за один раз и в деталях. Гибкость подхода к выбору текущих задач по проекту, а также еще несколько секретов методики позволяют командам повышать производительность на 50, 100 и даже 400%, заканчивая проекты в суперкороткие сроки. Например, бригада строителей, применяя метод Scrum, сделала ремонт в доме ровно за отведенные на это шесть недель. А в точно таком же доме, расположенном по соседству, уже без метода Scrum аналогичный ремонт затянулся на три месяца, потребовав не только в два раза больше времени, но и в два раза больше денег.
1. Что такое Scrum?
Чтобы тебе было проще понять суть методологии Scrum, давай рассмотрим её на простом примере из книги:
Итак, чтобы открыть производство бумажных самолётиков, нам понадобится 3 команды. Один человек будет считать готовые качественные самолёты. Другой будет их делать и попутно искать пути улучшения качества и скорости сборки. А задача остальных – сложить как можно больше качественных самолётов. Всего на это упражнение даётся 6 минут:
Этап 1. Планирование (1 минута) – все участники обсуждают предстоящую работу.
Этап 2. Изготовление (3 минуты) – каждый выполняет свою роль.
Чем же эта методика лучше других ты узнаешь из следующих выводов.
2. Результат важнее документов
Джефф Сазерленд в своей книге много раз доказал, что каскадная модель – это прошлый век. Бюрократия только тормозит работу. Серьёзно, когда ты последний раз заглядывал в рабочий архив? Можно строить бумажные небоскрёбы из ненужных отчётов и графиков, а можно вместо этого потратить больше времени на работу. Выбор очевиден, да?
3. Неспортивный спринт
В книге есть отличный способ выполнять работу быстрее – используй для готового списка задач чёткие временные отрезки (спринты). Тебе поможет эта схема:
1. Собери команду из 5-9 человек (если есть сотрудники)
2. Перед началом спринта составьте всей командой список общих задач
3. Запускай спринт (самое оптимальное время – 1-2 недели)
За это время все задачи из списка должны быть успешно выполнены. Если не получилось, на общем собрании разберите возникшие трудности и слабые места и учтите их в следующем спринте. Кстати, о собраниях следующий вывод.
4. Делай общий сбор
Чтобы работать быстрее, нужно устранять слабые места в работе. А чтобы их найти, проводи общие собрания перед началом каждого рабочего дня, но не дольше 15 минут. Этого времени достаточно, чтобы сотрудники успели поделиться трудностями и достижениями без приступов скуки.
5. Без приоритетов далеко не уйдёшь
Правильно расставленные приоритеты в задачах не только помогут сделать больше работы, но и освободят время на отдых. Давай проведём наглядный эксперимент из книги:
Засеки время и напиши на бумаге буквы, обычные цифры и римские в таком формате – А 1 I; Б 2 II; В 3 III и так далее (до 10-ти). Затем запиши результат и засеки время снова, но на этот раз записывай всё по порядку: АБВ – И; 123 – 10 и так далее. Какой из способов оказался быстрее?
Старайся группировать схожие задачи и сосредоточься на них.
6. Никаких должностей, только продукт
Scrum точно не для строгих боссов, которые любят всё контролировать. Джефф Сазерленд советует забыть о титулах и иерархии. Просто дай сотрудникам волю и позволь им делать под то, что они считают нужным и правильным (с возможностью нести ответственность). Осторожно, результат может приятно удивить!
7. Избавляйся от потерь
Если в работе часто что-то отвлекает или постоянно не хватает времени, тебе повезло. От таких потерь есть страховка, разработанная инженером компании Тойота – Тайити Оно. Он выделил 3 типа потерь:
Муда – действия, которые не приносят никакой пользы
Мура – неравномерность выполнения работы (неправильно расставленные приоритеты)
Мури – перегрузка и работа на износ
Избавляйся от них в работе и в жизни и будешь успевать гораздо больше.
8. Счастливые сотрудники – продуктивные сотрудники
Ещё одно важное правило Scrum – люди важнее процессов. Это значит, что пора забыть о переработках и звонках в нерабочее время как о страшном сне. Ты ведь не хочешь, чтобы сотрудник устал, выгорел и работал как сонная муха?
9. Забудь о наказаниях
Наказания сотрудников – это пережиток прошлого, который лишь убивает мотивацию. Если сотрудник допустил ошибку, нужно найти причину. Может он неправильно понял задачу или ему что-то мешает? Не наказывай, а ищи причину ошибки.
Ну а если ничего не меняется и человек очевидно валяет дурака, с таким сотрудником можно прощаться.
Читайте также: