Agile офис что это




Содержание страницы

Мода на agile. Чем полезен новый метод организации офисного пространства

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

Разные сферы трактуют методы agile по-своему. Для программистов это гибкая методология разработки программного обеспечения, для управленцев — эффективная практика организации труда небольших групп, для инвесторов — возможность из стартапа сделать «единорога» — компанию с капитализацией в $1 млрд. В недвижимости agile сегодня трактуется как некая гибкость офисного пространства, где в плотном взаимодействии работают участники создаваемой под проект группы. Современные офисы меняются вслед за мировыми трендами, а офисный рынок, в свою очередь, должен оставаться максимально гибким и готовым к трансформациям.

Офисы на перепутье

Уже в 2016 году, по данным Аналитического центра Национального агентства финансовых исследований, каждая пятая российская компания имела в штате хотя бы одного сотрудника, работающего удаленно. Некоторые организации решились на частичное использование незакрепленных рабочих мест. Освободившиеся «излишки» офисной площади стали распределяться на многофункциональные зоны — к примеру, переговорные, к функционалу которых добавился и кабинет руководителя: начальники департаментов покинули кабинеты и переместились в open space, а потребность в конфиденциальных встречах или совещаниях успешно реализовалась в увеличенном количестве переговорных зон разного формата.

Определенная гибкость офисного пространства для одних компаний стала инструментом оптимизации затрат и экономии площадей, а для других — способом повысить эффективность и лояльность сотрудников. Но надо понимать, что гибкий офис — это еще не agile. Agile-трансформация — это более глубокие изменения.

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

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

Философия agile — это система менеджмента «бирюзовых» компаний, в основе которой лежат самоорганизация, самостоятельность профессионалов, гибкий подход к созданию продуктов. Концепция пришла к нам от IT-корпораций, которые используют проектный подход и распространяют эту логику на все процессы. К примеру, в свое время по такому пути пошел знаменитый Microsoft. Трансформируя пространство и сокращая площади для закрепленных рабочих мест, такие компании распределяют место для многофункциональных зон, тем самым делая офис более комфортным и эффективным для групп разного количественного состава, работающих над проектами.

Модное явление

За последние годы мы отмечаем рост запросов заказчиков на организацию «гибких» пространств. Agile привлекает компании и просто как модное явление. Потребность быть в тренде есть у всех, но далеко не каждый готов разбираться в тонкостях организации гибкого офиса, привлекать специалистов и проводить серьезный анализ. Чаще всего в итоге создается классический офис с элементами гибкого пространства. Такие изменения тоже дадут плюс к комфорту и положительно скажутся на эффективности. Стоит признать, что, копнув глубже отдельных элементов, компании нередко сталкиваются с трудностями внедрения основательных изменений. Это происходит потому, что agile-офисы — сложные механизмы, и просто копирование отдельных свойств не приведет к нужному результату и эффекту. Для внедрения agile необходимо не только перестроить пространство офиса, но и провести глубокую аналитику со сбором большого количества данных и их анализом, а также подготовить команду для внедрения новых процессов.

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

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

Расчет пиковых загрузок офиса при этом достаточно прост: к примеру, если в компании 500 сотрудников, но при расчете пиковых значений оказывается, что максимально одновременно в офисе присутствует 450 (ввиду отсутствия людей в командировках, по причинам болезни или отпусков), то появляется возможность уменьшить офис на 10-15% или выделить освободившиеся площади для создания дополнительной офисной инфраструктуры и повышения уровня комфорта сотрудников. Если же расчетное значение в какие-то дни будет превышаться, то у администраторов офиса должна быть возможность организовать дополнительные рабочие места для сотрудников в неформальных зонах: благодаря их правильной организации риск превышения расчетных значений загрузки будет минимизирован.

Кусочки мозаики

Заимствование элементов, а не полноценное внедрение — это и есть текущий тренд на agile на самом деле. Примеров использования отдельных элементов agile на московском рынке немало. К примеру, для лофт-офиса IT-компании важно организовать правильные зоны отдыха. В ходе работы над одним проектом мы создали игровые зоны, где можно сыграть в дартс, настольный хоккей, заняться боксом. К слову, такие залы в рабочих пространствах сегодня становятся все более креативными. В одном из проектов московских офисов, например, мы работали над созданием звукоизолированной комнаты для занятий музыкой (в компании есть собственная музыкальная группа). Такая зона в офисе решает сразу несколько задач: это и возможность для сотрудников заниматься любимым делом при плотном рабочем графике, что повышает их лояльность, и способ объединения коллег за общим занятием.

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

Аккуратнее, но также активно компании используют такие новинки, как диваны с акустическими спинками, поглощающими внешние звуки: в таких мини-переговорных удобно проводить внутренние встречи, организовать conference call.

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

