Коли буде готово: як не зруйнувати відносини в команді

Мабуть питання «коли буде готово?» найчастіше та найважливіше у нашій галузі. На нього відповідають усі, незалежно від посади чи спеціалізації, але в більшості випадків це все ж таки обов’язок програмістів, бо вони є кінцевими виконавцями завдань.

Трапляється, що відповіді останніх звучать не дуже професійно, а іноді взагалі закінчуються конфліктами. «Буде готово, коли буде готово» — знайома ситуація? Такий підхід певного часу наробив проблем і мені, а декому заважає прямо зараз.

Ця стаття має за мету пояснення причин такої поведінки, що буде корисно для тих, хто питає, наприклад, QA чи PM, та можливі рішення для обох сторін.

Усі ми непогані люди

Уявімо одну з таких ситуацій — ви особисто підійшли до Олеся з питанням, коли він закінчить роботу над функцією пошуку. Через панорамне скло у ваш опенспейс потрапляє ще приємне сонячне світло, а кава, що ви зробили, виявилася незвичайно смачною. Мабуть Олесь мав почуватись так само добре, але його відповідь була неочікувано жорсткою. «Не знаю, сьогодні-завтра», — відповів він. Далі ви питаєте щодо готовності самої форми пошуку та можливі варіанти зменшення ризиків — наприклад, відмовитися від функції автодоповнення в цьому релізі, але Олесь починає жалітися на поганий код і каже, що треба зробити рефакторінг. Ви ідете від Олеся без відповіді та без настрою.

Найдоступніша реакція в такій ситуації — це негативні емоції та висновок, що Олесь некомпетентний і з ним краще не працювати. Не поспішайте з висновками, Олесь може мати схожу думку. Подивимось на ситуацію його очима.

Олесь працює над функцією пошуку вже другий тиждень, хоча планував зробити все за 3 дні. В процесі виявилося, що ваш пошуковий сервіс має суттєві обмеження і потребує допрацювання. Вчора він залишив офіс о 23:15, маючи всі необхідні зміни, а сьогодні вранці виявилося, що він зламав інтеграційні тести. Олесь пам’ятає, що оцінив роботу в 3 дні, цей факт тисне на нього. Тут з’являється Іванка і додає ще. Замість завершення поточної задачі, вона пропонує переключитися та витратити час на пошук альтернативних рішень, технічно — «костилів». Та й навіщо це їй, незрозуміло. Як взагалі спокійно реагувати?

Чи залишилась ваша думка про Олеся без змін, коли ви дізналися, що він почуває?

Ви працюєте з непоганими людьми, але не завжди про це знаєте. Я маю на увазі не тільки особисте знайомство, але й те, що потрібно тримати цей факт у свідомості. Останнє вимагає певної дицсципліни, особливо, коли вас переповнюють емоції.

Це актуально для обох сторін. Олесь чує незручне питання і немає думки, що це потрібно Іванці, наприклад, для проведення важливого демо цього четверга. Іванка отримує неочікувану відповідь і не має думки, що мабуть Олесь знаходиться під напругою. Хтось повинен включити мозок та збагнути, що колега навряд хоче когось образити чи дошкулити, а є більш ґрунтовні причини.

Непогані люди та планування

Ще одна поширена ситуація — це надання оцінки в процесі планування. Уявімо, що декілька тижнів тому ваша команда збиралась на мітингу і одним з питань була оцінка функції пошуку. Виявилося, що завдання може виконати тільки Олесь, бо інші програмісти ще не працювали з тією частиною системи, а отже і оцінювати можуть посередньо. Дивлячись на опис сценаріїв використання та макети, складалося враження, що нова функція відносно проста, але Олесь був менш оптимістичним. Він не проводив аналіз задачі перед мітингом, тому не міг пояснити, в чому проблема. Єдине, що він знав — код пошукового сервіса складний і, якщо доведеться дописувати, то це займе багато часу.

