Как хорошему разработчику не стать плохим менеджером [Константин Евгеньевич Борисов] (fb2) читать онлайн


 [Настройки текста]  [Cбросить фильтры]
  [Оглавление]

Про эту книгу

За свою жизнь я встречал многих классных руководителей, от которых перенял бесценные знания. Но видел и многих менеджеров, которые допускали грубейшие ошибки, и работать с которыми было мукой для команды и для заказчика. Многие люди (как специалисты, так и менеджеры) не понимают, что вообще делает менеджер в IT, какие навыки он должен иметь, и какие ошибки он ни в коем случае не должен допускать.

Бизнес-литературы по менеджменту много, но этот “менеджмент” в области разработки программного обеспечения часто оказывается бесполезен или даже вреден.

Почему разработчики увольняются, хотя их зарплаты постоянно растут? Как делать Fixed Price проекты? Почему после внедрения Scrum’а управлять проектами не стало проще? Ответы на эти вопросы каждому приходится искать методом проб и дорогостоящих ошибок.

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

Я часто слышал, что знания без опыта не работают, и в этой книге я передаю и свой опыт тоже. Около половины книги занимают истории из жизни1 и кейсы с разборами. Эти истории содержат реальный опыт, и позволяют вам не делать ошибки самому, а наблюдать за ошибками других.

Про автора

Автор этой книги, Константин Борисов, имеет двадцатилетний опыт работы в индустрии разработки программного обеспечения. Участвовав в десятках проектах в российских, зарубежных и международных компаниях в роли разработчика и менеджера, он накопил опыт, которым и делится в этой книге.

Связаться с автором можно с помощью электронной почты borisovke@gmail.com.

Личный блог автора доступен по адресу https://bukov-ka.livejournal.com/

Адреса в социальных сетях: ВКонтакте, Facebook

Создание обложки: Иллюстратор Ксения Ерощенко artbylulutyan

Раздел 1. Общие вопросы менеджмента

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

Особенности менеджмента в IT

Индустрия разработки программного обеспечения испытывает жуткую нехватку менеджерских кадров. Эта нехватка даже более выражена, чем нехватка разработчиков, тестировщиков, аналитиков и других исполнителей. Отчего так происходит? Дело в особенностях индустрии, которые требуют особенных (редких) менеджерских навыков и знаний. Давайте рассмотрим эти особенности.

1. В IT работают высококлассные исполнители, которые должны принимать решения сами.

Специалисты высокого уровня встречаются много где, но, пожалуй, только IT не имеет никаких протоколов и инструкций, и полагается на экспертные решения.  Технологии, методологии и бизнес-задачи слишком часто меняются, чтобы выработать какие-то реально работающие стандартные подходы. Да, многие компании имеют некоторые документы, но они описывают второстепенные вещи, а не основную работу. Описывается, как быстро надо ответить заказчику, но не описывается, что именно надо отвечать. Указывается процент покрытия юнит-тестами, но не описывается, как именно нужно реализовывать определённый функционал.

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

2. Исполнители крайне своевольны, не терпят хоть сколько-нибудь жёсткого обращения и требуют очень аккуратного управления.

Следствием предыдущего пункта и ситуации на рынке труда является то, что работники в IT требуют очень нежного менеджмента притом, что сами они ведут себя часто весьма агрессивно.

Например, только в IT менеджер сталкивается с тем, что его прямой и простой приказ не только не исполняется, но и открыто оспаривается. Для менеджера из другой области это шок, а для IT-менеджера – обычная реальность. Бесполезно говорить опытному разработчику, как именно он должен реализовать конкретный код. Его можно убедить, но им нельзя командовать.

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

Взаимодействие менеджера и подчинённого в IT – это разговор на равных, когда договорённости и взаимное уважение используются очень широко, а прямые приказы не используются вовсе (ну, почти).

3. Высокий уровень рисков.

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

4. Иностранные заказчики.

Знание английского языка является самым незначительным требованием при работе с иностранными заказчиками. Гораздо важнее, чтобы менеджер понимал культурные особенности и разницу в принципах ведения бизнеса.

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

5. Техническая сложность проектов.

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

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

Из этого есть два следствия. Первое: в IT вы можете работать с удивительно классными профессионалами. Я с очень большой теплотой вспоминаю менеджеров, с которыми мне довелось работать самому. Многих из них я считаю своими учителями. Я вспоминаю и обдумываю то, как они работали, и это помогает мне и в работе, и в жизни. Когда я сам становился менеджером, я грел себя мыслью, что я смогу вырасти в такого же профессионала, как те, под началом которых я сам работал.

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

Я написал эту книгу как раз, чтобы помочь менеджерам (действующим и будущим) оказаться не во второй категории, с которыми никто не хочет работать, а в первой категории людей, знакомством с которым гордятся.



Почему проекты заканчиваются неудачей

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

1. Разработка ПО сейчас очень дёшева и заказчики хотят её такой оставить. Хотя разработчики имеют высокие зарплаты, а компании, разрабатывающие ПО, получают хорошую прибыль, но с каждым годом разработка ПО дешевеет. Один единственный самолёт Boeing 777 стоит больше $300 миллионов. Бюджет даже крупных проектов по разработке ПО составляет малую часть этой суммы. А самолётов серии Boeing 777 на данный момент выпущено более 1600. Стоимость ПО ничтожна по сравнению с общей ценой изделий.

В цифровых продуктах аналогично. Instagram в 2012м году был приобретён Facebook, и примерная стоимость сделки составила $1 млрд. Стоимость собственно разработки несравнима с этой суммой. Стоимость компьютерной графики фильма “Миссия невыполнима – 2” не идет ни в какое сравнение с гонорарами Тому Крузу. Хотя его можно было бы просто нарисовать.

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

Справедливо считается, что исправление ошибок на более поздних этапах разработки очень дорого. Это правда, но вся индустрия разработки с каждым годом всё сильнее сглаживает эту проблему. Сейчас разработка модульная и даже, если основной модуль был спроектирован неверно, то не нужно переписывать всю систему. Большую часть кода можно сохранить.

Но деньги сами по себе не так важны, как следующий пункт.

2. У заказчика нет времени на уточнение требований. Изменение требований в процессе разработки ПО сейчас настолько распространено, что The Standish Group изменила критерии провала проекта для своего Chaos Report. Если клиент доволен, то считается, что проект успешен, несмотря на то, что сделали не то, что планировали.

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

Итак, заказчик не даёт денег на предварительный анализ системы, да ещё и меняет требования в процессе. Шансов, что более-менее сложный праехт2 проект пройдёт по плану абсолютно никаких.

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

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

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



Водопадная модель разработки

Периодически слышу от разных людей сожаление, что они используют водопадную модель разработки: “Мы бы и рады использовать Agile, но заказчик против”, “У нас водопад, мы к нему привыкли”, “Мы готовимся перейти на гибкие методологии, но пока у нас водопад”. Такие разговоры меня удивляют, так как встретить сейчас чистую водопадную модель разработки практически нереально.

Чтобы выяснить, почему так, давайте вспомним, что такое водопад как методология разработки, и как связаны разные этапы разработки:



Все этапы идут один за другим. Следующий этап начинается после полного окончания предыдущего этапа. Это очень-очень старая модель. Её название пошло из статьи Уинстона Уокера Ройса, опубликованной в 1970м году. Юмор заключается в том, что в той статье Ройс говорил об устарелости и ограниченности этой модели и о необходимости перехода на итеративные модели. То есть “водопад” – это то, как разрабатывали программы в 60-е годы.

Нам сейчас даже трудно представить, как это было, но давайте попробуем. Вот у какой-то компании есть нужда в какой-то программе. Она оплачивает анализ требований какому-нибудь проектному институту. В результате получает вагон требований (буквально железнодорожный вагон документации), который принимается и подписывается. Эта документация потом направляется в другой проектный институт, который уже делает дизайн, описывает, какое оборудование и какие программы нужны для реализации задачи. Опять, весь результат оформляется, принимается и подписывается. Для реализации документация направляется по нескольким другим компаниям, которые разрабатывают аппаратно-программные комплексы. На общую задачу им плевать, они работают по документации и производят не только код, но и кучу другой документации. На этапе интеграции ещё одна компания объединяет все эти разработанные куски в единое целое и только тогда начинается внедрение (отдельной компанией или департаментом).

Что делать, если заказчик на этапе интеграции захотел изменить требования, добавить отчёт? Ничего не сделаешь. В принципе отсутствовала такая опция в те далёкие времена. Можно было дождаться полной имплементации и начать новый проект по реализации этого отчёта. Либо прекратить все работы и начать всё снова. Нельзя попросить институт, который писал требования, их изменить. Потому что это физически вагон бумаги, который уже ушёл от них. И по той документации уже что-то сделано и компании не будут ничего переделывать, так как у них в контракте описана работа по изначальной версии задания и всё. Даже просто разорвать эти контракты и остановить работы часто было невозможно, так как в контрактах такая возможность могла отсутствовать. Компаниям приходилось оплачивать продолжение работ по контракту, даже когда нужда в программе отпадала. Так, например, происходило после распада СССР, когда экономическая ситуация изменилась кардинально и многие системы стали не нужны, но проекты остановить было невозможно.

Уже в 70-е годы прошлого века было понятно, что эта модель очень ограничена. Вся индустрия развивалась так, чтобы можно было в программы вносить правки, чтобы код следовал быстрым изменениям на рынке.

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

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

В обычном же проекте в настоящее время классического водопада нет. Да, возможно, не используется Scrum. Да, возможно, вообще никто не может сказать, что именно это за методология, и она нигде не описана. Но это не водопад.

Почему это вообще важно? Потому что методология разработки оказывает очень большое влияние на всё. Если вы считаете, что работаете по одной методологии, а на самом деле работаете по другой, то вы будете принимать неправильные решения.

На практике это выглядит просто и привычно. Вы думаете, что вы применяете водопадную модель. Значит, вы можете легко делать Fixed Price3 проекты. Нужно только собрать требования и можно сказать, в какой бюджет вы впишетесь.

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

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



Виды проектного менеджмента

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

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

Давайте пройдёмся по разным типам менеджмента. Но имейте в виду, что менеджеры, как и разработчики, бывают “fullstack” и на практике от вас наверняка потребуется знание нескольких перечисленных областей:

1. “Бумажная работа”. Самый печальный вид менеджмента, который менеджментом не является, так как не подразумевает принятия важных решений. Я бы не выделял этот пункт, если бы такой менеджмент не был настолько распространён.

Дело в том, что многие IT компании возникли как группа разработчиков, возглавляемых каким-нибудь молодым предпринимателем. Предпринимательский склад ума отличается от менеджерского, и разработческий менталитет тоже далёк от менеджерского. В результате компании живут фактически без проектного менеджмента до тех пор, пока не вырастут до размера 30-50 человек. На этом этапе уже появляется желание работать над проектами хотя бы среднего, а не мелкого размера. Владелец компании начинает понимать, что он не может выполнять функции менеджера проектов, так как у него не хватает времени. А ключевые разработчики начинают жаловаться, что 99% их времени занимают задачи, не имеющие отношения к разработке: написание писем, проведение совещаний, отчётность и т.д. Тогда решают “завести” менеджеров проектов.

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

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

2. Предпродажа/продажа. Интересный подвид проектного менеджмента, когда бойкий руководитель проекта с хорошо сработавшейся командой создаёт новый бизнес. Он общается с новым для компании заказчиком, а его команда быстро облекает все хотелки заказчика в работающий код. Начало бизнеса выглядит как череда мелких проектов и прототипов, которые быстро вырастают в большие проекты.

Такой менеджер имеет продвинутые навыки оценки проектов и ведения переговоров. А, например, нанимать junior-ов и выращивать из них senior-ов он запросто может не уметь или не любить. В его работе это не нужно. Когда бизнес из стадии зарождения переходит в более стабильную фазу, такому менеджеру становится скучно, а сам он становится неэффективным. Он передаёт подготовленную площадку другому менеджеру, а сам идёт стартовать новый бизнес с новыми заказчиками.

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

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

Но и в небольшом проекте, где работают 5 человек, очень здорово, когда разработчики не мешают тестировать, а заказчик может видеть нужную ему отчётность напрямую, без менеджера.

4. People management4. В компаниях с проектной организацией менеджеры проектов отвечают за найм, развитие и увольнение сотрудников. Даже, если менеджеры за это не отвечают, то они могут быть ключевыми людьми в деле мотивации и карьерного развития членов своих команд.

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

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

В IT у антикризисного управления есть особенности, которые сильно отличают его от антикризисного управления в других областях:

a. Невозможно сменить команду. Традиционный антикризисный подход – это начать работу “с чистого листа”. Вся команда меняется на новых людей, все процессы перезапускаются заново. В IT это сделать невозможно, так как люди слишком ценный ресурс и найти 20-30 незанятых человек просто невозможно. К тому же в “кризисных” проектах знания распределены по ключевым людям и без них нельзя продолжить работу. Да и заказчик не может терпеть задержку из-за “перезапуска” проектов.

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

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

Антикризисному менеджеру нужно очень хорошо понимать механизмы функционирования IT проекта, чтобы понять, на чём сконцентрировать изменения, а что можно оставить, как есть.

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

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

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



История про ответственность

На одном моем новом проекте подошли ко мне лиды двух команд, Вася и Наталья. Судя по их виду, разговор предстоял серьёзный.

– Константин, нам нужно принять серьёзное решение, – сразу перешла к делу Наталья.

– Отлично, я люблю принимать решения. В чём дело?

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

Вася и Наталья выжидающе глядели на меня. Я в ответ тоже глядел выжидающе:

– И какое решение нужно принять-то? – я пока не мог задать более осмысленного вопроса.

