Зачастую проблемы проекта заложены в самом его начале, потому что нет ответа на следующие вопросы: Кто является основным функциональным заказчиком? Кто является владельцем бюджета? Кто является высшей инстанцией для эскалации проблем? Какова вертикаль принятия решений на стороне заказчика и исполнителя? Существует ли устав проекта? Насколько четко в нем прописаны алгоритмы взаимодействия сторон? Выделены ли на стороне заказчика все необходимые функциональные специалисты и предусмотрено ли в их рабочем графике время для этого проекта (а желательно ещё и система премирования)? Существует ли резерв бюджета на незапланированные ранее работы, кто владелец данного бюджета и какова процедура его выделения? У кого и в каких случаях есть полномочия останавливать проект или корректировать объемы или сроки работ по проекту? И т.д.

План проекта – один из главнейших документов наряду с ТЗ и техпроектом. Если план нарисован «для красоты», чтобы в начале проекта убедить руководство, что всё будет сделано к «красным дням календаря» - жди беды ближе к концу проекта. Никакие лукавые объяснения в духе «мы тут поднапряжемся, а там нагоним побольше людей, а там поработаем в субботу» не спасут проект, если в плане заложены системные ошибки и нестыковки. Как говорится – «девять беременных женщин не родят за месяц». Необходимо честно проанализировать план: Насколько детально проработан план проекта? Возможно ли на данном этапе его детализировать, если впереди ещё предстоит написать ТЗ и концептуальный и технические проекты? Нет ли нелогичного следования взаимосвязанных этапов (например – обучение пользователей до развертывания и тестирования системы)? Насколько реальными выглядят сроки по отношению к планируемому объему работ? Располагает ли исполнитель необходимыми ресурсами и указаны ли они поименно в задачах плана? Все ли необходимые работы учтены (например – закупка оборудования до начала развертывания системы)? Учтены ли праздники и отпуска? И т.д.

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

Очень часто проблемы проекта начинаются с некорректно составленных технических требований, которые рассылаются потенциальным исполнителям для оценки бюджета внедрения. Регулярно приходится видеть подобные документы, которые были составлены наспех из различных (зачастую противоречивых) требований разных подразделений или созданы путем «художественной аппликации» из требований к различным системам. Также очень распространена ситуация, когда ТЗ и технические проекты написаны так поверхностно и в терминах «общечеловеческих ценностей», что любой, кто её читает, может в качестве результата представлять что-то своё, совершенно не совпадающее с изначальной задумкой автора. Это приводит к тому, что на этапах оценки бюджета и написания ТЗ потенциальные исполнители пытаются минимизировать цену работ за счет молчаливого отказа от части от них, а заказчик до момента приемки системы пребывает в полной уверенности, что получит всё, о чём думал. Как показывает практика, каждая из сторон впоследствии трактует любую расплывчатую фразу в свою пользу, что приводит к бесконечным и непродуктивным спорам. Например – фраза «система должна позволять X» трактуется исполнителем как то, что впоследствии система должна позволить добавить функцию X (за дополнительные деньги, разумеется), а заказчик уверен, что такая фраза является явным указанием на необходимость функции X в системе на данном этапе. Во фразе «В системе должна быть реализована функция Y для того, чтобы … Z» аналогичная печальная участь постигнет функционал Z. Анализ проектной документации и её своевременная актуализация до начала этапа разработки является важнейшим фактором успеха проекта.

Моя задача – помочь заказчику и исполнителю прийти к единому понимаю системы, что кардинально сокращает возникновение споров и взаимного недовольства на более поздних этапах. Описанная выше проблема различного трактования требований документации, к сожалению, обычно выявляется только на этапе сдачи заказчику уже разработанной системы, что не позволяет вносить большие изменения в практически готовую систему, которая в текущем виде может не представлять ожидавшейся ценности для заказчика. Такие проблемы обычно происходят при использовании классической «водопадной» модели проекта, когда этапы обследования, написания ТЗ и разработки следуют последовательно один за другим и занимают достаточно длительное время. Это приводит к тому, что после подписания сторонами «расплывчатого» ТЗ исполнитель уходит в разработку и потом приносит заказчику готовый (на его взгляд) результат, который неприятно удивляет заказчика. Поэтому самым важным этапом проекта является выработка единого понимания у заказчика и исполнителя, какие именно функции будут реализованы и как именно они будут работать. Для этого уже давно придуманы методологии гибкой разработки (например, Agile) и различные приемы совместного обсуждения функций системы в стиле «Пользователь в роли X хочет сделать Y чтобы получить Z. Для этого ему нужно выполнить действия A, B, C» (принципы User story mapping, Customer journey и т.д.). При таком подходе обе стороны будут иметь единое понимание того, что именно делает пользователь в системе, для чего и как. Наборы этих пользовательских историй должны быть отсортированы по приоритетам, и демонстрировать заказчику сразу после завершения и до перехода к разработке следующей истории.

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

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

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