Про ефективні багрепортах

Ти ставиш чайник на плиту, вмикаєш над нею підсвічування, щоб побачити, що смачненького в сусідній сковорідці приготував тобі чоловік, а світла-то і немає. Як ти йому про це скажеш?

«Дорогий, поміняй лампочку на кухні» або «Улюблений, там ця штука не світить»? У цей момент улюблений вникає в свіжу версію subversion, намагається зрозуміти як зробити merge двох репозиторіїв і йому твоя лампочка - до лампочки.

Як сказати йому про підсвічування? Точніше, давай так себе запитаємо: як йому сказати про підсвічування таким чином, щоб він почув, звернув увагу і однозначно зрозумів, в чому полягає проблема?

Це називається «баг репорт» (bug report), повідомлення про дефект. Це поняття прийшло з області розробки програмного забезпечення, але воно стосується людського спілкування в цілому. Не те щоб це було так важко й важливою частиною нашого життя, але для роботи корисно знати, як звертати увагу людей і колег на проблеми. Більш того, адже ми не ставимо собі за мету просто звернути увагу на проблему, на сам факт її існування. Нам важливо, щоб наш співрозмовник зрозумів, у чому саме її суть і щоб на тлі його свідомості відразу ж закрутився пошук рішення.

Нечіткий багрепорт ( «там ця штука не світить») все одно доведеться редукувати (уточнювати) до виразного. Але на це піде час і додаткові уточнення ( «яка штука? А чому ти вважаєш що вона повинна світити?»), Отримати які без нервів не вийде. А нерви треба берегти.

Програмісти, які звикли формулювати думки ясно (ладно-ладно, це комплімент), за довгі роки розвитку індустрії прийшли до простої формули, по якій можна повідомляти один одному про проблеми.

Формула вчиненого багрепорта

Формула вчиненого багрепорта складається з трьох простих пунктів:

Що зробила?
(Steps required to reproduce the problem)

Що отримала?
(Actual results)

Що очікувала отримати?
(Expected results)

Крім того, потрібно повідомити, де саме сталася проблема, за яких умов а також дати помилку назву.

«Дорогий, я включила світло над плитою, щоб подивитися, що смачного ти приготував, а він не горить. Ти не міг би подивитися, в чому там справа? »

Що зробила. Конкретна покрокова інструкція, що потрібно зробити для того, щоб відтворити дефект.

Що отримала. Що було отримано в результаті виконання цієї інструкції. Власне, дефект.

Що очікувала. Що повинно було, на думку репортера, вийти в результаті виконання цієї інструкції.

Умови. Те, що не є дією, але що важливо. Наприклад, для веб-додатків потрібно згадати броузер / ОС.

Назва. Це саме короткий опис проблеми або її частини, яке тільки можна сформулювати. Використовується для усного спілкування, для списків багрепортов і т.п.

Це - дуже корисна форма:

Вона прозора. Вона не дозволяє репортеру відхилитися в розповідний стиль або транслювати потік свідомості;
За нею складно написати щось, відмінне від багрепорта. Як наслідок, зменшується кількість інформаційного шуму в роботі;
Легко верифікувати. Тобто виконавши зазначені кроки, можна отримати такий же результат і підтвердити що дефект існує; або ж отримати інший результат і створити новий багрепорт; або ж отримати очікуваний результат і відхилити багрепорт;
В такому багрепорте чітко видно, валиден він, тобто чи дійсно дана ситуація є дефектом. Раптом так і треба, щоб лампочка над плитою не горіла, тому що її там зовсім не передбачено, а холостий вимикач з незрозумілих міркувань поставили загадкові китайці?
Така форма позбавляє від зайвої комунікації (донезмоги обридлих загальних уточнюючих питань);
Цій формі легко навчити нетямущих користувачів; Всього два-три дня істерик і ваші колеги навчаться чітко спілкуватися;
Повідомляючи вам в багрепорте, що саме очікував побачити користувач, він тим самим як би підтверджує, що він володіє системою і розуміє, як вона повинна працювати в даному випадку;
Такий багрепорт не мотивує відповідальна особа заткнути його в кут подалі і забути скоріше;

А тепер - слайди

Типова помилка, яку помітив користувач:

Не можу увійти в систему

Що очікував отримати:
1. Форму входу з діагностикою "неправильний пароль" або
2. Головну сторінку системи для користувача

умови:
MSIE 4.01 / Windows ME

Типова помилка, яку помітив системний адміністратор:

Що зробив:
Запустив /etc/init.d/exim4 restart на сервері lopata.something.com

