Когдапрозрачностьненашуткупугает

На последнем харьковском тренинге у меня была очень интересная группа. Более половины участников оказались менеджерами. Именно этим я объясняю то, что нам пришлось очень часто возвращаться к понятию проекта и его успешности. Project Management Institute (PMI) не помогает нам двигать индустрию в правильном, с нашей точки зрения, направлении. Как и прежде, они говорят об успешных проектах, а не успешных продуктах.

Проекты и продукты. Скажу вам честно, мне абсолютно не интересны проекты. Мне, как конечному потребителю, хочется, чтобы в жизни меня окружали удобные и качественные продукты (машина, бытовая техника, программное обеспечение, квартира, еда, телефон и т.д.), и подозреваю, что в этом желании я не одинок в мире. И если продукт классный, то я буду им пользоваться, не смотря на то, что бюджет проекта был превышен или же сроки его «поплыли» (в этом случае проект считается неуспешным).
Скрам четко говорит нам о том, что его цель – создание и поддержка успешных ПРОДУКТОВ, а не проектов:

Scrum is a framework for developing and sustaining complex products.

А теперь представьте себе, что проект был закончен успешно (в срок, с обещанным объемом функционала, в пределах запланированного бюджета), НО:

• В результате «марша смерти» в конце проекта команда полностью выгорела и нуждается в длительном восстановлении. Кто-то убегает из компании, кто-то берет вынужденный отпуск.
• Продукт никому не нужен. Да, вот так просто. Пилили, пилили, но напилили стружку, которой никто не хочется пользоваться. Нужны примеры? Гугл просто пестрит ими.

Успешный проект говорите? 🙂
Эта страшная вещь – прозрачность. А еще Скрам обладает такой «страшной» и «зубастой» штукой, как прозрачность. И в некоторых случаях она настолько неприемлема для компаний, что ее стараются засунуть как можно дальше, чтобы скрыть неприглядную правду, иметь возможность дальше лгать себе и заказчику. Мне приходится наблюдать это постоянно.

Пример из жизни. Одна аутсорсинговая компания заключила контракт с заказчиком. Скрам Команда должна была в кратчайшие сроки создать новый продукт. Скрам был выбран неслучайно – требования были настолько неопределенными (в случае со стартапом обычная ситуация), что даже менеджмент понял, что классическая схема с бизнес аналитиком, сидящим 2 месяца и набивающим требования перед заходом проекта, не прокатит. Более того, менеджмент был настроен на работу в чистом Скраме, что внушало оптимизм.

Команда стартовала, прошла несколько Спринтов, получила эмпирическую информацию о своей скорости (Velocity) и Скрам Мастер помог Владельцу Продукта сверстать первый Релиз План. Ба-Бах! И тут оказалось, что тот объем функционала, который заказчик рассчитывал получить через полгода, не будет готов даже через год.

На менеджмент компании начал оказывать давление заказчик, а тот в свою очередь на Скрам Мастера. Поняв, что Скрам Мастер не прокладка, просто передающая физическое усилие на команду, а ее защитник, менеджмент перешел к прямому воздействию. Эпилог, к сожалению, очень предсказуем и банален. Кен Швабер прекрасно описывает его в книге Software in 30 Days словами:

Мы знаем, что не должны оказывать давление на разработчиков для того, чтобы подогнать все под план. Наш бизнес страдает из-за подобных действий. Мы давим разработчиков и заставляем их влезать в эфимерные планы. Каждый раз, когда мы это делаем, разработчики отвечают автоматическим понижением качества продукта. Результат так плох, что нам приходится входить в стабилизационную фазу или выходить на рынок с продуктом низкого качества.

Но это еще не конец истории. Менеджмент компании сделал организационные выводы:

У нас Скрам не работает.

Прозрачность и Скрам убрали, Скрам Мастера НЕпрокладку заменили на Скрам Мастера прокладку и перестали мерять скорость. Зачем? А потому что она бы оставалась бельмом на глазе, мешала бы и дальше обманывать заказчика (контракт был Time & Material). Менеджмент не был готов честно признаться, что скорость команды слишком низкая для того, чтобы удовлетворить запросы заказчика и проект, возможно, стоит закрывать или же передать другому вендору, чтобы не тратить попусту деньги. Менять бюджет или резать скоуп, что логично делать в подобных ситуациях, заказчик категорически отказывался.

Напрашивается несколько выводов:

• Чистый Скрам редко когда возможен в компании с anti-Agile культурой. Он привнесет страшную прозрачность. Как только он покажет то, что реальность не сходится с фантастическими планами, от него будут стараться избавиться.
• Скрам предназначен не для успешных проектов, а для успешных продуктов.
• Скрам не может работать или не работать. Эмпирический процесс нейтрален, точка. Он просто показывает на что вы способны, а на что нет. Скрам работает ВСЕГДА в запутанном мире (модель Кеневин).
• Быть Скрам Мастером НЕпрокладкой (не передающим физическое усилие сверху) тяжело, а быть Скрам Мастером прокладкой (передающим физическое усилие сверху) просто.

Как закончилась та история. Недавно я узнал, что продукт, все-таки, выкатили на рынок. Ровно через полтора года, как и прогнозировалось в самом начале. Для меня это означает минимальные шансы на успех, но я буду рад ошибиться. Окном возможностей для любого стартапа сейчас считается период 3-5 месяцев. Если вы не выходите в публичный релиз за это время, риски начинают расти нелинейно, в геометрической прогрессии. Но это уже другая история, о которой мы, возможно, поговорим в следующий раз.