воскресенье, 25 марта 2018 г.

Топ 5 проблем у роботі команди від Катерини Несмелової — Full Advanced Level ISTQB certified professional




Катерина протягом тривалого часу працювала в Україні та Новій Зеландії. Вона – QA з понад десятьма роками досвіду в ІТ та сертифікована Full Advanced ISTQB. Одним із напрямів її роботи є покращення процесів тестування в командах. Тож ми запитали в неї, які ключові проблеми трапляються в роботі команди та як їх можна уникнути чи мінімізувати.

Найперша й найголовніша проблема в тому, що люди не вміють спілкуватися. Я проаналізувала матеріали декількох конференцій та мітапів, аби зрозуміти, що ж нам заважає й що необхідно змінити. Так з’ясувалося, що найчастіше – це проблеми спілкування. Не нестача певних технічних знань, не те, що люди не знають мови програмування тощо, а саме спілкування.

Непорозуміння, невміння домовлятися з девелоперами, із замовниками, між собою спричинюють серйозні проблеми в командах. На жаль, у нас це відбувається скрізь. Це специфіка не тільки ІТ-сфери, а загальна проблема будь-якої спільноти, будь-якої команди. Це пов’язано з дуже багатьма речами. Одна з найважливіших – це відсутність довіри між членами команди. Тобто найбільші проблеми в спілкуванні трапляються, коли люди одне одному не довіряють і їм потрібно якось себе захищати. Тоді затягується процес, збільшуються об’єми документації та бюрократія. Численні ж дослідження та курси для менеджерів доводять: коли в колективі високий ступінь довіри, працювати набагато краще. Процеси забирають менше часу.

Друга дуже серйозна проблема (і вона не технічна, знову-таки) – люди бояться робити помилки. Їх жахає те, які наслідки для них можуть мати ці помилки. Деякі люди бояться розповідати про свої проблеми команді або керівникові та намагаються все вирішити самотужки. Це призводить до того, що проблеми лишаються прихованими майже до точки дедлайна. А коли вони таки виринають на поверхню, то щось вдіяти вже важко.

Саме тому, коли в команді високий ступінь довіри, люди не бояться помилятися та відповідати за свої помилки. Відтак гарному менеджеру в цій команді лишається тільки мінімізувати наслідки цих помилок. У мене є дуже гарний приклад, як саме це працює в нашій компанії. Коли я тільки перейшла в PricewaterhouseCoopers (PwC), у нас був дуже специфічний керівник відділу: для нього завжди було дві точки зору – його та неправильна. І хоч загалом людина була непогана, але дуже вперта. Ступінь довіри в команді був не надто високий, а от people turn over якраз навпаки – люди йшли з команди часто. Після зміни начальства нас зібрали і сказали: «Ми трансформуємося, наше завдання – трансформувати бізнес. Але ми не можемо трансформувати бізнес, не трансформувавши водночас себе. А щоби трансформувати себе, ми маємо вчитися, ми повинні помилятися. Інакше нічого не вийде».

Третя проблема – невміння давати фідбек. Коли ти даєш фідбек, то найперше, що ти повинен розуміти, – яка мета цього фідбеку. Мета фідбеку – це підтримати «правильну» поведінку чи змінити «неправильну».

На жаль, люди дуже рідко надають фідбек на «правильну» поведінку та на «хороші вчинки». Якщо хтось щось зробив добре, то його треба похвалити, треба сказати «ти дуже добре це зробив, дякую, це мені допомогло», можливо, навіть написати листа вдячності. Однак (незрозуміло чому) у нас так не заведено. Якщо ти робиш щось добре, то це просто сприймається як належне. Але коли ти десь схибиш, тобі скажуть все, що про тебе думають. Тоді в людини виникає думка: «Ага, я, виходить, нічого гарного не роблю, я тільки помиляюся, я поганий». Тому, по-перше, фідбек мусить мати коригувальний вплив. Коли ти даєш коригувальний фідбек, треба розуміти, що людина не є поганою. Можливо, щось було зроблено не так, але людина не погана сама по собі. Це як із дітьми: коли дитина вчинить погано, то треба пояснити, що погана не вона, а лише її вчинок. Усі хороші люди можуть помилитися і зробити щось не дуже правильне. Але разом можна виправити це.

Про фідбеки дуже гарно розповідається на manager-tolls.com. Там є хороші безплатні подкасти про стосунки, про те, як їх налагоджувати. Я дуже раджу всім послухати про фідбеки. Там йдеться про те, як їх правильно структурувати та давати. Дуже гарна штука, яка дійсно працює.

З усього вищезгаданого випливає четверта проблема – невміння людей пояснити свою точку зору. Один із прикладів – це різниця контекстів: якщо ти зараз у певному контексті, то це не означає, що всі автоматично мають розуміти цей контекст. Саме тому, коли ти починаєш щось пояснювати (особливо коли ти захоплюєшся), треба обов’язково перевіряти, чи співрозмовники тебе зрозуміли. Треба не забувати наводити приклади.

