Comments 29
Многие разработчики, которые это понимают, вместо споров с РМ'ами предпочитают прятать дефекты.
Я бы поставил под очень большое сомнение профессионализм разработчика, если бы он мне сказал подобное. Т.е. разработчик мало того, что не хочет исправлять баги, так еще умалчивает и «прячет» их — «знаешь, у меня код прямо напичкан багами, но ПМу я о них не скажу, а то премии лишит или будет думать что я багодел». Кстати я могу с легкостью прогнозировать что для того чтобы «спрятать» баг зачастую понадобятся трудозатраты, сравнимые с его честным исправлением (включая его создание и трекинг в SCM-системе). Если бы я узнал что кто-то в моей команде так поступает, я бы не доверил ему исправлить даже имя колонки в таблице. А то вдруг он предпочтет «спрятать» этот запрос за изменение и поменять вместо этого просто имя колонки в представлении в клиентском коде, чтобы лишний раз не напрягаться кодогенерацией, валидацией тестов затронутых объектов БД и т.д.
Всё не так просто, нежелания не обязательно осознанны (а чаще всего, как раз, наоборот).
Я где-то сталкивалась с интересным исследованием, которое, к сожалению, теперь не могу найти. В исследовании линейных руководителей попросили ввести регулярный учёт метрик эффективности работы их группы. Что-то около 80% участников этого исследования чуть-чуть «читерили» результатами, чтобы они выглядели лучше.
При этом, им заранее объяснили, что во-первых это исследование, во-вторых, метрики нужны, не чтоб показывать, а чтоб видеть и знать, что нужно улучшать.
Таким образом, потихоньку, подсознательно, человеческий фактор влияет на все аспекты командной работы :)
Пока не обсудить, не сделать «прозрачными» подсознательные опасения, люди продолжат «читерить». И задача руководителя во многом заключается именно в этом — в прояснении непонятных моментов, их кристаллизации. А чем строже босс (хотя он и добра желает!) — тем больше читерства.
Я где-то сталкивалась с интересным исследованием, которое, к сожалению, теперь не могу найти. В исследовании линейных руководителей попросили ввести регулярный учёт метрик эффективности работы их группы. Что-то около 80% участников этого исследования чуть-чуть «читерили» результатами, чтобы они выглядели лучше.
При этом, им заранее объяснили, что во-первых это исследование, во-вторых, метрики нужны, не чтоб показывать, а чтоб видеть и знать, что нужно улучшать.
Таким образом, потихоньку, подсознательно, человеческий фактор влияет на все аспекты командной работы :)
Пока не обсудить, не сделать «прозрачными» подсознательные опасения, люди продолжат «читерить». И задача руководителя во многом заключается именно в этом — в прояснении непонятных моментов, их кристаллизации. А чем строже босс (хотя он и добра желает!) — тем больше читерства.
Вы — хороший ПМ. От вас прятать баги не надо.
А бывает, к сожалению, наоборот. Когда путем такого вот сокрытия разработчики приоритезируют баги и фиксят то, что более актуально, а не то, что «внезапно выскочило». А всё новое и внезапное у начальства почему-то в приоритете «по-умолчанию». И надо срочно переключаться, терять контекст итд/итп.
В идеальном мире надо менять такое отношение начальства, да. Но столкнувшись с ситуацией надо её решать сейчас, а не в перспективе.
//у нас не всё так плохо, но иногда бывает :) и я с сожалением представляю, что у кого-то еще это может быть не «иногда», а постоянно.
А бывает, к сожалению, наоборот. Когда путем такого вот сокрытия разработчики приоритезируют баги и фиксят то, что более актуально, а не то, что «внезапно выскочило». А всё новое и внезапное у начальства почему-то в приоритете «по-умолчанию». И надо срочно переключаться, терять контекст итд/итп.
В идеальном мире надо менять такое отношение начальства, да. Но столкнувшись с ситуацией надо её решать сейчас, а не в перспективе.
//у нас не всё так плохо, но иногда бывает :) и я с сожалением представляю, что у кого-то еще это может быть не «иногда», а постоянно.
Да, часто бывает такое, что РМ не понимает базовые вещи. Вроде хочет как лучше, а получается совсем наоборот.
Я сталкивалась со следующей ситуацией: разработка долгосрочного проекта, «типа итерации» по 3 недели (без выдачи клиенту), условие выхода из итерации — фикс всех серьёзных багов, не вышли вовремя — лишили премии.
В итерации N нашли много дефектов в модуле, рефакторинг (почти переписывание с нуля!) которого запланировано на итерацию N+1. Начальство так и не поняло что ему объясняли, тестировщики и разработчики вместе спрятали баги, а в следующей итерации естественно довели модуль до ума.
Такое неадекватное начальство приводит к тому, что процесс становится ими вообще неконтролируемым.
Я сталкивалась со следующей ситуацией: разработка долгосрочного проекта, «типа итерации» по 3 недели (без выдачи клиенту), условие выхода из итерации — фикс всех серьёзных багов, не вышли вовремя — лишили премии.
В итерации N нашли много дефектов в модуле, рефакторинг (почти переписывание с нуля!) которого запланировано на итерацию N+1. Начальство так и не поняло что ему объясняли, тестировщики и разработчики вместе спрятали баги, а в следующей итерации естественно довели модуль до ума.
Такое неадекватное начальство приводит к тому, что процесс становится ими вообще неконтролируемым.
Некоторые разработчики расстраиваются наличию ошибок.
А разработчик который боится багов — это все равно что летчик, который боиться летать :))) В итоге он просто замкнется в своей скорлупе, будет боятся лишний раз применить смекалку при решении задачи, будет постоянно у всех спрашивать как «сделать правильно», вместо того, чтобы потратить некоторое время на изучение кода и самостоятельно ответить на свои собственные вопросы. Я несколько раз сталкивался с подобными людьми — производительность труда у них ну ооочень низкая. И багов они, в конечном счете, делают столько же и даже больше.
>>> Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным
то есть тестеры в свою очередь думают «зачем эти разработчики нужны??»
то есть тестеры в свою очередь думают «зачем эти разработчики нужны??»
:)
Багу нашли, однако!
Я имела в виду что тестировщики тоже далеко не всегда понимают свою миссию на проекте.
Багу нашли, однако!
Я имела в виду что тестировщики тоже далеко не всегда понимают свою миссию на проекте.
Я сейчас работаю тестером, хотя сам программист, причем очень широкой специализации (от embedded на чистом C до java и C#). Решил посмотреть на код с другой стороны. =)
Так вот сейчас у меня как раз ситуация, когда я не понимаю «зачем компании нужен этот разработчик». Он ведь явно не понимает, что делает.
Так вот сейчас у меня как раз ситуация, когда я не понимаю «зачем компании нужен этот разработчик». Он ведь явно не понимает, что делает.
— Вот за это я и не люблю кошек. — Ты просто не умеешь их готовить!
Разнаботчики не умеют тестировать, они обычно тестируют то где «могут» быть баги, тестировщики же тестируют все подряд, а не только места где «могут» быть баги и у них кпд значительно выше.
под словом «могут» я имел ввиду очевидные дыры: передача параметров, ввод данных итд
под словом «могут» я имел ввиду очевидные дыры: передача параметров, ввод данных итд
Да, у тестировщиков есть свои тайные знания о том, где ловить баги, а у разработчиков — о том, как устроен продукт.
Если смешать эти тайные знания воедино, получается наиболее эффективное тестирование :)
Если смешать эти тайные знания воедино, получается наиболее эффективное тестирование :)
Не, тестировщик не должен знать как устроен продукт. Это как если Вам сказать что на севере леса зарыт клад, вы на юге не будете копать =) Тестировщик должен сам находить ошибки, иначе есть шанс появления желания сюлить, и ограничиться проверкой только там где «могут» быть баги. Тестировщики ведь тоже люди, а идеальных ситуаций не бывает
Не совсем :)
Простой пример: у меня есть приложение Х, которое откуда-то куда-то копирует файлы, к примеру. Протестировать ВСЁ невозможно, поэтому тестировщики обычно начинают с выявления моментов «что влияет на работу продукта?». И тестировщик может вообще не знать, что, к примеру, в зависимости от файловой системы, используются разные методы записи данных. Тестировщику это НЕ очевидно — он и не будет проверять.
Почти все ошибки, которые находятся пользователями, теряются именно поэтому. Обычно со стороны это выглядит так: пользователь жалуется на багу, мы собираем информацию и говорим «не воспроизводится». Потому что не знаем о влиянии какого-то фактора, и в сборе информации он даже не участвует.
Но при этом, конечно, это НЕ значит, что разработчики должны помогать *сужать* информацию. Более того, мой опыт подсказывает, что багов больше всего именно там, где разработчики говорят «их быть не может». Не потому, что прячут, а потому, что могли что-то не учесть (вот прям вчера нашла такой дефект из серии «это не может не работать» :))
Простой пример: у меня есть приложение Х, которое откуда-то куда-то копирует файлы, к примеру. Протестировать ВСЁ невозможно, поэтому тестировщики обычно начинают с выявления моментов «что влияет на работу продукта?». И тестировщик может вообще не знать, что, к примеру, в зависимости от файловой системы, используются разные методы записи данных. Тестировщику это НЕ очевидно — он и не будет проверять.
Почти все ошибки, которые находятся пользователями, теряются именно поэтому. Обычно со стороны это выглядит так: пользователь жалуется на багу, мы собираем информацию и говорим «не воспроизводится». Потому что не знаем о влиянии какого-то фактора, и в сборе информации он даже не участвует.
Но при этом, конечно, это НЕ значит, что разработчики должны помогать *сужать* информацию. Более того, мой опыт подсказывает, что багов больше всего именно там, где разработчики говорят «их быть не может». Не потому, что прячут, а потому, что могли что-то не учесть (вот прям вчера нашла такой дефект из серии «это не может не работать» :))
«Почему такое происходит?»
Всё вобщем написано верно (и про уровень квалификации, и про то что введение неправильных KPI вредит ходу проекта). Но честно гововря это всё декорации, на фоне которых разворачивается главное действие и источник проблем:
1)Повсеместный нарцысизм/стремление к интеллектуальному эллитизму который выражается в высокомерно-пренебрежительно-снисходительном отношении между участниками проекта. Причём выражается это часто как вербально так и невербально.
2)Низкая квалификация и/или попустительство линейных руководителей. PM не проводит приватных бесед со своими «звездами», на тему того что мы все делаем общее дело, что нет разделения на «мы» и «они», что наша общая цель — не обосраться после релиза, а вовсе не соревнования кунг-фу по переписке между тестированием и разработкой.
Кому-то может показаться что это «детский сад», что у нас же работают опытные взрослые люди. Тем-не менее «неконструктивное поведение» присуще людям внезависимости от возраста и квалификации. Вербальные и невербальные проявления высокомерия и проч — вызывают в ответ только проявление агресси — что негативно сказывается на общей эффективности и результатах.
Всё вобщем написано верно (и про уровень квалификации, и про то что введение неправильных KPI вредит ходу проекта). Но честно гововря это всё декорации, на фоне которых разворачивается главное действие и источник проблем:
1)Повсеместный нарцысизм/стремление к интеллектуальному эллитизму который выражается в высокомерно-пренебрежительно-снисходительном отношении между участниками проекта. Причём выражается это часто как вербально так и невербально.
2)Низкая квалификация и/или попустительство линейных руководителей. PM не проводит приватных бесед со своими «звездами», на тему того что мы все делаем общее дело, что нет разделения на «мы» и «они», что наша общая цель — не обосраться после релиза, а вовсе не соревнования кунг-фу по переписке между тестированием и разработкой.
Кому-то может показаться что это «детский сад», что у нас же работают опытные взрослые люди. Тем-не менее «неконструктивное поведение» присуще людям внезависимости от возраста и квалификации. Вербальные и невербальные проявления высокомерия и проч — вызывают в ответ только проявление агресси — что негативно сказывается на общей эффективности и результатах.
Подписываюсь под каждой буквой, пробелом и даже запятой! :)
К сожалению, как только в компании появляются CMMI, ISO и прочие процессуальные «улучшаторы»,
На свет рождаются вредные, а порой даже нелепые KPI.
И, к сожалению, для Высшего менеджмента именно они становятся показателями «эффективности».
В таком случае, нужна слаженная работа, как непосредственного PM, так тестировщика и разработчика.
Порой, некоторые некритичные баги нужно придержать 3-8 дней, для сохранения красивых метрик.
Был случай, когда пришел четкий указ сверху: «На всех проектах по 3 блокера в неделю, а у вас за пол-месяца только один. Нужно срочно больше блокеров»
На свет рождаются вредные, а порой даже нелепые KPI.
И, к сожалению, для Высшего менеджмента именно они становятся показателями «эффективности».
В таком случае, нужна слаженная работа, как непосредственного PM, так тестировщика и разработчика.
Порой, некоторые некритичные баги нужно придержать 3-8 дней, для сохранения красивых метрик.
Был случай, когда пришел четкий указ сверху: «На всех проектах по 3 блокера в неделю, а у вас за пол-месяца только один. Нужно срочно больше блокеров»
Наталья, как мне кажется, говорила всё же о конфликтах разработки и тестирования.
Что же до ошибок верхнего менеджмента и конкретно приводимых вами примеров — да такое тоже бывает. Люди часто ошибаются) — но это уже совсем другая проблема.
Я не имею опыта в прохождении организацией сертификаций типа CMMI или ISO (Видимо подразумевается семейство ISO9000 которое окружает нас повсюду, либо какой-то из его родственников/потомков ) и имею, если честно, весьма поверхностное представление о них. Но насколько я помню/понимаю — там высказываются довольно общие идеи из серии «в организации должен быть отдел контроля качества, который занимается контролем качества. эффективность работы отдела определяется разработанными и утвержденными в организации метриками». Уверен, что там нет нислова про то что такими метриками качества работы обязательно является «количество ошибок вообще» и/или «количество блокеров».
Я уверен что, что прохождение сертификации не является причиной ошибочных решений.
Если верхнее руководство ошиблось и ввело метрики которые ухудшают качество работы — варианта 3:
1)Смириться и остаться
2)Смириться и в скором времени сменить работу
3)Начать диалог.
с вариантами 1 и 2 всё вобщем ясно (на всякий случай — «уйти» — не всегда является плохим решением)
А вот про 3ий вариант хочется сказать немного подробней. В нашей отрасли редко кто стремится к диалогу. Чаще бывает так что: верхнее начальство придумало очередную ерунду, и разработчики вместо того чтобы разобраться, сформулировать свою позицию и попытаться обсудить сложившуюся ситуацию — сразу «встают и уходят».
Нет — понятно если эта работа «так себе». Но если это место работы вам нравится — обязательно надо «поговорить».
В случае с навязыванием метрик которые вредят — попробуйте написать письмо. Там будут ваши предложения — ввести новые метрики. Мотивационная часть новых метрик. Сравнение предлагаемых метрик с уже введенными а в особенности — с ошибочными (важный момент — избегать даже намеков на то что «кто-то» ошибся введя неверные метрики. иначе защита, агрессия, диалогу конец). Поймите, что руководство компании обычно заинтересовано в том чтобы всё было хорошо значительно рядовых сотрудников. И если идея здравая и внесена правильно — её скорей всего поддержат (и с удовольствием выдадут за свою) )
вот как-то так.
Что же до ошибок верхнего менеджмента и конкретно приводимых вами примеров — да такое тоже бывает. Люди часто ошибаются) — но это уже совсем другая проблема.
Я не имею опыта в прохождении организацией сертификаций типа CMMI или ISO (Видимо подразумевается семейство ISO9000 которое окружает нас повсюду, либо какой-то из его родственников/потомков ) и имею, если честно, весьма поверхностное представление о них. Но насколько я помню/понимаю — там высказываются довольно общие идеи из серии «в организации должен быть отдел контроля качества, который занимается контролем качества. эффективность работы отдела определяется разработанными и утвержденными в организации метриками». Уверен, что там нет нислова про то что такими метриками качества работы обязательно является «количество ошибок вообще» и/или «количество блокеров».
Я уверен что, что прохождение сертификации не является причиной ошибочных решений.
Если верхнее руководство ошиблось и ввело метрики которые ухудшают качество работы — варианта 3:
1)Смириться и остаться
2)Смириться и в скором времени сменить работу
3)Начать диалог.
с вариантами 1 и 2 всё вобщем ясно (на всякий случай — «уйти» — не всегда является плохим решением)
А вот про 3ий вариант хочется сказать немного подробней. В нашей отрасли редко кто стремится к диалогу. Чаще бывает так что: верхнее начальство придумало очередную ерунду, и разработчики вместо того чтобы разобраться, сформулировать свою позицию и попытаться обсудить сложившуюся ситуацию — сразу «встают и уходят».
Нет — понятно если эта работа «так себе». Но если это место работы вам нравится — обязательно надо «поговорить».
В случае с навязыванием метрик которые вредят — попробуйте написать письмо. Там будут ваши предложения — ввести новые метрики. Мотивационная часть новых метрик. Сравнение предлагаемых метрик с уже введенными а в особенности — с ошибочными (важный момент — избегать даже намеков на то что «кто-то» ошибся введя неверные метрики. иначе защита, агрессия, диалогу конец). Поймите, что руководство компании обычно заинтересовано в том чтобы всё было хорошо значительно рядовых сотрудников. И если идея здравая и внесена правильно — её скорей всего поддержат (и с удовольствием выдадут за свою) )
вот как-то так.
Вроде элементарные вещи пишете, но абсолютно точные! Вот я никак не могу себя заставить тестировать продукт с первых дней разработки. А это ведь очень полезный метод! Не придется потом городить костыли и заплатки! Спасибо за статью! Будем стремиться к лучшему.
Эх, как же мне хочется поработать в компании, в которой есть тестировщики…
Зачем обязательно работать в компании, где есть тестировщики? В его роли выступать может кто угодно. Пусть это будет твой клиент. Вы отдаете клиенту продукт, а он его тестирует. Можно с проецировать все советы не на тестировщика, как работника, который занимается тем, что ищет баги, а на клиента, заказчика, конечного пользователя. Думаю, это будет вполне «легитимно».
UFO just landed and posted this here
UFO just landed and posted this here
Тестировщики не плохие — вы просто не умеете их готовить :)
Ждем пост «Почему тестировщики не любят разработчиков» =)
Sign up to leave a comment.
Разработчики не любят тестировщиков. Потому что не умеют их использовать