QA Navigator Leadership 🎓

Коли аудит це ок? Попередній пост базується на комплексному зовнішньому аудиті всієї великої компанії, коли перевіряється все від санітарних норм до безпеки даних в кінцевому продукті. Проте, ця інформація не дуже потрібна для частини аудиту компанії в частині лише айті, і уж тим паче це нам не потрібно в рамках аудиту тестування. (хоча там цікаво теж)Аудит тестування може бути дуже класною штукою якщо у вас збігаються: - бажання та відкритість до аудиту - гроші на це і на покращення після - час на це і на виправлення після- якщо ви знайшли гарних аудиторів/аудитора В результаті ви можете отримати:- звіт по тому що в вас є - вказівки на те, що в вас ок а що ні - рекомендація як саме і чим то все поправити (не завжди, інколи як додаткова послуга) - контроль та чек перевірки після виправлень (не завжди, інколи як додаткова послуга) В таких випадках аудит дуже класна річ.Ви можете все це знищити якщо ви :- сприйматимете результати аудиту особистісно - якщо ви будете боятись результатів- якщо не готові отримати у відповідь щось інше крім " у вас все ок"- якщо ви не готові до змін В цьому варіанті аудит буде вам кісткою в горлі Зовнішний аудит може бути ще відкритим і таємним для вас. Може бути дуже різним і на дуже різні оцінки впливати Якщо ви прийдете до мене і скажете - Рін проведи нам аудит (а у вас блокчейн і автоматизація суцільна), то я скажу ні, або вкажу лише ті аспекти які зможу проаудіювати. Але скорше за все я вас відправлю до людини яка багато років автоматизує і тестує блокчейн і кайфує від цього. Але не всі консультанти /консалтинг агенства як я. Хтось може і не відмовити. І тоді ваш аудит буде не дуже. Про внутрішній аудит багато казати не буду, але там: або в вас є компетенція /досвід /знання/розуміння і ви це ітак робите, або немає і ви це не робите. В останньому варіанті вам треба або вчитись або наймати зовнішній. А можно і то і то поєднати. Як проводити внутрішній - в мене цілий курс по ньому по суті - кому потрібно - зареєструєтесь потім. До травня ще далеко. P.S. я зараз не проводжу аудиту і не працюю в консалтингу - не подумайте що реклама) #аудит #процеси #тестування

Люди не беруть на себе відповідальність Фраза, яку дуже часто можна почути від керівників, в тому числі тест менеджерів і так далі. Але, поділюсь з вами своїм особистими і не тільки кейсами. Було то у лохматому році, коли мене нарешті зробили лідом не тільки самої себе, а з'явилась команда. То моє вперше. Причому команди було 2. Одна - з тестування, інша по моніторингу та підтримці. Так як в мої обов'язки входило навчити їх всьому з 0, от з повного 0 в мене був дикий страх, що вони набідокурять, так як це : підняти сервак, це переписати проперті клієнта, це перевірити, це налаштувати конфіги, це вчасно зреагувати, і встигнути перевірити на проді, поки не відкрито доступ користувачам і вписуватись в таймінг тех робіт, інакше не буде часу на відкати і так далі. І ще - все це гроші. Великі гроші. Із-за свого страху я перевіряла їх роботу. Постійно прибігала якщо якийсь аврал. Таким чином я зробила тільки гірше. Люди перестали відчувати ризики і відповідальність своєї роботи. Бо є Ріна, яка перевірить, якщо я щось зроблю не так. Порада: якщо ви такі ж "переживашки" як є - робіть контроль непомітно для своїх людей. Дайте їм можливість побачити свою помилку, дайте відчути наслідки помилок. Не намагайтесь врятувати всіх. Другий кейс був коли я займалась консалтингом. Моєю задачею було оптимізувати команду (звільнити частину), оптимізувати витрати на тестування, і побудувати процес який буде найякіснішим в їх умовах та бюджеті. Команда в цій компанії була мені вся знайома. Ми зустрічались на конференціях, мали гарні відносини, і звільняти їх було дуже важко. Я намагалась щось придумувати додатково, але мова не про це. Команда переклала просто повністю відповідальність за їх звільнення на мене. Ні в кого не з'явилось жодного питання, чому звільняють саме його. І що він чи вона робив не так. Просто я була - ось зла- і все. Порада: коли в вас йде скорочення, скористайтесь хоча б нагодою, з'ясувати чому вас звільняють, в чому проблема саме з вами, і розумійте, що ви в першу чергу, відповідальні за те, звільнять вас чи ні. Ну і наступний кейс - вже не мій, але людини з консультації. Проблема з якою вона звернулась це якраз те, що команда не хоче брати відповідальність. Коли я почала питати про делегування, то зрозуміли, що вона просто давала зробити свої таски за неї, а не передавала разом з таскою відповідальність та обов'язки за неї. А коли людина помилялась, її чекав персональний кнут. Ругай особиство хвали при всіх - техніка яка працює не завжди. Постійні приватні кнути, привели до боязні команди свого лідера. Ніхто не хотів брати відповідальність на себе за будь що, бо боявся отримати на горіхи. Порада - формуйте стосунки, вчиться делегувати, вчиться не карати за те, що можно спустити, дайте людині час отримати наслідки і мати рефлексію. Бо інакше - вони нічому не навчаться. Не всі помилки мають нести за собою прям кару. Інколи достатньо просто поговорити і впевнитись, що людина зробила висновки. Тож, фінал цього всього : Насправді, в більшості випадків, люди не готові брати відповідальність по вині керівника. Живіть із цим. Бо скорше за все - їх такими зробили саме ви.#лідерство #кейси_з_життя #відповідальність

