Работаю тестером в небольшой компании. Однажды я наткнулся на такой текст:
...
Перекрестная компетентность вниз - это ситуация, когда человек является специалистом в одной сфере, достиг на этом поприще результата, а поэтому считает себя компетентным абсолютно во всех сферах, которые ставит ниже своей компетентности. Пример: когда руководитель считает, что если он руководит организацией, то он знает, как правильно построить работу какого-то отдела лучше руководителя отдела. (Иногда действительно так, но часто это перекрестная компетентность).
...
Перекрестная компетентность вверх - исполнитель может считать, что он является хорошим руководителем, и справился бы с руководством отдела или фирмы не хуже, а то и лучше нынешнего руководителя. Практика доказывает, что далеко не всегда хороший исполнитель становится успешным руководителем.
После прочтения меня не покидает мысль, что в моей жизни происходит что-то не то: либо я не понимаю специфики отрасли, либо у меня нескончаемая полоса "интересных проектов".
Мне кажется, что попадавшиеся на пути менеджеры проектов лезут во все дела, даже куда им и не надобно соваться. Я решил порассуждать, а собственно почему? И сделал вывод: потому что у обычных работников есть четко измеримый результат работы: написанные строки кода для исправления баги, оформленные отчеты по тестированию. А у менеджера: поговорил с заказчиком... принял важный звонок... посидел на собрании... так абстрактно, неосязаемо
Приведу примеры:
- Первый менеджер любил повозиться с фронтендом и продвигал свои решения на js вместо решений коллег
- Второй менеджер периодически (и безуспешно) возился с настройкой php-fpm и nginx для нужд проекта, имел доход с pet-project'а на ruby и сорил фразами "как сложно с
этими людьми, в отличие от программ. С ними все просто: true or false, а с этими..."
- Третий менеджер был бывшим тех. писателем. Он ревьюил документацию, подсказывал junior'ам как работать с БД, а также совмещал должность тестлида
- Сейчас я в другой конторе, новый менеджер... лезет
буквально во все, как Юлий Цезарь. Он "подсказывает" как тестировать, но со стороны идеи выглядят нелепо. Поменьше проверять валидацию вводимых значений, не уходить дальше основных сценариев (хорошо, это еще можно понять), оперировать только объективными критериями качества (извините, конечно, но если общеуважаемые эксперты тестирования вроде Баха, Болтона, Вайнберга заявляют о субъективности понятия качества для каждого отдельного лица, а тут...), автоматизировать проект как можно больше, чтобы тестировщики не обращали внимания на него в будущем (уже остапа понесло; а автотесты поддерживать кому? а то, что не покрыто ими?). Он может забрать повешенный на меня запрос, "проверить" (за пару минут), а потом от заказчика приходят жалобы. Половина того, что тестеры хотят завести - по его мнению, "не баг, а фича". Режет сроки для test lead на минимальные. Отпускает циничные шуточки по поводу заводимых багов, которые я бы счел приемлемыми максимум для анонимных комментариев на одном ресурсе с доменом .it Касательно разработки у него есть свои четкие представления, какие технологии true, а что не true. Оценка сроков, реалистичность внедрения, человеко-часы - не дело ли teamlead? Как оказалось, нет. Отдел UX-дизайна перегружен его видениями правильного дизайна, согласно статьям с Хабра. При этом в разработке наняты только backend, нет выделенных для frontend программистов. Люди, способные оптимизировать запросы к БД, разбирающиеся в тонкостях orm и настройки nginx, должны как малые дети копаться в js-лапше, на каждую правку делая по 2-3 других бага, за что тестерам прилетает по шапке потом.
В момент обучения в вузе у меня было понимание, что PM нужен для переговоров с заказчиками и для трансляции мыслей высшего руководства нам в виде, доступном для понимания простых смертных. Почему нельзя просто доверить эти дела руководителям отделов, а если они накосячат, то найти более компетентных лидов? У меня "перекрестная компетентность вверх" или описанное выше ненормально?
Простой
