Як поміняти мінус на плюс, або Давайте зробимо це цікавим

Недавно попався цікавий менеджерський кейс. Ситуація така: великий аутсорсер, один з ключових клієнтів, великий і старий проект, основна маса робіт - сумний багфіксінг. Все це приправлено постійними стресами - фікси непрості і потрібні на вчора. Продукт використовується в продакшені і користувачі дуже нервують, коли знаходять баги.

Команда в зневірі, люди активно дивляться по сторонах і приблизно половина рішуче налаштована йти. Адресат питання (терпила) - новий менеджер, якому дісталася ця краса. Суть питання - що робити?

Мій початковий варіант був простий - потрібно дати можливість хлопцям знайти найбільш проблемні місця в системі, де з'являється найбільша кількість помилок і переробити їх так, щоб помилок було менше. Контраргумент - де знайти на це час, якщо і так є переробки та баги фіксують потрібно. Моя думка була така, що якщо людей зацікавити (а аналіз вузьких місць і їх переробка може бути вельми цікавою діяльністю), то час знайдеться. Дійсно, адже коли не хочеться чогось робити, то мимоволі відкладаєш це до самого кінця (або далі - якщо є можливість). А якщо справа цікава - то і робитися воно буде легко і швидко. І виходить, що люди спочатку будуть швидко фіксують баги, щоб перейти до аналізу, а поступово проблемні місця підчистять і багів будуть знаходити менше.

Такий ось рецепт. На той момент він здавався мені дуже вдалим. Але потім я подумав що на цьому місці досвідчені манагери мабуть почали посміхатися. І в мене намалювалось інше, більш навколонауковою что-ли, рішення.

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

Це вже схоже на вирішення проблеми. Однак можна піти ще далі.

Якийсь розумний дослідник людського мозку сказав, що цей самий мозок схильний до однозадачности, і вимагає для повноцінного перемикання уваги на іншу задачу до 15 хвилин. І якщо вам РАПТОМ повідомляють, що є нова бага і потрібно стрімко її починати фіксують, то доведеться витратити якийсь час, щоб на ній сфокусуватися. Крім цього, може знадобитися відтворити її оточення: дістати потрібну версію з VCS (при цьому якось зберігши код, над яким йде робота), може щось перезібрати, пріатачіть відладчик, проклацать пару форм, повводіть туди тестові дані, і в підсумку дізнатися, що точка переривання варто занадто пізно :)

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

Коли розробник виправляє помилку, він пише на цю справу модульний тест. І заодно покриває тестами прилеглі ділянки. Потрібно зазначити, що покриття тестами старого legacy коду - ті ще веселуха. Це справжній challenge, а який розробник не любить цікавих завдань?

тестувальникам теж варто задуматися про автоматизації. Де не вистачить своїх сил - завжди можна попросити розробників допомогти. Поступово частка багфіксінга буде зменшуватися і в результаті стане нескінченно малим :)

Загалом, робота буде робитися добре, якщо вона цікава виконавцям. Я впевнений, що цікавість можна знайти в багатьох, часто несподіваних, місцях. І завдання менеджера - запалити людей. Ну і дивитися, щоб вони не згоріли.

А у вас є елемент нецікаво в роботі?

Опубліковано: 02/02/12 @ 08:13
Розділ Різне

SEO Блог

Як поміняти мінус на плюс, або Давайте зробимо це цікавим

Рекомендуємо: