Иллюзия контроля: шесть проблем в управлении крупными IT-проектами

Иллюзия контроля: шесть проблем в управлении крупными IT-проектами

Александр Козаржевский Начальник проекта, Москва

Большие внедренческие работы в IT требуют точного управления и тщательного планирования. Александр Козаржевский – о стереотипах и рисках, которых принципиально важно избежать.

Промахи на маленьких IT-проектах не так заметны. Многие вопросы решаются механическим нажимом и авралами. Участников мало, все возможно обсудить напрямую. Выходы за бюджет либо график не критичны.

В большинстве случаев, ничего ужасного не произойдёт, в случае если притормозить и возвратиться позже, в то время, когда покажутся ресурсы. Начиная средний и особенно большой проект, лучше не сохранять надежду на то, что все «как-нибудь» решится.

Ответственность значительно выше, а гибкость в управлении обстановкой ниже. На первый замысел выходит управляемость проекта – настоящая, а не декларируемая. В это же время, с ней далеко не всегда все идеально.

Давайте разглядим пара примеров того, из-за чего появляются неприятности с контролем IT-проектов, и как с ними бороться.

1. Из-за чего нельзя полагаться на статусы и цифры

Для начала пара примеров главных параметров IT-проекта:

Иллюзия контроля

Настоящий контроль

Выполненный срок завершения разработки, срок формализации требований

Выполненный срок ввода в промышленную эксплуатацию

Количество израсходованных часов

Неспециализированная цена работ, зафиксированных в соглашении

Приемка по ТЗ (техническому заданию)

Приемка по контрольным примерам из ФТ (функциональных требований)

Настоящий статус параметра, это тот, что возможно проверить: сдано пользователю (подписан протокол тестовых опробований), открыто (акт приема/передачи). Но на этапе доработок также нужно осуществлять контроль процесс. Как?

Статус от поставщика ответа – это иллюзия контроля.

Я знаю три пути контроля текущего положения дел на этапе разработки проекта: экспертная оценка, короткие задачи и «расход» ресурсов (но, это совсем второй принцип внедрения). Первый лучше второго, но второй дешевле. Третий, с позиций действительности происходящего лучше первых двух, но в конечном счете затратнее, из-за большей вовлеченности в приемку (а, следовательно, и тестирование) конечного пользователя.

И он менее контролируемый с позиций конечного результата, по причине того, что не разрешает строить долговременные замыслы.

Начальники проекта (РП) с обеих сторон с собственных отчетах часто маскируют действительность. И это кроме этого затуманивает настоящее положение дел на различных стадиях.

  • В то время, когда ведется подготовка документации, тестирование и разработка совокупности, не имеет значение, сколько процентов указано в отчетах. Эти цифры смогут быть забраны с потолка, их нереально проверить изолированно и основное, они не имеют независимой сокровище.
  • В то время, когда ТЗ сдано и подписано клиентом, появляется риск, что пользователь, подтверждая выполнение части работы, не примет всю работу полностью. Тогда в дельнейшем переделывать придется и первую (якобы сданную) часть также.

Все это, возможно сообщить, лежит на поверхности. Но имеется последовательность менее очевидных факторов, каковые значительны с позиций контроля работ в IT.

2. Дисбаланс в выборе IT-ответов

Любой IT-проект нужно соотносить с масштабом предприятия, задавая себе следующие вопросы:

  • Какие конкретно направления деятельности проект затрагивает?
  • От каких направлений бизнеса зависят автоматизируемые участки?
  • Как рамки проекта покрывают структуру департаментов, филиальную сеть?

Наряду с этим принципиально важно оценить необходимость автоматизации с применением внедряемого инструмента и узнать, имеется ли такая потребность у остальных подразделений.