– Решение о переписывании модуля на новую архитектуру! – Вася и Наталья были удивительно единодушны.

– Мы можем его не переписывать?

– Нет, не можем. В том и дело. Мы не можем реализовать нужные заказчику задачи без этого.

– Так а какая альтернатива есть?

– Никакой альтернативы! В том и дело! Мы просто вынуждены его переписать!

– Тогда решения никакого принимать не нужно. Вы сами уже приняли решение переписать модуль и просто хотите, чтобы я донёс это решение до заказчика, так?

– Нет. Ты должен принять решение!

– Так даже альтернативы никакой нет! Значит, решение вы уже приняли. В чём проблема-то?

– Э, не. Кто принимает решение, тот и ответственность несёт. А мы на себя ответственность такую брать не будем! Мы лидами уже давно работаем. С такими решениями всегда проблемы. Потом разборки начинаются, крайних ищут. И мы такими крайними быть не хотим.

Наконец-то я понял, чего от меня хотят.

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

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



Воздействия и результат

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

Чтобы пояснить, что я имею в виду, я хотел бы привести пример из замечательной книги Даниэля Канемана “Думай медленно… Решай быстро”.

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

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

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

В менеджменте такое происходит постоянно. В моей практике был очень забавный пример, как одни и те же результаты интерпретировались по-разному. Я тогда работал в очень большой IT-компании, где группе из примерно 30 менеджеров поставили задачу увеличить производительность их команд. Разработчики выполняли некоторые задачи, каждая из которых фиксировалась тикетом в Jira. Количество зафиксированных (созданных и закрытых) тикетов и определяло производительность.

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



На общем собрании один из менеджеров, очень активный парень по имени Пётр, так прокомментировал наблюдаемое: “Уважаемый менеджмент, поглядите, как здорово мы выполнили ваше задание. Вы попросили увеличить производительность, и мы всего за пару недель производительность фактически удвоили”.

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

Через неделю график производительность обзавёлся очередным скачком:



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

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

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

Со мной периодически кто-нибудь спорит:

– Константин, твои методы слишком сложные. Любую проблемную ситуацию в команде можно решить, просто пригрозив увольнением. Вот жалуется человек на что-то. А я ему говорю: “Увольняйся!” – и сразу все претензии пропадают.

– Но ведь так никакой команды не построить! – в шоке возмущаюсь я.

– Зато люди делают то, что им сказано. А больше ничего не надо. Это эффективно.

Неопытный менеджер просто не знает, как работать с людьми правильно. Возникают ситуации, которые он не знает, как решить. И вдруг оказывается, что если на людей наорать, пригрозить увольнением и объявить выговор, то проблемы как бы уходят. Это кажется простым решением, а  негативные последствия носят очень сложный и отложенный характер. Да, почему-то люди увольняются, но не сразу ведь. Да, новых людей становится искать всё сложней, а некоторые резко отказываются рассматривать любые вакансии этой компании, но это же рынок труда скудный. Да, разработчики ведут себя пассивно, но для этого и нужен менеджер, чтобы их “активизировать”. Так и продолжают существовать неэффективные, вредные и просто опасные приёмы менеджмента.

Отложены не только негативные, но и позитивные эффекты. Когда я работаю с сильно демотивированной командой, то явный прогресс становится виден через полгода-год. Часто я уже перехожу на другой проект и не вижу плодов своих трудов. Даже высокий менеджмент с трудом может отследить конкретный прогресс, так как уже забывает, что происходило так давно назад.

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

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

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



История про неожиданные выводы

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

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

Менеджеры обрадовались, но тут уже загрустили разработчики. Потому что менеджеры дружно запрещали разработчикам тестирование на другие должности. Просто и категорически. Конечно, разработчик мог просто уволиться, так как ему фактически запрещали повышение. Но менеджерам в той компании не было никаких минусов от увольнения разработчика. Компания была сторонницей жёсткого менеджмента, и увольнение сотрудника в минус менеджеру не шло. Конечно, проект терял разработчика, но он и так бы потерял его, если разработчик ушёл бы на повышение. А так разработчик оставался в проекте, так как увольняться было опасно. Можно было не пройти тестирование и остаться совсем без работы. Так что негласно такой запрет повышений компанией одобрялся.

Мне подобная политика не нравилась. Я считал её губительной уже в средней перспективе и на своих проектах разработчикам разрешал переходы. У меня даже получалось договариваться со всеми заинтересованными сторонами и оставлять разработчиков после повышения на моих проектах. Повышение зарплаты составляло обычно 60%-100%, так что разработчики были заинтересованы договариваться со мной о завершении текущих дел перед переходом на новую должность. Так что я даже извлекал пользу от этого своего отхода от принятой практики.

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

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

Причём, я мог бы просто поступить, как остальные менеджеры, запретить переход и работать дальше без проблем. Но это противоречило бы моим принципам, и я решил разрешить Игорю это тестирование. Дело было не таким простым, так как если бы я так просто отпустил бы недавно нанятого ключевого специалиста, то меня самого могли бы обвинить в непрофессионализме и уволить. Так что я обратился к своему начальнику, вице-президенту компании, объяснил свою позицию и заручился его согласием делать, как мне кажется лучше. Я дал своё одобрение Игорю, он пошёл тестироваться, а я пошёл думать, что я буду делать, если Игорь уйдёт с моего проекта.

Игорь не прошёл один из этапов тестирования, сообщил это мне и потом у нас состоялся интересный диалог. Игорь сказал:

– Константин, а ты ведь не верил, что я пройду тест!

– Почему? У тебя же есть опыт. Ты вполне мог пройти, – удивился я.

– А, понятно. Значит, ты меня просто не ценишь и тебе пофигу, работаю я у тебя и уволюсь!

Тут у меня слов не нашлось, и я просто завис, а Игорь продолжил:

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

Я, конечно, попытался объяснить свою позицию, но до сих пор сомневаюсь, что Игорь понял меня правильно. Уж очень у нас разный подход к делу оказался. А я тогда долго удивлялся, что мне в реальном проекте пришлось работать с традиционным домостроевским подходом “Бьёт – значит любит”.



Раздел 2. Мотивация и командообразование

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

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

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

Главное правило мотивации

В IT тема мотивации чрезвычайно популярна. Менеджерам рассказывают о важности мотивации разработчиков, и во многих компаниях много усилий вкладывается в мотивацию5. Каждый год строятся планы развития, где выясняются желания человека. Потом к этим желания подгоняются планы, соответствующие целям компании. Человек видит, как компания работает над исполнением его желаний.

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

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

Секрет очень прост: начать работу с мотивацией надо с того, чтобы исключить демотивацию. Дело в том, что мотивация – это очень хрупкий объект. Чтобы человек думал о всеобщем благе, стремился к самосовершенствованию и делал больше, чем необходимо, надо, чтобы у него было всё хорошо.

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

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

Например, знаю одного менеджера (очень опытного, кстати), который так говорит про свою работу: “Это я делаю все свои проекты, а не команда. Да, я использую разработчиков и тестировщиков в своей работе, но это просто инструменты для реализации проекта”. Он может это мнение своей команде никогда и не озвучивает, но оно прекрасно считывается. Этот менеджер говорит, что его проекты скучные и с них народ очень часто увольняется. Но сам он остаётся работать, поэтому проекты успешно функционируют.

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

Что же делать, если вы (или кто-то другой) всё-таки обидел человека? В первую очередь, нужно извиниться. Причём не просто формально, а так, чтобы человек поверил, что вы свою ошибку осознали, и приложите усилия к тому, чтобы её не повторить. Тут нужно подключить тот самый эмоциональный интеллект, чтобы не сделать ситуацию хуже.

Например, если вы назвали некоего Васю бракоделом, а он смертельно обиделся, то не надо говорить: “Вася, ну прости. Чего ты дуешься? Это ж я пошутил! Ты иногда и не брак делаешь! Ха-ха-ха!” Лучше подойти к делу вдумчиво, с опорой на ваши знания о человеке: “Вася, прости меня, пожалуйста. Это была дурацкая шутка. Меня самого так мой менеджер часто называет, мне слово кажется забавным. Я не думал, что ты серьёзно к моим дурачествам отнесёшься. Все же знают, что твою работу можно не перепроверять. Ты перфекционист. Прости, был не прав”. Причём, кому-то эти извинения надо принести при всей команде, а кому-то только лично.

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



История про мотивирующие речи

В одной из компаний, где я работал, я слышал запоминающееся выступление генерального директора. Оно было недолгим и основную часть я попытаюсь здесь пересказать близко к оригиналу:

“В нашей компании идут перемены, и многим кажется, что компания развивается в неправильном направлении. Я вижу и слышу от других, что сотрудники  нашей компании демотивированы. А демотивация создаёт проблемы. Вы работаете медленней, приносите меньше пользы проектам и распространяете свою демотивацию на других. Поэтому, если вы чувствуете, что вы демотивированы, мотивируйте себя сами! Будьте мотивированы”.

Этот подход, несмотря на свою полную беспомощность, является очень распространённым. Компании прекрасно видят, что люди демотивированы, понимают проблемы, которые это создаёт, но не представляют, как исправить положение дел.



Доверять команде

Тема доверия является ключевой в работе с людьми. И если посмотреть “в среднем” (а средняя картина всегда довольно печальная), то менеджеры не доверяют своим командам, а команды не доверяют менеджерам. Это абсолютно безумная ситуация, так как менеджер работает с людьми, они его инструмент. Не доверять своей команде – это то же самое, как если бы программист не доверял своему компилятору.  Дело бесполезное и опасное.

Давайте сперва определим термин “доверие”, так как здесь есть разночтения. Доверие – это вера в то, человек подойдёт к своим обязанностям честно, постарается выполнить свою часть работы, вместе с вами будет идти к результату, будет вести себя порядочно. Это вера в человека, ограниченная рабочими рамками.

Как доверие менеджера выглядит на практике? Давайте рассмотрим пример. Вот есть у вас разработчик Алексей. И он частенько опаздывает даже на ключевые встречи. При этом сильно вас подставляет, так как вы один на один с заказчиком и его техническими специалистами, без своего специалиста. И вот он снова опаздывает и оправдывается: “Я честно-честно заранее вышел, но у машины колесо спустило. Я её даже на дороге бросил и на такси сразу пересел. Но всё равно немного опоздал, так как такси ждал.

Многие менеджеры принимают подобные отговорки один раз, другой, максимум третий, а потом начинают подозревать такого Алексея в обмане. Недоверчиво косятся на него, задают каверзные вопросы (Какое именно колесо спустило?), пытаются найти свидетелей прокола колеса, просят показать историю звонков, чтобы увидеть вызов такси. Им кажется важным, обманывает их Алексей или нет. Всё это ведёт к напряжённым отношениям, а проблема не решается.

Гораздо проще сразу поверить Алексею. Сомневаться в его словах во-первых, неприлично, во-вторых, контрпродуктивно. Считайте, что действительно у него случилась какая-то критическая ситуация. Лучше даже не выслушивать оправдания, так как у человека могут быть очень личные или даже не совсем приличные проблемы, о которых он вам сообщать и не должен. Не спрашивайте об оправданиях. Зачем вам они? Считайте, что человек старался по максимуму, но у него не получилось.

Удивительно, но такая позиция абсолютного доверия многим кажется “слишком мягкой”. Однако же она гораздо жёстче позиции тех менеджеров, которые не доверяют людям и ищут подтверждений их слов. Как так получается? Очень просто. Менеджеры, которых интересуют отговорки, будут терпеть Алексея вечно. У него будут оправдания, менеджер проверит эти оправдания и успокоится.

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

Обратите внимание, что недоверие к Алексею вы не выражаете. Вы просто говорите, что он не соответствует занимаемой должности. Жёстко, не правда ли? И прикрыться оправданиями Алексей не может. Потому что в таком разрезе понятно, что вам нужна работа, а не отговорки. Но вы не выказываете и тени сомнения в том, что Алексей правда пытается прийти вовремя. Конечно, вы в это верите, просто вам нужен результат.

Те менеджеры, которые довольствуются отговорками, обычно, просто требуют чего-то, что на самом деле, не обязательно. Например, они требуют присутствия разработчика тогда, когда он не особо и нужен. Разработчик это чувствует и “отлынивает”, как может. А менеджер чувствует себя уязвлённым и хочет оправданий. Причём настоящих проблем у разработчика не бывает, так как серьёзных он проблем не создаёт. Менеджер должен ориентироваться на реальные задачи и требовать то, что нужно для дела. Тогда будет очевидно, что оправдания не нужны хоть правдивые, хоть нет.

Мне на такое возражают, что иногда разработчики явно говорят неправду. Например: “Мой разработчик вот говорит, что задача невыполнима, а её сделать можно. Явно врёт, зараза! Начинаешь его пытать и действительно оказывается, что решение есть. Значит, врал!”

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

Опять же, обратите внимание, в такой постановке вопроса нет никакой “мягкости”. Я тут прямо угрожаю разработчику: “Заказчик придумает своё решение и нам придётся его реализовывать”. Это страшная угроза и она реальна. Но говорить разработчику, что я ему не верю, очень неправильно. Я ему верю, решения задачи нет. Просто нам теперь нужно решить другую задачу: предложить что-то другое заказчику.

На самом деле, нет ни одного вменяемого примера, когда имеет смысл сказать человеку, что вы ему не верите. Человек врёт вам, вы ему об этом скажите, и он резко перестанет так делать? Это сумасшедшее предположение, так общение с людьми не работает. А если вы не можете сказать никому, что вы ему не доверяете, то зачем не доверять?

Подумайте над последним вопросом. Он таит за собой больше возможностей, чем кажется. Мне некоторые менеджеры говорили: “Я никак не могу поверить  некоторым своим людям. Они явно работают недобросовестно”.

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

