Текст книги "Agile. Процессы, проекты, компании"

1.4. Agile: процессы, кейсы, проекты

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

Джой Гамз, директор Project Auditors LLC

Agile и процессы

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

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

♦ работу исполнителей в процессах вместе и рядом, в одном помещении или использование, например, «аквариумных» видеоокон при удаленной работе;

♦ работу внутреннего владельца процесса, его участников, внутреннего заказчика процесса сообща, снижение потерь информации;

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

♦ лидерство и поддержку (далее введем термин «обслуживающее лидерство») владельца процесса, который задает направление и определяет правила сотрудничества и работы;

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

Business agility, или бизнес-гибкость

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

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

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

Бизнес-гибкость

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

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

✓ пересмотрена деятельность заместителей генерального директора, от многих из них отказались;

✓ вице-президенты покинули свои кабинеты и стали работать со своим персоналом как Agile-команды;

✓ кабинеты стали комнатами осведомленности (situational awareness room – SIT) о ситуации с продажами и прогрессом разработок, были вывешены белые доски с актуальной информацией и инфопанели;

✓ почти вдвое сократили количество периодических отчетов, остальные данные вносили в цифровом виде;

✓ стала применяться приоритизация важнейших для бизнеса вопросов: коммерческие предложения и удовлетворенность клиентов;

✓ использовались ежедневные 20-минутные утренние летучки – что было сделано вчера, чем заняться сегодня, какая и кому нужна помощь;

✓ проводились еженедельные (и даже ежемесячные) встречи вице-президентов с подчиненными;

✓ был организован онлайн– и видеодоступ ко всем сотрудникам.

Бизнес-гибкость проявляется в следующих направлениях:

♦ рынок: это оперативность или отклик рынка и оптимальные каналы, работа с большими данными, дизайн-мышление (сервис-дизайн);

♦ организационные моменты: распространение корпоративных знаний, цифровая культура и психология и управление изменениями;

♦ процессы: постоянная бизнес-аналитика, эластичность решений, организации и процессов, инновации в ПО и поиск/цепочка поставок.

Agile и управление кейсами

Кейс – это управление «решением конкретной задачи» для VIP-клиента или в особых условиях, например в работе врачей, юристов, консалтинге, исследованиях, проектировании или в общественных инициативах. Кейс включает описание конкретной исходной ситуации и способ ее разрешения, пути, выбранные участниками, их действия, материалы, относящиеся к делу, и полученный результат. К характеристикам кейса относится следующее[3]3
  https://habrahabr.ru/post/185858/


[Закрыть]:

♦ объектом управления является проблема (задача), а не собственно процесс;

♦ кейс объединяет участников, бизнес-процессы, контент;

♦ в ходе исполнения происходят (или вероятны) изменения процессов, подзадач, участников;

♦ высокий уровень неопределенности задач, недостаточно информации на старте;

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

Процесс работы с кейсом может включать шесть этапов.

1. Ассесмент (выяснение ситуации клиента кейса и ее оценка).

2. Планинг (планирование необходимых шагов).

3. Вмешательство (принятие мер).

4. Мониторинг (контроль, наблюдение за исполнением мер).

5. Оценка (оценка результатов, планирование помощи даже в случае неблагоприятного развития).

6. Реассесмент с повторением этапов 1–5.

Когда управление кейсом учится на прошлых ситуациях и формирует «лучшие практики», вводится термин «адаптивный кейс-менеджмент» (Adaptive Case Management, ACM, предложен в 2010 г. компанией Workflow Management Coalition). Такая технология позволяет гибко управлять решением задачи в зависимости от развития ситуации. Оформляют кейс, только если это имеет ценность в дальнейшем.

Agile и проекты

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

Спринт 2
Жизненный цикл проекта

Введение

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

Гарольд Керцнер

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

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

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

2.1. Предиктивный цикл

Проект без критического пути – как корабль без руля.

Н. Деан Мейер, автор работ по экономике и управлению

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

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

2. Подготовка к реализации: разработка полного содержания проекта и календарного плана работ; составление сметы на весь проект; определение и снижение рисков; заключение договоров с подрядчиками.

3. Организация основных работ: оперативное планирование; контроль за ходом работ; организация обеспечения; руководство, прогноз состояния; контроль основных KPI проекта (объем, качество, сроки, стоимость).

4. Завершение: сдача заказчику, подготовка документации и отчета, сбор уроков реализации проекта.

Циклы

Интересны сравнения таких циклов с баллистической траекторией и конусом.

Баллистическая траектория: точно прицелились в начале проекта, спустили «курок», подписывая договор, и внимательно следим за траекторией снаряда, ограничивая влияние ветра или других препятствий. Изменения вносить нельзя, от точности попадания в мишень зависит приемка результата проекта заказчиком.

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

Такие и подобные циклы, которые подразумевают последовательный переход с фазы на фазу без пропусков и возвращений, еще называют последовательными, «водопадными» (Waterfall), прогнозируемыми, предсказуемыми, классическими, типовыми или каскадными.

Первое их официальное упоминание приписывается статье Винстона Ройса, вышедшей в 1970 г., хотя сам автор и не использовал термин «Водопад», который, как считается, появился только в 1976 г.