Що отримав:
touch: `/ var / lib / exim4 ': directory not found

Що очікував:
exim перезапустився, стандартне повідомлення Ubuntu про успішне перезапуску сервісу

Типова помилка, яку помітив програміст:

Що зробив:
use dbPeerAccessor;
use DBI;

my $ dbh = DBI-> connect ( "dbi: mysql: telme", "telme", "telme");
my $ dbAccess = $ dbPeerAccessor-> new ($ dbh);

Що отримав:
$ DbAccess-> version () == undef

Що очікував:
$ DbAccess-> version () == "1.3.0";

умови:
trust: htdocs egor $ mysql -utelme -ptelme telme
Welcome to the MySQL monitor. Commands end with; or \ g.
Your MySQL connection id is 302
Server version: 5.0.51 Source distribution

Type 'help;' or '\ h' for help. Type '\ c' to clear the buffer.

До речі, такого роду багрепорти (за кодом) взагалі можна повідомляти в вигляді тестів (reduced test case), приблизно як ось тут, тільки у вигляді одного, цілого скрипта. наприклад:

use dbPeerAccessor;
use DBI;

my $ dbh = DBI-> connect ( "dbi: mysql: telme", "telme", "telme");
my $ dbAccess = $ dbPeerAccessor-> new ($ dbh);
printf ( "dbPeerInstance is% s \ n",
defined $ dbAccess-> version (). "Defined". "Undefined");

Типова помилка, яку помітив проектний менеджер:

"Забув пароль" має працювати інакше

Що отримав:
1. "Вам відправлений новий пароль"
2. Прийшов лист, в якому був згенерований новий пароль
3. Цей пароль дійсно працює, старий не працює

Що очікував:
Відповідно до наших user stories, листом повинен був прийти не новий пароль, а лінк на сторінку, на якій користувач може сам створити собі новий пароль

Типова помилка, яку помітив фінансовий директор:

Чому такі дорогі крісла?

Зверніть увагу - не обов'язково щоб текст багрепорта був написано саме за такою формою, але важливо, щоб там була потрібна інформація. Приклад програміста і останній приклад відмінно ілюструють, як можна написати хороший багрепорт з вичерпною інформацією, не вдаючись до «Що побачила?» І т.п.

No pain - no gain

Добре зафіксований пацієнт не потребує анестезії.

Є важливий момент, який необхідно враховувати при впровадженні ось такої форми багрепорта (а фактично - бізнес-процесу) в вашій команді. Справа в тому, що ніхто не вважає себе дурнем; навпаки, виявивши багу, користувач відразу відчує себе розумнішими творця системи. Навіть несвідомо. Тому, перебуваючи в контексті виявленого дефекту, користувач буде абсолютно комфортно і впевнено себе почувати, заповнюючи багрепорт виду «програма не працює, точка».

Тому впровадження суворої формальної форми багрепорта буде болючою для колективу. Причому якщо для IT-колективу ця біль переживається досить швидко, оскільки все - люди раціональні, то впровадження в віддаленому від IT колективі буде відчуватися досить. Багрепорт приносить прозорість в роботу, а прозорість вимагає певних зусиль. Та й не кожній людині в принципі під силу усвідомити, що таке «контекст» і чому співрозмовник його не розуміє, адже це ж так просто, програма не працює, ось дивись.

Мені доводилося впроваджувати цей «бізнес-процес» на підприємстві, де з користувачами спілкувалася тільки менеджер по роботі з клієнтами. Вона отримувала від користувачів зауваження і заповнювала по ним багрепорти. Як і всякий гуманітарій, вона мислила витонченими лініями і написати прямий і тупий багрепорт їй було дуже складно. Це були сльози, істерики і образи на мене, керівника підрозділу. Абсолютно щирі сльози! І хоч мені і було її шкода і зовсім не хотілося завдавати людині біль, проте, я відхиляв багрепорт за багрепортом, поки вона не навчилася писати цю нескладну форму. На це пішло близько трьох днів. Через ще пару днів вона вже на повному автоматі писала прекрасні багрепорти, а ще через тиждень вона зрозуміла цінність такого підходу і стала його прихильником. Продуктивність її роботи зросла, і проблеми клієнтів стали вирішуватися оперативніше.

У зв'язку з цим можу порекомендувати наступне. Впровадження такого підходу має відбуватися в компанії насильно. Воно повинно бути нав'язане керівником і лише тільки тоді, коли керівник сам особисто розуміє, навіщо це насильство потрібно і який вийгриш від цього отримає компанія.

Мене звуть Єгор Єгоров. Я - техдір і співвласник компанії Treebune.net, керівник проектів і програміст з 20+ роками досвіду, спеціаліст з систем масового обслуговування і журналіст за освітою. Детальніше.