Это бизнес и его риски. Надо править — наняли студента за пол батона или подрядчика за много денег. Исправили — отправили всех отдыхать на рынок дальше. Поэтому у понимающих бизнес прибыльный. А мечтатели, минусующие за ответы, которые им не нравятся, получат инфаркт в 35 лет ибо ночь темна и полна ужасов.
Сейчас рынок кандидатов другой. Падение средней квалификации при росте хотелок. И вопросы у них всегда одинаковые: «Сколько я буду получать? Будете ли вы меня развивать через конференции и командировки? И смогу ли я завтра набрать себе команду из 10 человек?» Там никто не спрашивает про архитектуру, решения и тд.
Поэтому на рынке и появляется все больше фреймворков и языков упрощающих жизнь, чтобы в любой момент можно было снять обезьяну с дерева, запилить заплатку и не отстрелить себе ногу.
Это нормально. Разработку могут делать 20 человек, а на поддержку оставят 5. Там нет сил дизайн переделывать. Просто надо догнивать потиху. Жизненный цикл программных продуктов.
Ожидаемая реакция. Со стороны это часто может казаться правдой. Однако:
1. Через год молокозавр говорит, что ему надо отредизайнить уже его код. Через 3 приходит новый молокозавр и хаит код предыдущего ничуть не меньше остального легаси.
2. На самом деле есть вселенские законы и механизмы почему так происходит. Вам никогда не приходило в голову, что еще НИКТО не видел легаси с идеальным дизайном. Неужели все эти годы программировали одни ушлепки? Просто это физика, почему любой код через 3 года превращается в тыкву. И тогда ты осознаешь, что «работает — не трогай» вполне правильный принцип. «Трогаешь — следуй стилю модуля» вторая заповедь достойная каменной скрижали.
Для большинства компаний это не работает:
1. Как вы сказали — время. Надо просмотреть много кандидатов. После 2х часов человек обычно уже измотан и все равно не сможет адекватно отвечать.
2. Вопросы обычно еле помещаются в часовое интервью (идеал по времени). А значит отвечать времени просто нету.
3. Мы компания которая пишет бинарные деревья. Вот мы и спрашиваем про них. Заодно показываем чем вы будете заниматься. Нам не интересны ваши успехи в искусственном интеллекте(косвенно) и если мы ответим вам, что понятия не имеем как он строится — что это даст нам обоим?
4. По стандартам в интервью уже есть место для «Может у вас к нам какие-то вопросы?». И возможно экспромт скажет больше, чем подготовка вопросов по гугл.
5. Интервью обычно оценивается менеджером. Разработчик там только для создания фона из вопросов. Менеджер всегда мечтает о работнике умнее, чем уже есть. Поэтому в игре «мы все знаем лучше вас» нет смысла по определению. Мы вас набираем решить наши проблемы, а не пипками меряться.
6. Вы в институте пробовали спросить профессора, а он точно знает доказательство теоремы Х? Вы же оба ученые, что же вам не поговорить. Стандартная печаль последних лет — это 23 летний молокозавр, который рассказывает ветеранам, что вчера он прочитал в книжке, что у нас дизайн не по феншую.
7. Да, здорово, когда люди работают душа в душу. Но так не всегда получается. И вас нанимают делать работу, а не обсуждать интервью Дудя на кухне с коллегами. Вот таск, время и веслы. Может у нас зарплата высокая именно потому, что придется общаться с трудными, глупыми людьми.
8. В вакансии надо писать список технологий которые требуется. Тогда не придется дополнительно что-то передавать через HR.
Доклад в целом хороший и правильный. Отражает состояние рынка. Надо подумать о добавлении тепла в вакансию. ))
Ну и прикольно, как обычные жалобы от HR подаются с заголовком "ты же важный тимлид". Вторая половина больше похожа на "10 ошибок современного тимлида", чем на изучение роли тимлида. Или это роль "Тормоз в найме"? Обидно.))
Интересно, когда HR агенства додумаются создавать школы тестировщиков и фронтендеров, оформленные как работа в фирме. И на выходе толпа людей с годом опыта в фуллстеке и ТД, вместо пекарей и электриков. У нас в тестировании работает паразитолог. )) Но мы бы его не взяли, если бы кто то не доверил ему мобилки тестировать за год до нас.
Красиво. А что по деньгам поддержки? За облако надо каждый месяц платить. В DD дисков докупить чтобы основное производство не стало. Порядок интересен. Стало дороже или нет и на сколько.
А в книгах что, опыт перестали передавать? Читайте, развивайся. Вот если вы обоснуете почему какую то книгу не стоит читать, вот тогда ваш комментарий засияет смыслом. (Я вот пришел опытные комментарии читать) Без обид, но пост нормальный. Лучше тучи маркетинговых блогов от компаний.
последующие шаги?
1. Unit test by Developer. (пока не работает — все отдыхают)
2. Ревью кода предусматривает проверку логики. Если есть продукт-овнер, который это делает быстрее разработчиков — пускайте вперед. Если он один на всех и занят — пускайте разработчиков соседей. Или тим-лида. Чистая логика: если работает не так — какая мне разница красивый ли там код.
3. Тестировщики максимально в конце. Желательно набор авто-тестов до того как людей дергать. Маленькая команда, тим лид глупый. Сделали мини ревью(формат только) — и пусть тестировщики разбираются работает или нет.
Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях. Документация ниже плинтуса? Раздражает? Введите стадию «Document update» и тд. Делаете код ревью в гите и не бывает такого, что ревью не сделано — можно вообще выкинуть стадию «On review» в Jira.
Просто попытайтесь проникнуться идеей. Чем больше задач делегированно или автоматизированно — тем больше у руководителя времени вырасти из менеджера- сортировщика в лидера, который думает о развитии продукта и мотивации персонала. Всегда можно найти работника сортировщика, который будет это делать на «достаточно» хорошем уровне и будет рад, что он уже как бы мини-менеджер.
«У нас принято выставлять задаче due date в момент» — положено-ешь, не положено — не ешь. Не знаешь дату — декомпозируй. Знаешь — пиши, работай.
Там еще «разработчик присутствует на рабочем месте». Если мержится и работает — зачем вам разработчик? Не работает — выкинули и встретимся по приходу из отпуска.
Что такое «On Production — Ok» ?? А если не ОК? Где стрелка отката назад? Подозреваю, что востановят прод из бекапа и он всегда будет снова ОК. Значит статус не нужен. Запустился, не упал за 10 мин — Closed. Упадет — новый тикет и root cause. Или ставьте Closed через 2 недели. Вы все равно НЕ ЗНАЕТЕ ок или не ок, пока две недели не пройдет. Зачем лишний статус?
Слишком много думаете о автоматизации и мало о процессе.
Сходу:
— Open это и есть беклог. Не нужен никакой отдельный беклог. Ассайнить тикеты никто не мешает.
— Лидера уволить и научить разработчиков самим брать тикеты. Когда лидер болеет, работа стоит?
— декомпозиция есть, а стадии нет? Ничего не создаём сложнее кнопки на экране? Спеки не создаём? Как вообще понять, что разработчик уже декомпозирует, а не тикет просто лежит в беклог? (Я знаю. Важный лидер за спинами ходит.)
— Сделать Due Date просто обязательным полем и выкинуть скрипт.
С уверенностью скажу за Яндекс.Маркет. И наверняка у вас тоже самое ибо процесс к этому склоняет. Вам кажется, что у вас идет рациональное обсуждение на митинге ПМ-ов, а по факту ресурсы получает тот, кто больше всех ноет. Тихий ПМ — мертвый ПМ.
Это вопрос уровня… А что делать если надо оттестировать то на что нет спецификации? А что делать если разработчик говорит, что фиксить баг не будет? А что делать, если ПМ говорит, что молодец Вася, хотя ты нашел багов в два раза больше и сделал больше релизов?
Эти вопросы не должны возникать в нормальных процессах. Смекалка — это как протестировать одним тестом два тест кейса. Или какие выбрать тесты из 2000, так как времени есть только на 400.
Вы тестируете выживет ли человек в вашей среде. Вместо того, чтобы сесть и один раз подумать, что изменить в процессах, чтобы такого просто не могло быть.
«Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»
Это по моему только в Яндексе толпа ПМ орет друг на друга кому достанется тестеровщик, просит поработать в обед и сделать все быстрее, чем обычно. Вместо того, чтобы выбрать одного ПМ решающего приоритет работ, планировать когда и что и наконец просто нанять тестеровщик сколько положено.
Ну и обязательно задать вопрос на интервью как выбраться из #опы, которую сами и придумали.
Именно! Несмотря на то, что у нас 2 копии базы, мы не хотим чтобы записи менялись одновременно на 2х сайтах. И один сайт думал что у Васи 100 руб, а другой 200. Это не особенность приложения. Это бизнес задача (требование). Будь хоть 100 узлов, работать будет как бы один, минус блокировки других узлов. В вашей табличке указано среднее время с учетом удвоения мощности и наличия фаз не требующих блокировок. И так как фазы не требующие блокировок в 6 раз более ресурсоёмкие, то и снижения среднего времени вы получаете за счет них. При этом я уверен что среднее время в пределах одного узла растет.
Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.
Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
Слово «критическая» не совсем подходит, ок. Просто скажите мне, почему в второй фазе при соединении кластера время растет в 2 раза, в отличии от других фаз?
Так, то есть мы имеем 3 фазы. 1я и 3я не требуют кластера и могут выполняться асинхронно. Синхронная 2я фаза увеличивает время в 2 раза даже на расстоянии 0. И весь выигрыш мы получаем только из за того, что время обработки 1й и 3й фазы в пять раз выше критической 2й. И их(1 и 3) можно накопить для обработки позже. Если бы рассматривали «карточный процессинг» то результаты были бы гораздо плачевнее, так как там нет отложенных и асинхронных транзакций.
>> Обмен данными между CF и подключенными системами организуется по принципу «память-память» (похоже на DMA), при этом процессоры, на которых работают приложения, не задействуются.
Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.
Сейчас рынок кандидатов другой. Падение средней квалификации при росте хотелок. И вопросы у них всегда одинаковые: «Сколько я буду получать? Будете ли вы меня развивать через конференции и командировки? И смогу ли я завтра набрать себе команду из 10 человек?» Там никто не спрашивает про архитектуру, решения и тд.
Поэтому на рынке и появляется все больше фреймворков и языков упрощающих жизнь, чтобы в любой момент можно было снять обезьяну с дерева, запилить заплатку и не отстрелить себе ногу.
Это нормально. Разработку могут делать 20 человек, а на поддержку оставят 5. Там нет сил дизайн переделывать. Просто надо догнивать потиху. Жизненный цикл программных продуктов.
1. Через год молокозавр говорит, что ему надо отредизайнить уже его код. Через 3 приходит новый молокозавр и хаит код предыдущего ничуть не меньше остального легаси.
2. На самом деле есть вселенские законы и механизмы почему так происходит. Вам никогда не приходило в голову, что еще НИКТО не видел легаси с идеальным дизайном. Неужели все эти годы программировали одни ушлепки? Просто это физика, почему любой код через 3 года превращается в тыкву. И тогда ты осознаешь, что «работает — не трогай» вполне правильный принцип. «Трогаешь — следуй стилю модуля» вторая заповедь достойная каменной скрижали.
1. Как вы сказали — время. Надо просмотреть много кандидатов. После 2х часов человек обычно уже измотан и все равно не сможет адекватно отвечать.
2. Вопросы обычно еле помещаются в часовое интервью (идеал по времени). А значит отвечать времени просто нету.
3. Мы компания которая пишет бинарные деревья. Вот мы и спрашиваем про них. Заодно показываем чем вы будете заниматься. Нам не интересны ваши успехи в искусственном интеллекте(косвенно) и если мы ответим вам, что понятия не имеем как он строится — что это даст нам обоим?
4. По стандартам в интервью уже есть место для «Может у вас к нам какие-то вопросы?». И возможно экспромт скажет больше, чем подготовка вопросов по гугл.
5. Интервью обычно оценивается менеджером. Разработчик там только для создания фона из вопросов. Менеджер всегда мечтает о работнике умнее, чем уже есть. Поэтому в игре «мы все знаем лучше вас» нет смысла по определению. Мы вас набираем решить наши проблемы, а не пипками меряться.
6. Вы в институте пробовали спросить профессора, а он точно знает доказательство теоремы Х? Вы же оба ученые, что же вам не поговорить. Стандартная печаль последних лет — это 23 летний молокозавр, который рассказывает ветеранам, что вчера он прочитал в книжке, что у нас дизайн не по феншую.
7. Да, здорово, когда люди работают душа в душу. Но так не всегда получается. И вас нанимают делать работу, а не обсуждать интервью Дудя на кухне с коллегами. Вот таск, время и веслы. Может у нас зарплата высокая именно потому, что придется общаться с трудными, глупыми людьми.
8. В вакансии надо писать список технологий которые требуется. Тогда не придется дополнительно что-то передавать через HR.
Доклад в целом хороший и правильный. Отражает состояние рынка. Надо подумать о добавлении тепла в вакансию. ))
Ну и прикольно, как обычные жалобы от HR подаются с заголовком "ты же важный тимлид". Вторая половина больше похожа на "10 ошибок современного тимлида", чем на изучение роли тимлида. Или это роль "Тормоз в найме"? Обидно.))
Интересно, когда HR агенства додумаются создавать школы тестировщиков и фронтендеров, оформленные как работа в фирме. И на выходе толпа людей с годом опыта в фуллстеке и ТД, вместо пекарей и электриков. У нас в тестировании работает паразитолог. )) Но мы бы его не взяли, если бы кто то не доверил ему мобилки тестировать за год до нас.
Пока одни жалуются, другие уже вовсю продают симулятор кота в Стиме.
Красиво. А что по деньгам поддержки? За облако надо каждый месяц платить. В DD дисков докупить чтобы основное производство не стало. Порядок интересен. Стало дороже или нет и на сколько.
А в книгах что, опыт перестали передавать? Читайте, развивайся. Вот если вы обоснуете почему какую то книгу не стоит читать, вот тогда ваш комментарий засияет смыслом. (Я вот пришел опытные комментарии читать) Без обид, но пост нормальный. Лучше тучи маркетинговых блогов от компаний.
Plugin portfolio for Jira ?
1. Unit test by Developer. (пока не работает — все отдыхают)
2. Ревью кода предусматривает проверку логики. Если есть продукт-овнер, который это делает быстрее разработчиков — пускайте вперед. Если он один на всех и занят — пускайте разработчиков соседей. Или тим-лида. Чистая логика: если работает не так — какая мне разница красивый ли там код.
3. Тестировщики максимально в конце. Желательно набор авто-тестов до того как людей дергать. Маленькая команда, тим лид глупый. Сделали мини ревью(формат только) — и пусть тестировщики разбираются работает или нет.
Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях. Документация ниже плинтуса? Раздражает? Введите стадию «Document update» и тд. Делаете код ревью в гите и не бывает такого, что ревью не сделано — можно вообще выкинуть стадию «On review» в Jira.
«У нас принято выставлять задаче due date в момент» — положено-ешь, не положено — не ешь. Не знаешь дату — декомпозируй. Знаешь — пиши, работай.
Там еще «разработчик присутствует на рабочем месте». Если мержится и работает — зачем вам разработчик? Не работает — выкинули и встретимся по приходу из отпуска.
Что такое «On Production — Ok» ?? А если не ОК? Где стрелка отката назад? Подозреваю, что востановят прод из бекапа и он всегда будет снова ОК. Значит статус не нужен. Запустился, не упал за 10 мин — Closed. Упадет — новый тикет и root cause. Или ставьте Closed через 2 недели. Вы все равно НЕ ЗНАЕТЕ ок или не ок, пока две недели не пройдет. Зачем лишний статус?
Сходу:
— Open это и есть беклог. Не нужен никакой отдельный беклог. Ассайнить тикеты никто не мешает.
— Лидера уволить и научить разработчиков самим брать тикеты. Когда лидер болеет, работа стоит?
— декомпозиция есть, а стадии нет? Ничего не создаём сложнее кнопки на экране? Спеки не создаём? Как вообще понять, что разработчик уже декомпозирует, а не тикет просто лежит в беклог? (Я знаю. Важный лидер за спинами ходит.)
— Сделать Due Date просто обязательным полем и выкинуть скрипт.
Это вопрос уровня… А что делать если надо оттестировать то на что нет спецификации? А что делать если разработчик говорит, что фиксить баг не будет? А что делать, если ПМ говорит, что молодец Вася, хотя ты нашел багов в два раза больше и сделал больше релизов?
Эти вопросы не должны возникать в нормальных процессах. Смекалка — это как протестировать одним тестом два тест кейса. Или какие выбрать тесты из 2000, так как времени есть только на 400.
Вы тестируете выживет ли человек в вашей среде. Вместо того, чтобы сесть и один раз подумать, что изменить в процессах, чтобы такого просто не могло быть.
«Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»
Это по моему только в Яндексе толпа ПМ орет друг на друга кому достанется тестеровщик, просит поработать в обед и сделать все быстрее, чем обычно. Вместо того, чтобы выбрать одного ПМ решающего приоритет работ, планировать когда и что и наконец просто нанять тестеровщик сколько положено.
Ну и обязательно задать вопрос на интервью как выбраться из #опы, которую сами и придумали.
Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.
Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.