И ещё иногда менеджеры смешивают доверие и технический уровень: “Задача сложная, Вася никогда не работал над такими, он может не справиться”. Это не имеет никакого отношения к доверию. Доверие – это про то, что Вася будет стараться изо всех сил (может и невеликих), а не про гарантию, что Вася справится с задачей. Работа с рисками, по-прежнему, на менеджере. Даже, если вы доверяете Васе, вы можете и должны помогать ему, контролировать его, организовывать ревью его работы более опытными разработчиками и т.д. Потому что никто (и вы в том числе) не застрахован от ошибок. И наличие ошибок не должно влиять на доверие.

Разделять вопросы доверия и квалификации критически важно. Смешивание их подобно смешиванию бизнес-логики, UI и слоя данных. Это приносит хаос и делает проект неуправляемым.

Так как вопрос доверия является ключевым и часто сложным для усвоения я хотел бы конспективно перечислить ключевые моменты:

Менеджер должен доверять своей команде, так как нет никакого практического смысла ей не доверять;

Менеджер не должен работать с теми людьми, которых он считает недостойными доверия;

Менеджер не должен путать доверие и гарантию от ошибок. Каждый может ошибиться;

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



История про ненужные сложности

Как-то устроился я менеджером в одну небольшую разработческую контору. И мне почти сразу после выхода на работу сказали, что одного моего разработчика, Сергея, надо срочно уволить. Мол, от него проблемы уже много лет, и попробовали уже всё, и ничего не помогает, и надо увольнять. И владелец компании мне это говорил, и руководитель HR. Очень уверенно говорили.

Но когда я спросил, почему Сергея ещё не уволили, ответа я не получил. Так как я с Сергеем ещё не работал, то и увольнять мне его было не за чем. О чём я и сообщил. Я знал, что своих людей надо защищать, так что Сергей получил ещё один шанс.

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

Я сообщил об этом владельцу компании и отделу HR, получив в ответ ожидаемое: “Мы же говорили!” Владелец сказал, чтоб я увольнял Сергея, как можно быстро, так как тот и так много вреда компании принёс.

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

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

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

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



Исправление ошибок

Исправление ошибок – это больная тема. Часто от разработчиков можно слышать про менеджеров: “Ну он же не с компьютерами работает, а с людьми! Тут ошибки исправить нельзя! Поэтому и допускать их нельзя!”

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

А вот насчёт исправления ошибок ситуация интересней. Что подразумевает разработчик, когда говорит, что он исправил ошибку? Он подразумевает, что в код внесены изменения и баг, который там был, теперь отсутствует. Но разве такое “исправление” достаточно, чтобы действительно исправить весь нанесённый ущерб? Конечно, нет. Тестировщики потратили время, работая с неисправным билдом. А теперь еще новый заново тестировать. Другие разработчики мучались при реализации своих кусков, так как код работал некорректно. Заказчик, видел баг в трекере и терял доверие ко всей команде.

Если разработчик исправит злой баг, из-за которого долго лежал сервер, то ему не стоит говорить заказчику: “Я всё исправил, теперь всё хорошо!” Так как с точки зрения заказчика всё совсем не хорошо, и ему нужно что-то делать с толпой недовольных пользователей.

У менеджеров всё так же. Сделанные ошибки исправить совершенно нельзя, но можно как-то попробовать компенсировать нанесённый ущерб, и улучшить ситуацию в целом.

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

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

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

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

Гораздо более правильным было бы признать свою ошибку и не говорить ни о каком “исправлении”, а говорить о будущем. Примерно так: “Вася, мне очень жаль, что ты решил нас покинуть. Очевидно, что это моя вина. Я недостаточно приложил усилий к твоему переводу. Мне жаль тебя терять и я хотел бы сделать всё, чтобы ты остался. Могу предложить тебе переход на любой другой проект вот из этого списка прямо с сегодняшнего дня. Текущему проекту будет тяжело, если ты уйдёшь, но ты с него уйдёшь в любом случае, а мне хотелось бы, чтобы ты остался в компании”. При таком подходе, когда менеджер признаёт свои ошибки и даёт человеку какой-то выбор, шанс на то, что человек останется в команде гораздо выше.

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



Люди, приносящие плохие известия

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

Менеджер проводит львиную долю своего времени с проблемными людьми. Если в вашей команде 10 человек, из которых 9 работают идеально, а 1 находится на грани увольнения, то вы будете 90% своего времени проводить с этим единственным проблемным сотрудником. Беспроблемный сотрудник раз в день скажет, что всё идёт по плану, а детальную информацию можно всегда получить в трекере или по почте. А с проблемным всегда уходит куча времени на то, чтобы узнать, как у него дела, где ему нужна помощь, какой статус у каждой задачи. Хороший сотрудник даже проблему свою подготовит для менеджера, так что вы будете хорошо понимать, что именно произошло, и какой выбор есть. Так что на решение вопроса уйдёт несколько минут. У сотрудника нерадивого всегда всё мутно, и вам приходится тратить огромное количество времени и сил, просто чтобы разобраться в происходящем.

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

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

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

Некоторые менеджеры ломаются на другом. Вот есть просто идеальные работники, опора и отрада любого менеджера. Они быстро и качественно выполняют любую данную им задачу да ещё и тащат кучу задач не своих. Вы таких работников практически не контролируете, потому что в особом контроле они не нуждаются. Такому работнику вы доверяете. И вот в один из дней такой идеальный работник косячит. Причём косячит очень сильно и глупо, принося столько проблем, сколько обычный косячник никогда не приносил. И вот тогда менеджер страшно кричит: “И ты, Брут?!” и навсегда теряет веру в людей.

Хотя на самом деле в такой ситуации менеджеру некого винить, кроме себя самого. У каждого человека есть право на ошибку. Любая более-менее сложная деятельность полна ошибок. Масштаб ошибок напрямую зависит от уровня сотрудника. Джуниор-разработчик вряд ли может нанести серьёзный ущерб (если в организации есть минимально разумные процессы), у архитектора масштаб косяков куда выше, а генеральные директора и владельцы компаний могут делать миллионные косяки.

Так что сам масштаб ошибки не свидетельствует против человека сам по себе.  И то, что эта ошибка кажется “глупой” тоже не должно вводить в заблуждение. Такими кажутся большинство ошибок после того, как они совершены. Это совсем не значит, что эту ошибку было так легко предотвратить. Опять же такой доверенный сотрудник уже привык решать проблемы сам, не отвлекая вас. Поэтому он может довести проблему до более “запущенного состояния”.

Так что не стоит сразу кричать об обманутом доверии. Лучше всё описанное выше сказать этому сотруднику. Он сам себя винит и абсолютно зря. Объясните ему, что вы его специально оставили с минимумом своего контроля и своей поддержки, чтобы высвободить своё время. И объясните, что такие ошибки и проблемы – это плата за это высвободившееся время.

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

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



Кейс “Прикрыть товарища”

Крупная аутсорсинговая компания открыла небольшой офис в новом для себя городе. Офис открыт всего 3 месяца, да  и работают там только два разработчика: Вася и Петя. Постепенно их проект должен разрастись, и наймут ещё людей, но это дело будущего. А пока разработчики работают практически “сами по себе”, так как их менеджер находится в другом городе.

Разработчики опытные,  проект простой, поэтому проблем не ожидается.

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

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

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


Анализ

Распространённая ситуация, когда некоторый “Петя” хочет быть “хорошим” и творит добро в отношении некоторого “Васи”. Очень полезно в таких ситуациях поглядеть на происходящее с точки зрения морали. Давайте применим золотое правило морали: поступайте с другими так, как хотели бы, чтобы поступали с вами.

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

Давайте теперь рассмотрим поведение Васи-алкоголика с точки зрения менеджера. Во-первых, для менеджера наверняка не является секретом, что Вася ненадёжен. Вряд ли первый проект в новом офисе поручили совсем уж бестолковому менеджеру. Да и когда нанимали Васю могли навести справки и узнать, что у того были проблемы с алкоголем в прошлом. Ну или на собеседовании это выяснить (это не так сложно, как может казаться). И за то время, пока он работает любому станет очевидно, что Вася – не супер-работник.

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

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

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

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

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

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

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

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

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



Мотивация и жёсткость

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

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

Я сам себя считаю довольно жёстким руководителем. У меня есть большой опыт антикризисного управления, когда дело требует принятия быстрых и непопулярных решений. Часто я работаю в таких проектах, которые сами по себе диктуют жёсткие условия (Fixed Price, требовательные заказчики, меняющийся бизнес). Но когда я про свою жёсткость говорю со своими разработчиками (бывшими для чистоты эксперимента), то они со мной не соглашаются:

– Да ну, Константин, какой же ты жёсткий? Не орёшь никогда, всегда выслушиваешь и по-человечески относишься.

– А ничего, что я за пару месяцев уволил людей больше, чем предыдущий менеджер уволил за прошлый год?

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

– Так и решения мои небезупречны, косяков хватает и серьёзных, – настаиваю я.

– Ты знаешь, то, что ты признаешь свои ошибки, уже достаточно редко. Ты просто жёстких менеджеров не видел.

Я уже не спорю. Не жёсткий, так не жёсткий. Меня очень радует, что команда понимает, что я делаю свою часть работы, и позволяет мне делать то, что нужно для проекта. Людям достаточно, что я объясняю, что и зачем я делаю, что я реально слушаю других, и что я признаю свои ошибки. Удивительно насколько мало нужно команде, чтобы уважать менеджера. И вдвойне удивительно, что команда так редко это малое получает.



История про очередь на увольнение

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

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

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

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

– Андрей, я работаю на тебя с самого дня открытия филиала. Ты должен мне пойти на встречу. Уволь меня, из меня ипотека все соки выжимает!

– Не могу я тебя уволить. Без тебя наш проект загнётся.

– Уволь, а? Я буду вечерами работать. Ты даже не заметишь, что я уволен!

– Андрей, уволь меня, а то я уволюсь сама!

– Полиси компании рекомендуют не вести переговоры с террористами.

– Тогда я не уволюсь, а ребёнка рожу! Будешь знать!

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

– Андрей, почему ты уволил этого рукожопа Олега?! На его месте должен был быть я!

– Не называй Олега рукожопом. На Олеге было меньше всего завязано задач, поэтому я его и уволил.

– И теперь он счастливый бухает в баре, а я по-прежнему пашу! Где справедливость?!

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

Тяжело пришлось Андрею. К счастью, тяжёлые времена у компании кончились, увольнения прекратились. Команда тяжело вздохнула и продолжила работать, как раньше, тайком мечтая о возвращении кризиса.



Не ругать свою команду

Одна из вещей, которые менеджер не должен никогда делать – это ругать своих подчинённых. Начинающему менеджеру как обычному человеку хочется поныть про свои беды: “Вот Петя такой косячник, такой косячник. У меня из-за него сплошные проблемы. Он вообще не понимает, что он делает”. Так вот каждый менеджер должен над собой работать, чтобы подобные желания у него даже не просыпались ни при каких условиях.

Быстрее всего менеджер учится не ругать свою команду при своих подчинённых, потому что это самый простой путь потерять доверие людей и разрушить команду. Поймите правильно, не нужно делать вид, что вы слепы к недостаткам других, но любую критику нужно давать очень аккуратно, не навешивая ярлыки и правильно расставляя акценты. Очень большая разница между формулировками “Петя невыносим, это всем известно! Мне на него все жалуются!” и “Я знаю, что Пётр не самый приятный в общении человек и только его уникальный опыт перевешивает его недостатки. Я понимаю, что с ним бывает трудно, и готов помогать. Если есть какие-то конфликты, то скажи мне, и я возьму на себя неприятную часть общения с ним”.

Гораздо сложнее менеджеру даётся понимание, что нельзя ругать свою команду своему начальству. Неопытный менеджер часто хочет оправдать проблемы на своём проекте ошибками подчинённых: “Мы релиз задержали из-за того, что Игорь пропал без объяснения причин и не сделал свои задачи!”

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

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

Так что не надо рассказывать своему начальству, подчинённым и знакомым, что вы завалили свои задачи из-за трудностей с командой. Лучше поругайте себя за то, что не справились со своей работой.



“Не хочу, не буду!”

Часто нежелание человека делать свою работу представляют как “смертный грех”, который ставит крест на работнике как профессионале, и с которым менеджер ничего не может поделать. Говорят: “Ничего нельзя сделать, если человек просто не хочет работать”. Как и большинство прочих расхожих истин, эта "истина" ложная и часто заводит менеджеров не туда.

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

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

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

Легко вспомнить ежедневные ситуации, когда человек высказывает своё “не хочу, не буду”. Например, от заказчика приходит очередное изменение давно реализованных требований и надо переписывать код. Или менеджер хочет, чтобы оценка в часах была вписана во все тикеты Jira. Или кто-то сломал билд, а от непричастного к этому разработчика ждут, что он его починит. Или заказчик организовал ежедневные митинг в неудобное время. Или нужно задержаться для исправления мелкого, но неприятного бага.

Во всех перечисленных ситуациях естественной реакцией многих будет: “Не хочу!” Кто-то справится с этой реакцией сам, кто-то пойдёт жаловаться менеджеру и тому придётся заниматься этой самой мотивацией. Но в любом случае в IT командах нежелание что-то делать даже из того, что делать надо обязательно, является нормальным. Это часто удивляет людей, от IT далёких.

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

К тому же люди в IT часто бывают высочайшими профессионалами. И даже, если они почему-то чего-то не хотят, то они всё равно могут выдавать очень хороший результат.

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

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



История про способ уволиться

