Договор с богом

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

А если конкретнее, то речь пойдёт о госконтрактах, применительно к моему собственному опыту, в крупных ИТ-проектах.

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

И собственно этап Реализации я бы разбил на две фазы: «бумажная» и «железная».

Хотя часто имеет место быть многомесячное, а то и многогодовое творение, под названием Концепция. Над которым, в неформальном порядке, трудятся несколько избранных, как со стороны Заказчика, так и со стороны Исполнителя. Но, даже когда за это платятся деньги, серьёзный, и в последствие читаемый и цитируемый документ, получаются редко. К тому же, между эрой Концепции и революционной эпохой Реализации может смениться не одно поколение менеджеров и законодательных модернизаций.

И вот на стадии завершения Реализации возникает задача сдачи результатов работы Заказчику. В «железном» виде. Потому как «бумажную» либо не читали, либо не поняли, либо поняли, но не так. А обычно, верхний менеджмент Заказчика ознакомился и подписал, а средний и низший слои ни сном, ни духом. И вот вы приходите именно к ним что-то внедрять.

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

И тут существует два крайних, взаимоисключающих подхода.

Первый подход. Сдавать всё строго по «бумаге».

Последствия: у вас всё примут. Проект, наиболее вероятно, будет рентабельным, но каждый человек из штатного состава Заказчика расскажет всем знакомым о вас много не очень хорошего. Вернее, очень не хорошего. Причём позиция у них может быть проактивной, а не реактивной. Т.е. они не будут дожидаться пока у них про вас спросят, а сами позвонят/напишут/расскажут.

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

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

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

Между этими Сциллой и Харибдой есть, вероятно, несколько проточин, куда можно проскочить.

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

При расплывчатых «бумажных» формулировках можно писать уточняющие конкретизирующие документы, направлять Заказчику с пометкой типа «в случае не получения возражений в 5-тидневный считается согласованным».

Можно ещё попытаться столкнуть лбами некоторых представителей Заказчика, у которых обнаружится диаметрально противоположный взгляд на решение одной и той же проблемы. Делая ставки и оценивая риски победы одного из них.

Мечтая попасть в те 16% ИТ-проектов, заканчивающиеся, по мнению одной очень авторитетной организации, успешно.  

Опубликовано ещё и здесь:
http://community.livejournal.com/ru_pm/170915.html
и здесь:
http://community.livejournal.com/ru_business_man/1267937.html