А что, тестировщики уже научились проверять качество софта ? (Сарказм)
Да? А критерии где? Нету?
Вот то-то же
Disclaimer: имеется в виду средний по палате тестировщик, а не инженеры nasa

лучше бы он их знать не знал

А что изменится если пытаться что-то объяснять клиенту? Експертизы у него как не было так и нет. Проверить ваши слова он не может. решения принимает все ещё клиент. И он все ещё хочет верить в то что хочет верить.

Не стоит отказываться от каких-либо действий убедив себя заведомо в «не разрешат» и «не получится» =)

Вообще-то весь процесс по выбору тулов/фреймворков и средств разработки это очень дорого (по времени). И оно не делается ’generic’ чтоб можно было потом использовать. Это надо делать под каждую конкретную задачу. Иначе просто бессмысленно.
И вот пришел такой клиент, и говорит -’хочу либку х’ , я тут у дяди Васи, соседа такую видел. Он платит, он решает какая будет либка. И что бы вы ему не говорили, он все равно в конце может сказать ’я ими не доволен’

Ту надо ставить вопрос ’кто принимает решения и насколько принимающий решения компетентен ?’ можно ещё добавить ’кто будет нести ответственность’. Если расклады таковы, что решения принимает клиент, при этом он не компетентен в области, но платит деньги и несёт ответственность, то все вопросы отпадают. Нет смысла ему что-либо объяснять про ’неработающие штуки’.
А вот если часть ответственности на исполнителях, то тут все сложно. Тут или предлагать только заранее годные варианты, и так чтобы клиент выбирал только из них. Самодеятельность не позволять. Ну или сразу оговаривать — на ком ответственность тот и принимает решения

Ну, во-первых донести что ’такой-то тул не подходит для решения такой-то задачи’ это уже сложно. Во-вторых, вариант с накидать на коленке альтернативу вообще-то не работает. И это даже хуже чем рандомный выбор кастомера.
Потому что для начала надо сформулировать задачу (ее как правило нет сформулированной на этом этапе).
Потом определиться с критериями выбора тулов/фреймворков/языков/технологий. Это уже долго. А потом надо ещё и проевальюировать пол рынка, чтобы найти хотя бы первый годный тул.
На коленке такое не делается. Штатного времени на такое тоже как правило не дают.
А вариант предложить на коленке альтернативу — он местами хуже варианта кастомера. Как минимум потому что ,на свой собственный вариант кастомер уже был согласен

Оттого что вы расскажете клиенту, что текущий стек технологий/языки/либки/фреймворки не способны решить ту задачу, которую поставили — ничего особо не поменяется.
Не редкость когда выбор фреймворка это что-то вроде ’ а у наших конкурентов именно этот фреймворк, мы его тоже возьмём’.
И никакие аргументы не работают.
Более того, если спросить напрямую а почему выбрали именно этот тул — то это вгоняет клиента в ступор. Это мы ещё даже не начали говорить про критерии выбора.
Кстати, менее компетентных левов никто не отменял. Они все ещё придут и объявят неработающую штуку работающей.
Иногда в роли таких девов сам клиент. И тогда вообще зашибись

А что именно вы пытаетесь решить такого рода прототипами? Зачем они ? Для кого ?
Судя по рисункам это не MVP. И это уж точно не прототип UI от дизайнеров.
Это и не прототип дизайна/архитектуры системы. Потому как в нем отсутствуют структурные связи (целостная картина). Тем более что в разработке этого прототипа отсутствовал техлид.
Если это был прототип требований от заказчика, то он ИМХО содержит много лишней информации (визуальной), и даже вводит в заблуждение...что из этого требование , а что просто часть прототипа/заглушки

С пунктом 1 ( про impossible ) все далеко не так однозначно. Не редко бывает что приходит клиент и ставит некую задачу. Тим лид или команда садятся и начинают Брейн шторм. И по ходу дела оказывается что в постановке задачи есть противоречия. Или что у каких-то штук есть зависимости и нельзя просто так взять и подкрутить чтобы обе были с некоторыми характеристиками , а можно только 1. Или что некоторые вещи в принципе невозможны в неких условиях (используем не real time OS, а хотим строгие гарантии по времени отклика)
На этой все лид /дев прямо скажет impossible.
А потом к клиенту приходит кучка менее компетентных девов, и гордо объявляют неработающую штуку работающей. И клиент им верит, потому что ему очень хочется верить. А проверить он не может....

