Что такое эффективная команда?

Работая в больших компаниях в общей сложности 15 лет, таких, как Сургутнефтегаз, Эр-Телеком, ФГУП «РЧЦ ЦФО», МТС, я постоянно встречался с командами, которых преследует ощущение малой эффективности. Взаимодействуя с лидерами команд и погружаясь в их процесс разработки продуктов, выяснялось, что команды реализовывают много задач, но не понимают, зачем и кто их явный потребитель. Команды угнетало, что, разрабатывая программный продукт в точности с техническим заданием, они получали результат, который не соответствовал ожиданиям руководства.

Погружаясь в процесс разработки, я понимал, что там просто нет команды. На каждый продукт выделялась рабочая группа с участниками. У каждого присутствует понимание, что без него продукт реализовать сложно. Но однако они работали по конвейерному принципу, да еще и над 10-15 продуктами единовременно. Соответсвенно, их подход к продукту был аналогичен принципу миниатюры Аркадия Райкина — «К пуговицам претензии есть?». И да, еще постоянно есть не хватка специалистов, а задач с каждым днем все больше и больше.

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

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

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

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

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

Итак, мы подошли к тому, что эффективная команда идет к общей цели, состоит из профессионалов (6-8 человек) и работают в одной комнате, участники команды непрерывно развиваются и обмениваются знаниями, быстро реагируют на обратную связь потребителя продукта и у них влиятельный лидер. А еще, эффективная команда настроена на достижение сложных и амбициозных целей. Команда готова непрерывно улучшаться, выходить за стандартные рамки решения задач и преодолевать трудности сообща!

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

Порекомендовать коллегам:

Agile как основа технологического бизнеса

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

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

Сейчас практически невозможно себе представить проект по разработке ПО, выполняемый по традиционным «жестким» методологиям, с планируемой поставкой на 2-3 года вперёд. Никто не может предсказать, как изменится внешний мир (клиентские потребности, требования к проекту, используемые технологии и т.д.) за это время.

На сегодняшний день гибкие методики (Agile — Scrum и Lean — Kanban) лучше всего адаптированы к постоянно ускоряющемуся развитию технологий, появлению новых средств разработки и все более переменчивым требованиям бизнес-заказчиков.

Гибкость приобретает сейчас особое значение в силу общих тенденций развития информационных систем.

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

Компания OnAgile регулярно проводит тренинги по Agile с выдачей сертификатов международного образца, выпускаемые консорциумом ICAgile и признаваемые компаниями во всем мире. Обучение имеет важное значение, так как позволяет познакомиться не только с инструментами, но с основой Agile-мышления, его ценностями и принципами, а так же научиться ими пользоваться.

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

Хотите сплотить команду и ускорить выход новых версий продукта до 1-3 недель? Наши консультанты готовы реализовать такой проект.

Порекомендовать коллегам:

Секрет головокружительного успеха ZARA (часть 2)

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

Time to Market

В ZARA хорошо отлажен не только процесс производства и логистики, но и процесс дизайна новых моделей. С момента принятия решения о разработке новой модели до появления её в магазинах (Time To Market) проходит всего 15 дней, в то время как у конкурентов это занимает 6 месяцев. Такая скорость произвела настоящую революцию в мире моды.
Классический подход подразумевает обновление коллекций один раз в сезон. Коллекцию заранее разрабатывают, затем производят большими партиями, затем доставляют в магазины. В ZARA всё совсем не так: модели обновляются постоянно, в среднем ZARA создает около 1000 новых моделей каждый месяц. Такой подход получил свое название — Fast Fashion, и он позволяет компании всегда оставаться в модном тренде.

Fast is the new Big

Парадигма скорости пришла на смену парадигме масштабов. Если раньше для победы в конкурентной борьбе нужно было укрупняться, то сейчас на первый план выходит скорость.
ZARA не переносила свое производство в Китай, как это делало большинство компаний. Такой перенос позволил бы снизить себестоимость изделий, но время поставки при этом бы увеличилось. В парадигме Big перенос производства в Китай это отличное решение: пусть чуть дольше, зато дешевле. В Zara думают по другому: в парадигме Fast такой перенос несет больше вреда чем пользы.

