Як я маю справу з повільним і необережним колегою в колективі? [зачинено]

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

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

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

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

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

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

Відповіді на коментарі:

Якщо він дійсно навмисно вводить в оману компанію, вам слід повідомити про це керівництву.

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

Чи не має ваша компанія ніякої системи відстеження помилок?

Тут фактичної системи відстеження помилок немає. Компанія намагається закінчити проект якнайшвидше і передає його до QA. А потім виправляє помилки, про які повідомляє QA.

Ось чому компанії повинні давати працівникам акції / опціони або якесь право власності. Таким чином ви можете буквально сказати хлопцеві: "Ви коштуєте мені грошового зростання ... чи не хочете ви також заробляти гроші?".

У компанії є опціони акцій, вони дали мені акцію 2500, в основному він також отримав би ще трохи.

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

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

Що QA робить це весь час? Чому вони не звітують / не підтверджують статус проектів?

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

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

Це я би робив:

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

• Запровадьте (у вільний час, якщо потрібно) повідомлення про помилки у вашій програмі, щоб усі помилки надсилалися електронною поштою вашим співробітникам та вашому менеджеру. Якщо помилка викликана його програмою, зробіть її видимою в електронній пошті (помістіть [XYZ APP BUG] у темі електронної пошти чи щось подібне).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В першу чергу:

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

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

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

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

На роботі є низка питань. Майте на увазі, що:

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

Тому, представляючи статус вашого проекту:

1. Не згадуйте іншу людину.
2. Коли повідомляєте про помилки або проблеми з кодом - не розробник. Скажіть "Виклик методу FooBar () повертається 1, коли він повинен повертати 2". Тоді будь-яке питання - це не особиста атака, ви просто говорите про код - не про людей.
3. дотримуйтесь фактів, для яких у вас є докази.
4. Якщо ваш колега стає захисним чи ворожим, задайте питання. "Я не розумію, чому ти вважаєш, що я повинен робити _ "
5. Не забудьте про соціальні висловлювання чи назви. Прикинься, що ти не отримуєш особистої атаки.
6. Засипайте багато сну вночі перед будь-якою статусною зустріччю, так що ви подумки спритні.
7. Документ, документ, документ.
8. Не соромтеся просити цього хлопця допомогти вам у вирішенні якоїсь цікавої проблеми, він може взяти до вас, якщо відчує, що ви його поважаєте. Йдеться про побудову раппорту. (зауважте, це не висмоктування - це щось інше)
9. Будьте готові виїхати, якщо вам доведеться, щоб таким чином не стати нужденним або емоційно захопленим. Це допоможе зберегти голову на нарадах.

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

Це не є здоровим і не можна очікувати від колег, якщо ви не отримаєте компенсацію до того, що зможете зняти роки за неминуче вигорання. (Щось на кшталт> 10% власності в компанії або вище $ 200ка на рік). Підтримка досвіду, щоб досягти того, щоб він міг розвиватися дуже швидко, вимагає часу. Частина вашого часу повинна бути присвячена розвитку досвіду.

"Проект c / c ++ - це головне додаток, яке виконує всю функціональність. Мій python надсилає на нього запит користувача та відображає відповідь від нього користувачеві. Можливо, він не любить це робити".

Python - більш гнучка мова, ніж C / C ++. Його додаток, схоже, містить всю функціональність; ваш додаток лише інтерфейс користувача. Швидше за все, це не рівні за складністю. Він може не швидко виробляти код; але якісне кодування набагато краще, ніж кількісне кодування. Ви дуже добре можете мати нереальні очікування щодо того, наскільки швидко він може кодувати години, які він бажає / очікує працювати (як правило, ~ 40 годин на тиждень; і пам’ятайте, якщо він там був роками, він, ймовірно, накопичив інші завдання, як управління іншими людьми або допоможе підтримувати старше проекти, які займають значну частину робочого тижня).

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

Тоді ви можете написати автоматичний тестовий набір для його виклику системи, яка відповідає узгодженим стандартам. Наприклад, тест, ніж Foo (1,2,3), дає відповідь "Bar 4 5 6". Це може допомогти йому визначити помилки та швидкість його розвитку (і не потрібно возитися зі своїм кодом). Як тільки ці речі будуть виконані, ви зможете перейти до іншого проекту / завдання (наприклад, допомогти йому з частинами C / C ++).

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

У цій ситуації є кілька міркувань, які потрібно врахувати.

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

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

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

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

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

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

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

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

Мені це здається, що тут недостатнє управління проектами. Вам потрібно: а) відслідковувати помилки, які впливають на вас, і б) слідкувати за обговореннями в письмовій формі.

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

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

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

Приступайте до своєї роботи. Документуйте будь-які проблеми, які виникають із помилкою в його додатку. І тоді ПОДІЙТЕ ДОМА! Мені все одно, ти сонний чи ні. Знайдіть друзів, яких варто мати.

Я щойно прочитав "Чистий кодер" від Р. Р. Мартіна (дядько Боб). Основна суть книги полягає в тому, що програмісти взагалі не мають великої поваги, оскільки вони не ведуть себе професійно . Це означає, що вони не ефективно спілкуються з керівництвом про стан проекту.

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

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

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

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

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

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

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

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

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

Відповідь Пата була чудовою. Я згоден на 100%. Не ходіть пробиратися на зустріч з начальником. Або візьміть його з колегою між 4 очима або зробіть це з усіма вами. Але пропозиція Пата зосередитись на питаннях з кодом, а не на людях - це правильний шлях.

Btw, 40h / тиждень досить чувак. Вам потрібно підтримувати мотивацію на високому рівні!

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

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

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

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