Идеальный код и продакшен

На связи Максим, сегодня хочу поговорить на тему идеального кода на продакшене, когда это важно и можно ли без этого обойтись. Начну с начала. Мое мнение относительно этого вопроса менялось по ходу роста моих навыков и смены должностей. Когда я только начинал разработчиком, мне нужно было делать кучу задач под разные проекты и платформы, которые были нужны на недолгий срок. Я опробовал много языков и платформ, особо в качество упирать естественно не было возможностей, да и понимания, где оно, это качество, не было.

Начав разрабатывать долгоживующие проекты, я понял, что очень важно писать их удобно для сопровождения и отладки. А частые правки от бизнеса приучили, что без тестов делать большие смены курса проекта или большой рефакторинг себе дороже.

С ростом сложности проектов я начал больше внимания уделять внимание архитектуре проекта. Отказоустойчивость компонентов, гарантированная доставка событий, корректная работа под пиковыми нагрузками и т.д. Структура проекта, или проектов, стала такой, что рефакторить куски стало не очень сложной задачей, а перерабатывать архитектуру всегда долго и больно.

Став СТО, я пришел к выводу, что в повседневной работе нужно всегда отстаивать сроки на разработку качественной фичи (обязательна правильная архитектура и наличие тестов), компромис в коде можно согласовать, если после запуска фичи сразу берется рефакторинг. Но, как правило, любой компромис останется вашим вечным техническим долгом.

Как же быть с проектами, которые нужно просто попробовать или фичами, с которыми нужно лишь протестировать взлетят они или нет? Если вы встраиваете фичу в большой проект, где поверх вашей фичи уже будут писаться другие, то тут без вариантов, качество должно соблюдаться на каждой фиче. Если это проект на попробовать, то у вас два варианта: пишите так, чтобы можно было отрефакторить в случае успеха или пишете с нуля, если выяснили, что проект взлетит. Это надо четко понимать, я видел много проектов, стартовавших как попробовать и потом развивающихся поверх этого кода многие годы. Работать с этим мягко говоря сложно, предсказуемость работы отсутствует. Поэтому если вы понимаете, что времени на исправление не будет, делайте хорошо сразу, если время будет, то я выбираю вариант с рефакторингом (при условии, что проект делается с запасом по нагрузке х2 и будет без огрехов выполнять заказанный функционал).

Уволить после отпуска

Всем привет! На днях мне скинули заметку о Форде с вопросом, что я вообще о таком думаю? Сама история:

Однажды Генри Форд собрал руководителей всех отделов свой компании и отправил их в двухнедельный круиз. После возвращения один ждало повышение, а других увольнение. Форд основывался на работе отделов в отсутствие руководителя. Если работа шла хорошо и без руководителя, значит он сумел все хорошо организовать, а если нет, значит отдел без своего руководителя работать не может и это его вина.

Можно ли такую практику применять
Если ответить коротко, то это вполне распространенная и применяемая практика, которая показывает готовность команды к работе без руководителя.

А теперь немного поподробнее, почему это вообще важно? Потому что руководитель - это человек, который должен выстроить процесс, сделать работу своих людей понятной, четкой и, по возможности, комфортной для достижения максимальной производительности. Поэтому, если при уходе в отпуск руководителя работа встает, очевидно, что отдел работает не самым эффективным образом. То есть о выстраивании эффективной работы руководитель задумывался слабо или вообще не думал.

Это работает не только для руководителей
Такие проверки устраивать нужно обязательно, более того не только руководители, но и исполнители, бывают незаменимы, о чем многие с удивлением узнают после увольнения людей, после которого весь процесс останавливается. Поэтому нужно всегда смотреть может ли каждый из ваших сотрудников уйти в отпуск так, чтобы это не повлияло на процесс (конечно это влияет на скорость, банально в команде нет одного человека, но команда должна понимать что делать с задачами и нештатными ситуациями).

Обязательно протестируйте себя. Уйдите в отпуск и будьте недоступны или слабо доступны. Это может подсветить много слабых моментов. Конечно в обычной ситуации перед уходом в отпуск нужно передать дела своим сотрудникам, рассказать о потенциальных проблемах, где и как им нужно вас подменить. Помимо этого можете попробовать посмотреть, как процесс работает без вас, просто став недоступным по определенным вопросам на несколько дней (например, в целом по процессу ведения уже взятых в работу задач с любыми проблемами на пути работы).

Когда так делать нельзя
Также хотел уточнить ситуации, когда такой подход нельзя применять:
- если руководитель только назначен и не успел вникнуть в дела или перестроить процесс под свое видение;
- если стоит задача перестройки или реорганизации команды/отдела;
- если происходит быстрый рост команды/отдела. Новые люди и новые проекты, это всегда точки некоторого хаоса и притирки. Просто нужно оговаривать какие-то примерные сроки и шаги по стабилизации и следить как идет процесс;
- запуск новых проектов.

