Блеск и нищета откатных проектов
Из объявления о вакансии:
“Требуется менеджер по работе с корпоративными заказчиками. Опыт работы с госструктурами обязателен”
Кто не в курсе, есть две категории IT-проектов- “откатный” и “честный”….
Кто не в курсе, есть две категории IT-проектов- “откатный” и “честный”. У откатного проекта заказчик - госструктура. Чиновники этой госструктуры проталкивают финансирование проекта, за что получают процент от комиссионные, или откат. Если в коммерческой структуре такой “лоббист” был бы скорее всего уволен за нарушение финансовой политики и корпоративной этики, то у госчиновников это нормальный способ улучшить себе зарплату. Обычная ставка отката в России - 10%. “Честный” проект - это когда все по честному, насколько это вообще возможно. Оставив в стороне морально-этические вопросы, я хочу остановиться исключительно на проблемах управления такими проектами. Откатному проекту присущи дополнительные риски провала и превращения в “отвратительный проект” (по классификации Э.Йордана). Происходит это из-за того, что у заказчика отсутствует реальный интерес к задаче, решить которую должен проект. Интерес лоббиста заканчивается с подписанием договора и получением отката. В результате исполнитель не получит ни конкретных формулировок ТЗ, ни конструктивных ответов на свои вопросы к заказчику в разумные сроки. Скорее всего, у этого проекта даже нет реального заказчика, а задача, которую это проект призван решать, надумана. Лобби получили откат - их задачи решены, а задачи бизнеса их не интересуют. Но проекты, которые внятно не отвечают на вопрос “зачем?”, обречены на прозябание в вечности. Они не кончаются, по крайней мере, не кончаются успешно. Можно было кончено всем получить деньги, состряпать наспех какую-нибудь систему типа потемкинских деревень из фанеры и продолжать спокойно жить дальше. Но вдруг, после того как все уже забыли друг про друга и про фанерную систему, заказчикам “просит” отчитаться за потраченные казенные деньги вышестоящее руководство. Тут и начинается весь джаз. В нереальные сроки нужно будет реализовать несформулированные требования для решения несформулированных или несуществующих задач. И кстати, кто вел нормальную документацию на ту ”фанерную” систему? На рабочие системы-то не всегда ее ведут. Аврал, скандал, крики и переработки. Проснувшийся заказчик песочит (это такой процесс “разработки” в госструктурах) исполнителя, а исполнитель, считая, что он один в ответе за проект, судорожно пытается спасти ситуацию. Разработчики ночуют за клавиатурой неделями, плохо едят и спят, от чего количество ошибок и недоработок в коде и в архитектуре системы растет по экспоненте. В результате система становится Франкенштейном, который терзает, пытает и изнуряет исполнителя. Она также становиться проблемой для заказчика. Даже если что-то будет сделано для отчета, то каково же будет поддерживать, продукт, сделанный замученными разработчиками!