Цель опроса понять не столько как в идеале должны взаимодействовать эти три человека сколько узнать как обстоят дела на самом деле на других проектах при разработке ABAP отчетов, особенно когда их очень много.
Хочется понять у всех ли получается писать идеальные ТЗ для программистов, в которых все расписано, начиная с наименований технических полей, заканчивая алгоритмом выборки данных из БД?
Немного поясню варианты ответов:
Программист<->Консультант<->Пользователь, ответ в случае если программист на проекте вообще не консультируется с пользователями, не показывает им отчеты, не при каких условиях, сидит в отдельной комнате и пользователи знать о нем не знают.
Программист<->Консультант(80-90%), Пользователь (10-20%), если программист контактирует с пользователями, сам устраняет мелкие косяки которые учтены ТЗ, но не попали в отчет по ошибке программиста
Программист<->Консультант(60-80%), Пользователь (20-40%), если программист консультируется с пользователями, демонстрирует им отчеты, сам устраняет косяки которые не учтены в ТЗ, но известно как их исправить без помощи консультанта.
Программист<->Консультант(<50%), Пользователь (>50%), программист больше консультируеся по отчету с пользователями, ищет откуда выбрать данные в SAP, в крайнем случае обращается за помощью к консультанту за помощью.

Если отчетов очень много - то это нелады в консерватории. Большенство отчетов вполне можно наваять в sqvi или инфосетах силами самих консультантов.

Если консультант сможет написать такое ТЗ - то это мегааццкий консультант. Если разработчику такое ТЗ необходимо - то это кодер-стажер, а не программист.

Идилия. Я б этих пользователей в глаза не видел. Ибо не моя задача.

Соотношение самое реальное, из моей практики. Только вот косяки ни разу не программиста.

Консультироваться с пользователями? Это шутка юмора?
Если консультант не поставил задачу вменяемо, уточнить у него. Или вы про рюшечки типа "выделите мне эту строчку розовеньким"? Так подобное на уровне консультанта еще должно отсекаться.

"Чужую работу буду делать только за отдельную рыночную плату" (с)

В целом, согласен с Артемом, общая практика в моем опыте - разработчик напрямую с пользователем не общается. Но это очень от разработчика зависит - бывают такие, что многих консультантов за пояс заткнут в части знания функционала )) я уже не говорю о консультантах, которые нормально абапить умеют

Если программист начинает консультироваться у пользователей - то он соответственно тянет на себе нагрузку консультанта. И тогда возникает вопрос : "Зачем нужны на проекте такие консультанты ? " - Видимо чтоб было куда бюджет закрывать. И САП не просто так придумал деление на программистов и консультантов. Консультант ставит бизнес-процесс и соответсвенно общается с пользователями. А вот программист просто разрабатывает отчеты в соответсвие требованиям, которые формулирует консультант.

Не понял, а зачем пользователю знать о программисте? Что еще за условия, чтобы программист стал отчеты показывать пользователю? Вы имеете в виду, что эти условия консультант придумывает, типа ты такой плохой, отчеты пользователям не показываешь, мы из-за этого не внедримся? Хотя если консультант приболел, например, почему не показать, если уверен в консультанте, отчете и себе:)

Не понятен, если честно, смысл опроса - мне кажется ответ очевиден, выполнять функции консультанта абапер будет разве что если хочет, например, себя почувствовать консультантом

Консультант же, доросший до консультанта, я думаю, понимает за что получает деньги. Как я понимаю весь интерес опроса в том, можно ли на абапера попытаться свои функции переложить? Трата времени, мне кажется. Лучше для дела время потратить на нормальные ТЗ. Или на изучение предмета для написания таковых.


Здесь я на стороне консультанта. Ни в коем случае не надо описывать алгоритм выборки данных из БД и никогда все не расписывайте в ТЗ )) А если серьезно, то мое мнение - ТЗ должно быть "расписано" ровно настолько, чтобы уверенность КОНСУЛЬТАНТА в успешном результате реализации стремилась к максимуму. Исходя из ситуации. Хор. абапер подметит и подскажет неточности (либо просто скорректирует), без которых не бывает. А вот если ТЗ не соответствует возможности успешной реализации... (задумался) - то тогда всеми силами абапера к пользователю - пусть сами там разбираются

Все сам . Настоящий программер, в отличие от просто кодера, как мне кажется, должен понимать физический смысл того, что он наваял.
Такому программеру никакой консультант даром не нужен.

Проголосовал за первый вариант ответа.
+1

Sibrin в свое время очень здорово написал про границу между обязанностями разных сотрудников в проекте



Если по существу - у нас пользователи с программистами не общаются вообще.

ИМХО, в настоящее время происходит поиск новых форм организации взаимодействия...: документация устаревает раньше, чем её успевают дописать - не то что применить; становится бессмысленным накопление знаний; тренд от абсолютных объёмов к объёму приращения; считается нормальным грамматическая неграмотность - движение к артикулярно-интуитивному пониманию,..4D-онтологии "дерева стратегии и тактики...жизнь постепенно усложняется упрощением...

Так что вполне возможно, что разделение - "это пережиток прошлого и по факту не более чем выписка из учетных систем пространственных данных." (c) ailev.

+ 1 за первое (только через консультант)

... бывали случаи когда пользователь был очень продвинутым и общался с програмистом, но это скорее исключение, чем правило.

Я за второй ответ (90 + 10).

Бывают "мелочи", которые консультант не учел, а конечному пользователю они важны. Прогонять их сквозь всю цепочку Р-К-П смысла мало. Проще написать программисту замечание на получасовую доработку.

Ситуация еще сильнее сдвигается, когда проект из внедрения переходит в стадию поддержки и развития. Мне в такой фазе повезло общаться с разумными пользователями, которые сообщали об ошибках и пожеланиях в полной и компактной форме (вместо "налоги в отчете считаются неверно, поправьте!!!"). При таком раскладе, вполне приемлема ситуация и 50 на 50. Особенно с однотипными отчетами.

PS Правда проект был на 80% из Z-разработок, так что роль консультантов была незначительной

2 Skif:
Немного офф... Возможно Вы наблюдаете изменение отношения людей к делу (не учитывая неграмотность)? Например, от покупательско-потребительского подхода к осознанному ценностно-ориентированному (вроде lean production) в широком смысле?
Не хотелось бы обсуждать все симптомы (документация, знания и др.). Imho всё это разделение есть попытка синтезирования качественного выхлопа системы не выходя за рамки её энергетического потенциала. От бедности наверное, а где-то и от скудоумия...