Как подружить разработчика и менеджера
Все компании, а тем более проекты, разные: отличаются задачи, подходы и команды. Их объединяет лишь одно — напряженность между менеджерами и разработчиками. В предыдущей статье я писал о том, что значит быть лидом (а это во многом значит быть менеджером). Наверное, такой опыт позволяет иначе взглянуть на ситуацию и попробовать копнуть тему глубже, чем «технари против гуманитариев» или «исполнитель против руководителя». А разобравшись, подумать, стоит оно того или нет.
В любой статье на DOU о менеджерах легко найдется хотя бы один из следующих комментариев:
- «Scrum не нужен, ведь деды пятилетками нейросети на перфокартах писали».
- «Менеджеры — дармоеды. Только требования дайте, а дальше мы сами».
- «Митинги — зло. Договаривайтесь без меня, но чтоб по-моему решили».
- «Софт-скилы для софт-людей. Лучше про код думайте».
«JavaScript не язык, Front-End не программист».
Читая примитивные высказывания с подобным посылом, становится стыдно за своих коллег. Поэтому цель этой статьи — не исправить матерых менеджероненавистников, а предложить заглянуть по ту сторону борды и понять, что там тоже есть жизнь. А дабы не скатываться к переходу на личности, сразу договоримся: разработчики и менеджеры здесь утрированы, возведены в абсолют и лишены любой индивидуальности. Я пишу о стереотипах и шучу только над ними.
Так уж получилось, что и менеджмент, и разработка формируют мазки, которыми человек рисует свою картину мира. Эти роли действительно сильно отличаются, и люди, которые в них преуспевают, тоже совсем разные. Но могут ли они найти общий язык и работать вместе не только продуктивно, но и с удовольствием? Да, если будут друг друга понимать. А путь к пониманию человека — это понимание мира, в котором он живет. С него и начнем.
Иллюстрации Каталины Маевской
Война миров
Программист пишет код. Код — это набор инструкций для машины. Хороший код — набор инструкций, который предусматривает почти все возможные события и определенным образом на них реагирует. Из этого следует, что программист все время создает последовательности действий, иначе говоря, алгоритмы — четко определенные логические цепочки. Это формирует некий тип мышления, в котором все заранее определено.
В то же время менеджер работает с людьми, которые меняют мнения, врут, ошибаются, несут чушь и верят в гомеопатию. При этом менеджер должен все это выслушать, собрать воедино, отсеять ерунду и придумать, как на этом деньги заработать. Таким образом, в мире людей ничего не определено, а можно опираться лишь на какие-то данные, пару мнений и свое чутье. Вроде бы все круто, но завтра конкурент зарелизил новую фичу — и ты в пролете. А программисты говорят тебе, что «антиэкранирование происходит из-за того, что переносчики сильного взаимодействия, которому подвержены глюоны, сами обладают цветовым зарядом и в процессе движения как бы „порождают новые глюоны из вакуума“, усиливая тем самым взаимодействие» (примерно так для менеджеров звучат рассуждения программистов о невозможности сдвинуть кнопку на 2 пикселя влево).
Поэтому при столкновении детерминированного мира программиста и вероятностного мира менеджера получается конфликт. В идеальной команде дискомфорт от надрыва парадигмы делится поровну: менеджер старается дать максимально точные и стабильные требования, а программист — построить фичу так, чтобы в случае изменений потратить минимум времени на их внесение. В реальной ситуации, конечно, бывает по-другому.
Вот простой пример: менеджер поговорил со стейкхолдерами, проанализировал рынок и решил, что продукту нужна еще одна таблица, допустим со списком котят. И вот он приходит к программисту и говорит:
— Друг, нужна таблица с котятами!
— Не вопрос. А сколько планируется котят в системе?
— Ну
— Хм, 1000 котят... Надо прикрутить пагинацию, сделать ленивую подгрузку, проверить на разных девайсах и скоростях... Нужен месяц.
Обычно дальше следует непереводимая игра слов, суть которой сводится к скукоживанию эстимейта мольбами, угрозами и различными стимуляциями. Причем здесь конфликт детерминированного и вероятностного мировоззрения? Притом, что стороны диалог-то вели, но не понимали друг друга.
Во-первых, огромный разброс по исходным данным в требованиях. Так пара десятков котят или пара тысяч? Откуда эти цифры? Поскольку менеджер живет в вероятностном мире, он видит возможность того, что котят будет именно 1000. Даже если такой человек будет один, а у остального миллиона пользователей будет от 5 до 10 котят. Почему бы не сделать продукт хорошим для всех?
А что услышал программист? Он услышал о лимите в 1000. Но ведь когда он будет писать код, то не сможет только чуть-чуть поддерживать определенный кейс. Его надо будет либо поддерживать, либо нет. Соответственно, он проектирует решение под 1000 котят, хотя в 99% случаев их будет на несколько порядков меньше. Отсюда и месяц.
При этом стоит лишь немного поменять диалог, и эта проблема исчезнет сама собой:
— Нужны котята в таблице!
— О’кей, сколько их?
— От 5 до 10. А если 1000, то насколько дольше будет?
— Ну для
— Много котов в одной таблице к беде. Делай для
Я очень часто замечаю, как простая фраза программиста: «А это реально нужно? Без этой маленькой фичи мы все сделаем за день, а с ней — минимум за неделю» — могла бы сэкономить уйму времени и денег, но она просто не звучит. Получается, программисты плохие? Нет. Как я писал выше, стороны должны поровну делить дискомфорт. И нормальный менеджер должен сам узнать, из чего состоит эстимейт и что доставляет больше всего проблем и в каждой конкретной ситуации давать именно те исходные данные, которые оптимальны для нее. А программист должен ему в этом помогать, подсказывая, что можно выбросить, экономя при этом ресурсы, а где дешево и сердито сделать с запасом.
Приведенный пример демонстрирует очевидную вещь: в большинстве проблем виновата коммуникация. О ней далее.
Мисс коммуникация
Менеджеры любят и умеют говорить. Это логично, ведь, по сути, это их основная работа. Программисты тоже любят и умеют говорить, но с машинами. Поэтому диалоги между ними часто напоминают попытку глухого объяснить немому, как выговаривать мягкий знак.
Повторюсь, дискомфорт от взаимодействия должны делить обе стороны. Поэтому и программистам, и менеджерам нужно понимать и принимать особенности друг друга, чтобы этот самый дискомфорт минимизировать. Имея это в виду, давайте искать проблемы.
Детали имплементации
Разработчики, внимание: далее следует жестокая правда! Менеджерам абсолютно, тотально, невероятно и глубоко фиолетово плевать на то, как вы реализуете фичу в техническом плане. Их интересует другое: насколько быстро, качественно и надежно вы ее сделаете. И эта осознанная невежественность — не капризы или лень, а необходимость. Это ваша работа, а им зачем влезать в нее? У них своей хватает. Ведь вы и сами беситесь, когда к вам лезут с советами.
Это редко выступает большой проблемой, но она отнимает много времени, особенно на митингах, а иногда становится причиной просто-таки детских обид разработчиков (что их не слушают, а значит, не уважают). Поэтому вы, программисты, оставьте технологии программистам, ибо они неинтересны менеджерам. А вы, менеджеры, если хотите быть не погонщиками, а любимыми господами/госпожами, дайте иногда кодерам высказаться. Сделайте умные глаза, задайте пару уточняющих вопросов и скажите в конце: «Круто!» Вам же с ними потом работать.
Синкапы
Как разработчик понимает, на каком этапе его фича или даже весь проект? Смотрит код. К сожалению, менеджеры так не умеют. Они вынуждены спрашивать у программистов. При этом они отвечают за этот проект: перед пользователями, клиентом, родиной. А очень сложно отвечать за что-то, не понимая, что там вообще происходит.
Отсюда эти вечные вопросы:
— «На каком ты этапе?»
— «Успеваешь уложиться в эстимейт?»
— «Получится залить сегодня на стейдж?»
Чаще всего эти вопросы задаются не с целью давления, как кажется разработчикам, просто менеджеры искренне не знают! Помню, как меня напрягало, когда в течение дня мне писала ПМ: «Привет! Как дела? Успеваешь доделать?» Сейчас я ее понимаю: есть обязательства и встречи с клиентами, на которых она должна либо показать, что обещали, либо объяснить, почему не успели. Это ее работа. Но для меня это выглядело как постоянный прессинг, особенно когда понимаешь, что с эстимейтом промахнулся.
Как минимизировать этот стресс, будучи разработчиком? Во-первых, перестать воспринимать эти вопросы как сомнения в своих навыках и просто отвечать как есть. А если видишь, что что-то идет не по плану, вообще написать первым. И менеджеру поможешь, и сам от лишних вопросов избавишься. Вот честно, лучше сразу написать: «Сегодня не отдам», чем сильно спешить, сделать плохо и отдать то, что крешнется на демо. А менеджерам нужно поменьше спрашивать, вот и все. Микроменеджмент до добра не доводит.
Назад в будущее
Еще одна проблема — это то, что программисты и менеджеры живут в разных эпохах. Если коротко, то тестировщики обитают в прошлом, программисты — в настоящем, а менеджеры — в будущем.
Так как менеджер курирует проект, он отвечает и за то, чтобы команда разработки не осталась без задач, особенно если этот самый менеджер заболеет, забухает или решит уйти в embedded. Поэтому он вынужден всегда быть даже не на шажок, а на целый шпагат впереди: пока программисты реализовывают этот модуль, он уже описывает следующий.
Так возникают ситуации, в которых каждый пытается перетянуть другого в свою временную линию:
- тестировщики дергают программистов в прошлое («Можешь глянуть? Я тут кликаю задачу, которую ты неделю назад двинул в QA, и...»);
- программисты тянут менеджеров в настоящее («Я тут читаю acceptance-критерии, и это какая-то дичь. Почему...»);
- а менеджеры тянут программистов в будущее («Нужно, чтобы ты взглянул на эту фичу и примерно оценил. И что значит дичь?!»).
Естественно, никому из участников процесса это не нравится, ведь их вырывают из зоны комфорта. Поэтому совет здесь универсальный и простой: раз этого не избежать, нужно это организовать. Договоритесь, кто, кого и когда может дергать на подобные активности, и будьте готовы на них отвлекаться. Отлично работает ставить подобные обсуждения на конец дня, когда разработчик может после митинга пойти домой, а не тратить снова пару часов на развертывание проекта у себя в голове. Кстати, раз уж мы об этом заговорили...
«Эй, ты не занят?»
Столько на эту тему сказано, а никто, похоже, не слушает. Представьте, что вы пытаетесь уснуть, и в тот момент, когда вы почти отошли в мир, где доллар по 100, а сыры по 10, вас трясут за плечо и спрашивают: «Извини, ты уже спишь?». И так раз 10 за ночь, причем еженощно. Разработчикам это ощущение знакомо: то же самое они чувствуют, когда входят в состояние потока, а их выдергивают фразой: «Ты сейчас занят?»
Честно, я не фанат всех этих сладких теорий о том, что программист — это краснокнижное животное, вокруг которого надо водить хороводы и петь йодлем. Но есть у него одна особенность: для продуктивной и качественной работы ему нужно время. Правильное время — непрерывное, как минимум 3 часа, на протяжении которых он сможет сосредоточиться на одной конкретной задаче. Обед, синкап, а иногда даже обычный вопрос о погоде ставят точку на текущем временном интервале, и его нужно отсчитывать заново. А тут есть проблемка.
Учитывая стандартный рабочий день, митинги, кофе и личные вопросы, чистого рабочего времени у среднего программиста всего пара-тройка часов. И если неудачно закинутая фраза отвлечет его как раз во время этих часов, продуктивность его работы над сложной фичей будет стремиться к нулю. Отсюда и раздражение самого разработчика, и недовольство менеджера перформансом последнего.
Решить это достаточно просто в 2020 году — с помощью мессенджеров. Менеджеры, тестировщики, а особенно другие разработчики, не дергайте человека вживую, даже если он сидит на соседнем стуле! Договоритесь об удобном всем канале связи и пишите туда. Будет время, он глянет и ответит. Нет — значит, ждите либо дергайте, но будьте готовы привести веские доводы в пользу такого решения.
Cloud microservice blockchain multi-tenant AI solution
Почти каждый менеджер, которого я знаю, в своей речи к месту и не к месту вставляет различные баззворды. Мне кажется, их на это вдохновляют разработчики. А менеджеры думают, что так с последними будет проще найти общий язык. Ну и звучит круто. Однако есть нюанс: надо все же понимать, что ты вообще несешь! :)
В любой индустрии, особенно связанной с инженерией либо технологиями, есть своя терминология. Причина ее появления проста: увеличить пропускную способность коммуникаций. Вместо того чтобы каждый раз давать определение чему-то, ты озвучиваешь устоявшийся термин, и все, кому он знаком, понимают, о чем ты. Это прекрасно работает до тех пор, пока термин для всех участников обсуждения значит одно и тоже.
Проблема в том, что часто термины объясняются другими терминами, а те — третьими и т. д. Классический пример — статьи на Википедии. Из этого следует, что недостаточно знать лишь определение того слова, которое ты использовал, нужно еще иметь представление о понятиях, которые с ним связаны. В случае с программистами это работает: мы все изучаем одни и те же алгоритмы, паттерны и подходы (в основном). Поэтому терминология у нас действительно экономит уйму времени, не лишая слова изначально заложенного в них смысла.
Но с менеджерами дела обстоят по-другому. Они слышат какой-то термин, гуглят его значение и, пробежав его глазами, вводят в свою речь, лишь отчасти понимая, что он на самом деле значит. И если изначально термины повышали эффективность беседы, помогая передавать больше смысла с помощью меньшего количества слов, то с таким подходом они дают абсолютно противоположный эффект.
Не самым плохим вариантом будет, если технический специалист, услышав термин от менеджера, просто уточнит, правильно ли он его понял. Но ведь не каждый раз так делать? Даже в моей практике бывало много ситуаций, когда мы с менеджером поговорили, вроде бы все решили, а потом оказалось, что говорили-то о разном! И одному гуглу известно, сколько человеко-лет сжигается подобным образом: когда кто-то просто захотел использовать термин, который не до конца понимает.
Если вы менеджер и решили использовать в разговоре с программистом одно из этих слов: кеш, блокчейн, микросервисы, АПИ, интерфейс, бэк-енд или клиент, то лучше объясните обычными словами, что вы имеете в виду. Иначе есть большой шанс, что получите вы совсем другое. Да и вообще, с умными словами не перегибайте: даже программисты часто друг друга не понимают, и то, что до сих пор выходят статьи с «простыми» расшифровками SOLID’а, яркий тому пример.
Мир, труд, скрам
Между программистами и менеджерами всегда будут конфликты. Потому что они люди. Люди находили причины съедать сердца друг друга (в буквальном смысле) задолго до изобретения аджайла, и вряд ли эта статья сможет на это повлиять. Однако часто ситуацию можно исправить, изменив наше отношение к ней. Вопрос лишь в желании. Дальше попробую быть корыстным.
Зачем программисту «дружить» с менеджером? Нравится нам это или нет, но берут нас на работу менеджеры (пусть и опосредованно — через других программистов), повышают нам зарплату и увольняют они же. Знать, что они ценят в разработчиках и как строить с ними продуктивные взаимоотношения, — прямой путь к быстрому росту, блестящей карьере и зарплате выше рыночной. Важно понимать, что я не предлагаю лебезить и заискивать перед ними (это уже выбор лично каждого). Я лишь говорю, что с большей вероятностью ты возьмешь на работу приятного тебе человека, который понимает, что ты делаешь и готов в меру своих сил тебе в этом помогать или как минимум не мешать. Его же ты и повысишь и ему же предложишь лишнюю тысячу, чтобы удержать. Поэтому программисту «дружить» с менеджерами очень полезно.
А зачем тогда менеджерам «дружить» с программистами? Потому что менеджер сам ничего не производит. Все успехи менеджера — это успехи его команды и результат ее непосредственной работы. Так что, если люди, которые эту работу делают, тебе симпатизируют и у вас налажена эффективная коммуникация, дело пойдет намного легче и быстрее. Также не стоит забывать, что рынок программистов сейчас очень горяч, и, если ты будешь относиться к своим сотрудникам плохо, они легко найдут другую команду с более адекватным руководством, а вот ты хороших разработчиков будешь искать долго.
Помимо всего этого, есть довольно простая причина жить дружно: так приятней. Ведь круто работать в дружном коллективе, где все друг друга понимают, поддерживают и помогают? Может, я и наивен, но стремиться к этому стоит.
Поэтому закончу цитатой Джима Джеффриса, которая в своей простоте прекрасно суммирует то, к чему я так долго веду: «Try not to be a cunt, and if you do that every day, you’ll be a good person».
Так что будьте good person, а остальное приложится. Ну а если не согласны, пишите в комментариях.
Классных вам проектов и легких апрайзалов! До новых виртуальных встреч!
