Коли протистояти хорошому керівнику проекту чи начальнику

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

Коли і як (якщо і колись) слід виражати різницю в думках?

Припустимо, ви думаєте, що ваш начальник помилився. У вас є три варіанти

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

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

Ставтесь до нього так само - м'яко і шанобливо, коли висловлюєте опозицію.

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

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

Чи це не приклад старої агресивної чи пасивної помилок?

Класичний третій варіант - це напористість, яка допускає конструктивну критику та ввічливість незгоду.

Не менш важливо - прийняття конструктивної критики (без обов'язкової згоди з нею) та прийняття розумної незгоди (не одержимість змаганням хто - хто - правий - а хто - хто - неправильний).

http://en.wikipedia.org/wiki/Aserserness

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

BTW - «Навики людей» Роберта Болтона - це хороша (і досить дешева) книга для таких речей - навички прослуховування, напористість тощо.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

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

"Як ваш метод / спосіб / архітектура справляється з проблемою x?" Якщо це не так, скажіть щось на кшталт: "Ну як щодо цього робити так, так вирішується проблема x?"

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

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

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

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

Я сподіваюся, що це допомагає.

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

Це не протистояння. Це не вороже. Це не воююче чи зле. Це обговорення різних підходів, витрат та переваг.

Не заходьте, коли палають шість гармат. Просто скажи йому щось, про що ти думав. "Що, якби ми зробили це так?" Хто знає, ви можете його переконати.

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

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

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

Хороша дискусія може закінчитися кількома способами:

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

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

Просто виведи це!

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

Я покладу м'яч у його двір, щоб навчити мене.

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

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

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

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

На мою думку і як я взагалі поводжусь зі своїм начальником:

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

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

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

Удачі.

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

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

Після розмови з ним він може лише:

а) Погоджуюся з вами: проблема вирішена!

б) Відхиліть їх і поясніть, чому: можливо, все-таки ви той, хто помиляється.

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

Моє запитання: коли і як (чи?) Висловити розбіжності в думках.

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

Справжній ключ тут - коли і як.

1-е "Коли": У кожному середовищі різні, але в деяких місцях проводяться щотижневі зустрічі або дискусії на відкритих / круглих столах, де відповідні теми для цього є підняття певних тем. Головне, чого ви не хочете робити, - це зробити так, як ви принижуєте чи оприлюднюєте якийсь особистий аргумент дизайну, який знаходиться між вами та лише 1 або 2 іншими. Люди, яким ви кидаєте виклик, не оцінять те, що їх кидають у виклик і, можливо, навіть бентежать на публіці. У цих ситуаціях спробуйте запланувати зустріч 1 на 1 з відповідними особами, щоб детально розглянути свої думки.

2-е "Як": Якщо ви збираєтеся до старшої людини, переконайтеся, що у вас є всі качки поспіль, підтримуючи свої думки. Ви не можете просто проїхати в офіс для осіб старшого рівня, кажучи: "Усі веб-форми повинні бути припинені, і ми повинні робити MVC!". На запитання "Чому?" і ви кажете: "Ну, це все роблять, і це є у всіх журналах", далеко не піде. Будьте готові до подальшої дискусії та запитайте про обґрунтування своїх думок щодо архітектури, кодування, дизайну, найкращих практик тощо. Якщо у вас є приклади робочого коду для виправдання (тобто невеликий тестовий джгут для підтвердження думки), це може бути допомогти також. Тут важливо - не вступати в битву за его та не дозволити емоціям наростати.

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

Щасти!

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

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

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

1. Один підхід / дизайн може бути просто правильним чи неправильним, як, наприклад, з математики 2 + 2 = 4, а не з п'яти. Якщо це неправильно, вам потрібно придумати правильне рішення якнайшвидше, виходячи з фактичних заперечень.
2. На сьогодні найбільше тем у дизайні системи - це можливі підходи, які не є винятковими. Існують також інші альтернативи, які вибирати залежить від досвіду, аромату, упередженості, загальної картини тощо. Щоб не спостерігати за можливим кращим підходом, зазвичай проводяться презентації та дискусії, коли розробникам рекомендується висловитись та поділитися своєю думкою. Але також майте на увазі, є періоди для обговорень та періоди для впровадження, у спритному програмуванні ці етапи добре визначені.