Маша работала не в IT, она была менеджером по продажам. Маша делала “холодный обзвон”, каталась по офисам компаний и заключала новые контракты. И она очень не любила увольняться. Никто не любит, конечно, но она прямо терпеть не могла эти последние разговоры,  эти упрёки: “Ну что ж ты так нас подводишь?” от уже бывшего начальника, эти ненужные никому вопросы и ответы и эту бессмысленную двухнедельную отработку. А увольняться ей приходилось часто. Она постоянно меняла места работы.

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

Вот и в этот раз она решила “увольняться” старым испытанным методом – просто не вышла на работу. Её начальник, Иван Иваныч, звонил много раз, так что ей даже пришлось добавить его в “чёрный список”. Звонили и из отдела кадров пару раз, но она не брала трубку. Чего тут разговаривать? И так всё понятно.

Но когда она через обычные две недели пришла за своей трудовой, в отделе кадров ей сказали, что она не уволена. “Иваны Иваныч, приказ на тебя не подавал”, – ответили они. А тут и сам Иван Ивановичприбежал: “Машенька, ну наконец-то ты вернулась! Что случилось? Я знал, что что-то случилось. Ты так неожиданно пропала, и телефон твой перестал отвечать. На меня начальство давит, чтоб я нашёл тебе замену, но я-то тебя знаю. Я знал, что ты вернёшься и все наладишь. И вот ты вернулась! Ты когда сможешь полностью на работу вернуться?”

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



Признание ошибок

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

Разработка скорее похожа на съёмки фильма. Да, есть сценарий, но он не включает в себя все детали и постоянно переделывается. Каждая сцена снимается и переснимается, пока не получится так, как надо. И в процессе случаются многочисленные накладки разной степени ужасности: актёры беременеют, бюджет меняется, меняются законы и т.д. В таких условиях даже сам подход “сделать сразу без ошибок” не имеет смысла. Это как сказать актёрам: “Плёнки на дополнительные дубли нету, играйте сразу нормально”.

Для людей из многих других областей неизбежность ошибок кажется ненормальной. Особенно странным им кажется то, что разработчик не несёт никакой ответственности за сделанные им баги. Для нас, работающих в IT, такое положение дел логично и понятно.

Одно время я вёл примерный учёт заведённых на меня багов. Для разработчика каждый баг можно считать официальной регистрацией сделанной им ошибки. Вести счёт я прекратил, когда багов стало больше 3000. Менеджер делает свою работу в тех же условиях неопределённости, что и разработчик, поэтому в IT проекте будут менеджерские ошибки. И их будет много.

Иногда бывает, что разработчик, которому сказали, что по его функционалу нашли 20 багов, удивляется и начинает их разбирать: “Ну, этот баг – это не я виноват, это там у нас дизайн кода такой кривоватый. А эти два бага надо в один объединить, и вообще это, скорее, в требованиях ошибка. А эти баги я уже исправил, это у вас просто код старый в тестирование ушёл. А эти баги очень мелкие, они не считаются. В общем, я реализовал всё без ошибок!”

Очень странно слушать такие речи от разработчика, но совсем недопустимо, когда подобное говорит менеджер. Вместо оправданий менеджеру нужно брать на себя ответственность. Любая ошибка, сделанная командой – это ошибка менеджера. Менеджеру полезно это не только знать, но и признавать публично.

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

Во-вторых, проблема не может быть решена на том уровне, на котором она возникла (© Альберт Эйнштейн). Если некоторый Вася обрушил продакшн, неправильно реализовав какой-то кусок кода, то очень хочется в виде решения поругать Васю и сказать ему, чтобы он так не делал. Но обычно такие ситуации означают, что процесс построен неверно, и надо менять его, а не Васю. Юнит-тесты, код-ревью, автоматизация, Continuous Integration и прочие плотно вошедшие в индустрию практики как раз позволяют избегать тех ситуаций, в возникновении которых пару десятков лет назад обвиняли “нерадивых разработчиков”.

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

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

Только менеджер должен быть очень конкретен в признании своих ошибок. Недостаточно заявить: “Вот, у заказчика сервер упал и не поднимается. Это моя ошибка, так как только по ошибке я мог нанять таких косячников, как вы. А теперь давайте вместе подумаем, как всё исправить”.

Нужно быть очень аккуратным в выборе слов, чтобы подать пример. Менеджер должен сказать то, что он хотел бы услышать от каждого из своей команды. Например: “Как вы уже знаете, продуктовый сервер заказчика на новой версии не работает, старая версия не восстанавливается, и заказчик несёт большие убытки. Причина может быть в том, что я запланировал недостаточно тестирования на этот релиз. Или в целом процесс релиза я не сделал надёжным. Или, может, мне надо было сильнее вовлечь заказчика в процесс проверки релиза. Точная причина неизвестна и не важна. Над предотвращением таких проблем в будущем мы подумаем позднее, когда пожар потушим. А пока, кто что может предложить для того, чтобы починить сервер сегодня, чтобы, когда клиенты заказчика проснулись, они могли бы работать?”

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



Добренький менеджер

Люди – животные социальные. Мы все хотим симпатий окружающих нас людей и стараемся избегать действий, которые вызовут неодобрение. Особенно, если мы говорим о людях, которых мы уважаем. Менеджеры уважают свою команду, и им бывает тяжело делать что-то такое, из-за чего их могут посчитать “плохими”. Неопытные менеджеры стараются быть “добренькими”, не делать ничего, что могло бы негативно отразиться на других.

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

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

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

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

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

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

В общем, день у команды прошёл нескучно. Листок рвали и переписывали. Возникали стычки и склоки. Каждый припомнил всё, про каждого из коллег. Кто-то не выдерживал и уходил. Кто-то из ранее ушедших возвращался. В общем, менеджеру листочек с пятью фамилиями пришёл только в конце дня. Он очень удивился, так как ещё утром к нему пришла Оленька с готовым списком. Оснований не доверять тому списку у менеджера не было, так как фамилия Оленьки там была первой. Он уже составил приказ и утвердил его у руководства. Пётр тоже был в том списке.

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

Желая остаться “добреньким” менеджер разрушил свою команду, и причинил много вреда ни в чём не повинным людям. Он перекинул принятие решений на свою команду, которая не имела ни навыков, ни полномочий такие решения принимать. Поэтому вся ситуация и вылилась в такой небольшой филиал ада.

Как было правильно менеджеру провести сокращение команды? Да как угодно! Он мог выбрать пятерых по алфавиту, по времени приёма на работу или полностью случайно. Да, ему пришлось бы объяснить, что его выбор несправедлив, но это просто потому, что никакой справедливости в этой ситуации нет. Да, был бы негатив, направленный против него, но это неотъемлемая часть работы! Менеджер и нужен, чтобы нести ответственность за свои решения.

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



История про жажду критики

Я работал в одной компании, где было принято очень мягко работать с сотрудниками. Там было не принято выражать критику, не важно, насколько осторожной она была. Там менеджеры очень хорошо прокачивались в сглаживании острых углов и избегании конфликтов. А работа была тяжёлая. Не все выдерживали. Многие уходили в нервный срыв, а кто-то просто брал на себя слишком много и не справлялся, подводя команду и заказчика.

Но даже, когда кто-то из команды начинал вести себя непрофессионально, его не одёргивали. Его очень мягко направляли, советовали, уговаривали. Часто подключали специалистов HR, которые так же мягко пытались привести  человека в норму. Даже когда становилось очевидно, что сотрудник не может выполнять свои обязанности на нормальном уровне, его переводили на более спокойный проект, давали лёгкие задания, оставляя формально ту же должность. Людей не расстраивали.

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

Кстати, именно работая в той компании, я понял, что критика как инструмент управления, в общем-то, менеджеру не нужна. Она важна для развития человека, и то только если человек готов её воспринять. Но даже у таких готовых к критике людей первая реакция на критику негативная. А для менеджера это лишние сложности. Даже если человек плохо выполнил свою работу, можно просто уточнить, как вы хотите, чтобы она была выполнена. Без всякого негатива. Можно даже извиниться, что изначально “некорректно” поставил задачу. Признать ошибку, похвалить человека и пойти дальше, унося критику с собой. Я и сам научился так делать, и много раз видел, как так делали с другими.

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

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

В результате это недоверие стало одной из причин, по которой я компанию сменил. Зато я на своём примере понял, насколько прямота нужна людям. А прямота иногда включает и критику.



Раздел 3. Бабло

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

Прибыль и затраты

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

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

Продуктовая компания получает деньги за продажи своего продукта. У неё может вообще не быть ни одного разработчика (такое случается, например, на старых продуктах, которые слабо поддерживаются), но она будет получать деньги. Разработчики для продуктовой компании – это в первую очередь источник расходов. На доходы они влияют косвенно, разрабатывая продукт.

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

С прибылью разобрались. А что составляет основные затраты компании? В аутсорсе всё просто. Основная статья затрат – это зарплата технических специалистов, особенно разработчиков. Вспомогательный персонал относительно немногочислен. Затраты на инфраструктуру невелики по сравнению с фондом зарплаты.

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

Каковы затраты продуктовых компаний? Здесь всё гораздо разнообразней. Процент затрат на разработчиков высокий только на первых этапах жизни продукта. Потом он сильно снижается. Зато есть много других источников затрат: на специалистов поддержки, на продажников, на маркетинговые кампании, на инфраструктуру (что может быть очень много для SaaS продуктов). В результате зарплаты разработчиков не очень сильно влияют на экономические показатели продукта. Если какой-то специалист приносит реальную пользу бизнесу, ему могут платить очень и очень много. Поэтому, например, в США, где уровень зарплат высок, продуктовые компании выживают, а аутсорсные практически нет.

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

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



История про посреднический процент

Проводил собеседование в одну продуктовую компанию. Все свои вопросы задал, пришла очередь кандидату задавать свои вопросы.

– У меня только один вопрос, – сказал он. – Вот зарплату вы предлагаете гораздо выше конкурентов. А сколько ваша компания будет брать сверху моей зарплаты с клиента?

– Нисколько. Мы продуктовая компания, мы и есть клиенты.

– Как так?! Наверняка же сколько-то накидываете! Мне нужно знать, сколько!

– Мы не бодишоп, мы людей не перепродаём. Деньги компания получает от продажи продуктов, а разработчики эти продукты создают. Никакой “наценки” нет.

– А, ну хорошо. А то на прошлой работе оказалось, что клиент компании платит в три раза больше, чем я получаю.

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

– Ну, нет. Слишком жирно им будет ни за что такие деньги получать! Хорошо, что у вас такого нет.

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



Зарплата и благосостояние

Менеджеры по-прежнему используют денежную мотивацию как основную. Но при этом редко кто задумывается, насколько относительны и субъективны денежные суммы. Кажется, что сумма зарплаты – это величина объективная. Но когда мы начинаем рассматривать мотивацию, всё становится субъективным и оценивается через призму восприятия конкретного человека.

Итак, предположим у нас есть разработчик, получающий 100 тысяч рублей в месяц. Сколько он должен получать, чтобы чувствовать себя в 2 раза богаче? Очевидно, что удвоение зарплаты будет ощущаться скорее как десятикратное увеличение благосостояния. Человек сможет себе позволить просто новый уровень жизни. А что будет увеличением в два раза?

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

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

То есть если человек из своей зарплаты в 100 тысяч рублей тратит 90 тысяч на необходимые себе вещи, то достаточно повысить ему зарплату всего на 10 тысяч, чтобы он стал себя чувствовать себя в 2 раза богаче. Именно поэтому человек, у которого обязательные траты приближаются к доходам, склонен сменить работу даже из-за совсем небольшой прибавки зарплаты. Для него эта небольшая прибавка воспринимается как громадная пропасть между нормальной жизнью и экономической катастрофой. И именно поэтому в Москве, где уровень трат крайне высок, разработчики отличаются меньшей лояльностью к компании и очень ориентированы на денежную мотивацию. В регионах же, наоборот часты ситуации, когда люди отказываются от предложений удвоения зарплаты. Они имеют достаточно денег, чтобы закрыть необходимые траты и порадовать себя.

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

Во всех этих рассуждениях есть два важных момента. Первый момент заключается в том, что уровень “необходимых трат” является полностью субъективным. Я видел человека, который считал, что его семья живёт хорошо, если они могут позволить себе есть мясо. Я видел другого человека, который считал, что он живёт нормально (даже не хорошо), если он может купить квартиру за 2 года без начальных накоплений. Зарабатывал второй человек больше первого. Ощущал себя беднее.

Второй момент заключается в том, что у семейных людей бюджет часто общий. И траты, и доходы суммируются, и всё становится ещё сложнее. У одного разработчика жена имеет дорогие привычки и не имеет доходов, а у другого – муж владеет контрольным пакетом акций крупной корпорации и содержит семью на свои деньги. Отношение к деньгам будет очень различно.

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



История про увольнение из-за повышения зарплаты

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

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

Заморозка зарплаты во время общего роста цен фактически означала падение реальных доходов. Это коснулось абсолютно всех. Разработчики, тестировщики, аналитики и менеджеры стали жить всё хуже и хуже. Но открытая позиция компании всем понравилась. Большинство сотрудников проработали много лет в компании, очень её ценили и готовы были потерпеть временные трудности, чтобы помочь компании, которая была для них похоже на семью.

“Заморозка” зарплат длилась пару лет. И люди терпели. Абсолютное большинство не искало возможности сменить работу ради более высокой зарплаты, хотя предложений на рынке становилось всё больше и больше.

И вот настал день, когда компания официально объявила, что тяжёлые времена прошли, что компания теперь планирует расширяться и что зарплаты будут повышены. Директор поблагодарил всех за ту помощь, которую работники оказали компании во время кризиса. И все зарплаты были повышены процентов на 15.

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

