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

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

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

Проблема 1. Расстановка приоритетов

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

Увы, но задачи менеджмента гораздо важнее задач тестировщика, если вам приходится совмещать. Теперь вы ответственны за всех в команде, и откладывание управленческих задач чревато простоем других.

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

Проблема 2. Нехватка времени

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

Что делать? Закрепите или развейте проблему фактами. Мне помог дотошный трекинг времени всех выполненных задач.

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

Первое направление: неэффективное выполнение определённого типа задач.

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

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

Второе направление: задачи, которые каждый раз отодвигаются как неприоритетные, пока не начнут «подгорать».

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

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

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

Проблема 3. Отношение к мелким деталям

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

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

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

Проблема 4. Доверие к команде

Я понимала, что могу проверить лучше, найти баг быстрее. У меня был постоянный соблазн перепроверить.

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

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

Проблема 5. Ответственность за команду

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

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

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

Проблема 6. Внутренний перфекционизм

Нужно вовремя сказать «стоп» и отсеять то, что может подождать. Это может оценить только руководитель проекта, он в курсе всей финансовой стороны и отвечает за соответствие планам.

Что делать? Теперь всё нужно рассматривать через призму «время – деньги». Важно выпустить релиз вовремя. Иногда лучше обсудить проблему с заказчиком и совместно расставить приоритеты, нежели пытаться всё-всё-всё пофиксить.

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

Проблема 7. Претензии и пессимизм

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

Что делать? Не поддаваться панике, пресекать её безосновательное распространение на проекте. Сосредотачиваться на поисках решения. Спокойно относиться к недовольству и сохранять здравый рассудок. Меньше эмоций.

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

Мои выводы

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

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

• Мало исследовательских задач. Приобретённые технические навыки забываются и устаревают за ненадобностью.
• Отсутствие возможности набрать свою команду. Чаще всего руководители проектов работают с теми, кого им назначили на проект.
• Перейти на другой проект – сложно. Не нравится проект? Значит вы что-то делаете не так.
• Нет независимости от обязательного чтения мессенджеров/писем 24/7. Огромное количество коммуникаций, созвонов, встреч и писем.
• Сложно изолироваться от внезапных важных задач, которые требуют немедленного переключения.
• Нужно иметь стальные нервы, чтобы умело фильтровать поток проблем, поступающих с разных сторон.

Полезные навыки, которые удалось приобрести:

• Способность найти общий язык со всеми членами команды и заказчиками.
• Умение решать проблемы на проекте и прогнозировать их.
• Понимание и принятие причин управленческих решений.
• Осознание, как в целом построен процесс разработки проекта.

Но это всё только личный опыт и наблюдения. Не бойтесь пробовать новое.