Игнорировать оценки

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

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

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

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

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

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

Как передавать знания в агентстве?

Специфика агентской разработки — малое погружение специалистов в проект: проектов много, а специалисты постоянно меняются.

Если у вас так же и вас достало по 100 раз пережёвывать одни и те же правила, постройте у своих программистов систему наставничества.

Подробнее — в моём новом совете на сайте Бюро.

Любимые посты

— Хороший план исходит от команды,
— Твой отдых — твоя ответственность,
— Одна задача — один ответственный,
— Найм людей: лучше false negative, чем false positive,
— Как начать новый проект без знаний программирования,
— Сначала процесс, потом автоматизация.

А ещё я пишу в блоге и фейсбуке, а так же даю советы на сайте Бюро.

Ну а если вы программист, фоловьте меня на гитхабе.

Всё ужé

Важный чекпоинт на пути профессионального роста — состояние «всё ужé». Это когда смотришь на работу программиста, проверяешь, скажем, покрыты ли тестами крайние случаи — а они уже покрыты. Проверяешь, как ПР будет интегрироваться с соседним проектом — а там уже все обсудили и утвердили. Смотришь, насколько итог работы соответствует изначальному дизайну — а дизайнер сам уже написал, что всё ок.

Состояние «всё ужé» означает, что обучение полностью завершено, человек «врос» в своё рабочее место. Кто-то доходит до такого состояния за полгода, кому-то и через пару лет нужен небольшой контроль в сложных моментах.

Есть ребята, которые после достижения «всё ужé» замедляются — зачем бежать вперёд, когда всё понятно, уважение коллег заслужено, все нужные паттерны поведения освоены. Есть те, кто наоборот, начинает в таком состоянии скучать.

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

Что делать, чтобы вас не заменили роботом

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

Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.

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

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

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

Вопрос: работаете ли вы с подрядчиками в части разработки кода? Если да, то как проводите код-ревью?

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

К тому же у внешних ребят обычно страдает качество кода (писал об этом тут). Кодовая база — достояние компании, её будущее. А я не хочу, чтобы будущее строилось на дорогих костылях и техдолге, созданном людьми, которыми я не управляю.

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

Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.

Отдых — твоя ответственность

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

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

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

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

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

Как проверить компетентность веб-разрабротчика?

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

Спойлер: сделать с ним тестовый проект.

Вопрос: кто такой CTO для бизнеса?

CTO для бизнеса это такой же топ-менеджер, как и все остальные: CFO, COO, CPO и кто там ещё есть. То есть человек, который полностью закрывает своё направление — выполняет KPI, согласовывая с CEO только бюджет.

KPI могут быть самые разные, но обязательно завязанные на основные задачи бизнеса. В технологичном стартапе на ранней стадии это valuation. В галерном агентстве — способность производства переварить весь проданный скоуп.

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

Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.

Бирюзовое доверие

Возьмём типичную проблему — допустим есть бизнес, у которого разработка периодически ломает прод. Если решать эту проблему классическим способом, как решали раньше на заводах, то вы просто построите ОТК: отдельный этап тестирования, жёсткие правила для код-ревью, чтобы без одобрения двух коллег нельзя было выкатывать. Как настоящий кризисный менеджер, вы придумаете какой-нибудь солидно звучащий KPI для программистов, вроде количества автотестов. Только вот прод реже ломаться не начнёт.

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

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

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

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

Незавершёнка

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

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

Любые принципы продуктивности основаны на очистке мозга от незавершёнки — пустые списки дел в GTD, удаленные письма в Zero Inbox, пустые колонки в Kanban.

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

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

Спокойствие и уверенность в себе

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

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

Когда я только начинал строить команды разработки, я искал баланс — как дать ребятам спокойствие и уверенность в себе, при этом не отпускать рычаги — бизнес есть бизнес, и чтобы заработать денег, надо иногда делать штуки, которые делать никто не любит, вроде всплывающих окон и говнокода в проде. В ГдеМатериале мне повезло — всю команду нанимал я. Это позволило мне почти не тратить сил на поиск баланса — люди либо совместимы отсутствием ТЗ, «чтобы что» и свободным графиком, либо у нас не работают.

С командами, которые давно стоят на привычных рельсах взаимного недоверия, всё гораздо сложнее.

Скажите, а какой у вас опыт перестроения обычной команды из парадигмы галеры в сторону доверия? Можно даже не программистов, или не на работе. Насколько получилось приблизиться к цели? Что помешало? Как доносили участникам парадигму доверия?

90% фич вылетает в трубу

Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.

9 из 10 фич. Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?

Вместо пиления фич вы начнёте проверять гипотезы.

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

Помните мой совет со входом через инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.

Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

Это был традиционный #вопрос по понедельникам. Задайте свой — #вопрос по понедельникам. Задайте свой — @fedor_borshev

​Открыть локалхост наружу

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

Скажем, делаете вы интеграцию с какими-нибудь странными ребятами из 2008 года, которые шлют вам вебхуки, а документацию держат в файле документация.docx.  Не будете же вы отлаживать этот сервис на проде?

Можно делать все локально — просто поднимаете сервис на своей машине, запускаете ngrok и получаете уникальный адрес в интернете вида https://48fad95b6ce3f79.ngrok.io. Все запросы к этому адресу форвардятся на вашу локальную машину, так что вы просто даёте этот адрес странным ребятам и потом спокойно разбираетесь — может хоть отладчик запускать на боевых данных.

Как правильно ставить KPI программистам?

В продолжение поста про бирюзовое доверие, рассказал на сайте бюро, почему программистам вообще лучше не ставить никакие KPI.

Вопрос: расскажи, какими должны быть должностные обязанности менеджера?

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

Такие формальные обязанности нужны слабым менеджерам, которые умеют только копать, где сказали.

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

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

Это был традиционный вопрос по понедельникам. Другие ответы доступны по тегу #вопрос. Чтобы задать свой — напишите на @fedor_borshev.

Почему я предпочитаю удалённую работу

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

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

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

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

Метод гипотез в решении технических задач

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

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

Вместо результата у непонятных задач лучше фокусироваться на процессе. К примеру, можно пообещать проверять по одной гипотезе раз в два дня. Садимся, и раз в два дня выдвигаем гипотезу, скажем «я считаю, что виноват redis, потому что он иногда падает, а потом долго грузит сохранённые данные с диска».

Дальше садимся и проверяем гипотезу: как быстро запускается redis с сохранёнными данными? А под нагрузкой? Может избавиться от промежуточных сохранений кеша и вообще отключить сохранение? Придумали эксперимент, запустили проверку — и на пару дней переключаемся на другие задачи.

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

Каждый понедельник я публично отвечаю на вопросы, которые задают мне в личку. В этом посте я собрал самые интересные ответы:

Что думаешь об ХХХ (технологии\подходе\и т.д.):
- Что думаешь про монорепозитории?
- Как лучше учиться — вширь или глубь?
- Что думаешь о node.js в вебе?

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

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


Почитайте все ответы по хештегу #вопрос, а лучше — поддержите рубрику: деньгами или новыми вопросами на @fedor_borshev.