MonochromatiqueТут вся тема о томстранные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов.

Нет. В типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону. Даже если BL будет реализовна неправильно (на самом деле так, или кодер так подумал) - проблема будет ВЫНУЖДЕНА подняться до проектировщика интерфейса.

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

"спуск интерфейсов" - вполне может быть даже частью системных требований. но речь не об интерфейсах реализованных/задекларированных в каком-то коде. PM пишет юнит с декларацией интерфейсов?.. архитектор, в целом, может. или тимлид. или сам программист, который должен эту задачу реализовать.

MonochromatiqueА в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет.

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

MonochromatiqueТут вся тема о томпропущено...

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

"спуск интерфейсов" - вполне может быть даже частью системных требований. но речь не об интерфейсах реализованных/задекларированных в каком-то коде. PM пишет юнит с декларацией интерфейсов?.. архитектор, в целом, может. или тимлид. или сам программист, который должен эту задачу реализовать.

пропущено...

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

В in-house разработке, особенно там, где производство ПО ДАЛЕКО не основная деятельность - косты режутся до состояния будет/не будет.

Какое код-ревью, какая аналитика, какая проработка. Но качество ПОДАЙ.

Дали мяч - фуячь, вот и всё ТЗ.

С 1С-ом тоже в принципе можно придумать что сделать. Ведь цель - дать адекватную оценку результату за минимальное время. Разработать критерии и т.п.

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

как это какой код-ревью? вы что, действительно фигачите сразу на продакшене? или неглядя выкладываете?
и почему прозвучало "какая аналитика"? вроде ж был сбор требований, было "100-страничное ТЗ".
авторДали мяч - фуячь, вот и всё ТЗ.
вот! вот мы и вернулись к проблеме руководителя!
вы все продолжаете быть программером. учитесь посылать нахер)))
хитро, культурно, так чтобы все подумали что вы их хвалите, заботитесь об их здоровье и долголетии.
ну и, собственно, это ж прозвучала констатация: все плохо, как все исправить, ничего не меняя.

надо начинать.

имхо начать имеет смысл:
- с решения проблем постановки - то что выше озвучил про работу с требованиями; в процессе организации (постепенного проявления в сумбурных процессах) работы с требованиями должны потихоньку воспитываться заказчики. им нужно обозначать риски, трудозатраты, произносить фамилии тех, чьи задачи и насколько календарно должны быть сдвинуты чтобы сделать их "важную" говнокнопочку - все то что слышать не очень приятно. они не спрашивают - а вы все равно рассказывайте. и переспрашивайте, и просите подтверждения. мол, туповат я стал, да и забываю все. киньте в почту.
плюс корректная оценка квалификации, адекватные назначения и декомпозиция+детализации требований

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

т.е. надо прекращать на вход подавать непонятно что
и надо начинать смотреть что же там на выходе выдается

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

MonochromatiqueОстался вопрос.
вопросов гораздо больше одного

MonochromatiqueВ самом начале создается описание системы. Основные понятия, перечисление подсистем, картинки, схемы и прочее.
Скажем так - вырастает это всё до сотни страниц. Это по лайту.
Зачем это - заказчик хочет ПОНИМАТЬ, что он получит в итоге.
Понять он может только текст. Причем околохудожественный.

водопад вам нахрен не нужен
100 страниц - жесть
я так понимаю речь не о моделях бизнес-процессов и алгоритмах, не о UML, IDEF0, EPC, т.е. "просто текст"
по факту итоговых страниц может быть гораздо больше, вопрос не в количестве

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

MonochromatiqueВ какие-то короткие сроки такой документ сделать нереально. Качественно сделать, я имею ввиду.
Почему - писать можно что угодно. Какие-то системы могут быть несогласованы между собой, какие-то откровенно противоречить.
Есть какие-то методики анализа/проверки, что модель описанная текстом - валидна?

ээээ ммммм читать написанное? структурировать написанное чтобы его можно было читать? иметь разные уровни требований, а не "100 страниц текста"?

MonochromatiqueПроверять программированием - долго.
Остаются прототипы?
не очень понятны оба пункта. проверять программирование-... если ничего не проверяли, то потом все сразу - да, долго. или у вас и здесь водопад?

- программисты, вот вам 100 страниц!
(через год)
- пм, вот тебе 7000 юнитов, 200 000 строк!
- пользователи, вот вам 300 форм и 1500 кнопок!
- ...вашу мать, это че за херня?

последний пункт - без вариантов! только так.

прототипы - это скорее про управление ожиданиями. прототипировать можно на этапе сбора требований, на этапе проектирования, на этапе реализации. везде будут разные прототипы для разных людей (ну, может что-то и для одних и тех же но на разном уровне проектирования, с учетом разных подробностей). с учетом "пишем 100 страниц сначала" тоже теряет смысл и не очень понятно в какой момент и кому нужны эти прототипы.

обратно смотреть на методологии и работу с требованиями