Как хорошему разработчику не стать плохим менеджером - [36]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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