Что такое agile-подход и зачем он нужен бизнесу?

Содержание

Внедрили кросс-дисциплину t-shape

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


Схематическое отображение t-shape

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

Важно!
Scrum-команды и люди в Scrum-командах должны быть специалистами в том, что они делают, и интересоваться смежными сферами.

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

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

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

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

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

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

III Анализ явления гибкие методологии

1. Определения Гибких методологий

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

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

Использование постоянного тесного взаимодействия всех членов команды, включая заказчика

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

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

Подобные приемы скорее всего позаимствованы из более ранних методик. Например, это практикует RUP.

2. Разберем основные идеи Agile Manifesto

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Пункт 1Пункт 2Пункт 3Пункт 4.

3. Обсудим принципы Agile Manifesto

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

Манифест Agile

Вернёмся к документу 2001 года, который стал основой современных принципов гибкого метода.

Четыре основополагающих идеи манифеста:

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

Принципы манифеста Agile:

  • Удовлетворение потребностей заказчика важнее соперничества и внутренней иерархии. Это достигается непрерывной работой и мгновенным исправлением ошибок.
  • Быстрая реакция на изменения требований к продукту.
  • Непрерывный темп с повторяемой скоростью работы.
  • Поддержка вовлечённых сотрудников. Мотивированная команда выполняет работу лучше, чем недовольные условиями труда специалисты.
  • Тесная коммуникация лицом к лицу с заказчиком и всеми членами команды разработчиков на протяжении всего проекта.
  • Простота, как основа работы.
  • Маркетинговый план должен обновляться как можно чаще – раз в две недели или полтора месяца.
  • Отказ от условностей и субъективных мнений в пользу детального изучения заказчика, внедрения изменений и анализа результатов.
  • Несколько краткосрочных тестирований актуальнее одного долгосрочного эксперимента.

Статья в тему: Что такое CRM и зачем она нужна

II Предыстория возникновения методик разработки программных продуктов

2. А что, если не Waterfall?

  1. Циклический подход производства ПО. Жизненный цикл проекта RUP разбит на 4 фазы и 9 рабочих процессов.
  2. Итеративный процесс разработки. Проект RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель.
  3. Обязательная разработка требований. Для описания требований в RUP используются прецеденты или варианты использования (use cases). Каждый прецедент использования является описанием сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу.
  4. Инкрементный подход, направленный на поэтапное приращение функциональности продукта. Основной единицей планирования итераций является прецедент использования, что позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.

Минусы Agile

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

Некоторые организации очень беспокоят такие издержки. Их можно снизить, если создать для команды условия, в которых она сможет быстро и как можно менее болезненно ошибаться согласно неофициальному девизу Agile «Fail Fast — Fail Safe» («Ошибайся как можно раньше — ошибайся безопасно»). Однако такие структуры и среды также стоят дорого. 

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

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

Agile как инструмент в конкурентной борьбе

Очень часто мы сталкиваемся с коварный ситуацией:

Agile в производстве

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

Но есть довольно интересный нюанс:

Объедините в Agile команды специалистов по маркетингу и продажам вместе с конструкторами и специалистами по производству.

Управление по Agile: создаем стандрат

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

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

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

Agile риски внедрения

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

Консультанты по Agile отмечают, что примерно 25%-30% проектов, связанных с внедрением гибких методов управления заканчивается неудачами и основная причина связана с отсутствием правильной подготовки или системы мотивации со стороны персонала.

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

Рекомендация экспертов по Agile в этом случае проста:

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды размером до 9 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 будет планирование ближайшей итерации, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Область применения Agile

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

Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Одно из ключевых ограничений Agile кроется в словах «для разработки новых продуктов». Пусть «продукт» здесь употребляется в самом широком смысле, но вот новые продукты все-таки разрабатывает лишь небольшой процент людей. А особенно эффективно Agile себя проявляет лишь в творческой работе и/или в условиях неопределенности. В противном случае накладные расходы на Agile-процессы могут превышать выгоды от Agile с точки зрения бизнеса, особенно при неумелой настройке этих процессов.

  • Agile целесообразно применять в ситуации, когда первую версию продукта нужно выпустить на рынок как можно быстрее, иначе конкурентная борьба может быть проиграна.
  • Другая ситуация, когда ценности Agile будут наиболее эффективны: инновационный продукт с заранее непредсказуемыми свойствами и/или с нестандартными средствами (новыми технологиями) для его разработки.

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из (11 видео, 65 минут).

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

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


