Дипломатия или решаем проблемы грамотно

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

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

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

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

- А какие у них цели? - тихо, боясь задать глупый вопрос, сквозь зубы процедила девочка.

- Менеджер стремится сдать проект и получить свой бонус за своевременную сдачу. Архитекторы возводят прочный фундамент и каркас приложения, по необходимости добавляют в него базу данных, и верят, что это венец их творения, и что пока нельзя создать лучше. Программист же пишет красивый код, при этом, восхищаясь его красотой, он не всегда замечает недоработки. Вы же, в случае если ошибки просочатся через стену тестирования, всегда будете крайними. Таким образом, требуя исправления, вы защищаете себя, а значит вы отстаиваете качество продукта ценой собственной репутации, как QA специалистов. И тут уже Вы должны проявить себя хитроумными стратегами. Нужно правильно сказать программисту, что именно эта ошибка делает его код несовершенным и некрасивым, а менеджеру, что из-за нее он не только не получит бонус, но еще и оплатит неустойку за простои в работе клиента.

Вверх несмело поднялась рука, затем встал невысокого роста аккуратно причесанный "ботаник" и, поправив очки, несмело спросил:
- Учитель, а вдруг они нас не послушают и не захотят исправлять ошибку, вдруг они посмеются над нами. Что тогда делать?

- Эх, - вздохнул учитель, который тоже задавался такими вопросами вначале своего пути. - Может и не захотят, может и посмеются. Но! Смеется тот, кто смеется последним. У вас есть секретное оружие - система багтрекинга. Заносите туда описание ошибки, назначайте её на того, кого надо. Если программист вернул её Вам обратно, требуйте его написать комментарий, по какой причине он не хочет исправлять ошибку. Если вы все еще не согласны с тем, что проблему можно оставить, переназначьте её на менеджера, чтобы он принял окончательное решение. Но! Не забудьте обосновать почему, по-вашему, ошибка должна быть исправлена. Таким образом именно менеджер возьмет на себя всю ответственность за проблемы, связанные с той ошибкой.

- Учитель, на летней практике, у меня был случай, когда я был уверен, что нашел ошибку, но, как оказалось, о подобном сценарии ничего не говорилось в спецификации. Разработчик просто отклонил багрепорт с комментарием "Цэ не баг, цэ фiча". Я был расстроен, но поделать ничего не мог. Как быть в такой ситуации? - спросил "молодой боец" с гелевым ежиком на голове.

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

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

* * * * *

- На этом урок окончен. - Добавил учитель и, выдохнув, растворился в облаке горько-сладкого табачного дыма.