Департамент QA: Ошибки управления

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

Когда я пришел в компанию, у меня был довольно большой опыт в ведении тестирования (как части QA) и разработки программ. Опыта управления процессом, в котором задействовано много людей и разные команды, практически не было. Фактически, на тот момент «картина мира» для меня выглядела так.

Мифическая организация разработки

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

В большой компании, выпускающей крупные продукты, с разделенными географически офисами (сюда можно включить оффшорные компании и местные (domestic) филиалы компании), эта схема разбивается вдребезги. Всё оказалось намного сложнее. Бизнес сторона не всегда может что-либо спланировать или четко сказать, что нужно сделать. Изолированность оффисов приводит к недостатку коммуникаций и не пониманию реальной ситуации и потребностей. А о технической документации вообще задумываются редко, особенно когда речь заходит о взаимодействии связанных, но разных частей системы (лучший пример клиент-серверная архитектура). А помимо пресловутого треугольника существует еще множество разнообразных служб и подразделений: Application Management, Системные администраторы, Backoffice, поддержка клиентов и пользователей и бог знает кто еще. И все, даже новенькая уборщица, имеют свой собственный взгляд на то, каким должен быть финальный продукт. Шутки шутками, но в реалиях действительно существует множество людей, прямо или косвенно использующих финальный продукт, имеющих разные взгляды на разработку и качество продукта. В результате всего этого, при отсутствии продуманного менеджмента, через некоторое время, возникает хаос. Часто, в этот момент владельцы или топ-менеджеры задумываются о тестировании и Quality Assurance.

В зависимости от мировоззрений руководства роль QA может сильно отличатся в разных компаниях. Соответственно и возможности менеджмента ограничены только этим. В любом случае, сначала придется работать в тех условиях, которые есть, с прицелом на то, чтобы получить больше возможностей для проведения улучшений, а для того чтобы это происходило легче нужно избегать ошибок в работе. Наиболее частные ошибки… ага, так очень любят писать, хотя откуда такие данные никому не известно. А мои ошибки были такие:

  • нерегулярное или несвоевременное оповещение руководства о проблемах и статусе тестирования в целом;
  • не совсем корректное и эмоциональное общение с членами процесса, которых я по каким-либо причинам считал профанами или бездельниками, но это противоречило мнению руководства;
  • слишком большой упор на скурпулезное документирование в разработке;
  • негибкость и непрозрачность процессов тестирования;
  • не всегда четкий план и сроки тестирования;
  • недостаточное количество метрик для оценки качества релизов;

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

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

3 Comments

  1. Alex, поправьте, пожалуйста, линк на иллюстрацию. Очень хочется узнать что вы имели ввиду)

    1. Поправил, но там ничего особенного, да и 4 года прошло, сейчас читаю – несколько наивно выглядит заметка, на самом то деле.

Leave a Reply

Your email address will not be published. Required fields are marked *