Я не знаю, кто первый начал практиковать способ с отпусками и где он впервые был описан, но это хороший способ проверить, что руководитель выстроил работу, а сотрудники шарят знания и могут подменять друг друга.

Максим Шаламов

#тимлиду

Большинство не знает этого секрета в подаче обратной связи

Умение давать обратную связь другим людям вообще встретить довольно сложно. Но я бы хотел остановиться на одном аспекте, а именно: ваша реакция на презентацию чего-либо от ваших коллег (друзей и кого угодно в целом). На этой, казалось бы мелочи, вырастают и конфликты, и демотивация, и отсутствие контакта и взаимопонимания в команде.

Как это обычно выглядит: человек или команда делают продукт/концепт/прототип/фичу/т.д., вкладываются в это, прикладывают все усилия, презентуют результат… Ну и слышат сходу что-то вроде: “да, но хотелось бы побольше, побыстрее, покрасивее”. И тут на самом деле даже люди привычные к такому будут не сильно в восторге, а у людей, близко к сердцу принимающих свою работу, будет гореть так, что огнетушитель не поможет. Причем, мало кто осознает во время или после таких презентаций, что все негативные эмоции и конфликт произошли из-за этой маленькой мелочи - критики со старта.

Обычно вы не знаете через какие проблемы проходят люди, какие там внешние и внутренние проблемы мешали, да и просто это не лучшая стратегия. Обязательно поблагодарите людей, хотя бы за то, что они старались и показали вам результат своих усилий. Стартуйте обсуждение с того, что вам не понравилось не в форме осуждения, а в форме вопроса. Например: “чем обусловлен выбор этого решения?” или “рассматривали ли вы такие подходы?” и т.д. На самом деле, из таких мелочей в итоге и складывается конструктивная или не особо работа. Не нужно врать людям и не говорить свое мнение. Просто уважайте чужой труд и выбирайте правильную форму подачи. В конце концов, если выяснится, что смягчающих факторов нет и все реально плохо, то тогда и можно переходить к ультимативной критике. До этого используйте более тактичный подход. Это сэкономит вам время и нервы.

Максим Шаламов

Вопросы, которые важно задавать любой компании на собеседовании. Часть первая "Цели"

От года к году мое понимание того, что и зачем спрашивать у потенциального работодателя меняется. Сейчас я хочу поделиться своим текущим набором вопросов. Конечно много вопросов пойдут от специфики компании и от того, как будет происходить общение. Но есть минимальный общий набор. Это особенно важно, когда вам предлагают руководить и отвечать за какие-то направления.

Первым сейчас для меня идет блок вопросов о целях. Без целей у компании не будет направления, а у людей не будет вокруг чего объединяться. Имея опыт работы в компания без конкретных целей, сейчас я сразу заканчиваю общение в случае, если мне не могут сформулировать цели компании и вытекающие из этого личные цели. Можно выделить следующие вопросы.

Каковы цели компании?
Верхнеуровневые цели, сформулированные руководством. Для достижения этих целей собственно и должны работать все сотрудники компании. Глядя на эти цели уже можно сложить представление о том подойдет вам компания или нет.

Каковы цели вашего проекта/департамента/…?
Поскольку каждый из нас работает в рамках какого-то проекта/департамента/ваша орг. структура, то нужно понять какие цели будут стоять у вашего подразделения и как вы влияете на цели компании. Из этого можно понять насколько важна ваша работа для компании и будет ли ваше подразделение в числе первых получать дополнительные ресурсы или нет. На этом этапе вы уже должны верхнеуровнево понимать, на что ваша работа влияет и степень ее важности. Если тут особого интереса не возникает, то я бы советовал поискать еще.

Каковы будут ваши личные цели и как они соотносятся с глобальными целями? Как понимать степень успеха вашей работы?
На этом этапе нужно понять есть ли четкое понимание вашего места в компании, того, что от вас ожидают и как будут оценивать. Чем более абстрактно на этом этапе отвечают, тем больше неприятных сюрпризов будет ждать в дальнейшей работе. Если вас вдохновляет то, чем занимается компания и то, как вы можете поучаствовать в ее работе, то в этом месте вы должны четко обговорить свои обязанности и цели. Чем четче вы зафиксируете и детальнее проговорите все детали, тем вам же будет проще в дальнейшем.

Какие решения принимаете лично вы на этой позиции?
Важный вопрос для понимания того, какие функции вам реально будут делегированы. На этом этапе может оказаться, что вам будет либо недостаточно инструментов для исполнения обязанностей, либо на вас пытаются переложить слишком много. В любом случае это хороший пункт, чтобы выровняться по ожиданиям и либо пойти на уступки, либо нет. В случае если вы произведете хорошее впечатление, чаще всего вам пойдут навстречу.

На этом пока все. Обязательно следите за обновления, на следующей неделе будет вторая часть с вопросами, которые помогут определить сложится ли ваше счастливое будущее в потенциальной компании. А пока сохраняйте этот пост, делитесь с друзьями и помните о нем на ближайшем собеседовании.

Максим Шаламов