Обратная связь

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

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

Процесс дизайна в ZARA сфокусирован на потребителях больше, чем вы можете себе представить. Это яркий пример методики непрерывных улучшений (Kaizen).

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

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

Agilty

Узнай реальные потребности заказчика, как можно быстрее создай продукт удовлетворяющий этим потребностям. Сокращай время поставки (Time to Market), не делай лишнего, получай обратную связь как можно раньше. Все это принципы Agile, которые применимы во всех областях человеческой деятельности. И ZARA — это один из примеров воплощения этих принципов на практике.

Порекомендовать коллегам:

Что такое Непрерывная поставка (Continuous Delivery)?

Разрабатывая программное обеспечение в стремительно меняющемся мире, часто возникает вопрос, как оставаться конкурентно способным на рынке?

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

Ответ на эти вопросы лежит в практиках DevOps, одной из которых является непрерывная поставка (Continuous Delivery).

Непрерывная поставка (Continuous Delivery) — это подход к разработке программного обеспечения, при котором все изменения, включая новые функции, изменения конфигурации, исправления ошибок и эксперименты — поставляются пользователям максимально быстро и безопасно.

Непрерывная поставка — важный инструмент в современном процессе создания ПО. Весь процесс можно представить следующим образом:

  1. Разработчик отправляет свои изменения в систему контроля версии.
  2. На сервере сборки начинается процесс сборки поступивших изменений.
  3. Запускаются юнит тесты.
  4. Собранный пакет, после успешной интеграции, выкладывается на тестовый сервер.
  5. Заинтересованные лица, получают уведомления о выкладке новой версии ПО на тестовую площадку. Начинается вторая фаза тестирования, запускаются интеграционные, ручные, приёмочные, UI тесты и тд.
  6. После успешного прохождения предыдущих шагов, мы имеем готовый к публикации пакет, новой версии ПО.

Первые три шага в этом процессе — нам давно знакомая непрерывная интеграция. Далее идёт активная фаза тестирования, большая часть из которой полностью автоматизированна.

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

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

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

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

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

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

Если выпускать новые изменения небольшими партиями, релизы становятся обыденным событием для команды. Это мероприятие больше не вызывает панику и стресс, а наоборот мотивирует, давая возможность сразу видеть результаты своей работы.

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

Порекомендовать коллегам:

Секрет головокружительного успеха ZARA

В 1975 году Амансио Ортега Гаона открыл первый магазин одежды ZARA. В мае 2016 года Forbes оценил стоимость бренда ZARA в 10.7 миллиарда долларов.

На текущий момент открыто более 6000 магазинов ZARA в 88 странах мира. Именно благодаря ZARA ее основатель Амансио Ортега Гаона стал богатейшим человеком Европы, а в октябре 2015 года на несколько часов потеснил Билла Гейтса на пьедестале богатейшего человека мира.

Каким образом ZARA удалось занять лидирующие позиции в модной индустрии оставив конкурентов далеко позади?

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

“Чтобы добиться успеха, нужно одной рукой держаться за фабрику, а другой за покупателя”.

Принцип “Точно вовремя”

В ZARA очень малый процент распродаж: более 85% товаров ZARA продает по обычной цене, в то время как у конкурентов этот показатель составляет лишь 60-70%. Этого удалось достичь благодаря использованию подхода “Точно вовремя”, который был разработан в компании Toyota в 1948 году. В понятиях Toyota этот термин означает “делать только то, что необходимо, когда это необходимо, и только в необходимом количестве”. Эта методика нацелена на уменьшение потерь и несоответствий, на исключение ненужных этапов рабочего процесса, что в итоге приводит к повышению продуктивности.

Термин “Точно вовремя” широко использовался в бизнес среде в 80-х годах, но начиная с 90-х годов этот подход начали называть термином “Lean”. В самостоятельной форме термин “Lean” обычно не переводится на русский, однако в словосочетаниях, таких как “Lean Production”, “Lean Software Development” переводят как прилагательное: “Бережливое производство”, “Бережливая разработка программного обеспечения”.

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

Поток единичных изделий

