Развитие технологий и необходимость быстрее принимать решения, выпускать новые продукты или обновлять имеющиеся, а потому обучаться и меняться заставляют компании искать новые формы организации работы над проектами; создавать такие варианты, когда обратная связь между заказчиком и исполнителем передается и воспринимается быстрее, а активные изменения в продукт или заказ органически встроены в процессы его разработки и вывода на рынок.
Для повышения скорости и эффективности работы над проектами, удовлетворенности сотрудников и клиентов еще в конце XX в. была разработана система гибких методов разработки продуктов. Первое упоминание о них появилось еще в 1970-х гг. в работе американского ученого-программиста Уинстона Ройса. На основе его статей в 1990-х гг. была разработана система гибких методологий управления проектами, а в 2001 г. сформулирован манифест Agile. Созданная система предполагала активную вовлеченность всей проектной команды в процесс разработки продукта, когда каждый может предлагать, обсуждать и вносить изменения в продукт.
Agile-модель и ее производные серьезно преобразились при распространении информационных технологий. Возросла доля удачных проектов, ускорились процессы разработки продуктов, повысилось качество результатов. Сейчас основные принципы, ценности и методы данной модели становятся все более популярными и в других сферах бизнеса и управления, развиваются другие гибкие технологии работы коллективов, которые традиционно связывают с понятием внутреннего предпринимательства1.
Работа коллективов в гибких технологиях подразумевает реализацию следующих принципов:
- создание рабочих прототипов вместо документации;
- постоянная обратная связь команды разработчиков с клиентами, гибкость при создании продукта с сохранением сроков вывода на рынок и стоимости;
- минимальный период планирования только того, что необходимо делать сейчас;
- мотивированные разработчики, управление, культивирующее эту мотивацию;
- приоритет личному контакту между разработчиками и заказчиком;
- постоянный высокий темп деятельности;
- упрощение процесса создания продукта без потери его качества.
На основе этих принципов были разработаны разные виды работы agile (таблица 8.4).
Таблица 8.4. Виды Agile
| Agile Modeling (AM) | Процедуры по моделированию и документированию информации в ходе создания ПО |
|---|---|
| Agile Unified Process (AUP) | Модель разработки ПО в рамках приложений для бизнеса |
| Agile Data Method (ADM) | Гибкое создание ПО путем сотрудничества кросс-функциональных команд между собой с акцентом на разработку решений и требований |
| Dynamic Systems Development Method (DSDM) | Быстрая разработка приложений путем привлечения конечного потребителя к созданию продукции |
| Essential Unified Process (EssUP) | Использование не универсальных методик и техник, а только применимых в данном конкретном случае с акцентом на архитектуру продукции |
| Extreme Programming (XP) | Использование и развитие имеющихся лучших техник создания ПО при параллельной, а не последовательной проверке создаваемого программного продукта |
| Feature-Driven Development (FDD) | Реализация каждой функции в течение двух недель и не более |
| Getting Real (GR) | Разработка продукта с дизайна и интерфейса, а затем разработка функционального наполнения |
| OpenUP (OUP) | Акцент на следовании плану по всем этапам разработки в части принятия решений |
| Lean Software Development | Концепция бережливого управления производственной компанией |
| Scrum | Гибкое создание программных продуктов, предполагающее вовлечение заказчика в разработку |
Источник: составлено Красностановой М.В.
Приведенные классификации условны, так как служат прежде всего цели упорядочивания накопленного практического опыта.
Адаптивная модель при ее применении в подходящих условиях повышает производительность и удовлетворенность сотрудников, клиентов, оптимизирует издержки переговоров, документирования, планирования и контроля, улучшая выпускаемый на рынок продукт и сокращая уровни организационных структур.
Основные типы гибких методологий обладают своими характеристиками, достоинствами и недостатками (табл. 3.27)
Таблица 3.27. Основные виды гибких методологий
| Описание | Плюсы | Минусы |
|---|---|---|
| Scrum | ||
| Название пришло из спортивной игры «регби» («скрам» — «свалка вокруг мяча» — активное, резкое, жесткое командное действие, направленное на достижение цели, — получение мяча). В бизнесе метод направлен на слаженное творческое взаимодействие команды по принципу «бережливости» (устранения всего лишнего) и «точно в срок». Организация создает небольшую группу от трех до девяти человек, состоящую из всех необходимых для осуществления проекта специалистов, которая сама управляет своей деятельностью: в сжатые сроки группы тестируют прототипы продукта, привлекая потенциальных клиентов. Если продукт принимается потребителем, он выпускается на рынок. План работы составляется общий, подробно расписывается только то, к чему нужно приступить уже сейчас. Работа дробится на короткие циклы — спринты. Всей работой руководит ведущий, знающий scrum и удерживающий команду на задаче |
|
|
| Lean, или бережливое производство | ||
|
Суть подхода заключается в устранении ошибок, помех и сокращении растрат времени и ресурсов с помощью схемы потока операций. Нет жестких границ этапов («спринтов»), как в Scrum, можно выполнять сразу несколько работ одновременно, существенно сокращая запасы времени. Работа строится на постоянном процессе анализа дел и беспрерывных небольших улучшений. Основные принципы работы:
|
Стабильно высокое качество продукта с минимальными потерями времени и ресурсов |
|
| Kanban | ||
| Широкие временные рамки. Акцент на цели, последовательное их достижение и оценка эффективности. Бережливое производство и уменьшение количества задач за счет превращения мелких локальных в крупные и глобальные, которые делятся на этапы работы. На каждом из таких этапов конкретная команда специалистов решает одну задачу, а после ее передачи на следующий этап переходят к другой. Количество задач на каждом этапе строго ограничено, чтобы не создавались «заторы». По сути, это конвейер, но его элементы работают, когда это необходимо. Процесс постоянно анализируется и улучшается. Важный элемент методологии —визуализация с помощью таблицы (канбан-доска), столбцы которой содержат различные стикеры с задачами2 |
|
|
| Экстремальное программирование, или eXtreme Programming (XP) | ||
| Основная задача — справиться с постоянно меняющимися требованиями к программному продукту и повысить его качество разработки. Четыре основных процесса: кодирование, тестирование, дизайн и слушание, базирующиеся на принципах простоты (учитывать то, что необходимо сейчас), коммуникации («вживую»), максимальная обратная всех со всеми, смелость и уважение, постоянное улучшение дизайна системы требованиями |
Снижение затрат на разработку за счет сфокусированного общения «вживую» |
Подходит для небольших проектов |
Источник: составлено Красностановой М.В.
Успешность внедрения адаптивных моделей зависит в первую очередь от готовности менеджмента, собственников привносить что-то новое в компанию, развивать сотрудников, себя и компанию. Однако знание типичных ошибок при внедрении позволяет их избежать. К ним относятся:
- незнание или непонимание границ применимости гибких методологий, надежда на них как на панацею вне связи с целями и спецификой работы компании;
- излишняя скорость и масштаб внедрения, желание изменить все «до основания, а затем…»;
- недооценка важности технического оснащения компании, невозможность организовать работу сотрудников без коммуникативных технологий (корпоративный сайт, почта, пространства для собраний и т. п.);
- нежелание расставаться с неподходящими сотрудниками и находить новых сотрудников;
- нежелание поддерживать интерес сотрудников к процессу внедрения новых технологий.
Среди стереотипов сотрудников, которые придется разрушать при внедрении гибких моделей, можно назвать следующие:
- привычка к роли, когда специалисты неохотно выполняют непривычные для них обязанности (например, для аналитиков это может быть тестирование системы), нежелание делать монотонную рутинную работу, попытки усложнять простые задачи;
- привычка получать от заказчиков требования в документах, а не в прямом контакте;
- нежелание работать со специалистами из других подразделений в одной команде.
Практика показывает, что эти и другие стереотипы разрушаются, а проблемы решаются при готовности руководства меняться самим и последовательно реализовывать необходимые изменения во вверенной им организации.
Сторонниками гибких технологий (теоретиками и практиками) отмечается неуниверсальность их применения: далеко не для всех продуктов и не во всех производственных процессах они могут быть реализованы (табл. 8.3).
Таблица 8.3 Условия применения гибких технологий
| Условия | Подходящие | Неподходящие |
|---|---|---|
| Рыночная ситуация | Нестабильная, предпочтения клиентов и решения по продуктам часто меняются | Стабильная, спрос предсказуем, решения известны |
| Участие заказчика в разработке продукта | Возможно и желательно, так как быстрая обратная связь позволяет заказчику лучше понимать свои потребности | Невозможно и не нужно, так как требования изначально известны, понятны и не могут меняться |
| Разработанность, понятность продукта | Продукт новый, решения заранее неизвестны, много решается и определяется в процессе разработки, непонятен объем работ, технические характеристики могут меняться по ходу, время вывода продукта на рынок сильно лимитировано, важны творческие озарения и взаимодействие внутри команды | Технология производства продукта известна, ранее использовалась, техническое задание и план работ можно составить заранее и следовать им, проблемы можно решать последовательно силами разных специалистов и подразделений |
| Возможность дробить работу | Работу можно делать отдельными частями в любой последовательности, дорабатывая части и целое на любом этапе. Клиенты могут тестировать отдельные модули | Невозможно тестировать отдельные модули, последовательность процессов должна строго соблюдаться, менять что-либо в конце работы невозможно или нерентабельно |
| Роль ошибок | Их анализ может приводить к новым решениям и возможностям | Могут обнулить всю работу, приводя к неисправимым последствиям |
Источник: составлено Красностановой М.В.
Возможность для сотрудников реализовывать собственные бизнес-идеи с использованием ресурсов компании для развития ее бизнеса.↩︎
Первый столбец — глобальные цели — находится в самом начале таблицы. В нем отмечаются основные направления развития, долгосрочные цели, цели на этот год. Следующий столбец — задачи в очереди — содержит те задачи, к выполнению которых можно приступить сейчас. При этом чем выше задача, тем выше ее приоритет для компании. Колонки с этапами работы — это столбцы, по которым перемещается задача в зависимости от степени выполнения — стикер с задачей переходит вперед, если этап выполнен успешно, или назад — при обнаружении дефектов на предыдущем этапе. В последнем столбце обозначены выполненные задачи. Иногда перед этим столбцом ставят столбец «Тест», для того чтобы подтвердить качество проделанной работы.
Методологию Kanban применяют в различных сферах бизнеса для команд с различной численностью. Ограничением применения в данном случае является скорее готовность руководства и самого персонала к переходу к такому режиму работы.↩︎