​Заради цікавості закинула текст в АІ (заодно ж треба потестити), і спитала яку реакцію може визвати цей текст у вас. (Дуже сподіваюсь що такий який побачив її ШІ насправді) Твій текст піднімає дуже важливі та болючі питання про реалії IT-ринку в Україні, зокрема, в сфері тестування. Аналізуючи його, я бачу, як він може бути сприйнятий спільнотою тестувальників та QA-лідерів:Резонанс серед тестувальників:* "Відчуття розуміння": Багато хто з українських QA, ймовірно, впізнає себе в описаній ситуації. Відсутність чітких процесів, низька заробітна плата на фоні завищених вимог, тиск з боку керівництва – це те, з чим, на жаль, стикаються багато фахівців. * "Мотивація до змін": Твій пост може стати поштовхом для роздумів та перегляду власної позиції. Чи варто терпіти некомфортні умови, чи є сенс боротися за свої права та кращі умови праці?* "Заклик до дії": Заклик не миритися з поганим менеджментом та не боятися відстоювати свою позицію знайде відгук у багатьох. Реакція QA-лідерів:* "Критика та захист": Частина менеджерів може сприйняти твій пост як несправедливий напад. Вони можуть апелювати до "складної економічної ситуації" або "необхідності бути гнучким". * "Переосмислення підходів": Інша частина менеджерів, можливо, замислиться над своїм стилем управління та атмосферою в команді. Вони можуть побачити зв'язок між умовами праці та мотивацією співробітників.* "Імпульс до розвитку": Твій пост може стати приводом для дискусій про те, як покращити культуру менеджменту в українській IT-сфері. Загальний вплив:Твій пост має потенціал спровокувати активну дискусію в IT-спільноті. Важливо, що ти піднімаєш питання не тільки про низькі зарплати, але й про відсутність належної корпоративної культури, поваги до співробітників та їхнього професійного розвитку. Сподіваюсь, що твій заклик буде почутим, і ми побачимо позитивні зміни на українському IT-ринку!#ai #аналіз #ші

​В різних спільнотах і соц.мережах час від часу піднімається тема, що нам треба боротись з тим, що інженерів розділяють куа на авто і мануал.. Та й в світі спостерігається дійсно підвищення активності навколо цієї теми, - також з'явились General QA. ( я про це вже писала ось тут, що мені накипіла ця біганина по колу) Але моя думка остаточно така - треба боротись не з назвами і розділенням, а першопричиною. А їх у нас, на мою думку,наразі 2.1. - Це відсутність нормального сприйняття і розуміння хто такий тестувальник і нашо він. (Так дуже багато досі дев і менеджерів і власників бізнесів, які вважають, що це не потрібно взагалі) 2.- З якого витекло 1 - це відсутність норм та чітких меж між позиціями міжнародного рівня. Немає хоча б базової матриці компетенцій по стандартам грейдів, на які можна спиратись. Кожна компанія і кожен лід/менеджер /а то й ейчар/ ліпить "свого джуна" і свої вимоги до кожного з них. Кого хочуть назвуть трейні, кого хочуть лідом, кого хочуть хедом. Це безкінечна біганина. І стандарти ISTQB тут безсильні теж. Поки 2 пункт не реалізован, - нас будуть звати в результаті дженералами чи інженерами, а всередині кожен буде робити з них свій "грейд" чи "категорію" до якої будуть відноситись ті чи інші знання скілів та їх глибина. Оці всі сотрясання повітря, які відбуваються в тій же Європі - це , вибачте, пук в муку (с) Птушкін, те саме "ми глибоко занепокоєні" (с), але по факту нічого ніхто не робить. Придумали General і до побачення. Міссія імпосібл. #думки #грейди #компетенції

