В процессе найма программистов принято давать тестовые задания.  Это нужно, чтобы продемонстрировать аккуратность, знание заявленных технологий, способность понимать задачу и предвосхищать ожидания.

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

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

Такое задание — как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?

Если вдруг проект не получается отдать из-за НДА-шных причин — отдаю специально хранимый для этих целей pet project.

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать» — это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить более важные.

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

Если спринт спланирован хорошо, то примерно половина из буферных задач успешно закрывается. Если плохо — закрываются или все, или ни одной.

И ещё один банальный софтскилл, которого не хватает 80% программистов, которых я встречал — сдавать работу с первого раза. Серьезно, любой менеджер или дизайнер легко вспомнит десяток случаев за последний год, когда программист написал «я сделяль», а на самом деле ничего не работает.

Я говорю не про сложные для программистов случаи, когда действительно нужен сторонний взгляд — вроде форм заказа, которые принимают номера телефонов только в одном, программисту известном формате.

Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку — получаю ошибку». Непосредственных причин такой хуйни может быть много — CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.

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

Самое лучшее средство от непонимания definition of done — всегда подкреплять свои слова доказательством. Пофиксил баг — приложи скриншот. Выкатил фичу — запиши видосик. Если не понимаешь, что скриншотить/записывать — иди за пониманием задачи к тимлиду или менеджеру.

Иногда бывает, что работу сдавать некому — дизайнер\менеджер не отвечает, ты делаеешь задачу на своем проекте, или просто не считаешь нужным кого-то отвлекать.

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

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

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

В 50-х годах прошлого века умный дядька по фамилии Паркинсон, историк по профессии, вывел немного шутливый, но верный и правдивый закон — работа всегда занимает все отведенное на нее время.

Если у внучки есть три дня, чтобы написать письмо бабушке, то она будет писать три дня.

Если у вас в спринте три мелкие задачи, то вы будете делать их две недели.

Наоборот тоже работает — если до конца недели нужно сделать 20 задач (и вам отрежут руку, если не сделаете), то вы найдете способ все успеть — пофлексите, упростите код, напишете говно, наконец.

А если внучка торопится в кино с подружками, то бабушке хватит и открыточки.

Тайм-менеджмент в технологической компании — сложная задача: работы всегда больше, чем можно успеть. На проблемы планирования часто накладывается наша эмоциональность — сложно отказать руководителю, который громко требует «пойти и работать». И почти невозможно отказать самому себе, когда хочется поделать фичу, которая только что пришла в голову, и «точно всем нужна».

Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.

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

Моя любимая часть — про «видение». Марк Форстер рассказывает, как клево живется, когда у тебя есть четкая система, которая отделяет вещи, которые нужно делать от вещей, которые делать не нужно.

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

Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.

Никогда не реагируйте на что-­то немедленно, если ситуация не является по­-настоящему неотложной или ваша работа не предполагает такой реакции.

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