Усі погляди були спрямовані на Олеся, він мав приймати рішення. «Два тижні на програмування», — відповів він. Інші учасники теж не проводили аналіз задачі, але на них це справляло протилежний ефект. «В нас є пошуковий сервіс, нам потрібно додати нову форму, схожа вже є на іншому екрані, де тут два тижні?», — випалила Іванка. Слово за слово, обговорення затягнулося, а настрій у всіх зацікавленних суттєво погіршився. Олесь виглядає непрофесійно, бо не може пояснити складність. З його ж сторони ніхто нічого не розуміє і всі від нього щось хочуть — суцільний стрес. Врешті-решт Олесь здається і погоджується, що зробить за 3 дні, якщо не буде проблем з сервісом. Він відчуває, що це закінчиться погано.

Зараз у вас є достатньо інформації, щоб зрозуміти обидві сторони, але в житті ми граємо одну роль і маємо обмежену точку зору. І цю ситуацію доволі просто покращити, якщо включити мозок та збагнути, що й тут колега навряд хоче когось образити чи дошкулити, і є більш ґрунтовні причини.

Можна навести багато прикладів, але всі вони будуть зводитися до необхідності подивитися на проблему очима опонента. Це мабуть єдина проактивна реакція.

Але як взагалі не допустити таких ситуацій? Для цього потрібно відповісти на інше питання.

Що бентежить програміста?

Нерозуміння як оцінювати

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

Задача незрозуміла

Можливо задача, яку ви хочете оцінити, зрозуміла вам, але не зрозуміла програмісту. Ви розібралися і все виявилося надто простим, та не забувайте, що ваш колега, ймовірно, ще не витрачав час на аналіз цієї задачі, а отже і оцінки прямо зараз не надасть.

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

Спроба все ж таки щось почути прямо зараз, іншими словами тиск, і в першому, і в другому випадках майже завжди закінчується конфліктом.

Прийняття рішення

Оцінка щодо виконання задачі — це прийняття рішення. З рішенням потрібно прийняти й відповідальність. Потрібно побороти сумніви, бути готовим до різних сценаріїв, бути готовим відстоювати своє рішення. Це однозначно вихід з зони комфорту. А вам до вподоби виходити з зони комфорту?

Ризики

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

Чому ви взагалі це питаєте?

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

Розповсюджена ситуація — це конфлікт з QA, котрі планують тестування та надто цікавляться, коли можна буде починати. Правда на вашому боці, та потрібно зважати і на іншу сторону, бо питати значно простіше, ніж відповідати.

Що з цим робити?

Певно, що приділяти увагу. Зазвичай програмісти цікавляться фреймворками, мовами програмування та іншими технічними питаннями. Схожа ситуація і з іншими спеціалістами, котрі фокусують увагу на методологіях розробки, тестуванні тощо. Оцінки та взаємовідносини в цілому, на жаль, не така популярна тема.

Як і усі інші процеси, надання оцінок можливо формалізувати, впроваджувати та поступово покращувати, як на особистому, так і на командному чи корпоративному рівні.

Є ідеї? Наведу свої.

Покращення особистих відносин

Повторюся ще раз — ви працюєте з непоганими людьми. Усвідомлення цього факту — це найважливіший чинник ефективної співпраці. Допомогти в цьому можуть всім знайомі тімбілдінги, поїздки на конференції, природу, заняття спортом тощо. Найбільш дружні і комфортні колективи, в яких мені довелося працювати, постійно проводили час поза роботою. Певен, що у вас так само.

Поширення досвіду

Опишіть процес оцінки в документі.

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

Якщо комусь з колег важко оцінювати задачу — допоможіть. Покажіть, з чого почати, спитайте, як він планує виконувати задачу, які підзадачі він виділив, які є ризики та що з ними робити.

Розбирайте ситуації, коли оцінену задачу виконали за суттєво більший час. Питання «чому?» в такому випадку може звучати осудливо, тому є сенс акцентувати увагу на питанні «як краще?».

Покращення планування

Для того, щоб оцінити задачу, потрібен час, це таке ж завдання як програмування чи тестування. Закладайте відповідний час, і тоді розробка буде більш прогнозованою, а атмосфера менш напруженою.

Щоб проаналізувати деякі завдання, потрібно витратити години, а іноді дні. Це не завжди зрозуміло іншим членам команди та менеджерам, тож програмісти повинні пояснювати, в чому складність і чому це займає суттєвий час. За такого підходу вам нададуть необхідні ресурси, запропонують допомогу та перестануть задавати незручні питання.