После этой истории меня спрашивают, не было бы разумней со стороны компании, не объявлять об окончании кризиса и о повышении зарплат, а продолжать работать дальше. Ведь сотрудники бы продолжали “поддерживать родную компанию” и не увольнялись бы ещё год-другой. Компания бы заработала больше денег. А так она потеряла деньги на повышении зарплат, а потом ещё и на увольнениях. Компания же работает для прибыли, так зачем её терять?

Так вот компания поступила абсолютно правильно. Заметьте, что как раз открытая и честная позиция компании помогла ей пережить трудные годы. Если бы компания начала бы развиваться и набирать людей, не “размораживая” зарплаты, то команда мгновенно бы поняла, что её обманывают. Тогда компания потеряла бы не только людей (причём гораздо большее количество), но и имидж. Потери даже в средней перспективе были бы гораздо больше, чем “сэкономленные” на зарплатах деньги.

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



Премия разработчика

Далеко не все менеджеры определяют премиальную систему компании, но всем им приходится работать с последствиями её применения. К тому же рассмотрение проблем с премиями показывает общие проблемы с денежной мотивацией. Я вижу некоторые плюсы от ежегодной премии (13 зарплата) или бонусов за завершение релиза. Но ежемесячная премия даёт больше проблем, чем преимуществ.

Почему? Источник этого в том, что в IT пока не придумали действительно эффективных метрик для измерения работы разработчика (как и тестировщика, аналитика и менеджера, но об этом пока не будем). Притчей во языцех является измерение работы количеством строчек кода и то, в какой ужас превращается код при этом.

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

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

К тому же в большинстве компаний премии строятся не по логике достижения, а по логике избегания. То есть декларируется принцип: “Не делай вот так, а то мы лишим тебя премии!” Нормой является наличие премии, а отсутствие её используют как наказание. Это сильно мешает созданию высокомотивированных команд, так как постоянно висящая над человеком угроза наказания давит инициативу.

Чтобы все эти проблемы были не такими значительными, премию делают низкой: 10%..15%. Разработчики обычно не сильно спорят из-за такой небольшой части своей зарплаты. Но это кроме снижения эффективности мотивации даёт еще один неожиданный эффект.

Разработчик может согласиться на лишение премии и отказаться от выполнения этих установленных норм. И менеджерам очень тяжело с этим работать. Это как со штрафом за превышение скорости. Водитель превысил – получил штраф. И всё, этим он искупил проступок. Да, он считается нарушителем и потом это может играть какую-то роль, но за конкретное превышение скорости он рассчитался.

У меня был такой случай в компании, где оплата разработчиков была почасовая, но чтобы стимулировать их работать 40 часов в неделю, им выдавалась премия 10%, если они работали полную рабочую неделю. И вот ко мне пришёл разработчик и сообщил, что у него очень много времени отнимает дополнительное образование и он решил отказаться от премии и работать полдня. А меня как менеджера такое не устраивает. Мне он нужен на проекте хотя бы 30 часов в неделю. А человек возмущён. Если он будет работать 30 часов, то ему будет очень тяжело, а его всё  равно накажут лишением премии. Хотя он идёт мне навстречу. В IT проектах важна командная работа, а премия концентрирует внимание разработчика на его собственных показателях.

К тому же любая премиальная система снижает управляемость. Примерно на уровне, когда премия составляет 80% зарплаты работник становится полностью неуправляемым и делает не то, что ему говорит его менеджер, а то, что требует его премиальная система (см. книгу “Мотивация на 100%. А где же у него кнопка?” Ивановой С.В). Но даже при 10% иногда премия мешает.

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

Забавная ситуация случилась как-то со мной. Я  работал в компании, где премия составляла значительную часть, примерно 30% моей зарплаты и была квартальной. Причём, сумма премии от меня зависела не сильно. Премия зависела от курса доллара, прибыли за квартал и тому подобных вещей. А от меня зависело, получаю я премию или нет. То есть я работал 3 месяца, получая откровенно маленькую зарплату, а потом получал некоторую сумму денег, величину которой мне никто не мог сказать заранее.

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

– Вы мне оклад повысили на 15%, а на сколько вырастет моя зарплата вместе с премией? Меня же полная сумма интересует.

– Никто не знает. Величину премии мы каждый раз заново рассчитываем.

– Но хотя бы суммарная зарплата в следующем квартале будет выше, чем в этом?

– Неизвестно. Может быть и ниже, если премия будет меньше.

– То есть мой оклад повысили, но зарплата может и уменьшиться?

– Ну да…

Я понимал, что происходит с точки зрения имеющейся системы, но с точки зрения здравого смысла было смешно.

В той же компании мой коллега-менеджер просто плюнул на премию и не делал ничего для её получения. Премия была нулевая. Зато он на проекте сильно перерабатывал, и оплата этих переработок превышала величину премии. Это было очевидно выгодно, так как величину премии он контролировать не мог, а вот переработками на своём проекте он мог манипулировать легко. Но очевидно, что это не то, чего хотело руководство компании.

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

Если вам кажется, что я ошибаюсь, и в вашей компании реализована удачная система премирования разработчиков, пожалуйста, напишите мне о ней на borisovke@gmail.com. Мне эта тема очень интересна.



История про увольнение из-за повышения зарплаты (часть 2)

Ещё одна история про то, как сотрудники увольняются, когда им повышают зарплату.

В компании работал очень опытный и очень лояльный разработчик, Игорь. Он начал свою работу как студент-интерн и вырос в компании до уровня тим-лида. Игорь был талантливым и имел прекрасное образование. Он очень много принёс пользы для компании, и компания его очень ценила. Зарплату ему повышали весьма щедро. Год за годом его зарплата росла, чтобы его не могли переманить ни местные конкуренты, ни столичные компании, ни даже зарубежные предложения. По деньгам у разработчика было прямо совсем хорошо, и он даже не пытался найти какую-то другую работу.

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

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

По поводу этой истории меня часто спрашивают, не разумнее ли держать программистов “на голодном пайке”, чтобы они ценили свою работу и боялись увольнения. На это мне очень трудно отвечать серьёзно. Хорошо хоть цепями приковывать не предлагают. Я считаю, что хорошо платить за хорошую работу – это принцип, который надо соблюдать, чтобы быть успешным в средней и, тем более, дальней перспективе. Те, кто пытаются не доплачивать своим сотрудникам, не удерживаются на таком сложном и современном рынке как рынок IT услуг.

В качестве примера могу привести другой пример. Я работал в компании, условия работы в которой были откровенно тяжёлые: нервная работа, требовательный менеджмент, сложные задания, постоянное давление со всех сторон. Но оплата очень хорошая. Каждый получал в 3-4 раза больше, чем это возможно в соседних компаниях. Текучка в этой компании была просто поразительная. Многие отрабатывали 2-3 месяца и увольнялись. При этом они так и говорили: “С такой зарплатой я уже успел заработать достаточно, чтобы раздать все долги и накопить немного. Теперь попробую поискать что-то более нормальное”. На безденежье высокая зарплата привлекала, но как только финансовые проблемы были решены, люди не хотели так напрягаться, как раньше, и меняли место работы. Многие шли в эту компанию, чтобы заработать конкретную сумму: для открытия собственного бизнеса, для покупки квартиры или для переезда за рубеж. Как только сумма была накоплена, люди уходили. А копить получалось быстро.

Казалось бы, очень просто можно текучку уменьшить. Надо просто снизить зарплаты. Тогда люди будут вынуждены работать дольше, и текучка будет ниже. Да ещё и экономия денег на зарплате будет большая. Одни плюсы и никаких минусов! Так?

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



Кейс "Деньги за тестовое задание"

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

Коллега связался со мной и описал, что их компания пытается бороться с этой проблемой, оплачивая $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, то это вы не классно сэкономили так бюджет, а увеличили риски. А увеличение рисков – это рост бюджета, они денег стоят. Теперь у вас в проекте есть бомба, которая может сработать и вы вылетите за бюджет. Причём, даже не будете понимать, почему так произошло. Просто сработал риск, бывает.

Ваш процесс может покрывать (а может не покрывать) мелкие исправления после демо. Но он точно не покрывает случайные “мелкие улучшения” разных кусков системы. Здесь очень хорошо помогает навык менеджера организовывать процесс. Добавить тикет на это улучшение, убедить заказчика, что лучше подкопить изменения и вернуться потом к этому экрану, подгадать изменение к регрессионному тестированию, чтобы не создавать дополнительной работы для тестировщиков – это всё часть работы менеджера по управлению скоупом.

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

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

Например, сейчас все понимают, что требования должны быть готовы и одобрены до начала разработки. Если разработчик начнёт писать код и через час споткнётся о неясность, то ему придётся уточнять вопрос у заказчика (или ещё кого-то), а самому переключаться на какую-то другую задачу, отвлекать тимлида или менеджера с просьбой эту задачу дать. В результате отвлекается не один человек, а несколько.

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

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

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

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

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



История про самую распространенную причину провала проекта

Как-то, проходя мимо переговорки, я заметил большую толпу заходящего туда народа и коллегу-менеджера, Макса. Я остановился и спросил, что происходит.

– Да вот ретроспективу своего проекта проводить буду. Должно быть интересно. Мы проект завалили, в полтора раза дольше делали, чем это планировалось. Заказчик крайне недоволен да и наше руководство тоже.

– А почему завалили-то?

– Ты знаешь, Константин, я сам понять не могу. Вроде, всё по плану шло, ничего беды не предвещало. А в самом конце вдруг выяснилось, что не успеваем закончить вовремя и так вот и потянулось дальше: то одно, то другое, и все сроки откладываются и откладываются.

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

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



Так что же является новым скоупом?

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

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

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

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

Именно поэтому мы в бюджет проекта закладываем очень большой буфер на возможные изменения. Мы знаем, что заказчик захочет сделать эти изменения, и отказ будет воспринят как дешёвый сервис. А IT компании работают (или пытаются работать) в области дорогого, а следовательно, качественного сервиса.

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

Так и при разработке проектов. Мы включаем в бюджет буфер на то, что заказчик будет вносить изменения в UI, что он будет уточнять и расширять бизнес-логику, что какие-то требования он вообще не сможет нам предоставить и нам их придётся создавать самим. Это всё составляет уровень сервиса, за который заказчик и платит.

Но для менеджера такой подход создаёт дополнительные трудности. Потому что заранее никто не знает, что именно включено в бюджет. Менеджеру надо точно отслеживать, остаётся ли объём задачи в рамках запланированного или нет. А после того, как он решит, что объём превышает план, его ждёт следующая ступенька квеста – нужно в этом убедить заказчика и как-то решить денежный вопрос.

Это как если клиент в парикмахерской просит дополнительно подровнять брови и к кофе дать шоколадку. Мастеру гораздо проще дать это бесплатно и сделать клиенту приятно, чем отказать и, потенциально, нарваться на конфликт. Но потом этот клиент попросит шоколадку ко второму своему кофе. И в следующий свой визит попросит бесплатную стрижку бровей. Чем дальше, тем труднее будет отказать такому клиенту. Ведь раньше всё было включено.

Так и с проектами. У менеджера есть выбор: либо продемонстрировать клиентоориентированность и гибкость и сделать, что просит заказчик, либо напомнить про бюджет и пойти на потенциальный конфликт. Менеджеры не враги себе, они выбирают “простой” вариант. Особенно при подходе Time&Material, когда все дополнительные хотелки всё равно будут выполнены за счёт заказчика.

Но когда в парикмахерской клиенту выставляют счёт и он видит, что его шоколадка стоит так же, как и стрижка, конфликт гораздо острее, чем объявленная заранее цена. Бесплатного ничего нет. За всё кто-то в конце-концов заплатит.

То есть менеджеру, чтобы эффективно контролировать scope creep, нужно как чётко понимать, какие работы были запланированы изначально и что добавилось позже, так и иметь хорошие навыки в переговорах/продажах. Однако такая ситуация имеет и плюсы. Если вы имеете мощные переговорные навыки, то некоторые упущения в контроле объёма работ, могут не быть такими критичными. И наоборот, если вы очень хорошо умеете планировать и отслеживать, что делает ваша команда, это даст вам отличные аргументы в переговорах с заказчиком.



История про предугадывание желаний

Однажды я пришёл в новую парикмахерскую. Мне нравится пробовать разные образы, и мне интересно давать свободу мастеру, поэтому стрижку я заказал, как обычно: "На ваше усмотрение, но чем безумнее, тем лучше". Мастер позадавал наводящие вопросы и пообещал сделать стрижку, "как в Омске точно не стригут" и "за эту стрижку из соседнего барбершопа мастера выгнали". Результат мне понравился, но я был немного удивлён. Мастер не использовал длину моих волос, а сделал очень короткую стрижку. Она была довольно сложная в исполнении, но не “безумная”, как я формулировал, а скорее “практичная”. Спортсмены и военные что-то подобное носят.

Я спросил у него, почему он сделал именно такую стрижку. Ответ сделал мой день: "Ну ты же программист, вряд ли хочешь сильно с укладкой париться". Мастер при этом улыбался знающей улыбкой, искоса поглядывая на меня, как бы говоря: “Здорово я угадал, правда?”

И здесь мы видим очень важный момент, с которым менеджеры сталкиваются постоянно. Обратите внимание, что мастер не спросил меня, готов ли я укладывать волосы. Вместо этого он спросил меня, чем я занимаюсь, и сделал выводы. Хотя казалось бы спросить напрямую  гораздо проще и безопасней. Можно просто спросить, получить ответ и не рисковать ошибиться. Зачем играть в “угадайку”?

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

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

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



Секреты успешных Fixed Price проектов

Абсолютное большинство аутсорсных проектов ведётся по принципу bodyshop. Компании продают разработчиков заказчику и в управлении проектами не участвуют или почти не участвуют. Это не интересный для менеджера проектов вариант.

Следующая ступенька, до которой уже доходят далеко не все, это Time&Material проекты, когда уже аутсорсер сам занимается управлением проектом, но оплата идёт по отработанным часам. В таких проектах заказчик имеет возможность подходить к бюджету гибко и изыскивать дополнительные финансы при необходимости.

Fixed Price проекты – самые жёсткие. У заказчика есть фиксированный бюджет и в него нужно уложиться при любом раскладе.

Все аутсорсные компании хотят научиться делать Fixed Price проекты (и практически никто не умеет это делать). Дело не в том, что эти проекты дают больше прибыли (хотя это и так). Дело не в том, что успехи в Fixed Price проектах означают высокий профессионализм команд и совершенство процессов (хотя это тоже так). Дело в том, что Fixed Price проекты не могут быть сделаны никак иначе. У заказчика есть некоторый бюджет и требования, которые ему нужно реализовать. Он не может превысить бюджет по соображениям бизнеса. Он готов платить больше, чем он заплатил бы по Time&Material, но ему нужны гарантии, что он уложится в бюджет. Это требование бизнеса. И такие проекты могут получать только те, кто умеет делать Fixed Price.

Я видел достаточно успешных и неуспешных Fixed Price проектов, чтобы утверждать, что секрет их выполнения – это контроль скоупа проекта. Я уже писал в главе “Куда ползёт scope” про те источники превышения бюджета, о которых обычно забывают. Но с Fixed Price проектами описанное там приобретает на порядок большую важность.

Что будет, если менеджер на проекте Time&Material допустит превышение бюджета? Аутсорсер получит больше денег! Потому что, чтобы довести проект до конца, заказчик будет вынужден найти больше денег и компания-аутсорсер получит больше прибыли6. Что будет, если менеджер на проекте Fixed Price допустит превышение бюджета? За это придётся заплатить компании, и она потерпит убытки.

Часто на проектах Time&Material даже ставятся задачи найти какой-то дополнительный объём работы и “допродать” его заказчику. Это фактически управляемый scope creeping. При Fixed Price дополнительные объёмы всегда идут по одной схеме: закончите этот проект качественно и в срок, и мы будем дальше с вами работать.

Подходы эти настолько разные, что я бы даже не рекомендовал одному менеджеру вести одновременно Fixed Price и Time&Material проекты. Потому что нужно иметь совсем разный настрой и по-другому общаться с заказчиком. Конечно, менеджерские навыки там и там нужны одинаковые, но их использование сильно отличается.

Но дело даже не только в настрое менеджера и его квалификации. К команде тоже предъявляются другие требования. Я видел компании, где для менеджеров проводятся тренинги по Fixed Price проектам и ведётся анализ успехов и неудач, но на разработчиков очень редко обращают внимание. А это важно.

Помните ту историю, которую я рассказал в главе “Куда ползёт scope” о разработчике, который прямо не митинге с заказчиком реализовал какие-то требования? Так вот, если бы в проекте Fixed Price такое произошло, то наверняка бы раздался звук чего-то тяжёлого, брошенного менеджером в голову этого разработчика, чтобы вывести того из переговорного процесса. Потому что в bodyshop-проекте такое поведение является желаемым (инициатива полезна!), в Time&Material – иногда терпимым (путает процесс, но работает на удовлетворение заказчика), а вот в Fixed Price – категорически вредным.

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

Вообще, далеко не все компании обращают внимание на чёткое разделение ролей и дисциплину. Как-то в одной компании мой разработчик без всякого согласования со мной сообщил заказчику, что мы не можем выполнить условия контракта. Хорошо, что заказчик оказался с очень развитым чувством юмора. Но для меня, не привыкшего, что разработчики берут на себя роль CEO, это был настоящий шок. А просто в той компании никто не думал о том, кто именно за что отвечает, и кто за что несёт ответственность.

В Fixed Price проектах команда должна понимать всю сложность проекта и очень осторожно действовать с требованиями, оптимизациями, предложениями и замечаниями заказчика.

Тут меня могут спросить: “А как же Agile?! Мы же все такие гибкие и ориентированные на изменения под требования заказчика!” Всё так и есть. Здесь Fixed Price проекты не выделяются. Я успешно делал Fixed Price проекты по Scrum (и это было весело). Но надо учитывать, что высший приоритет заказчика – это бюджет. Любые предложения что-то добавить ведут к необходимости что-то выкинуть. Это можно сделать и реально делается, но надо быть осторожным.

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

Причём, заказчик в Fixed Price проектах абсолютно осознанно сам за объёмом работы не следит. Он ведь специально заплатил вам больше денег, чтобы вы это делали за него. И в контракте его очень точно прописано, что нужно сделать и за сколько. Так что любые улучшения, которые вы предложите и на которые он согласится, будут за ваш счёт.

Жёсткое отслеживание объёма работы в случае Fixed Price проектов – это не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.



История про объединение оценок

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

– Так, первый пункт “Экран ввода данных”, у Дмитрия общая оценка получилась 200 часов. Посмотрите ваши оценки, у вас такие же часы получились по подзадачам?

– Нет, у меня больше на создание БД. 32 часа вместо 24. Мне кажется мы там провозимся, – озвучивал я свои отличия.

– Отлично, ставлю 32 на создание БД, – Владимир не спорил.

– А у меня ещё там есть подзадачка обновление юнит-тестов на 6 часов. Но её Дима, наверное, по другим раскидал, – заметил другой разработчик, Алексей.

– Хорошо, добавляю задачку на юнит-тесты на 6 часов, – Владимир обновлял оценку, пока говорил ответ. – Всё по этой задаче? Следующая: “Отчёт по премиям”.

– У меня там на дизайн формы в два раза больше времени…

– А у меня ещё на экспорт и отправку почты маленькие задачи.

– Добавлено, – оценка росла как на дрожжах. – Двигаемся дальше.

Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:

– Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.

– Константин, мой опыт показывает, что если кто-то видит какую-то проблему, то он прав, эта проблема обязательно возникнет и мы потратим на неё время. – Владимир шёл по задачам, округляя все числа в большую сторону. – А это мне ещё все говорят, что я слишком оптимистичен.



Почему Scrum не решает менеджерских задач

Сразу скажу, что я очень уважаю Scrum как философию. Scrum привнёс очень много в индустрию разработки ПО. Достаточно вспомнить хотя бы скрам-митинги, которые сейчас используются повсеместно. И в продуктовой разработке, на которую Scrum ориентирован в первую очередь, результаты его применения очень хороши. Но проблема в том, что Scrum часто позиционируют как средство управления проектами, которым он совсем не является. Да и вообще, как средство управления Scrum вообще рассматривать не стоит. Давайте посмотрим, почему.

Сложность. В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.

Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат.  Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.

А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.

Даже традиционные статистические методы предсказания конца проекта, которые неплохо работают в традиционных проектах (например, статистика багов), очень плохо работают в Скраме, так как он не даёт никаких ограничений на элементы баклога.

От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.

Командообразование. Может быть, скрам как-то помогает сколотить команду в единое целое? Отнюдь. По скраму команда является самоорганизующейся (self-organizing), а скрам-мастер может только заниматься коучингом (coaching). А коучинг, между прочим, является сложнейшей менеджерской техникой, когда менеджер, абсолютно не высказывает своего мнения и помогает человеку прийти к решению самому. Как овладеть скрам-мастеру такой техникой? Ответа нет. Что делать, если в команде конфликты, если часть команды ведёт себя контрпродуктивно, если разные члены команды действуют неслаженно? Ответа нет.

Даже самыепростые вопросы координации скрам не освещает. Например, у вас есть разработчики, тест-дизайнеры, автоматизаторы и ручные тестировщики. Как они должны работать, чтобы никто не простаивал, а спринт выдавал качественный результат? В начале спринта у тестировщиков нет тест-плана, а в конце спринта у тест-дизайнеров нет работы. Скраму это безразлично.

Управление большими командами скрам тоже не поддерживает, указывая, что команды больше 9 членов “нуждаются в слишком большом объёме координации”. А ведь размер команды как раз является одним из показателей мастерства менеджера. Скрам это не покрывает.

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

Риски и кризисное управление. Скрам заявляет, что следование ему позволяет контролировать риски, но никаких средств по управлению рисками не предоставляет. Предполагается, что максимум, что может пойти не так – это придётся “откатить” работу одного спринта. На практике, конечно, это совсем не так. Повсеместно встречаются проекты, в которых много одинаково критичных кусков, без каждого из которых система не нужна. Успех любого количества спринтов может быть легко перечёркнут одной проблемой, вылезшей в самом конце проекта.

И, конечно, скрам никак не помогает в ситуации, когда проект заходит в тупик по какой-то причине.

Список ограничений можно продолжать долго. Проще сказать, что скрам не закрывает ни одной функции менеджера. Значит ли это, что менеджеры должны его игнорировать? Ни в коем случае! Я считаю, что сейчас каждый работающий в сфере разработки ПО должен хорошо представлять, что такое скрам и уметь работать с ним. Но относиться к скраму нужно не как к инструменту менеджмента, а как к набору идей, которые расширяют сознание и вырабатывают полезное отношение ко всему процессу разработки.



Для чего нужен Scrum

После предыдущей главы у кого-то, возможно, в голове возникает вопрос: “Ну и зачем этот скрам вообще тогда нужен?!” На самом деле, существование скрама очень полезно для всех.

Во-первых, давайте рассмотрим, почему скрам вообще возник. Скрам объявляет эмпиризм своей основой, то есть он полностью ориентирован на практику. А какая самая заметная черта проектов в IT? Самая заметная черта – это то, что они, в основном, проваливаются.

В соответствии с Chaos Report от Standish Group в 2015м году процент успешных проектов в IT был всего лишь 29% Причём, этот процент мало изменился с 1996го года (тогда он был 27%). Что это значит? По большому счёту, это значит, что менеджмент проектов в IT не работает. Если проект провалился, то это провал руководителя проекта.

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

С другой стороны, у IT проектов есть особенности, которые иногда сводят на нет усилия даже опытного менеджера. Первая особенность заключается в том, что успех проекта сильно повышается, когда руководство заказчика его поддерживает и понимает цели бизнеса. Standish Group в своих отчётах пишет этот вывод постоянно.

А вторая особенность заключается в том, что маленькие проекты завершаются успехом гораздо чаще, чем большие. Среди успешных проектов 62% было маленького размера и 21% “небольшого” размера (moderate, что меньше medium).

Теперь становится понятней, почему Scrum “работает”. Он во-первых, ограничивает количество людей в команде. А во вторых, требует постоянно актуальный и отсортированный баклог и всегда доступного Product Owner’а, который как раз обеспечивает необходимое участие заказчика в проекте.

Прелесть Scrum’а в том, что он уже является своего рода стандартом разработки. Все заказчики его знают и понимают. Поэтому, менеджеру очень легко пользоваться им как инструментом.

Например, сроки горят и заказчик требует увеличить команду с семи человек до двадцати. Ситуация стандартная и, обычно, менеджеру приходится прилагать много усилий, чтобы отговорить заказчика от этой идеи. А тут можно очень просто сформулировать: “Это противоречит Scrum Guide и может привести к непредсказуемым последствиям. Оно вам правда надо?” Слово “Scrum” для заказчиков является аргументом, потому что они знают, что это Best Practice отрасли . Иногда даже использование Scrum прописывается в контракте. Тогда всё ещё проще.

Или вот тоже распространённая проблема, когда заказчик затягивает с ответами на вопросы команде. Раньше приходилось всю ночь вылавливать заказчика в его часовом поясе и выслушивать какие-то отговорки. А сейчас можно просто отправить грозное письмо: “В соответствии со Scrum для работы команды необходим Backlog с чётким описанием каждого элемента. Сейчас мы такого баклога не имеем. Последствия могут быть любыми”. В кратчайшие сроки заказчик сам выйдет на связь и сделает со своей стороны нужную работу.

Scrum ещё хорош тем, что он сразу устанавливает команду как self organizing, то есть по Scrum команда должна сама за себя отвечать. Обычная проблема, когда разработчики сидят и ждут, чтоб им сказали, “что и как надо делать”, снова отпадает. Мне кажется, это оказывает настолько же мощное воздействие, как активное участие заказчика в разработке. В свою очередь, разработчики получают много возможностей влиять на проект, чтобы сделать его именно таким, каким они хотят его видеть.

Огромной ошибкой, которую я вижу у некоторых менеджеров, является игнорирование Scrum’а. Они назначают Scrum-мастера и устраняются из процесса. У них какие-то свои дела, а разработчики работают по Scrum’у. Так не стоит делать. Это противоречит основным идеям Scrum: прозрачности и ориентации на взаимодействие. Чтобы пользоваться преимуществами Scrum’а, менеджер должен быть его частью.



История про удовлетворённость клиентов

В истории маркетинга есть очень известная байка про компанию Rolls Royce. Я её периодически вспоминаю, но уже применительно к IT.

Однажды в компанию Rolls Royce пришла жалоба от клиента, которая звучала примерно так: “Вы называете свои автомобили лучшими, но их качество разочаровывает. В недавно купленном автомобиле полно явных инженерных просчётов. Наиболее раздражающий – это часы. Их тиканье настолько громкое, что я его отчётливо слышу, даже на скорости в 60 миль в час! Это просто позор!”

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

Но зато известно, что именно из этой претензии родился известный слоган компании Rolls Royce: “На скорости 60 миль в час самый громкий шум в салоне – это тиканье часов”. Этот слоган наполняет гордостью работников и привлекает новых клиентов. Этот слоган показывает качество.