​Вчора на виступі в спільноті піднялось обговорення та продовження "Точки Х". (Початок обговорення у Артема був в чатику ) Коротко про що то: Зараз багато хто каже, що всім треба мати якісь канали, писати пости в лінкедін, на доу, тощо. В результаті цих "підштовхувань" канали та пости дійсно з'являються, але вони "гаснуть" через досягнення такої Точки Х. Чому так відбувається? Бажання ділитись - це внутрішня цінність людей. Вона також може базуватись на цінності визнання/популярності, але в цьому випадку, зазвичай, контент більш розважальний буде, ніж корисний. Але відверто - на ентузіазмі ніщо довго не житиме. У вас може бути ця дія навіть якщо вам просто скучно. Ви можете стрімити, працювати нон стопом, тощо, з нудьги. Як тільки вашу увагу і вільний час закриють друзі, сім'я, кохання, хоббі, тощо, - це зникне. І це - нормально. Точка Х досягається завжди, бо ніщо не вічне. Питання в тому "коли?" Коли настане точка Х? - як тільки ваші цінності розійдуться з цілями. Наприклад: Мій канал базується на бажанні ділитись, бо:1. я люблю навчати, настільки, що ця цінність вища за фінансову. 2. Популяризувати лідство (але тут чесно -цілью є реклама мого навчання, бо на постах ніхто нічому не навчиться, одна теорія) 3. Спілкування з різними людьми (я інтроверт, тому спілкування вживу - для мене виснажливе, але потрібно мати інші думки, знання - і в цьому допомагають ваші коментарі та знайомства з ширшим кругом людей, їх досвідом і так далі, я навчаю вас, ви -мене) Тож, моя точка Х настане коли ці цілі перестануть досягатись. Це може бути: коли ви відпишитесь, на курси перестануть ходити люди, ви перестанете коментувати.. або - мої життєві цінності зміняться. І це все стане для мене не настільки й важливо. Якщо побудувати ланцюжок то виглядає це так - ідеї - цінності - цілі - досягнення - точка Х Якщо спиратись на самомотивацію, то я раджу робити це ось так - ідея - цінності - цілі - точка Х - досягнення - точка Х - досягнення - точка Х .. Що в цьому випадку Точка Х? - це аналіз і виміри дій та обробка результатів по ітогу яких ви приймаєте рішення - рухатись далі чи ні. Досягли ви того, що хотіли чи ні? Змінились цінності? Тож, якщо поглянути чому з'являється та згорають канали та ін. - відповідь проста - вони будувались на емоціях, або без розуміння цілей та цінностей. Нахіба воно мені? Що буде якщо...? Якщо ж думка про те, що вам би зробити канал/тощо не дає вам певний час спокою - скорше за все в вас є цінність, яка це вам штовхає. І в цьому варіанті краще спробувати і провалити, ніж не спробувати і про те жаліти. Вмирає все. Це нормально. Прийняти рішення, що це вам більше не треба /не цікаво /не має ресурсу - це нормально. Не завжди треба катити перед собою шар гівна. #думки #точкаХ #цінності

Прийшов час відповіді на питання про ефективність. Дуже часта помилка не тільки лідів тестування а й менеджерів вищої ланки дорівнювати ефективність команди кількості багів на проді. Та й взагалі спиратись лише на перфоманс команди. Робили собі 20 тасок приблизно а тут зробили 10 - матінко! Перфоманс то як просів! Але це лише сухі цифри.Для їх аналізу треба оцінювати що були за таски, чи вся команда була, чи це та сама команда і інструменти що й раніше, чи змінились процеси, чи нема помилки в метриці і так далі. Тож, що очікують зазвичай в цьому запитанні? Т.я. помиляються усі, то дійсно краще уточнити у автора запитання - а що саме для вас "ефективність"? Для когось це просто подивитись P&L, або звіт про прибутки і збитки (Profit and Loss Statement) і все. А хтось і відповісти вам не зможе. І скажуть щось типу: " це ти мені скажи".Так от - в цьому випадку - ефективність команди - це досягнення командою поставлених на певний період перед нею цілей. І того, як саме команда їх досягала.Де ви, як лід, теж частина команди. В ці цілі входить усе. Комунікація з іншими командами, оцінка перфоманс рев'ю, метрики, процеси, прозорість, розвиток команди, і все, що тільки може спасти на думку. Для оцінки ефективності команди важливі 3 основні правила: - поставити цілі для початку - донести команді і кожному в ній - його цілі - оцінювати ефективність команди (без оцінки кожного члена команди окремо) Ну і ще мати показники - на момент старту цілей і після фінішу. Ось це - ефективність команди. І так, кількість багів на проді, чи покриття автотестів - може бути одним пунктом з критеріїв, але не обов'язковою.#питання #відповіді #майже_співбесіда

