Известно, что до 70% проектов внедрения информационных систем заканчиваются неудачей. Правда эти факты достаточно редко выставляются на всеобщее обозрение . Довольно интересно было почитать о самобичевании фирмы “Формула Безопасности”, заказчика проекта которые, “тоже признали свою вину”, но все-таки настояли на возврате 50% предоплаты.
Такой конфликт стандартен для всех проектов автоматизации. 1С- вцы могут настаивать, что это единичный случай, но это не так. И дело здесь даже не в платформе. Дело несовпадении ожиданий (как я уже писал) заказчика и подрядчика (довольно часто истинные ожидания заказчика скрыты до момента сдачи проекта). Поскольку требования к проекту были зачастую весьма размыты, то трактовать их можно в любом направлении.
Итак, коротко суть конфликта:
“В ноябре 2006 г. «Формула Безопасности» заключила контракт с компанией ВДГБ — партнером «1С» на создание системы автоматизации. Сумма контракта составила 5 млн руб. К 1 апреля 2007 г. проект, содержащий 13 спецификаций, должен был быть завершен. Но к окончанию проекта закрытыми оказаличь лишь 1,5 спецификации”.
А вот это интересно, за 6 (!) месяцев стороны как бы и не видели, что проект катиться к пропасти. Вернее все видели, но закрывали глаза или повернуть проект в нужное русло не смогли, к тому же за это время у ВДГБ сменились три (!) менеджера проекта. Только представьте, приходит неопытный менеджер проекта, которого бросают в серьезный бой (а проект для “Формулы Безопасности” довольно большой и уже получена предоплата, партия сказала “Надо” – Менеджер ответил “Есть!”). Через пару месяцев работы становится ясно, что проект необозримый и сделать его этими силами и с этим опытом и не реально. Менеджер увольняется, а на его место приходит новый и все начинается с начала.
- Почему потерпевший весь в синяках?
– Он случайно наткнулся глазом на дверь.
– ????
– Да, господин судья, это случилось десять раз подряд.
И что же было дальше? Развязка приближалась.
С апреля по сентябрь 2007 г. заказчик и исполнитель безуспешно пытались договориться о том, можно ли считать выполненную работу завершением проекта. «Формула Безопасности» не была удовлетворена результатами, ВДГБ, в свою очередь, отказывался продолжать
И тех и других можно понять. Если не документировать требования и не определять ключевые точки, то можно работать долго и упорно над задачами, которе возникают уже после того, как определен объем работ (и выделен бюджет). И получается, что делаются работы, которые не описаны ранее, а то, что описано (и что должны проверить) не делается. Требования “плывут”, менеджера проекта – нет. Ограничить заказчика в наваливании горы пожеланий – некому. Зарплата идет, результат – предсказуем.
А виноваты оба. У подрядчика небыло людей с нужной квалификацией (сейчас вообще найти людей с нужной квалификацией – проблема). А заказчик этим воспользовался и диктовал свои условия, скорее всего, нигде не описанные. И наверняка не слишком активно занимался проектом, возможно там даже небыло ответственного за внедрение (лучше целой команды).
В итоге все закончилось хорошо (интересно, почему проект посчитали неудачным?). Правда 50% предоплаты вернули, а проект продолжили делать уже другие подрядчики, как это обычно и бывает. Это был хороший опыт, как говорят в таких случаях.
Показательно то, что раскрываются причины по которым проект посчитали неудачным, но ни слова не говориться о том, почему же эти сведения были преданы широкой огласке.
(рейтинг:+1, голосов:1) 
Loading...
Stanislav O. Pogrebnyak
По данному вопросу рекомендую книгу Роберта Мартина “Быстрая разработка ПО” (в основном там техническая информация но есть и обще-полезная лирика) и книгу Э. Ханта и Д. Томаса “Программист-прагматик”. И все что есть у Кента Бека.