Зачем вы вообще ему что-то доказываете? С вами человек говорит с позиции ребенка, а вы ему пытаетесь логикой что-то рассказать. Уверен, что до "совместного бюджета" нужно дорасти ментально, ваш оппонент пока не дорос и не готов воспринимать такую, казалось бы, базу здоровых отношений.
Потому что у нас не Штаты, а Россия — тут даже на испытательном сроке нельзя просто взять и выгнать человека. По ТК (статья 71, если точнее) нужно оформлять увольнение по всем правилам: документально фиксировать несоответствие, собирать доказательства, ждать проверок. А любой адекватный кандидат с юрподдержкой (а такие как раз и прорываются) заставит выплатить минимум три оклада, да ещё и через суд восстановится, если ты косяков в бумагах допустишь. Так что 'попробовать на работе' — это не пять дней, а месяц геморроя с риском остаться и без сотрудника, и без денег.
Прилетает сотня резюме — все одинаково красивые, все по шаблону 'идеальный кандидат'. А когда начинаешь копать — 80 просто нагло врут, 15 что-то умеют, но тоже приукрасили, и только пятеро более-менее честные. И теперь попробуй найди этих пятерых... или хотя бы тех пятнадцать! А ведь по бумагам-то они все на одно лицо — ChatGPT научил, как надо. Вот и приходится устраивать трехэтапные (минимум) собесы, потому что иначе никак не отфильтровать, кто там реально может работать, а кто просто резюме хорошо оформляет. Ах да, там еще среди 80 есть 5-10 человек которые еще натренились проходить собеседования. Кодить не умеют, но собесы и вопросы задрочили. Обычно от таких мы чаще всего слышим "Зачем литкод на собесе? Я же сказал, что все знаю и умею, а джентльмены верят другу другу".
Поток огромный — значит, делаем классическую пирамиду: сначала HR гоняет 500 дешёвых скрининговых звонков, потом мидлы мучают 50 средних по стоимости собесов, и только потом синьор, зажмурившись, тратит время на 5 «избранных».
А альтернатива-то какая? Чтобы этот самый синьор сам нырял в эти 500 резюме? Ну тогда он не код писать будет, а только собесы давать. Так что да, компания «побегала» в три этапа — зато синьор хотя бы не сгорел на первом же круге ада.
Попробуйте разместить такую вакансию — с хорошей зарплатой и условиями. И вот они, 500+ идеальных резюме: всё по пунктам, как в вашем списке. Правда, когда начнёте собесить, выяснится, что реально соответствуют — ну может, процентов десять. Остальные просто научились красиво копировать шаблоны и загонять их в LLM
Наоборот - жесткие дедлайны ДОЛЖНЫ занимать ВЕСЬ скоуп. Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет. Поэтому, наоборот - весь скоуп должен быть ЖЕСТКО прибит к срокам. И вендор должен обспечить необходимое количество разработчиков, чтобы выполнять взятые на себя обязательства. С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем". В этом случае заказчик сразу начинает искать другого вендора.
Иначе и в случае оплаты заказчик будет говорить "Ну, мы оплатим через месяц. А может не оплатим, хз". Так бизнес не ведут %).
Четкие договоренности - скоуп-срок-оплата - это крауегольный камень заказной разработки. Если вендор его не выдерживает - пора искать другого вендора.
P.S. Задача вендора и его менеджеров - рассчитывать различными методами потенциальную будущую нагрузку с учетом "влетов", появления новых клиентов и держать на готове необходимое количество сотрудников. Умение вести подобные расчеты, кстати, один из ключевых навыков ПМ, если я правильно помню %)
И оценкой менджмемента как раз будет являться то, насколько точно они предсказали нагрузку.
Посмотрите на ситуацию глазами заказчика и сэйлза. Заказчику не хватает фичи в софте. Фича нужна к какому-то сроку. Например, запланирована маркетинговая активность завязанная на этой фиче. Или регуляторка. Заказчик идет к сэйлзу и говорит: "Вот тут допилите, мне надо". Заказчик ждет от вас четкий срок "КОГДА" т.к. от этого срока он будет планировать свою деятельность. Что вы предлагаете сделать сэйлзу? Сказать заказчику "Да хрен знает когда сделаем, у нас тут распланировано все на три месяца вперед, мы вас поставим в очередь и может быть сделаем. А может быть не сделаем"?. Ну, в таком случае компания закроется очень быстро.
Вендор должен либо идеально оценивать сроки и укладываться в них (что мало кому удается) либо держать команду "на подстраховке", которая может заниматься тех.долгом, ресерчами, оптимизациями и т.д., но в случае "Надо" - подключиться к кор. задачам. Как только команда "подстраховки" начинает бОльшую часть времени заниматься продуктовыми задачами вместо развития - набирается еще доп. команда.
А если кто-то считает, что тех.долг, рефакторинг и оптимизация не нужны и не приносят денег - огласите список. Общественность должна знать своих героев %)
Вероятно наниматель считает, что фрилансеров бывших не бывает. И к разработчику будут приходить вчерашние клиенты, которых нельзя бросить. И в итоге разработчик будет делать задачи по фрилансу в ущерб основному месту работы.
Крупный, не крупный - понятие относительное. 15 человек это 2, ну , максимум, 3 команды. Если у вас работа третьей команды зависит от второй, то как понять второй команде, что ей нужно кровь из-носу сделать задачи 2 и 3, а вот 4 и 5 могут подождать? Да никак.
Я не спорю, что проекты можно и вообще на телефоне делать тремя разработчиками. Но если вы презентуете свой шаблон, то, пожалуйста, определите понятие "Крупный" количеством участников/команд. На текущий момент, сорри, но шаблон не жизнеспособен - т.к. даже при наличии трех команд, как правило, возникают связи между ними. Например, если команда А не поставит ТЗ команде Б, то ВСЕ работы команды Б пойдут по... одному месту.
Надеюсь, вы доработает шаблон, ведь там осталось всего ничего %)
В шаблоне, как минимум, нет связи между задачами. Какие задачи зависят от строки 8? Если строка 8 сдвинется на две недели, то что будет? Куда уедет весь проект?
Увы, этот шаблон для простых небольших проектов без зависимостей.
Ощущение, что нейросеть писала. Во второй задаче вообще зачем добавлена группировка по дням? Достаточно сделать group by по клиенту из orders и sum(cos) с отбором по периоду.
Попробую донести ключевую мысль: нанять "плохого" разработчика гораздо хуже, чем не нанять хорошего. Это особенно важно в очень крупных компаниях, где процесс увольнения штатных сотрудников КРАЙНЕ затратен. "Сократить", "уволить по соглашению сторон" - нереально и может занимать месяцы (реальный случай в очень крупной компании - 10 месяцев длился процесс увольнения разработчика, и всё это время он почти ничего не делал). Потому что разработчик на удалёнке может контрибьютить пару плохих реквестов в день и тогда доказать по суду, что человек плохо работает, почти невозможно. "Плохие разработчики", как правило, прекрасно знают свои права и, дорвавшись до вожделенных 300к в секунду, будут держаться за своё место до последнего. А всё это время проект, на который выделен разработчик, будет страдать. При этом ставка закрыта, и взять нового человека без изменения штатного расписания не получится. Убыток на одном таком случае может достигать десятков, а то и сотен миллионов рублей.
Все компании сейчас сталкиваются с бумом "вайти" и "хакеров собеседований".
Расскажу, как это было в одной достаточно большой конторе.
Раньше у нас была возможность на каждый собес отправить опытного senior-разработчика, а сейчас поток кандидатов настолько большой, что senior-ов не хватает, хотя мы и удвоили их количество. Дело в том, что HR не может отличить по резюме дельных кандидатов от "хакеров собеседований". Потому что сейчас резюме любого джуна за небольшую плату специалисты причешут так, что он будет выглядеть минимум middle, а может, и senior. При этом в резюме нарисован релевантный опыт и нужные скиллы. Но HR работая с текстом резюме не может этого понять. И начинает гнать нашим синьорам на собеседование в 3-5-10 раз больше кандидатов. Из которых 30% оказываются "хакерами собеседований" ищущими путь к заветному месту на 300к/сек.
Далее Senior говорят - "так не пойдёт, кандидатов слишком много. Вот список скрининговых вопросов и ответов. Если кандидат не набрал хотя бы 8 баллов - не зовём". Это помогает нам ровно на месяц. Затем все вопросы утекают в сеть и "хакеры" успешно проходят скрининги. При этом по-прежнему 3 кандидатов из 10 не могут написать цикл.
И вот тут мы вывели параллельно с senior-ами несколько middle-разработчиков. Нагрузка распределилась, мидлы справлялись с собеседованиями и стало почти хорошо. Пока мы не обнаружили среди новых коллег тех самых "хакеров собеседований", которые "хакнули" собеседующих мидлов. После детального анализа и разбора стало понятно, что в лучшем случае двое из них являются джунами, а один и вовсе стажёр. При этом на собесах они показали отличные знания.
Так вот - из-за этих трёх деятелей два проекта факапнулись на несколько месяцев, пришлось срочно переключать разработчиков с других задач. Потери составили несколько десятков миллионов.
По итогу мы пришли к такой схеме
HR-скрининг (15 минут. Проходят 80% кандидатов)
Тех. собес с middle+ (1 час. Проходит 30% кандидатов)
Тех. собес с senior/lead (1 час. Проходят 80% кандидатов)
Собес с командой (софты, и т.д.) (30 - 60 минут, проходят 80% кандидатов)
Мы теряем качественных разработчиков из-за этого процесса? Да. Но зато мы уверены в тех, кто прошёл. Опыт с "хакерами резюме" обошёлся гораздо дороже.
Поэтому я уверен, что как только ситуация с потоком таких кандидатов улучшится, то сразу вернутся ламповые короткие встречи на полчаса с обсуждением опыта кандидата. Но скорее количество этапов будет расти и дальше, ведь "хакеры" совершенствуются - под дипфейками собеседования проходят реальные senior, а выходит джун и другие трюки. Как с ними бороться - покажет время.
Почитал с удовольствием :)
Прикольно, но имхо — человек не очень разбирается, про что пишет.
Рейтинг MW или UL это оценка юзабилити, которая нужна НЕ клиенту (для выбора банка или чего-то еще). Обычные люди не являются ЦА таких рейтингов. Этот рейтинг, внезапно, для правления банков и топ-меджемента. Рейтинг, по сути, является тем, что в других компаниях называют аудитом. Т.е. условно говоря, верхушка может оценить насколько удобно наше приложение для обычных клиентов именно по этим рейтингам (де-юре и де-факто эти агенства независимые).
Второе, «Итого, выходит 140 человек, которым надо заплатить за участие в исследовании. Прикинем самый простой и дешевый сценарий, по 5000 рублей за респондента, и получим неиллюзорные 700 000 рублей. Минимум, да. Обычно же эта цифра приближается к 1 400 000. Впору бы своё рекрут-агентство открыть :)» Не так и много для таких агенств. На самом деле тратят на респондентов сильно больше. Они на зарплату сотрудникам в месяц больше тратят. А крупное исследование проводят раз-два в год. Т.е. вообще не аргумент. Они проводят «частные» исследования которые стоят ГОРАЗДО дороже.
Третье, «Так мобильные приложения стали скатываться к тому чтобы запихнуть в себя всё, чтобы соответствовать рейтингу, а не не то, что нужно пользователю. Ну вот как двойная камера у Яндекс.Телефона. Она-то есть, но, говорят, не работает. Но есть. » — слабое знакомство с методиками оценки. Если есть ненужная фича (например, аналог whatsapp в сбере), то она дает мало баллов. Зато если окно чата будет закрывать основной функционал, то приложение получит мало баллов в другой оценке. И суммарно приложение может получить меньше баллов с доп.фичей чем без неё. А уж за «криво» сделанные фичи оценку режут только так, никто не оценивает «есть-нет».
Четвертое — много текста в стиле «Если делать некачественные исследования, то результаты будут некачественными, а если делать хорошие исследования, то результаты будут хорошими». Дальше ожидалось увидеть что-то типа «Наша компания делает хорошие исследования, а другие — плохие!»
И в общем-то дальше это подтверждается: «Мы думали, что зарегать счета во всех исследуемых банках и завести деньги на них будет довольно быстрой задачей.»
Т.е. они попробовали сами провести исследование и поняли, что, это блин, не так просто. А раз у них не получилось, значит UL и MW тоже не смогут сделать качественно?
ИМХО, данный пост написан от лица компании, которая то ли хочет влезть на рынок UX исследований, то ли пыталась, но не получилось.
Зачем вы вообще ему что-то доказываете? С вами человек говорит с позиции ребенка, а вы ему пытаетесь логикой что-то рассказать. Уверен, что до "совместного бюджета" нужно дорасти ментально, ваш оппонент пока не дорос и не готов воспринимать такую, казалось бы, базу здоровых отношений.
Потому что у нас не Штаты, а Россия — тут даже на испытательном сроке нельзя просто взять и выгнать человека. По ТК (статья 71, если точнее) нужно оформлять увольнение по всем правилам: документально фиксировать несоответствие, собирать доказательства, ждать проверок. А любой адекватный кандидат с юрподдержкой (а такие как раз и прорываются) заставит выплатить минимум три оклада, да ещё и через суд восстановится, если ты косяков в бумагах допустишь. Так что 'попробовать на работе' — это не пять дней, а месяц геморроя с риском остаться и без сотрудника, и без денег.
Прилетает сотня резюме — все одинаково красивые, все по шаблону 'идеальный кандидат'. А когда начинаешь копать — 80 просто нагло врут, 15 что-то умеют, но тоже приукрасили, и только пятеро более-менее честные. И теперь попробуй найди этих пятерых... или хотя бы тех пятнадцать! А ведь по бумагам-то они все на одно лицо — ChatGPT научил, как надо. Вот и приходится устраивать трехэтапные (минимум) собесы, потому что иначе никак не отфильтровать, кто там реально может работать, а кто просто резюме хорошо оформляет. Ах да, там еще среди 80 есть 5-10 человек которые еще натренились проходить собеседования. Кодить не умеют, но собесы и вопросы задрочили. Обычно от таких мы чаще всего слышим "Зачем литкод на собесе? Я же сказал, что все знаю и умею, а джентльмены верят другу другу".
Поток огромный — значит, делаем классическую пирамиду: сначала HR гоняет 500 дешёвых скрининговых звонков, потом мидлы мучают 50 средних по стоимости собесов, и только потом синьор, зажмурившись, тратит время на 5 «избранных».
А альтернатива-то какая? Чтобы этот самый синьор сам нырял в эти 500 резюме? Ну тогда он не код писать будет, а только собесы давать. Так что да, компания «побегала» в три этапа — зато синьор хотя бы не сгорел на первом же круге ада.
Попробуйте разместить такую вакансию — с хорошей зарплатой и условиями. И вот они, 500+ идеальных резюме: всё по пунктам, как в вашем списке. Правда, когда начнёте собесить, выяснится, что реально соответствуют — ну может, процентов десять. Остальные просто научились красиво копировать шаблоны и загонять их в LLM
Наоборот - жесткие дедлайны ДОЛЖНЫ занимать ВЕСЬ скоуп. Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет.
Поэтому, наоборот - весь скоуп должен быть ЖЕСТКО прибит к срокам. И вендор должен обспечить необходимое количество разработчиков, чтобы выполнять взятые на себя обязательства. С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем". В этом случае заказчик сразу начинает искать другого вендора.
Иначе и в случае оплаты заказчик будет говорить "Ну, мы оплатим через месяц. А может не оплатим, хз". Так бизнес не ведут %).
Четкие договоренности - скоуп-срок-оплата - это крауегольный камень заказной разработки. Если вендор его не выдерживает - пора искать другого вендора.
P.S. Задача вендора и его менеджеров - рассчитывать различными методами потенциальную будущую нагрузку с учетом "влетов", появления новых клиентов и держать на готове необходимое количество сотрудников. Умение вести подобные расчеты, кстати, один из ключевых навыков ПМ, если я правильно помню %)
И оценкой менджмемента как раз будет являться то, насколько точно они предсказали нагрузку.
Посмотрите на ситуацию глазами заказчика и сэйлза. Заказчику не хватает фичи в софте. Фича нужна к какому-то сроку. Например, запланирована маркетинговая активность завязанная на этой фиче. Или регуляторка.
Заказчик идет к сэйлзу и говорит: "Вот тут допилите, мне надо". Заказчик ждет от вас четкий срок "КОГДА" т.к. от этого срока он будет планировать свою деятельность.
Что вы предлагаете сделать сэйлзу? Сказать заказчику "Да хрен знает когда сделаем, у нас тут распланировано все на три месяца вперед, мы вас поставим в очередь и может быть сделаем. А может быть не сделаем"?. Ну, в таком случае компания закроется очень быстро.
Вендор должен либо идеально оценивать сроки и укладываться в них (что мало кому удается) либо держать команду "на подстраховке", которая может заниматься тех.долгом, ресерчами, оптимизациями и т.д., но в случае "Надо" - подключиться к кор. задачам. Как только команда "подстраховки" начинает бОльшую часть времени заниматься продуктовыми задачами вместо развития - набирается еще доп. команда.
А если кто-то считает, что тех.долг, рефакторинг и оптимизация не нужны и не приносят денег - огласите список. Общественность должна знать своих героев %)
Вероятно наниматель считает, что фрилансеров бывших не бывает. И к разработчику будут приходить вчерашние клиенты, которых нельзя бросить. И в итоге разработчик будет делать задачи по фрилансу в ущерб основному месту работы.
66 лет - проблема для корректировки зрения?
Всё так, отличная статья и примеры. Можно показывать в качестве учебного пособия.
Крупный, не крупный - понятие относительное. 15 человек это 2, ну , максимум, 3 команды. Если у вас работа третьей команды зависит от второй, то как понять второй команде, что ей нужно кровь из-носу сделать задачи 2 и 3, а вот 4 и 5 могут подождать? Да никак.
Я не спорю, что проекты можно и вообще на телефоне делать тремя разработчиками. Но если вы презентуете свой шаблон, то, пожалуйста, определите понятие "Крупный" количеством участников/команд. На текущий момент, сорри, но шаблон не жизнеспособен - т.к. даже при наличии трех команд, как правило, возникают связи между ними. Например, если команда А не поставит ТЗ команде Б, то ВСЕ работы команды Б пойдут по... одному месту.
Надеюсь, вы доработает шаблон, ведь там осталось всего ничего %)
В шаблоне, как минимум, нет связи между задачами. Какие задачи зависят от строки 8? Если строка 8 сдвинется на две недели, то что будет? Куда уедет весь проект?
Увы, этот шаблон для простых небольших проектов без зависимостей.
Ощущение, что нейросеть писала. Во второй задаче вообще зачем добавлена группировка по дням? Достаточно сделать group by по клиенту из orders и sum(cos) с отбором по периоду.
Попробую донести ключевую мысль: нанять "плохого" разработчика гораздо хуже, чем не нанять хорошего. Это особенно важно в очень крупных компаниях, где процесс увольнения штатных сотрудников КРАЙНЕ затратен. "Сократить", "уволить по соглашению сторон" - нереально и может занимать месяцы (реальный случай в очень крупной компании - 10 месяцев длился процесс увольнения разработчика, и всё это время он почти ничего не делал). Потому что разработчик на удалёнке может контрибьютить пару плохих реквестов в день и тогда доказать по суду, что человек плохо работает, почти невозможно. "Плохие разработчики", как правило, прекрасно знают свои права и, дорвавшись до вожделенных 300к в секунду, будут держаться за своё место до последнего. А всё это время проект, на который выделен разработчик, будет страдать. При этом ставка закрыта, и взять нового человека без изменения штатного расписания не получится. Убыток на одном таком случае может достигать десятков, а то и сотен миллионов рублей.
Все компании сейчас сталкиваются с бумом "вайти" и "хакеров собеседований".
Расскажу, как это было в одной достаточно большой конторе.
Раньше у нас была возможность на каждый собес отправить опытного senior-разработчика, а сейчас поток кандидатов настолько большой, что senior-ов не хватает, хотя мы и удвоили их количество. Дело в том, что HR не может отличить по резюме дельных кандидатов от "хакеров собеседований". Потому что сейчас резюме любого джуна за небольшую плату специалисты причешут так, что он будет выглядеть минимум middle, а может, и senior. При этом в резюме нарисован релевантный опыт и нужные скиллы. Но HR работая с текстом резюме не может этого понять. И начинает гнать нашим синьорам на собеседование в 3-5-10 раз больше кандидатов. Из которых 30% оказываются "хакерами собеседований" ищущими путь к заветному месту на 300к/сек.
Далее Senior говорят - "так не пойдёт, кандидатов слишком много. Вот список скрининговых вопросов и ответов. Если кандидат не набрал хотя бы 8 баллов - не зовём". Это помогает нам ровно на месяц. Затем все вопросы утекают в сеть и "хакеры" успешно проходят скрининги. При этом по-прежнему 3 кандидатов из 10 не могут написать цикл.
И вот тут мы вывели параллельно с senior-ами несколько middle-разработчиков. Нагрузка распределилась, мидлы справлялись с собеседованиями и стало почти хорошо. Пока мы не обнаружили среди новых коллег тех самых "хакеров собеседований", которые "хакнули" собеседующих мидлов. После детального анализа и разбора стало понятно, что в лучшем случае двое из них являются джунами, а один и вовсе стажёр. При этом на собесах они показали отличные знания.
Так вот - из-за этих трёх деятелей два проекта факапнулись на несколько месяцев, пришлось срочно переключать разработчиков с других задач. Потери составили несколько десятков миллионов.
По итогу мы пришли к такой схеме
HR-скрининг (15 минут. Проходят 80% кандидатов)
Тех. собес с middle+ (1 час. Проходит 30% кандидатов)
Тех. собес с senior/lead (1 час. Проходят 80% кандидатов)
Собес с командой (софты, и т.д.) (30 - 60 минут, проходят 80% кандидатов)
Мы теряем качественных разработчиков из-за этого процесса? Да. Но зато мы уверены в тех, кто прошёл. Опыт с "хакерами резюме" обошёлся гораздо дороже.
Поэтому я уверен, что как только ситуация с потоком таких кандидатов улучшится, то сразу вернутся ламповые короткие встречи на полчаса с обсуждением опыта кандидата. Но скорее количество этапов будет расти и дальше, ведь "хакеры" совершенствуются - под дипфейками собеседования проходят реальные senior, а выходит джун и другие трюки. Как с ними бороться - покажет время.
Прикольно, но имхо — человек не очень разбирается, про что пишет.
Рейтинг MW или UL это оценка юзабилити, которая нужна НЕ клиенту (для выбора банка или чего-то еще). Обычные люди не являются ЦА таких рейтингов. Этот рейтинг, внезапно, для правления банков и топ-меджемента. Рейтинг, по сути, является тем, что в других компаниях называют аудитом. Т.е. условно говоря, верхушка может оценить насколько удобно наше приложение для обычных клиентов именно по этим рейтингам (де-юре и де-факто эти агенства независимые).
Второе, «Итого, выходит 140 человек, которым надо заплатить за участие в исследовании. Прикинем самый простой и дешевый сценарий, по 5000 рублей за респондента, и получим неиллюзорные 700 000 рублей. Минимум, да. Обычно же эта цифра приближается к 1 400 000. Впору бы своё рекрут-агентство открыть :)» Не так и много для таких агенств. На самом деле тратят на респондентов сильно больше. Они на зарплату сотрудникам в месяц больше тратят. А крупное исследование проводят раз-два в год. Т.е. вообще не аргумент. Они проводят «частные» исследования которые стоят ГОРАЗДО дороже.
Третье, «Так мобильные приложения стали скатываться к тому чтобы запихнуть в себя всё, чтобы соответствовать рейтингу, а не не то, что нужно пользователю. Ну вот как двойная камера у Яндекс.Телефона. Она-то есть, но, говорят, не работает. Но есть. » — слабое знакомство с методиками оценки. Если есть ненужная фича (например, аналог whatsapp в сбере), то она дает мало баллов. Зато если окно чата будет закрывать основной функционал, то приложение получит мало баллов в другой оценке. И суммарно приложение может получить меньше баллов с доп.фичей чем без неё. А уж за «криво» сделанные фичи оценку режут только так, никто не оценивает «есть-нет».
Четвертое — много текста в стиле «Если делать некачественные исследования, то результаты будут некачественными, а если делать хорошие исследования, то результаты будут хорошими». Дальше ожидалось увидеть что-то типа «Наша компания делает хорошие исследования, а другие — плохие!»
И в общем-то дальше это подтверждается: «Мы думали, что зарегать счета во всех исследуемых банках и завести деньги на них будет довольно быстрой задачей.»
Т.е. они попробовали сами провести исследование и поняли, что, это блин, не так просто. А раз у них не получилось, значит UL и MW тоже не смогут сделать качественно?
ИМХО, данный пост написан от лица компании, которая то ли хочет влезть на рынок UX исследований, то ли пыталась, но не получилось.