Что такое хорошая постановка в вашем понимании?

Это миф! Говорю как консультант😂

Все от уровня разработчика зависит) кому то достаточно описать логику, кому то вплоть до fm/класса

Когда конс знает, что он хочет получить, из чего, для чего, и наиболее оптимальным и простым путём. Желательно, чтобы он шарил за места расширения по своему направлению)

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

Это все решается скорее всего внутренними регламентами компании) в каком виде давать ФС

Спасибо, кэп. Но речь шла о том, что "что такое нормальная фс для присутствующих в чятике?"

мне кажется это во многом зависит от творческой части личности разработчика, некоторым описываешь максимально детально и они бурчат если немного просишь отклониться от спеки и что-то допилить, а кому-то абстрактно описываешь задачу и они на харизме пилят классную вещь с удобными фичами

на одном из проектов прописали в регламенте, что при разработке UI5 нужно ОБЯЗАТЕЛЬНО предоставлять кликабельный прототип приложения. До этого заказчику "зарекламировали" UI5 - что это круто, удобно и быстро. Он согласился. когда конс оценил бизнес-потребность, регламент и заказчика - он переубедил сделать все на GUI в итоге довольный заказчик юзает ALV и проблем не знает)

то-то потом бухи радуются... или кадровики... этакому творчеству...

а чем их прототип напугал? Это ж поди про wire-model речь шла... splash, или что там нонеча в моде, в руки - и алга

зачем что-то делать нетрадиционно, если можно традиционно?) думаю, просто не хотелось связываться с бесполезной вещью и тратить время

а.. ну т.е. если конс чего-то не знает, то это становится бесполезной вещью? яснапонятна 🤣

странно, что при таком подходе они не предложили перейти на традиционные счеты

ну не совсем так. на тот момент прототипирование шло в SAP Build и SAP действительно отказался от него. то есть по факту время показало, что конс все-таки прав...

сап отказался потому что есть масса других инструментов. Юзеры просто их выбирали. Поэтому - так себе отмазка

да нет) потому что инструмент - не очень вышел...

Ну так и что? есть масса других, которые вышли "очень" и вполне используются. Подход "сделаем wireframe, что бы быстро показать диазйн приклады" никуда не делся тащем-то

не надо тут подменять понятия) сделаем и покажем дизайн - это одно)) а ОБЯЗАТЕЛЬНОСТЬ для ФС - это другое

че эт ? ну а как тогда показать дизайн малыми затратами у приклады, которая еще не сделана?

Я исхожу из того, что консультант это разработчик. Только пишет он не на ABAP для сервера приложений и БД, а на человеческом для других участников команды. Но процесс разработки на определенном уровне восприятия системы никто не отменял, консультант также моделирует, строит связи, логические цепочки и т.п. Соответственно, кроме общих критериев - полнота и непротиворечивость (и однозначность толкования) - есть еще задача не пытаться объясняться на языке которым вы владеете лишь частично. Пишите по-русски и не выдавайте примеры реализации за позтановку задачи. Постановка содержит цели, задачи, определения функциональности, зависимости и т.п. Но не содержит инструкций по реализации. Это дело команды ABAP. Если в команде ABAP стажер, то помочь ему должен прежде всего ABAP-экперт, а не консультант.

Это требует много времени, чтобы хорошо сформулировать. Чаще проще показать "как не надо делать постановку" Лично для меня, хорошая постановка это та, которая структурировано излагает информацию о реализуемой разработке. Например, нужно обработать какие-то данные: вот у нас входные данные, вот у нас выходные данные, а вот так первые преобразуются во вторые. По шагам, без потерь по дороге "ну тут что-то надо сделать - сам додумай". Естественно, для разных типов задач постановка будет разная. Но должна быть внтренняя непротиворечивость и логичность. Не должны посередине описания процесса из ниоткуда появляться данные. Крайне желательно, что бы при этом соблюдались человеческие нотации (говорю ж, проще на примере "как не надо" показать. Мое любимое "считать данные документа А. В документе Б выполнить присвоение А.поле1 = Б.поле1". Думете что тут присвоение нового значения полю1 в документе А? Хрен там плавал! Консультант хотел присвоить новое значение именно полю1 в документе Б!) Коллеги в чате уточняли (пофиг, что исходный вопрос-то был только про "постановку" ) , что типа "ну вот есть ФС, есть ТЗ". Угу-угу. Иногда есть. А иногда есть только ФС. А иногда - совмещенное одно с другим. Опять же: если с ФС все понятно, кто ее пишет, то кто же будет писать ТС? (а на большей части проектов, кстати, практикуется написание ТС после реализации задачи). Посему, хотелось бы как минимум описания в котором не появляются из ниоткуда данные в середине алгоритма, соблюдаются общепринятые нотации\стандарты, а да! и мое любимое: не используются отсылки к др.бизнеспроцессам "сделать как в ФС Х", т.к. ФС Х - независимый документ, и она может измениться, а ты со своей ФС Y об этом никогда не узнаешь.

Алгоритм задачи описан в ТЗ.ХХХ.000.ХРЕНЗНАЕТГДЕ.НИКТОНЕСЛЕДИТ.ЗАВЕРСИЕЙ

Ну это, кстати, - хороший вариант. Задачи декомпозированы, и идет именно отсылка на ФС. А не "ну сделать точно так же! не сложно жы!"

Вот часто как раз "сделать ПОЧТИ так же".

угу. тем более)