Що ви повинні зробити, якщо ваш молодший не прийняв вашу пропозицію? [зачинено]

Я очолюю команду з 3-4 молодших розробників. Моя робота - крім написання коду - полягає в забезпеченні нагляду та настанов для юніорів.

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

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

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

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

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

Цей підхід важливий з наступних причин:

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

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

• Ваш код передбачає доступ до виробничої бази даних. Як ми могли це змінити, щоб воно все ще працювало і JUnit було правильно перевірене у відключеному середовищі розробки? (потенційна відповідь: ах! нам слід використовувати ін'єкцію залежності ...)
• Що станеться, якщо зловмисник навмисно надіслав якийсь хитро побудований SQL у вашій онлайн-формі для введення даних? (потенційна відповідь: ах! Мабуть, ми не повинні будувати оператори SQL шляхом об'єднання неперевіреного тексту з мереж)

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

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

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

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

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

• Чи маєте ви повноваження підштовхувати конкретні рішення?
• Яка міра для цієї влади?
• Чи є рішення поганим чи просто іншим?

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

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

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

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

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

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

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

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

Я б запитав, чи ви насправді представляєте свою пропозицію у спосіб, який не поблажливий. Коли ви використовуєте фрази, такі як:

моє рішення значно перевершує їхнє

і

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

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

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

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

Перш за все, чи знаєте ви справжню причину, чому ваш молодший не прийняв вашу пропозицію?

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

Я б запропонував спробувати підійти до своїх юніорів без будь-якої (або маленької) «аури» старшого, спробувати поговорити з ними рівневим рівнем, проявити цікавість до написаного ними коду. Задайте питання, почуйте їх відповіді. Не вимагайте звинувачувального способу, наприклад:

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

натомість запитуйте

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

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

Чи контролюєте ви натиснений доступ до сховища?

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

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

Є деякі обставини, коли правильної відповіді немає (наприклад, налаштування стилю кодування). У цьому випадку спробуйте встановити (або застосувати) політику для всієї компанії, щоб вони зрозуміли, що стиль коду повинен бути орієнтований на відповідність основній кодовій базі даних. Використання вже сформованої настанови щодо стилів (наприклад, посібник зі стилів Microsofts для C #) - найкращий спосіб, особливо для нових розробників у команді.

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

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

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

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

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

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

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

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

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

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

РЕДАКТУВАТИ: переконайтесь, що ваші пропозиції є справжніми та не завуальованими вимогами. Пропозиція - це просто те - пропозиція, яку можна вільно слідувати чи ні. Якщо це вимога, викладіть її як таку.

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

Що стосується спроб змусити молодших розробників робити ті речі, як ви хотіли б їх робити:

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

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

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

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

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

Дайте накази. Живи з наслідками. Вчитися на досвіді. Повага - вулиця двостороння. Ви це демонструєте, а вони ні.