Я вспоминаю эту историю каждый раз, когда премию менеджера привязывают к числу жалоб клиентов. Это простой и, вроде бы, объективный показатель, который нужно и полезно отслеживать.

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



Оценки задач

Я написал несколько глав про оценки: про PERT, про то, как проверять оценки, про оценку рисков. Но меня не оставляло ощущение, что эти главы малополезны и я их убрал из окончательного варианта книги, оставив только пару неочевидных моментов.

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

В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.

В общем, все эти, показавшиеся мне очевидными, рассуждения об оценках я убрал. Но, возможно, я был неправ. Если вам не хватает информации об оценивании задач и проектов, напишите мне, пожалуйста, о том, что именно вам хотелось бы знать: borisovke@gmail.com.



Оценка субъективна

Но один момент в оценивании необходимо упомянуть, так как я часто вижу, что его игнорируют и попадают в беду. Важно понимать, что оценка – это субъективная величина. Про это легко забыть, когда смотришь на результат оценки в долларах. Кажется, что если проект оценён в $1’000’000, то это объективно. Ведь величина бюджета – это объективная величина! Как будто у нас есть некий мешок работы и мы его взвесили. Всё точно!

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

Кажется, что это не так важно, когда мы уже получили проект. Ведь мы знаем, как наша компания работает. С новым проектом мы будем работать, как обычно. И оценка сделана из этого предположения. То есть в рамках одной компании можно оценку считать объективной?

Совсем нет. Например, если вы спросите оценщика, на какую команду он рассчитывал оценку, то он скажет либо конкретные фамилии, либо уровень. Разумно в оценку сразу закладывать определённую структуру команды: один тимлид, три senior-разработчика, 5 middle-разработчиков. Но нужно понимать, что здесь тоже заложена субъективность.

Даже одинаковые по структуре команды могут сильно отличаться по производительности, просто за счёт того, что отдельные люди не могут сработаться. А отдельные могут так сработаться, что пожениться и сбежать из компании в отпуск на Багамы.Опытный менеджер может это выровнять, а может и не выровнять. Я уж не говорю о том, что вместо планируемых middle-разработчиков обязательно в команду вкинут junior-ов. Реальный бюджет при этом изменится и не в меньшую сторону.

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

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

Поэтому, кстати, я очень против распространённой практики, когда оценивает проект один менеджер и оценщик (часто более опытные), а на выполнение проект попадает к совсем другому менеджеру и лиду.

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



Бесплатные буферы

Оценка проекта важна на этапе определения бюджета, но для контроля выполнения проекта и менеджеры, и заказчик используют плановые даты, milestones. Основная дата, дата окончания проекта, жёстко закреплена и для контроля не подходит, так как в конце проекта уже ничего изменить нельзя. А вот многочисленные промежуточные даты используются для отслеживания прогресса, координации разных команд, демонстрации системы и уточнения требований, а также многих других полезных вещей. И тут есть возможность (и необходимость) заложить буферы, которые я называю бесплатными.

Например, вы руководите проектом на 12 месяцев с довольно большой командой в 30 человек. И вы решили сделать промежуточный релиз, который будет содержать основную функциональность в приличном качестве. Заказчик готов посадить своих специалистов на проверку системы. Вы получите дополнительное тестирование, а заказчик сможет провалидировать свои требования. Если окажется, что ему нужна немного не такая система, как ему казалось, то ещё будет время что-то исправить.

Предположим, вы оценили этот релиз и получилось, что он будет готов через 6 месяцев. Так вот тут очень важно запланировать дату этого релиза на неделю (а может и на две) дальше. Этот буфер заказчику не будет стоить ничего, потому что на объём работ он не влияет. Но вам и команде будет гораздо проще жить.

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

Другой вид бесплатных буферов – это когда вы подстраховываетесь от действий других. По вашему плану нужно, чтобы требования были готовы 10 июня? Сообщите заказчику, что вы ждёте требования 1 июня. Тогда у вас хотя бы будет шанс не понести потери, когда вы получите требования плохого качества или с задержкой.

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

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

Если вы видите, что не можете добавить запас по времени в ваш план, то это повод записать в свой реестр новый риск. Это показатель хрупкости плана. Скорее всего, у вас проблемы и надо начинать их решать уже сейчас.



Цена бесплатных буферов

Хотя я и называю сдвиг промежуточных дат в плане “бесплатным” буфером, но менеджер прекрасно знает, что за всё надо так или иначе платить. Где подвох с бесплатными буферами?

Самая основная проблема заключается в том, что менеджер включает в план только “безопасные даты” и забывает, что плановые даты были другими. То есть менеджер забывает, что релиз должен быть готов не через 6.5 месяцев, а через 6. Заказчик тоже этого не знает. Поэтому, когда релиз выходит через 6.5 месяцев (по плану!), то ни менеджер, ни заказчик не осознают, что проект запаздывает на две недели.

Точнее, нормально, что это не осознаёт заказчик, но вот менеджер должен следить не только за “внешними” датами, но и за плановой скоростью реализации функционала. Я настойчиво рекомендую вставлять “настоящие” даты в свой план проекта, который заказчик может и не видеть.

Но менеджеру всё равно не так легко объяснить заказчику, что на проекте проблемы. Заказчик же видит, что всё идёт по плану. Тут можно достать этот “внутренний” план и объяснить, когда релиз должен был быть закончен на самом деле. Заказчики очень спокойно относятся к заложенным буферам, а особенно к буферам в виде сдвига дат. Ведь они им ничего не стоят!

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

И здесь начинаются сложности, потому что вы можете пойти навстречу заказчику и согласиться получить API на месяц позже. Но тогда вы берёте на себя дополнительные риски. Если этот API будет с ошибками, или недостаточно документирован, или у вас будут проблемы с доступом – ваш проект будет терпеть убытки. Но с другой стороны, если дать заказчику больше свободы, то есть больше шансов, что API будет качественным.

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

Я придерживаюсь стратегии, что если мы говорим о ранних сроках реализации проекта и оговоренные условия пойдут в контракт, то мы должны давать только “безопасные” даты. Чем безопасней, тем лучше. А вот если проблемы выплывают ближе к запланированной дате, то уже можно проявлять гибкость и сдвигать даты по договорённости с заказчиком, уменьшая “бесплатный” буфер. Но нужно быть очень прямым и объяснить заказчику в том числе и в письменном виде, что любые уменьшения буферов увеличивают риски. Тогда можно избежать расплаты за использования “бесплатных” буферов.



История про проведение ретроспективы

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

Чтобы понять, почему так произошло, организовали ретроспективу. Руководитель проекта, в лучших традициях скрама, давал всем высказаться и выписывал на доску длинный список всех проблем, которые команда называла. Опять же в лучших традициях ретроспектив, сперва давали высказываться junior-ам, чтобы более опытные члены команды не давили своим авторитетом. Самым последним слово досталось лиду разработки, очень опытному архитектору, Петру. Пётр был краток:

– Вы вот все много разных причин назвали, но самую главную упустили. Очевидно, что проект завалился только из-за одного: тестировщики нашли слишком много багов. Из-за них-то мы и не смогли в срок выпустить приложение.

Команда тестирования, не веря своим ушам, дружно стала возмущаться, но Пётр поднял руку, призывая всех к тишине.

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

Команда разработки была примерно в два раза больше команды тестирования. Они все дружно проголосовали вслед за Петром за названную им “проблему”. На этом ретроспектива была закончена. По её результатам причиной провала проекта считалось, что “тестировщики нашли слишком много ошибок”. Половина тестировщиков после такой ретроспективы пылала гневом, другая половина была, как в воду опущенная.

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



Раздел 5. Становление менеджера

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

Менеджмент: начало

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

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

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

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

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

Надо заметить, что “исполнительский” подход не хуже и не лучше “тимлидского”. Это скорее вопрос личных предпочтений человека. Конечно, компания тоже должна соответствовать этим предпочтениям. Разработчики, которые не хотят даже минимально лезть в менеджмент, выбирают компании, где процессы установлены, где роли строго распределены, и где накладки являются редкостью. В таких компаниях описанной проблемы с требованиями, скорее всего, не возникнет. А если она и возникнет, то от разработчика самодеятельности ждать не будут.

“Тимлиды” же нормально себя чувствуют в условиях лёгкого бардака и готовы менять процессы и меняться самим. Они оседают в стартапах и других проектах, где ценят их готовность обсуждать и решать проблемы там, где они обнаружились.

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

Разработчик может не интересоваться изменением процессов, но ему может быть интересно что-то другое из арсенала менеджерских умений. Возможно, ему интересно общаться с заказчиком и разбираться в нуждах бизнеса. Тогда он и будет этим заниматься. Или он чутко реагирует, когда кто-то рядом расстроен, и умеет (или хочет научиться) это исправлять. Тогда он будет прокачивать свой эмоциональный интеллект.

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

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



История про менеджмент не в IT

Мне очень нравится  смотреть на то, что происходит не в IT. Некоторые проблемы там выглядят совсем по-другому и решаются оригинально. Очень полезно перенимать такой опыт. Я хочу поделиться одним примером моих наблюдений.

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

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

Никакой специальной должности Аня не имела, она была просто преподавателем. Но ей удалось убедить руководство кружка, что нужно вложиться в маркетинг. Бюджета на рекламу всё равно не было, но Ане разрешили рекламировать кружок, как она считает нужным. Этого согласия оказалось достаточно. Аня нашла возможность привлечь студентов из шефствующего ВУЗа, уговорила знакомых помочь ей с разработкой материалов, сама проводила многочисленные мероприятия, разработала сайт, развила деятельность в соцсетях. Фактически она выполняла менеджерские функции, хотя формально она была рядовым преподавателем. Она определяла лицо кружка и руководила маркетинговой работой.

Вывод 1: Менеджеру не нужны ни должность, ни дополнительная зарплата, ни даже особые ресурсы. Менеджер делает свою работу, потому что она ему нравится.

Чего удалось добиться Ане? За несколько лет кружок вырос в 10(!) раз. Далеко не все желающие могли поступить на обучение, появился конкурс. Аня помогала привлечь хороших преподавателей и перспективных учеников. Конкурентов у этого кружка в городе не осталось. Из явных аутсайдеров кружок стал абсолютным лидером. Коммерческий успех был несомненным.

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

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

Что это прежнее руководство начало делать в первую очередь? Сокращать количество учащихся. Причём они не просто повысили сумму за обучение, чтобы сохранить прибыль. Они стали делать условия оплаты более трудными для родителей, объявляли непонятные условия обучения, делали хуже условия для преподавателей. Устно обоснование было простым: “У нас очередь на обучение, так что если кто-то не хочет у нас учиться, то только лучше станет”.

Мне казалось, что руководство просто проф.непригодно. Так планомерно разрушать созданное другими могут только ужасно недальновидные люди, ведь так? Но когда я поузнавал получше, выяснилось, что зарплата у руководства не зависит от числа учащихся и от величины прибыли. То есть обучать 300 человек им нисколько не выгодней, чем обучать 30. Но ведь работы объективно больше!

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

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

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



Первое задание менеджера

Хотя менеджер – это скорее состояние души, чем роль или, тем более, должность, но формальное присвоение должности “менеджер” всё-таки важно. Официально признанный менеджер имеет доступ к дополнительным ресурсам. Очень часто бывает так, что разработчик очень быстро вырастает до тимлида и проявляет задатки будущего менеджера проектов, и сам он не против стать менеджером, но всё как-то не срастается. Так вот первое задание такого начинающего менеджера – это добиться менеджерской позиции!

Для начала давайте рассмотрим, почему возникает такая “заминка” в карьере:

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

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

Шаг от тимлида к менеджеру значительный. Гораздо более значительный, чем рост от Middle до Senior разработчика, например. Если тимлидом разработчик может стать очень плавно и безболезненно, то шаг к менеджеру означает смену экспертизы и требует очень много усилий от самого тимлида да и от других людей тоже.

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

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

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

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

Чтобы преодолеть эту психологическую пропасть, тимлид должен быть очень мотивирован. Он должен очень-очень хотеть стать менеджером, чтобы побороть все сложности, о которых он даже и не знает. Но если он так мотивирован, то почему он не становится менеджером? Задача не такая сложная и для менеджера обычная. Ему придётся на своём проекте постоянно устанавливать свою позицию относительно команды и заказчика. Почему он не может установить свою позицию в компании? Видимо, не так уж хочет. А раз не так уж и хочет, то не сможет вынести напряжения менеджерской роли.

Это, кстати, менеджерский взгляд на вещи, к которому тимлиду надо как-то прийти.

Менеджеру нет выгоды делать менеджера из тимлида, ему это, скорее, приносит проблемы. Вот, кстати, хороший тест на “менеджерской мышление”. Большинство разработчиков, прочитав начало этого пункта сформулируют в голове какую-то такую мысль: “Ага, значит мой менеджер – это мой враг! Он будет мне мешать! Как только я захочу стать менеджером, он меня возненавидит!” Эта мысль неправильная. Менеджеру гораздо сильнее надо разделять эмоции и работу, чем разработчику.

Этот пункт не означает, что менеджер плохо относится к тимлиду, который рвётся в менеджмент. Менеджер может очень сильно помогать такому тимлиду. Но буквально плюсов самому менеджеру нет, так как на его проекте положительно это не скажется. А вот негативно скажется наверняка, так как тимлид с него уйдёт.

И, как я указал в первом пункте, к менеджеру этот рост отношения не имеет. Ожидать, что ваш менеджер проекта полностью сделает из вас менеджера – это так же, как ожидать, что он на вашей даче грядки будет поливать. Он может вас любить и уважать, но причём тут он? У него есть куча работы и обязательств перед командой, компанией и заказчиком. Менеджер может только помочь знаниями и советом. Сами справляйтесь.

