Заметки с тегом «Софтскиллы»

Недавно на Q&A «Есть минутки» мне задали вопрос — как вести асинхронную коммуникацию, когда периодически бывает, что сотрудник нужен срочно — упал тестовый стенд, ветка не мёрджится или просто нужно срочно сделать задачу.

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

Большинство менеджеров почему-то воспринимают срочность как аксиому, типа «давайте сделаем чатик с сисадминами, потому что они бывают нам срочно нужны». Такое решение только маскирует проблему — они не анализируют причины проблемы, а лечат симптомы.

Работа менеджера\тимлида — не обслуживать срочность, создавая больше чатиков. Хороший менеджер, наоборот, убивает срочность — выделяет время, чтобы сделать неломаемые стенды; внедряет github flow, чтобы не было немёрджащихся веток; бьёт по рукам других менеджеров, которые выдумывают срочность, потому что не доверяют людям.

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

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

С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за день вместо недели или за 300 строк вместо 30 000.

Если планируете развиваться в кого-то кроме синьёра, годами не вылезающего из своего, постепенно превращающегося в легаси, проекта, такой оверижиниринг для вас — стратегическая ошибка. Смотрите сами, технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.

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

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

Грубо говоря — плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.

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

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

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

Цели бывает три:

• Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
• Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
• Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».

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

Гениальный совет, который когда-то подсмотрел у Николая Товеровского — чтобы не опаздывать на офлайновые встречи (люди, бывает, разговаривают лично), можно приезжать сильно заранее — не на 15 минут, а на час или даже два. Время ожидания не пропадает — всегда найдутся дела, которые можно поделать из любого места: пописать код, поотвечать на письма, навести порядок в проекте.

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

Если на встречу, запланированную в 15:00 приехать в 13:00, острота выбора снимается — даже если вы чуть-чуть задержитесь и приедете в 13:15, никто не заметит разницы. Время с 13:15 до 15:00 тоже не пропадёт — поделаете рутинные дела. Если вы интроверт, как я, то ещё и настроитесь спокойно на встречу, сделав обстановку комфортной — удобно поставите ноутбук. привыкните к креслу, выпьете кофе.

Пользуюсь этим советом уже несколько лет, иногда даже встречаю коллег по лайфхаку — это когда договорился встретиться в кофейне в 20:00, приходишь туда в 18:30, а тебя уже ждут.