Если сел писать письмо, и у тебя получается больше трёх абзацев — удаляй это письмо нафиг. Чем больше текста — тем больше шанс, что тебя поймут неправильно.
Принял решение и не можешь его объяснить за три абзаца — это плохое решение. Выражаешь мнение, и оно не входит в три абзаца — это плохое мнение. Ставишь задачу и не можешь объяснить её за три абзаца — это плохая задача.
Конечно, иногда людям действительно нужно передавать друг-другу много информации. Но почему бы тогда просто не поговорить голосом, и в процессе всё не записать? Когда говоришь лично, включается мимика и интонации, а с помощью этих инструментов гораздо легче передать любое послание.
В общем, если написал длинное письмо — стирай его нафиг и назначай встречу.
Ещё в школе мы привыкаем получать оценки. Помог учителю донести пачку тетрадей — молодец. Опоздал на урок — плохо, двоечник. Многие родители хвалят за хорошие оценки и ругают за плохие — так мы с детства и подсаживаемся на одобрение. А когда вырастаем, эту же модель поведения мы применяем к рабочим отношениям с коллегами: начинаем делать вещи, нацеленные на одобрение, и избегаем вещей, которые ведут к неодобрению.
Ради хорошей оценки мы можем даже пойти на должностное преступление — не спросить с коллеги за пропущенный дедлайн; недожать ресурсов для важного проекта; поставить в спринт неважную фичу только только потому, что попросили. Типа коллега запомнит, и на ежеквартальном ревью помянет добрым словом. Будете часто так делать — превратитесь в офисный планктон: все с вами дружат, но результатов бизнесу вы скорее всего не приносите.
Игнорируйте внешние оценки. Если для важной задачи нужно переругаться со всем офисом — ругайтесь. Если коллега пришёл с глупой хуйнёй — скажите ему, что он пришёл с глупой хуйнёй. Пусть первичными будут ваши внутренние правила, а не мнение коллег.
Тяжелее всего так делать в стартапах: вокруг бардак, вместо одного руководителя вы отчитываетесь всей компании, и каждый коллега норовит вам поставить «самую важную на текущий момент» задачу. Начнёте браться за всё — быстро сгорите, ничего не добившись. Так что выбирайте важное, и не стесняйтесь жертвовать одобрением коллег ради собственных стандартов качества.
Каждому из нас периодически падают плохо проработанные, непонятные и невежливые письма: «Коллеги нужна выгрузка платежей генеральный требует ASAP». Если вы сами пишете такие письма — почитайте Ильяхова. А в этой заметке я расскажу про заклинание, которое от таких писем помогает.
Заклинание называется «я ничего не понял». Если вам написали неопрятное письмо, даже не озаботившись тем, чтобы из него было понятно, чем можно помочь — просто пишите в ответ «я ничего не понял».
Конечно, прежде чем так писать, нужно искренне приложить усилия, чтобы разобраться — не все люди умеют выражать свои мысли.
Но если вы потратили несколько минут, а письмо понятнее не стало — просто вежливо напишите «я ничего не понял». От этого никто не умрёт, вы сэкономите время, а если человеку и правда от вас что-то нужно — он напишет еще одно, понятное письмо, или предложит созвониться.
В общении с плохими программистами (а ещё строителями, водителями и сантехниками) часто проскакивает тон «нерешаемая задача»:
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Не получится, мы в этот момент ещё не авторизованы на бекенде :(
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Это невозможно — мы для таких заказов не знаем ID аналитики :(
Это — плохие ответы. Для хороших ответов есть простое правило: в любом письме предлагай решение. Даже если оно будет безумным и нерациональным — не бойся: предложи и напиши об этом.
— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Давай, только придётся отключить авторизацию, и кто угодно сможет запустить такую отправку.
— Давай передавать данные о телефонных заказах в Гугль-аналитику? Давай, только можем либо забить на идентификаторы пользователей, либо интегрироваться с внешним коллтрекингом.
И ещё один банальный софтскилл, которого не хватает 80% программистов, которых я встречал — сдавать работу с первого раза. Серьезно, любой менеджер или дизайнер легко вспомнит десяток случаев за последний год, когда программист написал «я сделяль», а на самом деле ничего не работает.
Я говорю не про сложные для программистов случаи, когда действительно нужен сторонний взгляд — вроде форм заказа, которые принимают номера телефонов только в одном, программисту известном формате.
Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку — получаю ошибку». Непосредственных причин такой хуйни может быть много — CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.
А вот фундаментальная причина одна, и ее легко исправить — это непонимание definition of done. В случае бага все просто, сделанная работа — это когда баг не воспроизводится на продакшене. В сложных фичах нужно позадавать себе вопросы — что постановщик ожидал получить? Какой самый частый сценарий использования? В каком виде лучше показывать результат?
Самое лучшее средство от непонимания definition of done — всегда подкреплять свои слова доказательством. Пофиксил баг — приложи скриншот. Выкатил фичу — запиши видосик. Если не понимаешь, что скриншотить/записывать — иди за пониманием задачи к тимлиду или менеджеру.
Иногда бывает, что работу сдавать некому — дизайнер\менеджер не отвечает, ты делаеешь задачу на своем проекте, или просто не считаешь нужным кого-то отвлекать.
Чтобы не запускать неработающее говно, проведи презентацию самому себе. А еще лучше — выбери коллегу поопытнее, и представь, как проводишь презентацию ему. Прямо без шуток — представь реального человека, попробуй понять, какие вопросы он захочет задать, куда захочет нажать. Подготовь пару «слайдов» и демонстрацию экрана.
Воображение!
Воображаемая презентация позволяет на 5 минут переключить точку зрения и встать на место менеджера. Глазами менеджера ты найдешь не только очевидную хуйню, типа неработающих кнопок, но и более фундаментальные проблемы — забытые сценарии, интерфейсные тупики и любое другое несоответствие здравому смыслу.
О таких проблемах гораздо лучше узнавать от воображаемого коллеги, а не от реального.
