Видео доклада: Youtube-канал Егора Бугаенко.

Егор давно в разработке софта и видит одну и ту же проблему, которая становится тенденцией в современном менеджменте:

Менеджмент не трансформируется, а деградирует.

Менеджмент вместо функции управления, вместо помощи участникам проекта и организации их работы, превращается в бесполезную высокооплачиваемую прослойку, ничего не делающую. В Америке и Европе, считает Егор, немного больше даже. Более того, на конференциях и докладах спикеры даже пропагандируют эту деградацию, называя ее Agile. Егор считает, что это - не Agile точно, и ничего против Agile Егор ничего не имеет: он готов подписаться под всеми двенадцати пунктами Agile-манифеста, кроме шестого - “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

Егор выделяет четыре основные проблемы современного менеджмента.

1. Ответственность vs корпоративные ценности

Современные менеджеры заменяют ответственность корпоративными ценностями, тогда как менеджмент должен распределять ответственность между участниками проекта. Вместо четко прописанных инструкций и описаний задач каждому человеку менеджеры предлагают нам командные тренинги и игры и учат нас быть ответственными за общий результат. Нас учат отвечать “ни за что”. Егор считает, что необходимо каждому участнику проекта давать личные метрики эффективности и фидбек на основе работы каждого отдельно взятого члена команды. Менеджеры же пытаются привить мысль о том, что

либо команда целиком выиграла, либо целиком проиграла.

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

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

2. Управление проектами vs стрессоустойчивость

Современный менеджер в принципе не компетентен. Менеджер проекта должен:

  • анализировать риски
  • управлять временем
  • управлять скоупом работы
  • управлять ресурсами

Но Егор видит, что чаще всего на место менеджера в IT-сфере попадают просто более стрессоустойчивые разработчики. Эти современные менеджеры - просто люди, которые дольше сидят на работе, на которых можно легче “кричать”, просто люди, которые способны выдержать больше давления:

  • ”Теперь ты не программист, а менеджер, потому что когда все мы выходили в субботу, все остальные расстроились, а ты - не расстроился и сидел допоздна”.
  • ”Ты умеешь разговаривать с клиентом, когда клиент кричит на тебя по телефону, ты не бросаешь трубку, а слушаешь его до конца. Ты - прекрасный менеджер”.

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

3. Личная мотивация vs командный дух

Правильный менеджмент должен уметь дать разработчикам личную мотивацию и разбираться в вопросах мотивации. Он должен делать так, чтобы каждый участник команды, преследуя и достигая личные цели, делал ценный вклад в общее дело. Но вместо этого современный менеджмент продвигает идеи корпоративных ценностей и value. Вместо того, чтобы признать тот факт, что все мы работаем за деньги, и нам нужно связать нашу личную мотивацию с мотивацией общего проекта, вместо этого нам говорят “Value” и ставят главными мотиваторами для нас внешние показатели всей компании. Иначе говоря, программисту, пришедшему на работу и отвечающему за реализацию конкретной фичи в продукте, менеджмент собирает общее совещание на 2 часа и 150 человек рассказывает, куда идет их компания в последующие пять лет. В итоге лучшие профессионалы из таких компаний уходят, потому что профессионалы честные и жадные.

Профессионалы хотят, чтобы за их труд платили по-честному, они не хотят “кушать” эти корпоративные ценности, которые ничего лично для них не значат.

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

4. Документооборот vs митинги

Современный менеджмент не умеет правильно организовать документооборот - обмен информацией между людьми. Вместо этого современный менеджмент предлагает нам митинги. Передача знаниями должна происходить дисциплинированным способом через документы, тулзы, электронные средства. Но менеджеры не умеют это организовать, они полагаются на митинги и экспертов. Иначе говоря, такие менеджеры знают, что “есть вон там программист, который уже три года работает, вот он все знает, обращайтесь к нему”. Особенно ярко эта ситуация проявляется, когда в команду приходят новички: новичок пытается погрузиться в проект, но вместо этого ему предлагают “пообщаться вон с тем экспертом”. “В чем же тогда роль менеджмента?”, риторически спрашивает Егор.

(Современные) менеджеры в этой ситуации лишь наблюдают за процессом, ремонтируют кондиционеры и ставит кофемашины.

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

Егор даже видит иногда, как такие современные менеджеры гордятся своими экспертами. Они говорят: “У меня есть такой классный программист, на котором держится весь проект”, но Егор считает, что этими словами современные менеджеры расписываются в собственном бессилии. В итоге огромное количество денег и времени тратится на бесконечные митинги, а знания теряются, когда “эксперты” уходят из проекта.

Некомпетентные лентяи и капризные рабы

Возможно грубо звучит, но Егор считает, что в сложившейся ситуации виноваты два типа людей:

  • “некомпетентные лентяи” на позициях менеджеров, которые развешивают лозунги компании на стенах и продвигают корпоративные ценности вместо управления;
  • “капризные рабы” на уровне исполнителей, которые приходят в офис и сидят с девяти до пяти. получают зарплату за месяц и капризничают, когда им не хватает денег.

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

Егор считает, что проектный менеджер должен строиться не на корпоративных ценностях, а на том факторе, который можно описать цитатой:

Честный ребенок любит не маму с папой, а трубочки с кремом, а честный матрос хочет не служить, а спать. (с) Контр-адмирал В.Г. Доброскоченко

