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