Ще один дуже важливий аспект цієї проблеми – це неефективні мітинги, неефективні зустрічі. Знову нетехнічна проблема. Я впевнена, що будь-яку технічну проблему можна розв’язати, коли ти працюєш разом із командою: чи то написання автотестів, чи розробка якоїсь дуже хитрої стратегії тестування… – немає жодної різниці. Коли проблему вирішує команда, це вже не проблема, а лише невеличкий технічний челендж.

Що ж до неефективних мітингів – це дуже важка річ, яка з’їдає надто багато часу. Люди, коли там сидять, не завжди розуміють, що вони там роблять. Але чомусь вважається, якщо вони були на тому мітингу, з усім були згодні та не ставили жодних питань, то вони все зрозуміли і все буде добре. Ні.

На тому ж manager-tolls.com є гарна добірка подкастів про ефективні мітинги. Я у своїй компанії нещодавно робила невеличкий тренінг про ефективність мітингів. Там я проводила експеримент про те, що на мітингах треба слухати й аналізувати. Найперше я розбила групу на 4 підгрупи:

Першій групі було поставлено просте питання. В одного з членів команди були ручка та аркуш паперу, куди він міг записувати. У другої групи допоміжних матеріалів не було. Ми обговорювали питання, що вимагало запам’ятовування деталей. Ми провели опитування: інтервʼюери мали розповісти мені те, що їм розповіли їхні партнери. Звісно, ті, хто записував, розповіли більше, ніж ті, хто не записував.

Але далі експеримент був ще цікавішим. Це інші дві групи. Третій групі дозволили записувати чи не записувати – за бажанням інтервʼюера. У четвертій групі цій людині дозволено було гортати FB чи телефон під час питань. Запитання були дуже прості. Типу «Що позавчора ви їли на вечерю?», «Де ви провели вихідні?» тощо. У тих, хто не відволікався на телефон, середній відгук був 5-10 секунд. Але в тих, хто відволікався, відгук був майже 30-40 секунд. Лише порівняйте – 5 секунд і 30 секунд!

Це пов’язано з тим, як працює наш мозок. Це називається behavior economics. У нашого мозку дуже мало ресурсу й коли ти його витрачаєш на різні дрібниці (… як пам’ять процесора чи ЦПУ), то в тебе залишається менше ресурсу на обробку важливих задач. Тож коли ти відволікаєшся, аби відповісти на мейл, почитати FB і т. ін, то уваги й ресурсів твого «процесора» не вистачає на важливу задачу. Відтак дуже важливо, щоби на мітингах не було телефонів, а лептопи були тільки для нотаток. І тут важливо зазначити: краще мати на лептопі програмку скетчінгу, щоби писати прямо на екрані як на папері. Якщо ж у лептопі немає такої крутої опції, то звичайний аркуш паперу завжди згодиться. Адже цікаве свідчення: коли ми записуємо інформацію, ми її запам’ятовуємо краще, бо в нас працює інший відділ мозку.

П’ята проблема так само належить до так званих софт скілс. Вона теж пов’язана з контекстом, але трохи в іншому сенсі. Часто люди намагаються робити все так, як раніше, і не беруть до уваги певний локальний контекст: навички конкретної команди, як побудовано спілкування з девелоперами, бізнес-аналітиками, замовником, з ким завгодно… які є доступні технології, і найголовніше – якою є мета.

Порівняймо: сьогодні ви розробляєте веб-сайт для того, щоби випустити якийсь новий вид супер-ламп і їх треба швидко продати. А назавтра ви, наприклад, розробляєте медичне програмне забезпечення, яке буде відповідати за операцію на серці… Мета та підходи будуть різними. Це головне. Коли ти починаєш працювати, треба розуміти, яка в тебе мета, та її постійно перевіряти: чи вона не змінилася, чи ви працюєте так, аби її досягти. Це, знов-таки, стосується не лише програмістів чи тестувальників. Це застосовно взагалі до всього. Треба чітко обговорювати й розуміти цілі: важливо, аби вони були спільними. Бо в команді дуже часто буває таке, що в усіх вони різні. Хтось із девелоперів прийшов вивчити нові підходи до програмування, хтось прийшов відсидіти свої 8 годин та щось за це отримати… А мета має бути одна – зробити класний продукт, який буде допомагати людям.

Коли в тебе є мета, ти і працюєш краще, бо розумієш, чого тобі треба досягти. Ти ліпше розумієш, як тобі співпрацювати з іншими. Ти можеш чітко пояснити, що тобі потрібно від цих інших. Як бачимо, усе переплітається: якщо у вас усіх одна мета, вам простіше працювати в команді, ви довіряєте одне одному, ваші мітинги стають ефективними, ви в одному контексті. Тож виходить, що все починається з визначення спільної мети. А від неї вже залежить, як працювати над рештою складників. Мету я невипадково лишила наостанок, адже треба було до цього дійти. Як говорила моя вчителька англійської: the last but not the least. Тобто остання лише в списку, але не на останньому місці.


Редактор: Пірогова Юлія
Інтерв' ювер: Марина Шевченко