Путешественники на воздушном шаре пролетают мимо высокой горы, где видят одинокого пастуха.
– Скажите, милейший, где мы находимся?
– Вы находитесь на воздушном шаре!
Это прекрасный классический пример общения менеджера-гуманитария с разработчиками-технарями, который я привожу почти на каждом семинаре. Он иллюстрирует ситуацию, когда на естественный человеческий вопрос программисты дают убийственно чёткий, правдивый и абсолютно бесполезный ответ.
Со стороны такое поведение разработчиков действительно выглядит как очевидная демагогия, завышенное чувство собственной важности и банальный эгоизм. Сейчас я провожу довольно много семинаров для разных компаний, на которых коллеги (и руководители, и разработчики) делятся со мной аналогичными проблемами.
На самом деле программист, скорее всего, не желает вам зла – он просто воспринимает вопрос и даёт ответ в своей структуре восприятия окружающего мира. В этом посте я в очередной раз поделюсь с вами порцией моего практического опыта и советами – как не-программисту руководить программистами, находить с ними общий язык и добиваться результата.
1. Используйте ключевое слово в вопросе.
“- Почему эта бага номер NNN до сих пор не исправлена?!!” – типичный вопрос для руководителя, недостаточно чётко владеющего ситуацией внутри разработки продукта. Особенно если этот вопрос сдобрен приличной дозой эмоций и агрессии – такой прозрачный намёк, что эти быдлокодеры тут зажрались и играют в игрушки вместо исполнения своих прямых обязанностей.
В ответ вы получите, скорее всего, чёткое и развёрнутое объяснение: бага не решена потому, что ей присвоен приоритет 14, а с приоритетом 13 и выше у нас ещё 28 задач, 14 из которых мы должны выполнить в релизе 10.4.8, а так же у нас ещё 40 заявок от важных партнёров с более высоким приоритетом, и так далее.
Вы получите в ответ что угодно, только не решение проблемы. “- Что за демагогия, разве вы не знаете, что бага NNN это заявка от супермегаважного партнёра ABC?” – “Эээ, разве, я вижу что этот партнёр у нас третий по рейтингу” – “У вас нет никакой клиент-ориентированности!” – “Нет, посмотрите, мы закрываем в два раза больше заявок от клиентов” – “Вы забыли, кто вам здесь деньги платит!” – “Мы работаем по согласованному плану, в чём именно заключается претензия?” – ещё несколько дней такого футбола от менеджера к разработчикам напрочь выводит из строя весь отдел. А поскольку девелоперы зачастую люди неординарные, они начинают изощряться в словестной полемике.
Так менеджеры становятся идиотами.
Менеджеры, запомните! В вашем таком поведении нет ни малейшего смысла. Разработчики смотрят на вас как на эмоционального идиота, который сам не понимает чего хочет и даже не может сформулировать претензию. Это напрочь роняет ваш авторитет. Дальше вам одна дорога – плакаться вышестоящему начальству, что подчинённые вам не подчиняются.
Корень проблемы: менеджеры формулируют претензии в точности так же, как их ругали в детстве их родители.
Разве тебе не стыдно чавкать за столом? Нет, не стыдно. Или – да, не стыдно. Оба этих ответ равнозначны, и оба не являются решением проблемы, оба не приносят желаемого результата. Вменяемые родители говорят мягко, но коротко и однозначно: не чавкай.
Решение проблемы: выносите суть проблемы в ключевое слово и будьте конкретны.
“Решите багу NNN в ближайшее время. Можно отодвинуть все остальные задачи вплоть до недели”.
В одном простом предложении заключена конкретная решаемая задача, и соглашение о том, чем придётся пожертвовать. Если программисты спросят “почему” – расскажете им про вип-клиентов и клиент-ориентированность. Но поверьте на слово – скорее всего и не спросят, а молча решат вашу задачу. Этот нехитрый приём помогает самым невзрачным менеджерам завоёвывать любовь самых суровых девелоперов.
2. Добавляя задачи, добавляйте ресурсов.
Команда разработчиков со стороны выглядит как бездонный бурлящий котёл, в котором происходят какие-то загадочные процессы. Легко может показаться, что при возникновении какой-то новой задачи достаточно бросить её туда, и она там сама рыбкой выплывёт – пройдёт нужные инстанции, сама себе спроектируется, решится, и даже протестируется. В конце концов, разве вы не за это деньги платите всем этим людям?
Нет.
Если ваш тимлид не полный идиот, он уже загрузил всех на 100% и даже на 200% – то есть уже существует определённая очередь задач. Если бы было нечего делать – он бы придумал сам или спросил у вас. Однако в подавляющем большинстве случаев команда загружена в N раз больше, чем может переварить. Любая задача потребует дополнительных ресурсов. Вот блять любая, поверьте на слово. Потребуется либо человеческий ресурс (добавить людей), либо ресурс времени (отложить другие задачи).
А что вы там в предыдущей главе говорили про клиент-ориентированность и приоритеты? Ага, вот-вот. Команда-то занята уже очередью задач для супермегаважных клиентов. Поэтому каждый раз, когда вы вбрасываете новую задачу и встречаете некое противодействие, задайте себе простой человеческий вопрос “почему”. Уточню, не “какого %уя”, а “почему”. Да потому, блять, что люди работают по определённому плану – а значит они взяли на себя ответственность, обязательства, дали обещание выполнить такие-то задачи к таким-то срокам.
А тут вы пришли со своей мега-фигнёй. Которая потребует отложить какие-то задачи на (пока) неопределённый срок. А значит все эти суперважные партнёры, не получив во время решений своих заявок, скажут что? Да пи%%аболами они назовут этих разработчиков, вот что. А разработчики упомянут хорошим словом вас, дорогой менеджер.
Корень проблемы: игнорирование известной истины о том, что на любую задачу нужен менеджер и ресурсы. Всегда кажется, что ресурсов и так много. Это ложь и самообман.
Решение проблемы: ставя новую срочную задачу, либо чем-то жертвуйте, либо добавляйте ресурсов.
“Я предлагаю поручить Васе Пупкину заняться задачей X на ближайшие 4 месяца. Насколько нарушится график релизов из-за этого? А если мы добавим в команду стажёра Петю Васькина, как это повлияет на ситуацию?”
Вы можете удивиться, но добавление стажёра Пети Васькина может не только не ускорить процесс, а затормозить его. Почему? Спросите в комментариях, я отвечу.
3. Меняя курс, уведомляйте всех.
Стратегические решения принимаются где-то (условно) за закрытыми дверями, среди людей к которым тянутся ниточки от всей компании в целом. Эти решения могут молниеносно меняться даже в голове одного единственного человека. А что делает руководитель после того, как принял решение? Правильно: в лучшем случае он идёт и отдаёт распоряжение. А в худшем? В худшем случае он уверен, что всё всем и так понятно и очевидно.
Мы сейчас оставим в стороне психологическую суть явления, когда руководитель думает что в штате работают одни телепаты. Поговорим о том, что происходит когда решение о смене курса долетело-таки до разработчиков.
Во-первых, если вы внимательно прочитали предыдущую главу, то вы помните что смена курса автоматически вынуждает разработчиков нарушить свои текущие обязательства перед клиентами. Если вы не защитите их от чувства вины (а зачастую – и от тухлых яиц, летящих из зрительного зала) то в вашу сторону будут направлены лучи ненависти максимальной концентрации.
Во-вторых, вы прослывёте человеком, который не держит слово. Частая смена приоритетов похожа на обычную эмоциональную истерию, и выглядит так как-будто у компании нет твёрдых устоев, принципов, и стратегии развития. Бросание из стороны в сторону демотивирует людей, потому что они начинают задумываться – а насколько стабильно моё текущее место работы? Сегодня мы делаем одно, завтра другое, послезавтра половину уволят – не стоит ли поискать место поспокойнее?
В-третьих, и это самое печальное, разработчики начнут подсознательно бояться решать серьёзные длительные задачи, и будут акцентироваться на различных мелочах. Сколько раз я слышал на семинарах жалобы руководителей небольших компаний: дескать, они (девелоперы) там сидят, что-то делают и делают, а в отчётах за итерацию полный пшик – какой-то скучный список мелочей. Почему конкуренты достигают звёздных высот?
Да потому лишь, что разработчики должны чувствовать себя защищёнными на тот случай, если работа над большой задачей продлится дольше, чем предполагалось. Немалую долю своего авторитета в командах я завоёвываю, защищая девелоперов от постоянного града упрёков в стиле “ну блять сколько можно, заканчивайте уже”. Безусловно, компании не нужны абстрактные теоретики, которые из каждой мелкой частной задачи делают универсальный комбайн. Но если важная долгая задача не доведена до конца, программист будет домысливать её в голове и тайком доделывать в продукте. Он не успокоится, пока не освободит голову от этого. Представьте, как это отразится на его настрое, энтузиазме, продуктивности. Кому как, а лично мне нужны девелоперы, которых прёт от своей работы, и которые приступают к каждой следующей задаче со свежей башкой.
Корень проблемы: неожиданная смена курса вынуждает разработчиков нарушить обязательства и оставить часть задач недоделанными.
Решение проблемы: меняйте курс в точках покоя.
На свете есть прекрасный механизм – итеративная разработка. Если у вас итерации чётко поставлены – меняйте курс перед началом очередной итерации, но блять не посреди неё. Если у вас итерации не выделены, делайте это в самом начале недели, буквально с утра понедельника. Лучше даже в середине пятницы сказать об этом тимлиду, чтобы к понедельнику он уложил всё в голове и перестроил планы.
Резюме:
Вы прочитали три очередных совета о том, как стать хорошим менеджером и создавать успешные программные продукты. Конкретно формулируйте вопросы, манипулируйте ресурсами, и позволяйте людям доводить дело до конца. Если вам есть что добавить – welcome в комментарии или личную почту.