Оглавление
- Отзывы о книге
- Предисловие
- Кому нужна эта книга
- Об авторе
- Благодарности
- Структура книги
- Раздел I. Управление IT-продуктами
- Глава 1. Кнопочное мышление против целостного IT-продукта
- Откуда берутся кнопочные идеи
- Торопыги
- Решалы
- Спасители
- Я – могучий генератор кнопок
- Мимикрирующие User Story и хитрые Product Owner'ы
- User Story как фильтр
- Хитрые Product Owner'ы
- Мимикрирующие User Story
- Преждевременные решения
- Истории из жизни
- Сколько стоят 1000 строк кода?
- Истории из жизни
- Движение без цели
- Истории из жизни
- Рефлексия и душевный покой
- Глава 2. Impact Mapping на практике
- История появления Impact Mapping
- Руки без головы
- Составляем Impact Map
- Why?
- Who?
- How?
- What?
- Организация процесса
- Пример из практики
- Why?
- Who?
- How?
- What?
- Результаты создания Impact Mapping
- Фильтр входящих задач
- Модернизация Kanban-доски
- FAQ по Impact Mapping
- Глава 3. Углубление в Impact Map
- Нюансы Impact Mapping
- Типичные ошибки Impact Mapping
- Impact Mapping гончара
- Почему так сложно сформулировать идею?
- Глава 4. Пять самых важных составляющих процесса выпуска успешных продуктов
- Общий взгляд на процесс
- Конец ознакомительного фрагмента
Истории из жизни
Кейс: Требуется больше всплывающих окон
Представьте IT-отдел внутри компании. Руководители отдела маркетинга, финансов и прочих ставят ему задачи. Приходит начальник, который отвечает за точки продаж, и требует добавить всплывающее сообщение раз в 10 минут на рабочем месте. Работников на местах обяжут нажимать «ОК» в модальном окне каждые 10 минут, чтобы понять, на месте работник или нет. Задача как задача; IT-отдел взял да и сделал. Прошло время. Работники на местах ужились с новшеством.
В IT-отдел пришёл начальник маркетинга и попросил добавить всплывающее сообщение, чтобы работник выходил на улицу и раздавал листовки. Сообщение по задумке всплывает каждые 30 минут, в результате должны повыситься продажи. Задача как задача; IT-отдел взял да и сделал.
На местах это вылилось в противоречивый сценарий. Работник видит сообщение о том, что надо идти на улицу и раздавать листовки. Он выходит и раздаёт, а в это время всплывает сообщение: «Ты на месте?»
Почему так произошло? Никто не контролировал целостность системы. Многоголовый Product Owner приносил задачу, разработчики брали задачу, не создав целостной картинки поставки ценности, поэтому они не увидели противоречий.
Кейс: Зачем делаем?
Заказчик пришёл с идеей сделать приложение для курьеров. Заказчик – федеральная компания, сотни филиалов по стране. Цель продукта – оптимизация работы курьеров.
До работы с нами у проекта накопилась полугодовая история. Заказчику сделали ТЗ, реализовали часть мобильного клиента, но не сделали серверную часть. С этой историей заказчик пришёл к нам. Мы начали проект по нашему процессу, и уже к концу Customer Journey Mapping заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через три месяца. В итоге вернулись через полгода с перестроенной компанией, которая стала готова для создания нового продукта. Продукт мы сделали и успешно запустили. Мы считаем это успехом, так как не позволили потратить время на что-то бесполезное.