Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Многие разработчики, которые это понимают, вместо споров с РМ'ами предпочитают прятать дефекты.
Я бы поставил под очень большое сомнение профессионализм разработчика, если бы он мне сказал подобное. Т.е. разработчик мало того, что не хочет исправлять баги, так еще умалчивает и «прячет» их — «знаешь, у меня код прямо напичкан багами, но ПМу я о них не скажу, а то премии лишит или будет думать что я багодел». Кстати я могу с легкостью прогнозировать что для того чтобы «спрятать» баг зачастую понадобятся трудозатраты, сравнимые с его честным исправлением (включая его создание и трекинг в 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ий вариант хочется сказать немного подробней. В нашей отрасли редко кто стремится к диалогу. Чаще бывает так что: верхнее начальство придумало очередную ерунду, и разработчики вместо того чтобы разобраться, сформулировать свою позицию и попытаться обсудить сложившуюся ситуацию — сразу «встают и уходят».
Нет — понятно если эта работа «так себе». Но если это место работы вам нравится — обязательно надо «поговорить».
В случае с навязыванием метрик которые вредят — попробуйте написать письмо. Там будут ваши предложения — ввести новые метрики. Мотивационная часть новых метрик. Сравнение предлагаемых метрик с уже введенными а в особенности — с ошибочными (важный момент — избегать даже намеков на то что «кто-то» ошибся введя неверные метрики. иначе защита, агрессия, диалогу конец). Поймите, что руководство компании обычно заинтересовано в том чтобы всё было хорошо значительно рядовых сотрудников. И если идея здравая и внесена правильно — её скорей всего поддержат (и с удовольствием выдадут за свою) )
вот как-то так.
Вроде элементарные вещи пишете, но абсолютно точные! Вот я никак не могу себя заставить тестировать продукт с первых дней разработки. А это ведь очень полезный метод! Не придется потом городить костыли и заплатки! Спасибо за статью! Будем стремиться к лучшему.
Эх, как же мне хочется поработать в компании, в которой есть тестировщики…
Зачем обязательно работать в компании, где есть тестировщики? В его роли выступать может кто угодно. Пусть это будет твой клиент. Вы отдаете клиенту продукт, а он его тестирует. Можно с проецировать все советы не на тестировщика, как работника, который занимается тем, что ищет баги, а на клиента, заказчика, конечного пользователя. Думаю, это будет вполне «легитимно».
Тестировщики не плохие — вы просто не умеете их готовить :)
Ждем пост «Почему тестировщики не любят разработчиков» =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработчики не любят тестировщиков. Потому что не умеют их использовать