Agile по-русски

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

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

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

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по «гибкой» разработке программного обеспечения.

Суть agile-подхода изложена в «манифесте», но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum — это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг «Scrum для проектных команд«. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

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

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек

Product Owner — это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них «главного», который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет «администратор». Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи — это делает сама команда;
  • Мастер не заставляет людей делать работу — это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать — это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

  • какие требования являются приоритетными — это делает Product Owner.

На снимке ниже команда проекта проводит обязательный «ритуал» — Daily Meeting (см. ниже).

Команда проводит «ритуал» Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review — сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

  1. Заказчик не может сформировать четкие требования к ПО;
  2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
  3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

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

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

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы — управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile — владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

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

Зачем нужны agile-офисы?

4 августа 2017 г.

В своем первоначальном назначении аgile — это одна из методологий управления проектами в IT-индустрии. Как метод управления влияет на организацию рабочего пространства и почему agile-офисы вошли в моду?

Московский офис компании Avito

Что такое agile и с чем его едят?

Начнем с простого — по-русски agile произносится как «эджайл» и переводится как «гибкий».

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

Московский офис компании Avito

Пространство для работы и… жизни

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

Московский офис компании Avito

Суть в том, чтобы сотрудник мог сам делать выбор — как, когда, где и сколько ему работать. Постепенно изменяется само отношение к рабочему пространству — это больше не безликие однотипные столы, разделенные монохромными перегородками. Рабочие зоны должны отвечать разным запросам сотрудников и соответствовать стадиям, на которых сейчас находятся их проекты. Офис становится мобильным, гибким (иногда не только в переносном, но в прямом смысле слова!), может меняться.

Московский офис компании Avito

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

Московский офис компании Avito

Благодаря зонированию на четыре типа рабочих пространств стоимость содержания офиса уменьшается вплоть до 30%, неэффективные рабочие места исчезают, вместимость вырастает на 25-30%. Командная производительность увеличивается до 40%.

Московский офис компании Avito

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

Дизайн и атмосфера

Московский офис компании Avito

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

Московский офис компании Avito

Пока создание полноценного agile-пространства под силу в основном крупным игрокам рынка. В России такими офисами могут похвастаться, например, Google, Yandex и Avito. Несмотря на то, что сам метод подходит и для маленьких компаний, создание полноценного agile-пространства им вряд ли под силу: нужно привлекать дизайнеров интерьеров, делать на заказ мебель и так далее. Но это не повод отказываться от идеи совсем — пробковые доски с матрицами задач по проектам и зонирование помещения с помощью разной мобильной мебели (вроде кресел-мешков) совершенно точно доступны всем.

Личный опыт

Московский офис компании Avito

Об опыте создания agile-офиса для компании, далекой от сферы IT, рассказывает директор департамента управления объектами NAI Becar (входит в Becar Asset Management Group) Мария Онучина. «Becar Asset Management Group на своем примере смогла доказать всю пользу от применения agile-подхода к организации офисного пространства. В новый офис нашей компании переехало 150 сотрудников. В предыдущем офисе на каждого нашего сотрудника приходилось по 11 кв. метров площади, сейчас — по 6,5 метра. При этом визуально новый офис кажется более просторным, чем старый. Сумму, вложенную в проект по созданию офиса, мы рассчитываем окупить за полтора года. Универсальность agile-подхода в том, что мы используем основные его положения как основу для создания самого проекта и управления им, и в итоге agile становится идеологической основой офиса. Этот подход позволяет существенно сократить сроки воплощения мечты в жизнь. К примеру, сейчас идет строительство мансарды. Раньше нам бы пришлось писать сложное техническое задание на сотни страниц, долго его согласовывать, и в итоге реализация проекта растянулась бы минимум года на два. Сейчас же мы планируем потратить в несколько раз меньше времени, — говорит Мария Онучина. — Мы больше не занимаемся бесконечным подписанием бумаг и формализацией отношений, мы просто выбираем подрядчика с хорошим портфолио, обсуждаем с ним все идеи в режиме онлайн, принимаем решения и делаем работу».

Внедрение гибких процессов Agile/Scrum

Что такое Agile?

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

  • Scrum (подходит для организации взаимодействия между Бизнесом и ИТ);
  • Kanban (подходит для упорядочивания мультизадачности в работе сотрудника; хорошо сочетается со Scrum);
  • XP (принципы экстремального программирования);
  • Lean (принципы бережливой разработки).

Мы предлагаем Scrum, т.к. это отличный способ выстроить проект, который требует участия и Бизнеса и ИТ подразделения.

