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

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

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

Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.

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

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

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

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

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

В кровавом аутсорсе и аутстафе принято с каждым новым клиентом, кроме договора об услугах, заключать ещё и NSA: non-solicitation agreement или соглашение о непереманивании. Типа, если сотрудник из аутсорса\аутстафа переходит на сторону клиента — клиент платит большой штраф.

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

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

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

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

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

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

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

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

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

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

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

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