Поток единичных изделий (One Piece Flow) — способ организации производства, предложенный Тайити Оно, главой компании Toyota. Это система, при которой изделия обрабатываются по одному либо небольшими партиями в соответствии с запросами потребителей. Поток единичных изделий является противоположным подходу массового производства:

  • Массовое производство — это производство огромного количества стандартных изделий.
  • Поток единичных изделий — продвижение изделий по производственной цепочке по одному в каждый момент времени.

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

Минимальные запасы

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

В ZARA товар не задерживается на складе, а в магазинах запасы сведены к минимуму. Отсутствие запасов компенсируется системой оперативного заказа, быстрого производства и доставки готовой продукции в магазины. Каждый магазин, дважды в неделю, в строго определенное время размещает заказ исходя из текущих потребностей. Примерно через 8 часов после размещения заказа товар уже упакован и готов к отправке со склада на северо-западе Испании. Благодаря централизованной системе логистики этот товар будет доставлен в любую точку мира в течении 48 часов.

Lean Business Model

ZARA является одним из ярчайших примеров хорошо отлаженной и устойчивой бережливой (Lean) бизнес модели вне индустрии машиностроения. Именно благодаря использованию принципов Lean у ZARA самый высокий показатель прибыльности в модной индустрии — 28%, что в среднем в 4 раза выше чем у конкурентов. Именно использование Lean позволило получить ключевые конкурентные преимущества, которые сделали ZARA лидером модной индустрии, и о которых я расскажу в следующей статье.

(продолжение…)

Порекомендовать коллегам:

Выбор пилотной команды для внедрения Agile

«С какой команды лучше начать пилотное внедрение Agile» — часто спрашивают нас клиенты, особенно в крупных компаниях.

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

Давайте подумаем, какая команда была бы идеальной для эксперимента внедрения Agile:

  • Небольшая (до 9 человек), сидящая в одной комнате
  • Без привлечения аутсорса (по fixed price & fixed scope контракту)
  • С некритичным для бизнеса продуктом или сервисом
  • С одним, явным и хорошим Продукт-оунером (менеджером), готовым тратить почти все свое время на команду
  • С минимумом зависимостей и интеграций
  • Придумайте что-то свое 🙂

Звучит немного утопично, правда? 🙂

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

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

Что касается остальных факторов, да, они обязательно добавят нам сложностей, но они решаемы.

Например, если сейчас мы работаем с подрядчиками по fixed price модели, никакого Agile нам не построить. Но в самом начале пилота мы просто возьмем и перейдем на time&material. Мы это делаем в 90% случаев во всех компаниях и обычно это занимает всего недели две согласований.

Тоже самое с продукт-оунерами. Например, сейчас развитием продукта управляют четыре человека, из четырех разных подразделений компании. Наша задача в первые дни пилота либо выбрать одного из них (так, чтобы остальные согласились), или выделить так называемого proxy-product owner’a с нашей стороны, который будет единым окном для команды. Но это только как временное решение, потому что настоящий PO должен обладать видением стратегии продукта, хорошим пониманием рынка и бизнеса.

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

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

Порекомендовать коллегам:

Весенняя подборка тематических книг по Agile

Незаметно сменился целый сезон, и на календаре — пора преображений, обновлений и отличного настроения.

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

— книга КРАСНАЯ — «Скрам», Джэфф Сазерленд

— книга БЕЛАЯ (чем не яркий цвет:)) — «Постигая Agile», Эндрю Стеллман, Дженнифер Грин

— книга БИРЮЗОВАЯ (здесь небольшая интрига: поймешь почему именно БИРЮЗОВАЯ, когда начнешь читать) — «Открывая организации будущего», Фредерик Лалу

Приятного чтения!

Порекомендовать коллегам:

Почему Agile не работает (Shu-Ha-Ri)

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

Я хочу познакомить вас с концепцией Shu-Ha-Ri. Она берёт истоки из восточных единоборств, и описывает стадии обучения через которые проходит ученик в процессе познания мастерства.

Стадия Shu (守)— “следуй правилу”. На этой стадии ученик обязан соблюдать все рекомендации учителя. Цель — научиться делать именно так, как говорит мастер.

