Successfully reported this slideshow.

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

2

Share

Loading in …3
×
1 of 34
1 of 34

More Related Content

Viewers also liked

More from SQALab

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

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 В о п р о с ы ?

×