Ідеально, коли питання оцінки взагалі не постає поза процесом. Програмісти оцінюють задачі у зручний час і виконують їх за планом, а інші сторони отримують необхідну інформацію та виконують свою роботу.

Покращення розуміння процесу

Важливо, щоб усі члени команди розуміли, яка в них спільна мета, які завдання вони виконують, які ролі є в команді та хто за що відповідає.

Чому програміст повинен надавати оцінку? Бо це його відповідальність за процесом, чи він згоден, що QA оцінять програмування краще?

Чому оцінювати потрібно зараз? Бо це частина вашого циклу розробки. Ви отримали нові бізнес-вимоги і тепер потрібно відповісти, що та коли буде готово, щоб бізнес планував продажі та інші активності.

Чому це потрібно знати QA? Бо відповідальність QA перевірити, що бізнес-вимоги виконані, і це треба зробити в тому ж спринті, інакше роботу програміста ніхто не побачить. Нічого особистого.

Чому це потрібно знати PM чи іншим менеджерам? Бо це їх відповідальність — задовольнити вимоги бізнесу. Можливо вони знайдуть більш прості рішення або запропонують виконувати та впроваджувати функціональність поступово.

Покращення декомпозиції задач

Оцінювати можливо тільки дрібні й прості задачі, бо вони вже багаторазово виконувалися раніше.

Чи зможете ви оцінити функцію пошуку? Чи розумієте, що потрібно буде робити?

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

Потрібен час на аналіз? Покращуйте планування.

Таку функцію пошуку не тільки простіше оцінити, але й виконати у зазначений термін, бо зрозуміло, що потрібно робити.

Впровадження культури пояснення причин

Якщо питання «коли буде готово?» постало поза процесом, то, мабуть, краще починати з причин, так як для програміста питання може бути складним і викликати спротив. Програмістам в свою чергу теж непогано було б пояснювати причини, чому саме «буде через N часу», чому не вийшло зараз та що ви плануєте робити, щоб вийшло. Такий підхід є ключем до взаємовиграшного рішення та позитивних відносин.

Також важливо виконувати аналіз задачі перед плануванням і готуватися до професійного пояснення, в чому складність та чому потрібно більше часу. Розбиратися доведеться в будь-якому разі, але краще робити це ще не погодившись на ті 3 дні з прикладу про функцію пошуку.

Впровадження культури допомоги

Якщо вас непокоїть те, що задача вже повинна бути виконана, а насправді — ні, то не слід питати, коли буде готово. Людина, що виконує завдання, скоріше за все перебуває під напругою, і такі питання будуть лише дратувати.

Спитайте, як допомогти, в чому проблема та що потрібно для її вирішення. Врешті-решт ви дізнаєтеся про стан справ, коли і що буде готово та які є альтернативи, можливо навіть більше ніж очікували, а колега ще й буде вам вдячний.

З чого почати?

Як фанат Стівена Кові, пропоную почати з приватної перемоги, тобто з себе. Принаймні, ви зможете пересвідчитися, чи покращилося ваше розуміння і чи є дієвими запропоновані підходи.

• Пригадайте незручні питання, на які вам довелося відповідати минулого тижня. Чи розумієте ви, чому вони постали? Чи можна було відповісти краще?
• Пригадайте неочікувані відповіді на ваші питання. Чи розумієте ви, чому так сталося? Чи можна було отримати відповідь іншим чином?
• Якщо ви менеджер, спробуйте розібратися, як ваші підлеглі оцінюють задачі, чи є в них на це час та наскільки добре виконується розбиття задачі на більш прості.
• Якщо ви програміст, спробуйте проаналізувати задачі перед тим, як вас за це спитають. Це ще називається заздалегідь. Підготуйте пояснення, що потрібно зробити та чому це займе стільки часу. Беріть до уваги, що пояснення повинно бути зрозумілим не тільки програмістам.
• Якщо ви QA, спробуйте пояснити програмістам особливості вашої роботи та чому потрібно планувати розробку таким чином, щоб нові функції не потрапляли в тестування в останній день ітерації. Зважайте на те, що програмісти зайняті виконанням задач, а відповіді на ваші питання потребують часу.

Якщо ці дії матимуть ефект на особистому рівні, то вам буде зрозуміло, що потрібно поширити серед колег та що робити далі.

Бажаю успіхів!