Доклад Карины Дозорновой на конференции SPM Conf-5, 6 ноября 2015 г., Минск www.spmconf.ru

1. Web-разработка Бизнес-системы Тестирование Поддержка проектов
True Story: спасение одного ИТшного проекта
(хаос, подрядчики, внутренние команды)

2. Web-разработка Бизнес-системы Тестирование Поддержка проектов
Обо мне
Высшее экономическое образование, специальность «Прикладная информатика в экономике»,
Московский Авиационный Институт им. С.Орджоникидзе (МАИ), Москва (2003 – 2008 гг.).
Разработчик профессионально ориентированных компьютерных приложений, Высшая Компьютерная
Школа «Эксперт» (на базе факультета ВМиК МГУ им. Ломоносова и Сетевой Академии «ЛАНИТ»), Москва
(2005 – 2007 гг.).
Основные проекты (с 2008г.):
• Система Anti-Fraud Filter – разработка математической модели дополнительного уровня
безопасности платежей для контент-провайдера;
• Система eDetailing (CLM/CRM) для фармацевтических компаний – идеолог проекта;
• Портал непрерывного медицинского образования – идеолог и руководитель проекта;
• ДБО юридических лиц – руководитель портфеля проектов (ДИТ);
• Система учета данных о проведенных диагностических исследованиях – идеолог и руководитель
проекта;
• Информационно-аналитический портал для отслеживания состояния нефтяных скважин –
руководитель портфеля проектов (ИТ-подрядчик);
• Человек-Онлайн – руководитель проекта (ИТ).

3. Web-разработка Бизнес-системы Тестирование Поддержка проектов
Обо мне
С 2014г. являюсь генеральным директором Take IT.
Главной задачей Take IT является определение истинных целей проекта,
требований к ним со стороны различных департаментов наших клиентов,
а также своевременное внедрение необходимых вам сервисов и систем.
Достижение результатов проектов должно основываться на желании
сделать вклад в отношения, благодаря которым эти проекты реализуются.

4. План презентации

5. True Story: спасение одного ИТшного проекта
План презентации
Ситуация на входе
• Команды, взаимодействие команд, источники информации,
поставленные задачи
• Выявленные проблемы
Предположения
и акценты
• Какие предположения были сделаны
• Проблемные точки (ЖЦ проектов)
Первая
нормализация
• Цели, задачи, срок достижения результатов, проблемы
• Результаты по итогам 6 месяцев работы
Вторая
нормализация
• Цели, задачи, срок достижения результатов, проблемы
• Результаты по итогам 6 месяцев работы
• Особенности внутренних взаимодействий и их влияние
Итоговый план
стабилизации
• Итоговый план стабилизации
• План по дальнейшей модернизации
AAR
• After Action Review
• Выводы и рекомендации

6. Ситуация на входе

7. True Story: спасение одного ИТшного проекта
Команды
Задействовано 4 команды:
• внешняя (вне компании),
• внутренняя (внутри подразделения),
• внешне-внутренняя (по отношению к
подразделению, но внутри компании);
• бизнес (заказчик, другая дирекция)
Внутренняя
Внешне-
внутренняяВнешняя

8. True Story: спасение одного ИТшного проекта
Команды
Задействовано 4 команды:
• внешняя – выделено 3 человека, отсутствие
информации о привлеченных специалистах;
• внутренняя – выделен 1 человек, частичное
привлечение руководителей отделов и их
специалистов;
• внешне-внутренняя – постоянное участие 2
руководителей подразделений, привлечение под
конкретные задачи их специалистов;
• бизнес (заказчик, другая дирекция) – выделено 2
человека, отсутствие информации о точном
количестве сотрудников, привлеченных к
проектам.
От 2 до ???От 3 чел.
до ???
От 4 чел.
до ???

9. True Story: спасение одного ИТшного проекта
Обмен информацией
Основные тенденции:
• При выделенном руководителе проекта со
стороны ДИТ и Бизнеса отсутствовали единые
точки входа и выхода.
• В любой момент управление мог на себя взять
один из вышестоящих руководителей.
• Заинтересованные лица не уведомлялись о
происходящих изменениях.
• Каждая команда тянула «корону» на себя и
снимала с себя ответственность, когда это было
«удобно».
• Специалисты воспринимали работу как сизифов
труд.
Внутренняя
Внешне-
внутренняяВнешняя

