Можна знайти опис поведінки токсичної людини тут www.webmd.com/...health/signs-toxic-person
Але я дуже сумніваюсь що люди які говорять про «токсичних» працівників, користуються цим поняттям правильно. На мому досвіді такого не було. Власне токсичність тому й використовують коли не можуть нормально поянснити чого ця людина не поже працювати в команді.
Коли біля кулера працівники говорять «він крутий програміст», то можливо не треба цього розшифоровувати. Та коли ви збираєте фідбеки на програміста, ви б захотіли дізнатись що це означає, і чи дійсно «крутий програміст» в понятті колеги співпадає з вашим розумінням.
дякую за комент.
Трохи роз’ясню, якщо це не було очевидно зі статті. Я ОК-ТИ ОК це не про класифікацію а про сприйняття. Тобто це те як я сприймаю себе і як я сприймаю співбесідника. Співбесідник може бути ОК, але якщо я думаю що він НЕ ОК, то діалогу не получиться. Якраз особливість цього методу що вона навпаки заставляє не класифікувати людей, а зрозуміти і змінити своє ставлення до ситуації.
Звісно це не чарівна таблетка, та це непоганий метод для старту.
Мені подобається ваш досвід і те що ви розповіли. Реалії мого досвіду — спілкування в мультинаціональних динамічних командах від 100 людей і більше, жарти та тролінг не працює як клей, тут власне конструктивна комунікація стає на перше місце.
Ідея для джина — супер.
В процесі ) це класна книга, але вимагає часу на читання.
Хоча, я вже почав її рекомендувати.
Дякую
Я не погоджуюсь що узагальнення дозволяють обмінюввтись сенсами швидше. Для різних людей інтроверт це про різні речі. Який сенс передають коли кажуть «він хороший програміст, але інтроверт»? Приблизно такий самий як «вона хороша програмістка, але жінка».
Що це означає? Це добре чи погано? Нам треба дослухатись до інтонації співбесідника і міміки щоб це визначити? Для мене в обох випадках це сигнал до наступних питань, таких як «розкажи приклади, коли з ним/нею були труднощі у спілкуванні?». Та ін
Так, я читав про цю модель. В транзакційному аналізі ігри розглядаються як негативний вид комунікацій. Це завжди підміна ролей. Ефективне спілкування це лише Дорослий-Дорослий і це відсутність ігор.
Трикутник Карпмана дозволяє розширити аналіз ігор в які грають люди, проте я ніде не бачив де на трикутнику Карпмана може відбутись ефективна комунікація. Якщо у вас є такий досвід, буду радий послухати)
Розпізнавати ігри на робочому місці, і вміння їх зупиняти я вважаю одним з головних обов’язків менеджера.
Трикутник Карпмана це вже гра, а це не про конструктивну взаємодію. Зазвичай це стан Я НЕ ОК — ТИ НЕ ОК.
Ну про «боротись» не скажу, але розуміння в якому стані ви перебуваєте зараз дуже допомагає.
Деколи можна просто завершити розмову і перепочити (або не починати розмови взагалі).
Але як я вже писав, вийти з стану Я ОК — ТИ НЕ ОК може допомогти декілька простих запитань — що конкретно людина зробила? що я очікував від людини? що потрібно зробити щоб виправити ситуацію (навчити, пояснити, поставити більш конкретні цілі)?
Я починав з цього, а далі вже книги, курси та ін.
Ви праві, це працює не завжди, інакше в нас були б ідеальні команди без конфліктів, і ніхто б нікого не називав «токсиком», «дурнем» та іншими словами. А ще б в нас не було конфліктів в сім’ї, з чиновниками, менше розлучень, вбивств.
Сорі, захопився.
Тепер тезисно: давати характеристику людині по її поведінці називається проекцією (en.wikipedia.org/.../Psychological_projection), «ти лінивий», «ти дурний», «ти псих», «всі мужики козли» — все це проекції і вони рідко призводять до вирішення проблем.
«ты рачок, твоя простыня из кода не работает»
ось ця фраза — яку вона проблему вирішує? Людина одразу перестає бути «рачком» чи код запрацює?
Я не проти тролінгу і жартів на робочому місці і в невеликих кількостях, але це не інструмент вирішення зачач, крім того це небезпечна стратегія, яка може перерости в пасивну агресію, і тоді втрачають всі.
HW поки не шукаємо, тільки софт.
Я не дуже розумію питання. Як зрозуміти що головний офіс відноситься до центру розробки як до третьосортного? В нас в офісі є люди що керують глобальними командами і суттєво впливають на процес прийняття рішень у випуску продуктів. На рівні з іншими офісами.
Ми орієнтовані на якісний а не на кількісний штат )
Не зовсім. Ми займаємось інтерконектом. Фактично все що описано тут developer.nvidia.com/networking це технології до яких ми причетні.
Зараз ми продовжуємо органічно розвиватись — набирати людей у вже створені команди і розширювати експертизу в нетворкінгу. В майбутньому ми будемо дивитись на можливості а також формувати інші експертизи в Україні — GPU/3D/AI/ML та ін.
Користуюсь Трекболом Logitech
Плюси:
— працює на будь-якій поверхні
— точність
— не треба ковзати по столу
— на одній батарейці АА тримається
Мінуси:
— тільки для правші
— періодично треба чистити (пригадуєте старі мишки з кулькою?)
Також дуже подобається що для того щоб перемістити курсор швидко і на велику відстань швидко треба просто сильніше покрутити кульку
Якщо такі проекти розвиваються (як мінімум підтримуються) — це означає що вони до тепер приносять прибуток, а це означає що вони корисні людям. А великі проекти приносять користь сотням і тисячам користувачів. Порівняйте це з стартапами, які ще не мають жодного користувача, і примарні перспективи. Це по-перше.
По-друге — старі проекти використовують старі технології. Це очевидно. Так само як і архітектура цих проектів була продиктована трендами цих років, коли проект активно розроблявся. На мою думку дуже корисно інженеру заглибитись в ці проекти щоб зрозуміти наслідки тих чи інших рішень, що були прийняті. Це дасть більше користі в майбутньому ніж зробити пару маленьких програмок з нуля. Взагалі робота в саппорті є дуже корисною для всіх, бо вона показує як «геніальні» дизайнерські і архітектурні рішення руйнуються при зустрічі з реальністю.
По-третє — стосовно переписування (не рефакторингу, а переписування) Джоел ще 14 років тому написав статтю www.joelonsoftware.com/...0000000069.html. Жаль що дуже часто програмісти не люблять читати не тільки код а й книги, статті та вчитись на помилках інших.
Я звісно не за те, щоб присв’ячувати життя саппорту, але вважаю цей досвід дуже корисним. Ті інженери що перейшли через це стають більш виваженими у рішеннях і спокійнішими до нових віянь в ІТ. Вони розуміють що таке хороший код, який сапортиться сотнями людей, хороша документація і хороша архітектура.
Наведені вище книги — це інструкції до інструментів. Як і інструменти вони старіють швидко, і список стає неактуальним. Я б теж радив читати такі книги у декілька підходів — спочатку швидко, а потім докладніше і, можливо, перечитувати.
А ось мій список книг, кожна з яких не вчить програмувати, але всі разом формують з людини інженера-програміста. В основному ці книги — класика інженерії та історія становлення IT.
Список для айтішника-початківся
Список для тих хто хоче йти і розвиватись далі
Моя рекомендація до читання цих книг (крім книг про історію) — швидко ознайомитись і з набуттям досвіду повертатись до них за необхідністю.
Саме тому краще узагальнення залишити психологам і психологічним селф-тестам. А самим користуватись описом поведінки і уникати узагальнень. Бо в більшості випадків це перетворюється на булінг.