• Работа с техническим долгом.
Архитектура часто не способствует быстрой эволюции продукта и не облегчает эту задачу разработчикам. Безусловно, ее не исправишь в одночасье, так как здесь требуются постоянные и согласованные усилия.• Отсутствие сильных менеджеров продукта.
Отсутствие компетентного менеджера продукта обычно главная причина его медленной эволюции. Недостатки этого специалиста влияют на команду по-разному, но особенно наглядно то, что ее члены работают как «наемники», а не «миссионеры». Продакт-менеджер не вдохновляет людей и не уделяет внимания евангелизации продукта, над которым они трудятся, и команда просто перестает ему верить.• Отсутствие операционного менеджера с техническими навыками.
Важнейшая задача этого специалиста заключается в устранении препятствий, а их список по мере роста технологической компании растет в геометрической прогрессии. И большинство не исчезают сами собой, если их устранением продуманно и целенаправленно не занимается менеджер проекта.• Редкие циклы релизов.
Большинство команд, чья работа продвигается низкими темпами, слишком редко выпускают готовые версии продукта. Ваша команда должна делать релизы не реже раза в две недели (превосходные команды делают это несколько раз в день). Как правило, чтобы исправить ситуацию, нужно серьезнее относиться к автоматизации тестирования и релизов, чтобы команда могла работать быстрее и увереннее.• Отсутствие видения и стратегии развития продукта.
Команда обязана ясно видеть общую картину и знать, какой вклад она делает в общее дело.• Отсутствие стабильных продуктовых команд, работающих в одном месте.
Если команды удалены территориально или, хуже того, технарей привлекают через аутсорсинг, такое положение вещей крайне негативно сказывается не только на инновациях, но и на темпах деятельности компании. Затрудняется даже общение сотрудников. И со временем все становится настолько плохо, что многие аутсорсинговые фирмы добавляют дополнительный слой персонала для координации и коммуникаций, что обычно только усугубляет ситуацию.• Слишком позднее включение инженеров-программистов в исследование продукта.
Инженеры должны участвовать в исследовании продукта с самого начала выработки идеи. Если вы привлечете их, чтобы продакт-менеджер и дизайнер имели возможность учесть их мнение, инженеры смогут предложить альтернативные подходы, с технической точки зрения реализуемые значительно быстрее. В противном случае их несравнимо важный вклад будет сделан слишком поздно.• Слишком позднее включение дизайнеров по продукту в исследование,
в результате чего им приходится делать свою работу одновременно с разработчиками, которые уже пытаются создать продукт, не только замедляет разработку, но и становится причиной скверного дизайна.• Изменение приоритетов.
Надо учитывать, что быстрая смена приоритетов ведет к значительной текучести персонала и снижает как моральный дух, так и производительность коллектива.• Культура, основанная на консенсусе.
Многие компании стремятся к консенсусу, и хоть они обычно делают это с благими намерениями, на практике это означает, что принимать решения становится очень трудно и дела начинают идти со скоростью улитки.Конечно, можно назвать еще множество причин медленной работы над продуктом, но, по моему опыту, здесь перечислены главные виновники.
Глава 67. Создание сильной продуктовой культуры
В этой книге мы говорили о продуктовых командах и методиках исследования успешных продуктов, но, надеюсь, вы заметили, что на самом деле речь в ней шла о продуктовой
К осмыслению продуктовой культуры я подхожу с двух сторон. Во-первых, может ли компания непрерывно заниматься инновациями, постоянно разрабатывая ценные решения для потребителей. Это мы делаем на этапе исследования продукта. А во-вторых, как она его исполняет? Какой бы великой и перспективной ни была идея, она ничего не стоит, если вы не можете создать и предложить потребителям готовый продукт. В этом суть этапа реализации продукта.
В последней главе я опишу, чем отличается сильная
Итак, что означает иметь сильную инновационную культуру? Инновационная культура — это культура:
•