3. Что сегодня будет?
— приоритезация фич
(«управление продуктом»)
— планирование разработки
(«управление процессом»)
— требования и ожидания
(«управление ожиданиями»)
— технический долг, управление им
20. — Важность для покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Важность для бизнеса
— Влияние на остальные процессы
— Размер заинтересованной аудитории
— Стоимость
Критерии
21. «Важность для покупателя»
1. серьезная ошибка в достатожно
важной операции
2. серьезная проблема usability
или отсутствие важного функционала
или серьезная непрозрачность
3. фича, без которой достаточно сложно
работать с сайтом
4. фича, помогающая в работе
5. «cherry on top»
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
22. «Сложность создания»
1. Часы
2. Дни
3. Недели
4. Месяцы
5. Не ясно
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
23. «Вероятность успеха»
1. Точно знаем на основании
проверенных фактов
2. Имеем какое-то количество
подтверждений
3. Верим, потому что логично
4. Не уверены
5. Не ясно
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
24. «Снижение расходов»
1. Можем количественно
оценить, достаточно большое
2. Можем количественно
оценить, небольшое
3. Снижение возможно, но
размер непонятен
4. Не уверены
5. Не ясно
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
25. «Влияние на остальные процессы»
1. Открывает другие возможности
2. Достаточное упрощение
процессов
3. Возможное небольшое
влияние
4. Не влияет
5. Может ухудшить
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
26. «Важность для бизнеса»
1. Можем количественно
оценить, достаточно большое
2. Можем количественно
оценить, небольшое
3. Снижение возможно, но
размер непонятен
4. Не уверены
5. Не ясно
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
27. «Размер заинтересованной аудитории»
1. Все пользователи
2. Заметная часть аудитории
3. Незначительная часть
аудитории
4. Только внутренние
пользователи
5. Невозможно оценить
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
28. «Стоимость»
1. Есть доход!
2. Нет затрат
3. Только наша работа
4. До … рублей
5. Свыше … рублей
— Важность для
покупателя
— Сложность создания
— Вероятность успеха
— Снижение расходов
— Влияние на остальные
процессы
— Важность для
бизнеса
— Размер
заинтересованной
аудитории
— Стоимость
33. Этапы
1. Понять зачем делать
2. Понять, что делать
3. Понять, как долго делать
4. Понять, как делать
5. Уточнить, как долго делать
6. Понять кем делать
7. Делать
8. Понять, что сделано
1. Понять, как сделано
2. Понять, стоило ли?
Постановка проблемы
Постановка задачи
Оценка сроков
Разработка ТЗ
Оценка сроков
Постановка в план
Продукт
Отчет: что сделано
Ревью-отчет: ретроспектива
Ревью-отчет: Бизнес-импакт
34. Реестр известных проблем
Реестр известных ошибок
Реестр известных рисков
«Понять, ЗАЧЕМ делать»
Бизнес-проблемы
Проблемы пользователя
Проблемы с надежностью
Проблемы с безопасностью
…
36. Оценка ресурсов
($, людей — своих/чужих, материалов)
«Понять, КАК ДОЛГО делать»
Метод «Дельфи»
«Уровень величины»
Диапазоны
Лучше какая-то оценка,
чем никакая
38. Конкретные ответственные
Ключевые роли
«Понять, КЕМ делать»
Не забыли про риски
«заболел»
Не забыли про риски
«не смог»
Кто управляет Кто «кодит»
Кто отвечает за сроки Кто отвечает за архитектуру
Кто отвечает за ресурсы
45. Игнорировать «дизайн» системы
брать деньги в долг
Рефакторинг (переделка)
способ возврата долга
Замедление разработки из-за арх. хаоса
выплата процентов
Провал проекта
облава налоговой полиции и конец бизнеса.
Технический долг
52. Как посчитать, сколько должны?
1. Список задач по улучшению «архитектурной
красоты» решения
2. Договориться с менеджментом о квоте на
такие задачи
3. Выбрать стратегию
53. Стратегия по устранению технического долга
1. Выделенная команда
(+ресурсы, - перегорают, дорого, распространение знаний)
1. Технологический налог
(+распространение знаний, -сложное планирование)
54. Когда действительно стоит брать в долг?
1. Близкий релиз с жесткими сроками
2. Заранее выделить время на рефакторинг
