Фёдор Борщёв

Удалённая работа и контроль результатов

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

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

За процесс, наоборот, спрашивать легко: опоздал программист на работу на 5 минут — значит виноват. Тупанул во вконтосик в рабочее время — значит плохо работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как победить в себе микроменеджера

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

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

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

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

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

Если вы занимаетесь микроменеджментом, значит вы не доверяете коллегам. А есть ли смысл садиться в одну лодку с людьми, которым вы не доверяете?

Боязнь ошибиться у программистов

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

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

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

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

На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.

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