Проект шел почти три года, выбор конфигураций не отличался ничем хорошим, и спустя такое количество времени стало понятно, что кроме подхода к архитектуре нужно менять и организационный подход к ведению проекта, причем как со стороны Исполнителя, так и со стороны Заказчика. А Заказчик-то однозначно не специалист по внедрению, иначе зачем был ему нужен Исполнитель? Поэтому после долгих обсуждений был сформулирован (ещё не окончательный) список с предложениями, как сдвинуть эту гору с мёртвой точки. Почему это не было сделано в начале проекта - ответ останется за кадром. Для общего понимания – на проекте больше 100 человек со стороны Исполнителя, и на практически любой встрече количество людей стремилось к 40 – до 10-15 человек от Исполнителя и остальные от Заказчика. Итак, первичные предложения по организации проекта на стороне Заказчика, которые, как мне кажется, стоит брать на вооружение на любом проекте: 1. Ограничение количества Ключевых Пользователей, наделение Ключей полномочиями принятия решений. (С толпой сложно разговаривать и договариваться – каждый тянет одеяло на себя) 2. Организация совместных рабочих групп Заказчика и Исполнителя. Ключевое слово тут – совместных. То есть – не Исполнитель делает всё и подаёт на блюдечке с исправлениями, а ещё и сами Ключи должны, в идеале, согласовывать предложенные изменения процессов внутри компании. Разумеется, при участии Исполнителя. И чем меньше будет размер такой группы – тем лучше. 3. Приоритет на типовой функционал. (Да, достаточно часто конфигурации пилятся в мясо, и даже по желанию тёти Гали из отдела по клинингу) 4. Релизный подход (по сути – спринты, но крупнее) – строгая фиксация требований и согласование порядка их размещения в релизах. 5. Проработка механизма эскалации «нерешаемых» вопросов. 6. Работы по реорганизации процессов вместо функциональных разрывов. (про ФР никто не забыл, просто сначала надо процесс в новой системе собрать, а не сразу ФР фиксировать) 7. Наделение Ключей проектной мотивацией. Смелое предложение, но был один интересный проект, где под таким соусом Ключам давали премии за «неосновную» работу и там было гораздо легче – люди начинали действительно упрощать жизнь себе и своим отделам с помощью новой системы вместо втыкания палок в колёса проекту. Многие скажут – «Это же только предложения к изменениям со стороны Заказчика! Вы что, его запряжете, а сами будете фигнёй страдать??» И конечно же – нет. С нашей стороны будет описание новой функциональной и процессной модели, переход на релизный подход (определить порядок и степень реализации требований в рамках релизов) и контроль логической и функциональной целостности релиза. Чтобы не получилось так, что половина блоков полностью готова, а половина ещё ничего не делала, кроме внесения требований. И разумеется, кучка согласований с Вами :) Ну и небольшое обращение к Заказчикам (которые вполне себе даже Спонсоры проекта): 1. Любой проект – это совместная работа. 2. Невозможно сделать так, что при переходе «ничего не поменялось». 3. Сотрудники привыкли работать так, как привыкли. Новое всегда воспринимается в штыки. Если их не замотивировать. Выбор мотивации – на Ваш вкус :) 4. Требования всегда растут в геометрической прогрессии, а бюджет не бесконечный. Кто-то должен принимать решение о том, без чего можно прожить. 5. Если делать переход ради перехода – ничего не изменится. (Если автоматизировать бардак – будет автоматизированный бардак) Как-то так, всем удачи, с наступившим Новым Годом, счастья-здоровья. Обсуждение, как и всегда, в комментариях.