Ознакомительная версия. Доступно 15 страниц из 71
4. Далее рассмотрим роль продакт-менеджера в этой модели. В сущности, ее даже не следовало бы так называть; на самом деле менеджер здесь является скорее менеджером проекта, чем продукта, потому что речь идет фактически о сборе требований и документировании их для инженеров-программистов. А это не имеет никакого отношения к реалиям современного менеджмента высокотехнологичных продуктов.
5. То же самое можно сказать и о роли дизайна. Для извлечения его реальной ценности уже слишком поздно, и в основном делается то, что мы назвали бы «сделать из дерьма конфетку». Ущерб уже нанесен, и теперь мы просто пытаемся внешне скрасить итог, представив хаос в лучшем свете. Дизайнеры пользовательского интерфейса знают, что он не хорош, но стараются сделать его привлекательным и логичным, насколько это возможно.
6. В этой модели инженеров слишком поздно подключают к процессу, что, на мой взгляд, огромная упущенная возможность. Мы всегда говорим: если ваши разработчики только пишут коды, вы используете их вполсилы. Раскрою вам маленький секрет: инженеры-программисты — лучший источник новаторских идей. А их слишком часто не приглашают принять участие в этом процессе.
7. Не только инженеров включают в процесс слишком поздно, то же самое касается принципов и ключевых преимуществ Agile. Команды, которые применяют Agile таким способом, используют фактическую ценность и потенциал этого метода процентов на двадцать, не более. В итоге мы чаще всего видим то, что можно назвать Agile для этапа запуска продукта, но остальная часть организации и контекст не имеют с гибкостью ничего общего.
8. Весь этот процесс в высшей мере ориентирован на проект. Обычно компания финансирует проекты, подбирает для них людей, «проталкивает» через разные уровни организации и наконец запускает. Увы, в проекте главное — процесс, а в продукте — результат, поэтому он предсказуемо оказывается неприглядным. В конце концов что-то создается, но оно не соответствует целям и задачам. В чем же тогда смысл? В любом случае это серьезная проблема; совсем не так нужно подходить к созданию продуктов.
9. Самым большим недостатком устаревшей каскадной модели было и остается то, что все риски сосредоточены в самом конце процесса; иными словами, проверка продукта на потребителе происходит слишком поздно.
Как известно, ключевой принцип Lean-системы (системы бережливого производства) — это сокращение потерь (отходов), а одной из худших форм таких потерь считается проведение проектирования, изготовления, тестирования и развертывания функции или продукта с тем, чтобы в конце этого долгого пути узнать, что это совсем не то, что нужно пользователю. И вот парадокс: многие команды убеждены, что применяют Lean-принципы, а между тем используют описанный мной базовый процесс. И тут я указываю им на то, что они проверяют свои идеи одним из самых дорогих и самых медленных способов из всех известных.
10. И наконец, пока мы сильно заняты этим процессом и крайне непродуктивно тратим время и деньги, наибольшей нашей потерей обычно становится цена упущенной возможности, то есть того, что наша организация могла и должна была сделать вместо этого. А это время или деньги, которых уже не вернешь.
Учитывая все вышесказанное, стоит ли удивляться, что так много компаний тратят ценные ресурсы, получая столь жалкую отдачу. А я предупреждал, что то, что я скажу, может огорчить вас. Но я все равно говорю об этом, потому что очень важно в полной мере понимать, почему ваша компания должна изменить подход к работе — если, конечно, она работает так, как я описал.
У меня для вас есть и хорошая новость: лучшие команды работают совершенно иначе, и мы можем у них этому поучиться.
Глава 7. Lean и Agile и не только
Люди всегда искали и продолжают искать некое волшебное средство, верный рецепт создания успешных продуктов, и всегда найдется отрасль, готовая им в этом помочь, — отрасль, которая только и ждет, чтобы предложить им книги, коучинг, обучение и консультации. Но у нее нет волшебной палочки, и люди рано или поздно это неизбежно понимают. И тогда для «верных рецептов» наступает час расплаты.
Сейчас, на момент написания этих строк, в моде критиковать как Lean, так и Agile. Я не сомневаюсь, что многие люди и команды в той или иной мере разочарованы результатами применения этих методологий. Мне понятны причины их разочарования. Тем не менее, по моему убеждению, ценности и принципы Lean и Agile пришли к нам надолго. Не столько их конкретные проявления, которые сегодня применяют многие команды, сколько принципы, лежащие в их основе. Я сказал бы, что обе методологии представляют собой значительный прогресс, и мне очень не хотелось бы стать свидетелем отступления на этих двух фронтах.
Но, как я уже сказал, их тоже нельзя считать волшебными средствами, и, как и в случае с любым инструментом, нужно подходить к их использованию с умом. Множество команд утверждают, что придерживаются принципов Lean, а сами месяцами работают над тем, что называют «минимально жизнеспособным продуктом» (minimum viable product, MVP). На самом деле они не знают, что у них получилось и будет ли это продаваться, до тех пор, пока не потратят массу времени и денег. Вряд ли такая стратегия в духе Lean. Или же они бросаются в другую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответственно, не слишком быстро продвигаются вперед.
Что же касается Agile, то выше я уже говорил, что использование этих методов на практике большинством компаний — разработчиков высокотехнологичных продуктов не имеет отношения к гибкости.
Лучшие известные мне продуктовые команды уже отказались от таких подходов; они руководствуются принципами Lean и Agile, но гораздо выше поднимают планку своих целей и способов работы. Эти команды могут по-разному формулировать проблемы, иногда их терминология несколько различается, но в целом все они придерживаются трех принципов:
1. Риски нужно учитывать в самом начале, а не в конце работы над идеей или продуктом. В лучших современных командах стараются максимально избавиться от рисков до принятия решения о начале работы. Речь идет о риске ценности (будут ли люди покупать это), риске юзабилити (удобства использования) (смогут ли пользователи понять, как это работает), риске реализуемости (осуществимости) (смогут ли инженеры создать то, что нужно, с учетом времени, навыков и технологий, имеющихся в распоряжении) и риске бизнес-жизнеспособности (будет ли это решение полезным для разных аспектов бизнеса: продаж, маркетинга, финансов, юридических вопросов и так далее).
2. Продукты определяются и разрабатываются совместно, в сотрудничестве, а не последовательно. Наилучшие команды вышли за рамки старой модели, в которой менеджер продукта выясняет и определяет технические условия, дизайнер-проектировщик разрабатывает решение, обеспечивающее их выполнение, а затем инженеры-программисты осуществляют их на практике — и каждому приходится считаться с ограничениями и учитывать решения тех, кто шел в этом процессе до них. В сильных командах все трудятся плечом к плечу, обмениваясь идеями и во всем помогая друг другу, чтобы придумать технологические решения, которые полюбят потребители и которые принесут реальную выгоду бизнесу.
Ознакомительная версия. Доступно 15 страниц из 71
