У вас возникал синдром «сожалений специалиста по найму»? Это когда вы жалеете о том, что наняли кого-то сразу после того, как он начал работать. Может быть, вам не нравится внешность новичка, а может вы просто желаете погрузить мир в хаос. Или, хуже того, он как-то упомянул, что любит джаз. Какой бы ни была причина, этот пост поможет вам заставить его уволиться самостоятельно, выбрав для него худший первый проект.
Не ждите, пока он обустроится
Ему всё ещё не выдали монитор? Менеджер проекта так и не добрался до него, чтобы познакомить с продуктом, над которым работает команда? Его бейдж не работает и ему приходится просить коллег провести его в туалет? Это самое подходящее время встретиться с ним и объяснить все подробности нового проекта. Есть какой-то компонент, который он пока не освоил? Сэкономьте своё время и пока не объясняйте его — пусть разберётся самостоятельно после завершения проекта.
Выберите что-нибудь большое
Это необходимый шаг. Подберите проект, в котором задействовано как можно больше компонентов. В идеале нужно, чтобы для выполнения этого проекта требовалось два-три месяца работы самого опытного сотрудника. Выбор крупного проекта гарантирует, что у новичка не будет маленьких побед и он не сможет тешить свою самооценку. Если ему удастся разбить проект на более мелкие части, вам следует донести до него, что вам важна только конечная цель, и что вас беспокоит, что он «тратит время на менеджмент проекта», вместо того, чтобы работать!
Если кто-то возражает против выбранного вами проекта, то просто скажите, что новичок должен «почувствовать ответственность».
Пусть он отвечает за то, за что отвечал человек, которого он заменил
Это увеличивает шансы на то, что проект будет неинтересным и что никто в команде не будет по-настоящему знать, что в нём творится.
Выберите что-то спорное
Если это возможно, выберите проект, против которого возражают другие. Например, кто-то недоволен направлением его технического развития; возможно, менеджер проекта и дизайнер не могут договориться насчёт UX; может быть, кто-то думает, что проект возненавидят пользователи.
Если вам удастся найти подобный спорный проект — не говорите об этом новичку! Но сделайте так, чтобы ему пришлось взаимодействовать с тем, кто против этого проекта. Бонусные очки: если противник проекта — член команды, то назначьте его ментором новичка.
Пусть он соберёт требования
Обязательно выберите неоднозначный проект, не имеющий чёткого набора требований. Опишите проект как можно менее подробно и отправьте новичка разбираться в остальном самому.
Добавьте взаимодействия между командами
Выберите проект, требующий участия максимального количества других команд. Вот список возможных способов взаимодействия между командами:
- Проект может зависеть от API, созданного другой командой, которая сейчас слишком занята (бонусные очки: позвольте новичку встретиться с другой командой одному, чтобы он рассказал о требованиях его команды). Пусть он постоянно находится в стрессе и ощущает, что никто его не страхует; он должен уяснить, что если опоздает, то разочарует кучу людей.
- Другой команде срочно может понадобиться проект вашей команды. Сообщите новичку, что другая команда разочарована тем, что задачу поручили ему. Здесь вашими друзьями будут чувство вины и низкая самооценка!
Пусть он обучает команду новой технологии
Так мы добьёмся идеального баланса: новичок и не понимает готовых инструментов, которыми все члены команды пользуются каждый день, и является единственным членом команды, знакомым с новой технологией.
Требуйте множества действий, не связанных с кодингом
Не позволяйте ему расставлять приоритеты! Сделайте так, чтобы ему приходилось делать что угодно и всё сразу:
- Пусть он организует все связанные с проектом совещания (сделайте так, чтобы ему пришлось вести записи на этих совещаниях: тогда ему не будет хватать времени слушать и понимать)
- Заставьте его проверять оптимизацию проекта: пусть занимается бенчмарками и анализирует результаты
- Пусть он разбирается во всём жизненном цикле проекта: получит одобрение юридического отдела, проверит его на безопасность и конфиденциальность и, разумеется, подготовит график запуска.
Сделайте так, чтобы проект препятствовал работе других людей
Проект не просто должен быть сложным сам по себе. Мы хотим, чтобы против новичка работали и его негативные чувства. Это можно сделать, добавив стресса и низкой самооценки. Скажите ему, что от него зависят другие люди. Бонусные очки: выражайте согласие придерживаться строгого графика от его лица, когда он находится в том же кабинете. В большинстве случаев новички цепенеют и соглашаются со всем, что вы скажете. Когда он начнёт жаловаться на слишком жёсткие сроки дедлайнов, просто напомните ему, что он мог сказать об этом вовремя!
Выберите ему в качестве ментора самого занятого члена команды
Убедитесь, что у помогающего ему много другой работы. У него должно быть множество совещаний и, возможно, скачущий график. Например, он работает удалённо или приезжает на работу в пять утра, чтобы избежать пробок. Бонусные очки: выберите того, кто скоро собирается в отпуск или командировку.
Откладывайте любые просьбы о помощи не менее чем на два рабочих дня
Большинство новичков очень долго пытается разобраться самостоятельно, прежде чем попросить о помощи. Это значит, что если вы оставите их без внимания, когда они уже просят помощи, то в процессе ожидания они гарантированно не смогут делать ничего. Это откладывает завершение проекта, вызывая стресс. К тому же, это культивирует общее чувство беспомощности и низкое самоуважение. Помните: что посеешь, то и пожнёшь, так что посейте немного несчастья!
Джун: «Можете мне помочь с этим?»
Сениор: «Прежде чем просить о помощи, попробуй разобраться сам»
*День спустя*
Сениор: «Ты потратил на это столько времени? В следующий раз, если запутаешься, проси о помощи»
Запланируйте частые синхронизационные совещания с участием высшего руководства
При правильном использовании синхронизационные совещания могут быть отличным способом развития проекта, поэтому не используйте их правильно! Начинайте ставить их в график ещё с ранних этапов проекта и включайте в них максимально возможное количество людей. Пусть высшее руководство ожидает быстрого прогресса; сообщите ему, кто за него ответственен. Нужно организовать всё так, чтобы после каждого синхронизационного совещания новичок ощущал себя неудачником и разочарованием. Донесите до него, что он должен презентовать что-то на совещании — благодаря этому он будет тратить время на подготовку к совещанию, а не на развитие проекта.
Как выбрать проект для новичка, чтобы он остался в компании
Ох, какая досада. Вам показалось, что новичок ужасно любит джаз, но позже он объяснил, что считает джаз ужасным. А его лицо уже не кажется таким отвратительным. Хм, возможно, стоит выбрать для него лучший проект?
Задачи для новичка, а не проект для новичка
Люди недооценивают сложность внесения даже малейших изменений в их кодовую базу. Вы представляете строки кода, но на самом деле всё гораздо масштабнее. Как ваша команда называет действие по внесению изменения в вашу кодовую базу? «Отправка диффа», «пуш коммита», «отправка мердж-реквеста»? Каждая команда делает это по-своему, и мы даже не используем одинаковые названия. У каждой команды своя система контроля версий, система отслеживания ошибок, система работы с тикетами, инструменты командной строки и так далее. Возможно, вы ко всему этому привыкли, но цель задач для новичка — упростить знакомство со всем этим. Для него это не должно быть игрой на выживание.
Начинайте с тривиально мелких задач. Нет, даже ещё меньше. И ещё меньше. Ещё немного меньше… отлично! Пусть исправит опечатку. Пусть изменит код для соответствия стандарту в том модуле, до которого у вас давно не доходили руки. Пусть добавит своё имя в файл
CONTRIBUTORS проекта. Это должно быть что-то, совершенно не представляющее трудностей. Процесс понимания потока разработки труден сам по себе.Затем начинайте двигаться вперёд небольшими шагами. Пусть он устранит небольшой баг. Вы должны знать, как выглядит решение, ещё до того, как дадите новичку эту задачу. Задачи новичков не должны делать ничего нового для вас. Пусть он добавит тест для одного конкретного бага. Пусть разберётся, как выполнять тесты, как проверить, что внесённые им изменения отразились в процессе непрерывной интеграции. Пусть он отследит их до продакшена. Не нужно торопиться.
Мелкие задачи — источник множества лёгких побед, и в то же время они позволяют познакомиться с вашей кодовой базой. Новичок прикоснётся ко всему. Начнёт узнавать имена компонентов, ассоциировать конкретную технологию и «стиль» с каждым из них, разберётся, где хранится его код в вашей системе контроля версий. Он получит представление о том, что и как вы делаете.
Пусть он работает над базовыми бизнес-задачами, основной целью вашей команды
У каждой команды есть задачи, на выполнение которых она наиболее оптимизирована. Команда, работающая над платформой обработки платежей, может считать одной из своих основных задач добавление нового поставщика сервиса платежей. Команда, сосредоточенная на разработке приложения для организации списка дел, может быть оптимизирована на добавление новых свойств задач и возможностей фильтров. Для команды разработчиков такого приложения не является основной задачей реализация платежей, а для разработчиков системы платежей основной задачей не является добавление возможности выбора пользователями крутых аватарок.
Пусть новичок занимается тем, что ваша команда делает часто и с чем справляется лучше всего. Благодаря этому всё, что он делает, будет значимо для проекта, а полученные навыки можно будет применять в будущих проектах. А ещё это значит, что все члены команды будут ему помогать, поэтому ему не придётся ждать, пока у конкретного человека появится свободное время.
Задачи должны быть максимально автономными
В идеальной ситуации для выполнения вводных задач новичку нужно общаться только с людьми из основной команды. Разумеется, если задача маленькая и чётко очерченная, вполне допустимо, что перед тем, как пушить её, она проверяется менеджером проекта. Но если новички ощутят чуть больше уверенности, прежде чем столкнуться с другими функциями, то эти взаимодействия окажутся для них гораздо более положительными.
Автономность также подразумевает отсутствие сложных перекрёстных зависимостей между задачами. Они не должны зависеть от чьего-то диффа, который будет готов «через два-три, или, может, через пятнадцать дней», как и никто не должен зависеть от изменений, вносимых новичком. Нет никакого смысла добавлять лишний стресс. Когда вы приходите на новую работу, стресса и так достаточно (и он обязательно добавится в дальнейшем).
Учитесь на ошибках прошлого
Спрашивайте членов команды об их опыте онбординга. Просите помощи у человека, пришедшего в команду последним, а не у самого опытного. Самый новый член команды, вероятно, лучше всего помнит свой опыт. Вероятно, он лучше знает, в каком поддерживаемом командой компоненте сложнее всего разобраться (и работы с которым поначалу стоит избегать), и о каких инструментах обязательно нужно рассказать в процессе онбординга.
Выберите ментора, но сделайте так, чтобы можно было обратиться к любому члену команды
Лучший разработчик команды — не всегда лучший кандидат на менторство новичка. Выберите того, кто любит обучать и к кому новичок сможет обращаться. Если обычно он участвует во множестве совещаний, возможно, ему следует освободить свой график на первые несколько дней после прихода новичка.
Однако одного человека недостаточно. Он может быть занят, заболеть или уйти в отпуск. Ментор и новичок просто могут не найти общий язык, и им некомфортно будет общаться. Сделайте так, чтобы новичок смог обратиться к любому члену команды, и чтобы ему было комфортно просить помощи. Это можно облегчить следующим образом:
- Пусть каждую мелкую задачу для новичка объясняет и проверяет другой член команды
- Пусть люди из команды рассказывают о вашем продукте и соответствующей ему кодовой базе
- Запланируйте на момент прихода новичка какое-то интересное мероприятие, чтобы он смог освоиться в общении со всеми
Проактивно предлагайте помощь
Как говорилось ранее, большинство новичков обычно тратит слишком много времени, прежде чем самим попросить о помощи. Опередите их, предлагая помощь проактивно. Однако это нужно делать аккуратно, потому что это тоже может вызывать стресс. Предложение помощи может подразумевать, будто вы думаете, что новичок запаздывает и что к этому моменту вы ожидали какого-то прогресса. Донесите до него, что если ему понадобится, вы всегда поможете, но не давите.
Когда вы помогаете новичку (проактивно или нет), не перенапрягайте его. Многие (обычно опытные) инженеры склонны отвечать на вопросы потоками подробной информации и длинными театральными монологами о том, как вы пришли к текущей ситуации («Это давняя история, начавшаяся ещё в те времена, когда контроль версий был причудой для богатых...»). Говорите новичку то, что он должен знать и спрашивайте, хочет ли он узнать подробности. Или позвольте ему сначала завершить мелкую задачу, потом сообщите чуть больше контекста, когда у него уже будет понимание того, что же делает компонент.
Комментарии (69)
edmus
11.08.2022 12:35+11В начале прямо мой первый проект 10 лет назад в точности описан. :) Кроме пункта про ментора. Его вообще не было. :) У меня потом долго не проходил синдром самозванца.
Staschik
12.08.2022 05:22Как выбрать для новичка такой проект, чтобы он уволился
6/12 Прямо сейчас на первом месте работы, но проект второй.
Плюс еще вот это habr.com/ru/post/681786/#comment_24619286
nmrulin
11.08.2022 13:24+1Ну вообще для джуна правильно. Но если нанимают скажем сеньора, когда в команде максимум ещё один есть, а то и никого нет? Тогда ожидается, что он как раз и будет разгребать хаос который образовался до того, как его наняли.
Ну и даже миддлу задачи будут давать сразу довольно заковыристые, как раз может такие, против введения которых протестовал сеньор, т.к. понимал возможности команды. А его и дадут в менторы миддлу, т.к. больше некого. И долго он менторстовать не будет, т.к. ожидает , что миддл не джуниор, и сам разберётся после пары наводящих подсказок.
RomeoGolf
11.08.2022 14:51+22На моей предыдущей работе почти все, описанное в первой части было нормой. И не только для новичка.
Конечно, менторов не было. И рабочее место никто не готовил. У тебя нет необходимого монитора/прибора? Пиши служебку. Не знаешь как писать и какой конкретно прибор? Спроси. Не знаешь, у кого? Спроси у кого угодно, у кого спросить. Тебе что тут, детский сад?
Задач должно быть несколько, не связанных друг с другом и вообще из разных сфер: кодинг, написание документов, желательно странных, типа заключения о технологичности, сбегать на производство просто курьером, подписать чужие документы у вышестоящего начальства, поучаствовать в настройке прибора. Приоритеты задач должны меняться неожиданно и произвольно. Исполнителю об изменении приоритета сообщать так: «Какого хрена ты все еще занимаешься фигней и почему все еще не сделана мегаважная вещь?» Через день-два повторить, изменяя «фигню» и «вещь».
Вишенка на торте — когда человек почти добирается до решения задачи, надо ее отобрать и отдать другому. И когда этот другой пройдет последние шаги и «добьется» результата, надо сделать выговор: «Вот ты не смог, а он — смог!»
И по опыту командировок и неформального общения с коллегами из предприятий смежников и заказчиков складывается ощущение, что на гос и «бывших» гос (ныне АО, ПАО и т. д.) околоайтишных фабриках типа КБ это норма в принципе.AlexWoodblock
12.08.2022 00:36+7Задач должно быть несколько, не связанных друг с другом и вообще из разных сфер
Вспомнил, как на первой работе в Израиле шеф выдал мне задание - позвонить и заказать несколько системных блоков, и договориться о цене пониже, т.к. мы закупаем побольше. На это я ему объяснил, что новому репатрианту, очень слабо говорящему на иврите, такие задания давать странно, а уж программисту, которого вы наняли, как программиста, а не закупщика, вдвойне страннее. Объяснение вышло очень доходчивым, больше таким меня не донимали.
olsowolso
12.08.2022 09:14О, почти 100% попадание, прям наше КБ в составе ПАО. Скажите, а работа программиста в других местах сильно отличается, или это все мифы? А то после института это пока единственное мое место работы.
kmosolov
12.08.2022 10:24Отличается разительно, вплоть до того что программисты могут «отговорить» прямое и не очень начальство не делать ту или иную «фичу», аргументировано, само собой.
RomeoGolf
12.08.2022 10:31+1Я в основном из хабра узнал, что сильно. Но быстро сменить место работы не выходило, потому что у нас в городе других вариантов почти нет, переезд по некоторым причинам на грани невозможного, а удаленка для преимущественно эмбеда тоже почти нереальна. Однако работу поменял и теперь по опыту скажу — есть места, где работать не только не мешают, но и помогают. У меня даже жена заметила, что я ощутимо изменился, стал спокойнее и добрее. Так что да, есть места, где отличается сильно.
RomeoGolf
12.08.2022 10:37+1Но добавлю — для «после института» это без дураков хорошее место работы. Это кузница кадров, «Тяжело в учении — легко на работе», как говорил Вицин. Научат работать вообще, а также как себя вести в искусственно созданных стрессовых ситуациях, как общаться с людьми, которые с тобой общаться не хотят, как выглядит реальная промышленная работа, в том числе, программирование Если повезет — научат и работе в команде (у нас с этим было практически никак). Наверняка рядом будет классный профи старой закалки, у которого можно будет многому научиться, как профессионально, так и организационно. Ну и плюс формальный опыт, сюда берут практически очень легко, когда в хороших местах джуны не нужны почти везде, а так хоть строчка в резюме достаточно неплохая. Я не жалею о своей работе в КБ, жалею только о том, что это было слишком долго.
tolyan_ekb
12.08.2022 12:07Тоже работал в КБ. Из КБ, как и из другой организации, если там происходит хоть 25% описанного надо срочно уходить. Есть компании, где можно гораздо производительнее проводить рабочее время.
didenis
12.08.2022 11:14Это норма в принципе на гос не только в айти и околоайти. Третий абзац это вообще классика: "универсальные солдаты" и внезапно возникающие задачи которые должны были быть решены уже завтра.
lea
11.08.2022 15:04+6Установите новичку на рабочую машину Linux или MacOS, если он до этого имел дело только с Windows.
Boilerplate
11.08.2022 15:28+1Хех, на мой первой работе была тоже windows 10, как и дома. Вот только поверх нее нужно было установить кучу SDK, DDK, Visual studio определенной версии и в определенной конфигурации и убедиться, что стоит правильное обновление винды. А чтобы обязательно протестировать на Win7 нужно было в виртуалке всё это повторить + накатить пару SP. Даже когда через год я себе все переустанавливал, то всё равно на правильную установку всех этих компонентов ушло пол дня. Инструкции были, но там как всегда не было половины нужных пунктов. Но с другой стороны на легаси-ентерпрайз проекте, взаимодействующему с определенным железом ничего другого и не стоило ожидать.
snuk182
11.08.2022 22:26+4Всего полдня на установку? Пфф. До появления choco и скриптов к нему легко можно было и неделю убить.
vedenin1980
11.08.2022 22:32+7На одной работе я два месяца проходил тренниги на различные темы (в основном, про дух компании и т.п., и успел поучаствовать в трех корпоративах) и только потом мне дали сделать первую таску.
mayorovp
13.08.2022 12:14Студия ставится не настолько сложно. Полдня — это как раз ручная установка, со всеми SDK и DDK.
sim31r
11.08.2022 16:42+6И ограничить права на всё. Захотел подключить флэшку - пиши заявление на директора, СБ и на всякий случай главбуха.
И внутрение сервисы работающие только в MS IE.
Staschik
12.08.2022 05:30+1Была обратная ситуация. Дело имел только с Linux, сказали работать на Windows. Веб разработка если что.
shlyakpavel
12.08.2022 10:30+1Такие вещи можно ещё на этапе собеседования обговорить, если это принципиально.
static_cast
11.08.2022 15:28+22Преподаватель в универе рассказывал, как он проходил практику на каком-то целлюлозно-бумажном комбинате. Он и в возрасте-то сохранил какую-то юношескую порывистость в движениях и мыслях, а тогда, - молодой инженер, только с ВУЗа, просто горел жаждой деятельности. Интересовался всем процессом, везде проявлял активность и, видать, чтобы не мешался, главный инженер поставил ему задачу:
- Вот, мол, на валах идет бумажная лента, что-то с ней там происходит, неважно, а в конце она наматывается в огромные рулоны. Все бы хорошо, но есть проблема, - бумага все-таки, могут быть небольшие разрывы, они потом расползаются, лента рвется, оборудование встает, показатели падают, всех дрючат, ужас. Ты молодой, мозги свежие, давай, придумай приблуду какую-нибудь, чтобы регистрировала факт образования разрыва, а потом бац, и автоматически аккуратно резаком кружочком его вырезала. Тогда вся лента не порвется, машина не встанет, а что в полотне дырки будут это не страшно, все равно рулон в нарезку пойдет.
Воодушевленный важностью и масштабом задачи, молодой начал рыть и конструировать. Как факт образования разрыва зарегистрировать? Механически или фотодатчиков наставить? Фотодатчики технологичней, но разрешающая способность... В три ряда что-ли ставить, а где? Резать-как? Резак штука простая, но лента-то движется, нужна синхронизация. И схема нужна, чтобы механизм адресно смещать к месту трещины. Питание еще. И место под все это.
В общем, погряз он во все это, пока какой-то старый инженер над ним не сжалился.
- Ты видел хоть раз как рвется лента, если там хоть мельчайшая трещинка образуется? На валу большое натяжение, чуть повредил, и все, в долю секунды треск и полотно пополам, и ничего ты не успеешь и зарегистрировать, а уж вырезать... Остынь, в общем, пошутили и хватит.
Даже в уже достаточно преклонном возрасте, рассказывал эту историю преподаватель, с некоторой обидой на поставившего ему эту тогда задачу. "Меня он тогда крепко подставил, да... А вы, на будущее, всегда выясняйте условия и применение, прежде чем браться за дело."
TerraV
11.08.2022 21:46+8То есть чувак взялся решать проблему даже не изучив её. Мне кажется это очень дорогой урок. Мне кажется это была не шутка а проверка на дурака и чел ее не прошел.
static_cast
12.08.2022 00:09Да, в конечном счете это получился урок, полезный опыт человек из ситуации вынес и даже передавал другим. Насчет проверки не думаю, все ж таки это практика, дальше им не работать, просто отделались на пару месяцев.
NikRag
11.08.2022 23:09+1Любая творческая часть работы должна делаться для себя.
А для работодателя - по ТЗ, желательно письменному.
Redrik05
11.08.2022 17:03Автор оригинала: Amir Rachum
Взял братишку индуса на работу, а потом понял, что он неприкасаемый..
MAXH0
11.08.2022 20:11+1т.е. это реальный кейс как уволить и не попасть под расследование по этике, а не из серии "плохих советов"?
Gilbert00
11.08.2022 17:37-3Описан типичный совок. Так работают не только новички.
allter
11.08.2022 22:09+2Не заметил про "совок". Да и автор издалека.
Описаны типичные рабочие сложности. И практика показывает, что даже в компаниях с развитым онбордингом и хелпдеском в какой-то момент возникают некомфортные задачи. И их решение - называется "работа".
Gilbert00
13.08.2022 12:52Весь этот онбординг и хелпдеск сводится только к бюрократическим процедурам. И на местах постоянно изобретают методы, как обойти контроль по этим процедурам.
ReadOnlySadUser
11.08.2022 20:38+4Существует риск, что новичок окажется сильнее всего этого, и-таки преодолеет весь этот бардак. Бюрократия очень мощное оружие в руках дотошного зануды) Тогда проблемы могут начаться у всех, кроме него самого.
funca
11.08.2022 23:19Здесь подразумевается, что новичок не умеет работать в ситуации с большим количеством неизвестных, что справедливо для 99% инженеров. Остальные, в самом деле, работают по специальности.
stranger_gu
12.08.2022 00:35+2Ещё добавляйте новичка во все совещания, которые даже не относятся к его задаче, так, на будущее
ForestDront
12.08.2022 08:41Начать работу, конечно, лучше с маленьких задач, главное, чтоб это не превратилось в бесконечный конвеер правки всякой фигни на года.
lagudal
12.08.2022 11:46+2Теперь на очереди ждем статью «Как работнику сделать так, чтобы его уволило руководство, с выплатой солидной компенсации и лучшей характеристикой, вместо того, чтобы уволиться по собственному желанию».
Хотя постойте, кажется, это уже было. Ах, да, конечно — в «Better Call Saul»…
Aleksandr-JS-Developer
12.08.2022 23:13+7Многие (обычно опытные) инженеры склонны отвечать на вопросы потоками подробной информации и длинными театральными монологами о том, как вы пришли к текущей ситуации («Это давняя история, начавшаяся ещё в те времена, когда контроль версий был причудой для богатых...»). Говорите новичку то, что он должен знать и спрашивайте, хочет ли он узнать подробности. Или позвольте ему сначала завершить мелкую задачу, потом сообщите чуть больше контекста, когда у него уже будет понимание того, что же делает компонент.
Есть у нас один опытный работник, который "стоял у истоков", участник легендарного Переезда проекта с технологии Х на Y.
Так вот, он любитель сжать ответ до трёх-пяти слов. Причём, скорее всего, это уточняющие вопросы, которые не относятся к проблеме.
-У нас полетела аналитика, после релиза Х. Мы всё проверили, можешь ещё ты глянуть?
-икнку в меню починли?
-Да, ещё в прошлом релизе
-ХорошоИ молчит...
Иногда пишет не переключив раскладку. И ладно, я сам так иногда пишу, но я, блин, редактирую сообщения, а он - нет.
Как-то, в порыве благодатного огня не из благодатных отверстий, я даже написал переводчик "ghbdtn" -> "привет" (можно как декодировать, так и кодировать, пишите во второе поле).Бодаться с ним не имеет смысла, т. к. работаем с ним раз-два в месяц...
А статья хорошая. Есть ещё добавить:
Не ведите документацию/тесты и подавляйте инициативы по созданию
Не делайте деплой на прод до 17:50
Давая концептуально новую задачу всегда спрашивайте точные сроки и сделайте так, чтобы их сдвиг означал головную боль всей команде
Первые два месяца пусть форматирует код вручную, чтобы чётко запомнил code style, принятый в компании
Лучше если каждый использует разные форматеры кода
При отсутствии штата (нанимаете первого), обязательно не нанимайте второго, но первому говорите, что скоро наймёте. Так-же не нанимайте сеньора, джуна/мидла хватит
Измеряйте продуктивность с самого старта работы сотрудника. Чтобы он видел в графе "продуктивность" 12% (привет, битрикс)
Первые 100% задач лучше всего давать по легаси коду для которого используются модифицированные легаси говно-библиотеки с которыми никто в мире, кроме 100 левых смельчаков с npm и не работал
Обязательно ставьте под сомнения решения новичка. Если вы не имеете компетенции - отлично! Это означает, что вы можете даже давать советы по реализации и долго отстаивать своё решение.
Главное в конце, когда уже вся команда привела по 10 аргументов, вы должны сказать "ладно, я не программист - вам виднее" и на следующий день всё это можно провернуть опять. Можно даже по той-же задачеУстановите трекер, чтобы нужно было нажимать на кнопку, когда сотрудник идёт в санузел. Не доведи Господи оплачивать сральное время по тарифу коддингово
Пусть время на выполнение задач
придумываетрассчитывает проджект, а не исполнительНазначьте несколько PM`ов для сотрудника и пусть они не согласовано фигачат задачи, соревнуясь в кол-ве огоньков в трекере
Не используйте популярные среди программистов таск-трекеры для своих программистов
Не покупайте лицензионный софт, программисты умные, они сами найдут софт
Не чистите компьютер перед передачей его новому сотруднику. Не меняйте логины и доступы. Пусть в гит пушит Олег, мы же знаем, что Олег уволился, значит, пушит Саня
А если всё-таки чистите - удалите важные компоненты помимо ненужных, не забудьте почистить реестр по туторам на ютубе
Запретите использовать докер для развёртывания проекта на машине для разработки
Никогда не согласовывайте API компонентов, которые делают разные разработчики
Лучшее время проверок задач для завтрашнего релиза - после 20:00, когда все уже дома
Написать в рабочий чат в 4 утра - это нормально
Никак не поощряйте инициатив по усилению безопасности продукта. Ну нашел уязвимость, разработал эксплойт и закрыл человек RCE с компрометацией учётных данных на платном сервисе за день и что тут такого? Кстати, кнопку так и не сдвинул?
Не тратьте время на актуализацию dev сервера
Если у сотрудника ДР - это хорошо. Значит, он будет работать с хорошим настроением
Никогда не проводите ретроспективы
Не отвечайте на запросы по рефакторингу
До беклога руки дойдут сами
В бизнес-процессы новый сотрудник вникнет сам
Если HR по какому-то глупому стечению обстоятельств всё-таки отправила пдфку со всем нужными сотруднику бизнес-процессами, то вам нужно им не следовать и делать круглые глаза всякий раз, когда новый сотрудник не угадал к кому идти по пдфке, а к кому "и так понятно, в пдфке устарело"
*При составлении этого списка пострадал один программист
Mayari
13.08.2022 19:20+1Статья мне понравилась, автор разложил всё по полочкам понятно и доступно. Вспомнился случай на работе, когда вместо того, чтобы что-нибудь объяснить, все члены команды начинали орать на меня, хотя я не могла знать специфику работы компании и этого подразделения. Все эти тонкости объясняются начальством и другими членами команды, в том числе начальником отдела. Увы, мне пришлось учиться самой, наблюдая за другими. Я испытывала большой стресс. Поэтому так и не смогла завязать добрые отношения ни с одним членом команды. И я ушла, потому что хватит это терпеть. Не люблю, когда в рабочие отношение примешивается личная неприязнь. И необоснованное высокомерие.
Зато с другими отделами очень даже сдружилась, с сисадминами, саппортом. До сих пор с ними общаюсь. Весьма позитивные люди.
Saiv46
К "вредным советам" следует добавить ещё один:
Принуждайте новичка работать в проде
Проект не существует в вакууме, от него может зависеть критическая часть продакшена. В таком случае побуждайте новичка как можно чаще релизить сразу в продакшен, чтобы он сильнее ощутил груз ответственности в случае неудачи.
(Внимание: подобные действия могут спровоцировать разборки в команде новичка с последующим разбором полётов)
DmitryMurinov
Бонус: найдите или придумайте задачу, которую можно отладить только на проде. Настройте прод так, чтобы при отладке через IDE вообще всё вставало на паузу (Java + JBoss/WildFly так работает), а не только отлаживаемое приложение. Задача должна класть весь кластер в случае падения (хороший пример, - отладка таймера, таски по которому должны исполняться только на одном экземпляре микросервиса).
sim31r
И направлять жалобы клиентов напрямую на разработчика тогда, чтобы он понимал что хотят клиенты. Круглосуточно. В 3 часа ночи звонок клиента "я тут нажал а оно пропало куда нажать чтобы не пропало?" очень будут мотивировать к вовлечению в проект. Когда разработчик отделен от клиентов двумя линиями техподдержки и тестировщиками это совсем не то, так скучно.
ElvenSailor
Заставь поработать на проде
Заставь уронить прод
Сделай виноватым
Выгони его
Profit!
MyraJKee
Задачи которые можно только на проде отладить не только джуна могут заставить уволиться ????
Staya_Krokodilov
Зато как ценят тех, кто умеет это делать (естественно, когда без этого не обойтись никак), кто уже имеет опыт типа "быстро поднятое уроненным не считается"... ???? Хирургия по коду!
TimTowdy
Ох уж эта боязнь релизить в продакшен.
if it hurts, do it more often.
В нескольких компаниях где я работал было правило: любой разработчик обязан релизнуть что-то полезное в продакшен в свой первый день работы. Даже если это новичок. Точнее не так. Особенно если это новичок.
vedenin1980
Успеть сделать что-то полезное, покрыть разными видами тестов, написать интеграционные/selenium тесты, пройти код-ревью, провести deploy на dev server, протестировать там вручную, собрать build со всеми unit test'ами, провести deploy на тестовый сервер, протестировать там силами QA, провести deploy на uat, протестировать там силами BA/бизнес пользователей, провести все автоматические тесты и сделать deploy на prod.
И все это за первый день работы! Я поражаюсь над продуктивностью ваших новичков!
TimTowdy
Вы серьезно пишите интеграционные + юнит тесты на каждый коммит?
У вас локальное окружение не поднимается одной командой?
Нет CI/CD?
Ревью десяти строк занимают несколько дней/недель потому что всем некогда?
Поздравляю, вы работаете в бюрократическом болоте, да еще и, похоже, гордитесь этим.
Мой комментарий не о продуктивности новичков, а о том что вредно с первого дня прививать боязнь деплоя.
Вы по ссылке хоть сходили?
funca
Вы просто объяснили неоднозначно. А так конечно хорошая практика, и не только для новичка. Пуская ченьж незнакомца в прод, они и для себя подтверждают, что все проверки и процессы в пайплайне работают как часы.
vedenin1980
Все есть и да, пишем (если они еще не написаны). Потому что ошибаются все и на самых глупых местах и при тестировании люди тоже ошибаются, а я работал в таких компаниях, где одна ошибка на проде может стоит больше чем любой разработчик заработает за всю жизнь в любой точке Земли.
Только там нет ничего про боязнь деплоя, а про то что сложные и болезненные вещи нужно делать поэтапно (что правильно). Имхо, но деплой крошечными пакетами без нормального регрессионного тестирование и определенных этапов проверок — не самое лучше решение.
Но вредно и обратное — пофигиское отношение к качеству того, что ты выдаешь на прод (ну если на прод, конечно, не всем, включая клиента, не наплевать). Есть определенные этапы и проверки, без которых получается программирование фиг-фаг и в продакт. Что еще хуже.
TimTowdy
Прям вижу как вы кулаком себя в грудь бьете.
В 99% софта оценка стоимости ошибки безмерно завышена неуверенными в себе программистами. Гораздо важнее иметь возможность быстро обнаружить и исправить ошибку, чем наивно пытаться не допускать их. Ошибки неизбежны т.к. появляются на всех этапах разработки, в том числе и тех где программисты не вовлечены вовсе.
Более того, есть проблемы которые вы никогда не исправите. Если юзер идет на ваш сервис с мобильного интернета, у него в любой момент может пропасть связь и винить он будет вас. Можете сколько угодно обмазываться юнит-тестами, но юзеру это не поможет. Если у меня есть 0.5% юзеров у которых возникают проблемы, и я могу ускорить разработку в разы заплатив за это поднятием этого показателя до 0.6%, то я не задумываюсь это сделаю.
Компании которые стоят миллиарды долларов каким-то образом умудряются деплоить десятки-сотни раз в день: Etsy, Netflix, Uber, Airbnb, Github. И, открою вам секрет, они столько стоят не вопреки их культуре деплоя, а благодаря ей.
Ваша неспособность построить эффективный процесс разработки это не повод для гордости. Все барьеры которые вы построили из-за страха нанести вред, точно также являются барьерами для принесении пользы. Представьте себе, пользователи ценят когда зарепорченый баг фиксится в течение 24 часов гораздо больше чем мифический софт без багов.
Регрессионное тестирование вполне себе может быть автоматизировано и не требует новых тестов на каждый коммит.
К слову, отсутствие конкретики наглядно демонстрирует ваш уровень: "нормальное" тестирование и "определенные" этапы проверок.
А вот и ожидаемый strawman argument подъехал. Я ведь ни слова не сказал о пофигистском отношении, вы его сами придумали. Потому что если вы неспособны построить эффективный цикл релиза, значит его не существует, верно?
inkelyad
Вообще, места разные бывают. Может, там писался какой-нибудь торговый биржевой робот. Где если уж он купил чего-нибудь не за ту цену и не вовремя - то "обнаружить и исправить" эту покупку уже не получится.
А если софт работает с реальным физическим миром, управляя дорогой и мощной железкой размером с небольшой дом или квартал - то угробленную железку и нанесенные убытки тем более быстро исправить не получится. (для примера, например, статья недавно была.
khulster
Теперь я понимаю откуда торчат ноги у практики, когда в день релиза сервера не справляются с нагрузкой. Просто кто-то решил, вместо того, чтобы арендовать на первое время Х+1 мощностей, поднять процент негатива на пару процентов. Ну а чаво такого? Потерпят.
Опять же где тут грань и кто ее проводит? Как определить момент с которого скорость разработки перестает что-то значить на фоне недовольства клиентов? Как не упустить точку невозврата, после которой уже не вернуть клиента назад?
И абсолютно не ценят, когда фикс одного бага, добавляет три новых. "Спасибо - стало -хуже" (с). В итоге вы можете хоть 100 раз успешно фиксить баги за 24-часа, но запомнят и будут припоминать вам 101-й случай, когда фикс пошел не по плану и вытащил на свет другие баги.
TimTowdy
Опять таки, "If it hurts, do it more frequently, and bring the pain forward".
Если у вас в культуре релизы десятки раз в день, вы набьете шишки на раннем этапе.
Очередной strawman. Но даже если я его приму, что лучше: изредка пофиксить один баг и добавить три новых, но при этом фиксить остальные баги за 24 часа. Или фиксить баги пачками раз в месяц?
vedenin1980
Я даже скажу как, когда у вас тысяча сервисов и тысяча команд (в компании где 10 тыс разработчиков это нормально, многие из них вообще почти никак не связаны с друг другом) — если каждая команда делает релиз раз в 2 недели — у вас будет десятки-сотни деплоев в день.
Но тут же его подтвердили
Причем вы не спросили бизнес во сколько им обойдется эти 0.1%. Я работал в нескольких компаниях с выручкой в миллард $ в год (например в 2017 тут), 0.1% это миллионов $ только прямых убытков.
И это не считая, что в выскоконкурентном бизнесе если пару раз сайт у пользователя не откроется или будет тормозить — он уйдет к конкуренту с друзьями и родствениками. И если у вас стабильная проблема у всего 0.1% пользователей каждый день, это не проблемы у 0.1% пользователей — вы теряете по 0.1% пользователей каждый ДЕНЬ или потеряете больше ТРЕТИ ваших пользвователей за год.
Может, но все равно должно оставаться ручное хотя бы самых важных сценариев. Потому что ошибка может быть и в автоматических тестах и они покажут все зеленым, а у вас вообще ничего работать не будет (такое на моей практике встречалось).
«Так чо ты меня своей шоблой пугаешь?!!»(с) из анекдотов.
Я не работал в Netflix и Airbnb, но я работал в компаниях из той же сфере и сопоставимы размерами (например, в trivago в год когда я работал была выручка 1 млд., против 2.5 млд. у Airbnb), поэтому статьи от этих компаний меня не впечатляют (открою вам небольшой секрет — обычно то, что пишется на публику и то что и как работает на самом деле в крупных публичных команиях — две очень большие разницы, на статьях-то у всех единороги и феи летают).
Представьте условный букинг ком, которые не дает вам никак забронировать гостиницу, которая вам нужна вот прямо сегодня (и которую вот вот кто-то другой забронирует). Будете ли их ценить больше если они пофиксят этот баг в течении 24 часов, после (утрировано) ночи на скамейке в парке?
TimTowdy
Зависимости сервисов друг от друга никуда не пропадают. Да, существуют изолированные кластеры, но внутри каждого полно зависимостей. И релизить каждый день все равно получается.
Неспособность релизить быстро приводит к тому что вы не можете вовремя приспособиться к потребностями рынка, в отличие от ваших конкурентов. И в итоге конкурент купит вас за бесценок.
Мне нужно интервью с разработчиками записать чтоб вы поверили?
Или может вы все-таки поймете, что способность CTO построить процесс в котором новичок приносит пользу в первый день работы, это показатель вашего качества как CTO?
Вот вам еще пару ссылок: Asana, Intercom. Впрочем у вас мышление конспиролога, все вокруг врут. На самом деле все живут в болоте, просто вы самый честный. Что-то мне это напоминает... Ах да, "загнивающий запад".
Спасибо, посмеялся. Удивительно, что работая в Trivago вы вообще не понимаете как работает hospitality индустрия.
Booking.com - это как раз идеальный пример опровергающий вашу позицию. Ваша бронь на букинге вообще никак не гарантирует вам комнату. Она может не дойти до отеля, отель может быть overbooked, вашу комнату могут продать дважды, PMS может прилечь (как локальная так и cloud), CRS может тормозить, и т.д.. Это происходит тысячи, если не десятки тысяч раз за день. И букингу пофиг. И отелям пофиг. И вендорам пофиг. Это плохо, но это реальность.
Если бы Booking в отрыве от реальности пытался построить надежную систему без багов, он бы никогда не взлетел.
Gruzchick
А что они там деплоят столько раз в день?
И точно верно что, то, что они деплоят по сто раз в день, означает, что те изменения которые они деплоят, не прошли релизный цикл?
Просто с автомобильного конвеер тоже по сто машин в день сходит, это не значит что, их до этого несколько дней не собирали при движении по конвееру
Makran
Видимо, он в майкрософте работал.
saboteur_kiev
А затем самолет падает в море, потому что пересек мередиан.
Felessan
Меридиан он при любом полёте пересекает, всё таки. А вот с переходом через линию перемены дат - да, может быть что-нибудь весёлое. Хотя обычно веселее летать с минусовой высотой относительно уровня моря (где-то на ближнем востоке такие места есть)
Frevv
Да можно советовать что угодно. Проектная работа и так ад, зачем вообще идти на такое. Хотите ощутить себя сотрудником макдональдса - идите уж тогда сразу в мак.
Да и вообще советы из статьи дискредитируют только работодателя. И хорошо если человек уйдёт молча, а не скинет гневное письмо на начальника директору компании со всеми переписками, примерами диалогов или записями на дистофон, а потом ещё и интернете оставит отзыв с указаниям фамилий тех кто его травил.
Luciphur
Никого не защищаю, но там помимо вредных советов в начале статьи (которые и правда ад) есть еще полезные ближе к концу.