Зупинення нескінченних технічних дискусій та прийняття рішення

Я завжди стикаюся з людьми, які люблять на віки стукатись найменшими "технічними речами".

Не зрозумійте мене неправильно, я програвач, який любить те, що я роблю, але ви знаєте тип розмови.

• Mac набагато краще, ніж Windows
• Не використовуйте для кожного циклу, використовуйте цикл while
• Не купуйте ПК на базі Intel, придбайте AMD.
• Ми повинні використовувати один контейнер IoC над іншим.

На всі ці "речі" є дійсні плюси і мінуси для обох сторін, і ви ніколи не отримаєте "правильної" відповіді, і людина ніколи не визнає суть. (звичайно, знайдуться деякі, де є відповідь, можливо :).

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

Проблема 1. Деякі люди не люблять програвати. Якщо вони не дзвонять пострілам, вони збираються обговорювати, поки вони не зателефонують до пострілу.

Проблема 2. Ніщо насправді не загрожує, тому дискусії терпляться.

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

Що робити?

1. Зрозумійте, що ні про що не йдеться.

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

3. Киньте монету. Серйозно. Просто виберіть щось і рухайтеся далі. Деякі люди побачать дурість у дискусіях. Тоді деякі люди будуть обговорювати характер кинутої монети. Якщо людей не вдасться задовольнити викиданням монети, у них виникають проблеми з егою та вони повинні дізнатися, що (а) нічого не поставлено на карту і (б) рішення буде змінено через кілька років.

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

Декілька речей, які слід поміркувати:

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

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

Це реальні речі, щоб уникнути двох проблем С.Лотта - те, що деякі люди не люблять втрачати, і що нічого не поставлено на карту. Моя відповідь ставить щось під загрозу, щоб не було дискусій заради ради.

1. Timebox дискусії. - Якщо для того, щоб кожна сторона заявила свою справу, потрібно більше 5 хвилин, то це занадто складно. Для цього ми фактично використовуємо кухонні таймери . Вони працюють чудово, і коштують близько 5 доларів.
2. Вимагають, щоб учасники сперечалися з даними та досвідом.
3. Ми зберігаємо варіанти на столі. Після того, як кожна сторона має свій час, ми витрачаємо ще 5 хвилин на обговорення наслідків кожного підходу. Через 20 хвилин ми виходимо і робимо це (реалізуємо). Якщо це не спрацює, ми підемо з іншим підходом.

Правило просте. Як тільки ви не знаєте, що вибрати - подумайте, що краще для компанії.

Так, вибір Intel v AMD не такий простий. Але що краще для вашої компанії? Наприклад, якщо є людина, яка відповідає за замовлення матеріалів, і це потребує віку, щоб замовити ПК на базі процесора AMD, але на базі Intel можна замовити за хвилину, і вам дійсно все одно, що це буде - просто замовте на базі Intel, тому що це краще для компанії.

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

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

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

Стандартизація - це один підхід

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

"Гей, ці ПК були зрештою марними, давайте спробуємо Маки!"

або

"Я вам це казав! Весна набагато краща, ніж EJB."

І так далі.

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

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

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

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

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

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

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

Один із підходів - шляхом голосування і добре працює в командах меншого розміру.

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

Простий, але демократичний і дозволяє рухатися вперед.

Подібне питання може бути:

Як зупинити релігійні / полум’яні війни на форумах?

Я думаю, що @ S.Lott має рацію у своєму коментарі, якщо єдиним моментом є "обговорення", "відхід" або інше ігнорування, це може бути єдиною відповіддю. Раніше я використовував цю техніку.

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

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

Видовища над мізерними балами витратили величезну кількість моєї зустрічі, і я не хочу більше її чути. : - /

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

Головне, що ми повинні бути зрілими і розуміти, що ми не завжди можемо погодитися один з одним, велика і зріла річ - це вчитися один у одного, чому ми маємо свої позиції, і, можливо, пов'язані з моєю власною запитайте, дізнайтеся, який досвід і чому. Тоді ми можемо скласти власну усвідомлену думку і бути проклятим чи ні.

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

"Я можу не погодитися з тим, що ви говорите, але я захищаю до смерті, ваше право сказати це". -Вольтер, філософ V століття

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

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

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

Спочатку вирішіть загальні проблеми: нам потрібен веб-сервер, сервер додатків, БД тощо.

Для дебатів про те, який БД або сервер використовувати, відкладіть ці пункти для іншої зустрічі.

Під час наступних зустрічей дозвольте обговорити "короткий список" потенційних пропозицій, наприклад, MySQl, MS SQL Server, Postgres тощо.

Дозвольте членам команди висловити свою думку, але попросіть їх підкріпити факти. Продукт X смокче! Не ріже, продукт Y не масштабує! Занадто розпливчастий. І т.д.

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

Якщо вам потрібно збити чіткого переможця або підтвердити підтримку / відсутність функції чи концепції, сміливо знайдіть певний час, щоб зробити POC (Proof of Concept), але зрозумійте, що це зажадає часу, і розробники мають тенденцію до Хочете працювати з тим, з чого вони почали ... Не забудьте перевірити будь-які дорожні блоки / технічні проблеми перед тим, як піти з POC.

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

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

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

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

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

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

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

Хороший фасилітатор зустрічей може полегшити такі види дискусій, не даючи їм вийти з рук.