Следующая стадия Ha (破) — “сломай правила”. На этой стадии ученик начинает отходить от правил, пробовать, экспериментировать. Именно на этой стадии происходит глубокое познание сути изучаемой техники. Ломать правила, анализировать полученный результат, сравнивать с эталонным, делать соответствующие выводы.

И последняя стадия Ri (離) — “отделение от правил”. На этой стадии человек уже впитал в себя суть методики, осознал самую суть учения. Ему уже не нужны правила, он просто действует естественным для себя образом.

Давайте рассмотрим на примере приготовления пищи. Сперва вы готовите точно по рецепту, тщательно взвешивая ингредиенты и действуя согласно инструкции. Это стадия Shu. Первый блин комом, дальше — лучше, в какой-то момент у вас получается неплохо. Чем больше вы готовите блюдо, тем лучше оно у вас получается. И вот, когда вы научились стабильно получать хороший результат, вы переходите на уровень Ha.

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

На уровне Ri вы просто готовите. Если у вас спросить рецепт с точными характеристиками и последовательностью — вы, скорее всего, не сможете быстро ответить. В вашем описании будут присутствовать словосочетания “на глаз”, “по вкусу” и другие расплывчатые формулировки.

Если всё так просто, то почему столько людей не умеют вкусно готовить? 🙂

Самая распространенная ошибка — слишком ранний переход на стадию Ha. Не получилось по рецепту — дай-ка я сделаю по-другому. Ой, опять не получилось — видимо надо тут подправить. И так до бесконечности. Поиск — это хорошо. Но если человек не научился делать по методике, то без методики у него шансов ещё меньше. И даже если получится — это будет случайность, которая в будущем, скорее всего, не повторится.

Стадия Ha требует не только успешного освоения методики на уровне Shu. Еще она требует высокого уровня осознанности при тестировании правил. Нужно обязательно измерять результаты экспериментов, сравнивать с эталонными, анализировать и делать выводы. Без этого теряется суть стадии Ha, и со временем все превратится в хаос.

Ловушка гибкости (agility)

И вот мы подошли к ловушке гибкости. Настоящая гибкость (agility) начинается на стадии Ha и расцветает на стадии Ri. Но сама суть Agile провоцирует людей на преждевременный переход на стадию Ha, со всеми вытекающими негативными последствиями: Agile не запускается, буксует, не помогает.

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

Как и в любом деле, помочь здесь может привлечение опытного эксперта, который перешел на уровень Ri и готов провести вас, вашу команду, вашу компанию через этот путь. Эксперт, который скажет вам что делать (уровень Shu), предостережет от опрометчивых действий (преждевременный переход Shu-Ha), обратит ваше внимание на неочевидные аспекты (уровень Ha), как коуч поработает с вашей осознанностью (уровень Ha).

Порекомендовать коллегам:

Увеличение гибкости (agility) компании

Dave Thomas, один из авторов Agile Manifesto, в своем интервью раскрывает понятие «гибкости» компании. Вот небольшой отрывок из его интервью.

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

Отличный вопрос!

Во-первых, я на 100% согласен с его сутью — гибкость начинается с личностей и распространяется вокруг. Она никогда не может быть просто “спущена» сверху.

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

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

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

Давайте вернемся к четырем шагам, являющимся основой гибкости, которые мы обсуждали ранее:

1. Понять, где мы находимся сейчас

2. Сделать небольшой шаг вперед, в направлении, куда мы ходим прийти

3. Посмотреть и оценить, что произошло

4. Повторить

Шаг 1. Понять, где мы сейчас. Здесь специально используется “мы” вместо “я”, так как мы работаем командами. И нам нужно понять, где сейчас находится наша команда. Это не работает на одиночного сотрудника, который решил стать лучше. Вместо этого, шаг 1 должен использоваться всей командой чтобы почувстововать, где она находится, и куда она хочет прийти. На этом месте переходим к шагу 2.

Шаг 2. Сделать небольшой шаг вперед. Какое минимальное изменение должно быть сделано, чтобы сдвинуться в нужном направлении? Это может быть даже 10-минутный стендап, который команда решила начать делать ежедневно, чтобы улучшить понимание текущей ситуации. Или это может быть наоборот, отказ от стендапа, потому что это пустая трата времени для команды. Решите, какое изменение необходимо, и внедряйте его. Но только на ограниченное время (например, две недели).

