* — слайды и слайды с комментариями.
Я часто слышу, что заказная разработка — это зло. Заказчик-самодур диктует свои условия, а разработчики пляшут под его дудку, пишут на Друпале (привет Омск), не высыпаются и мечтают о продуктовой разработке. Где, говорят, один внутренний заказчик, который всё знает, пишет подробное ТЗ, сроки гибкие, а разработчиков кормят плюшками с клюквой и возят на конференции. Все счастливы!
На самом деле нет. Есть свои нюансы, которые стоит учитывать.
О них я и расскажу:
— Product team VS feature team VS “dev на 50% времени и frontend на 20%, test на 100%”.
— “Продакт все знает он нам напишет подробное ТЗ” VS прототипы и сплит-тестирование.
— Старожилы VS живчики.
— “Сначала сделаем, потом подумаем как зарабатывать”.
Персонажи и события не выдуманы, буду использовать опыт 2ГИС.
10. Темная сторона продуктовой
разработки
Кудзев Артём @ 2ГИС
— Опыт с Омском и отказ открывать офис, т.к. аутсорсинг.
— Ситуация изменилась и это видно по текущей конференции
и её потокам.
— Поговорим о продуктовой разработке, о её темной стороне.
11. • Кудзев Артём — замдир
R&D, CodeFest, DevDay.
• 2ГИС — 30+ команд, 15 млн.
пользователей.
• Продукты — 2ГИС (онлайн,
десктоп, смартфоны), АПИ
карт и справочника, Фламп.
— Почему я вам это рассказываю?
— ИТ-менеджер в 2ГИС, отвечаю за команды и процессы.
— 6 продуктов (...), 30 команд, 15 млн. пользователей.
— Заказчик внутри, разработка тоже.
— Опыт есть!
ЦА — менеджеры продукта, проекта, тимлиды, кто хочет или
практикует разработку продуктов.
12. Продуктовая разработка —
не серебряная пуля.
— Основная мысль: Продуктовая разработка — не серебряная
пуля.
— Зачем? Собираетесь или разрабатываете продукт. Не
наступайте на наши грабли.
— Как? Используйте тот опыт о котором я вам расскажу.
13. Один за всех и
все за одного.
Команда
1. Команда составная по профилям. Работают в ползагрузки,
четверть и пр. К проект не привязаны.
2. Фича тим. Команда стабильная и решает класс проблем,
например интеграция с биллингом, поиск но на разных
продуктах.
3. Продакт тим. Все вместе, все привязаны к проекту.
Минус — надо ещё собрать команду, а потом как-то загрузить
узких специалистов: технолог, дизайнер, математик иначе
простой.
Вариант решения — кроссфункциональность, фиксированная
привязка к проекту.
14. Техзадания не будет.
Расходимся!
Требования.
— ТЗ не будет, будет потребность "пользователь хочет
проехать от А до Б".
— А дальше работа с UI и версткой, апробация через
прототипы и сплит-тестирование.
— И, отбой, возможно. Но точно доработки.
Минус — нет ТЗ и не будет, есть потребность, чтобы понять
как её удовлетворить, могут понадобиться несколько
итераций.
Решение — доставлять быстрее, чем сократить путь до
решения.
15. Олдскул, давай,
давай до свиданья!
Темперамент.
— Быстрые изменения, быстрая реакция и особенный
темперамент — живчик (не равнодушный и активный).
— Мало делать хорошо, надо постоянно выходить за границы.
— Готовность к изменениям.
Минусы — сложно найти, готовых тем более. Быстро уходят.
Решение — быть готовым учить и терять.
16. Нельзя взять так просто
и монетизировать
продукт.
Монетизация.
— Фокус на пользователя, а потом на деньги. Обратное
обычно не работает.
— Не понятно какие фичи-то выстрелят, тем более как их
монетизировать, это рискованно.
Минус — в любой момент времени продукт могут свернуть,
если он не будет зарабатывать деньги.
Решение — быть к этому готовым и не растерять команду.
17. Вопросы?
Итак, продуктовая разработка — не серебряная пуля.
У этого подхода есть вполне четкие границы и условия
применения. И чтобы все получилось:
— Вам нужная стабильная продакт-команда со всеми нужными
на борту.
— Будьте готовы работать без ТЗ, а с многочисленными
гипотезами и их проверкой.
— Найдите самых активных разработчиков, будьте готовы их
научить и потом потерять.
И при правильной бизнес-модели все взлетит.