10. True Story: спасение одного ИТшного проекта
Поставленные задачи
Руководство требовало:
• Формализация модели AS IS.
• Разработка детализированного плана проектов (на входе – 5, на выходе – 20).
• Соблюдение сроков и обеспечение 100% KPI (поквартально).
• Четкое понимание текущей ситуации в любой момент времени по всем основным задачам.
• Знание и понимание используемых технологий всеми заинтересованными лицами (исключение –
Бизнес, но в зависимости от задач).
• Увеличение количества поставляемых решений и повышение их качества.
• Закрытие релевантных «зависших» проектов.

11. True Story: спасение одного ИТшного проекта
Выявленные проблемы
После 2-х месяцев работы было определено (подтверждено):
• Отсутствие желания рассматривать глобальные проблемы. Главное – закрыть текущее. Работаем
по принципу «разберемся по ходу дела».
• Ужесточение политических нюансов. Главное – «это была наша идея».
• Уверенность в том, что текущая ситуация определена исключительно работой подрядчика.
• Отсутствие взаимопонимания между командами. Главное – отсутствие общих целей!
• Отсутствие единого источника информации, в т.ч. по уже внедренным сервисам.
• Высокая загруженность специалистов во всех командах.
• Отсутствие единого согласованного со всеми процесса поставки решений.

12. Предположения и акценты

13. True Story: спасение одного ИТшного проекта
«Руководство всегда право! Если руководство не право, значит, у тебя неверные мысли!»:
• «Мы работаем на износ. У нас если и бывают ошибки, то незначительные.»
• «У нас есть парочка «заброшенных» задач, но как-то было не до них. Сделаем потом, все равно о
них никто не помнит».
• «Нам нужна выделенная команда подрядчика. Мы должны знать всех, кто работает над нашими
проектами.»
• «Проблема кроется в том, что мы не понимаем, в каком объеме подрядчик работает.»
• «Очень плохое качество тестирования. Если будет выделенная команда подрядчика, то точно все
станет лучше.»
• «Нам нужно сотрудничать с Бизнесом. Сейчас они нами недовольны, потому что сроки постоянно
нарушаются.»
• и т.д.
Предположения руководства

14. True Story: спасение одного ИТшного проекта
Акценты
Последовательность работ:
• Ужесточение контракта и переход на выделенную проектную команду со стороны подрядчика.
• Определение этапов внедрения и согласование с Бизнесом необходимости этих внедрений.
• Необходимость делать хорошо и сразу (качество!).
• Повышенный контроль деятельности внешней, внутренней и внешне-внутренней проектных
команд со стороны руководства ДИТ (еженедельные совещания по всем проектам и релевантным
задачам).
• Внедрение сервисов в числе первых на рынке.
Единый выделенный руководитель проекта со стороны ДИТ, который
отвечает за результаты деятельности внешней, внутренней и внешне-
внутренней проектных команд.

15. True Story: спасение одного ИТшного проекта
Руководитель проекта
Последовательность действий:
• Повышения уровня доверия со стороны всех заинтересованных лиц.
• Определение проблем глазами специалистов.
• Изучение истории проектов (в основном методами «кофе» / «курилка»).
• Разработка журнала проектов с возможностью быстрой подготовки кратких отчетов (в т.ч. шаблон
совещаний, полный список всех заинтересованных лиц, матрица ответственности и т.д.).
• Создание единой информационной базы для всех заинтересованных лиц.
• Следование поставленным руководством задачам.
Главная задача – получить необходимый «кредит доверия».

16. Первая нормализация – акцент на подрядчиках

17. True Story: спасение одного ИТшного проекта
Предположения и акценты
●●●
Акцент на внешней команде.
●●●
Стабилизация работы внешней команды: план
работ, планирование ресурсов, база знаний
(технологии, процессы).
●●●
Самоуверенность в работе внутренней и внешне-
внутренней команды.
●●●
Точечное структурирование сквозных знаний и
данных.
ЖЦ ПРОЕКТА
Сбор требований и анализ
●●●
Подготовка плана работ
●●●
Реализация
●●●
Тестирование
●●●
Приемка и внедрение

