Здравствуйте, Saddo, Вы писали:

nvb>>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
nvb>>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
S>Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.

Уже много всего мы написали. Попробую избежать ухода в мультитопиковость

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

1. Аналитики не всегда могут корректно перевести англоязычные термины
2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность
3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики)
4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.

Это все? Можно дополнить.

Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта

1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения.
3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась
4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,

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

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