Когда я писал о процессах - я имел в виду постановку работы таким образом, чтобы уменьшить влияние человеческого фактора, в том числе самодурства. В качестве примера таких действий по уменьшению влияния людей, привёл чеклисты и колл-центры.
Потому что это известные примеры. Исходил из того, что если бы я привёл какую-то более специфичную ситуацию, сразу бы получил вопрос "а всем ли это надо и у всех ли это сработает?", но и здесь, Роман, вы нашли как ударить по иллюстрирующему примеру, а не сути аргумента.
Если вы внимательно почитаете аргумент про "Решают на уровне построения процессов", то там дальше увидите ремарку, что не у всех организаций есть ресурсы на организацию исследований психологии инженеров для решения проблем людей, вместо выставления ограничений в рамках процесса. Надеюсь, вы не будете хотя бы с этим спорить?
Впредь постараюсь все такие высказывания обрамлять в "по моему мнению, в некоторых случаях после предварительной оценки, может быть полезно сделать", хотя, честно говоря, это утомляет.
Особенно когда оппонент придерживается точки зрения, что люди могут договариваться с разным понятийным аппаратом, но сам действует только в рамках личных установок. И тем не менее, даже в таком диалоге мы можем получить новые мнения и опыт, поэтому если нужно вставлять подобные уточнения - постараюсь их сделать.
Если немножко в таком стиле ответить: какие ваши доказательства, что процессы "в текущем изводе чаще создают проблему и порождают тот самый репорт портал"? Всегда ли? Везде ли? Точно ли всем думать лень?
Разумеется не всегда и не везде, я это понимаю, и поэтому готов принять ваш аргумент, ведь проблема действительно есть. Вы мне не всегда отвечаете такой любезностью.
Не могу сейчас выдумать пример в вакууме, кроме банальной просьбы высокого руководителя сообщать ему лично о том самом "самодурстве" среднего менеджмента, но даже это может быть движением в сторону защиты от желания строить графики и отчёты ради графиков и отчётов, а не для пользы.
Лично я наблюдал такие ситуации, когда у вышестоящего руководителя действительно не прокатывала подача красивых презентаций ради премии менеджера вместо пользы для проекта. Это отличный вариант решения такой ситуации, менеджер либо учится делать дело вместо заботы о своём имидже, либо увольняется.
Аналогично - доверие заказчика можно зарабатывать, в том числе, таким подходом - когда результаты не приукрашиваются, провалы не скрываются, но при этом организатор процесса всерьёз старается решить задачи, поставленные заказчиком.
По поводу БДД я специально оставил ремарку про оценку целесообразности. Очевидно, если БДД предлагают ради рисованных картинок и дутых результатов - это иная проблема, мы можем её обсудить отдельно, думаю это может быть полезным.
Уточню на всякий случай позицию: согласны ли вы с утверждением, что "хорошо", "правильно" работающий БДД подход в сумме с другими нужными для этого изменениями, способен в определенных условиях (опустим пока набор этих условий, они зависят от конкретного проекта) улучшать процесс разработки/тестирования больше, чем затраты на реализацию БДД? Если вы считаете, что БДД никогда не может окупиться, то нет смысла продолжать эту ветвь дискуссии и лучше переключиться на техническую составляющую.
По поводу java - да, очевидно, что как и во многих долгоиграющих языках, вбираются удачные решения "соседей", и я писал о том что на джаве можно действовать не так, как "принято" классически в рамках ООП подхода, но опять-таки, чтобы быть в курсе таких тенденций, нужно за ними следить. Не все автоматизаторы это делают, ведь им хватает текущего подхода.
Мой вопрос заключается в том, можем ли мы оценить, что проще, следить за веяниями в облегчении "тяжеловесной" джавы, или выбрать для проекта JS или Python как альтернативы. Опять-таки, не везде это рационально или вообще возможно, но при старте нового проекта стоит задаваться таким вопросом, а не сразу брать джаву, разве нет?
Общее замечание: я согласен с теми людьми которые полагают что универсально полезных практик нет. Разные вещи могут быть полезны или вредны в зависимости от конктекста. У концепций, инструментов, техник есть область применимости. У "процессов" она тоже есть. Сами по себе абстрактные "процессы" (или чеклисты) общеполезными на вообще все случаи по-моему не являются. У них есть области/границы применимости, и, в зависимости от ситуации, от них может польза быть, не быть, или даже вред может получиться.
