Этот спор я слышу столько, сколько работаю в IT. Одни говорят: менеджер обязан уметь программировать, иначе он не понимает, чем руководит, и разработчики будут вешать ему лапшу на уши. Другие отвечают: менеджер должен управлять людьми и сроками, а код пусть пишут те, кто умеет, иначе он начнёт лезть в каждую строчку и мешать. Самое забавное, что правы обе стороны. Просто они отвечают на разные вопросы.
Мой ответ короткий: писать код менеджеру не обязательно. Понимать, как устроена система, обязательно. Это разные навыки, и путать их опасно в обе стороны.
Тренер не обязан играть лучше игроков
Возьмите футбольного тренера. Многие великие тренеры были посредственными игроками, а некоторые не играли на высоком уровне вовсе. Никто не ждёт, что тренер выйдет на поле и забьёт гол лучше своего нападающего. Но тренер, который не понимает игру, не видит, почему защита разваливается, не чувствует, где команда теряет темп, долго не продержится. Его работа не играть, а видеть игру целиком и принимать решения, которые игрокам с поля не видны.
С менеджером в разработке то же самое. Ему не нужно писать код лучше программистов. Но ему нужно понимать, из чего состоит система, как связаны её части, почему одна задача занимает час, а внешне похожая на неё требует недели.
Зачем менеджеру технические знания
Без базового технического понимания менеджер оказывается в положении человека, который покупает машину и не знает, что такое двигатель. Ему можно рассказать что угодно.
- Отличать реальную сложность от сказки. Когда разработчик говорит «это займёт три недели, потому что придётся переделывать модель данных», менеджер должен хотя бы примерно понимать, правда ли это. Не чтобы уличить, а чтобы задать правильный уточняющий вопрос.
- Оценивать вместе с командой. Оценки сроков без понимания архитектуры превращаются в угадайку. Менеджер, который понимает систему, видит риски заранее: здесь интеграция с внешним сервисом, здесь старый код, здесь миграция данных.
- Переводить с языка клиента на язык разработки и обратно. Это, пожалуй, главное. Клиент говорит «добавьте кнопку», а менеджер должен понять, что за этой кнопкой новая роль пользователя, права доступа и три новых сценария.
- Говорить с техлидом на одном языке. Не обязательно на его уровне, но хотя бы с общим словарём: база данных, API, деплой, миграция, кэш.
Есть старая шутка про руководителя, который просит программиста: «Сделай, чтобы приложение по фотографии определяло, где сделан снимок, и ещё, чтобы определяло, есть ли на ней птица». Первое делается за час, второе когда-то требовало исследовательской группы и пяти лет. Со стороны обе задачи выглядят одинаково. Менеджер, который не чувствует этой разницы, будет постоянно обещать клиентам невозможное или пугаться простого.
Менеджер не обязан уметь чинить двигатель. Но он обязан слышать, когда двигатель начинает стучать.
Опасность программирующего менеджера
Теперь о другой стороне. Я видел много менеджеров, которые пришли из разработки, и у них своя болезнь. Когда проект горит, у них чешутся руки. Они садятся и пишут код сами: так быстрее, так надёжнее. В этот момент проект теряет менеджера. Никто не разговаривает с клиентом, никто не следит за сроками, никто не видит, что соседняя задача тоже горит. Капитан спустился в машинное отделение и крутит гайки, а корабль идёт без управления.
Вторая болезнь мельче, но неприятнее: программирующий менеджер склонен навязывать команде свои технические решения. «Я бы сделал вот так». Команда перестаёт принимать решения сама и начинает угадывать, как сделал бы начальник. Это тот же самый микроменеджмент, только в технической обёртке.
Лучшие менеджеры, которых я встречал, умели держать эту границу. Они могли открыть код и прочитать его, могли понять схему базы данных и поспорить о решении на ревью. Но в рабочее время их руки лежали не на клавиатуре разработчика, а на штурвале проекта. Технические знания они использовали как зрение, а не как инструмент.
Что меняется с приходом AI
Сейчас вопрос приобрёл новое измерение. С AI-инструментами менеджер, который не умеет программировать, может за вечер собрать работающий прототип. Это прекрасно для того, чтобы показать идею, проверить гипотезу или объяснить команде, что имеется в виду. Мы в Ingello активно этим пользуемся: прототип за дни вместо месяцев меняет разговор с клиентом.
Но тут же появляется ловушка. Прототип, собранный за вечер, выглядит как готовая система, и менеджеру кажется, что осталось чуть-чуть. А между демонстрацией и продакшеном лежит всё то, чего не видно на экране: безопасность, данные, нагрузка, поддержка. Именно здесь техническое понимание снова становится критичным. Не для того, чтобы писать код, а для того, чтобы не принять декорацию за здание.
Что сделать завтра
Если Вы менеджер без технического бэкграунда, попросите своего техлида провести для Вас часовую экскурсию по системе: нарисовать на доске, из каких частей она состоит, где хранятся данные, как они движутся, что с чем связано. Задавайте глупые вопросы, это нормально. Через несколько таких встреч Вы начнёте слышать стук двигателя. Если же Вы менеджер из разработчиков, запишите на неделю, сколько часов Вы потратили на код, а сколько на управление. Если первая цифра больше второй, подумайте, кто в это время стоял у штурвала.
