Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.
«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.
Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.
Однажды работник Демьян пришёл к хозяину дома и спросил:
— Мне всегда было интересно, почему ты мне платишь только 2 рубля в неделю, тогда как Лукьяну — 15?
Хозяин ничего не ответил, а только выглянул в окно и сказал:
— Кажется, там кто—то едет. Может это сено продают? Нам как раз нужно на зиму запастись. Пойди, погляди.
— Хорошо, сейчас.
Работник вышел. Буквально через минуту возвращается и говорит:
— Да, там сено продают.
— А откуда оно? Случайно не с Елисейских лугов?
— Я не знаю.
— Так сходи, спроси.
Снова вышел. Приходит:
— Всё верно, с Елисейских.
— А с какого укоса то сено?
— Откуда мне знать?
— Как это «откуда»? Вернись и узнай.
Через минуту приходит к хозяину:
— Сказали, что с первого укоса.
— Хорошо. А почем продают?
— Я не спрашивал…
— А надо бы. Узнай, пожалуйста.
Пошел работник. Приходит к хозяину и говорит:
— По 25 рублей за воз.
— Многовато… А подешевле не отдадут?
В этот момент их разговор прервал Лукьян, который только что вошел в комнату.
— Хозяин, прошу прощения, что перебиваю, но там сейчас везут сено с Елисейских лугов. Оно первого укоса, продают по 25 рублей, но у меня получилось сторговаться на 18. Они уже заехали во двор, выгружают.
Хозяин усмехнулся и повернулся к своему первому работнику:
— Ну что, теперь тебе понятно, почему я плачу тебе 2 рубля, а Лукьяну 15?
Демьян и Лукьян одинаково компетентны в техническом плане: они оба могут сходить и спросить, и даже поторговаться, но Демьян неинициативен и заставляет барина своей неинициативностью и неавтономностью постоянно себя дёргать и принимать за себя решения. А значит и ценность Демьяна для барина не очень высока, потому что время, а главное — внимание руководителя обычно стоит дороже времени сотрудника. И если сотрудник экономит время и внимание руководителя, то он становится ценным для него. И эту ценность можно потом обменять на более высокую зарплату или должность, более интересную и ответственную работу и т.д.
Как вы думаете, кого из двух разработчиков повысят: того, который делает всё по ТЗ, или того, который прилагает мозг?
Конечно же требования к разработчикам сильно зависят от того, кто находится в подчинении. Для некоторых подчиненных требовать открытости и творческого подхода не просто бесполезно, но и вредно. Если нам нужны «биороботы», то основные требования сводятся к «делать всё по должностной инструкции, шаг влево—вправо — наказание». А если нам нужны — и у нас они есть — люди, способные к сложной творческой работе, — программисты, — то требовать от них включать голову кажется правильным требованием.
И когда к руководителю — и если он хороший руководитель (а к плохим я бы не советовал ходить работать ;)), — приходит на собеседование кандидат, то руководитель всегда старается понять, даже на техническом собеседовании, подходит ли человек? И задает себе, например, такие вопросы:
Смогу ли я ему ставить задачи и не тратить на это много времени?
Буду ли я получать от этого человека обратную связь?
Будет ли человеку интересно заниматься тем, чем мы занимаемся?
Смогу ли я с ним договариваться?
Умеет ли он подчиняться?
Впишется ли он в команду? В какой роли?
Не будет ли он «кошмарить» моих тимлидов и пытаться занять их место? Если им будет с ним некомфортно, то нужен ли мне такой человек?
Насколько его опыт пригодится в нашей работе? В нашем проекте?
И так далее. И очень часто эти рассуждения происходят в подкорке.
То есть для роста (и не только зарплаты) разработчику, очевидно, имеет смысл развиваться в разные стороны. Лично я при найме и составлении плана развития людей смотрю на четыре основных типа компетенций: технические навыки, продуктовое мышление, коммуникативные и организационные способности.
И даже с техническими компетенциям не всё так просто. Как показывает практика фреймворки меняются, а базовые знания — нет. Поэтому лучше отдавать предпочтение тем людям, которые имеют системное техническое мышление. Если оно есть, то выучить любой фреймворк или язык не представляется суперсложной задачей. Операционные системы и основополагающие протоколы за последние лет 10—20 не сильно изменились, а вот сколько родилось и умерло фреймворков для Javascript — не пересчитать. Основные паттерны работы с кодом и декомпозицией как были актуальны 20—30 лет назад — например, тот же DDD, — так и остаются. Разве, что в DevOps’е случилось несколько больших революций, но в этом случае формируется целая индустрия.
С продуктовым мышлением более или менее понятно. Готов ли человек, и интересно ли ему погружаться и смотреть на мир глазами клиента? Может ли он придумать простейшее продуктовое решение (не обязательно идеальное, достаточно просто рабочее)? Остановится ли он, если будет делать полную фигню?
Пример. Программист получает задачу «добавить ещё одну такую же табличку ниже существующей» делает такую же табличку и добавляет её в стык к существующей (так что между ними только пара пикселей). Выглядит это ужасно, и очевидно, что придётся переделывать. Но разработчик считает, что это проблема ТЗ и ему нужны были макеты.
Знание предметной области и её ограничений является ключевым фактором, который помогает разработчику писать хороший код и придумывать хорошую архитектуру. Эрик Эванс посвятил этому целую книгу. И пусть разработчик обладает очень крутыми техническими навыками, но если его интересует только ТЗ, а не сам продукт, то весь хороший, замечательный, идеальный код этого разработчика придётся много раз переписывать.
Коммуникативные способности также являются во многом определяющими. И хорошие коммуникации — это не смешно шутить с Ирочкой из соседнего отдела возле кулера или сплетничать в курилке, и вообще быть душой компании. Хорошие коммуникации — про способность управлять ожиданиями коллег, про способность быстро и эффективно договорится, максимально исключать недопонимание. И про то, как не погружаться в пучины бессмысленных споров и конфликтов, когда это не ведёт к результату. Хорошие коммуникации на самом деле про то, чтобы нужно было как можно МЕНЬШЕ коммуникаций, собраний, совещаний. Чтобы как можно МЕНЬШЕ говорить, а оставшееся время тратить на работу, имеющую на самом деле ценность.
Организационные навыки (их ещё можно назвать управленческими) важны не только на работе, но и в жизни. Доводить дела до конца — крайне полезный навык. Кажется, что это не так уж и сложно (на самом деле нет). Разделить слона на лягушек — декомпозировать задачу, спланировать, когда и что делать, организовать работы, — договориться с кем надо, и «съесть лягушек» (сделать задачи) — звучит просто. Но почему—то в жизни случается не так. О договоренностях забывают. «Ты обещал договорится с фронтами про формат API до конца дня, договорились?» — «Ой, забыл». Задачи декомпозируют и планируют по принципу «сначала то, чем приятней сейчас заниматься» или «что попалось первое на глаза, то и делаем». «Ой, я тут в модуле увидел плохой код и решил его порефакторить, и так получилось, что я переписал полпроекта».
Есть ложь, наглая ложь, а есть «Эта задача у меня займет четыре часа» из уст разработчика. Скорее всего, эта задача займет 4 часа плюс минус день, а то и два. И это не всегда проблема разработчика. Вообще, «скажи мне, сколько у тебя займёт эта задача» — классическая менеджерская манипуляция, потому что менеджер спрашивает обещание (commitment), а разработчик говорит оценку (estimate). Но в любом случае приходится давать оценки, и чем лучше они соответствуют реальности, тем легче и спокойнее всем живется — и это крайне полезный навык. А вот как оценку правильным образом донести до менеджера, и нужно ли её перезакладывать, это уже вопрос коммуникаций и управления ожиданиями. Если руководитель хороший, то скажи как есть; если нужно пообещать сроки, то заложи буфер на случай рисков и неопределённостей.
В общем, развиваться надо в разные стороны, и не потому, что так говорит Agile или твой начальник, а потому, что так увеличивается твоя эффективность, а значит и ценность на рынке.