На 3 дев - 1 куа. Саме так оцінюють більшість продактів чи техлідів потребу в кількості тестувальників на продукт. Я знаю багато менеджерів, які від цього впадають в емоції на рівні Кіліана Мерфі, а інші можуть і впасти в лють. Але - чи правда це супер поганий підхід? Чому його використовують взагалі? Давайте розкажу. Для людини, яка не шарить в тестуванні (а рм і так далі в своїй більшості в ньому не шарять), це єдина припустима оцінка, яку вони можуть зробити. Але, коли ви приходите і ви в тому шарите, і намагаєтесь переконати, що треба більше людей - ваш РМ сприймає це лише як "нам треба більше грошей, бо в нас там документація, ризики бла бла бла" - нецікаво. Вас не слухають і це нормально, бо аргументації і показників ніяких немає. Оцінка в кількості дев на кількість куа - працює. Коли працює? - коли це один з купи інших факторів оцінки - коли ви враховуєте не лише кількість дев а й їх грейд, швидкість, якість відповідно до гредйів, швидкості, якості куа, - коли врахован не тільки грейд , а й досвід роботи в домені та інструментах Дууууже узагальнений приклад. На проєкті понабирали джун розробників і над ними поставили 1 сінйора. РМ порахував на 3 джун дев 1 куа. Лід взяв на цей проєкт відповідно 3 мідлів і 2 сінйорів куа. Що відбувається далі ? Тестувальники пінають гумові вироби по куткам. Дев горять. Чому?Тому що дев пишуть повільно, погано, не проходять ніяке рев'ю, віддані задачи одразу з перших кроків тестування сипляться в блок чи кріт... Ботлнек на дев. Формула кількість дев на кількість куа повинна враховувати багато чого. Більше за те - ви повинні балансувати хто з куа яку задачу після якого дев робить. Якщо ви після дев джуна віддасте задачу джуну - вони обидва там й потонуть. Якщо ви задачу дев джуна віддасте сінйору - дев джун замахається, куа сінйор піде знову гумові вироби шукати. При цьому якщо ви віддасте мідлу тестувати задачу після сінйор дев - то все буде збалансовано. Мідлу буде цікаво, +- швидкість роботи буде однакова. Це лише приклади і вони мають виключення з правил, звісно ж. Не завжди то саме так працює. Проте - РМ цього всього не рахують. Більше того - ви теж це не рахуєте і просто кривитесь коли бачите таку формулу від керівника.Кривиться скільки завгодно - але користуйтесь інфою правильно. Наявність відсутність того чи іншого ботлнеку - одна з ваших задач то разгрести. І так, косяки РМ чи техліда, ви теж можете згладити врахувавши і цей момент при оцінці потрібної кількості людей та грейдів на тестування. #qa #qanavigator #estimation

Популярний тренд 📈: скажи непопулярну думку й біжи 🏃‍♂️.Бігти не буду, а от сказати 💬 - ізі.📚 жодне навчання в будь-якому форматі не гарантує вам підвищення грейду чи зп 🌟 лідерами не народжуються - ними стають 👨‍💼 ефективний менеджер - це суб'єктивна річ, ним можете бути і ви для когось 🔄 люди не люблять зміни. ніякі. як на старайтесь 🛠 якщо побудувати процеси нормально спочатку їх не треба оптимізувати 📊 метрики можуть бути тільки для вас, їх може ніхто не дивитись більше 🗓 як ви сплануєте і організуєте - так і будуть рухатись ваші процеси 🐢 ви будете рухатись так повільно, як рухається самий повільний член команди 🤝 делегувати не значить перекинути таску на іншого 🎯 но естімейт техніка - це та сама оцінка пальцем в небо/на досвіді ⏳ якщо ви конвертуєте поінти - відмовьтесь від них і робіть оцінку в годинах 📈 не стратегія не працює, бо ваші підходи до її створення погані 🤖 автоматизація була створена для пришвидшення і здешевлення процесу ручного тестування 🚀 якщо в вас можна впровадити або АТДД або автоматизацію - автоматизація пролітає ⬅️ шифт лефт не буде працювати якщо у вас погані /не чіткі вимоги 🤐 конфлікти не завжди треба вирішувати 🎭 маніпуляція і мотивація використовують одні й ті самі методи впливу на людей Що зачепило найбільше? діліться в коментарях 👉#лідерство #менеджмент