Come work in Estonia – the most advanced digital society. Many Ukrainians already know that Estonia is affordable – become one of them and check out the jobs available!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ризики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Багато говорять про оцінки в процесі розробки. І вони завжди є проблемою. Майже завжди провалюються (якщо там ніхто на 2 не помножив). І в результаті займають час та ресурси, без наближення до результату. Тобто граючись з оцінками, ми просто затягуємо час. Може нафіг їх ці оцінки?

ronjeffries.com/…​the-noestimates-movement

В більшості випадків, достатньо мати зрозумілий roadmap та розуміння де ми зараз і що конкретно є сенс робити саме зараз.

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

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

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

розгорнете думку?
що означає в наших умовах і в чому проблема маштабування?(на вашу думку)

Все стороны должны отдавать себе отчет, что оценка это тоже работа. И она требует какого-то адекватного времени, командных усилий, техник итд итп. Поэтому все попытки оценить задачу «за 15 минут» должны пресекаться как безответственные. Разумеется, шаблонные, понятные вещи могут и не требовать много времени для оценки, но это уже опыт в конкретном проекте.

Все правильно про декомпозицію і підходи до оцінювання сказано, але це не применшує пекельності питання «Коли буде готово». Коли все йде за планом і без проблем, питання «Коли буде готово» вибішує не менше: тобі імейл загубився чи мізки відбило? було сказано «в середу», буде в середу.

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

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

Дякую за відгук.

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

Цікаво почути відповіді менеджера з вашого прикладу в такій розмові.

«Дивись, щоб надати відносно точну оцінку(яка має сенс) мені потрібно 4 години часу, потрібно подивитись компонент А та компонент С, є ризики що ми їх зачіпаємо своїми змінами, а ще спитати QA коли вони перевірять. Зараз я займаюсь більш пріорітетним завданням і мені потрібен цей час щоб його виконати, чому нам потрібна ця оцінка саме зараз?»

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

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

Щодо самої риторики то я повністю згоден, саме тому наголошую що слід питати «як краще», «що потрібно», «що ми можемо зробити» і т.д.

Покращення планування...Покращення розуміння процесу...
Все гут ... а як щодо покращення взаєморозуміння і комунікації взагалі? Ви ніколи не чули такий відмаз: «Яке питання, така і відповідь» ?
Я до того, що питання (і естімейти) мають бути максимально конкретні. Питання у формі «коли буде готово?» має право прозвучати тільки тоді коли манагер 100% впевнений, що девелопер його правильно розуміє: шо саме готове? версія для тестування командою QA, версія з уже пофіксаними багами, демо-версія для замовника, версія показати клієнту замовника і т.д. «Єжу панятно» , шо талановиті баги вилазять і через роки, і як на мене, саме цей іжак може викликати не зовсім адекватну реакцію программера у відповідях на такого сорту питання.
Олесь працює над функцією пошуку вже другу неділю

:) схоже Олесь зовсім загнався і працює по вихідним...

Чудова стаття, дякую!
Але Олесь і справді виглядає некомпетентним і непрофесійним джуном. Ні менеджеру, ні QA не прочитати його думки стосовно складностей задачі. І якщо він їх замовчує і погоджується на «3 дні» (хоча можливо лише стільки треба розбиратись з API для оцінки), і подібна поведінка є систематичною, тоді є проблеми саме з цим розробником, а не у підході.

Для подібних задач можна використовувати двох ступеневу оцінку: перша — для аналізу чи побудови proof-of-concept, друга — безпосередньо техн опис, декомпозиція і оцінка. Перша ступінь також виявляє ризики, як от поганий код API чи інші складнощі, про які Олесь мав повідомити, але не зробив це. У даному випадку проблему цілком можливо вирішити невеликим тренінгом і постановкою чіткого процесу для подібних випадків.

Скорее, неопытным джуном, которого легко продавить. Опытный человек предложил бы, если их не устраивает две недели, походить, поискать того, кто сделает за три дня.

Плюс опытный бы еще и сказал — «что значит когда готово? в таске было обещано тогда-то, запротоколировано. что-то поменялось?»

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

Саша, у тебя менеджер некомпетентный мудак в первую очередь. Картина маслом: единственный человек знакомый с системой поиска говорит 2 недели, рядом джун говорит 3 дня. После такого расхождения все маркеры проблемы на лицо и дать возможность команде продавить исполнителя на срок в 3 раза меньше заявленного — найти себе проблем просто сходу. А так отличная статья — одобрям-с!

Згоден.

Поясненням може бути опис перелік підзадач з оцінкою часу виконання кожної.

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

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

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

Возможно мне показалось, но наверное вы не заметили абзац начинавшийся с «Усі погляди були спрямовані на Олеся, він мав приймати рішення. „Два тижні на програмування“, — відповів він...».
Хорошо, когда, в команде принято заранее планировать задачи, и правильно налажены процессы, но как быть когда, например, за 2 недели до релиза новой версии продукта и к тебе приходят с просьбой описанной в этой статье?

Конечно заметил, что является верным с точки зрения процессов. Хуже если бы команда взялась без анализа дружно играть в покер, и продавила бы бедного Лесика пытаться всё сделать за три дня.

Заметил еще одно условие:

Він не проводив аналіз задачі перед мітингом
Спрашивается почему? Если он джун, здесь понятно, и нужно спрашивать с его наставника. Но по условиям только он может сделать, а значит наш Олесь как минимум миддл/сениор. И вот здесь уже начинаются вопросы, почему он так легко продавился под наездами Иванки.

Я предвидел ваш вопрос о прогибе. Поэтому и задал в предыдущем комментарии ситуацию и вопрос, который вы, кстати, оставили без ответа.
Заранее хочу уточнить, что я не ради выпендрёжа тут пишу. Меня действительно занимает этот вопрос, хотелось бы в нем глубже разобраться.

Хорошо, когда, в команде принято заранее планировать задачи, и правильно налажены процессы, но как быть когда, например, за 2 недели до релиза новой версии продукта и к тебе приходят с просьбой описанной в этой статье?
Your lack of planning is not my emergency.

Если за две недели до релиза появляется задача, которая может потребовать 2+ недели и имеет определённые риски — это вводные для ПМа, с которыми он уже должен работать, со своим отделом маркетинга или клиентом. Это не проблема разработчика.

Если же с такой постановкой приходят к разработчику, он просто обязан трезво сообщить «насколько всё плохо» и ни в коем случае не прогибаться, тихо соглашаясь «ну ладно, три дня». Прозрачность — это всё. Если же команда продолжит на него давить, «да ладно, что там три дня делать», «у нас релиз подгорает а нам еще QA надо успеть и бета-тестирование», выйти в конструктивное поле и предложить попробовать разрешить риски в течение какого-то ограниченного времени и затем обновить оценку. Вся информация от разработчика должна прозрачно поступать всем заинтересованным лицам.

Менеджер может принять разные решения, в зависимости от степени важности проблемы или фичи, которую нужно сделать. Например, перенести её на след спринт, отложить, запросить решение у клиента и т.д. Если нужно кровь из носу, обеспечить наилучшую среду для разработчика, закупить печеньки и помогать всем чем нужно, и дать понять что любой результат или даже его отсутствие — это тоже результат, с которым дальше можно работать.

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

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

Умно! Спасибо)

Отличная статья, спасибо. И радостно, что я не один являюсь фанатом Стивена Кови ))

Все так и происходит, почти всегда.
Шикарная и полезная статья, спасибо!

Дуже гарно написано!
Дякую!

Все би нічого, але наскільки я пригадую українську мову — то там «не» з дієсловами пишеться окремо :)

Подписаться на комментарии