Константин Евгеньевич Борисов
Как хорошему разработчику не стать плохим менеджером
Кейс "Деньги за тестовое задание"
В своей книге “Брать или не брать? или Как собеседовать разработчика” я обращал внимание на то, что если при приёме на работу кандидатам нужно выполнить тестовый проект, похожий на реальный, то некоторые кандидаты возмущаются и считают, что их пытаются склонить к бесплатной работе. Такие кандидаты потом портят имидж компании, заявляя, что та под видом тестового проекта заставляет делать реальные проекты.
Коллега связался со мной и описал, что их компания пытается бороться с этой проблемой, оплачивая $50 за это тестовое задание. Таким образом, никакой бесплатной работы нет. Анализ такого подхода показался мне достаточно интересным, чтобы включить его в эту книгу.
Анализ
Для начала стоит заметить, что чаще всего об “обмане” заявляют те, кто задание не может выполнить. Они чаще всего не могут даже понять, что это не реальный проект, а тестовое задание, которое самостоятельной ценности не имеет. Что изменится, если мы им предложим $50? Как ни странно, ничего. Они по-прежнему будут считать задание реальным проектом очень большого объёма. Ну, предлагает компания немного денег и что? Ведь проект стоит гораздо больше! Они же на него убили неделю и сделали только 10%. Значит, компания обманывает и хочет получить код, который стоит $10000 за $50.
Есть кандидаты, которые принципиально не хотят делать бесплатную работу и хотят, чтобы тестовый проект был оплачен. Часть их может согласиться сделать проект за $50. В этом плане какой-то положительный эффект есть. Возможно, пара кандидатов согласится сделать этот проект. Но что делать, если кандидат поглядит на проект и скажет, что тот стоит $51, $60, $75 или $100? Ведь если компания назначает цену на тестовый проект, она фактически признаёт его реальной работой. А значит, исполнитель может не согласиться с назначенной ценой. В этом случае позиция кандидата гораздо сильней, чем когда компания расценивала этот проект как учебный. Даже часть кандидатов, которая раньше просто делала тестовый проект, теперь задумается, не продешевит ли она. То есть часть кандидатов, которые были согласны проходить этот этап бесплатно, теперь могут отказаться писать код за предложенные деньги.
Неожиданный негативный эффект может быть на сильных разработчиках. Им этот проект может показаться, наоборот, слишком лёгким. Они сделают его за час и будут ожидать, что их оплата в этой компании будет $50 в час. А реальный оффер может быть ниже в разы. Такое несоответствие ожиданиям может оттолкнуть действительно хороших кандидатов.
Ну и, наконец, я плохо представляю, как корректно провести этот платёж через бухгалтерию. Если делать всё по закону, то кандидатам надо заключать договор и платить налог за эти $50. Объём бумажной работы такой, что лично я не стал бы связываться. Лучше бесплатно выполнить этот проект, чем отчитываться перед налоговой.
Конечно, компания может платить “чёрным” налом и не ожидать, что разработчик будет как-то официально эти деньги проводить. Но ведь очень странно начинать знакомство с потенциальным работником с незаконных операций, не так ли? И кандидат задумается, что за компания предлагает ему работу, если она так легко обходит законы.
На мой взгляд, минусы такого подхода сильно перевешивают плюсы. И для меня это снова пример ситуации, когда мы платим людям деньги, а в результате ситуация становится хуже.
История про деньги и оценивание
Деньги имеют коварное свойство. Если их дать человеку за что-то, то мы автоматически назначаем цену на это что-то. И эта назначенная цена может человеку показаться несправедливой. “Назначенную” таким образом нами цену могут не принять просто из-за этой самой несправедливости.
Представьте, что кандидат пробует себя на позицию Java-разработчика с озвученной зарплатой в 100 тысяч рублей в месяц. Но показывает себя не очень хорошо и ему предлагают позицию Junior-разработчика с зарплатой в 50 тысяч рублей. Конечно, он разочарован, так как его ожидания не оправдались. Он хотел пройти на более высокую зарплату. Но кроме ожиданий, у кандидата всегда будет мысль: “Я что, в 2 раза хуже, чем кто-то на той, изначальной позиции? Почему они меня так низко ценят?!” При этом предложенная зарплата может быть больше, чем у него есть, но ощущение недооцененности может помешать ему принять это предложение. Это одна из причин, по которой компании не озвучивают зарплатную вилку вакансий. Это делает работу с не полностью подходящими кандидатами проще на порядок.
А со мной когда-то произошла история, где тот же механизм сработал в совершенно другой ситуации. Моя компания тогда планировала начать работу со студентами профильного ВУЗа. Я считал это прекрасной идеей само по себе, но кроме того, меня всегда привлекало преподавание. Я задумал прочитать в этом ВУЗе курс, параллельно присматривая перспективных студентов на свои будущие проекты и рекламируя свою компанию. Я считал это частью моих обязанностей как менеджера.
Сообщил об этом своему менеджменту. Менеджменту идея очень понравилась. Так что я начал договариваться с ВУЗом об этом курсе и составлять программу. Но тут ко мне подошла директор моего подразделения и сказала: “Костя, я услышала, что ты хочешь читать курс в ВУЗе. Это здорово! Я тут поузнавала, и мы можем тебе предложить небольшие деньги за эту работу. Примерно $8 за каждое занятие. А мы тебе рекламные материалы дадим, которые ты можешь развесить в аудитории”.
Это был конец моей мотивации. Казалось бы, я был готов сделать эту работу бесплатно. А тут мне предлагают небольшие, но дополнительные деньги. Так в чём проблема? А проблема в том, что человеческая мотивация работает не так. Предложенная сумма была смехотворна. Я должен был потратить на каждое занятие около 8 часов (с учётом подготовки и дороги), причём в свой выходной. И компания, предложив $8, оценила мои услуги. Причём, если работая бесплатно, я мог рекламировать компанию (а мог и не рекламировать), то взяв деньги, я был должен проводить рекламу.
Я посчитал, что это предложение мне не выгодно, и отказался. Я всё равно провёл занятие, так как мне было очень интересно познакомиться со студентами, но я убрал всю запланированную рекламу и подбор студентов для моих проектов. Я просто сделал то, что мне было надо самому, не учитывая интересы компании.
Кстати, рекомендую вам придерживаться такого принципа: если вы не можете получить справедливую на ваш взгляд оплату, лучше сделайте работу бесплатно. И трижды подумайте, прежде чем предложить деньги за что-то человеку. Ваше предложение может быть воспринято совсем не так, как вам того хочется.
Кейс "Увольнение классного спеца"
Этот кейс встречается в интернете с завидной периодичностью. Часто человек на форуме пишет следующую историю: “А вот мой менеджер оказался вообще профнепригодным. Я к нему подошёл и сказал, что уволюсь, если мне на 50% зарплату не поднимут. Он сказал, что не может такое увеличение сделать, и я уволился. А через пару месяцев узнаю, что на моё место сразу двух человек с примерно моей зарплатой взяли. В полтора раза больше платить менеджер не мог, и вот пришлось платить в два раза больше. Непонятно, за что менеджер деньги получает”.
Анализ
Это может показаться странным, но большинство менеджеров совсем не нацелены на минимизацию зарплатных затрат. Равно как не нацелены на минимизацию затрат на мебель, уборку помещений и т.д. Обычно вопросы зарплат решаются совсем другими способами. Например, утверждением штатного расписания, выделением фонда заработной платы для конкретного подразделения и т.д.
Это имеет большой смысл, так как экономия на зарплатах слишком незначительна и слишком опасна, чтобы менеджер тратил на это своё время. Время менеджера – ограниченный ресурс и он должен использоваться на приоритетные задачи. Поэтому до тех пор, пока менеджер не превысил выделенного ему бюджета, он может поднимать зарплаты или нанимать новых людей.
Предыдущий пункт имеет другое следствие. Абсолютное большинство менеджеров не может поднять зарплату на 50%, просто потому, что наверняка текущее штатное расписание это не позволяет. То есть здесь может быть даже не вопрос желания или нежелания менеджера. Менеджер сказал, что он не может поднять зарплату настолько и это, скорее всего, это и значит. Требовать настолько большого роста зарплаты редко разумно.
Иметь два человека вместо одного гораздо удобней. Если задачи допускают распараллеливание, конечно. Один работник может заболеть, уйти в отпуск или вот уволиться, и это парализует работу. Двое сотрудников подстраховывают менеджера и уменьшают риски. За это часто стоит платить.
Позиция работника: “Мне бы повысили зарплату на 50%, и я остался бы работать вечно”, очень наивна. Как показывает опыт, если ваш сотрудник заявил о желании уволиться, то даже, если вы его удержали, то он уволится в среднем через полгода. Поэтому часть менеджеров даже и не пытаются удержать людей.
Я лично считаю, что в IT нужно людей удерживать всеми силами, но в некоторых других областях людей заменить проще и руководители даже не пытаются научиться удерживать персонал. Но в любом случае, сотрудник который запросил повышение зарплаты на 50%, привносит очень высокие риски. Скорее всего, ему скоро станет скучно, или денег снова окажется мало, или что-то ещё случится, и он снова захочет такого повышения. В общем, повышение зарплаты – это, как минимум, временное решение, а то и не решение вовсе.
Бывают очень разные ситуации. Например, если мы говорим про разработчика, и он работает в проекте Time&Material, то замена его на двух других разработчиков – это повышение прибыли компании, а не траты. Потому что заказчик будет платить за двух разработчиков. А вот повышение зарплаты на 50% будет тратой, так как заказчик, скорее всего, откажется платить за того же разработчика в полтора раза больше.
Шантажировать менеджера увольнением – это очень некрасивое поведение. Оно выглядит примерно так же, как когда менеджер грозит уволить работника, чтобы тот работал лучше. И это вторая причина, по которой менеджеры могут не удерживать сотрудника, который говорит про своё увольнение. Они не могут работать с человеком, который так легко разбрасывается такими угрозами. А учитывая, что эти сотрудники ходят и рассказывают эти истории (я же их так и узнаю), есть подозрение, что менеджер мог уволить сотрудника вовсе не потому, что тот хотел повышения зарплаты. Возможно, скоро этот сотрудник был бы уволен и так. Просто потому, что он плохой работник. А его “ультиматум” ускорил этот естественный процесс.
И наконец, произошедшее реально могло быть ошибкой менеджера. И что? Ошибки делают многие и эта ошибка отнюдь не настолько дорогостоящая, чтобы делать вывод о профнепригодности менеджера. Как вы видите, у такого решения есть реальные плюсы, а вот бесспорный минус только один – некоторый проигрыш в заработной плате в ближней перспективе. Это не то, на чём стоит так уж заморачиваться.
Как демотивировать премией
В главе про премию разработчика я уже упоминал финт, которым многие компании умудряются отстрелить себе ногу и превратить премию в инструмент демотивации. Но так как этот финт очень распространён и является ещё одним примером опасности денег как инструмента мотивации, то я хотел бы остановиться на нём подробней.
Компании зарабатывают деньги на разработчиках, а на мотивированных разработчиках они могут зарабатывать большие деньги. Поэтому компании готовы тратить деньги на мотивацию, это просто выгодное вложение денег. Ситуация Win-Win просто.
И таким традиционным средством мотивации часто считают премию. Её получение не так жёстко регламентировано законами. Вполне можно награждать разработчиков, чтобы они были мотивированы и делали какие-то подвиги.
За подвиги в первую очередь и пытаются наградить. Если разработчик как-то спас проект, или его техническое предложение сильно понравилось заказчику, или благодаря ему был выигран пресейл, то вполне логично дать такому разработчику денежную премию.
Но тут сразу начинаются проблемы. Во-первых, если давать премию за подвиг, то другим разработчиком непонятно, что делать, чтобы тоже получить премию. Все разработчики участвуют в пресейлах, принимают решения на проектах, стараются, но замечают не всех. Награда за “подвиги” получается какой-то случайной. А добиваться устойчивой мотивации случайными наградами сложно.
К тому же работа в индустрии IT командная, поэтому часто заслуга не принадлежит какому-то одному разработчику. Каждый успешный проект – это подвиг, ради которого старается вся команда. Измерить этот уровень стараний каким-то объективным способом не представляется возможным, и понятные цели установить не получается.
Но ведь на самом деле всех бы устроило просто, чтобы разработчики “не косячили”. Премию можно давать, просто если разработчик не допускает грубых дефектов, укладывается в свои оценки и ничем не раздражает заказчика и менеджера. Давайте запишем этот список возможных косяков и, если разработчик ничего из этого списка не делал, то дадим ему премию!
Такие, казалось бы правильные рассуждения распространены. В очень многих компаниях именно так премирование и выглядит. Но можно заметить, что мы от мотивации достижения (сделай хорошее – и тебя наградят) перешли к мотивации избегания (не делай плохого – и тебя наградят). Вместо того чтобы давать премию хорошим работникам, мы лишаем премии нерадивых.
Так в чём проблема? Лишение премии – это освящённый многими десятилетиями принцип, который всегда работал. Чего это он вдруг стал плохим?
А плох этот принцип в том, что он катастрофически подавляет инициативу. Если разработчик ничего не делает, то он нигде не ошибётся и получит премию. Если разработчик не общается с заказчиком, то вряд ли заказчик выразит им недовольство. Если разработчик будет брать на себя меньше задач, то он будет иметь меньше шансов какую-то задачу провалить. Значит, нужно работу над каждой задачей затягивать. К тому же, если написанный код перепроверить десять раз, то меньше риск, что в него прокрадётся баг. А если задачи оценивать с огромным запасом, то больше шансов в эту оценку уложиться. В конце концов, растянуть работу над задачей на порядок проще, чем ускорить разработку, если в оценку не укладываешься.
Таким образом мы, введя премии, имеем реальный риск получить разработчиков, которые затягивают свою работу и боятся делать что-то новое. То есть мы, вкинув деньги, получаем демотивированную команду. Нога успешно отстрелена.
Кейс "Замена команды"
В зарубежной международной компании работали менеджер проекта (американец) и тимлид (русский разработчик). Тимлид чем дальше, тем больше был недоволен своей командой. Эти люди были собраны случайным образом и они так и не стали командой. Их технический уровень был низок, а они не рвались желанием его повышать. Они раз за разом делали одни и те же ошибки в коде, и тимлид раз за разом делал им одни и те же комментарии после ревью. Код писался, но медленно и с большим трудом.
Когда менеджер и тимлид обсуждали очередной релиз и ожидаемые сроки, тимлид не выдержал и сказал: “Мы не сделаем этот релиз в срок этой командой. Каждый из них работает в два раза медленнее, чем это следовало бы. Даже хорошие junior-ы сразу после университета были бы лучше, чем это сборище лентяев!”
Менеджер задумался на секунду и сказал: “Так давай уволим их всех и наберём новых! Согласен?” И тут задумался тимлид. Он и правда считал, что команду надо разогнать. Но ему было жалко увольнять всех этих людей. Одно дело просто абстрактно их ругать, другое дело принимать решение о судьбе конкретных разработчиков, с которыми работал бок о бок. Пусть и плохих разработчиков, но всё же.
В результате тяжёлых размышлений тимлид так и не смог решиться уволить всю команду, которая ему так не нравилась. Релиз команда завалила.
Анализ
Мысли тимлида понятны. Но давайте посмотрим, о чём думал менеджер в то же время. Его мысли были примерно следующими: “Отлично. Тимлид предлагает сменить всю команду. Это логично, так как с этими разработчиками у нас были проблемы уже давно. Всех уволить я могу, но как набрать новую команду, не ставя под удар текущие задачи? Мне нужна помощь тимлида, поэтому хорошо, что именно он поднял этот вопрос. Надеюсь, тимлид скажет, кого надо заменить в первую очередь, и скажет конкретные сроки, в которые нам нужно уложиться с набором людей. Потом мы вместе спланируем найм и обучение людей и создадим новую команду”.
А после того, как тимлид не решился вернуться к этому разговору, менеджер подумал примерно так: “Значит, тимлид не хотел ничего менять, а просто ныл на свою жизнь. Это неразумная позиция. Зачем ругать свою команду и ничего не пытаться изменить? В любом случае, без помощи тимлида я не смогу обновить команду. Да ещё и лида, похоже, менять надо, так как с этим парнем изменений не добиться. И надо заранее предупредить топ менеджмент, что этот релиз мы, скорее всего, завалим”.
Этот кейс встречается в жизни довольно часто, и в нём несколько интересных моментов. Во-первых, тимлид, когда жаловался на свою команду, почему-то не считал, что это может привести к проблемам для них. А потом внезапно оказалось, что разработчиков лиду жаль. Не стоит настолько недооценивать свои слова. Даже если рядовой член команды жалуется на другого члена команды, то он должен подозревать, что к его словам могут прислушаться. У тимлида вес слов высокий. Если он кого-то ругает, то не медаль же этому другому выдавать.
Во-вторых, увольнение – это всё-таки обязанность менеджера. Даже если менеджер спрашивает совета у тимлида, это не значит, что он перекладывает ответственность на него. Как, например, если разработчик предложит менеджеру написать больше юнит-тестов, то это совсем не значит, что юнит-тесты будет писать менеджер. Даже если он согласится, что идея хорошая. В деле увольнений решения принимает менеджер, тимлид советует. Так что тимлид взял на себя слишком много.
В-третьих, за нерешительность тимлида заплатила компания, так как релиз команда таки завалила. Эта цена дорогая и она уплачена из чужого кармана только для того, чтобы тимлид мог считать себя “добреньким”. Уклонение от какого-то решения – это тоже решение, которое имеет свои последствия.
Есть разработчики, которые категорически не хотят брать на себя ответственность за других. Они занимаются только техническими задачами и специально избегают ключевых позиций. Потому что серьёзные технические решения тоже оказывают серьёзное влияние на всю команду. Но если уж человек согласился быть тимлидом, то ему нужно брать ответственность за свои слова, свои действия и своё бездействие.
Раздел 4. Контроль выполнения проекта
Контроль выполнения проекта – это прямая обязанность менеджера. Команда может ему помогать, но основной контроль лежит на его плечах. Разработчики не делают эту работу и часто даже не видят, как это делают их менеджеры, поэтому возникает очень много проблем, когда разработчики становятся менеджерами.
Куда ползёт scope
Умение работать с разрастанием объёмов работ (scope creeping) является вторым важнейшим навыком (после работы с рисками), необходимым для менеджера проектов. Большинство срывов сроков и выходов за бюджет связано именно с проблемой роста объёма работ, который прошёл незамеченным.
Особенно эта проблема важна для Fixed Price проектов, когда бюджет жёстко определён заранее и любой выход за этот бюджет идёт за счёт исполнителя. Компании не могут работать с Fixed Price проектами, потому что не умеют работать со scope creeping.
Но как же так?! Ведь каждому менеджеру много раз говорили, что нужно следить за скоупом проекта! Да, это так. И менеджеры очень чётко отслеживают, когда заказчик приносит новые требования. Если заказчик пишет письмо с просьбой добавить новый функционал (экран, сервис), то менеджер это заметит и отработает правильно (оценит, сообщит об изменении бюджета и т.д.). Но чаще дополнительные требования приходят не настолько явно.
Рассмотрим ситуацию. Заказчик ещё до старта проекта указывал, что ему нужен некий отчёт. Ещё до появления хоть сколь-нибудь детальных требований этот отчёт оценили и включили в бюджет. Потом заказчик предоставил требования. Требования не расходились с изначальными предположениями, отчёт реализовали в соответствии с ними.
Но выяснилось, что реализованный отчёт работает очень долго на тех объёмах данных, что есть у заказчика. Пользователю приходится ждать более часа. Даже когда нет специальных требований к производительности, то такие ситуации считаются багами. Разработчики проверили код, сделали оптимизацию, но отчёт всё равно выполняется больше получаса, и непонятно, что с этим делать.
Заказчик идёт навстречу команде и упрощает требования. Теперь не нужно выводить отчёт на экран, а можно просто обработать данные в фоне и выслать пользователю готовый отчёт в формате PDF. Да, отчёт будет выполняться по-прежнему долго, но приложение не будет выглядеть “зависшим” и им можно объяснить, что происходит. Генерация PDF уже реализована, добавить рассылку по почте можно быстро. Команда быстренько допиливает систему, баг закрыт, все счастливы. Ведь так?
Нет, совсем не так. Мы получили дополнительные требования и реализовали их. Объём работ вырос, бюджет не вырос. Мы проморгали scope creeping. И самое плохое тут, что заказчик не осознаёт, что добавились требования. Ведь он же наоборот, упростил задачу для команды. Как могла его помощь увеличить объём работ?
Ключевое здесь не то, что scope добавился, а то, когда он добавился. Многие, не задумываясь, скажут, что объём добавился, когда заказчик явно предложил заменить отчёт на рассылку PDF. Это не так. Заказчик в тот момент уменьшил объём работ, предложив упрощённое решение. А добавился scope тогда, когда команда начала работу над багом по производительности.
Требований по производительности нет, поэтому баги по производительности сразу оказываются вне рамок проекта. Да, разработчик должен потратить немного времени, чтобы удостовериться, что эта проблема с производительностью не является следствием ошибки кодирования. Но эти затраты невелики и должны покрываться другим важным навыком менеджера, навыком работы с рисками. А вот оптимизация и реализация упрощённых решений должна быть сделана только по отдельному согласованию с заказчиком и за отдельные деньги.
Многим кажется, что такое ведение дел очень агрессивно и нечестно по отношению к заказчику. Мы написали нерабочий отчёт, а потом ещё и требуем дополнительные деньги с него, чтобы исправить явный баг. Но на самом деле подобное отслеживание объёмов работы является показателем высокой квалификации менеджера и уважения к заказчику.
Гораздо правильней прозрачно и заранее объяснить заказчику, что происходит, чем через несколько месяцев сообщить ему, что деньги закончились и нужно ещё. Когда команда начинает несогласованную оптимизацию производительности, она тратит деньги заказчика (или своей компании, тут бывает по-разному). Возможно, эти траты не нужны. Возможно, отсутствие требований по производительности не является упущением, а является следствием продуманной политики заказчика.
Если заказчику сказать, что ускорение отчёта (или даже просто детальное исследование проблемы) будет стоить денег, то, возможно, заказчик выберет оставить отчёт “как есть”. Я видел немало Enterprise систем, в которых отчёты запускались в пятницу вечером с тем, чтобы посмотреть их результат в понедельник утром. Не надо принимать решение за заказчика. Надо дать ему информацию и возможность подумать над проблемой самому.
Бывают менее выраженные ситуации. Например, на демо заказчик принимает экран с парой мелких замечаний, которые разработчик тут же правит. А на следующем демо заказчик смотрит эти исправления, принимает их и добавляет, что он поработал с этим экраном и хорошо бы внести минимальные правки: увеличить пару полей, расширить всплывающую подсказку. А потом через пару недель заказчику хочется добавить текущее время в каком-то другом часовом поясе на этот экран, или выделить пару слов жирным шрифтом, или скрыть пару полей.
Разработчику эти правки не стоят ничего. Он говорит: “Да я их внёс прямо сейчас, пока мы разговариваем”. Оценка на них ровно 0. То есть если даже это и добавленная работа, но это работа с нулевой оценкой. Она же не может влиять на бюджет, правда?
Нет, не правда. Одновременно с радостным замечанием разработчика о том, что он уже изменил экран по просьбе заказчика, можно услышать тяжёлый вздох тестировщика, которому нужно теперь проводить регрессию (хотя бы небольшую) этого экрана. А у него есть более важные, причём заранее запланированные дела. Например, exploratory testing, которое позволяет найти неочевидные и очень неприятные баги и значительно снижает риски. Или автоматизацию тестирования, или обновление тест дизайна. В общем, как раз все те вещи, на которые времени почему-то не хватает, и которые очень снижают риски.
А риски, как мы помним, выражаются в тех же деньгах. То есть если вы, как правильный менеджер, заложили 3 раунда регрессии, а провели всего 2, то это вы не классно сэкономили так бюджет, а увеличили риски. А увеличение рисков – это рост бюджета, они денег стоят. Теперь у вас в проекте есть бомба, которая может сработать и вы вылетите за бюджет. Причём, даже не будете понимать, почему так произошло. Просто сработал риск, бывает.
Ваш процесс может покрывать (а может не покрывать) мелкие исправления после демо. Но он точно не покрывает случайные “мелкие улучшения” разных кусков системы. Здесь очень хорошо помогает навык менеджера организовывать процесс. Добавить тикет на это улучшение, убедить заказчика, что лучше подкопить изменения и вернуться потом к этому экрану, подгадать изменение к регрессионному тестированию, чтобы не создавать дополнительной работы для тестировщиков – это всё часть работы менеджера по управлению скоупом.
Важно помнить, что кроме явных затрат на разработку есть ещё другие трудозатраты, и что риски являются такой же частью бюджета, как и работы.
В бюджет проекта всегда так или иначе включены так называемые “накладные расходы”: затраты на коммуникацию, отчётность и т.д. Важной особенностью этой области является то, что менеджер очень сильно может снизить эти затраты.
Например, сейчас все понимают, что требования должны быть готовы и одобрены до начала разработки. Если разработчик начнёт писать код и через час споткнётся о неясность, то ему придётся уточнять вопрос у заказчика (или ещё кого-то), а самому переключаться на какую-то другую задачу, отвлекать тимлида или менеджера с просьбой эту задачу дать. В результате отвлекается не один человек, а несколько.
Многие задачи разработчика требуют полного погружения на длительное время (час, два, иногда больше). Если разработчика в течение часа “дёрнуть” раза четыре, то его производительность за этот час будет околонулевой.
Иногда менеджеры вынуждены отвлекать разработчиков со срочными вопросами, но часто эти вопросы вполне могут подождать. Имеет смысл задавать такие вопросы в почте с припиской, что можно ответы дать вечером, или завтра, или в течение недели. Можно подсказать разработчикам, что мессенджер можно отключать на время ответственных работ, и самому с пониманием относиться к такому.
Я очень большой сторонник общения лицом к лицу и считаю, что менеджеру нужно почаще разговаривать со своей командой. Но у менеджера должно хватать такта и умения своё общение не превращать в отвлечение. Возьмите самую свою большую кружку для кофе, улыбнитесь разработчику, который в это же время наливает кофе себе, и расскажите какую-нибудь забавную ситуацию, связанную с проектом, которая вылезла у вас на беседе с заказчиком или вашим менеджментом. Та часть команды, которая в этот момент ждёт выгрузки репозитория или сборки проекта, поучаствует в беседе и вынесет для себя что-то полезное, а та часть, которая погружена в отладку, не заметит происходящего, если не сильно шуметь.
Если вы видите, что одна команда бегает “в мыле” и постоянно решает срочные вопросы, а другая спокойно сидит, не спеша набирая код, то можно быть уверенным в том, что вторая команда гораздо производительнее первой. И если вы не можете обеспечить вашей команде нормальные условия работы, то это снизит производительность и, следовательно, раздует бюджет.
Не нужно забывать, что в ваш бюджет входит очень много косвенных затрат. Тогда не будет удивления, что, например, значительное падение скорости сети ведёт к значительному росту оценок вашей команды.
