Фёдор Борщёв

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

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

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

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

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

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

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

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

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

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

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

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

Производство и потребление: часть 2

После прошлой заметки о производстве и потреблении, многие ребята спрашивали в личку, как всё-таки можно производить больше 95% людей имея только блокнот и ручку?

На самом деле, задача очень простая — 95% людей, которых вы встречаете на улице, не производят вообще ничего. К примеру почти всё, что большинство людей делает на работе — это простейшие манипуляции, которые всего лишь улучшают потребление. У многих цепь настолько простая, что не отличается от мышки в лабиринте: совершил 100 звонков -> выполнил KPI -> получил бонус -> заработал на новый айфончик.

Каждый из этих телефонов послужил кому-то Высшей Целью в Жизни

Никто не задаётся вопросами. Кому стало лучше от 100 звонков? Мне? Близким? Человечеству?

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

Заведите блог (те самые блокнот и ручка). Кому-то будет полезно и интересно.

Сделайте пет-проект — не просто todo-MVC, а что-то с конкретной пользой: удобного бота для телеграма, помощника в выборе одежды, каталог эмодзи с поиском по настроению, что угодно.

Запишитесь в волонтёрскую организацию.

Прочитайте 150 книг.

Возьмите кусочек рынка и переверните его с ног на голову.

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

Почему я не люблю оценивать задачи

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

Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить не 5 часов работы по написанию кода, а работающую фичу на проде.

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

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

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

Хороший план исходит от команды

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

В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.

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

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

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

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

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

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

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

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

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

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

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

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

Не работаю с мудаками

В отношениях с людьми я руководствуюсь простым правилом — я не работаю с мудаками.

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

Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.

Расставаясь с такими людьми, я делаю лучше и им, и себе.

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

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

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

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

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

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

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

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

Не учитесь технологиям — учитесь решать задачи

Начинающие программисты часто спрашивают в личке — как правильно выбирать технологии? Что учить, чтобы не отставать от прогресса? Это — плохой вопрос, учить надо вовсе не технологии.

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

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

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

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