Вашей компании (или подразделению) может быть не выгодным рост тимлида. Опять же никаких эмоций, просто бизнес. У компании может не быть работы для ещё одного (ещё и неопытного) менеджера. Или уход тимлида может нанести такой удар по текущим проектам, что компания не захочет рисковать.

Что делать компании в такой ситуации? Если просто сказать человеку: “Ты вряд ли станешь у нас менеджером,” то тимлид начнёт подыскивать новое место работы. Поэтому формулируется гораздо более обтекаемо: “Пока возможности нет, но мы работаем над этим. Как только появится вариант, мы тебя сделаем менеджером”. Тимлиду может казаться, что вся компания в дружном порыве работает над его карьерой. Но вряд ли всё так радужно. Вполне возможен вариант, что об этом желании тимлида помнят и просто ждут (и то не особо), когда ситуация поменяется.

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

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

В общем, начинающему менеджеру пора как-то брать ситуацию в свои руки и действовать активно. Потому что это именно то, чего от него ждут на менеджерской позиции.

Я сам в своё время потратил очень много времени и сил на то, чтобы перевести свою карьеру на рельсы менеджмента. Пришлось иметь дело и с противодействием руководства, и с неприятными подковёрными играми, и с объективными обстоятельствами. Ну и кто мне виноват? Я же сам двигался к тому, о чём мечтал. Зато в процессе я получил бесценный опыт переговоров, который мне пригодился сразу же, как только я добился, чего хотел.



История про чужие решения

Как-то беседовал со знакомым, недавним студентом. Его зовут Андрей, он очень умный парень, делает карьеру в IT и ему нужны были мои советы по разным вопросам. В частности он рассказывал, что его девушка хочет переехать в Москву, и он, конечно, переедет с ней, хотя и сомневается в том, что оно того стоит, но девушка очень хочет переехать, и её не переубедить. Так что они переезжают, это 100%. Мы обсудили особенности IT в столице. И тут он попросил карьерного совета:

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

– Андрей, главный совет для тебя, это научись принимать решения. Для менеджера это очень важно. Например, ты мне рассказывал про ваш переезд в Москву, но так, будто это за тебя решили, а не ты согласился.

– Но ведь это  не моё решение! Это моя девушка хочет, а я не уверен.

– Но ведь ты точно переезжаешь?

– Да, уже билеты куплены.

– Значит, ты принял решение.

– Ну… я бы так не сказал…

А я вспомнил про одного своего друга, Михаила, который, когда его уговаривали пойти пива попить или задержаться в гостях дольше запланированного, отвечал: “Друзья, зачем вы меня уговариваете? Я же подкаблучник. Я давно принял решение делать всё так, как жена сказала. Она сказала мне вернуться к десяти и я вернусь. Да, я могу сейчас задержаться, но это сиюминутная выгода. В более долгой перспективе мой подход самый правильный”. Так вот, хотя все решения как бы не его, а его жены, но Михаил – это человек-кремень. Если он сказал, что придёт, то он придёт. Если сказал, что его не будет, то всё, дело решённое. Даже то, что жена решает все вопросы, он формулировал как своё собственное решение. Да это и были его решения, раз он им следовал.

Возможно, вы слышали оправдания разработчика, когда ему указывали на его кривые коммиты на его старом проекте: “Да это не я такой! Там все так писали, хотя я был против! Тимлид коммиты откатывал, если в них хотя бы пары багов сразу не было! Заказчик требовал, чтобы билд всегда сломан был! Я хотел нормально писать, но мне не давали! Да я даже лучше код делал, чем он был, только это незаметно на общем уровне”. Все эти оправдания разной степени правдоподобности не имеют никакого значения. Разработчик отвечает за код, с которым он работает.

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



Менеджер или Специалист

У начинающих менеджеров часто возникают проблемы, для решения которых им очень хочется вернуться в роль специалиста (разработчика, тестировщика). Например, у меня было такое, когда из одного из моих трёх проектов уволился программист. Я от безысходности (как мне казалось) стал его заменять, чтобы не останавливать проект. В результате я и программировал, и руководил проектами, и это было очень тяжело. Знаю много примеров, когда менеджеры поступали так же.

В конце концов ведь от менеджера требуют выполнения проектов. А что ему для этого надо делать, неважно. Если ему нужно самому писать код, то пусть пишет. Так ведь? Не совсем.

Для начала я хочу обратить внимание на то, что такие дилеммы возникают только у начинающих менеджеров. Почему? Потому что более опытный менеджер всё равно не сможет работать как специалист на своих проектах. Когда я развился как менеджер, то я никак не мог заменить ушедшего разработчика. Потому что у меня в подчинении была сотня человек и несколько проектов. Я не мог выделить даже полчаса, чтобы написать какой-то код. Плюс проекты были на технологиях, в которых я не специализировался. Тратить моё время на разработку было бы неразумно и неэффективно.

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

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



Кейс "Менеджер-программист"

История от моего читателя Алексея, который любезно поделился своим опытом, за что ему большое спасибо. Пересказываю её тут своими словами:

Алексей был опытным разработчиком (Java/Scala developer/Data Engineer с опытом в C++), но его поставили на проект с абсолютно незнакомыми ему технологиями (web + Python + Front End). Причём времени на “раскачку” ему не дали, и ему сразу пришлось принимать важные технические решения, вроде выбора технологического стека для проекта и решения проблем с производительностью. Из-за этого Алексей иногда делал задачи дольше, чем мог бы, а его оценки были неточными.

Алексей старался закрыть пробелы в своих знаниях курсами, статьями и видео, но у него недавно родился ребёнок, и поэтому вне работы свободного времени было немного.

И вот в этом контексте и развернулась интересная история. Алексей работал над сложной задачей и потратил на неё 2 недели, но решение работало медленно. Главная сложность была в проблеме с производительностью использованного фреймворка в конкретном случае. Проблема была известной и общего решения не имела. Но хотя бы функционал работал.

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

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

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

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

Алексей ушёл думать. Он решил докопаться до сути и погрузился в исследование решения Игоря. Почему оно проще и быстрее? Вскоре Алексей выяснил, что менеджер вместо работы с базой использовал заранее приготовленные файлики JSON с нужными данными и показывал только первые 1000 записей. Поэтому и производительность была нормальной. Когда эти хаки убрали, решение менеджера стало тормозить так же.

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

На этом история не закончилась. После этого менеджер оспаривал любую оценку Алексея, заявляя, что всё должно быть проще и быстрее. Менеджер просил других разработчиков сказать свою оценку, чтобы проверить оценку Алексея. Иногда это были даже разработчики из других проектов. Все они, кстати, подтверждали оценки Алексея, но это не помогало.

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


Анализ

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

Самое интересный вопрос тут, это зачем менеджер полез в код? Он хотел ускорить работу разработчика? Зачем тогда он делал это втайне, и почему не взял ответственность на себя? Менеджер (а скорее тимлид) может перевести на себя какую-то задачу, если видит, что разработчик не сделает её. Но тогда нужно делать это полноценно, по процессу, доведя задачу до конца.

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

То есть вместо ускорения работы Алексея получилось значительное замедление. Причём, например, заставлять Алексея тратить время на убеждение команды и менеджера в правильности принятого решения было совсем излишне. В этом и суть распределения ответственности. Если разработчик принимает решение, то заставлять его аргументировать излишне. Это если решение должен принять менеджер, то ему нужны доказательства, информация и прочее.

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

Причём, здесь в высшей степени не важно, насколько хорошо Алексей сам подходил для решения задачи. Даже если действительно задача была простой “двухдневной”, а Алексей на неё тратил 2 недели из-за недостатка знаний. Ну и что? Менеджер может заменить разработчика или работать с тем, что есть. В конце концов, часто бывает, что тимлид работает с командой новичков. Там каждый(!) член его команды работает во много раз медленнее, чем он сам. Ну и что? Это нормально. Можно прокачивать свою команду, можно использовать их “как есть”. Но какой практический смысл в том, чтобы гнобить своих разработчиков? Это крайне непрофессионально.

Аналогичная картина видна и в продолжении истории. Какой смысл показывать недоверие всем оценкам? Зачем просить других членов команды подтверждать (или даже опровергать) оценки. Даже если есть какой-то Пётр, который может сделать какую-то задачу в два раза быстрее Алексея, то что из этого следует? “Я угадаю эту мелодию с трёх нот. – Угадывай!”

Смысл оценки в том, чтобы разработчик подписался на то, что он сделает задачу в срок. А то, что какой-то другой разработчик может сделать её в два-три-десять раз быстрее… Кому какая разница? Менеджер показывал своё недоверие Алексею, а значит и команде разработки в целом. Причём, команда подтверждала оценку Алексея, а менеджер выглядел совсем бледно.

Что делать в такой ситуации менеджеру? Прекратить показывать свои комплексы и неуверенность и начать управлять. Либо заменить разработчика, либо начать ему доверять, а не устраивать детский сад.

Что делать в такой ситуации Алексею? Я бы занял жёсткую позицию. Менеджер даёт свою реализацию задачи. Что он хочет, чтобы я с ней сделал? Изучил код? Это reverse engineering и пусть менеджер даёт согласие на эту трату времени. Либо пусть сидит и объясняет, как его код работает. Нужно принять решение по выбору кода, который идёт в прод? Отлично, решение принято, в прод идёт мой код. А, так нельзя, нужно сравнить решения? Тогда это исследовательская задача и пусть менеджер явно назначает такое задание, и принимает решение сам по результатам сравнения. При этом где-нибудь я бы эскалировал проблему менеджеру менеджера, так как явно он мешает работать.

А вот финал истории вполне закономерен. Менеджер потерял разработчика, причём не по своей инициативе. То есть и здесь у него всё пошло наперекосяк.



История про деньги заказчика

Услышал интересные рассуждения от опытного фрилансера:

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



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

Возможно, вам хочется написать мне какую-то историю из вашей жизни. Или, может быть, вы хотите мне написать, с чем вы не согласны. Или вам хочется, чтобы в следующей книге я написал о чём-то важном. Пожалуйста, напишите мне об этом на мою почту borisovke@gmail.com, мне будет приятно.

До новых встреч!

Примечания

1

 Во всех историях я постарался изменить обстоятельства и имена героев, чтобы не нарушать право людей на личную жизнь. Если вам кажется, что вы узнали себя или кого-то другого в какой-то из историй, то уверяю вас, вам только кажется. Если вы хотели бы поделиться какой-то своей историей (или задать вопрос), то вы можете связаться со мной через почту borisovke@gmail.com.

(обратно)

2

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

(обратно)

3

Fixed Price – модель работы, когда заказчик заранее договаривается о конкретной сумме за проект. Любые превышения бюджета идут за счёт компании-исполнителя. Этот термин используется в противоположность проектам Time&Material, когда заказчик оплачивает время работы разработчика на своём проекте, сколько бы этого времени не понадобилось.

(обратно)

4

Вот один из примеров, когда явление настолько редкое, что даже термина нормального устоявшегося нет. Часто менеджеры занимаются “делом”, а когда нужно мотивировать, выращивать специалистов, исправлять выгорание, разрешать конфликты и осуществлять прочую нетривиальную работу с людьми, зовут HR-специалистов, которые не могут ничем помочь, потому что недостаточно погружены в конкретную проблему. Члены команд опытных People Manager’ов характеризуют их как честных, справедливых, опытных или просто говорят “нормальный руководитель, приятно с ним работать”.

(обратно)

5

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

(обратно)

6

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

(обратно)

7

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

(обратно)

Оглавление

  • Про эту книгу
  • Про автора
  • Раздел 1. Общие вопросы менеджмента
  •   Особенности менеджмента в IT
  •   Почему проекты заканчиваются неудачей
  •   Водопадная модель разработки
  •   Виды проектного менеджмента
  •   История про ответственность
  •   Воздействия и результат
  •   История про неожиданные выводы
  • Раздел 2. Мотивация и командообразование
  •   Главное правило мотивации
  •   История про мотивирующие речи
  •   Доверять команде
  •   История про ненужные сложности
  •   Исправление ошибок
  •   Люди, приносящие плохие известия
  •   Кейс “Прикрыть товарища”
  •   Мотивация и жёсткость
  •   История про очередь на увольнение
  •   Не ругать свою команду
  •   “Не хочу, не буду!”
  •   История про способ уволиться
  •   Признание ошибок
  •   Добренький менеджер
  •   История про жажду критики
  • Раздел 3. Бабло
  •   Прибыль и затраты
  •   История про посреднический процент
  •   Зарплата и благосостояние
  •   История про увольнение из-за повышения зарплаты
  •   Премия разработчика
  •   История про увольнение из-за повышения зарплаты (часть 2)
  •   Кейс "Деньги за тестовое задание"
  •   История про деньги и оценивание
  •   Кейс "Увольнение классного спеца"
  •   Как демотивировать премией
  •   Кейс "Замена команды"
  • Раздел 4. Контроль выполнения проекта
  •   Куда ползёт scope
  •   История про самую распространенную причину провала проекта
  •   Так что же является новым скоупом?
  •   История про предугадывание желаний
  •   Секреты успешных Fixed Price проектов
  •   История про объединение оценок
  •   Почему Scrum не решает менеджерских задач
  •   Для чего нужен Scrum
  •   История про удовлетворённость клиентов
  •   Оценки задач
  •   Оценка субъективна
  •   Бесплатные буферы
  •   Цена бесплатных буферов
  •   История про проведение ретроспективы
  • Раздел 5. Становление менеджера
  •   Менеджмент: начало
  •   История про менеджмент не в IT
  •   Первое задание менеджера
  •   История про чужие решения
  •   Менеджер или Специалист
  •   Кейс "Менеджер-программист"
  •   История про деньги заказчика
  • *** Примечания ***