Ошибки Заказчика на фазе анализа

(Из ленты b290 » работа)

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

Я люблю своих Заказчиков. Мне с ними везёт. За всю свою карьеру мне не встретился ни один неадекватный Заказчик. Но тем не менее нервов моих скормили они собакам немеряно. О том и поговорим.

Как уже повелось, начнём с контекста. Попробуем ответить на вопрос — а что им, Заказчикком, движет?

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

А бывают еще и другие Заказчики — такие, которые вынашивали проект буквально как ребенка — кормят только вкусными конфетками и воспитателей пытаются найти получше. И я думаю, не стоит объяснять, почему они остро реагируют на признаки того, что проект не будет выполнен или его реализация не приведет к ожидаемому эффекту.

Именно поэтому неадекватных Заказчиков не бывает. Если тебе кажется, что твой Заказчик неадекватный, то проблема скорее всего в том, как ты организовал и ведешь проект в глазах своего Заказчика. Ты можешь идеально засетапить проект. Но если это не видит или не понимает твой Заказчик, то у тебя появляются проблемы, поскольку Заказчик начинает сетапить проект за тебя. И тут начинаются нюансы моментов. Я выделил три, поскольку пока только они пришли в голову.

Управление проектом

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

Желание лезть в управление проектом и лично все организовать возникает у Заказчика тогда, когда он не видит или не понимает того, как устроен проект на стороне вендора, кто за что отвечает и как он может отслеживать прогресс.

Поэтому важно помнить две вещи:

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

Квалификация привлеченных специалистов

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

Важно помнить, что проект не делается только вендором. Проект — это общее дело вендора и Заказчика. Это подразумевает некоторое взаимодействие. А взаимодействие всегда приводит к разделению ответственностей и полномочий. В том числе и в экспертизах.

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

Когда это не сделано, мы искусственно создаем возможность возникновения выше обозначенной проблемы. По сути — провоцируем Заказчика.

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

Но важно всегда помнить — в вопросах быстрого погружения в предметную область, оптимизации работ, быстрого получения результата, синтеза решения и подобных вещах аутсорсер ВСЕГДА сильнее ИТ подразделений Заказчика. Это жизнь, ребята. Нас это кормит.

Но никто не знает бизнес Заказчика лучше, чем люди Заказчика.

Навязываемые решения

Это опять про экспертизу. Точнее про ее уровень на стороне Заказчика.

Мне пару-тройку раз довелось видеть, как вендор навязывал Заказчику технические решения, по той или иной причине обреченные на провал: отсутствие у Заказчика экспертизы для сопровождения продукта, разведение технологического зоопарка, неоправданная сложность решения и т.п.

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

Здесь я могу только одно сказать — вендор должен всегда помнить о своей ответственности перед Заказчиком. Сам факт того, что нас позвали делать проект, говорит о том, что нам доверяются.

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

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

Источник: Ошибки Заказчика на фазе анализа