Правильный менеджмент в компании Егора Бугаенко

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

  1. Ставить только персональные задачи. Программист, ответственный за задачу, не может сказать, что он “не сделал задачу потому что…”, она либо сделал ее, либо нет.
  2. Открывать метрики производительности. Каждый участник должен видеть, почему он лучше или хуже своего коллеги и как ему подняться на ступень выше и получать больше денег. Егор не скрывает эту информацию, а программисты уважают эту открытость и честность.
  3. Платить только за результат. Закрыл тикет - получил оплату.
  4. Никаких офисов и митингов. Каждый участник сидит кто где хочет, и нет необходимости сидеть в одном месте.

Построение такого процесса - непростая задача, над ней нужно работать. Менеджер - это не о толерантности или корпоративных ценностях. Менеджер - это диаграммы Ганта, анализ рисков и планирование времени. И когда на конференции заявляют, что задача менеджера - донести корпоративную ценность до исполнителей на нижнем уровне, особенно когда “они устали”, то верить этому не стоит, ведь правильный менеджмент - не об этом.

Вопросы из зала

Как рассчитываются количественные показатели эффективности программистов у вас?

Одна из метрик - это время решения задач. Учитывая, что тикеты разбиты в среднем на небольшие объемы работы (1 час, по заявлению Егора), то можно сравнить затраченное время программистов друг с другом и понять, кто лучше работает, а кто - хуже. Другая метрика, которую использует Егор, это количество закрытых задач в единицу времени. Егор считает, что метрики могут быть любые, но одно ясно точно:

метрики должны быть всегда.

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

Это и есть задача менеджера - поделить объем работы на маленькие тикеты. Неграмотный менеджер просто говорит разработчикам: “Вот тебе большая задача, сам с ней разберись”, а грамотный менеджер умеет находить способы поделить эти большие задачи на маленькие. И только тогда появляется возможность управлять сроками и рисками. Как можно поделить задачи? Как один из вариантов, Егор предлагает позвать разработчика только лишь поделить задачу на мелкие “кусочки”. Если у менеджера в проекте две-три большие задачи на спринт, то это не менеджер, а надсмотрщик. Управлять большими задачами практически невозможно. Выдал тикет - получил результат, и это повторять как можно чаще.

Но зачем тогда менеджер нужен, если этот самый разработчик, которого позвали поделить тикеты, может сам передать их остальным участникам команды?

Действительно, может показаться, что менеджер не нужен. Что можно выдать объем работы команде и сказать: “Вот вам проект, разберитесь там сами, только не поругайтесь.”

Менеджер нужен для того, чтобы дать информацию тому, кто платит за проект, о том, когда мы его закроем.

Это и есть главная миссия менеджера, без менеджера нам эту информацию нам никто не даст.

Должен ли проектный менеджер обладать техническими знаниями, чтобы верно оценить сроки проекта?

Егор считает, что проектный менеджер не должен обладать техническими знаниями, что они ему мешают. Чем больше технических знаний, тем больше они ему мешают заниматься управлением. Менеджер должен уметь использовать ресурсы верно: привлекать одних людей для разбиения объема работы на мелкие тикеты, давать другим людям оценивать эти тикеты, а третьим - имплементить их.

Как найти грамотного менеджера? Как понять, кто хороший менеджер, а кто - плохой?

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

Не демотивирует ли сотрудников метрика рейтинга: в этом месяце он первый, а в следующем - десятый.

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

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

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

Программисты обычно интроверты, менее социальны, и поэтому они получают низкие оценки.

Еще пример приводит Егор. Его как-то позвали повысить производительность группы тестировщиков в одной европейской компании. Он пришел в команду и предложил им внести метрики производительности. Егор мало что понимает в тестировании, но понимать, кто лучше работает, а кто хуже - нужно, и сделать это можно только через систему метрик. И он предложил такую метрику: кто больше найдет багов с учетом их сложности в неделю, тот и лучше тестировщик. Один из тестировщиков команды работал давно и считался хорошим специалистом, а остальные - молодые ребята. Через неделю посчитали баги, и оказалось, что молодые ребята нашли в среднем по двадцать багов, а “старожил” - один. Егор спрашивает его “как так получилось”, на что в ответ старожил заявил, что метрика не отражает реальности, что у него много других задач и что метрику нужно изменить. Егор сказал, что его главная задача - находить баги в продукте, и поэтому метрику менять не будет. На следующей неделе ситуация повторилась: у всех по двадцать, а у старожила - один. Егор предложил вышестоящему менеджменту уволить этого тестировщика, потому что он не слушает своего менеджера - Егора - и не выполняет свою работу - не находит баги. Егор рассказывает, что поднялся шум и что менеджмент не захотел его увольнять, ведь “он так давно работает у нас”.

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

Как быть с заказчиками, которые привыкли к стрессоустойчивому “современному менеджменту”, а не правильному?

Егор считает, что это - трудная задача, и не всегда выполнима. Иногда бывает, что заказчик звонит Егору и говорит, что хочет со всеми разработчиками устроить конференц-колл. Егор спрашивает его: “зачем митинг? Напиши полстраницы текста что тебе нужно, и мы обдумаем и ответим на все твои вопросы. Зачем тебе собирать 8 человек и держать их два часа?”. Заказчик отвечает Егору: “Я хочу рассказать разработчикам о цели проекта”, на что Егор говорит, что

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

Разработчику нужно, чтобы ему четко поставили задачи, и он ее выполнит. Ему не нужно знать цель стартапа, над которым он работает. Разработчик - не бизнесмен, а Java-программист, и он не хочет разбираться в бизнесе.

Иногда получается переубедить заказчика, но бывает и так, что Егор теряет заказчиков. Такие заказчики привыкли, что толпа людей слепо подчиняется ему, и отказываться от этого они не хотят.

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

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

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

Нельзя быть техническим специалистом, если ты не пишешь код каждый день.

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