Цитаты из книг автора «Марти Каган»

потребность в обязательствах (и их силу), но стремятся брать на себя только обязательства с высокими требованиями (мы говорили о них выше); широких полномочий: в распоряжении команд имеются инструменты, ресурсы и разрешение делать все необходимое для выполнения взятых обязательств;ответственности: отдельные сотрудники и команды чувствуют себя в полной мере ответственными за взятые на себя обязательства, что подразумевает и негативные последствия за их невыполнение, которые необязательно выражаются в увольнении — подобное случается только в экстремальных ситуациях или в случае неоднократного невыполнения обязательств. Последствия чаще всего выливаются в потерю репутации среди коллег;сотрудничества: самоорганизация и свобода действий безусловно важны, но для достижения больших и значимых целей гораздо важнее уметь работать сообща;результатов: необходимо фокусироваться на результате, а не на процессе; команды часто ищут для себя подсказки в том, что вознаграждается в компании и что в ней приемлемо. Какую команду ждет вознаграждение — ту, что предлагает перспективную новую идею, или ту, что получила реальный результат, взяв на себя повышенные обязательства? И какое сообщение получают люди при виде того, как легко прощается невыполнение обязательств?

Хорошие команды ставят во главу угла референcных клиентов. Плохие команды одержимы борьбой с конкурентами. ГЛАВА

авторитетных экспертов из разных подразделений компании. Плохие команды обижаются, когда «чужаки» лезут не в свое дело. В хороших командах продакт-менеджер, дизайнер и инженер-программист трудятся плечом к плечу, в полной мере осознавая необходимость компромисса между функциональностью, пользовательским опытом и технологией реализации. В плохих командах люди сидят в своих «отсеках» и требуют, чтобы другие делали запросы на их услуги в соответствующей форме с четким соблюдением графика.Хорошие команды постоянно тестируют новые идеи, чтобы не перестать быть новаторами, но делают это так, чтобы доход и бренд компании были защищены. Плохие команды ждут сверху разрешения на каждый тест.Хорошие команды настаивают на том, что у них должны быть все специалисты, необходимые для создания хитов, например сильный дизайнер продукта. В плохой команде о таких специалистах даже не слышали.В хороших командах инженеры-программисты ежедневно тестируют прототипы на этапе исследования и благодаря этому находят новые способы улучшения продукта. Плохие команды дают на оценку прототипы технарям только на этапе планирования спринта.Хорошие команды каждую неделю взаимодействуют с конечными пользователями и клиентами, чтобы лучше понимать их запросы и проблемы и видеть их реакцию на самые новые идеи. Плохие команды думают, что они и есть потребители.Хорошие команды знают, что многие из их любимых идей не понравятся потребителям, а даже если люди их примут, понадобится нескольких итераций, чтобы достичь желаемого конечного результата. Плохие команды просто создают продукт из дорожной карты, довольствуясь при этом тем, что соблюдают установленные сроки и обеспечивают нужное качество на отдельных этапах разработки.Хорошие команды понимают необходимость скорости и знают, что быстрые итерации — это ключ к инновациям; по их мнению, эта скорость произрастает на почве использования правильных методик, а не принудительного труда. Плохие команды объясняют низкую скорость работы недостаточным усердием коллег.Хорошие команды берут на себя обязательства с высокими требованиями только после того, как всесторонне оценят запрос и убедятся, что у них есть жизнеспособное решение, выгодное и полезное как для потребителя, так и для бизнеса. Плохие команды жалуются на то, что в их компании всем заправляет отдел продаж.Хорошие команды применяют инструменты, позволяющие немедленно оценивать, как используется их продукт, и на основании этих данных оперативно вносить коррективы. Плохие команды считают, что иметь возможность просматривать аналитику и отчеты неплохо, но в этом нет особой необходимости. Хорошие команды вводят новые функции в продукт и выпускают релизы постоянно, зная, что непрерывный поток небольших релизов обеспечивает клиентов более надежным решением. Плохие команды тестируют продукт вручную в самом конце болезненного этапа интеграции, а затем одним махом делают релиз.

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

Уже много лет я пылкий сторонник использования данных для управления продуктовыми командами. Вместо того чтобы выдавать команде устаревшие дорожные карты» с составленными кем-то списками догадок относительно того, какие фичи могут (или не могут) сработать, я предпочитаю предложить ей набор бизнес-целей с измеримыми конечными результатами, после чего команда сама принимает решение, какими способами лучше всего этих целей достигать. Это один из аспектов всеобъемлющей тенденции, наблюдающейся сегодня в сфере разработки новых продуктов — сосредоточиваться на результате, а не на процессе. ГЛАВА 54 КОЛИЧЕСТВЕННЫЕ МЕТОДИКИ ТЕСТИРОВАН

Эти команды могут по-разному формулировать проблемы, иногда их терминология несколько различается, но в целом все они придерживаются трех принципов

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

Тот факт, что мы потратили время и силы на создание работающего продукта, еще не означает, что кто-то захочет его купить.

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

Самым большим недостатком устаревшей каскадной модели было и остается то, что все риски сосредоточены в самом