Как поменять минус на плюс, или Давайте сделаем это интересным
Недавно попался интересный менеджерский кейс. Ситуация такая: крупный аутсорсер, один из ключевых клиентов, большой и старый проект, основная масса работ — унылый багфиксинг. Все это приправлено постоянными стрессами — фиксы непростые и нужны на вчера. Продукт используется в продакшене и пользователи очень нервничают, когда находят баги.
Команда в унынии, люди активно смотрят по сторонам и примерно половина решительно настроена уходить. Адресат вопроса (терпила) — новый менеджер, которому досталась эта прелесть. Суть вопроса — что делать?
Мой первоначальный вариант был простой — нужно дать возможность ребятам найти наиболее проблемные места в системе, где появляется наибольшее количество ошибок и переделать их так, чтобы ошибок было меньше. Контраргумент — где найти на это время, если и так есть переработки и баги фиксить нужно. Мое мнение было такое, что если людей заинтересовать (а анализ узких мест и их переделка может быть весьма занимательной деятельностью), то время найдется. Действительно, ведь когда не хочется чего-то делать, то невольно откладываешь это до самого конца (или дальше — если есть возможность). А если дело интересное — то и делаться оно будет легко и быстро. И получается, что люди сначала будут быстро фиксить баги, чтобы перейти к анализу, а постепенно проблемные места подчистят и багов будут находить меньше.
Такой вот рецепт. На тот момент он казался мне весьма удачным. Но потом я подумал что на этом месте матерые манагеры небось начали ухмыляться. И у меня нарисовалось другое, более околонаучное что-ли, решение.
Итак, для начала можно попробовать понять в чем проблема. Как себе представляю себе я — все напряги появляются из-за того, что пользователи находят ошибки. Тогда сразу первый вопрос — а почему так? Вот если бы сделать, чтобы баги находились и исправлялись ДО заказчика? Таким образом можно понизить уровень стресса в команде — заказчик доволен, и беспокоиться нечего. Появляется решение — разобраться с разработчиками и QA, почему баги пропускаются и доходят до заказчиков.
Это уже похоже на решение проблемы. Однако можно пойти еще дальше.
Какой-то умный исследователь человеческого мозга сказал, что этот самый мозг склонен к однозадачности, и требует для полноценного переключения внимания на другую задачу до 15 минут. И если вам ВНЕЗАПНО сообщают, что есть новая бага и нужно стремительно ее начинать фиксить, то придется потратить какое-то время, чтобы на ней сфокусироваться. Кроме этого, может понадобиться воспроизвести ее окружение: достать нужную версию из VCS (при этом как-то сохранив код, над которым идет работа), может что-то пересобрать, приатачить отладчик, проклацать пару форм, повводить туда тестовые данные, и в итоге узнать, что точка прерывания стоит слишком поздно :)
Что делать? Надо как-то ловко сделать так, чтобы ошибки находились тогда, когда разработчик еще в контексте проблемы. То есть еще до того, как код получат тестировщики. И тут мы вспоминаем про такую штуку, как модульные тесты. Каким боком они нас спасут? Да очень просто (у менеджеров все всегда просто — достаточно вспомнить решение проблемы убитого негра афроамериканца в одноименном фильме «криминальное чтиво»).
Когда разработчик исправляет ошибку, он пишет на это дело модульный тест. И заодно покрывает тестами близлежащие участки. Нужно отметить, что покрытие тестами старого legacy кода — те еще веселуха. Это настоящий challenge, а какой разработчик не любит интересных задач?
Тестировщикам тоже стоит задуматься об автоматизации. Где не хватит своих сил — всегда можно попросить разработчиков помочь. Постепенно доля багфиксинга будет уменьшаться и в результате станет бесконечно малым :)
В общем, работа будет делаться хорошо, если она интересна исполнителям. Я уверен, что интересность можно найти во многих, часто неожиданных, местах. И задача менеджера — зажечь людей. Ну и смотреть, чтобы они не сгорели.
А у вас есть элемент неинтересности в работе?
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
Найкращі коментарі пропустити