К черту менеджерские карго культы! Дайте нормальное ТЗ

Дмитрий Лобасев

Transcript

1. К  черту  менеджерские   карго  культы!   Дайте  нормальное  ТЗ   Дмитрий  Лобасев   Enterprise  Agile  Coach   ScrumTrek  
2. Дмитрий  Лобасев   •  Enterprise  Agile  Coach,   ScrumTrek     •  Background   –  Разработчик   –  Тимлид   –  Менеджер   –  Архитектор  процессов  
3. (с)  Борис  Вольфсон  
4. Начнем  разбираться  в  проблеме..   Требования  опять   поменялись   Заказчик  не  знает,    чего  хочет   Аналитики  плохо   подумали   Это  бесит   Надоело  переписывать   одно  и  тоже   Получается  кривой  код   Почему?   Почему?   Почему?   Почему?   Почему?  
5. Почему  меняются  требования?  
6. Почему  меняются  требования?  
7. «Стандартный»  цикл  боли  заказчика   Сделайте  мне   так,  чтобы..   Анализируем,   Проектируем   Заказчик   подписывается   Мы  делаем   Заказчик   принимает..  как   есть   Мы  выкатываем..   как  есть   Обрабатываем   запросы  на   изменения  
8. Корень  зла   •  «Если  заранее  сесть  и  как  следует  подумать,  то   можно  качественно  спроектировать  и  в   деталях  описать  будущий  продукт»                        Наш  девиз  :)       Мы  считаем,  что:   •  Проблема  известна   •  Решение  известно  
9. На  самом  же  деле..       IKIWISI   I’ll  Know  It  When  I  See  It       IKIWISI   I’ll  Know  It  When  I  See  It  
10. Бонус:  проблемы  с  ответственностью   •  Очень  известный  банк  и  очень  крупная   аутсорсинговая  компания.  Лето  2013   •  «Проблема  обновления  статусов  ..  дефектом,  с   точки  зрения  разработчиков,  не  является,  поскольку   нет  противоречий  требованиям»   •  «Разработчик  не  считает  проблемы  при   использовании  cmd+V  в  Safari  дефектом,  поскольку   не  было  прописано  требований  к  работе  cmd+V»  
12. КАК  ЭТО  ИСПРАВИТЬ?  
13. Agile!!!!111  
14. Что  это  значит  для  нас   •  Ну  да,  требования  все  равно  будут  меняться   •  Но  мы  же  здесь,  чтобы  помогать  бизнесу   •  Давайте  облегчим  себе  жизнь   –  Будем  проектировать  и  реализовывать  небольшими   порциями   –  Каждые  две  недели  показывать  заказчику   –  С  радостью  вносить  правки  по  результатам  демо   –  Писать  простой,  легко  поддерживаемый  код   –  Автотесты,  рефакторинг,  ну  вы  все  знаете..  :)   •  Цель  –  максимально  уменьшить  стоимость  внесения   изменений   –  Заказчика  все  равно  не  остановить  
15. Как  это  теперь  выглядит  
16. Проблемы  выходят  на  новый  уровень   •  Мы  опять  спроектировали  продукт  заранее   –  Хоть  и  реализуем  его  итеративно  и   инкрементально     •  Фидбек  от  заказчика  определяет  наше   движения   –  Но  продуктом  пользоваться  будет  не  он   Мы  считаем,  что:   •  Проблема  известна   •  Решение  неизвестно  
17. А  что  насчет  конечных  пользователей?       IKIWIEI   I’ll  Know  It  When  I   Experience  It   ???           IKIWIEI   I’ll  Know  It  When  I   Experience  It  
18. НУ  ЕСЛИ  УЖЕ  И  AGILE  НЕ  ПОМОГ..  
19. Co-­‐Creakon   Совместное  с  заказчиком   проектирование  продукта  
20. Формирование  гипотез   •  Неделя  непрерывной  работы  всей  команды  и   заказчика   –  Проектируем  бизнес-­‐модель  продукта  с  учетом   мнений  и  идей  каждого   •  Получаем  всего  лишь  набор  гипотез   •  Цель  –  проверить  наши  предположения  на   реальных  пользователях,  не  написав  ни   строчки  кода  
21. Проблемы   Решения   Уникальное   предложение   ценности   Нечестное   преимущест во   Сегменты   пользовате лей   Метрики   оценки   продукта   Каналы   продаж   Структура  затрат     Потоки  прибыли  
23. Валидация  через  общение   •  Интервьюирование  будущих  пользователей   •  Подтверждение  или  опровержение  гипотез   •  Формирование  новых   •  Цель  –  проверить  как  можно  больше  наших   предположений  в  единицу  времени  
24. Непрерывный  цикл  работы  
25. Валидация  через  деливери   •  На  словах  ок,  пора  переходить  к  делу   •  True  Agile  –  Scrum  –  Kanban  –  WHAT  EVER  YOU   WANT   •  Непрерывная  поставка  конечным   пользователям   –  Начинаем  с  инноваторов,  потом  остальные   –  Все  время  собираем  обратную  связь  (общение  +   продуктовые  метрики)  
26. Бизнес-­‐метрики  как  подтверждение   создания  правильного  продукта!  
27. Разница  в  подходах   Agile   •  Мы  считаем,  что  нам   неизвестно  решение   •  Ориентируемся  на  фидбек  от   заказчика  на  демо     •  Делаем  довольным   заказчика   •  Цель  –  готовый  к  поставке   продукт   •  Инкремент  –  недели   Co-­‐creakon  (lean  startup)   •  ..  Мы  даже  не  знаем   исходной  проблемы   •  На  поведение  пользователей   в  продакшн     •  Работаем  над  бизнес-­‐ метриками   •  Цель  –  провалидировать   гипотезу  и  научиться   •  Инкремент  –  часы  
28. ПРИМЕР  РАЗВОРОТА  КОНЦЕПЦИИ  
29. Минимальная  версия  продукта  
30. Новое  требование  через  3  недели  :)  
31. Немного  другая  модель  восприятия   •  Продукт  для  заказчика  –  наш  стартап   –  Команда  на  фултайм   –  Проектируем  продукт  совместно  с  заказчиком   –  Ориентируемся  на  результат  через  бизнес-­‐метрики   •  Пользователи   •  Деньги   •  И  т.п.  в  зависимости  от  продукта   •  Заказчик  –  наш  инвестор   –  Который  ждет  окупаемости  
32. Требуется  чуть  другое  окружение   •  Хорошо  работает  в  современной  модели   мотивации   –  Автономность   –  Мастерство   –  Предназначение  (миссия)   •  До  тех  пор,  пока  человек  сам  не  начнет  менять   мир  вокруг  себя,  никто  за  него  этого  не   сделает   –  Ну  или  менять  компанию  :)  
33. Спасибо!