ИИ менеджмент продукта 1.0 - страница 4

(Изучить) – если никто не юзает, меняем стратегию (а не добавляем новых фич, надеясь, что «на этот раз зайдёт»).

Как делать MVP, а не «MVP»?

Плохо: год разрабатывать идеальный сервис, потратить 500 тысяч долларов, а потом понять, что он никому не нужен.

Хорошо: запустить лендинг, проверить спрос, обработать 100 заявок вручную и только после этого писать код.

Примеры нормальных MVP

• Airbnb – первые бронирования проходили через Google Forms.

• Zappos – сначала просто фотографировали обувь в магазинах и смотрели, будет ли кто-то покупать.

Золотое правило: MVP должен тестировать одну главную гипотезу.

Если у тебя в «MVP» уже 30 фич – ты что-то делаешь не так.

3.3. Agile: как не застрять в бесконечном планировании

Что такое Agile?

Это когда ты не пишешь 100-страничные ТЗ, а делаешь маленькие улучшения каждую неделю.

Суть: разработка делится на спринты (обычно 1—2 недели).

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

Теперь про Scrum. Это такой конкретный способ применять Agile, чтобы не превратить процесс в хаос. В Scrum есть несколько ролей.

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

Во-вторых, Product Owner – тот, кто отвечает за продукт, общается с пользователями, выслушивает их жалобы, мечты и страдания, а потом решает, какие фичи действительно нужны, а какие – очередная блажь босса.

Ну и, конечно, сама команда, которая все это делает.

Процесс в Scrum выглядит так

• В начале спринта – решаем, что реально важно.

В начале спринта вся команда собирается на планирование, где обсуждает, что именно будет сделано за ближайшие две недели.

После этого каждый день проходит короткая встреча – daily stand-up. Это такой утренний ритуал, где все рассказывают, что сделали, что планируют делать и какие есть проблемы. Длится максимум 15 минут, иначе превращается в собрание уныния.

• В конце – выкатываем хоть что-то работающее.

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

Теперь самое главное – зачем всё это вообще нужно.

Agile и Scrum помогают не зависнуть в бесконечном планировании, не делать то, что никому не нужно, и выпускать обновления быстро, чтобы сразу получать фидбэк. Вместо того чтобы годами пилить огромную фичу, которую в итоге никто не использует, команда может быстро протестировать идею, посмотреть, как на неё реагируют пользователи, и уже потом решать, стоит ли её развивать или проще выкинуть.

Без Agile: CTO пришёл и сказал «Давайте добавим VR-функцию».

С Agile: команда проверила аналитику → увидела, что юзеры дропают продукт на третьем шаге онбординга → сделали онбординг короче вместо бессмысленного VR.

И самое приятное – Agile работает не только в разработке. Его используют маркетологи, дизайнеры, даже менеджеры свадеб. Везде, где нужно делать работу кусочками, получать фидбэк и не угробить нервы, Agile приходит на помощь. Ну, если, конечно, его правильно применять, а не просто переименовать начальников в Scrum Masters и объявить, что теперь у вас «гибкая разработка».