Изучив и опробовав на практике несколько вариантов Agile-управления проектами, я десятки раз сталкивался с ситуациями, когда красивая теория не работает на практике. Люди просто не в состоянии предвидеть свое будущее и более-менее адекватно оценивать время и собственные силы, вне зависимости от того, на сколько этапов раздроблен проект и как красиво нарисованы все управляющие графики и таблицы. Когда нам в 35-й раз завернули дизайн — уже казалось, что ситуация просто безвыходная и спасти нас может только чудо.
И вот совсем недавно я узнал, что на свете уже давно существует такая методика разработки информационных систем – Evo (от слова «эволюция»), которая делает провалы проекта принципиально невозможными! Под провалом здесь подразумевается неконтролируемый рост сроков, бюджета, состава команды разработки, общего негатива; а также недостижение заранее установленных и измеримых целей.
Авторы этой эволюционной системы управления проектами Том и Кай Гилб, к сожалению, все многочисленные детали и хитрости своей методики раскрывают только на своих платных семинарах, однако общее представление об их идее можно вполне сделать и просуммировав несколько разрозненных статей, что я сейчас и сделаю в своем кратком обзоре.
Не провалить сроки – да как такое может быть?
Для любого человека главном вызовом в жизни и самым сложным испытанием всегда является управление и контроль за чем-либо. Автомобилем, семьей, карьерой, командой, и процессами – да ничего более ответственного и сопряженного с рисками в жизни и не бывает. А любой провал именно в управлении влечет за собой самые серьёзные катастрофы, и именно поэтому люди полагают, что контроль над любым процессом нужно постоянно усиливать, до бесконечности увеличивая число ограничений. Когда-то и мне казалось, что только рост рамок в геометрической прогрессии дает проекту шансы на успех, ведь главное – правильно и заранее расставлять все эти рамки.
Как правило при таком подходе мгновенно забывается, что ни один человек в мире не способен предвидеть будущее и описать подробно даже свой завтрашний день, не говоря уже о завтрашнем дне всей команды, создающей информационные системы. При этом все и всегда в мельчайших деталях предсказывают будущее любого нового проекта и ждут от менеджера только сверх способностей, граничащих с умением управлять пространством-временем. Когда же он не обнаруживает таковых в себе, то и Заказчик, и вся команда — очень искренне разочаровывается. А тем временем некоторые компании уже нашли новый способ управления своими проектами, при котором возможно не только систематически избегать неудач, но при этом перманентно получать — и значительные улучшения продукта для клиентов, и повышенный энтузиазм среди руководства и команды инженеров.
Описываемый в статье Evo-метод настолько эффективен, потому что он решает самые ключевые проблемы – постоянные задержки крупных проектов, неконтролируемый рост функционала и дополнений к первичному Техническому заданию, постоянный отход от первоначальных прототипов и общее непонимание командой и самим заказчиком основных целей создаваемой системы.
Думаю, никто не станет отрицать, что традиционный метод «Водопада» является сильно устаревшим, и сейчас только самые ленивые студии не используют тактику мелких итераций во времени, дробя крупную задачу на несколько мелких. Так, в компаниях HP и Confirmit практикуют цикл в 1 неделю, Microsoft применяет шестинедельный цикл; но оказывается, что на практике это далеко не всегда помогает. Сплошь и рядом встречаются ситуации, когда первоначальный прототип (макет Главной, ТЗ, sprint zero – нужное подчеркнуть) заворачивается и отдается на переработку по 10, 20, 30 раз. Программисты и тестировщики, верстальщики и ваши сервера пока пылятся без дела, а сверхкипучая деятельность на самом первом шаге перемешивает в шлак десятки тысяч часов и долларов без видимого успеха. Что же делать?
Пусть расцветают все цветы
Данная методика не похожа на планирование в том виде, в каком его привыкли видеть все консервативные менеджеры. Скорее она учится у самой природы, сравнивая создание информационной системы с процессом воспитания ребенка или выращиванием цветов у себя на клумбе.
Согласитесь, вы же не можете выдать своему цветку документ, четко регламентирующий: какого числа и в какое время он обязан зацвести, какого размера в сантиметрах он должен вырасти и сколько листьев иметь – ведь вы понятия не имеете, сколько будет солнечных и дождливых дней в году, вы не сможете предвидеть появление паразитов, падение метеорита, тень от соседнего цветка и т.д. Именно поэтому писать ТЗ для цветка вам кажется смешным.
А теперь попробуйте представить, как родители в 70-х годах прошлого века пробуют написать план на жизнь для собственной дочери. Я представляю себе такую четкую стратегию ее дальнейшего продвижения в жизни: выучиться обязательно на инженера (самая престижная профессия), затем в 21 год выйти замуж за человека по имени Вася, в 22 родить мальчика, в 25 – девочку, в 30 вступить в Партию, в 40 первый раз поехать по путевке за границу – в Болгарию! Это звучит еще смешнее.
Однако, создавая информационную систему с жизненным циклом в 2-3, а то и 5 лет – каждый из нас не видит ничего смешного, чтобы заранее предсказать до пикселей – какой функционал системе будет необходим. И затем все мы крайне недоумеваем, когда через пару лет выясняется, что проект вырос совсем не в то, что планировалась заранее.
Главная проблема всех менеджеров продукта в том, что мы со своими планами и ТЗ вмешались в естественный процесс эволюции, о котором не имеем ни малейшего представления. Методика Evo же использует минимальные начальные требования вкупе с ранней и постоянной обратной связью о происходящих процессах, чтобы своевременно корректировать рост и развитие продукта. Никто и никогда не способен заранее постичь и предвидеть миллион факторов, но в методике Evo этого и не требуется. Наблюдательность, здравомыслие и постоянные точечные корректировки — этого минимума достаточно для гарантии большого успеха любого создаваемого продукта.
Конечно, эволюционный менеджмент точно также делит каждый проект на несколько эволюционных циклов. Однако, это разложение в начале пути не предполагает знания ни конечных сроков, ни общего числа этих циклов. Первый цикл эволюции — это решение первой задачи «Достичь Цели № 1 самым простым путем» с последующей аналитикой «Что получилось в итоге?». По сути главное отличие эволюции от стандартных методик: все программисты, заказчики, дизайнеры, скраммастера – постоянно учатся и меняются, как и сам проект. Продукт каждую неделю становится немного другим: чуть больше, чуть лучше, чуть удобнее, чуть популярнее. При этом нельзя сказать, что эта методика декларирует просто «плыть по течению», наоборот — Evo ориентирован на достижение согласованных целей и решение четких задач. И как раз для достижения оптимального эффекта – все требования, выраженные количественно в виде ценности и качества конечного продукта – еженедельно мутируют и обучаются вместе со всеми. Именно так можно дать шанс любой информационной системе безгранично улучшаться, динамично меняя приоритеты при самых минимальных затратах на разработку – просто потому, что вы не делаете ничего лишнего.
Эволюционная методология не позволяет людям строить замки из песка, в которых запираться от реального мира со своими великими идеями и тратить слишком много ресурсов на понимание того, что работать не будет. Она предлагает начинать любой сайт с простой заглушки, лэндинга с одной кнопкой, и затем, по мере роста доходов заказчика и его собственного штата – добавлять все новые и новые страницы, товары и услуги, интерактивные функции и маркетинговые фишки. Вам больше не нужно будет продавать квартиру чтобы СРАЗУ сделать крутой сайт – сделайте простую страничку, чтобы заработать себе дальнейшие бюджеты на развитие всего бизнеса в целом.
Миллион способов убить свой проект
Как бы не был многоопытен каждый из нас, непредсказуемых способов уничтожить свой проект всегда гораздо больше, чем можно предвидеть заранее. Перечислю из собственного опыта лишь самые популярные из них:
• Слишком большая гордость от первоначальной идеи и нежелание ничего менять,
• Безразличие и крайняя ненаблюдательность всей команды разработки,
• Возведенное в сакральный статус невнимание к мелочам,
• Отсутствие самодисциплины у каждого конечного исполнителя: ожидание письма, приказа, пинка для начала размышления над проектом,
• Вера в то, что проблемы решаются числом (людей, дней, денег), а не умением,
• Отсутствие малейшей измеримой системы оценки полученных результатов,
• Подход «Сделаем и поскорее забудем»,
• Непонимание фактора, что главный ресурс в любой информационной системе – это люди,
• Жестокая кара за любые неудачи, вместо повода максимально тщательно проанализировать неверные шаги и стать лучше,
• Создание всевозможных дополнительных ограничений до построения самой системы,
• Попытки сделать очень общее решение сразу для всех с бесконечным масштабом для роста функций,
• Попытки контролировать и навязывать, а не анализировать и обучаться,
• И так до бесконечности…
В завершение своего обзора сразу скажу, что автор, как и все вы, не присутствовал на живых семинарах авторов этой методики, а также не обкатал данную методику несколькими годами практики, чтобы сделать более обоснованные выводы. Более того, я готов сознаться, что, возможно, несколько превратно понял или плохо перевел некоторые постулаты данной методики – именно поэтому и прощу вашей помощи в комментариях дополнить мою статью другими полезными материалами по теме, которые помогут всем читателям, которые придут после вас – получить в комментариях более полную картину отписываемого способа менеджмента.
Ниже перечислю основные прицепы Evo так, как я их уяснил для себя:
1. Максимально быстро получать первые реальные результаты, которые и будут основой для следующего витка эволюции;
2. Следующий шаг эволюции должен быть именно таким, который обеспечивает достижение скорректированных целей и задач по итогам первого этапа,
3. Оставьте своих детей свой проект в покое – это лучшее, что вы можете сделать,
4. Признание самому себе о полном отсутствии экстрасенсорного и астрологического таланта, и в связи с этим раз и навсегда искоренение в себе привычки делать менторским тоном прогнозы и требования,
5. Эволюция подразумевает принцип открытой архитектуры – любой раздел, блок, пункт, страница должна иметь возможность полного исправления за 5-10 минут без перекройки всей платформы,
6. Вы не должны боятся изменений. Меняйте все так часто – как должны,
7. Вся команда проекта Evo должна быть целиком и полностью сосредоточена на текущем витке эволюции. Никто не должен простаивать неделю, месяц, год, в ожидании согласования, подтверждения, включения в работу. Добиваться успеха или терпеть неудачу в текущем шаге – только все вместе, без самых виновных и оставшихся в стороне с чистыми руками. Никто не будут тратить свою энергию на последующих стадиях, влившись в проект на полпути и не постигнув всю историю и принципы его роста с самого начала.
8. Методология Evo — это сплошное обучение. Гуру, менторам и «зазвездившимся» тут не место,
9. Избавляйтесь от всего плохого как можно раньше, не ждите чуда,
10. Не сдавайтесь в полушаге от победы.
Автор: protogui