Управление довольно часто склонно переоценивать зрелость собственных компаний – и зря, по причине того, что за отличие между реальностью и ожиданиями нужно будет заплатить живыми деньгами. Для успешной реализации масштабного IT-проекта прежде всего нужны:

  • Зрелые бизнес-процессы (регламентированность деятельности подразделений, их сотрудничества, формализация ответственности).
  • Наличие IT-стратегии.
  • SLA с бизнесом (Service Level Agreement, Соглашение об уровне обслуживания).
  • Соответствие уровня внедряемого ПО и применяемого ПО (производитель, часть рынка, функциональные возможности, цена владения).
  • Соответствие уровня выбранного вендора и уровня компании (бюджет вашего проекта не должен равняться годовому обороту вендора).

Маркеры того, что проект шире, чем думается:

  • Полностью не покрыта функциональная область. К примеру, не проработаны связи отчётности и операционной деятельности (управленческой, бухгалтерской).
  • В соглашении на внедрение не отражена цена интеграции в существующую IT-инфраструктуру.
  • Временные рамки первых трех частей (формализация требований/доработки/ввод в эксплуатацию) заданы с значительным отклонением от пропорции 35%/45%/20%. Это условный критерий, но в случае если проект запланирован на шесть-восемь месяцев, а обследование заняло всего 14 дней – вспомните, что сатана кроется в подробностях.

Кроме этого полезно не забывать о том, что технологически фактически любой IT-проект состоит не из трех, а из четырех главных этапов:

  • Обследование/Формализация требований.
  • Внедрение/Разработка.
  • Ввод в эксплуатацию (развертывание).
  • Сервис (предстоящее сопровождение + доработки).

Договаривайтесь «на берегу» по всем четырем этапам сходу.

3. Что в действительности необходимо РП, в то время, когда он требует полномочий

Ниже перечислены обычные вопросы, каковые в большинстве случаев задают начальнику проекта, в то время, когда он заявляет, что ему не достаточно полномочий. Вопросы эти не верны по собственной сути:

Неправильные вопросы

Верные ответы

Какие конкретно полномочия необходимы РП, дабы он по большому счету имел возможность делать собственную работу?

Дело не в полномочиях. Ни при каких полномочиях РП один ничего не сделает.

Что необходимо, дабы РП стал супер-производительным?

РП не исполнитель. Он не может быть производительным, он должен быть результативным.

Чего РП не сможет сделать, даже в том случае, если ему дать полномочия генерального директора?

Один ничего не сможет сделать.

Как усилить команду в целом, действуя через РП?

Никак. Тут дело в самой команде. Сущность в том, что РП требует полномочия, в то время, когда ему не достаточно административного ресурса. И в случае если ему дать полномочия, будет лишь хуже.

Из-за чего я так считаю? Команда проекта складывается из топ-менеджеров. Все остальные (консультанты, программисты, бухгалтера, менеджеры по закупкам, кладовщики) – это лишь руки.

Дабы РП проекта (к примеру, по внедрению совокупностей класса ERP) был действенным, ему необходимо видеть потребности топов, по причине того, что изменение бизнес-процессов лишь в их власти. И как раз исходя из этого, РП необходимы не полномочия, а вовлеченность тех, у кого эти полномочия имеется.

Пример верно организованного проекта: регулярный проектный комитет, наличие ТЭО (технико-экономического обоснования), зафиксированные исчисляемые регулярное обновление и бизнес цели статусов по ним.

4. IT не драйвер бизнеса, а следствие развития бизнеса

Сущность неприятности содержится в нарушении причинно-следственных связей. Логичный, тождественный порядок: сперва у бизнеса появляется некая потребность, ответственная для повышения прибыльности, а позже рассматриваются предложения по автоматизации для обеспечения данной новой потребности. Пожалуй, единственное исключение – увеличение эффективности уже существующих процессов за счет применения более идеальных инструментов.

В обратном порядке это, в большинстве случаев, не работает. По причине того, что наилучший IT-инструмент в отрыве от настоящего бизнеса ничего не усиливает. Без проблематики, сформулированной бизнесом, ресурсы IT смогут и вероятнее будут направлены не на проблемные участки, а в том направлении где их применять несложнее либо увлекательнее, но не обязательно – в том направлении, где самый выгодно.