При моделировании обсуждаемых циклов часто используют корпоративные или отраслевые шаблоны, или библиотеки фрагментов, иную регламентирующую документацию, которые формализуют управление, облегчают контроль и понимание статуса проекта, помогают обучаться и подбирать команду, типизируют риски и организацию проекта. По данным исследования PMI®, 12 % компаний применяют методологию Waterfall постоянно, 40 % респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25 % организаций[4]4
  https://habrahabr.ru/company/it-guild/blog/341932/


[Закрыть].

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

♦ иногда очень важно, чтобы переход от одной фазы к другой происходил только после полного и успешного завершения предыдущей фазы (подход Stage-Gate), например при передаче технической информации или сдаче технического элемента;

♦ в проекте объявлена жесткая необходимость обязательного расчета затрат и сроков при фиксированном содержании;

♦ лучше всего подходит для проектов, где создаются физические объекты, – от строительных до проектов по установке оборудования;

♦ требования заказчика непротиворечивы, известны, понятны и зафиксированы;

♦ все стороны хорошо понимают, какой продукт они создают, и этот продукт важен именно полностью и в конце проекта;

♦ проект не очень масштабный;

♦ графики и алгоритмы проектов можно использовать в будущем для идентичных или аналогичных проектов;

♦ проект типовой, существует понятное ТЗ, заказчик не хочет управлять проектом и похожие ситуации.

Гибкость на практике

Руководство компании Toyota, знаменитое созданием Lean и Канбан, часто критикуют за недостаток гибкости: до конца 2000-х для нужд производства компания пользовалась каскадной моделью разработки ПО.

Анализ разработки сайта в компании Ericsson AB показал, что предиктивный вариант привел к путанице и 26 % изначальных требований оказались просто бесполезными.

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

2.2. ИНКРЕМЕНТНЫЙ ЦИКЛ

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

Вуди Уильямс

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

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

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

Фавелы

Фавелы в Латинской Америке строятся по комнатам. У жителей времени много, зимы нет, как и денег. Они строят свою первую комнату из кирпичей, пока не кончатся или сколько есть. Потом достраивают, ставят окна, накрывают крышу и иногда даже штукатурят и красят. Когда семья растет, пристраивают следующую комнату.

2.3. Итеративный цикл

Нам не нужны повторяющиеся процессы, нам нужны повторяющиеся результаты.

Канадский программист Скотт Амблер

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

Кино

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

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

2.4. MVP

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

Скотт М. Граффиус. Agile Scrum: краткое руководство с пошаговыми инструкциями

По результатам итераций разрабатывается продукт с минимально необходимым набором возможностей или функций. Заказчик его оценивает, давая свои новые требования и по возможности начиная использовать этот продукт уже в своей деятельности. Такая версия продукта называется MVP – Minimum Viable Product (минимально ценный продукт) (исполнительный директор SyncDev Фрэнк Робинсон, 2001 г., позже Эрик Райс, основатель IMVU) или PSPI – Potentially Shippable Product Increment (готовое к поставке приращение продукта). Например, это базовая функциональность продукта, первый тестовый продукт для рынка.

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

Zappos – интернет-магазин обуви

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

2.5. Agile: комбинация итеративных и инкрементных циклов

– Начни с начала, – торжественно произнес Король, – и продолжай, пока не дойдешь до конца. Тогда остановись!

Льюис Кэрролл

Подходы, которые могут быть итеративными и/или инкрементными, предназначенные для создания MVP, уточнения элементов продукта и частой поставки заказчику, называются Agile или адаптивными циклами. Команда ожидает, что изменения будут вноситься в реальном времени на всем протяжении проекта и реализовываться за меньшую цену из-за частых итераций. После каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ и ценностей Agile – «реакция на изменения важнее следования плану». Итеративные и инкрементные подходы обеспечивают обратную связь, которая позволяет лучше планировать следующие шаги проекта. Контроль рисков и стоимости осуществляется с учетом поступления информации о требованиях и ограничениях.

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

Agile лучше применять, когда:

♦ потребности пользователей постоянно меняются;

♦ изменения реализуются за меньшую цену из-за частых инкрементов;

♦ проекты имеют дело с сервисноориентированными и нематериальными результатами, например изменения, копирайтинг или проектирование;

♦ надо быстро стартовать;

♦ значение ценности проекта в приоритете, а сроки и стоимость могут варьироваться;

♦ заказчик хочет активно участвовать в проекте на всем его протяжении;

♦ заказчик, проектировщик и исполнители находятся рядом и постоянно общаются;

♦ возможна пошаговая разработка, основанная на инкрементах, версиях (MVP);

♦ допустимы простые визуальные способы отслеживания (карточки на стене, а не формальные документы) и т. п.

К недостаткам Agile относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Необходимы регулярная вовлеченность заказчика и выделенная команда. Гибкость может приводить к потере фокуса. Отсутствие четкого процесса и процедур, разбиение проекта на подпроекты и частые изменения при отсутствии четкого направления со стороны руководства могут привести к потере ориентиров и понимания того, что важно, а что – вторично.