Мій колега хороший хлопець, але його виступ є підрозділом. Чи я скажу своєму начальникові? [зачинено]

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

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

Зараз я не претендую на найкращий програміст у світі. Я працюю з багатьма дуже розумними людьми, які краще розробників, ніж я. Однак я дуже намагаюся написати код, який є простим, наскільки це може бути і надійним. Я перевіряю свої чеки. Якщо я бачу, що мій код стає безладним і важко працювати з ним рано, я його змінюю. Я провів кілька розмов зі своїм колегою, намагаючись допомогти йому написати кращий код. Це трохи хитро, тому що: а) він має 20-річний досвід роботи в цій галузі, а у мене лише 5, і б) його найняли як так званого "експерта з UX", а інші розглядають його як досвідченого.

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

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

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

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

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

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

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

З точки зору менеджменту, існує 3 поширених способи поводження з працівниками у цій ситуації:

1. Взяти під контроль свої слабкі сторони
2. Грайте на свої сили
3. Позбавтеся від них (не дуже ваш вибір)

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

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

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

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

Грайте на свої сили

Ей, шефе, я працюю з кодом для проекту x, і це чудово. Код, з іншого боку, може використати неабияку роботу. Я думаю, що проект буде краще, якби [ux guy] зміг зосередитись на UX, тоді як я роблю рефакторинг, щоб перевести його у стабільніший стан. Після того, як UX надійний, проект b, ймовірно, міг би використовувати його сенсацію Midas.

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

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

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

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

Я був би дуже обережний з кількох причин:

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

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

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

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

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

Якщо ви працюєте більше, ніж 50 годин на тиждень над будь-яким проектом, то це щось серйозно не так, і ви ставитесь до себе, не звертаючи про це прем'єр-міністра або не виходячи з нього. Я твердий прихильник роботи СМОТРІШЕ НЕ ТРУДНЕ.

Працюйте розумним 50, і якщо проект не виходить, то НЕ ВАША ВАЛЬНА. Якщо це не вдасться через його некомпетентність, і вони звинувачують вас, то, мабуть, це не середовище, над яким ви хотіли б працювати.

Так багато моїх друзів працюють МНОГО протягом типових 40 / тиждень над некерованим проектом, тому що вони бояться невдач, коли не усвідомлюють, наскільки мало невдачі АБО успіх безпосередньо впливає на всю вашу кар’єру.

Більше 80% проектів провалюються, в цьому немає сорому.

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

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

І сподіваюся, що вас не найняли на посаду його няні. Удачі.

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

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

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

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

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

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

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

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

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

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