18. True Story: спасение одного ИТшного проекта
Выбор направления
Основные выявленные ошибки:
• Повторная разработка модулей, которые ранее разрабатывались другими командами.
• Отсутствие понимания приоритетности задач.
• Ошибки в подготовке документации.
• Плохое качество документации для проведения тестирования.
• Отсутствие знаний по процессу проведения тестирования.
• «Передергивание» с одной задачи на другую.
• Сложность в изменении состава модулей в поставляемых решениях.
• Двойной контроль работ команды (внутри подрядчика и ДИТ).
Основной акцент – формирование единой базы знаний.

19. True Story: спасение одного ИТшного проекта
Нормализация внешней команды
ИНДИВИДУАЛЬНЫЙ
АНАЛИЗ
СОВМЕСТНЫЕ
ИССЛЕДОВАНИЯ
ЭКСПЕРТНЫЙ
СОВЕТ
Цель: повысить качество и сократить
сроки внедрения новых продуктов
●●●
Задача: оперативно сформировать
базу знаний
●●●
Срок: 1 месяц
● далее – ежемесячный анализ
эффективности
●●●
Проблема: объем документации
(более 10 000 стр.)

20. True Story: спасение одного ИТшного проекта
Итоги нормализации
●●●
Формирование первичной базы знаний: 2 мес.
●●●
Отдельная задача команды: поддержание базы
знаний в актуальном состоянии и постепенное
обновление.
●●●
Результат после 6 мес. (с даты официального
формирования команды):
● повышено качество
● стабилизирована работа на стадии
интеграционного тестирования
● сокращены сроки внедрения
ИТОГ ЧЕРЕЗ 4 МЕСЯЦА ПОСЛЕ
ВНЕДРЕНИЯ БАЗЫ ЗНАНИЙ
Люди
Технологии
Процессы

21. Вторая нормализация – выявление внутренних проблем

22. True Story: спасение одного ИТшного проекта
Предположения и акценты
●●●
Отставание в развитии команд по сравнению с
внешней (эффективность команд стабильно
падала).
●●●
Повышение напряжение внутри команд.
●●●
Проблемы на всех гранях
проектного треугольника.
ЖЦ ПРОЕКТА
(5 МЕС. ПОСЛЕ СТАРТА)
Сбор требований и анализ
●●●
Подготовка плана работ
●●●
Реализация
●●●
Тестирование
●●●
Приемка и внедрение

23. True Story: спасение одного ИТшного проекта
Выбор направления
Основные выявленные ошибки:
• Постоянные изменения приоритетов в связи с «псевдо-форс-мажорами».
• Увеличение загрузки специалистов в связи с увеличением объема поставляемых решений.
• Проблемы в приоритезации задач между внутренней, внешне-внутренней командами и
Бизнесом.
• Отсутствие качественной документации по сервисам и процессам.
• Отсутствие единого плана внедрений.
• Увеличение количества ЛПР – появление ЛПР со стороны вышестоящего руководства (правление
компании).
• Отсутствие формализованного процесса тестирования и сдачи-приемки решений.
Основной акцент – планирование.

24. True Story: спасение одного ИТшного проекта
Нормализация внутренних команд
ОЦЕНКА
СИТУАЦИИ
ИССЛЕДОВАНИЕ
РЕШЕНИЙ
ЭКСПЕРТНЫЙ
СОВЕТ
Цель: синхронизация действий
подразделений
●●●
Задача: формирование единого плана
работ и ограничений по внесению в
него изменений
●●●
Срок: 1 месяц
● еженедельный контроль
●●●
Проблема: внештатные ситуации,
изменение приоритетов у правления
компании, внутренние процессы
(например, долгое согласование).

25. True Story: спасение одного ИТшного проекта
Итоги нормализации
●●●
Формирование и утверждение плана работ (Sprint = 2
weeks): 1 мес.
●●●
Утвержден порядок изменения приоритетов по
проектным и текущим задачам.
●●●
Принято решение о выделении группы специалистов
(выделенная проектная команда).
●●●
Проведена модернизация внутренних бизнес-процессов.
●●●
Проведена интеграция баз знаний всех проектных
команд
ИТОГ ЧЕРЕЗ 1 МЕСЯЦ ПОСЛЕ
ПРИНЯТИЯ РЕШЕНИЯ ПО
МОДЕРНИЗАЦИИ
Люди
Технологии
Процессы

