Для чего agile трансформация
Мода на agile. Чем полезен новый метод организации офисного пространства
Сегодня перед бизнес-сообществом стоит выбор: либо меняться под новые запросы рынка, либо выбывать из гонки. Темой трансформаций увлечен весь топ-менеджмент, от руководителей крупнейших госкорпораций до небольших мобильных начинающих компаний. Во главу угла ставятся гибкость и 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-трансформация: гибкое путешествие к продуктивности
Всем привет! Уже на следующей неделе мы запускаем курс «Руководитель разработки», который посвящен управленческой деятельности во всех её аспектах в контексте руководства командой разработчиков. В преддверии запуска делимся с вами переводом статьи, которая может стать полезной для будущих тимлидов.
В последнее время много чего происходит из-за того, что некоторые организации переходят на Agile, уделяя больше внимания самоорганизующимся командам, дополнительным результатам и максимальной привлекательности для бизнеса. Однако всякий раз, когда кто-то читает об этой трансформации, обычно информацию преподносят с точки зрения организации и того, как Agile влияет на нее в целом. 
Но хотя со стороны может показаться, что организация представляет собой некую безликую монолитную структуру, мы знаем, что она состоит из живых, дышащих людей, которые сами поставляют товары и услуги, которые предоставляет организация. Таким образом, мне кажется важным рассмотреть, как это повлияет на тех, кто должен иметь дело со своей личной Agile-трансформацией.
Я занимаюсь традиционным управлением проектами более двадцати лет. Я также преподаю управление проектами, и я всегда любил говорить своим студентам, что управление проектами, как и бухгалтерский учет, является зрелой профессией. Бухгалтеры говорят о дебетах и кредитах, и единственное, что действительно периодически меняется, — это налоговый кодекс. Лингва франка управления проектами на протяжении многих лет является такими артефактами, как диаграммы Ганта и структуры декомпозиции работ.
Но в значительной степени почва начала меняться под ногами традиционных (плано-ориентированных или каскадных) руководителей проектов, особенно в последние несколько лет. Это связано с тем, что Agile-подход, первоначально определенный в манифесте в 2001 году, наконец начал закрепляться в корпорациях. Нет, я бы даже сказал, до такой степени, что он заменяет традиционные методы.
Достаточно важно, что руководители проектов теперь должны быть не только осведомлены об этом, но также должны начать думать об обучении этому и приобретении опыта. (Его более широкое признание в этом бастионе традиционного управления проектами, шестом издании PMI, является довольно значительным событием).
На личном уровне я получил сертификацию Scrum Master в начале 2013 года, но никогда не использовал ее, по крайней мере, изначально. Это было не столько, что я был против Scrum, сколько то, что я работал в традиционном управлении проектами и действительно не был свидетелем революции из первых рядов.
Но постепенно я начал понимать, что будет существенный сдвиг в направлении использования Agile и что для того, чтобы оставаться актуальным — и, я мог бы добавить занятым, — необходимо будет начать знакомиться с Agile-проектами и работать в них.
Размышляя об этом, я понял, что, пожалуй, самое первое, с чем мне пришлось столкнуться в Agile, это тот факт, что роль менеджера проекта не только не столь значительна, а на самом деле нет определенной роли PM как таковой. В варианте Scrum есть только три определенные роли — Scrum Master, владелец продукта и команда разработчиков.
Когда я получил сертификацию Scrum, я уже тогда понял, что это был другой тип роли. Как руководитель проекта, я мог бы — и должен — делать все планирование с моей командой. Но когда приходит время решать, кто что и когда делал, это всегда была моя работа. Это очень большая структура командования и управления. И не только я ожидал возглавить команду, команда ожидала, что ее возглавят.
Но в Agile все по-другому. В этой роли я больше помощник или тренер, нежели поводырь команды. Команда самоорганизуется, и это означает, что, хотя я могу помочь устранить препятствия для них, моя задача не в том, чтобы сказать им, что делать как таковое. Их задача — выяснить, что делать в команде, а Scrum Master’а — помогать и тренировать.
Ниже вы найдете несколько полезных советов о том, как добиться успеха в Agile-трансформации.
Это серьезный сдвиг не только для руководителей проектов, но и для команд. Менеджеру проекта следует перестать быть директивным и начать оказывать содействие. Для многих руководителей это очень сложный переход. Они не знают, как не руководить. И, скорее всего, если они долгое время были PM, они очень привыкли использовать планировщик, такой как MS Project. Но команде Scrum не обязательно нужен такой инструмент, предпочитая инструменты рабочего процесса, такие как Jira, для отслеживания прогресса.
Проблема состоит в том, что традиционный менеджер проекта должен сдерживаться, говоря команде, что делать, когда они спрашивают. Он или она может устранять препятствия, когда они возникают. Но его или ее лучший совет, когда его спрашивают, что член команды должен сделать, так это «поделиться с командой». В некотором смысле, он или она должен переосмыслить то, что он знает, и выбросить некоторые из своих навыков в окно.
И не только у премьер-министра может возникнуть проблема с адаптацией к этой новой реальности. Представьте себе члена команды, который привык получать указания что делать в иерархической системе. Теперь он или она сталкиваются с тем, что нужно быть в определенной степени самостоятельным. Некоторые предпочитают не переживать этот опыт.
И хотя Agile можно использовать для самых разных проектов, он все еще активней используется в средах разработки программного обеспечения. А некоторые разработчики, например, привыкшие работать в одиночку, теперь должны ежедневно встречаться не только с командой, но и с “бизнесом”. Для некоторых это за пределами их зоны комфорта. Я разговаривал с женщиной на конференции Agile, которая сообщила мне, что несколько разработчиков в ее команде попросились переехать или покинуть компанию, когда появился Agile.
Я думаю, что главный вывод здесь — принятие изменений и адаптация. (По иронии судьбы, отличительные черты самого Agile.) Некоторые люди просто предпочитают делать вещи так, как они всегда это делали. И затем, когда изменение настигает их — как, конечно, это происходит в проворном мире — они не могут вносить изменения и оказываются снаружи, глядя внутрь.
Как только я понял, что мне нужно попасть в тот мир, я совершил переход не только обучаясь, но и применяя гибкое мышление. (Именно этим и помогают команды Agile-тренеров.) Я начал читать все, что мог, занимался нетворкингом, насколько мог, и затем, когда пришло время, направил эти знания и мои годы в управлении проектами в компанию, которая будучи Agile-готовой, все еще видела ценность обоих подходов. И когда я отпустил необходимость контролировать ситуацию и понял, что мне нужно быть тренером и помощником, я обнаружил, что все стало на свои места.
Традиционно ждём ваши комментарии и приглашаем на открытый урок, который уже сегодня проведет Станислав Михальский — директор по разработке в «Биглион Технологии».
Что такое Agile и подойдет ли он вашей компании
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
4 подводных камня Agile-трансформации
Мы выбрали Agile 5 лет назад еще на старте компании, как способ цифровой трансформации и оптимизации внутренних процессов. Сегодня рассказываем, где, обо что и сколько раз спотыкались в ходе внедрения.
Методология Agile появилась около 20 лет назад. Гибкая, направленная на прозрачную, эффективную коммуникацию, синхронизацию команды, оптимизацию затрат. Основная цель Agile-трансформации — ускорение поставок и выхода продуктов на рынок. Исследование ScrumTrek показало, что у 47% респондентов это получилось еще при тестировании пилотной версии новой системы. Но в Agile-трансформации есть 4 подводных камня, о которые стремительно разбиваются все стратегии внедрения. Мы споткнулись обо все и решили рассказать о своем опыте.
Важно сказать, что это не мануал по внедрению, не статья об основах Agile. Здесь вы не научитесь внедрять методологию за 10 понятных шагов. Если ваша цель в этом, лучше пройдите практический курс по управлению проектами по Agile. У нас, кстати, такой курс есть. Если интересно, можете заглянуть в раздел «Обучение» на сайте RocketSales.
Эта статья поможет тем, кто уже понимает основу методологии, избежать сложностей, о которых не пишут в учебниках. Потому что это честный опыт малого представителя IT-бизнеса.
Мы выбрали Agile 5 лет назад еще на старте компании, как способ цифровой трансформации и оптимизации внутренних процессов. Agile часто привлекает команды, которым путь к результату не менее важен, чем его достижение. Мы в RocketSales много работаем не только в процессе, но и над процессом. Стараемся делать все лучше, быстрее, легче. Поэтому выбрали философию Agile, основанную на умении подстраиваться под непредвиденные обстоятельства, быть гибкими и открытыми к новому.
Agile действительно рабочая методология в руках умелого управленца. Но при неправильном подходе он становится обузой. Сотрудники сначала удовлетворяют запрос собственника, выполняя бессмысленные на их взгляд ритуалы, а потом по-старинке идут решать свои задачи. В итоге у топ-менеджмента нет реальной картины прогресса проектов, а у команды нет инструментов, которые бы помогали эффективно решать задачи.
Сложно приучить команду работать в рамках неудобной системы управления проектами. Если это все же получилось, еще сложнее сломать всю систему и построить правильную с нуля. Это как кости, которые срослись неправильно. Придется ломать и соединять по новой.
Внедрить гибкое управление проектами компаниям из всех отраслей мешают практически одни и те же факторы:
Давайте остановимся подробнее на каждом из них.
Agile в небольших компаниях часто начинается со Scrum. А Scrum – c этой книги:
Книга отличная, но Джефф Сазерленд вряд ли предполагал, что ее будут использовать как единственный источник знаний про Scrum. Что случается в компании, топ-менеджер которой прочитал эту книгу?
Одна из ошибок неопытных Agile-внедренцев в том, что они пытаются вырвать зуб пассатижами. Или покрасить стены кисточкой для бровей. Назначение пассатижей – вырывать, но не зубы, а гвозди. А кисти для бровей – красить, но, уж понятно, не стены. Инструмент вроде применяют по назначению, но без учета потребностей процесса.
Мы, как и многие, пытались идти от инструмента. Клеили стикеры на Scrum-доску, использовали Kanban для управления задачами. Этапов на наших досках становилось все больше. И как только менялась одна переменная – появлялся внешний подрядчик, требовалось дополнительное согласование с клиентом и т.д. – весь процесс становился непригодным.
Одна из главных вещей, которую мы поняли за 5 лет – все нужно пропускать через призму здравого смысла. Теперь мы ищем свои подходы к системе управления проектами и смело меняем то, что не нравится команде. Мы перестали использовать стикеры, бейджи, отошли от идеи с Kanban доской даже в электронном формате. Как только появилось сопротивление частым собраниям, мы поменяли установку и сделали координацию еженедельной. Исчезло отторжение, команда увидела, что цель внедрения методологии – помочь им легко справляться с поставленными задачами.
До 2020 года корпоративная культура RocketSales представляла собой классические правила и принципы работы компании. Не опаздывать, общаться вежливо, строить долгосрочные отношения с коллегами и клиентами. В прошлом году мы много времени уделили внедрению новой корпоративной культуры, важной частью которой стали понимание своей роли в миссии компании, уважение и требовательность к себе и остальным коллегам.
Если в компании не принято давать обратную связь, обмениваться инициативами или прозрачно вести свои проекты, внедрить проектную методологию, основанную на всем этом будет сложнее.
Мы вписали рабочие инструменты в признанную командой инфраструктуру и показали, как качественная система управления проектами улучшает качество нашей деятельности.
Это сейчас мы научились легко вдохновлять на Agile новых сотрудников. На первых этапах мы не придавали много значения разговорам с командой. Вот методология и, поверьте на слово, она работает. Но если оставить сотрудника один на один с незнакомыми инструментами, он, скорее всего, в них «закопается».
Поэтому важно сделать систему обучения хотя бы трехступенчатой:
За 5 лет мы сменили 4 отдела маркетинга и столько же отделов разработки. Мы вели доски, путались в приоритетах задач. И, самое страшное, никто не знал, чем занимаются остальные. Мы подумали, как показать всем объем работы, выполняемой отделами? Как сделать влияние каждого действия сотрудника на финальный результат прозрачным?
Мы ввели в практику большие годовые итоговые планерки, а также регулярные дайджесты новостей. Все остальное за нас сделали Agile и Asana (ну, ладно, Asana мы интегрировали с TimeDoctor, чтобы показать, сколько человек и как долго работали над каждой конкретной задачей). И постановщики задач, и их исполнители увидели, сколько людей участвует в поиске решения и в его реализации. Мы получили прозрачность и спокойствие.
Жизнь предпринимателя полна неопределенности: сегодня пришел новый квалифицированный сотрудник, а завтра уволятся двое, внезапный кризис почти разорит компанию или же вы станете ведущими специалистами в стране, прибыль вырастет или упадет. Десятилетия существовало убеждение, что для развития бизнеса необходимы план и нерушимая стратегия. Но стратегия – это не волшебная пилюля и не универсальный инструмент. Предусмотреть все невозможно. Нужно расставить приоритеты, но в условиях нестабильности и постоянной переменчивости обстоятельств важно быть готовым внести коррективы.
Гибкость Agile-методологии дает компаниям следующие преимущества:
Как существенный бонус – осознанные сотрудники прозрачно и четко ведут проекты. Даже если кто-то из них уволится, вы все равно будете понимать, выполнение какого объема работы нужно обеспечить, чтобы прогресс не останавливался. Потому что список задач на ближайшие пару недель актуален и готов.
Три года назад мы не были Agile. Совсем. Сейчас мы можем сказать, что управляем проектами по методологии Agile. Хотя всего 50% наших процессов подчиняются ее принципам.
Определить конкретный момент, когда компания заработала по методологии, трудно. Если вы проводите ежедневные стендапы, раздаете бейджи, часто выпускаете новый продукт, можно ли сказать, что вы в Agile?
Первым знаком того, что Agile «прижился», будет умение подстраиваться. Если ваша команда не падает в обморок при смене курса или изменении входных данных, если сотрудники тут же подхватывают новые условия задачи и корректируют ход действий, значит все работает.
Второй признак – фокус на решении задач. Дел всегда больше, чем ресурсов на их завершение. Важно не перегрузить человека, не задавить его срочными задачами. Как с этим справляется Agile? Существует Definition of Done – критерий готовности, конкретная договоренность внутри вашей команды. Принимая задачу или открывая новый проект, сотрудники должны определить измеримые критерии, по которым будут оценивать, выполнена ли задача.
Третий признак – умение адаптировать методологию под потребности команды. На старте вы неизбежно будете использовать много практик. Это обязательная часть процесса. Представьте строительные леса. На первом этапе бригаде без них не обойтись, но когда дом построен, в них больше нет необходимости. Нужно убирать то, что уже сыграло свою роль. Так и в Agile, когда вы попробовали все практики, вы в полном праве решить, с чем комфортнее работать вашей команде.
В жизни постоянно происходят аномалии: в делах, задачах, проектах, финансах, стратегии и планировании. Невозможно просчитать все ходы заранее. Единственный способ быть на плаву – не ломаться под воздействием внешней среды, а адаптироваться под нее.
Agile заполняет пространство, меняет форму вместе с ним. Нужно немного терпения и последовательности. Ваша команда непременно оценит преимущества Agile, главное подобрать правильный софт и продолжать ставить здравый смысл во главу угла! Удачи!