Но ведь на самом деле всех бы устроило просто, чтобы разработчики не косячили. Премию можно давать, просто если разработчик не допускает грубых дефектов, укладывается в свои оценки и ничем не раздражает заказчика и менеджера. Давайте запишем этот список возможных косяков и, если разработчик ничего из этого списка не делал, то дадим ему премию!
Такие, казалось бы правильные рассуждения распространены. В очень многих компаниях именно так премирование и выглядит. Но можно заметить, что мы от мотивации достижения (сделай хорошееи тебя наградят) перешли к мотивации избегания (не делай плохогои тебя наградят). Вместо того чтобы давать премию хорошим работникам, мы лишаем премии нерадивых.
Так в чём проблема? Лишение премииэто освящённый многими десятилетиями принцип, который всегда работал. Чего это он вдруг стал плохим?
А плох этот принцип в том, что он катастрофически подавляет инициативу. Если разработчик ничего не делает, то он нигде не ошибётся и получит премию. Если разработчик не общается с заказчиком, то вряд ли заказчик выразит им недовольство. Если разработчик будет брать на себя меньше задач, то он будет иметь меньше шансов какую-то задачу провалить. Значит, нужно работу над каждой задачей затягивать. К тому же, если написанный код перепроверить десять раз, то меньше риск, что в него прокрадётся баг. А если задачи оценивать с огромным запасом, то больше шансов в эту оценку уложиться. В конце концов, растянуть работу над задачей на порядок проще, чем ускорить разработку, если в оценку не укладываешься.
Таким образом мы, введя премии, имеем реальный риск получить разработчиков, которые затягивают свою работу и боятся делать что-то новое. То есть мы, вкинув деньги, получаем демотивированную команду. Нога успешно отстрелена.
Кейс "Замена команды"
В зарубежной международной компании работали менеджер проекта (американец) и тимлид (русский разработчик). Тимлид чем дальше, тем больше был недоволен своей командой. Эти люди были собраны случайным образом и они так и не стали командой. Их технический уровень был низок, а они не рвались желанием его повышать. Они раз за разом делали одни и те же ошибки в коде, и тимлид раз за разом делал им одни и те же комментарии после ревью. Код писался, но медленно и с большим трудом.
Когда менеджер и тимлид обсуждали очередной релиз и ожидаемые сроки, тимлид не выдержал и сказал: Мы не сделаем этот релиз в срок этой командой. Каждый из них работает в два раза медленнее, чем это следовало бы. Даже хорошие junior-ы сразу после университета были бы лучше, чем это сборище лентяев!
Менеджер задумался на секунду и сказал: Так давай уволим их всех и наберём новых! Согласен? И тут задумался тимлид. Он и правда считал, что команду надо разогнать. Но ему было жалко увольнять всех этих людей. Одно дело просто абстрактно их ругать, другое дело принимать решение о судьбе конкретных разработчиков, с которыми работал бок о бок. Пусть и плохих разработчиков, но всё же.
В результате тяжёлых размышлений тимлид так и не смог решиться уволить всю команду, которая ему так не нравилась. Релиз команда завалила.
Анализ
Мысли тимлида понятны. Но давайте посмотрим, о чём думал менеджер в то же время. Его мысли были примерно следующими: Отлично. Тимлид предлагает сменить всю команду. Это логично, так как с этими разработчиками у нас были проблемы уже давно. Всех уволить я могу, но как набрать новую команду, не ставя под удар текущие задачи? Мне нужна помощь тимлида, поэтому хорошо, что именно он поднял этот вопрос. Надеюсь, тимлид скажет, кого надо заменить в первую очередь, и скажет конкретные сроки, в которые нам нужно уложиться с набором людей. Потом мы вместе спланируем найм и обучение людей и создадим новую команду.
А после того, как тимлид не решился вернуться к этому разговору, менеджер подумал примерно так: Значит, тимлид не хотел ничего менять, а просто ныл на свою жизнь. Это неразумная позиция. Зачем ругать свою команду и ничего не пытаться изменить? В любом случае, без помощи тимлида я не смогу обновить команду. Да ещё и лида, похоже, менять надо, так как с этим парнем изменений не добиться. И надо заранее предупредить топ менеджмент, что этот релиз мы, скорее всего, завалим.
Этот кейс встречается в жизни довольно часто, и в нём несколько интересных моментов. Во-первых, тимлид, когда жаловался на свою команду, почему-то не считал, что это может привести к проблемам для них. А потом внезапно оказалось, что разработчиков лиду жаль. Не стоит настолько недооценивать свои слова. Даже если рядовой член команды жалуется на другого члена команды, то он должен подозревать, что к его словам могут прислушаться. У тимлида вес слов высокий. Если он кого-то ругает, то не медаль же этому другому выдавать.
Во-вторых, увольнениеэто всё-таки обязанность менеджера. Даже если менеджер спрашивает совета у тимлида, это не значит, что он перекладывает ответственность на него. Как, например, если разработчик предложит менеджеру написать больше юнит-тестов, то это совсем не значит, что юнит-тесты будет писать менеджер. Даже если он согласится, что идея хорошая. В деле увольнений решения принимает менеджер, тимлид советует. Так что тимлид взял на себя слишком много.
В-третьих, за нерешительность тимлида заплатила компания, так как релиз команда таки завалила. Эта цена дорогая и она уплачена из чужого кармана только для того, чтобы тимлид мог считать себя добреньким. Уклонение от какого-то решенияэто тоже решение, которое имеет свои последствия.
Есть разработчики, которые категорически не хотят брать на себя ответственность за других. Они занимаются только техническими задачами и специально избегают ключевых позиций. Потому что серьёзные технические решения тоже оказывают серьёзное влияние на всю команду. Но если уж человек согласился быть тимлидом, то ему нужно брать ответственность за свои слова, свои действия и своё бездействие.
Раздел 4. Контроль выполнения проекта
Контроль выполнения проектаэто прямая обязанность менеджера. Команда может ему помогать, но основной контроль лежит на его плечах. Разработчики не делают эту работу и часто даже не видят, как это делают их менеджеры, поэтому возникает очень много проблем, когда разработчики становятся менеджерами.
Куда ползёт scope
Умение работать с разрастанием объёмов работ (scope creeping) является вторым важнейшим навыком (после работы с рисками), необходимым для менеджера проектов. Большинство срывов сроков и выходов за бюджет связано именно с проблемой роста объёма работ, который прошёл незамеченным.
Особенно эта проблема важна для Fixed Price проектов, когда бюджет жёстко определён заранее и любой выход за этот бюджет идёт за счёт исполнителя. Компании не могут работать с Fixed Price проектами, потому что не умеют работать со scope creeping.
Но как же так?! Ведь каждому менеджеру много раз говорили, что нужно следить за скоупом проекта! Да, это так. И менеджеры очень чётко отслеживают, когда заказчик приносит новые требования. Если заказчик пишет письмо с просьбой добавить новый функционал (экран, сервис), то менеджер это заметит и отработает правильно (оценит, сообщит об изменении бюджета и т.д.). Но чаще дополнительные требования приходят не настолько явно.
Рассмотрим ситуацию. Заказчик ещё до старта проекта указывал, что ему нужен некий отчёт. Ещё до появления хоть сколь-нибудь детальных требований этот отчёт оценили и включили в бюджет. Потом заказчик предоставил требования. Требования не расходились с изначальными предположениями, отчёт реализовали в соответствии с ними.
Но выяснилось, что реализованный отчёт работает очень долго на тех объёмах данных, что есть у заказчика. Пользователю приходится ждать более часа. Даже когда нет специальных требований к производительности, то такие ситуации считаются багами. Разработчики проверили код, сделали оптимизацию, но отчёт всё равно выполняется больше получаса, и непонятно, что с этим делать.
Заказчик идёт навстречу команде и упрощает требования. Теперь не нужно выводить отчёт на экран, а можно просто обработать данные в фоне и выслать пользователю готовый отчёт в формате PDF. Да, отчёт будет выполняться по-прежнему долго, но приложение не будет выглядеть зависшим и им можно объяснить, что происходит. Генерация PDF уже реализована, добавить рассылку по почте можно быстро. Команда быстренько допиливает систему, баг закрыт, все счастливы. Ведь так?