Вы отличный IT-специалист, прошли долгий путь от новичка до профессионала и находитесь на последних ступенях, за которыми только менеджмент. Руководство уже намекает, что пора бы брать на себя задачу менеджмента команды, ведь в продукте вы разбираетесь и с коллегами работаете не первый год. И действительно, ну появятся новые задачи, справитесь, как справлялись с теми, что были раньше. Но вот проблема, раньше они были техническими, а работа с людьми - совсем другое. Не одна тысяча проектов проваливаются исключительно из-за плохого управления. Сегодня мы взглянем на менеджмент качества проекта и опровергнем несколько устойчивых и вредных мифов. Этот доклад для начинающих менеджеров, а также для тех, кто вот-вот вырастет в менеджера из тестировщика.
Лекция в РБК и Sensitive Brands в ответ на запросы вроде: как правильно работать с почтой, сервисами, планерами, таскменеджерами, как быстро читать соцсети и новости, как использовать ярлычки и папки.
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Лекция в РБК и Sensitive Brands в ответ на запросы вроде: как правильно работать с почтой, сервисами, планерами, таскменеджерами, как быстро читать соцсети и новости, как использовать ярлычки и папки.
Презентация к вебинару - https://youtu.be/mZEJ_YEFdoI
Вебинар из серии вебинаров ICAgile Agile Team Facilitation, которая состоит из 7 вебинаров о фасилитации Agile команд. Будем рассматривать техники, которые помогают командам проводить совместные обсуждение и принимать решения.
О чем узнаете на вебинаре?
2 техники для “обсуждения-дискусcии", они обе хорошо подойдут как для малых (4-5 человек) так и для больших (12-14 человек) команд. Плюсы и минусы этих техник, особенности и возможности их трансформации под ваши рабочие условия.
2 техники для “обсуждения-обратной связи". Одна из них довольно распространенная и она мне не очень нравится своей банальностью, а вторую вы вряд ли знаете, она интереснее, но и сложнее в применении.
1 техника для “обсуждения-анализа”, называется “Декартовы Координаты”, часто применяется в индивидуальном коучинге, но в 99% упускается одна интересная деталь при ее использовании, на вебинаре я про нее расскажу.
2 техники для голосования, про точко-голосование вы все, конечно, уже в курсе, я расскажу еще две простые техники, может, они вам тоже знакомы. Я бы хотела больше остановиться даже не на самих техниках, а на том, как можно манипулировать будущими результатами голосования еще до самого голосования.
Продолжая тему манипуляций, мы рассмотрим валидность мажоритарного способа принятия решений и познакомимся с другими, возможно, более подходящими для ваших команд, подходами.
Запись прошлых вебинаров:
https://youtu.be/7x3uHaFqe1I
https://youtu.be/ykx54Kx6wOA
https://youtu.be/mjIu06mvO4A
Как Повысить Продуктивность: 17 Уникальных Советов, Которые Действительно Раб...GanttPRO Software
Как повысить продуктивность работы
Небольшие шаги и советы, которые способны привести к значительным изменениям.
А как вы повышаете продуктивность работы? Делитесь опытом в комментариях ниже.
Полная версия статьи по ссылке:
https://blog.ganttpro.com/ru/kak-povysit-produktivnost-productivity-raboty/
Рецензия на книгу Джеффа Сазерленда "SCRUM. Революционный метод управления пр...Valerii Kosenko
О чем книга?
О более широком позиционировании Scrum как “методологии управления проектами, бизнесом” и даже “жизненным состоянием” (с.55), и “решением серьезных проблем человечества” (с.231) взамен существующего позиционирования как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне постоянной критики каскадной модели и диаграммы Ганта.
О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56).
Об управлении противоположном “Макиавелли” (с.182)
И вы не поверите - про бирюзовые организации, такие как Morning Star (с.257)
Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу?
В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.
Мифы про Project-ов, Product-ов, любимую Jira и многие темы вокруг на Gonchik Tsymzhitov
Привет!
В этот день мы поговорим про "Мифы про Project-ов, Product-ов, любимую Jira и многие темы вокруг".
Программа конференции
12:45 – 12:50 - Татьяна Гороховская, Наталья Кудрявцева, Product club SPb community leader, Tektosoft Product Manager, Chief of Staff «Мифическая схожесть Product Manager и Project manager: почему нас часто путают?»
Развеиваем мифы о схожести и различиях двух управленческих ролей в продукте, рассказываем легенды о требованиях к профессии продуктолога.
Взгляд изнутри, обзор ситуации на рынке труда.
12:50 – 13:20 - Гончик Цымжитов, Atlassian User Group SPb community leader, «Мифы и легенды Jira. Стандартная функциональность дашбордов на практике»
Поговорим о мифах гибкости и не гибкости инструмента для живых отчетов. Развеем миф, что графики - не главное, поделимся легендами 3 китов анализа в Jira
13:30 – 13:50 - Екатерина Сенаторова, HERE Eastern Europe, Sr LDI Analyst, Project Lead «Канбан метрики в Jira. Мифический зверь или реальность?»
В докладе поговорим о том, какие метрики есть в Канбан методе и зачем они нужны. И что делать, если Канбан хочется, но у вас Jira — как на основе базового функционала возможно работать с метриками и как это делаем мы, в компании HERE.
14:00 – 14:30 - Брейк! Нетворкаем и переводим дух
14:30 – 15:30 - Игра! Игра о пропускной способности команды Часто кажется, что чем больше возьмёшься сделать, тем больше и сделаешь. Но мы-то с вами знаем, что это не так. Или всё же так?
14:40 – 15:10 Юлия Атлыгина, ALM Works, «OKR: миф или реальность?»
Поговорим о том, что такое OKR и обсудим несколько мифов о целеполагании: где правда, а где вымысел?
15:30 – 16:15 - Александр Зиза партнёр Aletheia-Digital, партнёр Онтико, эксперт МШУ СКОЛКОВО
«Развенчиваем миф: есть люди, с которыми невозможно найти общий язык»^ Люди являются одним из основных факторов неопределенности и рисков в управлении проектами. В зависимости от их ролей, позиций и статусов, интересов и мировоззрения, их можно типизировать и выбрать наиболее подходящую стратегию взаимодействия для каждого типа. А для чего это нам? Для того, чтобы выстроить правильную коммуникацию, минимизировать риски и отклонения от плана. Вместе разберем схемы и рассмотрим стратегии коммуникаций с некоторыми типовыми ролями.
16:25 – 17:15 - Андрей Макаров Neti, Директор по счастью, спикер TED «Миф: счастье сотрудников - это не про бизнес»
Говорят, что думать о счастье сотрудников - это не про бизнес. Что счастье - это мягкие пуфики, смузи, макбуки и зарплата побольше.
Как Повысить Продуктивность: 17 Уникальных Советов, Которые Действительно Раб...GanttPRO Software
Как повысить продуктивность работы
Небольшие шаги и советы, которые способны привести к значительным изменениям.
А как вы повышаете продуктивность работы? Делитесь опытом в комментариях ниже.
Полная версия статьи по ссылке:
https://blog.ganttpro.com/ru/kak-povysit-produktivnost-productivity-raboty/
Рецензия на книгу Джеффа Сазерленда "SCRUM. Революционный метод управления пр...Valerii Kosenko
О чем книга?
О более широком позиционировании Scrum как “методологии управления проектами, бизнесом” и даже “жизненным состоянием” (с.55), и “решением серьезных проблем человечества” (с.231) взамен существующего позиционирования как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне постоянной критики каскадной модели и диаграммы Ганта.
О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56).
Об управлении противоположном “Макиавелли” (с.182)
И вы не поверите - про бирюзовые организации, такие как Morning Star (с.257)
Программное обеспечение не вечно. Старые продукты перестают удовлетворять каким-то требованиям и запускаются проекты по разработке новых продуктов, которые должны быть функциональнее, быстрее, надёжнее. Но вот беда: новый продукт нельзя сделать за пару месяцев. Разработка может тянуться в течение года, двух, трёх… И всё это время старый продукт требует поддержки и допилки. Вот здесь и начинаются проблемы. Должен ли опыт разработки старого продукта учитываться при создании нового? Должны ли команды работать друг с другом и насколько тесно? Как сохранить мотивацию команды, поддерживающей старый продукт и как мотивировать догоняющих? Что делать, когда оба продукта работают на боевой среде и данные в них частично дублируются, а частично противоречат друг другу?
В своём докладе я расскажу о тех ошибках, которые я встречал (и совершал тоже) при одновременной разработке легаси-проекта и его преемника, а также о том, как можно в этой ситуации избежать конфликтов между людьми, технологиями и данными.
Мифы про Project-ов, Product-ов, любимую Jira и многие темы вокруг на Gonchik Tsymzhitov
Привет!
В этот день мы поговорим про "Мифы про Project-ов, Product-ов, любимую Jira и многие темы вокруг".
Программа конференции
12:45 – 12:50 - Татьяна Гороховская, Наталья Кудрявцева, Product club SPb community leader, Tektosoft Product Manager, Chief of Staff «Мифическая схожесть Product Manager и Project manager: почему нас часто путают?»
Развеиваем мифы о схожести и различиях двух управленческих ролей в продукте, рассказываем легенды о требованиях к профессии продуктолога.
Взгляд изнутри, обзор ситуации на рынке труда.
12:50 – 13:20 - Гончик Цымжитов, Atlassian User Group SPb community leader, «Мифы и легенды Jira. Стандартная функциональность дашбордов на практике»
Поговорим о мифах гибкости и не гибкости инструмента для живых отчетов. Развеем миф, что графики - не главное, поделимся легендами 3 китов анализа в Jira
13:30 – 13:50 - Екатерина Сенаторова, HERE Eastern Europe, Sr LDI Analyst, Project Lead «Канбан метрики в Jira. Мифический зверь или реальность?»
В докладе поговорим о том, какие метрики есть в Канбан методе и зачем они нужны. И что делать, если Канбан хочется, но у вас Jira — как на основе базового функционала возможно работать с метриками и как это делаем мы, в компании HERE.
14:00 – 14:30 - Брейк! Нетворкаем и переводим дух
14:30 – 15:30 - Игра! Игра о пропускной способности команды Часто кажется, что чем больше возьмёшься сделать, тем больше и сделаешь. Но мы-то с вами знаем, что это не так. Или всё же так?
14:40 – 15:10 Юлия Атлыгина, ALM Works, «OKR: миф или реальность?»
Поговорим о том, что такое OKR и обсудим несколько мифов о целеполагании: где правда, а где вымысел?
15:30 – 16:15 - Александр Зиза партнёр Aletheia-Digital, партнёр Онтико, эксперт МШУ СКОЛКОВО
«Развенчиваем миф: есть люди, с которыми невозможно найти общий язык»^ Люди являются одним из основных факторов неопределенности и рисков в управлении проектами. В зависимости от их ролей, позиций и статусов, интересов и мировоззрения, их можно типизировать и выбрать наиболее подходящую стратегию взаимодействия для каждого типа. А для чего это нам? Для того, чтобы выстроить правильную коммуникацию, минимизировать риски и отклонения от плана. Вместе разберем схемы и рассмотрим стратегии коммуникаций с некоторыми типовыми ролями.
16:25 – 17:15 - Андрей Макаров Neti, Директор по счастью, спикер TED «Миф: счастье сотрудников - это не про бизнес»
Говорят, что думать о счастье сотрудников - это не про бизнес. Что счастье - это мягкие пуфики, смузи, макбуки и зарплата побольше.
Лира: Как мы строим распределенную работу с клиентами и внутриArtem Akulov
Поиск и привлечение сотрудников в бюро, организация работы в разных часовых поясах.
Привлечение и работа с клиентами из других городов и стран. Опыт и рекомендации бюро.
Доклад на SemConf 2017. Москва
Что я делаю каждый день: дневник креативного продюсера / Альберт Жильцов (1C ...DevGAMM Conference
Менеджмент творческих коллективов, 40 минут о самом простом. О том, что Альберт Жильцов, Creative Producer в 1C Game Studios, делает каждый день: об удаленке и роли продюсера, о пользе споров и необходимости общения, об инструментах и процессах, которые пригодились и нет.
QA Fest 2019. Сергій Короленко. Топ веб вразливостей за 40 хвилинQAFest
Поговоримо про найпопулярніші помилки, яких припускаються розробники веб додатків, та як зловмисник може використати їх на свою користь. Охопимо максимальну кількість матеріалу за короткий проміжок часу.
QA Fest 2019. Анна Чернышова. Self-healing test automation 2.0. The FutureQAFest
Мы уже разговаривали о self-healing автоматизации, как она работает, какие есть подходы, чем они хороши, плохи и о новом инструменте, который мы разрабатываем в EPAM. Наш продукт завершает стадию POC и настало время поделиться результатами и понять, насколько self-healing автоматизация поможет вашим тестам стать стабильнее? Или наоборот, навредит?... Приходи и узнаешь!
QA Fest 2019. Doug Sillars. It's just too Slow: Testing Mobile application pe...QAFest
Mobile apps and websites are now the predominant ways that users interact with brands. Research has shown that slow sites and apps lose customer engagement. Despite this, most mobile sites and apps have performance issues that can be easily resolved once diagnosed. In this talk, we will walk through steps to diagnose network performance bottlenecks in mobile services. We'll discuss real-world examples and how they were resolved. Attendees will leave this talk armed with the tools to test, diagnose and resolve the top network performance issues that affect mobile today.
QA Fest 2019. Катерина Спринсян. Параллельное покрытие автотестами и другие и...QAFest
Раньше мы в Badoo фокусировались в основным на ручном тестировании. Получался этакий дедлок мануальной регрессии: не было времени, чтоб писать тесты, потому что много тестировали руками, а много тестировали руками, потому что не было автотестов.
Но мы смогли наладить свою систему автоматизации и процессы, разорвали этот порочный круг и начали писать годные тесты.
В своем докладе я расскажу, как нам удалось сократить ручную регрессию с 90% до 30% рабочего времени, при этом сохранить достойный уровень качества и профессионально вырасти!
QA Fest 2019. Никита Галкин. Как зарабатывать большеQAFest
Вам знаком термин mindshift? Именно его вы испытаете от этого доклада. Он будет не о QA процессах или инструментах, он будет о деньгах и бизнесе, о рисках и коммуникациях. Все это с примерами из Украинского и мировом IT в формате живого общения с аудиторией.
QA Fest 2019. Сергей Пирогов. Why everything is spoiledQAFest
In this talk, I will cover the pain points of the Test Automation process. We will discuss traps, mistakes and crazy decisions that lead to test automation failure and lost budgets.
QA Fest 2019. Сергей Новик. Между мотивацией и выгораниемQAFest
Поговорим о мотивации простым языком, проясним, что стимулирует нас работать лучше. Поисследуем обратную сторону мотивации – выгорание. Выясним, как диагностировать выгорание и не допустить неприятных последствий.
QA Fest 2019. Владимир Никонов. Код Шредингера или зачем и как мы тестируем н...QAFest
Для разработки современных программных решений необходимо обеспечить эффективную систему тестирования, которая состоит из большого количества компонентов и задает требования ко всем этапам разработки.
Владимир Никонов, руководитель департамента разработки платформы в Terrasoft, эксперт в области проектирования приложений с опытом работы более 10 лет, поделится экспертным мнением с участниками QA Fest и расскажет:
- об инструментах и процессах на каждом этапе создания и поставки функциональности: от unit-тестов до нефункционального тестирования;
- о требования к инструментам тестирования и компетенциям команды QA-инженеров, которые необходимо выдвигать на каждом этапе тестирования;
- как внедрять современные подходы в существующий проект с минимальными затратами;
- как развивать команду и процессы тестирования в целом.
QA Fest 2019. Владимир Трандафилов. GUI automation of WEB application with SV...QAFest
Доклад посвящен автоматизации тестирования WEB-приложений с SVG-графикой. В 1-ой части доклада даны короткое описание процессов разрабатываемого приложения и обоснование необходимости применения SVG-графики. Во 2-ой части сделан короткий обзор SVG-графики, показаны основные преимущества/недостатки такого типа графики, сделан обзор основных SVG-поверхностей и рассмотрен процесс их трансформации с помощью матрицы преобразования с разбором ее основных типов. В 3-ей части обозначены основные проблемы автоматизации действий с SVG-графикой, такие как drag’n’drop графических объектов (SVG на SVG), их масштабирование при помощи колесика мышки и выделение ломаный линий. В 4-ой части показаны решения обозначенных проблем с использованием JavaScript.
QA Fest 2019. Иван Крутов. Bulletproof Selenium ClusterQAFest
Browser tests are known to be the flakiest ones. This is partly because browser infrastructure is complicated to maintain. But the second reason is – mainstream browser automation tools such as Selenium server are far from being efficient.
A year ago I have shown Selenoid - a truly efficient replacement of the standard Selenium server. This year I would like to demonstrate how to organize a fault-tolerant and easily scalable Selenium cluster using virtual machines in the cloud. I will start by setting up several Selenoid nodes and configure them to send logs and recorded videos to S3-compatible storage. Then I will run multiple Ggr load balancer instances allowing to use all running Selenoid nodes and organize a single entry point to the cluster. Finally, we'll discuss how to work with VNC and video recording in such a cluster.
QA Fest 2019. Николай Мижигурский. Миссия /*не*/выполнима: гуманитарий собесе...QAFest
Случалось ли вам запускать автоматизацию на проекте? Испытывать непревзойденное удовольствие от необходимости собеседовать технического специалиста, когда сам не имеешь технического опыта? Если да, то этот доклад для вас.
Мы научимся анализировать сеньорность кандитата, его технический уровень и способность к организации команд. Но самое главное - все это мы сможем достичь без серьезного технического опыта. Будет интересно, заходи на огонек!
QA Fest 2019. Володимир Стиран. Чим раніше – тим вигідніше, але ніколи не піз...QAFest
Це буде огляд підходів до побудови програми безпеки програмного забезпечення в команді розробки або кампанії загалом, доповнений висновками з мого власного досвіду виконання практичних та консультаційних проектів в сфері Application Security.
QA Fest 2019. Дмитрий Прокопук. Mocks and network tricks in UI automationQAFest
Веб-приложения и технологии стремительно развиваются. Мы уже вступили в эру Single Page Application и идем к Progressive Web Application. В большинстве современных проектов идет разделение команд на front-end и back-end, и не только команд, но идет раздельная релизная политика. Это требует более детальных подходов к тестированию front-end. В этом докладе мы рассмотрим кейсы, который есть на практике при тестировании задач front-end и инструменты автоматизации, которые могут решать задачи описанные в этих кейсах: чтение request/response browser network и соответственно мокирование response.
QA Fest 2019. Екатерина Дядечко. Тестирование медицинского софта — вызовы и в...QAFest
Проектирование и производство медицинских устройств — это регулируемый бизнес. Государственные органы во всем мире призваны гарантировать безопасность и эффективность медицинских устройств. Несоответствие нормативным требованиям ставит под угрозу жизнь и здоровье человека. Как медицинское регулирование влияет на рабочий процесс компании производителя? Мы поговорим о том, какие вызовы стоят перед тестировщиком медицинского софта, а также какие возможности при этом открываются.
QA Fest 2019. Катерина Черникова. Tune your P’s: the pop-art of keeping testa...QAFest
This document discusses testability and provides advice on several topics related to keeping testability under control, including problem, product, people, proactivity, productivity, pipeline, project, process, and philosophy. For each topic, common issues are identified and recommendations are provided, with an emphasis on taking a whole team approach and focusing on customers, risks, automation, decision making, and continuous improvement.
QA Fest 2019. Алиса Бойко. Какнезапутаться в коммуникативных сетях ITQAFest
Твою гениальность не замечает никто кроме мамы? Идеи и проекты нравятся только твоему коту? Одногруппники уже руководители подразделений, а ты завис между middle и senior? Пришло время найти баги не только на проекте, но и в своей голове! Прокачаем коммуникативные навыки:)
QA Fest 2019. Святослав Логин. Как найти уязвимости в мобильном приложенииQAFest
С каждым годом мобильных приложений становится все больше, но мало кто обращает внимание на безопасность этого приложения, когда оно находится в процессе разработки. Так как бизнес нацелен только на то, чтобы оторвать большую часть пользователей, которые будут использовать это приложение, они обращают внимание на конфиденциальность своих клиентов в последнюю очередь. В своем докладе я расскажу как мануал QA может проверить мобильное приложение на уязвимости и найти топовые дыры по рейтингу OWASP. В презентации будут использованы такие тулзы Santoku Linux + Genymotion.
QA Fest 2019. Катерина Шепелєва та Інна Оснач. Що українцям потрібно знати пр...QAFest
Маючи досвід роботи з іноземними замовниками і колегами, а також вивчаючи культурні особливості жителів інших країн, ми якось поставили собі за мету з'ясувати, якими українців бачать іноземці, чи потрібно їм підлаштовуватись під нашу манеру спілкування, чи є щось, що вони зовсім не можуть прийняти.
Поділимося з вами результатами цієї затії, а також поговоримо про:
- те, що потрібно знати українцям про свої софт скіли,
- то, як відрізняються софт скіли українців і жителів кількох інших країн,
- важливість софт скілів для успішних комунікацій з іноземними колегами,
- важливість софт скілів для просування по кар'єрі.
QA Fest 2019. Антон Серпутько. Нагрузочное тестирование распределенных асинхр...QAFest
Обычно в процессе нагрузочного тестирование необходимые app-side метрики(response time, throughput, ..) можно получить прямо в генераторе нагрузки. Мы шлем запрос, получаем респонс и зачастую время выполнения запроса это и есть то что нам нужно.
Но что если после того как сервер отдал вам ответ происходит еще ряд асинхронных операций, время выполнения которых нам необходимо проверить? Как замерить время выполнения этих запросов? Какая часть системы является узким местом в производительности?
В докладе рассмотрим какие челенжи появляются в такой ситуации и как их можно решить.
QA Fest 2019. Петр Тарасенко. QA Hackathon - The Cookbook 22QAFest
Хотели бы вы, чтобы в Украине происходило больше QA ивентов? Чувствуете, что их не хватает?
Знаете, кто может это изменить? - Вы!
Я поделюсь подходами, которые мы использовали при организации QA хакатонов в Wix, которыми завтра вы сможете воспользоваться для создания вашего крутого ивента!
QA Fest 2019. Петр Тарасенко. QA Hackathon - The Cookbook 22
QA Fest 2017.Андрей Павлов.Спецвыпуск MythBusters для начинающего QA-Менеджера
1. QA Fest 2017
СпецвыпуСк MythBusters для
начинающего QA-Менеджера
Andrey Pavlov
T-Systems RUS, Saint-Petersburg
2. overview
Разрушаем мифы:
Микроменеджмент - это нормально
Проекту требуется, чтобы люди работали в
overtime
Ты можешь руководить любым количеством
тестировщиков
Я могу рассчитывать работу исходя из
времени, которое люди проводят на работе
Я должен решать проблемы команды за них
Я могу придумать, как другие люди будут
делать свою работу
Idea:
3. About me
June
Ex-Developer
В IT более 10 лет
5 из них в тестировании
Test Team Lead @ T-Systems
linkedin.com/in/qapavlov
ru.apavlov@gmail.com
5. Myth 1: МикроМенеджМент - это норМально
June
Елена
QA-менеджер
Олег
Тестировщик
Привет, Олег! Как дела с тем багом?
Я еще не закончил…
6. Myth 1: МикроМенеджМент - это норМально
June
Ну, я должна знать, когда ты закончишь. Ты ведь
используешь именно тот подход, что мы обсудили?
Мы не обсуждали подход вообще.
Может быть, ты хочешь сделать это сама?!
Может быть, я могу вам помочь?
Елена
QA-менеджер
Олег
Тестировщик
Павел
Руководитель направления
7. Myth 1: МикроМенеджМент - это норМально
June
Это было бы здорово!
Елена
QA-менеджер
Олег
Тестировщик
Павел
Руководитель направления
8. Myth 1: МикроМенеджМент - это норМально
June
Окей, расскажи мне, что случилось.
Елена не дает мне делать мою работу! И это касается
не только этого бага.
Мне нужно время подумать!
Олег
Тестировщик
Павел
Руководитель направления
9. Myth 1: МикроМенеджМент - это норМально
June
А что значит, что это касается не только
данного бага?
Она всегда думает, что знает все лучше других.
Когда я говорю ей, что мне нужна помощь, она
отвечает, что когда она была тестером, то ей с такими
задачами никто не помогал.
Олег
Тестировщик
Павел
Руководитель направления
10. Myth 1: МикроМенеджМент - это норМально
June
Ладно, думаю, что сегодня у меня будет минутка
поговорить об этом с Леной.
Олег
Тестировщик
Павел
Руководитель направления
11. Myth 1: МикроМенеджМент - это норМально
Менеджеры должны учиться делегировать!
Если вы были одним из лучших технических специалистов, и были повышены до менеджера, вам
однозначно придется научиться, как делегировать задания.
Люди хотят чувствовать себя ответственными за свою собственную работу. Люди хотят и добиваться
успеха и терпеть неудачу самостоятельно.
Если вы объясните людям, зачем вы этого хотите, ваши сотрудники это сделают.
13. Myth 2: Ты можешь руководиТь любым количесТвом
ТесТировщиков!
June
Иван
QA-менеджер
Екатерина
Test Team Lead
Катя, через две недели я добавлю еще троих
тестировщиков в твою команду.
Подожди! Нам нужно это обсудить.
Мне нужно нанять троих тестировщиков? Зачем?
14. Myth 2: Ты можешь руководиТь любым количесТвом
ТесТировщиков!
June
Иван
QA-менеджер
Екатерина
Test Team Lead
Нет-нет!
Я переведу троих тестировщиков из команды Олега.
Я хотел бы, чтобы ты ими руководила.
Если ты добавишь мне еще трех человек, я не буду в
состоянии руководить ими.
У меня не будет времени.
15. Myth 2: Ты можешь руководиТь любым количесТвом
ТесТировщиков!
Каково разумное число людей, которыми может управлять QA-менеджер?
Как с любыми сложными вопросами, ответ, разумеется: “Это зависит от…”.
Если вы уже менеджер, вы знаете, что вполне возможно руководить командой в восемь-девять
сотрудников. Как только вы пытаетесь управлять больше чем девятью людьми, вам приходится
искать дополнительное время, чтобы встретиться с людьми и обсудить их работу.
Это говорит о том, что пора посмотреть на конфигурацию команды и спросить, можно ли
делегировать больше ответственности другим, например, тим-лидам? Однако, не нужно забывать,
что и у них есть предел максимального количества сотрудников и вряд ли он больше, чем ваш.
16. Myth 2: Ты можешь руководиТь любым количесТвом
ТесТировщиков!
17. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
June
Алексей
Тестировщик
Ольга
Тестировщица
Ты слышала новую глупость, которую придумал наш
QA-менеджер Андрей?
Нет. Какую?
18. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
June
Алексей
Тестировщик
Ольга
Тестировщица
Мы должны заполнить тайм-шиты. Он хочет знать,
сколько времени мы реально проводим на работе.
Чем больше времени, тем лучше.
Ну, кажется, это не сложно.
19. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
June
Алексей
Тестировщик
Ольга
Тестировщица
Да. Но это глупость. Я не понимаю, почему он думает,
что может измерить нашу продуктивность по тому
времени, которое мы тратим здесь.
У всех бывают неудачные дни, когда работа просто
“не идет”.
Ну, у меня конечно, тоже бывают такие дни.
Хорошо, как мы можем обратить внимание Андрея на
его ошибку?
20. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
June
Алексей
Тестировщик
Ольга
Тестировщица
Возможно, стоит попросить его руководство
поговорить с ним. Или, возможно, мы должны сами
объяснить, что скорость работы имеет очень
небольшое отношение ко времени, проведенному на
работе.
21. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
Время – это не результат!
Когда вы используете время в качестве меры работы своих людей, вы заставляете их играть по
вашим правилам и показывать определенное поведение. Время на работе не равняется
продуктивной работе. Никогда не равнялась, и никогда не будет.
Если вы перестанете требовать обязательного нахождения на работе весь день при любых
условиях, ваши сотрудники смогут сами принимать решения относительно своих задач.
Сотрудники умственного труда работают в разном темпе в разные дни. Некоторые дни им
работается быстрее. Некоторые - медленнее. Я не скажу вам, сколько времени я писал этот доклад.
Но могу абсолютно точно заявить, что у этого процесса была неравномерная скорость. Однако
результат – законченный доклад, который вы сейчас слушаете.
22. Myth 3: Я могу рассчиТываТь рабоТу исходЯ из
времени, коТорое люди проводЯТ на рабоТе
23. Myth 4: проекТу ТребуеТсЯ, чТобы люди рабоТали в
overtime
June
Максим
IT – директор.
Марина
QA-менеджер
Марина, мы должны поговорить. Мне не нравится как
ты управляешь тестировщиками.
Все твои сотрудники уезжают из офиса 17:00 и 17:30!
А есть какая-то проблема с тестированием?
Насколько я знаю, на данный момент мы сделали
все, что было обговорено.
Я знаю, что тебе хотелось бы, чтобы мы делали
больше. Но мы делаем то, о чем договаривались.
В чем проблема?
24. Myth 4: проекТу ТребуеТсЯ, чТобы люди рабоТали в
overtime
June
Максим
IT – директор.
Марина
QA-менеджер
Люди уходят из офиса! В пять часов!
Нам нужен больший commitment! Нам нужно, чтобы
все в нашей лодке были готовы грести!
Что это за аллегории с бизнесом и лодками?
Они приходят к стендапу в 9:00. Вся команда
приходит к этому времени. До 17:00 работают, как
проклятые. К 17:30 они уже в полной запаре. Тебе
нужны усталые люди, которые работают над тестами
или документацией? Нет, вряд ли нужны.
25. Myth 4: проекТу ТребуеТсЯ, чТобы люди рабоТали в
overtime
June
Максим
IT – директор.
Марина
QA-менеджер
…
Хочешь знать, что я сказала сотрудникам? Я
разрешила им не задерживаться на работе, а
работать из дома, если будет желание. Это показало
отличные результаты. Почему? Поскольку люди не
утомлены. Они довольны своим временем и могут
самостоятельно им распоряжаться.
Теперь, еще раз, в чем проблема?
26. Myth 4: проекТу ТребуеТсЯ, чТобы люди рабоТали в
overtime
June
Максим
IT – директор.
Марина
QA-менеджер
Мне нужно, чтобы твоя команда выполняла больше
работы, помогала на других проектах.
Хорошо, тогда ты должен или забрать у нас часть
текущих задач, или позволить мне нанять больше
людей.
Но ты не можешь вытащить из людей больше работы.
Люди не могут думать больше.
Или тяжелее. Или быстрее.
27. Myth 4: проекТу ТребуеТсЯ, чТобы люди рабоТали в
overtime
Так в чем проблема?
Когда менеджеры просят, чтобы люди работали сверхурочно, они не думают о том, на что похож
день технического специалиста.
Когда менеджер хочет, чтобы люди работали сверхурочно, инвестировали свое время в проект и
компанию, какова реальная проблема, стоящая за этими словами?
Этот миф тесто связан с предыдущим, что менеджер хочет измерить работу тем временем которое
сотрудники тратят на работе. Когда вы не вынуждаете людей к обязательному соблюдению
рабочего времени, они прекращают заниматься бесполезной тратой времени. Они начинают
делать полезную работу, и они начинают сотрудничать. Но, только если Вы прекращаете
вмешиваться и все контролировать.
29. Myth 5: Я должен решаТь проблемы команды за них
June
Алексей
VP разработки
Так. Первым пунктом на нашей повестке дня мой
план относительно реорганизации нашего проекта.
30. Myth 5: Я должен решаТь проблемы команды за них
June
Я заметил, что некоторые проектные команды
испытывают затруднения при сотрудничестве, таким
образом, я решил, что нам нужна перестройка назад,
к функциональным командам.
О, нет, даже не думай об этом.
Это будет огромный шаг назад. Если ты это сделаешь,
я даже не знаю, что будет с проектом!
Действительно, разработка, наконец, добилась
успеха с TDD и continuous integration. Между
командами есть конфликты. Они работают над их
разрешением. Оставьте их в покое.
Какие проблемы Вы пытаетесь решить?Вера
Менеджер команды разработки
Алексей
VP разработки
Дмитрий
QA-менеджер
31. Myth 5: Я должен решаТь проблемы команды за них
June
На прошлой неделе я видел, как Наталья и Мария
кричали друг на друга, обсуждая последний билд.
Если мы разобьем аналитиков, разработчиков и
тестировщиков на функциональные группы, они не
будут так много ругаться, правильно?
Алексей, тестеры и разработчики наконец учатся,
как сотрудничать. Это ново для команд. Они никогда
работали так прежде. И вы должны ожидать “болезни
роста”. Позвольте им разобраться самим.
Эти люди - взрослые. Не пытайтесь решить проблемы
других людей для них. Позвольте им решить свои
проблемы самим.
Теперь, что дальше в Вашем списке на сегодняшний
митинг?Вера
Менеджер команды разработки
Алексей
VP разработки
Дмитрий
QA-менеджер
32. Myth 5: Я должен решаТь проблемы команды за них
Решайте проблемы на том уровне, на котором они были созданы.
Лучший способ решения проблем - когда люди с проблемой решают эту проблему. Если те люди
решают проблему слишком долго, то пора спросить, нуждаются ли они в помощи. Но главной
рекомендацией для менеджеров будет: “Позвольте, людям с проблемой решить эту проблему”.
Однако есть случаи, когда требуется помощь менеджеров. Бывает, команды или люди с проблемой
так погружены в нее, что испытывают явные затруднения при поиске решений.
Менеджеры, в данном случае, не те люди, которые должны проблему решить, но зачастую,
находясь на уровень выше, они могут яснее видеть решения.
33. Myth 5: Я должен решаТь проблемы команды за них
Один из способов, которыми мне нравится решать подобные проблемы, Правило Трех:
Найти одно решение проблемы – ловушка, которая с большой вероятностью заведет вас туда,
откуда будет очень сложно выбраться, хотя формально проблема может быть решена;
Найти два решения проблемы – всегда дилемма, которая оставляет после себя вопрос ”а что если
бы вы выбрали другой вариант?”;
Три же решения открывают возможности, и предоставляют нам выбор.
34. Myth 5: Я должен решаТь проблемы команды за них
Спросите команду, “Какая помощь вам может быть полезна от меня?” Могло случиться так, что
команда не думала о вас как о ресурсе для помощи вообще. И, тогда можно предложить ваши
варианты решения, но оставить возможность принять окончательное решение команде.
Менеджеры не должны решать проблемы команды. Они могут обеспечить обратную связь, тренинг,
ретроспективу, помощь.
Прежде чем вы возьметесь решать проблему команды, спросите себя, “Я делаю это для команды
или для себя?” Тогда Вы будете знать, что делать.
35. Myth 5: Я должен решаТь проблемы команды за них
36. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Хорошо, я действительно рада, что весь менеджмент
смог сегодня собраться. Я хотела бы поговорить о
стандартизации.
Я хочу создать стандарты для наших проектов.
Анна
IT директор
37. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Мм, Аня, я правильно понимаю, что ты хочешь, чтобы
теперь мы поставили все свои фишки на agile?
38. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Почему нет?
Ну, мы не закончили наш пилотный проект, это во-
первых, и у нас нет достаточного количества денег
для обучения.
Почему тебя беспокоит, как мы работаем, пока мы
работаем эффективно?
Наша работа состоит в том, чтобы решить проблемы.
Твоя работа состоит в том, чтобы удостовериться, что
мы решаем правильные проблемы.
39. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Ну…
Если ты сможешь ответить, какие проблемы мы
должны решить, мы подумаем, как эти проблемы
решить.
Возможно, мы придем в выводу, что тут нам поможет
agile. Возможно – нет.
Переход на agile — или любой другой подход — не
должен происходить, просто потому что ты так
решила.
40. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Но я…
И почему мы должны использовать именно этот
подход? Почему мы должны быть так
стандартизированны? “Agile или смерть” для всех
проектов?
В конце концов, Аня, ты наняла меня, потому что я
могу думать. Я нанял людей, потому что они могут
думать. Кажется, пришло время дать им подумать не
только о том, что делать, но и как им делать свою
работу.
41. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Конечно, но…
Я говорю, к черту стандартизацию!
Все наши проекты отличаются друг от друга. И
команды в проектах, зачастую, сильно отличаются.
Почему мы должны использовать один и тот же
подход в каждом случае?
Давайте объявим нашим экспертам результаты,
которых хотим достичь и временные рамки, когда
нам нужен этот результат. Почему мы должны делать
что-то, кроме этого?
42. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
June
Анна
IT директор
Николай
QA-менеджер
Хорошо, давате поступим так. Если вы берете
ответственность над своими экспериментами и пока
из-за этого не начались проблемы с поставками ПО –
мы договорились
43. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
Стандарты дают менеджерам ложное чувство безопасности.
Когда у вас есть “стандартный” подход к проектам, или что-такое, менеджеры чувствуют, будто у них
есть чувство защищенности. Это - ложное чувство.
Когда Вы стандартизируете работу сотрудников умственного труда, вы рискуете делать работу
скучной, менее эффективной, и не ориентированной на реальную цель вашего проекта.
Работа ума и знаний уникальна и организует сама себя. Вот почему каждый проект должен искать
свой собственный подход, начинется ли это как водопад, итерационная модель, инкрементальная
или их комбинации. Нет единого правильного способа делать все проекты. Каждая проектная
группа должна решить, как и что сделать для ее собственного проекта.
44. Myth 6: Я могу придумаТь, как другие люди будуТ
делаТь свою рабоТу
Навязываение стандартов не дает людям думать.
Хуже того, многие стандарты пытаются касаться всех потенциальных проблем в процессе.
Навязываение стандартов не дает людям думать.
Почему мы нанимаем людей? Думать и решать проблемы. Почему тогда не хотим, чтобы люди
думали? Нет, мы хотим, чтобы люди думали и решали проблемы, является ли это проблемой в
процессе или продукте.
Мы наняли этих людей, потому что мы считаем, что они умны. И они умны. Позвольте им показать,
как они применяют свои навыки решения проблем к самому проекту, не только к их области
знаний.
45. Myth 5: Я должен решаТь проблемы команды за них