Лего картинки это конечно забавно. Но лучше б отдали raw данные. И графичками. А то выборка параметров для написания текста отчета как-то не очень.
Даёшь raw!

Поинт в том, что по сути нужно не пост фактум ревью сделанного кода, а ревью решения/дизайна Перед началом имплементации.
И да, это будет микро agile.

Есть один интересный нюанс.
В схема с 2мя исполнителями получается скорее ’дизайн ревью’. Ревью неких решений, архитектурных и не только. То есть из пост фактум ревью пулл реквестов мы так плавно перешли к ревью дизайна Перед началом исполнения.
Это действительно полезно. Вот только собственно сам пулл реквест теперь ревьювить не очень надо. Потому что если что-то пойдет не так, то принимающий опять будет ревьювить дизайн. И потом снова имплементация. И так по кругу.

А что за метрики production-а такие?
Интересно как вы меряете что приложение действительно работает у пользователя.

А что есть рекрутеры, которые действиткльно обладают навыками для оценки soft skills? Если да, то это что-то новенькое.
Обычно там не оценка, а описание каких-то ощущений рекрутера. Обратное чрезвычайно редко.
А насчёт Codility и ему подобных. Ни рекрутер, ни менеджер во многих случаях понятия не имеют что действительно надо будет делать на проекте. Могут даже лидов не спросить. Описание вакансии пишут как-нибудь . В итоге найти надо универсального единорога.
Вот и прилетают всякие тесты.
Не то, чтобы от них нет пользы. Просто они как правило не релевантны с реальной вакансией.
Бесит именно то что они не релевантны.

Вообще-то для embedded очень даже характерна задача добиться размера бинаря не больше чем Х. А размер бинаря это один из видов метрик для измерения сложности. Так что...

Т.е. есть как минимум 3 разных понятия, подразумеваемых под ’сложность’. Но нет, будем смешивать их в одно потому что есть 1 слово?
Теперь про пресловутую ’общественно полезность’ и ’трудоемкость’.
Трудоемкость можно выразить через количество логических операций необходимых для решения задачи. Оно очень даже осязаемое и измеряемое. Причем консистентно от человека к человека. Другой вопрос что для некоторых подзадач существуют уже готовые решения, и некоторые об этом знают, а некоторые нет.

Будет ли измеренная сложность объективной действительно зависит от метрики. И тем не менее, если иметь дело только с обективно измеряемыми параметрами, то и измеренную таким образом сложность тоже можно назвать объективной.
Не ’истинной ’ или ’правдивой’. А всего-лишь объективной

Не работает для чего?

И ничего там толком ты не найдешь. Будут безумные фантазии психолухов

Видимо вы никогда, или почти никогда не читали нормальные papers. Papers, а не высеры в интернетах . Иначе бы не утверждали что там нет определений. Или что это фантазии.

Оценка экпертов на то и оценка, что это оценочные суждения. И в некоторых случаях оценка базируется на объективных показателях/метриках.

И нет, такой подход скорее не работает чем работает. (оценка сама по себе)
Более того, оценка експертом скорее всего нужна для достижение консенсуса по некоторому вопросу.

Работает. Прямо с ходу могу назвать аж несколько вариантов. Знаю проекты где это применяется.
— все та же цикломатическая сложность
— тупо размер бинаря
— наличие и количество циклов переменной длинны (очень актуально для всех real time систем)
— все та же О(N)

И все это про ’сложность’

А с каких пор цикломатическая сложность стала фиктивной метрикой?
А ’сложность в человеческом понимании’ это про оценочные суждения. Они как правило субъективны. И естественно не консистентны от человека к человеку.
Если покопаться, то в каких ни будь paper по психологии найдется даже определение этой ’сложности’.
Так вот собственно, объективная сложность системы (измеренная какой-нибудь метрикой) != субъективная оценочная сложность.

И цикломатическая сложность не единственная метрика сложности системы.
Можно например представить систему графом, и считать количество ребер (связей) в нем. Тоже метрика сложности.