Очень часто можно услышать комментарии вроде «кг/ам» по поводу абсолютно любой вещи: начиная от винды и заканчивая автомобилями хонда.
Это нормально, что продукт нравится не всем. Относимся спокойно, с конструктивной критикой работаем.
Переживать надо, когда перестают пользоваться :)
вот ещё, что подумалось:
>>Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида).
Это сильно увеличивает цикл работы над одной ошибкой. Если мы не можем себе позволить ждать, пока менеджер пройдется по багам (раз в день или в конце итерации), то единственный выход — назначать баги напрямую. И тут по-любому возникнет «не на того назначил», «я просто забыл задеплоить, это не баг, перепроверьте». Такие ситуации не перерастают в конфликты только, если люди адекватные и отношения нормальные.
К примеру, у нас баг, найденный на продакшне, как правило, фиксится и выкатывается в тот же день. Это означает быстрый фикс и быстрое регрессионное тестирование. Тут нельзя работать через менеджера.
В то же время, я знаю системы, где запрос на хотфикс от поступления до попадания в следующий билд живет полгода.
В это примере разница в системах в том, что первой пользуются пользователи в интернете, а вторая — для корпоративного использования. я не знаю, всегда ли так, но в этих случаях это работает.
Вы же согласитесь, что здоровая «контра» подразумевает «Ну что, ребята, прочешем продукт вдоль и поперек, чтоб ему жарко стало», а не «щас я им багов наколбашу и домой уйду, а они пусть разбираются, если нормально кодить не могут».
Наоборот тоже: «Ого, молодцы, сколько всего понаходили» против «опять багов навалили, достало уже»
ещё дело в атмосфере
вы можете брать отличных людей, которые друг с другом хорошо общаются, но если в проекте атмосфера «сделать продукт, чтоб менеджер (заказчик) отвязался», ни к чему хорошему не приведет.
Кстати, такая больная атмосфера, в большинстве случаев, исходит от менеджера, который не дает команде понимания, что их работа значима, полезна и ценима
наболело то, что многие спрашивают, как быть в такой ситуации ( я часто по конференциям езжу, со многими общаюсь), а как помочь им не знаю, потому что мы всегда такие вещи предотвращали набором правильных людей и созданием правильной атмосферы, я вон выше писала.
если Вы про Иннову, то на сегодня мы не разрабатываем игры, а лишь паблишим. там совершенно про другое все.
>> Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…
О, как же ошибочно мнение мира разработки «человеческого софта» о геймдеве. Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Теперь про «человеческий софт». Наш отдел разработки делает продукты, которые к играм с точки зрения пользователя имеет отношение очень слабое. Например, биллинг. Сложная финансовая и юридическая часть к оркам и эльфам имеет отношение слабое, всего лишь айдишниками товаров. (бухгалтеров и юристов за сказочных существ не считаем :)). Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).
В моей прошлой компании — аутсорс «человеческого софта» — работали и в многолетних проектах. Не бухгалтерский пакет, конечно, но американская система подачи аппликейшнов в FDA тоже не очень весела, поверьте.
И не было там ни отфутболивания, ни презрения, ни высокомерия, ни «кто больше наделает». Были жесткие процессы, потому что объемы и повторяемость. Но были и люди.
>>Так что IMHO все же системный подход решает.
если Вы системным подходом решаете проблему, о которой я говорю, отлично!
>>резко агрессивных людей нельзя пускать в коллектив людей, работающих головой, есил они уж нужны компании, например гении, то пусть работают изолированно).
«не баг» — нормальная ситуация.
много «не баг» — ненормальная ситуация, у которой 2 причины:
1) это действительно не баги, тогда смотрим на тесты, на тестеров, на требования, в ту сторону вобщем
2) со второго раза программист признает, что это таки-баг. И если это тенденция, то это не здорово. Я об этом. Отфуболивание.
Оставим в покое архитектора. Я вполне понимаю, почему в этой конкретной компании такой специалист бы принес больше вреда, чем пользы. А разговор о сферическом архитектора не имеет смысла.
>> Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей.
Требовать постфактум нельзя, конечно. Но можно а) не брать таких, для которых это противно по природе, и б) создать и поддерживать такую атмосферу.
Про меньше денег никто не говорит. И про объем работы тоже. Речь о качестве. В которое входит и скорость. И о человеческом факторе. Который неминуем. Есть 2 пути им управлять:
— построить минимально человекозависимые процессы — это то, о чем Вы говорите
— держать баланс между жесткими процессами и человеческими отношениями — это то, о чем говорю я
Оба имеют право на жизнь. В обоих важно не запустить один раз и полагаться, что само выживет, а постоянно ревизировать, выявлять проблемы, оздаравливать.
Интересно посчитать, сколько тратится на поддержку в обоих случаях и какой реально эффективнее. У меня таких цифр нет, но я верю и работаю по второму. Это не означает отсутствие процессов. Это означает, что в момент принятия решения у человека больше свободы, но он адекватен по дефолту, и, следовательно, с высокой вероятность. выберет не один из предписанных, а третий, более эффективный путь.
В обоих вариантах, кстати, клиники, которую я описываю в посте, как проблемы не возникнет.
А если проблема существует (о чем свидетельствуют рассказы людей), значит не умеют ни процессы настроить, ни с людьми работать. И это плохо.
Я мыслю категориями бизнеса, только другого. Если этот продукт моя компания выпустит под своим именем, то ей критичен каждый вздох каждого члена команды. Гениальная архитектура не спасет продукт, если команда будет противостоять изменениям, которые требует рынок от продукта.
Про четкие инструкции — повторюсь: «Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.»
Конечно же, зависит от бизнеса компании, Вы правильно заметили. В аутсорсинге продается предсказуемость. В продуктах — решает лояльность и любовь к продукту.
Почему же не может? Может и нужет. Если это действительно нужно.
Просто бывает, когда нужно «тупо отработать бабки», тогда эффективность невыгодна. Страдает продукт, страдают люди. Страдают следующие хорошие продукты, в которые эти испорченные люди потом придут работать.
Мне рассказывали про программистов, которые прямо так и говорят на полном серьезе: «Я сегодня делал баги, пусть ищут».
Про заставить программистов тестировать — это вообще отдельная песня. Стереотип потому что, что занятие это второстепенное. Но в выпуске продукта второстепенных задач нет, Вы согласитесь, я уверена. Потому что Вы ответственность за свой продукт чувствуете.
нет, не у вас одного :)
но Вы даже не представляете, в скольких компаниях такие проблемы. Я часто по конференциям езжу и со многими людьми разговариваю. такого много. Меня такого рода ситуации ставят в тупик. В голове не укладывается, КАК можно считать работу твоего со-командника второстепенной и пытаться нивелировать её ценность. КАК можно сказать «это не баг», зная, что так и пойдет в продакшн, не исправленным.
Во всех командах, где мне доводилось работать, мы вместе с программистами разбирали баги, советовались о приоритетах тестирования и выборе областей наибольшего внимания. С нынешней командой мы совместно импрувим процесс работы, чтобы было удобнее и эффективнее работать.
А извилины менеджера по персоналу тут вряд ли помогут. Если они не сталкивались с такими проблемами, они не смогут идентифицировать их на собеседовании.
Такие конфликты нужно предотвращать, подбирая правильных людей в команду и создавая правильную атмосферу. Тогда отношения скорее станут доверительными и слаженными.
Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»
Это sofy skills, которые тоже очень важны при найме специалиста.
В моей прошлой компании приходилось набирать по 20 человек за месяц на новые проекты, сложно было смотреть ещё и на отношение человека к работе, потому что на рынке специалисты вообще дефицит. Но, тем не менее, отказывали потенциальным вирусам.
И исходить правильное отношение к работе и к коллегам должно от менеджера, в первую очередь. Если он, конечно, не координатор работ, а действительно человек, отвечающий за свой проект.
>> Немного некрасиво, но ничего страшного в этом нет. Это лишь личное мнение человека, который выполнил свою работу, а остальное его не волнует. Это нормально.
Вы знаете, это смотря что при этом подразумевает говорящий. Если это просто формулировка такая, типа как друзья между собой общаются: «Въехал вчера в зад джипу на перекрестке» — «Ну курица ты, что сказать», то конечно ничего страшного нет. Но если это всерьез говорится, то такие высказывания сбивают с толку неопытных тестеров, да и подход такой не способствует эффективной работе.
>> Cоответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика.
Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»
>>Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков.
то же самое, что и в предыдущем пункте
>>Тут все зависит от процесса тестирования.
Согласна. Но в гибком процессе эффективнее, чтобы тестировщики были в курсе дальнейшей судьбы дефектов.
Вообще, я Вам так скажу: это все имеет право на жизнь, если это не клиника. Но намного здоровее и продуктивнее работать с людьми заинтересованными в успехе своего дела. Да, это трудно обеспечить в жестком процессе, где шаг вправо не поощряется.
Если говорить о том, что "«нефиг заниматься не своим делом, за это не похвалят» — то тут у меня такое мнение: все, чему ты учишься, добавляет тебе стоимость (карму, если хотите). В этом проекте тебя считали выскочкой и шикали — в другой компании тебя с руками оторвут и денег дадут больше, и ответственности.
Такой момент: набирая себе людей (я руковожу отделом тестирования), я смотрю на то, в каких проектах им доводилось работать. Если в таких, как Вы описываете, то мне такие не нужны. Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.
Мой выбор такой, именно поэтому и атмосфера у меня в отделе такая, что ничего из описанного в посте нет.
Это нормально, что продукт нравится не всем. Относимся спокойно, с конструктивной критикой работаем.
Переживать надо, когда перестают пользоваться :)
>>Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида).
Это сильно увеличивает цикл работы над одной ошибкой. Если мы не можем себе позволить ждать, пока менеджер пройдется по багам (раз в день или в конце итерации), то единственный выход — назначать баги напрямую. И тут по-любому возникнет «не на того назначил», «я просто забыл задеплоить, это не баг, перепроверьте». Такие ситуации не перерастают в конфликты только, если люди адекватные и отношения нормальные.
К примеру, у нас баг, найденный на продакшне, как правило, фиксится и выкатывается в тот же день. Это означает быстрый фикс и быстрое регрессионное тестирование. Тут нельзя работать через менеджера.
В то же время, я знаю системы, где запрос на хотфикс от поступления до попадания в следующий билд живет полгода.
В это примере разница в системах в том, что первой пользуются пользователи в интернете, а вторая — для корпоративного использования. я не знаю, всегда ли так, но в этих случаях это работает.
Наоборот тоже: «Ого, молодцы, сколько всего понаходили» против «опять багов навалили, достало уже»
вы можете брать отличных людей, которые друг с другом хорошо общаются, но если в проекте атмосфера «сделать продукт, чтоб менеджер (заказчик) отвязался», ни к чему хорошему не приведет.
Кстати, такая больная атмосфера, в большинстве случаев, исходит от менеджера, который не дает команде понимания, что их работа значима, полезна и ценима
а ситуация, к сожалению, распространенная
>> Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…
О, как же ошибочно мнение мира разработки «человеческого софта» о геймдеве. Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Теперь про «человеческий софт». Наш отдел разработки делает продукты, которые к играм с точки зрения пользователя имеет отношение очень слабое. Например, биллинг. Сложная финансовая и юридическая часть к оркам и эльфам имеет отношение слабое, всего лишь айдишниками товаров. (бухгалтеров и юристов за сказочных существ не считаем :)). Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).
В моей прошлой компании — аутсорс «человеческого софта» — работали и в многолетних проектах. Не бухгалтерский пакет, конечно, но американская система подачи аппликейшнов в FDA тоже не очень весела, поверьте.
И не было там ни отфутболивания, ни презрения, ни высокомерия, ни «кто больше наделает». Были жесткие процессы, потому что объемы и повторяемость. Но были и люди.
>>Так что IMHO все же системный подход решает.
если Вы системным подходом решаете проблему, о которой я говорю, отлично!
>>резко агрессивных людей нельзя пускать в коллектив людей, работающих головой, есил они уж нужны компании, например гении, то пусть работают изолированно).
мы об одном и том же
много «не баг» — ненормальная ситуация, у которой 2 причины:
1) это действительно не баги, тогда смотрим на тесты, на тестеров, на требования, в ту сторону вобщем
2) со второго раза программист признает, что это таки-баг. И если это тенденция, то это не здорово. Я об этом. Отфуболивание.
>> Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей.
Требовать постфактум нельзя, конечно. Но можно а) не брать таких, для которых это противно по природе, и б) создать и поддерживать такую атмосферу.
Про меньше денег никто не говорит. И про объем работы тоже. Речь о качестве. В которое входит и скорость. И о человеческом факторе. Который неминуем. Есть 2 пути им управлять:
— построить минимально человекозависимые процессы — это то, о чем Вы говорите
— держать баланс между жесткими процессами и человеческими отношениями — это то, о чем говорю я
Оба имеют право на жизнь. В обоих важно не запустить один раз и полагаться, что само выживет, а постоянно ревизировать, выявлять проблемы, оздаравливать.
Интересно посчитать, сколько тратится на поддержку в обоих случаях и какой реально эффективнее. У меня таких цифр нет, но я верю и работаю по второму. Это не означает отсутствие процессов. Это означает, что в момент принятия решения у человека больше свободы, но он адекватен по дефолту, и, следовательно, с высокой вероятность. выберет не один из предписанных, а третий, более эффективный путь.
В обоих вариантах, кстати, клиники, которую я описываю в посте, как проблемы не возникнет.
А если проблема существует (о чем свидетельствуют рассказы людей), значит не умеют ни процессы настроить, ни с людьми работать. И это плохо.
всем вместе над этим нужно работать, в этом суть
Я мыслю категориями бизнеса, только другого. Если этот продукт моя компания выпустит под своим именем, то ей критичен каждый вздох каждого члена команды. Гениальная архитектура не спасет продукт, если команда будет противостоять изменениям, которые требует рынок от продукта.
Про четкие инструкции — повторюсь: «Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.»
Конечно же, зависит от бизнеса компании, Вы правильно заметили. В аутсорсинге продается предсказуемость. В продуктах — решает лояльность и любовь к продукту.
Просто бывает, когда нужно «тупо отработать бабки», тогда эффективность невыгодна. Страдает продукт, страдают люди. Страдают следующие хорошие продукты, в которые эти испорченные люди потом придут работать.
Мне рассказывали про программистов, которые прямо так и говорят на полном серьезе: «Я сегодня делал баги, пусть ищут».
Про заставить программистов тестировать — это вообще отдельная песня. Стереотип потому что, что занятие это второстепенное. Но в выпуске продукта второстепенных задач нет, Вы согласитесь, я уверена. Потому что Вы ответственность за свой продукт чувствуете.
но Вы даже не представляете, в скольких компаниях такие проблемы. Я часто по конференциям езжу и со многими людьми разговариваю. такого много. Меня такого рода ситуации ставят в тупик. В голове не укладывается, КАК можно считать работу твоего со-командника второстепенной и пытаться нивелировать её ценность. КАК можно сказать «это не баг», зная, что так и пойдет в продакшн, не исправленным.
Во всех командах, где мне доводилось работать, мы вместе с программистами разбирали баги, советовались о приоритетах тестирования и выборе областей наибольшего внимания. С нынешней командой мы совместно импрувим процесс работы, чтобы было удобнее и эффективнее работать.
А извилины менеджера по персоналу тут вряд ли помогут. Если они не сталкивались с такими проблемами, они не смогут идентифицировать их на собеседовании.
замужем, потому и смотрю :)
Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»
Это sofy skills, которые тоже очень важны при найме специалиста.
В моей прошлой компании приходилось набирать по 20 человек за месяц на новые проекты, сложно было смотреть ещё и на отношение человека к работе, потому что на рынке специалисты вообще дефицит. Но, тем не менее, отказывали потенциальным вирусам.
И исходить правильное отношение к работе и к коллегам должно от менеджера, в первую очередь. Если он, конечно, не координатор работ, а действительно человек, отвечающий за свой проект.
Вы знаете, это смотря что при этом подразумевает говорящий. Если это просто формулировка такая, типа как друзья между собой общаются: «Въехал вчера в зад джипу на перекрестке» — «Ну курица ты, что сказать», то конечно ничего страшного нет. Но если это всерьез говорится, то такие высказывания сбивают с толку неопытных тестеров, да и подход такой не способствует эффективной работе.
>> Cоответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика.
Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»
>>Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков.
то же самое, что и в предыдущем пункте
>>Тут все зависит от процесса тестирования.
Согласна. Но в гибком процессе эффективнее, чтобы тестировщики были в курсе дальнейшей судьбы дефектов.
Вообще, я Вам так скажу: это все имеет право на жизнь, если это не клиника. Но намного здоровее и продуктивнее работать с людьми заинтересованными в успехе своего дела. Да, это трудно обеспечить в жестком процессе, где шаг вправо не поощряется.
Если говорить о том, что "«нефиг заниматься не своим делом, за это не похвалят» — то тут у меня такое мнение: все, чему ты учишься, добавляет тебе стоимость (карму, если хотите). В этом проекте тебя считали выскочкой и шикали — в другой компании тебя с руками оторвут и денег дадут больше, и ответственности.
Такой момент: набирая себе людей (я руковожу отделом тестирования), я смотрю на то, в каких проектах им доводилось работать. Если в таких, как Вы описываете, то мне такие не нужны. Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.
Мой выбор такой, именно поэтому и атмосфера у меня в отделе такая, что ничего из описанного в посте нет.