"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК. В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.

2. ТОП 10 не могу
или что нужно сделать, чтобы жить по Agile

3. Входные данные (кейс “ИС Охотуправление.РФ”)
1. Около 15 человек задействовано в разработке ПО
2. Приверженность к системному подходу
3. Государственный Заказчик
4. Начало реализации, лето 15 года
5. Типовой проект, тиражируемый на регионы
6. Наличие компетенций по PM, QA
И вроде бы все есть, для успешного старта, но...

4. Что-то пошло не так

5. “Я, видимо, читал не ту версию ТЗ”
Крупный блок работ не был оценен верно
То что хотел заказчик, не соответствовало задаче
программистам
Размытые формулировки в ТЗ тянули за собой большой
объем работ

6. “А это Андрей в курсе, он с Заказчиком говорил”
Информационный вакуум
Знание сосредоточено в одних руках
Синдром “лучше меня никто не сделает”
Сложно узнать текущий статус

7. “Мы решили переписать ядро на Java”
Кто несет ответственность за последствия?
Какова тяжесть последствий и ценность приобретений?
Категорирование решений и их согласование

8. “Было много задач, не успели протестировать”
НИКОГДА этого не делайте
Сорванные приемки и “глупые” баги
Резкое падение имиджа в лице Заказчика

9. “В задаче этого не сказано!”
Непонимание требуемого результата
Тройные трудозатраты на решение вопроса
Ответственность за постановку задачи

10. “Она была так настойчива...”
Неверный выбор приоритетов проекта/проектов
Успех проекта зависит от особенности Заказчика
Политический проект может провалится

11. “Проще сделать самому, чем учить...”
Замкнутый круг!
Отсутствие кадрового потенциала
Неготовность к резкому увеличению команды

12. “Завтра приемка? А Иван уже уехал домой...”
Люди не осознают важность проекта
Отсутствие командного духа
Срыв сроков

13. “А где можно об этом почитать?”
Отсутствует процесс передачи знаний
Нет “базы знаний” в целом и по проекту в частности
Высокий порог вхождения в проект
Сложный процесс ввода нового сотрудника

14. “Не хватило времени...”
Неверное планирование работ
Нет времени на анализ предметной области
Отсутствие саморазвития
Моральный упадок

16. В чем проблема? Пути решения:
Описание бизнес-процессов
Единое информационное пространство
Автоматизация производства
Мотивация на результат
Обучение/подготовка кадров

17. Описание БП
БП - крупными мазками
Инвентаризация операций сотрудников
Фиксация типовых форм документов
Определение метрик качества шага процесса
Без воды, только четкие инструкции

18. Единое информационное пространство
Периодические сборы команды
Общие информационные ресурсы
Мотивация на передачу знаний
Требования к документированию

19. Автоматизация производства
Документирование
Тестирование
Обновление и доставка до клиента

20. Мотивация на результат
Бюджетирование проекта
Прозрачная мотивация
Зависимость от успеха компании в целом

21. Кадровый потенциал
Создание проектной песочницы
Практикант/Стажер/Сотрудник
Жесткие входные требования
Программа адаптации сотрудника
Жесткий входной контроль и
создание конкуренции