Кстати, эти же мысли дают ключ к ответу на вопрос что лучше – развивать уже имеющееся ПО (ПО) либо разрабатывать «с нуля под ключ»?

В случае если нет ограничений по применению существующего ПО (в случае если имеется, то вопрос закрыт), то смотрите затраты: суммы и сроки. Лишь смотрите верно. Новое ПО, это и обучение сотрудников, и перестройка бизнес-процессов, применяющих внедряемое ПО.

Другими словами необходимо сравнивать цена доработок уже применяемого ПО (+ цена его сопровождения) со ценой внедрения нового ПО (+ цена переоборудования рабочих мест + цена обучения персонала + цена сопровождения новой совокупности).

Само собой разумеется, имеется еще таковой фактор, как возможность. Новые информационные разработки дают конкурентные преимущества: новые каналы сбыта (к примеру, электронная торговля), более своевременный, а обычно и автоматизированный контроль бизнес-активности и т.п.

5. Чем ТЗ отличается от постановки задачи

Бизнес не мыслит в категориях IT. Прием товара на склад – не то же самое, что и оформление накладной в совокупности учета. Бизнес-объекты это проводки по квитанциям, накладные, индексы, а вовсе не таблицы, формы, отчеты.

Примеры KPI в IT:

  • Количество транзакций.
  • Перечень форм ввода.
  • Количество строчков в закупке.

Пример KPI в бизнесе:

  • Области автоматизации (бухгалтерский учет, управленческий учет, склад, закупки).
  • Перечень бизнес процессов.
  • Скорость обработки данных (к примеру, регистрация прихода не более 5 мин.).
  • Время репликации данных по всем совокупностям (отделениям) компании.

Исходя из этого:

  • Технические «айтишные» ТЗ не годятся для формализации задач бизнеса. Они оперируют вторыми категориями.
  • На этапе постановки задачи со стороны клиента должны быть лишь главные пользователи.
  • Сотрудники IT-департамента (консультант, архитектор) должны выступать лишь аудиторами процесса внедрения для понижения риска неточностей со стороны поставщика ответа.

Функциональные требования (ФТ) не окажут помощь без:

  • контрольных примеров, они же use-cases,
  • описания бизнес-процессов (с формализацией важного за каждую операцию, входных/выходных параметров).

6. В то время, когда Scrum ведет к хаосу вместо порядка

В этот самый момент мы медлено переходим к методике внедрения. на данный момент показался последовательность методик эластичной разработки, сущность которых сводится к маленьким циклам работ до получения результата. Не отдавайте дань моде.

Выбор разработки неизменно должен быть осознанным, в смысле обоснованным. Сравните минусы и плюсы различных подходов:

Методика разработки

Плюсы

Минусы

Agile-способы итеративной разработки (DSDM, Scrum, FDD)

Стремительный итог, возможность гибко реагировать на новые требования

Отсутствие стратегического планирования, риски все переделывать на следующем этапе

Каскадная модель с твёрдым планированием (Waterflow)

Предсказуемость сроков, бюджета, критерии контроля и чёткие этапы

Недостаточная гибкость к новым требованиям

Как осознать, что лучше в конкретном случае? Чего бы не говорили «гуру от сохи», определяющим в выборе методики внедрения/разработки есть возможность зафиксировать требования. Не формализовать, в частности зафиксировать.

К примеру, в случае если ожидается, что количество трансформаций за срок внедрения составит меньше 20-30% от общего объема работ, лучше выбрать Waterflow. В случае если трансформаций будет больше, стоит без шуток разглядеть способы итеративного программирования.

IT-менеджмент1503 0

Как (де)мотивировать подрядчика вашего IT-проекта

Главы из книг3201 3

Книги для бизнеса: библиотека начальника проектов

>

Разведопрос: Сергей Марков об неестественном интеллекте


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer