Кручу гайки. Пишу матом. Настраиваю ин-хаус разработку в стартапах.

Сдавать с первого раза

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

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

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

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

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

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

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

Воображение!

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

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

Приходи с решением, а не с проблемой

Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».

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

Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.

Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.

Пацан сказал — пацан сделал

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

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

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

Пацан сказал — пацан сделал

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

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

Не кидайся ссылками

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

Чтобы не наращивать конфликт, достаточно просто говорить. Тупое правило: если видишь в сообщении от коллеги хоть небольшой намек на эмоции — немедленно прекращай общение и назначай встречу. Если сам написал эмоциональное сообщение — стирай скорее.

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

Никогда не презентуй свою работу по почте

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

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

Топ-даун и прогрессивный джипег для программистов

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

Проверь через два дня

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

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

Проверка через два дня не требует никакого напряжения и предотвращает кучу долга — в проекте не копятся неработающие и невнедренные фичи.

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

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

Марк Гоулстон — Послушай

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

Марк Гоулстон — Я слышу вас насквозь

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

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

Кроме способов самоуспокоения, книга учит проявлять эмпатию — сопереживать и выслушивать (в оригинале книган азывается «Послушай»). Автор описывает донельзя конкретные методики («Я хочу понять, что вы чувствуете. Я думаю это отчаяние. Разве не так?»).

Несмотря на попсовость, книгу стоит прочитать всем адептам Кэмпа — она учит травить леску. Вот, кстати, другие прочитанные мной книги, которые детально раскрывают советы Кэмпа.

Совет Книга
Задавать открытые вопросы СПИН-продажи
Приносить пользу Советник, которому доверяют
Травить леску Я слышу вас насквозь

Покупайте в МИФ.

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

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

Джек сразу признался, что вряд ли сможет изменить свои привычки.

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

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

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