Согласен с тем, что люди нанимают больше тех, кто им симпатичен больше на уровне подсознания, даже если пытаются отрицать. Егор об этом и говорит, что чтобы снизить влияние эмоций при найме, необходимо использовать метрики. И метрики у каждого работодателя могут быть свои, Егор же привел в пример свои собственные.
медийный программист очень успешно работал на свой медийный образ
У этой палки тоже два конца. С одной стороны, медийный программист прокачивает свой личный бренд, но с другой, когда он выступает от лица работодателя на конференции, он прокачивает и бренд компании в том числе: он показывает, что в компании обращают внимание на конференции, что в ней работают такие специалисты, способные рассказать о чем-то новом и поделиться знаниями. И некоторые программисты-слушатели вполне могут захотеть попасть в такие компании.
В конечном итоге выигрывают все: и сам программист прокачивает свой медийный образ, и компания, которая получает увеличение своей медийности и увеличение потока кандидатов при минимальных вложениях.
Какой на ваш взгляд туллинг на test coverage юнит тестов хорош?
Пока что я не занимался настройкой графиков покрытия тестами, однако есть в планах настроить репозиторий так, чтобы при агенты пайплайнов сканировал test coverage проекта, и если он стал ниже определенного уровня, то пайплайн фейлился
Была идея запускать прогон тестов бэкенда тоже, однако решил отказаться от нее по нескольким причинам:
Чем больше проект, тем больше тестов, а значит и больше времени на пуши. К тому же, в своей работе я следую принципу "много тестов не бывает" и других постоянно убеждаю.
Когда рефакторим крупные куски кода, то часто бывает так, что разраб коммит и пушит нерабочий код в свою ветку намеренно, чтобы сохранить проделанную работу.
Держать в течение нескольких дней отрефаченный код без возможности его запушить — рискованно тоже по нескольким причинам:
Бас-фактор конкретного исполнителя. Никто не сможет подхватить ветку за него.
Никто не сможет помочь с рефакторингом параллельно, стянув код с его ветки.
Статья действительно не о тестах, а о том, как подготовить репозиторий для команды, чтобы она стала писать код в одном стиле без просьб и пряников с кнутами. Сама система не даёт написать нестандартный код.
А юниттесты — понятное дело, тоже нужны, и об этом написано много. В том числе и поэтому касаться этого я не стал в статье
Изложение похоже на то, как мог бы сказать Егор Бугаенко. Как и у него, в этой статье есть интересные мысли, но категоричность может оттолкнуть некоторых людей, а других наоброт — увлечь, ведь написано емко.
На проекте видел ситуации, когда действительно применялись только следования инструкциям без экспериментов, которые и могли бы привести к улучшениям. И при этом, когда говоришь «а давайте попробуем… и ...», в ответ слышишь «не, сейчас нет времени, дэдлайны горят». Только вот беда в том, что дедлайны всегда будут гореть, и нет в мире ни одного заказчика, который бы сказал «ну да, поэкспериментируйте со своими процессами, а я подожду пару месяцев». А если удается убедить в необходимости улучшений, то тимлид затевает нечто вроде «Big Bang Refactoring» большинства процессов и не особо желает пробовать по чуть-чуть.
С канбаном примерно то же самое происходит. Действительно, прочесть скрам-гайд на 25 страниц гораздо проще, чем понять, почему те или иные артефактфы и мероприятия вообще рекомендуют авторы.
Банк Kaspi тоже ведет себя как IT-стартап по большей части: быстро запускает какие-то технологические сервисы/продукты, смотрит на фидбек и рефакторит, если взлетело. Работая там, увидел все отличительные особенности стартапа, как положительные, так и отрицательные.
Прочел коммент по ссылке. Хм, решение довольно спорное, но если с точки зрения бизнеса статистика не нужна, да и учитывая расходы на хранение данных — вполне подходящее. Спасибо за ответ
Интересный рассказ об опыте внедрения. Как бывший работник того самого банка-партнера, боюсь представить, с какими требованиями к безопасности вы сталкивались и, тем более, с какими интеграционными процессами, включая митинги =) Договориться об интеграциях различных разделов сайта было не так легко, что уж говорить про интеграции между двумя компаниями
Когда человек выставляет свое авто на автокредит, то он проходит околообязательную техническую проверку на СТО-партнере. СТОшникам смысла искажать данные нет — банк больше денег дает, а покупатели уверены в техсостоянии. Бизнеспроцесс хорошо выстроен
Получается, у вас к каждому объявлению сущность с числовым счетчиком прикручен? Тогда несколько вопросов.
Почему был выбран именно такой подход? Почему бы не инсертить каждый просмотр как новую метку с двумя полями «ДатаСоздания» и «ОбъявлениеАйди», например? Тогда можно было бы и собрать более подробную статистику по дням/часам/секундам, и проблем с целостностью можно избежать. А прежние просмотры при архивации объявления удалять с базы
Мне кажется, что value delivery и visibility из оценок в статье покрывают эти критерии. Для каждого оценивающего ведь ценность разная, и коллеги-разработчики оцениваемого разработчика как раз ориентируются на указанные вами показатели
Спасибо за развёрнутый ответ. Но возникло пара вопросов:
1) вы говорите о том, что нормально, что человек посещает собеседования, однако хотели бы знать о таких случаях. Иначе говоря, чтобы это было более менее «прозрачно», что-ли. Но разве много людей по вашему опыту приходят и говорят, что «Доброе утро, <начальник_нейм>! Кстати, у меня было собеседование в компании Н»? Мне кажется, что немногие скажут нечто подобное, да и случаев вроде как в рабочем процессе, когда бы можно было такое сказать, нет. Или все же случается такое?
2) Вы пишете, что тяжело поднять зп сотруднику, который пришёл неопытным на меньший оклад, но быстро «вырос», и теперь хочет получать больше. И.е., вы как его начальник сделали все возможное, чтобы это произошло, но повышение не утвердили. Разве офер из другой компании не является логичным действием такого сотрудника? Или это не относится к ситуации, когда «немного обидно»?
Как вы относитесь к тем сотрудникам, которые, несмотря на то, что и в команде ведут себя приветливо со всеми, и проблем не высказывают, и в целом не показывают негатив по отношению к компании, но посещают собеседования и обновляют периодически свое резюме на соответствующих ресурсах по найму? Ведь, если вы пишите, что человек приходит с офером из другой компании, значит он его как-то добился
Когда я пришел на работу на следующий день, я обсудил звонок со своим руководителем и сказал ей, что планирую принять предложение. И. Я. Получил. Предложение. О работе. От Sony. Через. Два. Дня.
Не совсем понятна мне ситуация в больших компаниях. То есть человек работал некоторое время за бесплатно, затем за копейки (относительно уровня жизни там) в течение восьми месяцев, хорошо выполнял часть проекта, на котором компания зарабатывала деньги, но только после того как у него появился оффер от другой компании, они ему сами предложили работать?
Верно, но за неимением лучшей альтернативы Егор пользуется интервью, которое проводит по собственному сценарию.
Согласен с тем, что люди нанимают больше тех, кто им симпатичен больше на уровне подсознания, даже если пытаются отрицать. Егор об этом и говорит, что чтобы снизить влияние эмоций при найме, необходимо использовать метрики. И метрики у каждого работодателя могут быть свои, Егор же привел в пример свои собственные.
У этой палки тоже два конца. С одной стороны, медийный программист прокачивает свой личный бренд, но с другой, когда он выступает от лица работодателя на конференции, он прокачивает и бренд компании в том числе: он показывает, что в компании обращают внимание на конференции, что в ней работают такие специалисты, способные рассказать о чем-то новом и поделиться знаниями. И некоторые программисты-слушатели вполне могут захотеть попасть в такие компании.
В конечном итоге выигрывают все: и сам программист прокачивает свой медийный образ, и компания, которая получает увеличение своей медийности и увеличение потока кандидатов при минимальных вложениях.
Пока что я не занимался настройкой графиков покрытия тестами, однако есть в планах настроить репозиторий так, чтобы при агенты пайплайнов сканировал test coverage проекта, и если он стал ниже определенного уровня, то пайплайн фейлился
Была идея запускать прогон тестов бэкенда тоже, однако решил отказаться от нее по нескольким причинам:
Держать в течение нескольких дней отрефаченный код без возможности его запушить — рискованно тоже по нескольким причинам:
Статья действительно не о тестах, а о том, как подготовить репозиторий для команды, чтобы она стала писать код в одном стиле без просьб и пряников с кнутами. Сама система не даёт написать нестандартный код.
А юниттесты — понятное дело, тоже нужны, и об этом написано много. В том числе и поэтому касаться этого я не стал в статье
На проекте видел ситуации, когда действительно применялись только следования инструкциям без экспериментов, которые и могли бы привести к улучшениям. И при этом, когда говоришь «а давайте попробуем… и ...», в ответ слышишь «не, сейчас нет времени, дэдлайны горят». Только вот беда в том, что дедлайны всегда будут гореть, и нет в мире ни одного заказчика, который бы сказал «ну да, поэкспериментируйте со своими процессами, а я подожду пару месяцев». А если удается убедить в необходимости улучшений, то тимлид затевает нечто вроде «Big Bang Refactoring» большинства процессов и не особо желает пробовать по чуть-чуть.
С канбаном примерно то же самое происходит. Действительно, прочесть скрам-гайд на 25 страниц гораздо проще, чем понять, почему те или иные артефактфы и мероприятия вообще рекомендуют авторы.
Почему был выбран именно такой подход? Почему бы не инсертить каждый просмотр как новую метку с двумя полями «ДатаСоздания» и «ОбъявлениеАйди», например? Тогда можно было бы и собрать более подробную статистику по дням/часам/секундам, и проблем с целостностью можно избежать. А прежние просмотры при архивации объявления удалять с базы
Спасибо за развёрнутый ответ. Но возникло пара вопросов:
1) вы говорите о том, что нормально, что человек посещает собеседования, однако хотели бы знать о таких случаях. Иначе говоря, чтобы это было более менее «прозрачно», что-ли. Но разве много людей по вашему опыту приходят и говорят, что «Доброе утро, <начальник_нейм>! Кстати, у меня было собеседование в компании Н»? Мне кажется, что немногие скажут нечто подобное, да и случаев вроде как в рабочем процессе, когда бы можно было такое сказать, нет. Или все же случается такое?
2) Вы пишете, что тяжело поднять зп сотруднику, который пришёл неопытным на меньший оклад, но быстро «вырос», и теперь хочет получать больше. И.е., вы как его начальник сделали все возможное, чтобы это произошло, но повышение не утвердили. Разве офер из другой компании не является логичным действием такого сотрудника? Или это не относится к ситуации, когда «немного обидно»?
Не совсем понятна мне ситуация в больших компаниях. То есть человек работал некоторое время за бесплатно, затем за копейки (относительно уровня жизни там) в течение восьми месяцев, хорошо выполнял часть проекта, на котором компания зарабатывала деньги, но только после того как у него появился оффер от другой компании, они ему сами предложили работать?