Как совершить должностное преступление

Сижу в офисной кухне, ем еду.

«Жрум-хрум, жрум-хрум»…

Мимо в юго-западном направлении проходит молодой надежда киевского тестирования.

~ Привет, — говорит.

~ Спасибо! отвечаю.

~ А, приятного аппетита.

~ Привет! отзываюсь.

~ Гы! Умеешь ты запутывать! 🙂

~ А то! )))

Но если можно запутывать, то можно и распутывать. Выясняется, что с утра наш надежда киевского тестирования безнадежно застрял в сложной нравственной производственной проблеме: нашелся баг, но программист просит не сообщать о баге закащщику…

Дескать, баг есть, но его исправлять — это много времени нужно, а релиз на носу-с.

И мы его, милай, зарезолвим в лучшем виде, но после релиза.

А пока — не сообщай.

В общем, запутался он.

Что делать?

Если о баге не сообщить — вероятно, релиз выйдет спокойно и все будет хорошо.

~ Но при этом совершается должностное преступление, ты не сообщаешь информацию, для добывания которой тебя и пригласили в проект! — науськиваю я…

Если сообщить — вероятно, релиз релиз выйдет спокойно, но программисту придется неспокойно провести ряд вечеров или ночей в решении бага. И тады кирдык надежде киевского тестирования, бо будут гнобить.

И будут правы, согласно канонам действующей лагерно-пацанской морали общества.

Если не сообщить, но слабо рассчитывать на то, что баг будет исправлен…

~ А не факт, что будет исправлен, — подливаю я кипящего масла в душевную морозилку. — Его же не будут учитывать в плане работ…

Вооооот!

А если этот баг потом будет задевать другой функционал?

А если этот баг найдет закащщик? Баг был найден четко по тест-кейсу…

А если вдруг ВНЕЗАПНО что-то случится?

Надо сообщать о баге. Но программист… Боится он, что ли?

Ну…

Все равно ведь про баг узнают…

Вердикт: сообщить о баге закащщику должен сам программист (с поддержкой в виде тестировщика на фоне декораций).

Если сообщить с уточнением: «Фикс займет столько-то дней, и если его фиксить, то мы рискуем не успеть сдать объект к 22 апреля* …«, то весьма вероятно, что релиз могут выпустить с багом, но учитывая риски, и фикс таки случится.

* В позднее советское время строители сдавали в эксплуатацию всякие объекты социалистической стройки не по мере готовности, а к определенным датам календаря; после чего много лет фиксили недостатки уже «по-бумаге» сданных объектов.

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

Обед закончился.

По итогам:

  1. баг учтен;
  2. сделали небольшой релиз с учетом проблем;
  3. фиксы всей области, в которой был найден баг, были запланированы на следующий релиз, бо баг там был не один, как водится;
  4. выпустили, стали фиксить.

Щастье 🙂

9 ответов на “Как совершить должностное преступление”

  1. Мені розказували історію, коли на проекті були 2 багтрекери — один «білий» для замовника, а один «для себе». Тільки ті баги, які були поревювані менеджером і одобрені постались в «білий багтрекер»… Прямо як подвійна бухгалтерія 🙂
    Мотив менеджменту був один — показати що в нас «все гуд» :)))

    • Иногда это нормально.
      Если над проектом работает толпа народа, то неизбежны всякие дубли или просто порожняки. Тогда разумно всем кагалом пользовать внутренним багтрекером; затем специальная тётя просматривает все сообщенные баги и принимает решение о том, которые будут переведены в трекер клиента.
      А вот если «показать, что у нас все гуд» — тогда это безусловное петросянство.

  2. А можно выпустить релиз и приложить к нему known_bugs.txt , например =), предложив воркэраунд до появления исправляющего патча.. 🙂 Иногда, заказчики соглашаются на такое, ведь у них тоже сроки, мосты и фельетоны ))

    • А вот за такое следует ломать ноги и руки, если система выходит в общественное пользование 🙂
      Если система закрытого типа, то бывает допустимо.

  3. я бы не придумала лучшего решения данной проблемы)
    хуже — могу)
    лучше — увы, будут пострадавшие.)

  4. Алексей, вы скоры на расправу)..Ноги.. Руки.. переломать… Практика ведения known_bugs довольно распространена. Самое главное, чтобы в этом списке не было критичных ошибок. Но я, кажется, упоминал про воркэраунд =)
    Есть много разных способов организации релизной политики. Некоторые из них просто не допускают правок всего подряд, с некоторого момента.. Все зависит и от вендора ПО и от заказчика, а точнее от того «кто кому нужнее». Работал я как-то в одном отечественном «гиганте» производства биллинговых систем для операторов сотовой связи (название упоминать не буду =)..ну так у них политика была ну очень жесткой.. Правда и за баги , найденные уже на «замороженных» стадиях могли довольно сильно потрепать всю вертикаль власти в компании..Да и процесс был организован настолько тщательно, что такие явления были большой редкостью, а пресловутый known_bugs был тощим..

    • Я тут скор потому, что два раза натыкался на «Это же минорный баг!», тогда как я совсем не считал баг минорным и долго думал матерился.
      В остальном — все правильно, ситуации разные.

Добавить комментарий