Чуток вырвался из бесконечного колесика дел и могу вернуться к статьям. В конце ноября я посетил конференцию PM Day Lviv и хотел написать пару строк о ней и своих выступлениях.
Конференция проходила в 4 потока (PM практики, гибкие методологии, PM модели, мастер-классы). Среди участников были как IT менеджеры так и менеджеры в других направлениях. Это очень непривычно после многолетнего посещения сугубо IT мероприятий. Я уже привык к тому, что базовые IT понятия знакомы всем без исключения участникам и не стоит объяснять что к чему. Стоит отметить, что большинство докладов были совершенно не техническими и не затрагивали особенности и специфику именно IT.
Я побывал на выступлениях о построении культуры компании (так и не понял в чем же роль менеджера), об ответственности и лидерстве (вынес классификацию лидеров и способы ухода от ответственности), о видении современного менеджера, о рассуждении на тему необходимости менеджера в принципе (странный доклад, как бы поиск оправданий и самоубеждение), о тенденциях в современном менеджменте проектов (тут я вообще мало что понял, потому что текущая ситуация печальнее печального, а мы уже дальше городим абстрактные призывы и лозунги).
Ощущение в целом осталось двоякое. С одной стороны, круто что менеджеры собираются и говорят о насущных проблемах, делятся опытом и знаниями. С другой стороны, плохо что не затрагивается в обсуждениях IT специфика на достаточно глубоком уровне, создавая впечатление, что менеджер нужен для координации и организации работы группы странных, не способных на самоорганизацию людей. И это какой-то отрыв от реальности. В мире все больше обсуждают как строить максимально самоуправляемые команды, плоские организации вместо иерархических, как растворить роль менеджера в команде. А у нас вместо этого: “а кто это сделает если не менеджер? они же ничего не хотят и не умеют делать!”. Утрировано, но тем не менее такой посыл звучал из многих докладов.
Зато у нас получилась очень душевная after-party, где удалось пообщаться в непринужденной обстановки с знакомыми и познакомиться с новыми интересными людьми. Львов, душевность, настойки… И это я уже молчу про whisey pre-party в гостях у Тараса Матяшовского, где было еще душевнее.
Волею судеб (в последний момент не смог выступить другой докладчик), я выступал сразу с двумя докладами. Рассказывать о них не буду, чтобы не спойлерить, проще посмотреть видео и полистать слайдики.
Итак, первый доклад “Как QA инженеры могут повлиять на качество продукта? Или не могут?”:
И второй доклад “Геймификация в аутсорсинговой компании: практический отчет”:
Буду следить за этой конференцией и надеюсь участвую в ней в качестве докладчика не последний раз.
Обсуждение
( Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
2)
Привет, QA – это роль, а не конкретный человек. И да, это про те команды, где есть выделенный QA, а на деле он оказывается просто QC в лучшем случае. Тимлид не всегда обладает знаниями и навыками в области QA. Некоторые полезные для QA в целом навыки есть именно у тестировщиков.
Коля, привет. Из первого доклада я так и не понял, почему должен появиться отдельный человек, который должен париться за качество. А команде типа фиолетово. Ты же сам года 4 назад рассказывал про то, что тестировщики не нужны (я понимаю, что тестировщики – это не всегда и не совсем про QA), и там ты напирал на то, что задачи этой роли могут выполнять разработчики. Почему здесь это не работает? Почему разработчики не должны парится “а почему возник этот дефект”?
Или доклад из серии “если уж у вас есть QA, то вот чем он должен заниматься”.
А насчет того, что разработчики про тестирование и качество не читают, так и QA-щики (часто мной встречаемые) тоже редко это делают 😉 Многие так называемые QA-шики даже объяснить это самое QA не могут.
Куда в этой истории делся тимлид, если мы говорим о фиче-тиме, вообще неясно. В общем ты рассказал с проекции того, чем сейчас занимаешься.
Мы используем файлы cookies для различных целей, включая аналитику и персонализированный маркетинг. Продолжая пользоваться сайтом, вы соглашаетесь на использование файлов cookies. Подробно ознакомиться с правилами работы с файлами cookies можно здесь
Привет, QA – это роль, а не конкретный человек. И да, это про те команды, где есть выделенный QA, а на деле он оказывается просто QC в лучшем случае. Тимлид не всегда обладает знаниями и навыками в области QA. Некоторые полезные для QA в целом навыки есть именно у тестировщиков.
Коля, привет. Из первого доклада я так и не понял, почему должен появиться отдельный человек, который должен париться за качество. А команде типа фиолетово. Ты же сам года 4 назад рассказывал про то, что тестировщики не нужны (я понимаю, что тестировщики – это не всегда и не совсем про QA), и там ты напирал на то, что задачи этой роли могут выполнять разработчики. Почему здесь это не работает? Почему разработчики не должны парится “а почему возник этот дефект”?
Или доклад из серии “если уж у вас есть QA, то вот чем он должен заниматься”.
А насчет того, что разработчики про тестирование и качество не читают, так и QA-щики (часто мной встречаемые) тоже редко это делают 😉 Многие так называемые QA-шики даже объяснить это самое QA не могут.
Куда в этой истории делся тимлид, если мы говорим о фиче-тиме, вообще неясно. В общем ты рассказал с проекции того, чем сейчас занимаешься.