В начале проекта сбор информации и запись требований проходят гладко и по плану. Однако при переходе к этапу разработки начинаются задержки и сдвиги сроков, что особенно удивительно, когда разработчики полностью выделены под проект. Руководитель проекта часто лишь констатирует факт сдвига сроков и не уверен в новых сроках. Без опыта в разработке ему особенно трудно понять причины задержек.
В моём первом проекте по внедрению ERP системы Oracle RMS в 2007 году мне случайно поручили команду, задачей которой была выгрузка данных из системы Domino в новую систему. У меня не было знаний об этих системах, и я не понимал сложности задачи. Пять человек постоянно сдвигали сроки.
Я перешёл от контроля по датам к ежедневному контролю. Каждое утро мы собирались с разработчиками, обсуждали их планы на день и записывали ожидаемые результаты. В конце рабочего дня мы подводили итоги, и если кто-то не выполнил план, он объяснял причины.
Четверо из пяти разработчиков начали выполнять свои обещания и даже догнали изначальный план. Сработал эффект общественного давления и соревнования. Коллеги подшучивали над теми, кто занижал сроки, и помогали тем, кто сталкивался с трудностями.
С пятым разработчиком я начал проводить контроль каждый час. Первые пять минут часа — планирование, последние пять минут — контроль. Но это не помогло, и я узнал о существовании скрытых противников проекта. Но это уже другая история.
Выводы
- Ежедневный контроль: Регулярные утренние и вечерние встречи повышают ответственность и производительность команды.
- Эффект общественного давления: Соревнование и поддержка коллег помогают улучшить выполнение задач.
- Индивидуальный подход: Иногда необходимы более строгие меры контроля, но они могут не всегда срабатывать.
- Выявление скрытых противников: Важно своевременно выявлять и нейтрализовать участников проекта, препятствующих его успешному завершению.