Спринты в Scrum

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»). Жизненный цикл задачи отображается на канбан-доске, физической или электронной

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

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


Задачи на Канбан-доске

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5.

Agile команда в российском бизнесе

У небольших компаний очень большое преимущество при внедрении Agile, так как эджайл создан для небольших команд: 7-10 человек идеальный состав для Agile команды.

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

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

Agile изменяет мышление и мировоззрение, фокусируясь на достижении цели, используя коммуникации, а не командно-административную структуру.

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

Ошибочно также полагать, что Agile может увеличить результативность вашей компании моментально, все зависит от двух факторов:

  1. от ваших сотрудников
  2. и ваших бизнес-процессы,

а они уникальны в каждой компании!

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

Изучите инструменты для контроля

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

  • Trello — подходит для маленьких проектов, быстро и удобно.
  • Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
  • Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

Чек-лист — как начать использовать Agile и Scrum на проекте

  • Научиться вести бэклог и расставлять приоритеты.
  • Проводить спринты.
  • Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
  • Контролировать работу с помощью диаграммы сгорания проекта.
  • Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
  • После каждого спринта демонстрировать проект.
  • Изучить инструменты и найти самый удобный.

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

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

Построение Agile команды в компании

Сформировать Agile команду можно довольно быстро, на это может потребоваться несколько дней, но сколько времени потребуется на «притирку» участников команды?

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

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

Agile методология это:

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

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

Какие компании используют Agile?

Очень популярны Agile методы в ИТ компаниях: Google, PayPal, Facebook, что вполне логично, так как эджайл пришел из ИТ, в России первые проекты в области Agile стал внедрять Сбербанк, по данному вопросу есть мои статьи:

  • Внедрение Agile в Сбербанке: гибкое управление в банке
  • Как внедрить Agile в банке

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

  • Agile руководство шаг за шагом
  • Agile методология в холдинге, на примере ИКЕЯ
  • Agile в государственном секторе управления

Примеры проектов и применение Agile

Кейсов применения Agile в мире великое множество, и наша страна тоже не отстает. В первых рядах практиков гибких подходов в России стране идут IT-компании. За ними следуют банки и страховые компании. В основном это команды, так или иначе связанные с ИТ. Однако есть и менее типичные кейсы. 

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

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

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

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

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

Благодаря масштабируемости Скрама несколько команд могут работать на создание новых продуктов и каналов продвижения в диджитал-среде для страхования автомобиля.

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Фокусировка на нуждах и целях клиентов

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

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

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

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

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие принятые в Agile методы описания гипотез и процессов.

Неудобные вопросы

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

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

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

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

Хотите использовать гибкие методы? Вам нужна гибкая организация!

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

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

Проектная команда по внедрению Agile

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

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

Методы гибкого управления Agile (эджайл) позволяют:

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

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

Мы узнали что-то новое? Скорее всего нет, а с другой стороны ДА!

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

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

Как внедрить

Agile нельзя внедрить. Agile — это трансформация процессов и культуры организации. 

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

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

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

Затем обучите команду. Для старта лучше всего подойдут широко распространенные подходы — Scrum или Kanban. По ним много материалов, проще найти курс для команды и нанять сотрудников, знакомых с методиками и инструментами. Выделите два или три дня для глубокого погружения участников команды и заинтересованных сторон в новый процесс. 

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

Следующие шаги индивидуальны — кто-то запускает еще несколько команд. Другие запускают масштабную трансформацию, а некоторые вообще отказываются от Agile.