Опять (сраный) созвон

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

Картинка смешная, но лично у меня она навевает печаль и грусть. 

И грустно мне по двум причинам.

1. Причина для печали разработчика.

Мем явно программистский. Причем от программиста на удаленке. 

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

И если это знать, то становится ясна боль программиста, который в условиях "удаленки" и так старается не отвлекаться на домашние дела, и хоть что-нибудь напрограммировать, так его еще отвлекают созвонами ср...е менеджеры и scrum-мастер. Ну совершенно невозможно работать! 

2. Причина для печали менеджера.

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

Между тем, как правило, вся ответственность за результат лежит на менеджере. А если это Scrum-мастер, то ему обязательно прилетит от вышестоящего руководства за неэффективность и непрозрачность работы команды, так как обеспечивать и то и другое - его прямая обязанность. 

Кто виноват и что делать?

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

Лично мне менеджеров и Scrum-мастеров в этой ситуации жаль гораздо больше, чем разработчиков. Не зря одна из самых старых книг по управлению разработчиками называется "Как пасти котов" (Herding Cats: A Primer for Programmers Who Lead Programmers) и не смотря на то, что написана она была аж в 2002 году, актуальности она не потеряла до сих пор. Программисты - как коты. Делают что хотят и когда хотят, часто считают себя пупом земли, и самыми умными на планете (уж точно умнее "этих менеджеров"), принудить их что-то делать - опасно, потому что они в ответ могут нагадить в код и уволится, а потом эти "закладки" начинают вонять, или ещё чего хуже.

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

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

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

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

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

А на что же похожа работа менеджера?

Задачи менеджера гораздо более многочисленны и разнообразны, чем задача программиста. Главное что нужно сделать программисту - это написать код, который будет работать без "багов", и давать тот результат, который нужен заказчику.

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

С другой стороны, в отличие программиста, менеджер имеет гораздо больше степеней свободы при реализации своих задач. Там где для программиста стоит выбор из конечного числа технологий, инструментов, алгоритмов, для менеджера пространство выбора практически неограниченно. Взять хотя бы задачу "написать требования". Можно написать требования самому или делегировать эту работу аналитику. Или взять ТЗ от прошлой похожей задачи, и "докрутить" его для новой. Можно в стиле Scrum собрать "грумминг" с разработчиками и используя фасилитационные практики проработать с ними задачу, закрепив это в виде описания бизнес-сценария используя стикеры на доске, а по итогу этого общения положить все это на бумагу в виде задания. Можно написать общую постановку задачи, а можно включить в нее архитектурные требования и эскизы. Можно вообще не писать ТЗ, а сесть рядом с программистом и вместе с ним "на коленке" разрисовать задачу от начала до конца, так чтобы по итогу все поняли одинаково, что нужно сделать, и как этом можно реализовать. Можно скормить описание задачи ChatGPT, дать ему задачу написать ТЗ, а потом отдать на корректировку и доведение до ума аналитикам и разработчикам. Можно придумать и вспомнить еще сотню способов как выполнить задачу "написать ТЗ".

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

А это значит, что пространство вариантов в работе менеджера гораздо, ГОРАЗДО больше, чем в работе программиста.

Количество коммуникаций

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

В то же время, количество вовлеченных сторон и систем, с которыми должен взаимодействовать менеджер для выполнения своих задач - несоизмеримо выше.

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

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

Вывод

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

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

P.S. Берегите друг друга. И нервную систему тоже