Крупный, не крупный - понятие относительное. 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 исследований, то ли пыталась, но не получилось.
Крупный, не крупный - понятие относительное. 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 исследований, то ли пыталась, но не получилось.