РИТ++ 2017, Whale Rider Зал Москва, 5 июня, 17:00 Тезисы: http://whalerider.ru/2017/abstracts/2534.html В кулуарах мы часто слышим, что рентабельность веб-студий и заказной разработки сокращается или находится около нуля. Проведенные нами опросы подтверждают это наблюдение. Основные причины этому: ошибки в оценке бюджета проекта, изменяющийся скоуп и несоответствие результата ожиданиям заказчика. Ответ на вопрос, почему это происходит, будет рассмотрен в ретроспективе наших устоявшихся подходов ведения проектов. ...

1. Повышаем
рентабельность заказной
разработки через
эффективное ТЗ
Евгений Савицкий

2. Познакомимся!
17 лет в разработке ПО
- заказная и продуктовая разработка
- архитектор, аналитик, разработчик
- технический директор в Devprom

3. Успех заказной разработки в…
Количество заказов
Качественный результат
Долгосрочные отношения с клиентами
Профит от сделки

4. Опыт подсказывает, что это

5. Одна история…
Внутренний портал
ТЗ, аналитик, менеджер, разработчики
Удовлетворение потребностей заказчика
Неожиданный поворот

6. Ретроспектива: что было плохо?
Непрофессионализм
Плохой контроль на проекте
Нереалистичное ТЗ
Вера в «доброго» заказчика
Исключительный случай

7. В среднем по больнице
70% - детальное ТЗ (> 5 листов)
60% - выходят за бюджет
40% - платят неустойку
70% - видят проблему и хотят ее решать

8. Сейчас мы делаем это так:
t
Хотелки
Ошибки

9. Объект управления - ТЗ
Задачи
Бюджет
Прогресс/Ошибки
Хотелки
Ошибки Тесты

10. Ретроспектива: как улучшить?
Учиться делать хорошее ТЗ
Нанимать профессионалов
Сменить парадигму…

11. Так есть же Скрам!
Делаем только то, что нужно
Фиксируем прибыль в конце спринта
Любой каприз за деньги клиента

12. За счет чего это работает?
Доверие с самого начала
Один источник требований
Частые коммуникации
> 60% не готовы менять парадигму…

13. Конус неопределенности
https://msdn.microsoft.com

14. Укротить неопределенность:
Уменьшить объем требований к сдаче
Сократить срок до сдачи
Делать качественные требования
Использовать вилку оценок

15. Качественное требование
Измеряемое
Ранжируемое
Однозначное
Тестируемое

16. Пример измеряемого требования
«Публикация товарной номенклатуры в каталоге интернет-
магазина.
Основной сценарий: создание/изменение/удаление продуктов в
каталоге (3 дн. – обязательно)
Расширенный сценарий: интеграция с 1С, импорт продуктов из
базы (2 нед. – желательно)»

17. Пример скрытого требования
«Для регистрации на сайте пользователю необходимо указать:
email, контактный телефон, ФИО»

18. Нетестируемые требования
«Для браузеров более ранних версий допустима некоторая потеря
качества отображения информации»
«Защита от несанкционированного доступа»
«Стиль с интуитивно понятным интерфейсом»

19. Выводы
Новый проект начинайте с конца
Готовьтесь к худшему сценарию
Сделайте проект, где ТЗ в фокусе внимания

20. Правильное требование выглядит так:
Указана важность
Есть оценка трудоемкости
Вариации записаны как доп.
требования
Видны задачи по
требованию и их статус
Тестируемо и записаны
шаги тестирования
Нет скрытых требований
Можно определить степень
готовности

21. Спасибо!
Евгений Савицкий
https://t.me/get_tz_done