Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

True Story: спасение одного ИТшного проекта

410 views

Published on

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

Published in: Education
  • Be the first to comment

True Story: спасение одного ИТшного проекта

  1. 1. Web-разработка Бизнес-системы Тестирование Поддержка проектов True Story: спасение одного ИТшного проекта (хаос, подрядчики, внутренние команды)
  2. 2. Web-разработка Бизнес-системы Тестирование Поддержка проектов Обо мне Высшее экономическое образование, специальность «Прикладная информатика в экономике», Московский Авиационный Институт им. С.Орджоникидзе (МАИ), Москва (2003 – 2008 гг.). Разработчик профессионально ориентированных компьютерных приложений, Высшая Компьютерная Школа «Эксперт» (на базе факультета ВМиК МГУ им. Ломоносова и Сетевой Академии «ЛАНИТ»), Москва (2005 – 2007 гг.). Основные проекты (с 2008г.): • Система Anti-Fraud Filter – разработка математической модели дополнительного уровня безопасности платежей для контент-провайдера; • Система eDetailing (CLM/CRM) для фармацевтических компаний – идеолог проекта; • Портал непрерывного медицинского образования – идеолог и руководитель проекта; • ДБО юридических лиц – руководитель портфеля проектов (ДИТ); • Система учета данных о проведенных диагностических исследованиях – идеолог и руководитель проекта; • Информационно-аналитический портал для отслеживания состояния нефтяных скважин – руководитель портфеля проектов (ИТ-подрядчик); • Человек-Онлайн – руководитель проекта (ИТ).
  3. 3. Web-разработка Бизнес-системы Тестирование Поддержка проектов Обо мне С 2014г. являюсь генеральным директором Take IT. Главной задачей Take IT является определение истинных целей проекта, требований к ним со стороны различных департаментов наших клиентов, а также своевременное внедрение необходимых вам сервисов и систем. Достижение результатов проектов должно основываться на желании сделать вклад в отношения, благодаря которым эти проекты реализуются.
  4. 4. План презентации
  5. 5. True Story: спасение одного ИТшного проекта План презентации Ситуация на входе • Команды, взаимодействие команд, источники информации, поставленные задачи • Выявленные проблемы Предположения и акценты • Какие предположения были сделаны • Проблемные точки (ЖЦ проектов) Первая нормализация • Цели, задачи, срок достижения результатов, проблемы • Результаты по итогам 6 месяцев работы Вторая нормализация • Цели, задачи, срок достижения результатов, проблемы • Результаты по итогам 6 месяцев работы • Особенности внутренних взаимодействий и их влияние Итоговый план стабилизации • Итоговый план стабилизации • План по дальнейшей модернизации AAR • After Action Review • Выводы и рекомендации
  6. 6. Ситуация на входе
  7. 7. True Story: спасение одного ИТшного проекта Команды Задействовано 4 команды: • внешняя (вне компании), • внутренняя (внутри подразделения), • внешне-внутренняя (по отношению к подразделению, но внутри компании); • бизнес (заказчик, другая дирекция) Внутренняя Внешне- внутренняяВнешняя
  8. 8. True Story: спасение одного ИТшного проекта Команды Задействовано 4 команды: • внешняя – выделено 3 человека, отсутствие информации о привлеченных специалистах; • внутренняя – выделен 1 человек, частичное привлечение руководителей отделов и их специалистов; • внешне-внутренняя – постоянное участие 2 руководителей подразделений, привлечение под конкретные задачи их специалистов; • бизнес (заказчик, другая дирекция) – выделено 2 человека, отсутствие информации о точном количестве сотрудников, привлеченных к проектам. От 2 до ???От 3 чел. до ??? От 4 чел. до ???
  9. 9. True Story: спасение одного ИТшного проекта Обмен информацией Основные тенденции: • При выделенном руководителе проекта со стороны ДИТ и Бизнеса отсутствовали единые точки входа и выхода. • В любой момент управление мог на себя взять один из вышестоящих руководителей. • Заинтересованные лица не уведомлялись о происходящих изменениях. • Каждая команда тянула «корону» на себя и снимала с себя ответственность, когда это было «удобно». • Специалисты воспринимали работу как сизифов труд. Внутренняя Внешне- внутренняяВнешняя
  10. 10. True Story: спасение одного ИТшного проекта Поставленные задачи Руководство требовало: • Формализация модели AS IS. • Разработка детализированного плана проектов (на входе – 5, на выходе – 20). • Соблюдение сроков и обеспечение 100% KPI (поквартально). • Четкое понимание текущей ситуации в любой момент времени по всем основным задачам. • Знание и понимание используемых технологий всеми заинтересованными лицами (исключение – Бизнес, но в зависимости от задач). • Увеличение количества поставляемых решений и повышение их качества. • Закрытие релевантных «зависших» проектов.
  11. 11. True Story: спасение одного ИТшного проекта Выявленные проблемы После 2-х месяцев работы было определено (подтверждено): • Отсутствие желания рассматривать глобальные проблемы. Главное – закрыть текущее. Работаем по принципу «разберемся по ходу дела». • Ужесточение политических нюансов. Главное – «это была наша идея». • Уверенность в том, что текущая ситуация определена исключительно работой подрядчика. • Отсутствие взаимопонимания между командами. Главное – отсутствие общих целей! • Отсутствие единого источника информации, в т.ч. по уже внедренным сервисам. • Высокая загруженность специалистов во всех командах. • Отсутствие единого согласованного со всеми процесса поставки решений.
  12. 12. Предположения и акценты
  13. 13. True Story: спасение одного ИТшного проекта «Руководство всегда право! Если руководство не право, значит, у тебя неверные мысли!»: • «Мы работаем на износ. У нас если и бывают ошибки, то незначительные.» • «У нас есть парочка «заброшенных» задач, но как-то было не до них. Сделаем потом, все равно о них никто не помнит». • «Нам нужна выделенная команда подрядчика. Мы должны знать всех, кто работает над нашими проектами.» • «Проблема кроется в том, что мы не понимаем, в каком объеме подрядчик работает.» • «Очень плохое качество тестирования. Если будет выделенная команда подрядчика, то точно все станет лучше.» • «Нам нужно сотрудничать с Бизнесом. Сейчас они нами недовольны, потому что сроки постоянно нарушаются.» • и т.д. Предположения руководства
  14. 14. True Story: спасение одного ИТшного проекта Акценты Последовательность работ: • Ужесточение контракта и переход на выделенную проектную команду со стороны подрядчика. • Определение этапов внедрения и согласование с Бизнесом необходимости этих внедрений. • Необходимость делать хорошо и сразу (качество!). • Повышенный контроль деятельности внешней, внутренней и внешне-внутренней проектных команд со стороны руководства ДИТ (еженедельные совещания по всем проектам и релевантным задачам). • Внедрение сервисов в числе первых на рынке. Единый выделенный руководитель проекта со стороны ДИТ, который отвечает за результаты деятельности внешней, внутренней и внешне- внутренней проектных команд.
  15. 15. True Story: спасение одного ИТшного проекта Руководитель проекта Последовательность действий: • Повышения уровня доверия со стороны всех заинтересованных лиц. • Определение проблем глазами специалистов. • Изучение истории проектов (в основном методами «кофе» / «курилка»). • Разработка журнала проектов с возможностью быстрой подготовки кратких отчетов (в т.ч. шаблон совещаний, полный список всех заинтересованных лиц, матрица ответственности и т.д.). • Создание единой информационной базы для всех заинтересованных лиц. • Следование поставленным руководством задачам. Главная задача – получить необходимый «кредит доверия».
  16. 16. Первая нормализация – акцент на подрядчиках
  17. 17. True Story: спасение одного ИТшного проекта Предположения и акценты ●●● Акцент на внешней команде. ●●● Стабилизация работы внешней команды: план работ, планирование ресурсов, база знаний (технологии, процессы). ●●● Самоуверенность в работе внутренней и внешне- внутренней команды. ●●● Точечное структурирование сквозных знаний и данных. ЖЦ ПРОЕКТА Сбор требований и анализ ●●● Подготовка плана работ ●●● Реализация ●●● Тестирование ●●● Приемка и внедрение
  18. 18. True Story: спасение одного ИТшного проекта Выбор направления Основные выявленные ошибки: • Повторная разработка модулей, которые ранее разрабатывались другими командами. • Отсутствие понимания приоритетности задач. • Ошибки в подготовке документации. • Плохое качество документации для проведения тестирования. • Отсутствие знаний по процессу проведения тестирования. • «Передергивание» с одной задачи на другую. • Сложность в изменении состава модулей в поставляемых решениях. • Двойной контроль работ команды (внутри подрядчика и ДИТ). Основной акцент – формирование единой базы знаний.
  19. 19. True Story: спасение одного ИТшного проекта Нормализация внешней команды ИНДИВИДУАЛЬНЫЙ АНАЛИЗ СОВМЕСТНЫЕ ИССЛЕДОВАНИЯ ЭКСПЕРТНЫЙ СОВЕТ Цель: повысить качество и сократить сроки внедрения новых продуктов ●●● Задача: оперативно сформировать базу знаний ●●● Срок: 1 месяц ● далее – ежемесячный анализ эффективности ●●● Проблема: объем документации (более 10 000 стр.)
  20. 20. True Story: спасение одного ИТшного проекта Итоги нормализации ●●● Формирование первичной базы знаний: 2 мес. ●●● Отдельная задача команды: поддержание базы знаний в актуальном состоянии и постепенное обновление. ●●● Результат после 6 мес. (с даты официального формирования команды): ● повышено качество ● стабилизирована работа на стадии интеграционного тестирования ● сокращены сроки внедрения ИТОГ ЧЕРЕЗ 4 МЕСЯЦА ПОСЛЕ ВНЕДРЕНИЯ БАЗЫ ЗНАНИЙ Люди Технологии Процессы
  21. 21. Вторая нормализация – выявление внутренних проблем
  22. 22. True Story: спасение одного ИТшного проекта Предположения и акценты ●●● Отставание в развитии команд по сравнению с внешней (эффективность команд стабильно падала). ●●● Повышение напряжение внутри команд. ●●● Проблемы на всех гранях проектного треугольника. ЖЦ ПРОЕКТА (5 МЕС. ПОСЛЕ СТАРТА) Сбор требований и анализ ●●● Подготовка плана работ ●●● Реализация ●●● Тестирование ●●● Приемка и внедрение
  23. 23. True Story: спасение одного ИТшного проекта Выбор направления Основные выявленные ошибки: • Постоянные изменения приоритетов в связи с «псевдо-форс-мажорами». • Увеличение загрузки специалистов в связи с увеличением объема поставляемых решений. • Проблемы в приоритезации задач между внутренней, внешне-внутренней командами и Бизнесом. • Отсутствие качественной документации по сервисам и процессам. • Отсутствие единого плана внедрений. • Увеличение количества ЛПР – появление ЛПР со стороны вышестоящего руководства (правление компании). • Отсутствие формализованного процесса тестирования и сдачи-приемки решений. Основной акцент – планирование.
  24. 24. True Story: спасение одного ИТшного проекта Нормализация внутренних команд ОЦЕНКА СИТУАЦИИ ИССЛЕДОВАНИЕ РЕШЕНИЙ ЭКСПЕРТНЫЙ СОВЕТ Цель: синхронизация действий подразделений ●●● Задача: формирование единого плана работ и ограничений по внесению в него изменений ●●● Срок: 1 месяц ● еженедельный контроль ●●● Проблема: внештатные ситуации, изменение приоритетов у правления компании, внутренние процессы (например, долгое согласование).
  25. 25. True Story: спасение одного ИТшного проекта Итоги нормализации ●●● Формирование и утверждение плана работ (Sprint = 2 weeks): 1 мес. ●●● Утвержден порядок изменения приоритетов по проектным и текущим задачам. ●●● Принято решение о выделении группы специалистов (выделенная проектная команда). ●●● Проведена модернизация внутренних бизнес-процессов. ●●● Проведена интеграция баз знаний всех проектных команд ИТОГ ЧЕРЕЗ 1 МЕСЯЦ ПОСЛЕ ПРИНЯТИЯ РЕШЕНИЯ ПО МОДЕРНИЗАЦИИ Люди Технологии Процессы
  26. 26. True Story: спасение одного ИТшного проекта Особенности нормализации Помимо повышения качества работ всех команд: • утвержден экспертный совет со стороны ДИТ и Бизнеса с возможностью привлечения экспертов внешней команды. • увеличен «кредит доверия» между командами ДИТ и Бизнеса: совместное обсуждение и выбор вариантов решений, информирование друг друга о возможных изменениях, «прозрачность» планирования работ всех команд («из 4 лодок мы создали единый корабль»). • знакомство с основными членами проектных команд, но с четким ограничением дальнейшего взаимодействия. • уменьшилось влияние политических аспектов. Улучшился эмоциональный фон всех «моряков на корабле»!
  27. 27. Итоговый план стабилизации
  28. 28. True Story: спасение одного ИТшного проекта Ситуация через 6 месяцев… ●●● Нормализация проходит в соответствие с планом. ●●● Зафиксированы большие затраты на стабилизацию, в т.ч. формирование баз знаний (все проектные расходы увеличены в 1,5-2 раза). ●●● Определены планы по повышению качества внедряемых сервисов. ●●● Проведена модернизация бизнес-процессов. ●●● Улучшился эмоциональный фон. СОСТОЯНИЕ ЧЕРЕЗ 6 МЕС. ПОСЛЕ СТАРТА (УСРЕДНЕННЫЕ ПОКАЗАТЕЛИ) Люди Технологии Процессы
  29. 29. True Story: спасение одного ИТшного проекта Планы по развитию ●●● Обогащение и синхронизация баз знаний всех команд. ●●● Синхронизация действий всех команд. ●●● Увеличение пропускной способности всех проектных команд. ●●● Полная стабилизация ситуации по итогам 6 мес. и устранение узких мест. ●●● Поддержка эмоционального фона. КОНЕЧНАЯ ЦЕЛЬ Люди
  30. 30. True Story: спасение одного ИТшного проекта План стабилизации Старт Самоуверенн ость Определение псевдо- ложных акцентов 2мес. Формировани е внешней базы знаний Курс по псевдо- ложному плану 4мес. Стабилизация одной из проектных групп Выход на эффективные показатели одной проектной группы Фиксация проблем в других областях 6мес. Формировани е единого плана работ и перечня решений Стабилизация всех проектных команд 8мес. Наращивание показателей Период мониторинга. Синхронизац ия нового подхода к процессам, технологиям и людям 10мес. Выход на итоговую цель «один корабль, а не 4 лодки» Выход на эффективност ь Плановые проектные затраты Фактические проектные затраты
  31. 31. After Action Review
  32. 32. True Story: спасение одного ИТшного проекта На ошибках учатся! Хаос нас обогащает? • Самоуверенность и всезнание губит начинания • Чтобы сделать правильное решение, нужно послушать и услышать мнение всех сторон • Неправильная оценка собственных сил приводит к увеличению сроков и снижению качества сервисов • В любой ситуации можно найти крайнего, но не у каждого найдется мужественность признать свою ошибку • Любая проектная деятельность должна начинаться со всесторонней оценки текущей ситуации • В ходе реализации проекта нельзя забывать о накоплении знаний («армию нужно формировать перед сражением, а не во время него») • Повторное использование знаний и удержание их сокращает себестоимость проекта
  33. 33. True Story: спасение одного ИТшного проекта Мы команда! • Важно не только слушать, но и слышать. Порой за словом «все нормально» может скрываться проблема. Слышать • Иногда один член команды может привнести в нее полное разрушение. • «Доверие» – это не самый худший инструмент работы с людьми. Чувствовать • Мы должны понимать, что происходит вокруг. • Мы должны видеть состояние и настроение наших коллег и тем более подчиненных. Видеть Закон Муира: стоит потянуть за одно звено цепи, как сразу видно, что оно связано со всеми остальными • Когда одним нужна защита, другим нужен хороший кнут. • Нужно учиться улавливать «веяния» со всех сторон.Предсказывать
  34. 34. Web-разработка Бизнес-системы Тестирование Поддержка проектов Узнайте больше! kd@take-it.systems 8 (926) 248-04-02 8 (495) 772-92-62 www.take-it.systems www.dozornova.ru В о п р о с ы ?

×