Фёдор Борщёв

Хороший план исходит от команды

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

В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.

Когда спринт планируют исполнители, мозг перестраивается — вместо накидывания задач, чтобы забить ёмкость, люди начинают под них подписываться. Внутренний диалог ведётся совсем по-другому: не «верно ли я оценил эту задачу», а «успею ли я выполнить вот эти обещания в срок?».

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

Отдых — твоя ответственность

Ребята, которые впервые попадают в распределённую команду, особенно со свободным графиком, часто начинают перерабатывать. Если раньше день можно было разделить на две части походом в офис, то теперь этого нет: есть задачи, есть дедлайны и 24 часа в сутках, которыми ты управляешь самостоятельно.

Возникает что-то вроде синдрома отличника, ты неосознанно начинаешь брать больше и закидывать дальше: жертвовать спортзалом, сном, прогулками с близкими. Часто ситуацию усугубляют менеджеры, которые впихивают задачи пока впихивается, легко преодолевая неумелое сопротивление новичка.

Чтобы не катиться по наклонной, начни воспринимать своё внимание как ограниченный ресурс. К примеру, как деньги. Взял задачу у менеджера — значит отдал немного внимания из кошелька. Засиделся допоздна за задачей — забрал внимание у близких. Начал спать по 6 часов в день — крадёшь внимание у своего организма.

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

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

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

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

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

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

Не работаю с мудаками

В отношениях с людьми я руководствуюсь простым правилом — я не работаю с мудаками.

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

Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.

Расставаясь с такими людьми, я делаю лучше и им, и себе.

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

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

Найм людей: лучше false negative, чем false positive

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

Самое главное в команде — общая среда, которую еще иногда называют «корпоративной культурой». Среда может развивать ответственность у новых участников (пример — Студия Лебедева, почитайте их конституцию), а может наоборот, подавлять, как условный ЖелДорСвязьКредитБанк, где инициатива наказуема. В хорошей среде люди цветут и развиваются, в плохой — киснут.

Среду создают люди. Пока в вашей команде один участник, вся среда — это вы: команда планирует время в точности, как вы, реагирует в случае авралов как вы, выстраивает отношения с коллегами как вы.

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

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

Не учитесь технологиям — учитесь решать задачи

Начинающие программисты часто спрашивают в личке — как правильно выбирать технологии? Что учить, чтобы не отставать от прогресса? Это — плохой вопрос, учить надо вовсе не технологии.

Фреймворки, паттерны, методики разработки, языки программирования — это хард-скиллы. Навыки, которыми можно овладеть, просто изучив пару книг и немного попрактиковавшись. Если вы имеете за спиной базовые знания о том, как устроены инструменты программиста —  вы легко приобретёте нужный хард-скилл в любом возрасте.

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

Когда умной компании нужно построить дом, она ищет не людей, которые умеют работать с молотком, а людей, которые умеют строить дома. Чем вы построите этот дом: шуруповёртом, подъёмным краном или нанятой командой монтажников — не так уж и важно. Важно ваше умение решать задачи, при необходимости включая в арсенал неизвестные инструменты.

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

Feature flags

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

Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.

Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.

Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.

См. также:

  • Подробное объяснение пользы фиче-флагов от самого Мартина Фаулера
  • Launch Darkly — централизованное управление включенностью фич
  • Unleash — то же самое, но бесплатно и self-hosted

Важная мысль про сложные переговоры, которой почему-то нет в книгах

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

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

Или нервяк перед собеседованием на работу. Какие причины нервничать, если я отлично разбираюсь в том, чем занимаюсь, у меня крутое резюме и рекомендации от известных в тусовке людей?

Не доводи до сложных переговоров

Если за спиной все в порядке, то любые переговоры будут простыми. А если ты не уверен в себе, то никакие манипуляционные техники из книжек не помогут.

Единственный автор, который хоть немного подводит к этой мысли — Джим Кэмп. А остальные, кажется, просто пишут селф-хелп про то, как побороть неуверенность.

FOMO

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

Тот же самый FOMO настигает нас в торговом центре, когда мы заходим в магазин с распродажей и покупаем себе третий подряд ненужный джемпер, «потому что потом подорожает».

FOMO — это сокращение от Fear Of Missing Out, страх упустить возможность. Он сидит настолько глубоко в каждом из нас, что часто не мы ищем возможности, а возможности находят нас и подчиняют себе. Увидел красивый банер с детьми и улыбающейся женщиной в домашней одежде, по телефону тебе объясняют, что цена действует «всего три недели» — и бац, ты уже подписываешь кабальный контракт, по которому 15 лет (треть активной жизни!) будешь платить за однушку посреди поля в 40 километрах от МКАД.

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

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

Однако Salomon — кроссовки надежные. Если вдруг скидок в феврале не случится (или я не смогу ими воспользоваться, как в этом году), то я не останусь без обуви — просто прохожу ещё год в тех же самых кроссовках.

Так что читайте Нассима Николасовича и не упускайте возможности.

Процесс vs результат у разработчиков

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

Вам знакома ситуация, когда близко дедлайн, в коде в общем-то остается поставить один if, а вы принимаете тяжелое решение — переписать несколько методов с выходом в надсистему, вместо того, чтобы увеличивать цикломатическую сложность. Это и есть разница — if это результат, переделать методы — процесс. Процесс важен, но без результата — не нужен:

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

Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго просранного таким образом проекта, вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для запуска?»; «Для чего мы запускаем этот проект? Какая у нас цель?»; «Что из того, что я запланировал можно НЕ делать?».

Если не хотите искать проекты на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Пример хорошей личной задачи — завести блог. Пойдете писать бекенд на гошечке и микросервисах? Возьмете модный генератор статичных сайтов? Или все-таки медиум?