Согласен, контекст команды важен. Но не всякую локальную норму стоит автоматически считать здоровой. Если в команде рабочие результаты не фиксируются в общем контуре, а живут только в личных договоренностях, это уже не “гибкость”, а слабый процесс. И да, с такими правилами обычно всплывают и другие странности в управлении. В тексте я как раз писал и об этом: если проблему решают “гибко” и без нормальной фиксации, вполне может оказаться, что ее уже не раз решали раньше, причем каждый раз по-разному.
Нет, мысль не про отсутствие проверки. На тестовой среде исправление могли проверить. Проблема в том, что без фиксации в общем контуре оно может не попасть дальше: в сопровождение, в инструкции развертки, в релизный состав или просто в финальную версию. И как раз поэтому такая фиксация нужна еще и нам самим как страховка. Мы свою работу сделали: нашли проблему, донесли ее до разработчика, увидели исправление и приняли его. Но контроль того, что изменение дошло до продакшена, что о нем уведомили сопровождение и что учтены все сопутствующие действия, далеко не всегда находится в зоне ответственности тестировщика. Очень часто это уже задачи релиз-менеджмента и смежных ролей.
Скорее из серии: KPI полезны, пока ими не начинают мерить всё подряд. Но мой тезис был не про “чем больше багов, тем лучше”. Он про то, что на performance review и в других рабочих ситуациях намного проще показать свой вклад, когда результаты зафиксированы в системе и их можно нормально поднять по автору. Иначе вместо понятной истории по задачам и дефектам начинается сбор доказательств по чатам и скриншотам. Мы все-таки не в детектив играем.
Я как раз не писал, что дефект нужно заводить на каждый чих. Моя мысль была в другом: результат работы должен быть зафиксирован в рабочем контуре, а не оставаться только в личной переписке. Формат фиксации уже зависит от процесса команды: баг, таска, комментарий к задаче и так далее.
Спасибо, согласен с замечанием. Количество багов само по себе не говорит о качестве работы и легко превращается в вредную гонку за цифрой. Я хотел сказать о другом: если найденные проблемы не фиксируются в рабочем контуре то работа становится менее заметной и хуже отслеживается.
Спасибо, согласен. Без нормальной фиксации теряется не только учёт работы, но и возможность собрать связанные инциденты в одну проблему с общим решением.
Да, тут многое зависит от процесса в конкретной команде. Я не утверждаю, что на каждый чих нужен отдельный дефект. Речь скорее о том, что найденная проблема должна оставлять проверяемый след в рабочей системе: дефект, комментарий, возврат задачи, решение не чинить и тд..
Да, внутренние правила есть в любой компании. Мой посыл был не в том, чтобы спорить с процессами, а в том, что рабочий результат лучше фиксировать в системах, а не оставлять только в личных сообщениях.
Статья написана в рамках ХабраЧелленджа. Сам текст я писал самостоятельно, а дальше в рамках программы материал прорабатывался с ментором, через рабочую тетрадь и с редакторской поддержкой.
Согласен, контекст команды важен. Но не всякую локальную норму стоит автоматически считать здоровой. Если в команде рабочие результаты не фиксируются в общем контуре, а живут только в личных договоренностях, это уже не “гибкость”, а слабый процесс. И да, с такими правилами обычно всплывают и другие странности в управлении. В тексте я как раз писал и об этом: если проблему решают “гибко” и без нормальной фиксации, вполне может оказаться, что ее уже не раз решали раньше, причем каждый раз по-разному.
Нет, мысль не про отсутствие проверки. На тестовой среде исправление могли проверить. Проблема в том, что без фиксации в общем контуре оно может не попасть дальше: в сопровождение, в инструкции развертки, в релизный состав или просто в финальную версию. И как раз поэтому такая фиксация нужна еще и нам самим как страховка. Мы свою работу сделали: нашли проблему, донесли ее до разработчика, увидели исправление и приняли его. Но контроль того, что изменение дошло до продакшена, что о нем уведомили сопровождение и что учтены все сопутствующие действия, далеко не всегда находится в зоне ответственности тестировщика. Очень часто это уже задачи релиз-менеджмента и смежных ролей.
Скорее из серии: KPI полезны, пока ими не начинают мерить всё подряд. Но мой тезис был не про “чем больше багов, тем лучше”. Он про то, что на performance review и в других рабочих ситуациях намного проще показать свой вклад, когда результаты зафиксированы в системе и их можно нормально поднять по автору. Иначе вместо понятной истории по задачам и дефектам начинается сбор доказательств по чатам и скриншотам. Мы все-таки не в детектив играем.
Я как раз не писал, что дефект нужно заводить на каждый чих. Моя мысль была в другом: результат работы должен быть зафиксирован в рабочем контуре, а не оставаться только в личной переписке. Формат фиксации уже зависит от процесса команды: баг, таска, комментарий к задаче и так далее.
Спасибо, согласен с замечанием. Количество багов само по себе не говорит о качестве работы и легко превращается в вредную гонку за цифрой. Я хотел сказать о другом: если найденные проблемы не фиксируются в рабочем контуре то работа становится менее заметной и хуже отслеживается.
Спасибо, согласен. Без нормальной фиксации теряется не только учёт работы, но и возможность собрать связанные инциденты в одну проблему с общим решением.
Да, тут многое зависит от процесса в конкретной команде. Я не утверждаю, что на каждый чих нужен отдельный дефект. Речь скорее о том, что найденная проблема должна оставлять проверяемый след в рабочей системе: дефект, комментарий, возврат задачи, решение не чинить и тд..
Да, внутренние правила есть в любой компании. Мой посыл был не в том, чтобы спорить с процессами, а в том, что рабочий результат лучше фиксировать в системах, а не оставлять только в личных сообщениях.
Статья написана в рамках ХабраЧелленджа. Сам текст я писал самостоятельно, а дальше в рамках программы материал прорабатывался с ментором, через рабочую тетрадь и с редакторской поддержкой.
Почему стоит тег «искусственный интеллект»? Тут же нет с этим информации.
Здорово конечно что вы решили автоматизировать работу. Удивительно что все еще есть такие места где это не реализовано.