1.2 ПРЕИМУЩЕСТВА AGILE
Авторы раздела:
Крюнькин Е. Н.
Алферов П. А.
Ожаровский А. В.
Малахов А. А.
Потеев П. М.
Подходы Agile не просто помогают успешно реализовать проект, но, что важнее всего, они работают там, где другие средства просто не помогают. Если вам близки ценности Agile, то положительный результат от использования Agile не заставит себя ждать.
Подходы Agile не просто помогают успешно реализовать проект, но, что важнее всего, они работают там, где другие средства просто не помогают. Если вам близки ценности Agile, то положительный результат от использования Agile не заставит себя ждать.
Время чтения: 16 мин.
Кейс 1. Компания «Софт-М» создала медицинскую информационную систему полного цикла на базе регионального государственного лечебно-профилактического учреждения. Когда команда Александра М. разрабатывала и внедряла медицинскую информационную систему в государственном медицинском учреждении, она изначально столкнулась с волной негатива и сопротивлением врачей и среднего медицинского персонала. Люди десятилетиями либо спокойно работали в программе Microsoft Word, либо от руки заполняли карты, а теперь от них требовали осваивать новую непривычную систему. Многие отказывались, два врача уволились. Этот негатив выплескивался и на членов команды.
Время чтения: 16 мин.
Кейс 1. Компания «Софт-М» создала медицинскую информационную систему полного цикла на базе регионального государственного лечебно-профилактического учреждения. Когда команда Александра М. разрабатывала и внедряла медицинскую информационную систему в государственном медицинском учреждении, она изначально столкнулась с волной негатива и сопротивлением врачей и среднего медицинского персонала. Люди десятилетиями либо спокойно работали в программе Microsoft Word, либо от руки заполняли карты, а теперь от них требовали осваивать новую непривычную систему. Многие отказывались, два врача уволились. Этот негатив выплескивался и на членов команды.
Уже на второй месяц реализации проекта команда поняла, что нужно разделить работу на более короткие периоды (спринты), чтобы медперсонал видел результаты. Они начали работать недельными интервалами. Сделанное тут же показывали не только главврачу, но и всем сотрудникам того блока, в котором шла автоматизация. Кроме небольших еженедельных успехов пользователям демонстрировали крупные «прорывы», и это стало решающим фактором для успеха всего проекта. Одной из таких побед стала генерация автоматического выписного эпикриза. Это было важно, потому что после завершения рабочего дня врачи часто вынуждены были заполнять выписные эпикризы и тратили до получаса на эпикриз каждого пациента. После внедрения новой системы эпикриз на каждого пациента формировался автоматически за 5 секунд! Это был переломный момент.
Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.
Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.
Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.
Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.
Уже на второй месяц реализации проекта команда поняла, что нужно разделить работу на более короткие периоды (спринты), чтобы медперсонал видел результаты. Они начали работать недельными интервалами. Сделанное тут же показывали не только главврачу, но и всем сотрудникам того блока, в котором шла автоматизация. Кроме небольших еженедельных успехов пользователям демонстрировали крупные «прорывы», и это стало решающим фактором для успеха всего проекта. Одной из таких побед стала генерация автоматического выписного эпикриза. Это было важно, потому что после завершения рабочего дня врачи часто вынуждены были заполнять выписные эпикризы и тратили до получаса на эпикриз каждого пациента. После внедрения новой системы эпикриз на каждого пациента формировался автоматически за 5 секунд! Это был переломный момент.
Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.
Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.
Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.
Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.
Подходы Agile помогают реализовать проект с большей или меньшей эффективностью, и, что важнее всего, зачастую они работают там, где никакие другие средства просто не помогают и получить результат невозможно в принципе.
PMBoK — свод знаний по управлению проектами (англ. Project Management Body of Knowledge, PMBoK), выпускаемый Project Management Institute (США) (www.pmi.org) de facto стандарт по классическому управлению проектами. В последней версии стандарта добавлены рекомендации по использованию гибких подходов в управлении проектами.
Кейс 2. Егор К. работал заместителем руководителя регионального отделения ПФР. В ПФР составляли рейтинг региональных отделений, и руководитель поставил своему отделению задачу попасть в топ-10 рейтинга. «Мы год работали процессными методами, — рассказывает Егор, — и сделали все, что могли. Вошли в двадцатку — и все, далее развитие остановилось. Ты используешь все, что только можно, люди работают 24/7, но не получается».
Егор начал поиск новых методов повышения эффективности и открыл для себя методологию PMBoK, с ее помощью команда начала работать над продуктом, который позволяет в автоматизированном режиме взаимодействовать с должниками по страховым взносам. Реализация данного проекта позволила бы подняться выше в рейтинге. Использовалась классическая водопадная модель проектного управления, включая паспорт проекта на 50 листов, множество согласований, метрик и документов.
Разработка ПО заняла год, однако, когда продукт был готов, у руководства уже отпала потребность в нем. Это был настоящий провал. Команда развалилась, проектный подход как таковой оказался дискредитирован, а ведь при грамотной оценке нужд заказчика все это можно было определить гораздо раньше и предотвратить такой исход проекта. Егор не опустил руки и начал искать другие подходы, рассматривал, в частности, гибкий подход к управлению проектами Agile. Он и его сотрудники вскоре начали использовать подход в полном объеме: создали команду, завели доску задач, ежедневные встречи, обязательные демонстрации версий продукта, ретроспективы и т. д. C внедрением Agile команда воспряла духом, стала создавать эффективные продукты, подходящие заказчику.
Среди преимуществ нового подхода команда сразу отметила:
Егор начал поиск новых методов повышения эффективности и открыл для себя методологию PMBoK, с ее помощью команда начала работать над продуктом, который позволяет в автоматизированном режиме взаимодействовать с должниками по страховым взносам. Реализация данного проекта позволила бы подняться выше в рейтинге. Использовалась классическая водопадная модель проектного управления, включая паспорт проекта на 50 листов, множество согласований, метрик и документов.
Разработка ПО заняла год, однако, когда продукт был готов, у руководства уже отпала потребность в нем. Это был настоящий провал. Команда развалилась, проектный подход как таковой оказался дискредитирован, а ведь при грамотной оценке нужд заказчика все это можно было определить гораздо раньше и предотвратить такой исход проекта. Егор не опустил руки и начал искать другие подходы, рассматривал, в частности, гибкий подход к управлению проектами Agile. Он и его сотрудники вскоре начали использовать подход в полном объеме: создали команду, завели доску задач, ежедневные встречи, обязательные демонстрации версий продукта, ретроспективы и т. д. C внедрением Agile команда воспряла духом, стала создавать эффективные продукты, подходящие заказчику.
Среди преимуществ нового подхода команда сразу отметила:
- возможность быстро отследить ошибку и исправить ее;
- постоянное получение обратной связи от заказчика, уточнение требований, проверку соответствия ПО требованиям;
- возможность быстрой поставки (time-to-market);
- командную ответственность за продукт.
Кейс 2. Егор К. работал заместителем руководителя регионального отделения ПФР. В ПФР составляли рейтинг региональных отделений, и руководитель поставил своему отделению задачу попасть в топ-10 рейтинга. «Мы год работали процессными методами, — рассказывает Егор, — и сделали все, что могли. Вошли в двадцатку — и все, далее развитие остановилось. Ты используешь все, что только можно, люди работают 24/7, но не получается». Егор начал поиск новых методов повышения эффективности и открыл для себя методологию PMBoK, с ее помощью команда начала работать над продуктом, который позволяет в автоматизированном режиме взаимодействовать с должниками по страховым взносам. Реализация данного проекта позволила бы подняться выше в рейтинге. Использовалась классическая водопадная модель проектного управления, включая паспорт проекта на 50 листов, множество согласований, метрик и документов. Разработка П О заняла год, однако, когда продукт был готов, у руководства уже отпала потребность в нем. Это был настоящий провал. Команда развалилась, проектный подход как таковой оказался дискредитирован, а ведь при грамотной оценке нужд заказчика все это можно было определить гораздо раньше и предотвратить такой исход проекта. Егор не опустил руки и начал искать другие подходы, рассматривал, в частности, гибкий подход к управлению проектами Agile. Он и его сотрудники вскоре начали использовать подход в полном объеме: создали команду, завели доску задач, ежедневные встречи, обязательные демонстрации версий продукта, ретроспективы и т. д. C внедрением Agile команда воспряла духом, стала создавать эффективные продукты, подходящие заказчику. Среди преимуществ нового подхода команда сразу отметила:
- возможность быстро отследить ошибку и исправить ее;
- постоянное получение обратной связи от заказчика, уточнение требований, проверку соответствия ПО требованиям;
- возможность быстрой поставки (time-to-market);
- командную ответственность за продукт.
Описанные кейсы иллюстрируют то, что в условиях частых изменений требований, сжатых сроков и высокой степени неопределенности, характерной на данный момент для реализации проектов и создания продуктов в органах государственной власти, адаптивные гибкие подходы оказываются эффективными там, где классическое проектное управление (даже выстроенное максимально точно) не привело к значимым успехам.
Рассмотрим и другие преимущества гибкого подхода:
1. Скорость вывода продукта на рынок (time-to-market). Очень часто заказчик (или конечный потребитель) просит результат, который работает приемлемым образом непосредственно здесь и сейчас («это должно было быть сделано еще вчера»). Кроме того, в последние годы пользователи стали лучше разбираться в ИТ-продуктах и в том, что им нужно, могут оценить продукт (в том числе сравнивая с привычными коммерческими продуктами цифровых гигантов) и дать быструю обратную связь. Следовательно, разработка должна идти быстро, эффективно, производя на выходе реально работающий и полезный для потребителя продукт; именно поэтому госорганизации так или иначе приходят к Agile-подходам.
Рассмотрим и другие преимущества гибкого подхода:
1. Скорость вывода продукта на рынок (time-to-market). Очень часто заказчик (или конечный потребитель) просит результат, который работает приемлемым образом непосредственно здесь и сейчас («это должно было быть сделано еще вчера»). Кроме того, в последние годы пользователи стали лучше разбираться в ИТ-продуктах и в том, что им нужно, могут оценить продукт (в том числе сравнивая с привычными коммерческими продуктами цифровых гигантов) и дать быструю обратную связь. Следовательно, разработка должна идти быстро, эффективно, производя на выходе реально работающий и полезный для потребителя продукт; именно поэтому госорганизации так или иначе приходят к Agile-подходам.
Скидку на госпошлины продлили до 2021 года // Госуслуги. URL: http://base.garant.ru/71551636/
Эта задача была реализована с теми ведомствами, которые сами оказались готовы к такой быстрой работе.
Кейс 3. Ярким примером полезности Аgile на государственном уровне стал проект по внедрению 30%-й скидки на оплату госпошлины через портал «Госуслуги». Этот проект шел ровно 30 дней, потому что 30 ноября 2016 г. был подписан закон о внесении изменений в Налоговый кодекс. Новый закон разрешал 30%-ю скидку на портале «Госуслуги». Соответственно, с 1 декабря 2016 г. Министерство связи, Казначейство и органы власти начали быстро искать технологическую схему реализации такой скидки, потому что с 1 января все уже должно было заработать. В старой парадигме такую скорость применения закона, изменяющего четыре информационные системы разных ведомств, невозможно было представить. Однако, уже имея опыт работы в соответствии с гибкими подходами, разработчики «Госуслуг» смогли это сделать.
Кейс 3. Ярким примером полезности Аgile на государственном уровне стал проект по внедрению 30%-й скидки на оплату госпошлины через портал «Госуслуги». Этот проект шел ровно 30 дней, потому что 30 ноября 2018 г. был подписан закон о внесении изменений в Налоговый кодекс. Новый закон разрешал 30%-ю скидку на портале «Госуслуги». Соответственно, с 1 декабря 2018 г. Министерство связи, Казначейство и органы власти начали быстро искать технологическую схему реализации такой скидки, потому что с 1 января все уже должно было заработать. В старой парадигме такую скорость применения закона, изменяющего четыре информационные системы разных ведомств, невозможно было представить. Однако, уже имея опыт работы в соответствии с гибкими подходами, разработчики «Госуслуг» смогли это сделать. Обратим внимание на количество участников проекта: команда, субподрядчики, «суб-субподрядчики» — всего более 450 человек.
Больше преимуществ Agile, кейсов и историй об успешном применении этих методов можно найти в популярных книгах о гибких подходах, например в книге Дж. Сазерленда, основоположника метода Scrum и одного из авторов знаменитого манифеста Agile: Сазерленд Дж. Scrum: Революционный метод управления проектами. М.: Манн, Иванов и Фербер, 2015.
2. Минимизация рисков неприятия продукта. Частые демонстрации текущей версии продукта заказчику и пользователям позволяют протестировать продукт или его отдельную функцию и при необходимости в любой момент скорректировать ход разработки. Если у заказчика/ пользователя меняется видение и понимание продукта, так же быстро меняется и разрабатываемый продукт.
3. Сделать невозможное. В условиях госорганизации гибкие подходы к разработке позволят решать не только те задачи, которые неочевидны или выполняются медленно или неэффективно, но и те, к которым в традиционной схеме работы учреждения исполнители даже боятся подступиться и которые другими методами не решаются в принципе. Невозможное становится возможным за счет создания кросс-функциональной команды, развития командного духа, появления внутренних горизонтальных связей между сторонами, участвующими в разработке, и т. д.
3. Сделать невозможное. В условиях госорганизации гибкие подходы к разработке позволят решать не только те задачи, которые неочевидны или выполняются медленно или неэффективно, но и те, к которым в традиционной схеме работы учреждения исполнители даже боятся подступиться и которые другими методами не решаются в принципе. Невозможное становится возможным за счет создания кросс-функциональной команды, развития командного духа, появления внутренних горизонтальных связей между сторонами, участвующими в разработке, и т. д.
Кейс 4. Уже известная нам команда Егора К. должна была собрать статистические данные из нескольких организаций и ведомств в своем регионе. До нее эту задачу уже пытались выполнить несколько раз, и каждый раз безуспешно, поскольку возникали различные барьеры в межведомственных коммуникациях. Воспользовавшись гибким подходом к управлению и теми горизонтальными связями, которые установились во время предыдущих Agile-проектов в их организации, команда Егора К. смогла собрать статистику за три дня! «Нам вообще не поверили, что можно за три дня собрать эту статистику, но, главное, не верили в то, что это можно сделать вообще. Я считаю, что это просто пробивание стен», — рассказывает Егор К.
Кейс 4. Уже известная нам команда Егора К. должна была собрать статистические данные из нескольких организаций и ведомств в своем регионе. До нее эту задачу уже пытались выполнить несколько раз, и каждый раз безуспешно, поскольку возникали различные барьеры в межведомственных коммуникациях. Воспользовавшись гибким методом управления и теми горизонтальными связями, которые установились во время предыдущих Agile-проектов в их организации, команда Егора К. смогла собрать статистику за три дня! «Нам вообще не поверили, что можно за три дня собрать эту статистику, но, главное, не верили в то, что это можно сделать вообще. Я считаю, что это просто пробивание стен», — рассказывает Егор К.
4. Прозрачность хода реализации для всех участников проекта. Применение гибких подходов, ежедневные встречи команды и демонстрация продукта заказчику и пользователям позволяют сделать весь процесс разработки наглядным как для членов команды, так и для заказчика и пользователей. При таком подходе команда сразу видит узкие места проекта, имеет возможность изменить приоритеты, ускориться, решить проблему или быстро найти обходной путь. Заказчик может влиять на результат разработки, видит скорость работы, мотивирован на взаимодействие с командой. Иногда это оказывается просто критическим для того, чтобы проект состоялся.
Кейс 5. Александр М. со своей командой из компании «Софт-М» рассказывает: «Когда ты постоянно общаешься с пользователями и показываешь им результат, они понимают, чего им ожидать и зачем это все нужно. Период внедрения всегда дискомфортен для заказчика: приходится ломать какие-то бизнес-процессы, давать обещание „Подождите-потерпите, и дальше будет хорошо“. И здесь важно регулярно что-то показывать и говорить: „Смотрите, благодаря нашей разработке вот этот процесс стал лучше, стал качественнее“. Такие небольшие победы дают пользователю понимание, что продукт ему нужен».
Кейс 5. Александр М. со своей командой из компании «Софт-М» рассказывает: «Когда ты постоянно общаешься с пользователями и показываешь им результат, они понимают, чего им ожидать и зачем это все нужно. Период внедрения всегда дискомфортен для заказчика: приходится ломать какие-то бизнес-процессы, давать обещание „Подождите-потерпите, и дальше будет хорошо“. И здесь важно регулярно что-то показывать и говорить: „Смотрите, благодаря нашей разработке вот этот процесс стал лучше, стал качественнее“. Такие небольшие победы дают пользователю понимание, что продукт ему нужен».
5. Пересмотр ролей в команде с сокращением количества менеджеров («уплощение» структуры, в английском языке для этого используется термин de-layering или debossing, уменьшение количества уровней управления). При внедрении гибких подходов меняется структура команды. Следуя принципам самоорганизации, уровни управленческой пирамиды перераспределяются в пользу владельца продукта, а оперативные организационные функции во многом переходят ко всем членам команды при содействии Scrum-мастера. Остальные роли становятся только функциональными (а зачастую и опциональными), в результате можно сэкономить средства за счет сокращения ненужных руководящих должностей и получить удобную горизонтальную структуру управления, которая функционирует быстрее.
6. Фокус на ценность. При использовании Agile создается продукт, действительно нужный здесь и сейчас. В противном случае с помощью функционального или классического проектного управления можно год делать хороший, качественный продукт точно в соответствии с кропотливо согласованными требованиями, но потом выяснится, что требования уже не актуальны (или изначально были неверно сформулированы, например без учета реального «голоса клиента») и продукт фактически никому не нужен (не пользуется спросом).
6. Фокус на ценность. При использовании Agile создается продукт, действительно нужный здесь и сейчас. В противном случае с помощью функционального или классического проектного управления можно год делать хороший, качественный продукт точно в соответствии с кропотливо согласованными требованиями, но потом выяснится, что требования уже не актуальны (или изначально были неверно сформулированы, например без учета реального «голоса клиента») и продукт фактически никому не нужен (не пользуется спросом).
Кейс 6. Сергей С. руководит разработкой масштабных государственных информационных систем в Санкт-Петербурге. Он и его команда делят все основные функции системы на блоки, затем они работают над каждым блоком с применением гибких подходов, в результате чего появляется возможность продемонстрировать блоки пользователям, доработать по результатам обратной связи и выпустить информационную систему на рынок.
Кейс 6. Сергей С. руководит разработкой масштабных государственных информационных систем в Санкт-Петербурге. Он и его команда делят все основные функции системы на блоки, затем они работают над каждым блоком с применением гибких подходов, в результате чего появляется возможность продемонстрировать блоки пользователям, доработать по результатам обратной связи и выпустить информационную систему на рынок.
7. Экономия за счет быстрого показа продукта. Если версии готового работающего продукта регулярно демонстрируются пользователям и заказчику, то у последнего всегда есть возможность завершить разработку в тот момент, когда достигнут необходимый здесь и сейчас объем функционала (этот объем может отличаться от изначально запланированного и согласованного). Заказчик получает новый продукт быстрее, обходится он заказчику дешевле, команда приобретает дополнительную мотивацию за счет того, что быстро и эффективно решила задачу.
Кейс 7. И снова кейс Егора К.: «У нас был двухнедельный спринт, заказчик попросил некоторый набор функций продукта. Приходим на первый обзор, рассказываем, после чего происходит такой диалог с заказчиком:
— Хватит, мне достаточно.
— Да нет, у нас еще неделя будет!
— Мне достаточно. Все, что нужно, я получил. Команда молодец, пусть работает над новыми задачами. Этот продукт меня полностью устраивает».
— Хватит, мне достаточно.
— Да нет, у нас еще неделя будет!
— Мне достаточно. Все, что нужно, я получил. Команда молодец, пусть работает над новыми задачами. Этот продукт меня полностью устраивает».
Кейс 7. И снова кейс Егора К.: «У нас был двухнедельный спринт, заказчик попросил некоторый набор функций продукта. Приходим на первый обзор, рассказываем, после чего происходит такой диалог с заказчиком:
— Хватит, мне достаточно.
— Да нет, у нас еще неделя будет!
— Мне достаточно. Все, что нужно, я получил. Команда молодец, пусть работает над новыми задачами. Этот продукт меня полностью устраивает».
— Хватит, мне достаточно.
— Да нет, у нас еще неделя будет!
— Мне достаточно. Все, что нужно, я получил. Команда молодец, пусть работает над новыми задачами. Этот продукт меня полностью устраивает».
8. Прототип как способ сбора требований. При реализации нетиповых проектов создается новый продукт, которого до этого не было. Требования заказчика могут быть не сформулированы, сформулированы некорректно, «непонятно откуда взяты» и т. д. (пока культура выявления и формирования требований в госорганизациях не столь развита, как в коммерческом секторе). Здесь для обеих сторон оказывается выигрышной ситуация, когда разработчики могут показать заказчику (и конечным пользователям) прототипы (эскизы, наброски) будущего решения, дать заказчику поработать с этим прототипом и по ходу дела выявить и сформулировать набор нужных требований.
Кейс 8. Когда команда Егора К. работает над новым продуктом, его сотрудники считают, что эффективнее всего не обсуждать его путем обмена описаниями, а, распечатав скриншоты, демонстрировать их друг другу и внешним сторонам. Так удобнее взаимодействовать с заказчиком или с конечным пользователем. В рамках одного из проектов пользователь, увидев скриншоты продукта, понял, что это совершенно не то, что ему нужно. «С точки зрения архитектуры, все правильно, продукт у меня работает качественно», — ответил ему разработчик. Однако пользователь был недоволен тем, что интерфейс неудобный и не годится для решения его повседневных задач, хотя функционал и архитектура формально правильные. Таким образом, одна личная встреча с демонстрацией и обсуждением картинок сэкономила команде Егора К. часы и недели труда с сомнительным результатом.
Кейс 8. Когда команда Егора К. работает над новым продуктом, его сотрудники считают, что эффективнее всего не обсуждать его путем обмена описаниями, а, распечатав скриншоты, демонстрировать их друг другу и внешним сторонам. Так удобнее взаимодействовать с заказчиком или с конечным пользователем. В рамках одного из проектов пользователь, увидев скриншоты продукта, понял, что это совершенно не то, что ему нужно. «С точки зрения архитектуры, все правильно, продукт у меня работает качественно», — ответил ему разработчик. Однако пользователь был недоволен тем, что интерфейс неудобный и не годится для решения его повседневных задач, хотя функционал и архитектура формально правильные. Таким образом, одна личная встреча с демонстрацией и обсуждением картинок сэкономила команде Егора К. часы и недели труда с сомнительным результатом.
9. Высокая мотивация команды. В некоторых случаях применение Agile дает возможность повысить качество жизни всех участников команды. Сотрудникам становится интересно, они готовы эффективно работать, снижается риск творческого выгорания и бесполезной работы. В творческой атмосфере люди работают быстро, результативно и с удовольствием, способны на самые нестандартные и выигрышные решения, готовы «свернуть горы» (рисунок 2).
13-й отчет о состоянии адаптивных методик разработки (State of Agile Report), подготовленный в 2019 г. компанией VersionOne.
Рисунок 2. Эффективность Agile-подходов
Выгоды, которые приносит Agile использующим его компаниям
(на основании данных, предоставленных 1319 компаниями и организациями)
(на основании данных, предоставленных 1319 компаниями и организациями)
Сравнение эффективности Agile-команд и команд,
работающих по другим методам разработки ПО
работающих по другим методам разработки ПО
Кейс 9. В процессе гибкой реализации проекта в команде Александра М., который внедрял информационную систему в лечебном учреждении, создалась такая творческая атмосфера, что прямо по ходу возникали какие-то ноу-хау, полезные и интересные для пользователей. Кроме того, сотрудники создавали новаторские на тот момент инструменты для себя, которыми потом начинали пользоваться сотрудники лечебного учреждения. Например, они организовали техподдержку через мессенджер, тогда это было действительно новым и необычным решением.
Кейс 9. В процессе гибкой реализации проекта в команде Александра М., который внедрял информационную систему в лечебном учреждении, создалась такая творческая атмосфера, что прямо по ходу возникали какие-то ноу-хау, полезные и интересные для пользователей. Кроме того, сотрудники создавали новаторские на тот момент инструменты для себя, которыми потом начинали пользоваться сотрудники лечебного учреждения. Например, они организовали техподдержку через мессенджер, тогда это было действительно новым и необычным решением.
Конечно, подходы Agile, как и любые другие методы, не могут быть «серебряной пулей» или волшебной таблеткой. Более того, не во всех случаях применение Agile-подходов может быть оправдано или эффективно. Однако при выборе нужного подхода и его грамотном применении в подходящих условиях (см. раздел 2) названные преимущества значительно превышают возможные риски и потенциальные сложности (см. раздел 4.5). Исходя из описанных возможностей и преимуществ применения, можно выделить следующие основные цели применения гибких подходов в государственных организациях:
- предоставить новую форму работы над государственными услугами, проектами, продуктами и т. д., обеспечив ориентацию на ценность для конечного пользователя, быстроту разработки и изменений, прозрачность, открытость и управляемость;
- повысить результативность и эффективность командной работы (в том числе кросс-функциональной, межведомственной);
- ускорить создание и внедрение новых полезных продуктов (например, цифровых сервисов, нормативных документов, коммуникационных материалов для граждан).
Куда дальше?
Куда дальше?