Избегайте этих оправданий и у вас все будет хорошо

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

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

Если вы отвечаете на эти вопросы «да», то должны произойти следующие две вещи (в идеале, с соблюдением порядка):

1. Мы вместе с командой ищем способ решения проблем
2. Мы вместе с командой анализируем причины этих проблем, чтобы не допустить их повторения

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

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

Прости что опоздал, я тусил ночью

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

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

Но куда-то пойти и напиться, либо лечь настолько поздно, что вы проспите на 4 часа – это не чрезвычайная ситуация.

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

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

Но мы всегда так делали

Серьезно? Я говорю вам о том, что мы нашли ошибку в алгоритме, а вы говорите мне о том, что всегда так делали?

Честное слово, в какой-то момент карьеры эту фразу произносил и я сам.

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

Гораздо конструктивнее принять тот факт, что багрепорт правдив, и изучить его. Таким образом, возможно вы можете прийти к единому пониманию о том, что это не баг. Возможно были неправильно составлены тесты – тогда вы сможете вернуться к лиду, бросить багрепорт ему в лицо и крикнуть «Я же говорил, что это не ошибка!»

В таком случае у вас будут аргументы, а ваш ответ (каким бы громким он ни был) будет более конструктивен, чем «но мы всегда так делали!».

Это не моя вина

Если вас не обвиняют в том, чего вы явно не делали, говорить «это не моя вина!» (есть еще родственная фраза: «я этого не делал!») в случае возникновения каких либо проблем с проектом бесполезно для всех.

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

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

Мне скучно

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

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

И даже не задумывайтесь – и то, и другое – ошибка.

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

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

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

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

Научитесь делать скучные задачи интересными.

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

1. Проактивность
2. Самостоятельность
3. Страсть к изучению нового

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

«Это случайный баг»

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

Вы имеете хотя бы минимальное представление о том, как работают компьютеры? Ничто не происходит просто так, для всего есть причина. Баги – не исключение.

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

Разговоры о «случайных ошибках» только действуют мне на нервы. Этой фразой вы сообщаете мне две идеи:

1. Вас не волнует продукт
2. Вы согласны с тем, что ваши пользователи время от времени будут сталкиваться с этой ошибкой

Следует помнить, что для любой найденной ошибки ваш лид ожидает:

1. Что вы найдете решение, которое предотвратит ее повторное проявление;
2. Что вы примените Root Cause Analysis (RCA) для того, чтобы понять «почему эта ошибка вообще возникла»;
3. Что вы сможете гарантировать, что больше она не проявится. Этот пункт подразумевает сочетание RCA, хорошо задокументированного исправления и соответствующих тестов, которые четко покажут, что больше этот баг не проявляется (это могут быть юнит-тесты, интеграционные тесты или даже e2e-тесты)

Сказать «это случайный баг» – все равно, что забросить работу после начала первого шага.

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

1. Решить проблему
2. Понять почему она возникла
3. Убедиться, что больше она не возникнет

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

---

• Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
• В современном автомобиле строк кода больше чем…
• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• McKinsey: переосмысляем софт и архитектуру электроники в automotive