На последнем харьковском тренинге у меня была очень интересная группа. Более половины участников оказались менеджерами. Именно этим я объясняю то, что нам пришлось очень часто возвращаться к понятию проекта и его успешности. Project Management Institute (PMI) не помогает нам двигать индустрию в правильном, с нашей точки зрения, направлении. Как и прежде, они говорят об успешных проектах, а не успешных продуктах.
Проекты и продукты. Скажу вам честно, мне абсолютно не интересны проекты. Мне, как конечному потребителю, хочется, чтобы в жизни меня окружали удобные и качественные продукты (машина, бытовая техника, программное обеспечение, квартира, еда, телефон и т.д.), и подозреваю, что в этом желании я не одинок в мире. И если продукт классный, то я буду им пользоваться, не смотря на то, что бюджет проекта был превышен или же сроки его «поплыли» (в этом случае проект считается неуспешным).
Скрам четко говорит нам о том, что его цель – создание и поддержка успешных ПРОДУКТОВ, а не проектов:
Scrum is a framework for developing and sustaining complex products.
А теперь представьте себе, что проект был закончен успешно (в срок, с обещанным объемом функционала, в пределах запланированного бюджета), НО:
Успешный проект говорите? 🙂
Эта страшная вещь – прозрачность. А еще Скрам обладает такой «страшной» и «зубастой» штукой, как прозрачность. И в некоторых случаях она настолько неприемлема для компаний, что ее стараются засунуть как можно дальше, чтобы скрыть неприглядную правду, иметь возможность дальше лгать себе и заказчику. Мне приходится наблюдать это постоянно.
Пример из жизни. Одна аутсорсинговая компания заключила контракт с заказчиком. Скрам Команда должна была в кратчайшие сроки создать новый продукт. Скрам был выбран неслучайно – требования были настолько неопределенными (в случае со стартапом обычная ситуация), что даже менеджмент понял, что классическая схема с бизнес аналитиком, сидящим 2 месяца и набивающим требования перед заходом проекта, не прокатит. Более того, менеджмент был настроен на работу в чистом Скраме, что внушало оптимизм.
Команда стартовала, прошла несколько Спринтов, получила эмпирическую информацию о своей скорости (Velocity) и Скрам Мастер помог Владельцу Продукта сверстать первый Релиз План. Ба-Бах! И тут оказалось, что тот объем функционала, который заказчик рассчитывал получить через полгода, не будет готов даже через год.
На менеджмент компании начал оказывать давление заказчик, а тот в свою очередь на Скрам Мастера. Поняв, что Скрам Мастер не прокладка, просто передающая физическое усилие на команду, а ее защитник, менеджмент перешел к прямому воздействию. Эпилог, к сожалению, очень предсказуем и банален. Кен Швабер прекрасно описывает его в книге Software in 30 Days словами:
Мы знаем, что не должны оказывать давление на разработчиков для того, чтобы подогнать все под план. Наш бизнес страдает из-за подобных действий. Мы давим разработчиков и заставляем их влезать в эфимерные планы. Каждый раз, когда мы это делаем, разработчики отвечают автоматическим понижением качества продукта. Результат так плох, что нам приходится входить в стабилизационную фазу или выходить на рынок с продуктом низкого качества.
Но это еще не конец истории. Менеджмент компании сделал организационные выводы:
У нас Скрам не работает.
Прозрачность и Скрам убрали, Скрам Мастера НЕпрокладку заменили на Скрам Мастера прокладку и перестали мерять скорость. Зачем? А потому что она бы оставалась бельмом на глазе, мешала бы и дальше обманывать заказчика (контракт был Time & Material). Менеджмент не был готов честно признаться, что скорость команды слишком низкая для того, чтобы удовлетворить запросы заказчика и проект, возможно, стоит закрывать или же передать другому вендору, чтобы не тратить попусту деньги. Менять бюджет или резать скоуп, что логично делать в подобных ситуациях, заказчик категорически отказывался.
Напрашивается несколько выводов:
Как закончилась та история. Недавно я узнал, что продукт, все-таки, выкатили на рынок. Ровно через полтора года, как и прогнозировалось в самом начале. Для меня это означает минимальные шансы на успех, но я буду рад ошибиться. Окном возможностей для любого стартапа сейчас считается период 3-5 месяцев. Если вы не выходите в публичный релиз за это время, риски начинают расти нелинейно, в геометрической прогрессии. Но это уже другая история, о которой мы, возможно, поговорим в следующий раз.
Фича | Цена задержки | Сколько времени делают |
---|---|---|
А | 5 000 $ | 10 дней |
В | 5 000 $ | 5 дней |
С | 10 000 $ | 5 дней |