Устав проекта (почти взгляд заказчика)

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

Когда заказчик видит первый документ, который ему необходимо утвердить, он задает вопрос: «А что это?». Приглядевшись, заказчик понимает, что этот самый «первый документ» донельзя серьезен и максимально строго оговаривает настолько принципиальные вещи, что утвердить этот документ невозможно категорически.

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

Во-вторых, почти всегда видение заказчика проекта отличается от видения исполнителя. Принципиальная разница – в образовании, взглядах, профессии. То, что важно для профессионального финансиста или управленца, для IT-специалиста просто прихоть.

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

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

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