Если ваши документы никто не читает...

Если ваши документы никто не читает...

Когда я работал менеджером QA команды в одном проекте, меня, помню, ужасно раздражало то, как люди пишут заголовки для дефектов (они же bug summary, они же bug synopsis). Там, собственно, есть ровно одно правило: заголовок должен быть описательным. Чтобы, когда в поиске выдается список всех дефектов, ты мог по заголовку хотя бы в общих чертах понять, про что дефект.
А народ такое писал, такое. Естественно, был документ, где было написано как работать с дефектами. Естественно, его читал автор, я и еще пара человек. ©> А остальные 150 человек на него положили. Документ был большой, подробный, скучный. Ну, как водится.
Баги с ужасными заголовками появлялись каждый день и мозолили мне глаза. Надо было что-то делать.
Мне пришла в голову мысль. Я взял список всех багов за всю историю проекта, выбрал оттуда особенно выдающиеся случаи и написал примерно вот такое письмо (по причинам сохранения коммерческой тайны текст и номера изменены, но суть осталась прежней):.
Subject: Seven rules how to write bug summaries Hi everyone,.
From many people in our project I heard we had too many policies. But: what we didnt have yet was policy on writing really good bug.
summaries. Several evenings spent at home let me write this one. The policy first has been sent for approval to our management. They said it had to be announced to everyone. Here you go.
Thanks,.
Alex.
Rule #1: The summary must be brief #118: README.txt #149: ThrowException.
Rule #2: The summary must be clear. BKM: Write just "Shit happens"! #38: two tests do not run with JET #58: Error dialog.
#60: Menu->File->.
#127: fail in framework #134: incorrect severity #175: Test suite settings bug #189: Bug in system test #1434: BUILD CRASH #853: Make fails #4050: Build ailed #4051: Build Failed #3000: Sys build broken.
The winner:.
#5792: System crashes for not particular reason.
Rule #3: When it is not clear the summary must be intriguing.
#126: Strange heap #2154: Driver is a total mess #2515: Dialog dragging looks ugly #3545: Window dances wildly The winner: "window evolution".
#3113: window is bad.
#3114: inconvinient window.
#3115: window does not have all errors.
Rule #4: Two bugs are better than one bug! And three bugs:.
#703: DataUtilClass.nextContainer() works incorrectly with after ... #704: DataUtilClass.nextContainer() works incorrectly with after ... #705: DataUtilClass.nextContainer() works incorrectly with after ... #706: DataUtilClass.nextContainer() works incorrectly with after ... #716: ClassCastException exception at the URLQassLoader.getURL... #717: ClassCastException exception at the URLQassLoader.getURL... The winner:.
#5723: serialFieldID field missing #5724: serialFieldID field missing #5725: serialFieldID field missing #5726: serialFieldID field missing #5727: serialFieldID field missing.
#5728: serialFieldID field missing.
Rule #5: If you dont like equal summaries stretch your brain and be innovative!.
#771: BasicTreeConnection.
#772: BasicTreeConnection2.
#4688: Bad authors list.
#4690: Bad authors list.
#3526: Failed System Debug Scenario.
#3749: System Debug Scenario crashes.
The winner:.
#3140: System Help Scenario failed.
#3236: Failed System Help Scenario.
#3250: Failed System Help Scenario.
#3287: Failed system help sceanrio.
#3247: Failed System Help Scenario (faild on indexing).
#3437: Failed System Help Scenario on indexing (use Jitrino).
#3438: System Help Scenario failed on help indexing #4221: System Help indexing crashes.
Rule #6: Use several rules simultaneously (Rule #1 + Rule #4).
#248: JavaNet #480: JavaNet #627: Threading #1372: Threading.
Rule #7: Keep focus on everything!.
#418: Focus #1068: Focus request #1150: Focus on container #2034: Synthetic focus #2131: Focus on key press.
Это письмо про заголовки багов прочел, по-моему, каждый человек в проекте. Поскольку примеры были народу близки и понятны, то я получил десятка два писем с LOLами и благодарностями. Один менеджер предложил наградить авторов-чемпионов поучительным месседжем на ежегодной аттестации (менеджеру этого сделать не дали). Заголовки багов стали получше и раздражать меня стали меньше. В общем, новая политика создания заголовков сработала хорошо.
А все почему? Потому что написана была бодро, весело и про людей. © А теперь пара вопросов.
Вопрос №1. Какие нужные документы в вашем проекте народ не читает?.
Вопрос №2. Как их можно оформить в развлекательную упаковку?.
Если удастся что-нибудь такое сделать (или уже сделали), то не стесняйтесь поделиться с народом - составим список готовых рецептов для оживления рабочих документов. © Ну, над заголовками багов-то точно можно будет поржать. ©