Сопутствующий ущерб. Как запускать проекты с меньшей болью

Один из базовых навыков продакт-менеджера — предвидеть последствия решений, особенно косвенные. Его трудно приобрести без практики и приходится тренировать всю жизнь, обучаясь на своих ошибках, болезненных и для вас, и для пользователей. В заголовке я специально использую военный термин, обозначающий случайные жертвы и разрушения во время операции, потому что непредвиденные последствия редко оказываются благоприятными.

Технологические побочные эффекты вам помогут предусмотреть разработчики, если они хорошего уровня и достаточно вовлечены в проект до запуска. У маленьких команд с этим сложнее — если нет выделенного сисадмина, архитектора и DBA, то решать проблемы с производительностью или непонятными падениями приходится постфактум. Если вы делаете что-то новое для всех участников, максимально используйте мониторинг и предусмотрите заранее план отката. 

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

Но последствия не реже возникают и в зоне прямой ответственности продакт-менеджера.

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

Если подобным проектом занимается новый человек, это означает, что обязательно что-то останется не учтенным, даже если вы молодец и у вас есть база знаний. Скорее всего, ее нет или она неполная. Единственный рецепт в больших legacy-проектах — заранее попросить всех, кто что-то знает о проекте, рассказать, где и как используются составляющие сервиса. Даже если мудрецы расскажут вам о древних секретах примерно одно и то же, мелкие детали могут спасти проект от больших проблем.

Другая причина — недостаточная информированность и слепые зоны между участниками команды. Вы рассказали одно программистам и другое маркетологам, а редакторы что-то узнали только после запуска. В результате получается хаос, как на картинке ниже (это первый день,  когда в Швеции поменяли правостороннее движение на левостороннее). Я люблю разговаривать с людьми, но склонен переоценивать очевидность вещей, поэтому несколько раз уже чувствовал на себе, что в менеджменте избыток общения лучше недостатка.

Третья частая причина — неправильные представления об аудитории. Вы недооцениваете соотношение новичков и power users, делаете что-то для молчаливого большинства в 86% и получаете шквал негатива от громких 14%, уничтожающих, например, ваш рейтинг в мобильных сторах. Главная рекомендация в этом случае — проводите как можно больше времени на передовой. Для b2c это поддержка пользователей, для b2b это продажи. В любом случае старайтесь пользоваться своим продуктом как можно чаще и в разных ролях. Аналитика полезна, но ограничиваться только численными показателями опасно.

Бывают, наверное, и другие типы проблем; чем сложнее продукт и предметная область, тем их больше. Непредвиденные последствия всегда будут возникать, и лучшее, что можно сделать — превратить их в полезный опыт. Военные проводят ретроспективы (debrief) после любых операций; проводить ретроспективы после запуска проектов всегда полезно и в менеджменте. Помните, что человеко-часы, потраченные на решение каждой из проблем — это оплата вашего лично обучения. Пользуйтесь этим с толком.

1 комментарий к “Сопутствующий ущерб. Как запускать проекты с меньшей болью

Оставить комментарий