Эволюционное управление разработкой — гарантированный путь к успеху

Изучив и опробовав на практике несколько вариантов 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

Источник ^[1]