Шаг 3. Посмотреть и оценить, что произошло. Что чувствует команда? Начали мы работать лучше или хуже? Почему? Что еще мы можем сделать? Можем ли мы улучшить наше изменение? Или лучше отказаться от него? Или преобразовать во что-то другое?

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

Шаг 4. Повторить. Потому что стагнация ведет к гибели.

 

Оригинал и полное интервью Дэйва

Порекомендовать коллегам:

Что такое Scrum и как он работает

Что такое Scrum?

Scrum — это процессный фреймворк. Это значит что он гибкий и у него очень широкая область применения.

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

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

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

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

Скрам выделяет отдельную роль, которая управляет ценностью — Product Owner, или владелец продукта. Именно он определяет, какую ценность мы создадим в текущем спринте, а какую отложим на следующий. Таким образом владелец продукта отвечает за максимизацию ценности для заказчика. “Что мы можем сделать в следующем спринте, чтобы это было максимально ценно/полезно?” Над этим вопросом владелец продукта должен думать каждый день, готовясь к следующему спринту.

Все идеи и пожелания владелец продукта складывает в Product Backlog. За много лет так и не нашлось удачного перевода термина backlog, поэтому по русски так и называют — беклог. Беклог продукта это упорядоченный перечень всех пожеланий и идей, над которыми будет работать скрам команда. Посмотрев в беклог продукта любому заинтересованному лицу должно стать понятно, что и в каком порядке будет делаться. Управляет беклогом владелец продукта.

Структура спринта

Скрам четко определяет структуру спринта. Спринт начинается с планирования спринта и заканчивается обзором спринта и ретроспективой. В середине спринта скрам регламентирует лишь ежедневные 15 минутные встречи. scrum-events

Планирование спринта

Цель встречи — определить цель спринта и составить Sprint Backlog (спринт беклог). Обязательно присутствие всей скрам команды и владельца продукта. Владелец продукта рассказывает команде о цели спринта, отвечает на вопросы команды. Команда обсуждает реализацию, выясняет важные детали у владельца продукта, составляет перечень задач, выполнив которые команда достигнет поставленной цели. В конце встречи все одинаково понимают цель спринта, и в команде сформировано общее понимание как и что нужно сделать для достижения поставленной цели. Рекомендуемая длительность встречи — не более 4 часов для 2-х недельного спринта.

Ежедневный скрам митинг

Ежедневные встречи — это способ координировать усилия членов скрам команды, оперативно выявлять проблемы, создавать прозрачность текущей ситуации. Команда собирается у доски задач, и каждый участник скрам команды по очереди отвечает на 3 вопроса: Что я сделал вчера? Что сделаю сегодня? Что меня тормозит и мешает двигаться вперёд? Время жестко ограничено — не более 15 минут, поэтому на этой встрече команда только выявляет проблемы. Поиск решения выносится за рамки этой встречи.
daily-scrum-meeting

Обзор спринта

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

Ретроспектива спринта

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

Целостность скрам

Скрам — это идеально сбалансированный инструмент. В нем нет ничего лишнего, и каждый элемент имеет свою ценность и предназначение. Именно целостное применение скрама даёт максимальный синергетический эффект. Если убрать какой либо элемент — баланс нарушится, что негативно скажется на результатах.
Однако на практике приходится встречаться с искалеченным скрамом, когда некоторые элементы не используются. Такой искалеченный скрам даже получил собственное наименование — ScrumBut, или по русски СкрамНо.
Почему же так происходит? Казалось бы, всё очень просто, бери и делай. Да, берут, делают, но потом какие то элементы отменяют, так как они не приносят пользы. Люди всегда стремятся избавляться от того, что не приносит ценности, и это проявление мудрости. Проблема не в том, что элемент плохой. Проблема в том, что он используется неправильно. И даже эта проблема предусмотрена в скрам.

Скрам-мастер

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

Обучение скрам мастеров

На основе многолетнего опыта работы со скрам командами мы разработали тренинг Advanced Scrum Master. Посещение этого тренинга — это низкий старт для начинающего скрам мастера, и прокачка навыков для практикующего.

 

Порекомендовать коллегам: