1. Развитие IT организации
Асхат Уразбаев
ScumTrek
twitter.com/zibsun

2. Асхат Уразбаев (@zibsun)
• ScrumTrek
• Agile Coach
• Управляющий партнер
• В прошлом
• Программист, менеджер
проектов, методолог

3. Чем отличаются ИТ-организации?

4. Conant-Ashby Theorem:
Every good regulator of a
system must have a model of
that system

5. У каждого менеджера своя
собственная модель
реальности

6. Модели определяют правила
принятия решений
Совокупность похожих
моделей определяют культуру
организации

7. Кто в лес, кто по дрова
• Вы начальник отдела
• В вашем отделе 3 тимлида и 10
разработчиков
• Проблемы:
• Изобретение велосипедов
• Неэффективный дизайн
• Не единообразный подход
• ЧТО ДЕЛАТЬ?

8. Развитие ИТ организации –
условное (но типичное)

9. Цель разработки
• Поставка решения (срок, объем)
• Удовлетворенность ЗЛ
• Приемлемое качество

10. Хаотическая разработка
• Новый IT отдел
• Начало времен

11. Базовая модель
• Работа занимает все отведенное ей
время
• Поэтому - чем сильнее давишь, тем
быстрее сделают
• Все проблемы от того, что люди
безответственны
• Должна быть ответственность за
результат

12. Кейс «Кто в лес, кто по
дрова»
Что ответит менеджер такой
культуры?

13. Разработчик
• Разбирается в бизнес
домене
• Общается с
пользователями
• «Свой» программист для
заказчика

14. Тестируют пользователи
«Качество определяется
не наличием багов, а
умением программистов
их обезвреживать»

15. Высокая производительность
• Небольшие системы
• Минимум интеграции
• Разработчики не взаимодействуют друг с
другом
• Высокая гибкость
• Достаточная производительность

16. Задачи Баги
Проблемы Еще задачи
пользователей
Вопросы И опять
бизнеса задачи!

17. Кризис
Сроки срываются
всегда
Много багов
Поддерживать
дорого

18. Что делать?

19. Менеджер проекта
Будем составлять
требования
И подписывать их у
заказчика
И тогда он будет
отвечать за свои
слова!

20. Это война!
Долго делают!
Непродуманные
требования!
Срывают сроки!
Новые задачи!
Низкое
качество!
Не знают чего
Постоянные хотят!
баги!
Сроки с потолка!

21. Война бизнеса и разработки
Победа
бизнеса
Победа
разработки

22. Победа бизнеса
Почему не
Приоритеты готово?
поменялись
Новые
требования
Программиста
забрали на Чтобы завтра
другой проект было!
Урежем
тестирование

23. Некоторое время спустя
Почему баги?
А-а-а-а!

24. Война бизнеса и разработки
Победа
бизнеса
Победа
разработки

25. Разработка наносит ответный удар
Согласование
требований
Комитет по
управлению
изменениями Приемка у
заказчика!!!
Фаза разработки
архитектуры
Хе-хе. По
Фаза тестовым
тестирования сценариям!

26. Война: окапываемся!
Требования Ревью и
некачественны согласования в
е рабочих группах
Недовольство обязательны
пользователей
Фаза приемки у
группы
эксплуатации
Правите на
production Только release
engineer имеет
право
выкладывать
Больше бюрократии –
дольше разработка

27. Война коррупции с бюрократией
Планирование
новых работ JFDI!*
только в
следующем
квартале...
* JFDI – Just Fu&*ing Do It!

28. Функциональная модель
• Функциональную компетенцию надо
растить
• Компетенция передается через
коммуникацию

29. Кейс «Кто в лес кто по
дрова»
Что ответит менеджер такой
культуры?

30. Практические выводы
• Обучение разработчиков
• Разработчики должны сидеть вместе
• Тестировщики должны сидеть вместе
• У каждой функциональной группы свой
менеджер

31. Матрица
PMO
Аналитический
отдел
Отдел
разработки
Отдел
тестирования

32. Кризис слабой матрицы

33. Стабильная
кроссфункциональная команда
с 1 менеджером на 1 проекте
творит чудеса

34. Командная модель
• Команда может быть ответственной!

35. Гибкая модель
• Инкрементальность
• Быстрая качественная поставка
• Конечный пользователь важен

36. Изменение целей
Поставка решения Эффективная поставка
(срок, объем)
Удовлетворенность ЗЛ Удовольствие
пользователей
Приемлемое качество Классная команда

37. Асхат Уразбаев
• askhat@scrumtrek.ru
• Twitter: zibsun
• Skype: askhatu
• ЖЖ: zibsun.livejournal.com