Об аджайл или гибком подходе (agile – «гибкий» по-английски) уже давно постоянно пишут и говорят. Яркий пример – выступления Германа Грефа, который делает гибким огромный Сбербанк. Но чаще случается то, что для представителей компаний, не связанных с ИТ, аджайл остается просто модным термином. Предлагаю разобраться, почему компании переходят к гибкому подходу и чем он полезен.
Представьте, что вы открываете магазин в соседнем регионе. Подбираете ассортимент. Выбираете место. Разрабатываете детальный план. Начинаете ремонт. И вот с этого момента начинаются приключения. Строители срывают сроки. Поставщики привозят брак. Открытие затягивается. Вместо новогодней распродажи, магазин открывается в январский спад. Дальше – хуже. Покупатели не берут консервированную фасоль, спрос на которую обещали исследования рынка, зато расхватывают замороженные пельмени. Товар на полках застаивается, холодильников не хватает. На дополнительные холодильники денег нет, да и ставить их негде. И в этих приключениях вы не одиноки. В 2008 году в аэропорту Хитроу открыли Терминал 5. Перед открытием, инженеры тщательно протестировали систему погрузки багажа. Все тесты были успешными. В день открытия система встала. Она не предусматривала, что пассажир забудет ценную вещь в чемодане, и его придется снять с ленты вручную. 42 000 чемоданов не улетели вместе со своими владельцами. 500 рейсов пришлось отменить. Не секрет, что тщательная подготовка и тестирование не гарантируют 100% результата. Первыми об этой проблеме задумались производители программного обеспечения. 68% проектов в ИТ заканчивались провалом. В 2001 году группа экспертов предложила новые принципы управления, которые назвали «Манифестом аджайл (Agile Manifesto)».
Манифест о гибком подходе помогает допускать меньше ошибок и опирается на 4 принципа.
1. Общение с людьми важнее процессов.
Компания запускала новую услугу. Подрядчик предоставил шаблон технического задания. Документ подготовлен и согласован всеми руководителями. Когда его изучили, оказалось, что весь документ состоит из материалов, собранных в Интернете. Требования противоречили друг другу. Формально задание было подготовлено, но создать по нему услугу невозможно. Компания впустую потратила время, подрядчик не получил заказ.
Процессы создают, чтобы избегать ошибок. За процессами стоят люди. Они загружены повседневной работой. Если сделать процесс слишком сложным, люди начинают слепо следовать ему, не задумываясь над содержанием.
Помните о людях, которые будут выполнять выстроенную вами работу. Сложные задачи могут требовать «толстых» документов, но если можно обойтись электронным письмом или чертежом на доске, ограничьтесь ими.
2. Живой продукт важнее детального описания.
Мебельная компания изготавливает шкафы на заказ. Сделав замеры и поговорив с покупателем, компания присылает чертежи будущего шкафа на согласование. В чертежах указаны материал, цвет, размеры отделений. Покупатель подписывает чертежи. Компания изготавливает и устанавливает шкаф. После установки оказывается, что брюки мнутся потому, что отделение надо было сделать чуть выше, а раздвижная дверь все время скидывает рубашки с вешалки. Недовольный покупатель больше ничего не закажет и не порекомендует компанию своим знакомым.
Помните, что тщательное документирование не помогает понять, что же клиент хочет на самом деле. Человек должен пощупать, попробовать, примерить, чтобы понять действительно ли это то, что он хочет или разобраться, что его не устраивает. Выполняйте работу поэтапно. Покажите клиенту прототип. Дайте возможность увидеть результат каждого этапа. Пусть клиент видит, что работа выполняется так, как он хочет.
3. Сотрудничество с заказчиком важнее согласованных условий контракта.
Студия создает сайты и мобильные приложения. Заказчик обратился за разработкой интернет-магазина для своей компании. Когда часть работы уже была выполнена, заказчик понял, что вместо веб-версии ему больше подошло бы мобильное приложение. Менеджер компании-разработчика обозначил, что поскольку контракт подписан, студия закончит разработку магазина, после чего готова разработать мобильное приложение в рамках отдельного контракта. Контракт на мобильное приложение ушел другой студии.
Контракты важны. Они закрепляют объем работ, сроки, порядок расчетов. Но жизнь не стоит на месте. Могут измениться внешние условия. Работая с прототипами, заказчик может изменить свое первоначальное представление о продукте. Будьте готовы к этому. Контракт должен предусматривать возможность изменения. Опишите в контракте порядок изменений: какие могут быть сделаны бесплатно, какие потребуют дополнительной оплаты.
4. Готовность к изменениям важнее следования первоначальному плану.
Банк запустил проект по модернизации своего интернет-приложения. Проект предусматривал постепенное развертывание функций в течение трех лет. В проект вовлечено множество подразделений. Первую версию новой системы открыли для пользователей, и банк начал получать отзывы. Многие клиенты хотели получить функции, реализация которых планировалась на более поздних этапах. Каждое изменение плана требовало многочисленных согласований. Клиенты уходили к другим банкам с более продвинутыми приложениями.
Тщательное планирование не гарантирует успешности проекта. Детальный план делает изменение очень сложным, так как любое изменение вызывает за собой целый каскад других. Чтобы отбить охоту к изменениям, процесс делают дорогим и сложным. С самого начала выстраивайте работу так, чтобы план было легко изменить. Подготовьте укрупненный план, а детальное планирование осуществляйте перед началом очередного этапа.
Помните, что довольные клиенты приносят деньги. А принципы аджайл помогают получать довольных клиентов.