Марти Каган – Вдохновленные. Все, что нужно знать продакт-менеджеру (страница 5)

2. Далее следует упомянуть о фатальной ошибке во время оценки идей. На самом деле я ничего не имею против этого подхода, по крайней мере для идей, требующих больших инвестиций. Но то, как большинство компаний используют его на этом этапе для разработки дорожной карты приоритетов идей, просто нелепо. Объясню почему. Помните два ключевых вопроса, на которые должна дать ответ наша оценка? Сколько денег вы заработаете на этой идее и во что вам обойдется ее реализация? Так вот, в действительности на этом этапе мы понятия не имеем ни о том ни о другом. В сущности, мы просто не можем это знать.

Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).

Как бы там ни было, при разработке продуктов всегда нужно знать, чего мы не можем знать, а на этом этапе мы просто не можем знать, сколько заработаем на той или иной новой идее.

Точно так же мы понятия не имеем, во что нам обойдется создание нового продукта. Без фактического решения проблемы инженерам чрезвычайно сложно предсказывать какие-либо результаты. Большинство опытных разработчиков на этом этапе откажутся давать даже приблизительную оценку, но некоторых из них заставляют или убеждают пойти на компромисс и дать прогноз по типу размеров футболок: просто сообщите нам, каковы шансы этой идеи – «маленькие, средние, большие или очень большие». Очень уж хочется иметь дорожные карты с приоритетами, а для этого нужна какая-нибудь система для оценки идей и замыслов. Поэтому люди играют в бессмысленную игру с оценками.

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

Но тут возникает проблема, возможно, самая серьезная, на которую все закрывают глаза. Я называю это двумя неприятными правдами о продукте.

Первая истина заключается в том, что по крайней мере половина идей не сработают. Это может произойти по целому ряду причин. Чаще всего потребители попросту не придут от них в такой же восторг, как мы. И, как следствие, не выберут наш продукт. Иногда они решают использовать его и пробуют, но отказываются от него из-за чрезмерной сложности, а переход чреват такими проблемами, что овчинка выделки не стоит. А иногда проблема бывает в том, что потребителям продукт, возможно, и понравился бы, но его создание требует намного больше усилий, чем мы думали, поэтому тут уже мы решаем, что не можем позволить себе таких трат.

Словом, я вам обещаю: половина идей из дорожной карты никогда не оправдают ожиданий. (Лучшие команды исходят из предположения, что минимум три четверти идей не сработают так, как им хотелось бы.)

Впрочем, будто этого мало, есть и вторая неприятная правда. Она заключается в том, что для доведения идей, даже с уже подтвержденным потенциалом, до момента, когда они будут приносить необходимую ценность для бизнеса, обычно требуется несколько итераций. Мы называем это соотношением «время – деньги».

Один из самых важных уроков, которые я выучил за годы работы с программным продуктом, состоит в том, что обойти эти обстоятельства невозможно, будь ты хоть ста пядей во лбу. А ведь мне посчастливилось работать со многими исключительно хорошими продуктовыми командами. Так что я могу точно сказать: все зависит от того, как вы справляетесь с ситуацией.

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. Или же они бросаются в другую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответственно, не слишком быстро продвигаются вперед.