tестирование dot com

рый должен быть в курсе событий, знать состояние дел и

знать, кто за что отвечает, чтобы быстро и точно переадресо-

вать проблему тому, кто ее может решить.

Кстати, термин "проект" употребляется здесь (в разговоре о менед-

жерах проекта) в двух значениях:

• некая часть ПО, например, "Оплата". У Оплаты может быть свой

менеджер проекта, который на постоянной основе ведает всеми

делами, связанными с ней;

• новая инициатива, например, под названием "Обновление архи-

тектуры базы данных".

Хороший менеджер проекта — это благословение проекта, пло-

хой — его проклятие. Любимое развлечение плохих менеджеров

проекта — организация бесконечного числа бесконечных сове-

щаний с переливанием из пустого в порожнее.

Кстати, я однажды подсчитал, сколько денег компания тратила на ка-

ждое из совещаний по одному из проектов, — цифра была более чем

внушительная. Вот формула для консервативного подсчета стоимости

одного совещания, может быть, пригодится как-нибудь:

total cost of meeting =

= number of participants x median hourly rate x number of hours,

где total cost of meeting — сколько стоит компании одно совещание;

number of participants — число присутствующих на совещании; median

hourly rate — средняя заработная плата в час. Заработная плата каждого

— это вещь индивидуальная, но все равно можно прийти к некой условной

величине, исходя хотя бы из вашей собственной заработной платы; number of

hours — количество часов, которое длится совещание.

Я встречал PJ'MOB очень разных квалификаций и навыков в обще-

нии. Бывали даже случаи, когда я шел к своему менеджеру и про-

сил его дать мне другой проект, так как не хотел работать с неким

конкретным менеджером проекта.

В подавляющем большинстве случаев в стартапах обязанно-

сти менеджера проекта исполняют продюсеры.

244

Тестирование Дот Ком. Часть 3

Итак, обратно к "не нашему" ПО.

Во многих случаях наш веб-сайт так или иначе связан с ПО, ко-

торое принадлежит нашим бизнес-партнерам и ими же поддер-

живается в рабочем состоянии, например это ПО для процессинга

кредитных карт.

Так вот если найденный баг является багом в таком ПО, то тот,

кто исполняет обязанности менеджера проекта, набирает номер

ответственного лица на стороне наших бизнес-партнеров и коор-

динирует действия между нашей и не нашей стороной (например,

нашим и не нашим программистами) по разрешению проблемы.

Может, это и не баг вовсе, а недопонимание нами, как работает

не наше ПО.

Если же это баг, то наш партнер заносит запись о нем в собствен-

ную СТБ.

Далее.

Если это баг, то могут быть следующие варианты:

• баг имеет место быть на не нашей тест-машине, т.е. наша

тест-машина "разговаривает" с их тест-машиной и/или

• баг имеет место быть на не нашей машине для пользовате-

лей (мы выступаем в роли пользователей), т.е. наша машина

для пользователей "разговаривает" с их машиной для поль-

зователей.

В зависимости от того, где был найден баг в не нашем ПО и от

его важности для нас, а соответственно для нашего контрагента,

назначается приоритет, от которого зависит и скорость починки.

Всю координацию от "А" до "Я" с нашей стороны осуществляет

тот, кто исполняет обязанности менеджера проекта.

Итак, если мы можем повлиять на производителей не нашего ПО

и программист вернул вам баг с резолюцией 3rd party bug, вы в

Assigned to выбираете имя того, кто исполняет обязанности ме-

неджера проекта, и, сопровождая баг своими комментариями,

делаете его держателем бага. Он со своей стороны после выясне-

ния: "Кто виноват? Что делать? и Едят ли курицу руками?" —