Scrum активно применяется в крупных компаниях и корпорациях.

Основная суть процесса следующая:

  • проект выполняется короткими итерациями (т.н. спринтами), каждая из которых длится от одной до 4 недель;
  • в проекте есть всего 3 роли: Product Owner, Scrum Master, Team. Роли эффективно взаимодействуют друг с другом и ориентированы на сотрудничество.
  • в Scrum есть всего 4 артефакта (документа): Product Backlog (требования к продукту), Sprint Backlog (требования, которые будут реализованы в спринте), Sprint Goal (цель спринта, итерации), BurnDown Diagram (диаграмма сжигания работ).
  • в Scrum есть всего 4 ритуала. Но читайте лучше об этом в соответствующей статье.

Команда проводит «ритуал» Daily Meeting

Преимущества Agile-подхода:

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

Услуга внедрения Scrum

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

  1. Обученных менеджеров вашей компании. Мы проведем обучение для всех сотрудников, которые принимают участие в проектах разработки ПО как со стороны Бизнеса, так и со стороны ИТ. Обучение будет проводиться несколько раз: Бизнес и ИТ, только ИТ, только Бизнес, только команда «пилотного» проекта и т.п. Всего пройдет не менее 5 сессий.
  2. Подготовленную Scrum команду. Мы поможем вам сформировать команду, которая будет первой трудиться над пилотным проектом и на примере которой мы покажем эффект. Мы оценим доступность (capacity) команды, предложим её фокус-фактор, подскажем как распределить ресурсы между разными проектами, учтем иные зависимости.
  3. Запуск «пилотного» проекта, на котором мы покажем как работает процесс «от и до». Это самая ответственная часть нашей работы. На примере пилотного проекта выползают все скрытые проблемы, которые мешают вашему бизнесу развиваться (конфликты ресурсов, отсутствие аналитиков, невозможность быстро принимать решение и пр.). Мы подскажем вам как правильно уйти от возникших противоречий и недопустить подобных случаев в будущем.
  4. Инструкцию для команд и мастеров. Простой и доступный документ, в котором описаны основные действия, необходимые команде и её окружению, чтобы правильно выполнять все процессы в Scrum.
  5. ИТ-окружение. Если у вас есть программное обеспечение для управления проектами, то мы поможем правильно использовать его в проектах, выполняющихся по Scrum.

Как происходит проект внедрения?

Наш подход по внедрению основан на двухнедельных этапах. Мы готовы выполнить проект всего за 3 этапа:

  1. Обучение и подготовка к внедрению. Мы готовим ваших сотрудников, оцениваем ваши процессы, помогаем выбрать пилотный проект. Также мы рекомендуем подписать Устав проекта внедрения Scrum, чтобы у всего предприятия было одинаковое представление о границах внедрения.
  2. Внедрение Scrum на пилотном проекте. Мы помогаем запустить процесс на вашем пилотном проекте. Проводим дополнительное обучение для команды и владельцев продуктов. Учитываем реальную загрузку команды, влияние других проектов и пр. Также мы разрабатываем инструкцию для Scrum-команд.
  3. Сопровождение вашего пилотного проекта. Если требуется проводим повторный инструктаж для команды. Каждый день мы проверяем, правильно ли ваши сотрудники выполняют ритуалы Scrum? Выявленные ошибки корректируются на месте.

Перед началом нашей работы мы согласовываем детальный график работ на первый этап и рекомендуемый график на этапы 2 и 3.

Чем Agile отличается от Scrum?

Если кратко, то Scrum — это одна из Agile-методик.

  • для продуктовых команд, которые хотят повысить скорость работы и увеличить бизнес-ценность создаваемого продукта;
  • для аутсорсинговых команд — если требование внедрения Agile/Scrum исходит от Заказчика, мы поможем понять как лучше отстроить процесс работы;
  • для организаций, которые хотят наладить взаимодействие между IT и бизнесом в рамках внутренних проектов автоматизации.

Burndown диаграмма в Jira

Цена и стоимость внедрения

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

Советы заказчику

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

Компания «Проектный офис» единственная компания в Беларуси, которая обучает и внедряет «гибкие» методики разработки ПО.

Мы помогаем:

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

Что такое Agile: методология, команда, оценка эффективности

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

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

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

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

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

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

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

Делай сразу!

Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это — как в знаменитой мотивирующей формуле «сделано — это лучше, чем идеально». Реализуйте первую функцию и начните тестировать ее, создавая следующую, и так раз за разом — вот главное правило.

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

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

Горизонтальная организация

Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах product owner’у, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

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

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

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

Как внедрить Agile?

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

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

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

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

Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается «Манифест гибкой разработки»:

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.