26. True Story: спасение одного ИТшного проекта
Особенности нормализации
Помимо повышения качества работ всех команд:
• утвержден экспертный совет со стороны ДИТ и Бизнеса с возможностью привлечения экспертов
внешней команды.
• увеличен «кредит доверия» между командами ДИТ и Бизнеса: совместное обсуждение и выбор
вариантов решений, информирование друг друга о возможных изменениях, «прозрачность»
планирования работ всех команд («из 4 лодок мы создали единый корабль»).
• знакомство с основными членами проектных команд, но с четким ограничением дальнейшего
взаимодействия.
• уменьшилось влияние политических аспектов.
Улучшился эмоциональный фон всех «моряков на корабле»!

27. Итоговый план стабилизации

28. True Story: спасение одного ИТшного проекта
Ситуация через 6 месяцев…
●●●
Нормализация проходит в соответствие с планом.
●●●
Зафиксированы большие затраты на стабилизацию, в т.ч.
формирование баз знаний (все проектные расходы
увеличены в 1,5-2 раза).
●●●
Определены планы по повышению качества
внедряемых сервисов.
●●●
Проведена модернизация бизнес-процессов.
●●●
Улучшился эмоциональный фон.
СОСТОЯНИЕ ЧЕРЕЗ 6 МЕС.
ПОСЛЕ СТАРТА
(УСРЕДНЕННЫЕ ПОКАЗАТЕЛИ)
Люди
Технологии
Процессы

29. True Story: спасение одного ИТшного проекта
Планы по развитию
●●●
Обогащение и синхронизация баз знаний всех команд.
●●●
Синхронизация действий всех команд.
●●●
Увеличение пропускной
способности всех проектных
команд.
●●●
Полная стабилизация ситуации по итогам 6 мес.
и устранение узких мест.
●●●
Поддержка эмоционального фона.
КОНЕЧНАЯ ЦЕЛЬ
Люди

30. True Story: спасение одного ИТшного проекта
План стабилизации
Старт
Самоуверенн
ость
Определение
псевдо-
ложных
акцентов
2мес.
Формировани
е внешней
базы знаний
Курс по
псевдо-
ложному
плану
4мес.
Стабилизация
одной из
проектных
групп
Выход на
эффективные
показатели
одной
проектной
группы
Фиксация
проблем в
других
областях
6мес.
Формировани
е единого
плана работ и
перечня
решений
Стабилизация
всех
проектных
команд
8мес.
Наращивание
показателей
Период
мониторинга.
Синхронизац
ия нового
подхода к
процессам,
технологиям и
людям
10мес.
Выход на
итоговую
цель «один
корабль, а не
4 лодки»
Выход на
эффективност
ь
Плановые проектные
затраты
Фактические
проектные затраты

31. After Action Review

32. True Story: спасение одного ИТшного проекта
На ошибках учатся!
Хаос нас обогащает?
• Самоуверенность и всезнание губит начинания
• Чтобы сделать правильное решение, нужно послушать и услышать мнение всех сторон
• Неправильная оценка собственных сил приводит к увеличению сроков и снижению качества
сервисов
• В любой ситуации можно найти крайнего, но не у каждого найдется мужественность признать
свою ошибку
• Любая проектная деятельность должна начинаться со всесторонней оценки текущей ситуации
• В ходе реализации проекта нельзя забывать о накоплении знаний («армию нужно формировать
перед сражением, а не во время него»)
• Повторное использование знаний и удержание их сокращает себестоимость проекта

33. True Story: спасение одного ИТшного проекта
Мы команда!
• Важно не только слушать, но и слышать. Порой за словом «все нормально» может
скрываться проблема.
Слышать
• Иногда один член команды может привнести в нее полное разрушение.
• «Доверие» – это не самый худший инструмент работы с людьми.
Чувствовать
• Мы должны понимать, что происходит вокруг.
• Мы должны видеть состояние и настроение наших коллег и тем более подчиненных.
Видеть
Закон Муира: стоит потянуть за одно звено цепи, как сразу видно, что
оно связано со всеми остальными
• Когда одним нужна защита, другим нужен хороший кнут.
• Нужно учиться улавливать «веяния» со всех сторон.Предсказывать

34. Web-разработка Бизнес-системы Тестирование Поддержка проектов
Узнайте больше!
kd@take-it.systems 8 (926) 248-04-02
8 (495) 772-92-62
www.take-it.systems
www.dozornova.ru
В о п р о с ы ?