Из ресурсов внедрения вам понадобятся и сущностные, и ориентированные на перемены: удобный цифровой чек-лист нового процесса; мини-протокол с упрощенной версией всех участвующих процессов; своего рода рекомендательное письмо в видеоформате; информационная база вопросов и ответов.
К числу необходимых ресурсов относится инструментарий внедрения. Он создается, чтобы как на блюдечке представить весь проект и MVP любому, кто впервые знакомится с данной инициативой. Этот инструментарий должен быть одновременно информативным и завлекательным. Его структуру следует хорошо продумать. Она включает: четкое и краткое описание инициативы, отвечающее на все «кто?», «что?», «зачем?», «как?» и «почему?»; убедительное рекомендательное послание главного инициатора, желательно в видеоформате; тщательно выверенный обзор фактов и аналитики. Коротко говоря, это должна быть смесь «жестких» целей и «мягких» элементов, ориентирующих людей на изменения.
6.2.3. Продолжайте развивать MVP
Новые или перестроенные бизнес-модели – цифровые по определению. Как мы убедились в ускорителе 2, непрерывное развитие MVP целесообразно всегда, но особенно в случаях, когда MVP и его бизнес-процесс сильно зависят от ИТ. Сегодня чаще всего так и есть, поскольку почти все процессы информационно емки, а существующие и перспективные бизнес-модели сплошь и рядом подвергаются цифровизации.
Непрерывное развитие – не то же самое, что масштабирование. Разработка новых версий MVP (1.0, 2.0, 3.0) полностью отлична от масштабирования одной из версий. Второе будет обсуждаться в ускорителе 3. А здесь мы имеем дело с первым. Как продолжать разработку новых и лучших версий MVP? Главное – применять пользовательские данные для маневренных итераций.
Выбирая метод разработки, не стоит изобретать велосипед. Речь о том, что успешные методы разработки модернизированных или инновационных бизнес-моделей (на нашем жаргоне типов 2 или 3) уже известны. Понятие «аджайл» охватывает множество разных методов разработки, главный из которых называется «скрам». Ниже приводится общий обзор главных концепций аджайл-разработки и конкретно скрам.
6.2.4. Разбираемся в аджайл
Аджайл – влиятельная теория. Ее манифест, выпущенный группой американских разработчиков программного обеспечения в 2001 г., содержит следующие положения:
● Люди и взаимодействие важнее процессов и инструментов.
● Работающий продукт важнее исчерпывающей документации.
● Сотрудничество с заказчиком важнее согласования условий контракта.
● Готовность к изменениям важнее следования плану.
12 принципов манифеста:
1. Наивысшим приоритетом является удовлетворение потребностей клиента благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт – основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота – искусство минимизации лишней работы – крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
[166].
Гибкая разработка (аджайл-метод) ведется краткими циклами, в отличие от традиционной линейной последовательности этапов. Каждый цикл представляет собой реализованный элемент конечной бизнес-модели или MVP. Первый цикл – MVP, второй – его первая итерация, и т. д. Один цикл – не законченный этап работы, а всего лишь основа для последующих итераций и инноваций.
При традиционной разработке каждая фаза приносит промежуточные результаты, оцениваемые по критериям временных и материальных затрат. Например, проектирование, подготовительные работы, реализация, внедрение. Итерация, с другой стороны, представляет собой ограниченный по времени цикл прироста наиболее приоритетной в данный момент потребительской функциональности. Каждая итерация тоже состоит из проектирования, подготовительных работ, реализации и внедрения. Может показаться, что разница в смысле незначительна, но ее значение для потребителя трудно переоценить.
Есть несколько прекрасных книг на тему аджайл-разработки и проектного управления, в частности «Гибкое управление проектами» (Agile Project Management) Джима Хайсмита, «Основы Scrum» Кена Рубина и «Постигая Agile» Эндрю Стеллмана
[167]. Есть хороший источник на голландском языке: книга «Управление аджайл-проектами» (Managen van agile projecten) Берта Хедемана, Хенни Портмана и Рона Сеегерса
[168]. Она дает четкое представление о типах гибкого управления, их взаимосвязи и основных принципах. Кроме того, в ней приводится полный обзор различий между традиционной каскадной моделью разработки в ИТ и аджайл-моделью (cм. рис. 32).
Замените «программное обеспечение» на «продукт», и вы поймете, что принципы аджайл полностью применимы к итеративным разработкам вне сферы ИТ. Это могут быть проекты в области маркетинга, операционной деятельности или инноваций; принципы аджайл можно применять в любом проекте или программе, если:
