Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.
В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.
Проблема 1. Расстановка приоритетов
Плохая новость: в начале перехода старые задачи никуда не делись, появились ещё и новые обязанности. Задач много, все они важные. Возникало огромное желание клонировать себя, чтобы выполнять их одновременно.
Увы, но задачи менеджмента гораздо важнее задач тестировщика, если вам приходится совмещать. Теперь вы ответственны за всех в команде, и откладывание управленческих задач чревато простоем других.
Что делать? Мне помогало составление списка задач, опираясь на вопрос: «Если отложу эту задачу, как это повлияет на проект?», – и соблюдение полученного плана. Теперь главное — не баги, а задачи, сроки и бюджет проекта.
Проблема 2. Нехватка времени
Многие «переходящие в менеджмент» специалисты с этим сталкиваются. Времени на полноценное погружение в тестирование не остаётся. Тестирование либо откладывается на последний момент и тормозит разработку, либо страдает от некачественного исполнения. Оба варианта неприемлемы.
Что делать? Закрепите или развейте проблему фактами. Мне помог дотошный трекинг времени всех выполненных задач.
Проанализировав полученные результаты, я выявила два направления, над которыми нужно было поработать.
Первое направление: неэффективное выполнение определённого типа задач.
Например, у меня это были долгие переговоры с заказчиком и затянутые по времени митинги.
В таком случае нужно думать, как оптимизировать, экспериментировать. Пока не решите этот момент, нет смысла просить выделить ещё людей в помощь на проект.
Второе направление: задачи, которые каждый раз отодвигаются как неприоритетные, пока не начнут «подгорать».
В частности для меня, задач менеджмента становилось больше, так как команда росла. Задачи тестирования откладывались до последнего. Началась работа сверх нормы, чтобы успеть всё и везде. На меня отрицательно влияли систематические переработки. Я была неэффективна и особого энтузиазма не было.
Помогла расстановка приоритетов и трекинг времени. Не бойтесь консультироваться с руководством, правильно ли вы оцениваете важность задачи. Это нормально, так как у вас ещё мало опыта в менеджменте. Таким образом, вы покажете проблему изнутри.
Если начальство умеет слушать и ваши аргументы будут адекватными, то вам в помощь найдут специалиста. С прискорбием сообщаю очевидное: есть большая вероятность, что с вас снимут задачи тестировщика.
Проблема 3. Отношение к мелким деталям
По инерции я была в курсе всего на проекте. С одной стороны, хорошо всё понимать. С другой стороны, начинался перегруз информацией, и был большой риск упустить что-то важное.
Раньше я наизусть могла рассказать, в каком месте какая может возникнуть ошибка и как она обрабатывается. Теперь на выяснение этого просто не хватало времени. И я корила себя за то, что не в курсе всей информации по проекту.
Что делать? Понять, что за детали теперь несут ответственность другие члены команды. Задача руководителя – знать, у кого можно быстро получить информацию при необходимости.
Проблема 4. Доверие к команде
Я понимала, что могу проверить лучше, найти баг быстрее. У меня был постоянный соблазн перепроверить.
Что делать? Выдохнуть и дать команде самостоятельно заниматься задачами и решать возникающие проблемы, если время ещё есть. Задача руководителя – обеспечить комфортное выполнение задачи всем членам команды. Не надо мешать своей преждевременной помощью.
Я наблюдала за проектной деятельностью руководителей, которым повезло сразу начать свой путь с менеджмента. Они легко оперируют абстракциями, не пытаясь понять, что там внутри. Зато с помощью своих навыков тестирования, я выручала команду в кризисных ситуациях.
Проблема 5. Ответственность за команду
Что делать? Принимать всю ответственность на себя. Не винить кого-то конкретного. Учиться выражать обоснованное недовольство команде, когда это требуется. Транслировать претензии заказчика только в виде задач. Уметь защищать команду. Стараться понимать настроение в команде.
Я умела принимать ответственность на себя. Сложнее оказалось найти нужные слова, когда возникали проблемы. Надо хорошо разбираться в людях, чтобы неосторожным словом их не демотивировать. Это непросто сделать, ведь часто руководители проекта работают с теми людьми, которых им назначили на проект. К каждому нужен свой подход.
Кому-то из команды наверняка будет сложно перестроиться на то, что тестировщик стал руководителем, и нужно отчитываться перед ним. Увы, это исправит только время. Надо будет доказывать команде, что вы в состоянии принимать хорошие управленческие решения и можете контролировать процесс.
Проблема 6. Внутренний перфекционизм
Нужно вовремя сказать «стоп» и отсеять то, что может подождать. Это может оценить только руководитель проекта, он в курсе всей финансовой стороны и отвечает за соответствие планам.
Что делать? Теперь всё нужно рассматривать через призму «время – деньги». Важно выпустить релиз вовремя. Иногда лучше обсудить проблему с заказчиком и совместно расставить приоритеты, нежели пытаться всё-всё-всё пофиксить.
В этом кроется большая пропасть между руководителем проекта и отделом тестирования. Тестировщики обнаруживают проблему и испытывают радость, что они выполнили свой долг. Руководитель боится обнаружить проблему, так как это затянет срок выполнения задачи.
Проблема 7. Претензии и пессимизм
Невозможно избежать всех проблем. Они возникают как в команде, так и со стороны заказчиков. Когда в команде появлялся недовольный, то это быстро распространялось на других.
Что делать? Не поддаваться панике, пресекать её безосновательное распространение на проекте. Сосредотачиваться на поисках решения. Спокойно относиться к недовольству и сохранять здравый рассудок. Меньше эмоций.
Недовольство – это нормально, потому что все хотят улучшить проект. Только у безразличных нет претензий. Надо учиться с этим работать.
Мои выводы
В этом списке я обозначила те проблемы, с которыми сталкивалась сама при переходе из тестирования в менеджмент. Часть из них удалось преодолеть, по другим осознание пришло только после наблюдения за более опытными коллегами.
На должности руководителя проекта приходилось учиться жить с такими особенностями:
- Мало исследовательских задач. Приобретённые технические навыки забываются и устаревают за ненадобностью.
- Отсутствие возможности набрать свою команду. Чаще всего руководители проектов работают с теми, кого им назначили на проект.
- Перейти на другой проект – сложно. Не нравится проект? Значит вы что-то делаете не так.
- Нет независимости от обязательного чтения мессенджеров/писем 24/7. Огромное количество коммуникаций, созвонов, встреч и писем.
- Сложно изолироваться от внезапных важных задач, которые требуют немедленного переключения.
- Нужно иметь стальные нервы, чтобы умело фильтровать поток проблем, поступающих с разных сторон.
Полезные навыки, которые удалось приобрести:
- Способность найти общий язык со всеми членами команды и заказчиками.
- Умение решать проблемы на проекте и прогнозировать их.
- Понимание и принятие причин управленческих решений.
- Осознание, как в целом построен процесс разработки проекта.
Но это всё только личный опыт и наблюдения. Не бойтесь пробовать новое.
Комментарии (22)
dontspeaker Автор
09.12.2017 12:09terras Спасибо за вашу оперативную оценку меня как специалиста. Будет здорово, если вы также дадите определение такому термину, как тестирование.
lxsmkv
09.12.2017 16:14Тестировщик спит спокойно, когда все найденные баги исправленны, и пользователи пишут хорошие отзывы
Я думаю любой тестировщик, которому нравится его работа, всегда думает об багах которые он не обнаружил. И поэтому спит он не очень хорошо. А еще он плохо спит, если другие обнаруживают ошибки которые не смог найти он. Он думает, вот это простые люди, а нашли такое, а я профессионал, и не нашел. Мягко говоря, завышенной самооценкой тестировщики не страдают. Есть такие, кто ищут виноватых среди разработчиков, но я себе всегда говорю, ты не нашел — твоя недоработка, думай почему, и что улучшить.
По мне у тестирование и управление дополняют друг друга. Почему? Для управления приоритетами в разработке нужна информация о проблемных местах в продукте. Полезное (я намеренно не говорю слово «правильное») тестирование предоставляет эту информацию. Тестирование без стратегии, цели — будет менее эффективным. Руководитель настраивает тестирование на выполнение необходимых проекту задач. Он дает цели для реализации в продукте, а тестировщики проверяют насколько эти цели были достигнуты.
В конце один вопрос:
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач
dontspeaker расскажите как себя проявить. Как это было у Вас?
dontspeaker Автор
09.12.2017 19:08Недавно, услышала интересное мнение: "хороший тестировщик всегда сомневается". Я с ним полностью согласна, т.к. необходимо подвергать сомнению все. Даже свою выполненную работу. Но если на текущий момент все метрики в норме (например те, которые я привожу в статье), то не надо излишне терзать себя беспокойством. Не накручивайте себя и обязательно высыпайтесь. По этой теме рекомендую почитать книгу "Эмоциональный интеллект" Дэниела Гоулмана.
Со второй мыслью абсолютно согласна. Поэтому руководители очень ценят толковое тестирование.
Как проявить себя? Не бойтесь предлагать улучшения начальству или заказчику, если видите проблему и потенциальное решение. Выполняйте все, что обещали сделать на 200 процентов. Не стесняйтесь говорить о том, что вы готовы взять на себя дополнительные задачи и не забывайте предоставлять отчет о полученных результатах руководству. Общайтесь со всей командой по проекту, не будьте безразличны к чужим затыкам, помогайте по возможности.
lxsmkv
10.12.2017 16:26dontspeaker ну значит я все делаю правильно, может просто сейчас нет необходимости во мне как руководителе. С чего я взял, что вообще нужно к этому стремиться. Я же отказался получать сертификат по программированию, сказав что хочу быть хорошим тестировщиком, а не посредственным программистом. И судя по з/п мой труд высоко ценят и недавно неожиданно меня позвали в совет по обмену опытом как эксперта по тестированию. Но всегда хочется куда-то расти. Просто я нетерпеливый такой и ждать не умею :)
imxo2
09.12.2017 20:15Скажите пожалуйста, мне как новичку, люди добрые это нормально, назначать на руководителя проекта не Тимлида, не Сеньёра с большим опытом и образованием, а тестировщика? Не скажутся ли такие решения начальства на качестве продукции компании и работы команды?
dontspeaker Автор
09.12.2017 20:16+2Спасибо за комментарий.
К сожалению, сама формулировка вопроса содержит ошибочное мнение.
Не стоит исключать, что у тестировщика может быть большой опыт и хорошее образование.
Очень надеюсь, что вам со временем повезет поработать с такими специалистами.
Да, конечно, качество продукта может ухудшиться в том случае, если на замену не найдут такого же специалиста в тестировании.
Но, согласитесь, вряд ли человек, который раньше целиком отвечал за качество проекта, а теперь за сам проект, позволит забить на качество.
Умение работать с командой отдельная тема.
Тимлид обязан уметь работать с командой. Но со временем вы увидите, что сложно найти тимлидов, которые хотели бы перейти в управление проектами.
Сеньор разработчик это специалист, который хорошо прокачал свои технические навыки.
Но если вы помните, я писала выше в статье: хорошему управленцу не обязательно понимать все нутро проекта. Это даже может мешать команде.
Ну и не стоит забывать, что начальство не будет назначать любого тестировщика руководителем проекта, если не увидит в нем нужные качества.
lxsmkv
09.12.2017 21:59+2У нас есть сениоры которым волей судеб свалилось руководство командой и все прелести идущие в пакете — один, являясь отличным программистом, но не имея необходимого для ведения переговоров характера воспринял эту новую роль тяжело. Другой же сениор, которому досталось тимлидство по другой компоненте, по жизни общительный, незакомплексованный, оптимистичный человек, и для него звонить туда сюда, искать компромиссы никогда не составляло большого труда. И первый через год попросил избавить его от этой новой обязанности, а второй влился и нормально справляется. Зависит от предрасположенности к этому виду деятельности.
И что делает тестировщика подходящим кандидатом это то, что его знание требований к продукту практически на уровне разработчика (он только код может не пишет, но понимает как он устроен, ведь он при заведении бага указывает в какой компоненте проблема, напр. frontend, middleware, backend). Кроме того, тестировщика непонарошку заботит качество конечного продукта.
Получается, он знает, что должно получиться, он привык «заставлять» программистов делать так чтобы было как надо, он интуитивно понимает риски и правильно ставит приоритеты задач, он умеет общаться со всеми участниками команды — вот вам и качества лидера.
Конечно от конкретного человека зависит.
marshinov
10.12.2017 01:20Вы — большая умница и делаете правильные выводы. Советы в статье подойдут не только тестировщику, но любому исполнителю, волей судеб ставшему руководителем.
ClearAirTurbulence
10.12.2017 12:26Вроде бы все очевидно, но тем не менее, довольно интересно. Хорошо структурировано, видно тестера :)
Оффтоп: на КДПВ дверная ручка расположена неоптимально.lxsmkv
10.12.2017 14:49ClearAirTurbulence ваш «оффтоп» вполне по теме. Такое случается, что реализация может показаться нетипичной для нашего культурного опыта. В таком случае стоит свериться с документацией и требованиями. В данном случае мы имеем дело с другим этносом, где это является нормой. Изображение соответствует литературному описанию.
Fortop
10.12.2017 22:32Да безразличен этнос и литературное описание.
Чисто с точки зрения механики она стоит плохо
lxsmkv
11.12.2017 00:41Это да, но я про другое. Допустим, что у них асимметрия считается оскорбительной. Им пофигу на механику. Суждения тестировщика должны принимать такие моменты во внимание.
Такой репорт могут завернуть, даже если он помечен как «усовершенствование» и сказать, что «так надо». Получится ты зря потратишь время и свое и чужое. Это снижает эффективность бизнеса.
Философия тестирования на мой взгляд такова, что нужно освободить свое сознание от любого опыта, чтобы приблизиться к обьективности. У тестировщика нет ни хорошо, ни плохо, есть «соответствует требованиям», «не соответствует» и самый частый вариант: «я не знаю». Тестировщик это не инженер-рационализатор, не дизайнер, не программист. Он не знает как лучше и не должен знать, он должен наблюдать и выявлять несоответствия требованиям. Это кстати лучший известный мне способ жить в мире и согласии с разработчиками: «Не судить».
Расскажу коротенькую поучительную историю еще на этот счет.
На заре моей карьеры я нашел одну проблему в приложении, при определенных условиях оно начинало тормозить и переставало реагировать на ввод. Я написал в репорте что у приложения «фриз». Разработчик вскинулся и в порыве возмущения сказал: «Это не фриз, это задержка отрисовки, приложение в это время продолжает работать, так что просто лучше пиши что ты видишь, а не то что ты думаешь, что ты видишь.» С тех пор это мое золотое правило тестирования: «просто говори, что ты видишь».Fortop
13.12.2017 01:09Разработчик вскинулся и в порыве возмущения сказал
Это проблемы разработчика, а точнее постановки задачи product owner или project manager. Если с точки зрения бизнесзадачи тут должна быть отрисовка без «задержки», то должна быть именно она.
Если «бизнес» допускает временную остановку отрисовки (а на какой период?), то ок.
Mishootk
11.12.2017 11:00Тестировщик может заметить, что петли испытывают огромную нагрузку. Провисание и заклинивание люка обеспечено. Исторически так сложиться не могло. Это требование заказчика, которое приходится удовлетворять инженерам ломая голову. Я догадываюсь, что такой вход — это обеспечение legacy по отношению к ранее существующей системе типа «нора».
selotec
12.12.2017 08:24Хорошая статья. Сейчас прохожу через похожие этапы. Что-то кажется более менее пройденным, что-то в процессе. Пока что часто поддаюсь соблазну «сделай сам», потому что «людей мало», вместо того, чтобы заняться аудитом и оптимизацией работы. Порой хочется сделать что-то дома, внеурочно, но понимаю, что это может для технического спеца — круто, а мне нужно стремиться к другим вещам — перераспределить работу, дать таски ребятам по этой проблеме. Не бежать решать технические проблемы, в общем, а выстраивать процессы вокруг этих проблем такие, чтобы в команде был ресурс их решать. В общем, зон роста много, ваша статья позволила по ним свериться.
lxsmkv
12.12.2017 12:33selotec может поделитесь, как шли к этому? Чем занимается проект? Сколько в нем человек? На какой позиции начинали. На какой позиции теперь? Как выглядели процессы изначально, как вы смогли их улучшить?
Кто вам дал это сделать?
selotec
12.12.2017 13:02Начинал будучи стажером без опыта. Делал помимо технических задач (автотестов, ручного и т.д.) разные дела — и деплоить бэкенды доводилось, и факапы разгребать по качеству и по интеграциям общаться. Т.е. помимо технических задач имел разные зоны ответственности в проектах и команде в целом. Было дело — выстраивал процессы тестирования на новых проектах команды, ну и за релизы продуктов отвечал. В какой-то момент руководитель сказал, что я теперь сеньор.
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Exesium
13.12.2017 09:56+1Спасибо. Для меня, как бывшего тестировщика, обучающегося на данный момент на курсе MBA, статья выглядит очень жизненно и интересно.
- Отсутствие возможности набрать свою команду. Чаще всего руководители проектов работают с теми, кого им назначили на проект.
- Перейти на другой проект – сложно. Не нравится проект? Значит вы что-то делаете не так
Сделаю предположение, что это особенности именно вашей компании. Все же встречается и обратное
dontspeaker Автор
13.12.2017 10:05Спасибо за отзыв! Рада, что статья понравилась своей целевой аудитории.
Безусловно, встречается обратное, и вам повезло оказаться именно в такой компании.
Но судя по моему опыту работы в нескольких компаниях, а также опыту работы моих коллег, это скорее исключение, чем правило.
Terras
Главная задача тестировщика — тестирование. На этом моменте можно сразу сказать, что тестировщик из вас так себе.
Главная задача тестировщика — проверка соответствия качества конечного продукта (компонента продукта), требованиям спускаемых к этому продукту. Т.е. если продукт весь багнутый и дерьмовый, но продакт менеджер говорит требования, что так и должно быть — значит это и есть эталон качества.
terrakok
По вашим словам — это вы так себе тестировщик, и работаете по бумажке, а не для конечного пользователя. И в вашем подходе, вы всегда будете скидывать вину на начальника, без личной ответственности за проект.