Комментарии 6
а получилось как обычно
а получилось как всегда (с) Черномырдин
Классику знать надо.
Когда заказчик тянет с ответами, весь проект рискует пойти наперекосяк. Не раз сталкивался с ситуацией, когда сроки сокращаются, а требования остаются размытыми — в итоге качество страдает
То с чем я сталкивался:
1 Окологосударственная контра, директриса много лет спускается до микро менеджмента с поиском виноватых.. Участники проекта со стороны заказчика откровенно не тянут даже свою тему. Как-то много лет по накатанному выстроенному до них процессу работают, а люди которые процесс выстраивали уже там не работают.
В такой ситуации наша команда аналитиков самостоятельно решала за заказчика все методологические вопросы, разрабы делали и заказчик это получал и радовался, так как ничего лучше он не видел и представить не мог. Но тут аналитики были сильные и по теме заказчика знали реально больше и лучше.
2 Организация с сильными методологами. Иногда делали просто как они хотят, хотя на наш взгляд кривое решение. Но в большинстве вопросов сотрудники заказчика четко знали что хотят, оценивали и понимали новые предложения и быстро принимали решения. Работы много, сложные вещи, но приятно и четко.
3 Со стороны заказчика полное сопротивление и нежелания, много сотрудников не тянут. С нашей Аналитики не в теме и не прорабатывают до конца вопросы, ограничиваются узкой темой с узким специалистом заказчика - закрывают только один вопрос без связи с остальными частями проекта.
В итоге ко второму этапу нарываемся на сотни вопросов не решенных на первом этапе и мешающих реализации второго этапа. А первый закрыт и акты подписаны. Начинается бюрократия.
Итог - все решают специалисты, а все проблемы от их отсутствия или недостаточной квалификации.
Результат никогда не будет полностью соответствовать ожиданиям, но стремится к такому состоянию необходимо. Для этого нужно регулярно уточнять ожидания заинтересованных сторон. По мере усложнения или расширения проекта под эту задачу выделяется специальный человек: аналитик или бизнес-аналитик.
Раньше это называлось просто проектировщик и системы строились так: Аван-проект, эскизный \ технический \ рабочий проект, приемка, внедрение. В раках проектов - делали разные макеты, а в итоге - опытный образец ("железки" или ПО или все вместе - не важно). Сейчас такого обычно не встретить.
На этапе эскиза - рассматривалось несколько вариантов реализации изделия (а, б, в и т.д.), подходов, примерное технологическое направление реализации (используемые технологии) и т.п. Заказчик принимал эскизный проект и говорил, что выбирает варианты а) и б) для дальнейшей проработки. Начинался технический проект и т.д. Рабочий проект - это документация, по которой можно "работать": или строить (если это стройка) или отдать чертежи на завод, чтобы по ним что-то изготовили и собрали.
А техническое задание на изделие правилось на каждом этапе, т.к. хорошее ТЗ составить можно только на финальном этапе и то, это сможет сделать только сам разработчик.
«Хотели как лучше, а получилось как обычно»: почему заказчик получает не то, что хотел?