БІЗНЕС-КНИГИ
Підписуйтесь на Менеджмент.Книги
сучасні бізнес-концепції, проривні ідеї, авторські тези
та цінні інсайти — не часто, виважено, по суті
Управління проєктами/продуктами
КУПИТИ КНИГУ ↓
Kniga.biz.ua
Назва: Мапа історій користувача. Відкрий правдиву історію, створи саме той продукт
Автор(и): Джеф Петтон
Видавництво: "ArtHuss", — 2022
Опис:
Оригінал (англ.): "User Story Mapping: Discover the Whole Story, Build the Right Product" by Jeff Patton
Розробка мапи історій (story mapping) — це техніка, яка дає змогу побачити цілісну картину, чого не вдалося б зробити за допомогою простого набору історій. Ось, власне, і все — опис книги вклався в одне реченні, але цього цілком достатньо, щоб оцінити переваги методу. Огляд цілісної картини полегшує взаємодію з користувачами, дозволяє уникнути розробки непотрібних функцій, а також орієнтує на релевантний досвід користування.
Передмова Мартіна Фаулера ˅
Ця книга не лише для тих, у кого на бейджі або у профілі написано щось на кшталт «бізнес-аналітик». Напевно, найбільшим розчаруванням для мене за 10 років впровадження методології Agile стало те, що чимало програмістів розглядають історії як якісь односторонні вказівки з боку аналітиків. Але якщо ви справді хочете отримати ефективне ПЗ, яке може органічно вбудуватися в людську діяльність, то тих, хто створює програми, необхідно розглядати як джерело ідей про можливості, оскільки ніхто не знає, що можуть зробити програмісти, так добре, як самі програмісти. Тож ці люди повинні добре розуміти, що хочуть отримати їхні користувачі, і взаємодіяти з ними, створюючи мапи історій, де повністю враховано цілі користувачів.
Про автора:
За два десятки років у професії Джефф Паттон (Jeff Patton) дізнався, що немає «єдиного правильного способу» проєктувати й розробляти програмне забезпечення, але є багато хибних способів. Джефф зосередився на підходах Agile ще коли на початках своєї кар’єри, у 2000 році, працював у команді Extreme Programming. Зокрема він спеціалізується на інтеграції ефективного дизайну користувальницького досвіду та практики управління продуктом із сильною інженерною складовою.
Наразі Джефф працює незалежним консультантом, тренером із адаптивних процесів, тренером із процесів розробки продуктів та викладачем. Його нові статті, есе та презентації про різноманітні аспекти Agile-розробки продуктів можна знайти на сайті agileproductdesign.com та в Alistair Cockburn’s Crystal Clear. Джефф — засновник і модератор списку дискусійної групи Yahoo щодо зручності користування, оглядач StickyMinds.com і IEEE Software, сертифікований Scrum-тренер, а також переможець премії Agile Alliance’s 2007 Gordon Pask Award за внесок у Agile Development.
ЗМІСТ ˅
- Передмова Мартіна Фаулера
- Передмова Алана Купера
- Передмова Марті Кеґана
- Передмова
- Прочитайте це насамперед
- 1. Велика картина
- Слово на букву «А»
- Розповідати історії, а не писати історії
- Розповідати всю історію
- Гері та трагедія відкладеної роботи
- Говоріть і документуйте
- Сформулюйте свою ідею
- Опишіть своїх покупців і користувачів
- Розкажіть історії ваших користувачів
- Вивчіть деталі й варіанти
- 2. Плануйте створювати менше
- Мапи допомагають великим групам досягти загального розуміння
- Мапи допомагають заповнити прогалини у вашій історії
- Завжди забагато
- Створення мінімального життєздатного продукту
- Створення дорожньої мапи випуску
- Ставте у пріоритет не особливості, а результати
- Це магія, це справжня магія
- Чому ми так багато сперечаємося про MVP
- Новий MVP — це зовсім не продукт!
- 3. Плануйте, щоб навчатися швидше
- Почніть із обговорення перспектив
- Підтвердьте наявність проблеми
- Прототипуйте, щоб досліджувати
- Критично ставтеся до того, що люди кажуть про свої бажання
- Розробляйте, щоб досліджувати
- Повторюйте до життєздатності
- Як робити не треба
- Емпіричне навчання
- Ставте мінімальні експерименти
- Давайте підсумуємо
- 4. Плануйте завершити вчасно
- Поділіться з командою
- Секрет правильного оцінювання витрат часу
- Плануйте розробку крок за кроком
- Не кожен зріз гідний релізу
- Іще один секрет правильного оцінювання часових витрат
- Регулюйте свій бюджет
- Що зробив би Вінчі?
- Ітерації та приріст
- Дебют, міттельшпіль, ендшпіль
- Розділіть стратегію розробки просто на мапі
- Насправді суть у ризиках
- Що тепер?
- 5. Ви вже знаєте, як
- 1. Записуйте свою історію покроково
- Завдання — це те, що ми виконуємо
- Мої завдання відрізняються від ваших
- Я орієнтуюся на деталі
- 2. Організуйте свою історію
- Додайте пропущені деталі
- 3. Дослідіть альтернативні історії
- Зберігайте цілісність
- 4. Заберіть усе зайве, щоб виділити основне
- 5. «Наріжте» завдання, необхідні для досягнення результату
- От і все! Ви засвоїли всі важливі поняття
- Спробуйте вдома чи на роботі
- Це теперішнє, а не майбутнє
- Випробуйте метод у реальності
- Із програмним забезпеченням складніше
- Мапа — це лише початок
- 6. Справжня історія про історії
- Деструктивно проста ідея Кента
- Просто не значить легко
- Рон Джефрі та три «С»:
- 1. Card (Картка)
- 2. Conversation (Розмова)
- 3. Confirmation (Підтвердження)
- Слова і малюнки
- Оце й усе
- 7. Розповідаємо найкращі історії
- Класний шаблон Connextra
- Шаблонні зомбі та снігоочисник
- Контрольний список того, про що справді варто говорити
- Створюйте фотографії з відпочинку
- Є чим перейматися
- 8. Це ще не все на картці
- Різні люди, різні розмови
- Нам потрібна більша картка
- Радіатори та ящики з льодом
- Цей інструмент не для цього
- 9. Мапа — це лише початок
- Конструюйте, маючи чітке уявлення в голові
- Будуйте усну традицію оповідей
- Перевіряйте результати своєї роботи
- Це не для вас
- Будуйте, щоб учитися
- Не завжди йдеться про програмне забезпечення
- Плануй учитися і вчися планувати
- 10. Випікайте історії, як торти
- Почніть із рецепта
- Розділімо торт на шматки
- 11. Скелеломка
- Розмір завжди має значення
- Історії як скелі
- Епоси — це великі камені, якими іноді б’ють по людях
- Теми: Виокремлюйте групи оповідей
- Забудьте про ці терміни та зосередьтесь на оповіді
- Почніть із можливостей
- Виявіть мінімально життєздатне рішення
- Заглиблюйтеся в деталі кожної історії під час донесення
- Продовжуйте говорити, будуючи
- Оцініть кожну частину
- Оцініть разом із користувачами та клієнтами
- Оцініть разом із зацікавленими сторонами бізнесу
- Звільніть і продовжуйте оцінювати
- 12. Скелеломники
- Цінний — Придатний — Здійсненний
- Команді Discovery знадобиться ще багато, щоб досягти успіху
- Три дружки
- Власник продукту як виробник
- Це складно
- 13. Почніть із можливостей
- Розмови про можливості
- Копайте глибше, викидайте на смітник або думайте далі
- Можливість не повинна бути евфемізмом
- Мапа історії та можливості
- Будь вибагливим
- 14. Використання Discovery для створення спільного розуміння
- Discovery — це не створення програмного забезпечення
- Чотири важливі кроки до відкриття
- 1. Сформулюйте ідею
- 2. Зрозумійте клієнтів і користувачів
- 3. Уявіть своє рішення
- 4. Мінімізуйте і плануйте
- Діяльність відкриття, обговорення та артефакти
- Discovery призначено для створення спільного розуміння
- 15. Використання Discovery для перевіреного навчання
- Переважно ми помиляємося
- Старі недобрі часи
- Емпатія, фокус, формулювання, прототип, тестування
- Як зіпсувати хорошу справу
- Короткі цикли з емпіричним навчанням
- Як Lean Startup Thinking змінює дизайн продукту
- Почніть із припущень
- Визначте ризиковані припущення
- Дизайн, реалізація невеликого тесту
- Отримуйте зворотний зв’язок із тестування з користувачами та замовниками
- Перегляньте своє рішення та припущення
- Історії та мапи історій
- 16. Уточнюйте, визначайте та створюйте
- Картки, обговорення, багато карток, багато обговорень
- Різання та полірування
- Проведення семінарів із історії
- Планування спринту чи ітерації
- У натовпі не може бути співпраці
- Важливість компактності
- Використовуйте мапу історій під час розробки
- Використовуйте мапу для візуалізації прогресу
- Використовуйте прості мапи під час семінарів історії
- 17. Історії насправді як астероїди
- Зворотне складання розбитого каміння
- Не перестарайтеся, складаючи мапи
- Не хвилюйтеся через дрібниці
- 18. Учіться на всьому, що ви створюєте
- Оцініть свою командну роботу
- Оцініть свою роботу за допомогою інших працівників організації
- Достатньо
- Навчайтеся у користувачів
- Викладайте уроки з релізів користувача
- Результати за розкладом
- Використовуйте мапи для оцінювання готовності релізу
- Кінець чи не кінець?
- Подяки
- Посилання
- Покажчики