Làm cách nào để quản lý một nhà phát triển có kỹ năng giao tiếp kém


52

Tôi quản lý một nhóm nhỏ các nhà phát triển trên một ứng dụng nằm ở giữa vòng đời của nó, trong một công ty lớn. Thật không may, điều này có nghĩa là thường có sự phân chia 30/70 nhiệm vụ Lập trình cho "công việc kỹ thuật khác". Công việc này bao gồm:

  • Làm việc với các nhóm DBA / Unix / Network / Loadbalancer trong các nhiệm vụ khác nhau
  • Đặt và quản lý đơn đặt hàng cho phần cứng hoặc cơ sở hạ tầng ở các khu vực khác nhau
  • Chạy thử nghiệm chưa được di chuyển sang CI
  • Phân tích
  • Hỗ trợ / Điều tra

Thật công bằng khi nói rằng tất cả các Nhà phát triển sẽ thích viết mã hơn là thực hiện các nhiệm vụ trần tục hơn này, vì vậy tôi cố gắng thực hiện các công việc lập trình thú vị đồng đều giữa các nhóm.

Hầu hết các nhóm được thuê bởi vì, mặc dù họ có thể không có kỹ năng lập trình ưu tú để viết trình biên dịch / công cụ trò chơi / hệ thống giao dịch cao tần của riêng họ, v.v., họ là những người giao tiếp tốt, "có thể hoàn thành công việc", làm việc với các nhóm khác , và phần nào điều hướng bộ máy quan liêu phức tạp ở đây. Họ là những nhà phát triển giỏi, nhưng họ cũng là những nhân viên kỹ thuật giỏi toàn diện.

Tuy nhiên, một thành viên của nhóm có thể có kỹ năng mã hóa trên trung bình, nhưng kỹ năng giao tiếp dưới trung bình. Theo truyền thống, Trình quản lý phát triển trước đó có xu hướng giao cho anh ta các nhiệm vụ Lập trình chứ không phải các nhiệm vụ trần tục hơn được liệt kê ở trên. Tuy nhiên, tôi không cảm thấy rằng điều này là công bằng với phần còn lại của nhóm, những người đã thể hiện năng khiếu phát triển một kỹ năng toàn diện thường được yêu cầu trong một bộ phận CNTT doanh nghiệp lớn.

Tôi nên làm gì trong tình huống này? Nếu tôi tiếp tục giao cho anh ta nhiều công việc lập trình hơn, tôi biết rằng nó sẽ được thực hiện nhanh hơn (và ngược lại, tôi sẽ mong anh ta hoàn thành công việc khác chậm hơn). Nhưng nó đi ngược lại các nguyên tắc của tôi và thúc đẩy ý tưởng rằng bạn có thể tự tạo ra một "ngách thoải mái" cho riêng mình chỉ bằng cách làm xấu những nhiệm vụ bạn không thích.

Tôi muốn làm rõ rằng tôi không cố gắng giải quyết vấn đề này do mối hận thù, hoặc tôi có một "con chip trên vai" như đã đề cập. Tôi đang tìm kiếm lời khuyên về cách giữ cho một đội ngũ hoàn hảo, hạnh phúc và có động lực. Bằng cách quan sát sự đa dạng của câu trả lời cho câu hỏi này, có vẻ như có rất nhiều ý kiến ​​khác nhau về cách đạt được điều này.


15
Bạn có biết tất cả mọi người trong đội ngũ nhân viên của bạn thích lập trình hơn các nhiệm vụ khác không? Tôi biết tại một công ty tôi từng làm việc cho chúng tôi có một số ứng dụng ưa thích gỡ lỗi trong khi những người khác thích viết mã mới. Sau đó, một số ưu tiên làm việc trên các ứng dụng web của chúng tôi trong khi những người khác thích làm việc trên hệ thống cũ của chúng tôi.
lập trình viên

12
Làm thế nào anh ấy thể hiện kỹ năng giao tiếp kém? Bởi không phù hợp với khuôn của bạn?
James

5
@EvanPlaice Một lần nữa, cuộc tấn công "vấn đề cá nhân" là gì? Tôi đã nói trong câu hỏi "Thật công bằng khi nói rằng các Nhà phát triển sẽ thích mã hóa hơn". Có lẽ câu này chưa đủ rõ ràng và đưa ra nghi ngờ vì vậy hãy để tôi làm rõ - tôi đã nói chuyện riêng với các nhà phát triển và họ đã nói với tôi rằng họ thích làm việc với các nhiệm vụ lập trình hơn các nhiệm vụ khác. Nếu đây không phải là trường hợp, tôi thực sự không cần phải hỏi câu hỏi này.
djcredo

2
@djcredo Tôi không có ý đó là một cuộc tấn công. Tôi đang nói, tôi nghĩ bạn đang hỏi sai câu hỏi. Tìm cách làm cho mọi thứ trở nên bình đẳng hơn theo tiêu chuẩn cá nhân của bạn về một nhóm 'lý tưởng' là áp đặt ý chí của bạn lên nhóm. Mọi người, đặc biệt là những lập trình viên tài năng (đọc ý chí mạnh mẽ) không thích bị đùa giỡn. Nếu, như bạn nói, bạn đang làm việc với những người có kỹ năng / tài năng thì cách tiếp cận từ trên xuống có thể gây tác dụng ngược. Thay vì quyết định cho nhóm tại sao không hỏi họ trực tiếp những gì cần thay đổi để cho phép giao tiếp giữa các nhóm tốt hơn.
Evan Plaice

6
Tại sao "khắc ra một ngách cho chính mình" là một điều xấu? Bạn có muốn bác sĩ phẫu thuật thần kinh giỏi nhất bạn có thể lấy ra khối u não và bác sĩ tim mạch giỏi nhất bạn có thể tìm cách sửa động mạch chủ mở rộng của bạn, hoặc bạn muốn cùng một người đàn ông ổn trong cả hai lĩnh vực nhưng không xuất sắc trong cả hai việc bạn?
GordonM

Câu trả lời:


77

Có vẻ như bạn đang nỗ lực quá nhiều để có những cá nhân tròn trịa và không đủ nỗ lực để có một đội ngũ tròn trịa .

Không có gì sai khi giỏi một thứ gì đó - thực tế, đó có lẽ là lý do tại sao anh ta được thuê! Bạn nên biết ơn khi có một người giỏi lập trình để bắt đầu.

Bạn đã nói:

... nó đi ngược lại các nguyên tắc của tôi và thúc đẩy ý tưởng rằng bạn có thể tự tạo ra một "ngách thoải mái" cho riêng mình chỉ bằng cách làm xấu những nhiệm vụ bạn không thích.

Nếu anh ta là một lập trình viên tầm thường, thì tôi đồng ý. Nhưng bạn đã không nói như vậy. Bạn nói anh ấy là một lập trình viên giỏi. Anh ấy không tệ trong các nhiệm vụ khác để thoát khỏi chúng - anh ấy chỉ tập trung nỗ lực để trở thành một lập trình viên giỏi hơn. Chẳng có vấn đề gì với việc đấy cả.

Là người quản lý, công việc của bạn không phải là đảm bảo rằng tất cả mọi người đều "tròn trịa". Đó là công việc của bạn để đảm bảo rằng s *** được thực hiện. Và bạn không làm điều đó. Trên thực tế, bạn đang đưa ra quyết định ngăn mọi thứ hoàn thành.

Dù bạn có vấn đề gì, bạn cần phải vượt qua nó - bạn đang làm cho nhóm của bạn kém năng suất hơn.


22
Vì vậy, nếu lập trình viên kiểm lâm đơn độc bị xe buýt đâm vào, bạn nên chắc chắn rằng kỹ năng giao tiếp của anh ta đủ tốt để ghi lại những gì anh ta đang làm và nơi anh ta làm trong dự án.
lập trình viên

8
@JasonHolland, có một sự khác biệt giữa "Tốt" và "Đủ tốt." Miễn là anh ấy đủ tốt, không có lý do gì để đưa ra vấn đề. Các op đang nghiêm túc xem xét làm tổn thương năng suất của đội của anh ta vì anh ta không nghĩ rằng nó "công bằng". (Nhắc lại lần nữa, ai nói thế giới là công bằng?)
riwalk

14
@JasonHolland, op cũng nói: "Nếu tôi tiếp tục giao cho anh ta nhiều công việc lập trình hơn, tôi biết rằng nó sẽ được thực hiện nhanh hơn ..." Điều đó cho tôi biết rằng anh chàng đó cần phải lập trình. Các op có một con chip trên vai, và đó là vấn đề thực sự ở đây.
riwalk

10
Không có con chip trên vai - Tôi chỉ đơn giản là xin một lời khuyên quản lý trong một lĩnh vực mà tôi hiện đang yếu. Tôi đoán tôi đang cố gắng phấn đấu để công bằng để thúc đẩy tinh thần đồng đội trong thời gian dài, ngay cả khi điều này có nghĩa là hy sinh một số của tiềm năng giao hàng ngắn hạn. Bạn đưa ra một điểm tuyệt vời rằng đầu tư để trở thành một lập trình viên xuất sắc, anh ta nên được khen thưởng cho những nỗ lực của mình, vì vậy tôi đã chấp nhận câu trả lời này.
djcredo

10
@ Stargazer712, "op có một con chip trên vai và đó là vấn đề thực sự ở đây." Điều đó có thể đúng nhưng nhìn từ góc độ của các lập trình viên "trung bình" đang được đưa vào các nhiệm vụ không lập trình vì một anh chàng có kỹ năng lập trình "trên trung bình". Tôi sẽ lập luận rằng người quản lý này không làm công việc phát triển chuyên môn của mình cho những người khác. Có lẽ "trên trung bình" có nhiều kỹ năng hơn bởi vì anh ta lập trình nhiều hơn? Có thể các lập trình viên "trung bình" khác sẽ trở thành "trên trung bình" nếu được giao nhiều công việc lập trình hơn, các dự án trong tương lai sẽ hoàn thành nhanh hơn.
lập trình viên

39

Bạn đang cảm thấy hơi nóng ở đây trong các câu trả lời khác cho quyết định "làm điều gì đó" về anh chàng này, nhưng tôi hoàn toàn hiểu những gì bạn đang nói. Nếu các thành viên khác trong nhóm "tất cả đều thích mã hóa, hơn là thực hiện những nhiệm vụ trần tục hơn này" thì họ sẽ cảm thấy khó chịu khi bạn thưởng cho hiệu suất kém của người giao tiếp kém bằng cách giao cho anh ta những nhiệm vụ mà mọi người muốn.

Hãy tưởng tượng bạn là một trong những "người giao tiếp tốt" trong nhóm, những kỹ năng của họ có thể so sánh với nhà phát triển trong câu hỏi. Bạn xử lý các cuộc gọi, làm việc với các nhân viên không phải là IT khác, những người hầu như không biết chuột từ bàn phím, viết kế hoạch cho người dùng đăng xuất và hơn thế nữa, tất cả chỉ vì sếp của bạn nói phải làm điều đó. Trong khi đó, nhà phát triển cục cằn, vì anh ta có "kỹ năng giao tiếp kém", phải ngồi lại trong khối lập phương cả ngày mà bỏ qua những người dùng chỉ làm việc với những thứ "vui vẻ".

Bây giờ bạn nói rằng nhà phát triển cục cằn có kỹ năng "trên trung bình", nhưng bạn không nói anh ta là người giỏi nhất. Điều này có nghĩa là có thể 1/3 nhóm của bạn, những nhà phát triển giao tiếp giỏi, những người có trình độ kỹ năng của nhà phát triển khó tính trở lên, đều cảm thấy bực mình.

Có đáng để mất một số năng suất từ NHÂN VIÊN THỰC HIỆN TỐT NHẤT của bạn bởi vì họ khó chịu với nhà phát triển cục cằn? Bạn sẽ phải quyết định.

Trừ khi bạn muốn sa thải anh chàng, tôi khuyên bạn nên thực hiện một trong những cách tiếp cận sau:

1) Cố vấn anh ấy để trở thành một người giao tiếp tốt hơn. Chỉ có bạn có thể nói nếu điều này là khả thi. Bạn có thể thấy chỉ cần nắm tay anh ấy thêm một chút có thể giúp đỡ. Một số người chỉ sợ hãi các tương tác kinh doanh chính thức và thể hiện nó bằng cách tức giận khi được yêu cầu làm điều đó.

2) Khuyến khích "giao tiếp tốt", bằng tiền hoặc lợi ích khác. Hãy nói rõ rằng bạn thực sự coi trọng những người giao tiếp tốt và sau đó các nhà phát triển của bạn sẽ không quá khó chịu, nhưng phần thưởng phải thực sự & có ý nghĩa. "Ăn trưa với người quản lý huyện" sẽ không cắt giảm. Một giải thưởng "ngôi sao / kudos / attaboy" cũng sẽ không chỉ là một tờ giấy. Nó phải là thêm tiền, nghỉ thêm, một số thời gian linh hoạt, một số công nhận nghiêm túc với những người cao hơn kiểm soát tăng lương, vv


11
Ông thực sự đã đề cập rằng người giao tiếp kém là một người biểu diễn tốt hơn. Tại sao bạn lại ủng hộ việc khen thưởng thành tích tốt của anh chàng này với một công việc ít phù hợp hơn? Tôi là một người ủng hộ rất lớn cho khái niệm rằng mọi người đều có điểm mạnh của mình và nên chơi theo họ. Nếu tôi mềm ở một khu vực, tôi hy vọng người quản lý sẽ có khả năng làm tròn đội với một người mạnh ở khu vực đó, và sau đó KHÔNG cho chúng tôi chuyển việc!
Bill K

3
@BillK, "Tuy nhiên, một thành viên của nhóm có thể có kỹ năng mã hóa trên trung bình". Anh ấy đã không nói rằng anh ấy là 'tốt nhất'. Tôi đã đâm và nói rằng anh ta tốt hơn 2/3 các nhà phát triển khác. Điều đó khiến 1/3 các nhà phát triển giỏi hoặc giỏi hơn anh chàng này, những người phải làm thêm việc không vui như những gì anh ta phải làm mọi lúc ("tất cả đều thích mã hóa"). Bạn sẽ thích nó như thế nào nếu một trong những đồng nghiệp của bạn nói rằng "Tôi không thích chạy Bài kiểm tra đơn vị để bạn phải chạy tất cả của tôi cho tôi"? Bạn sẽ thấy khó chịu khá nhanh. Thái độ xấu của anh chàng này là nhận được phần thưởng cho anh ta (ít nhiệm vụ không mã hóa).
Graham

9

Trước hết, đổ lỗi cho các thành viên trong nhóm của bạn ... biểu thị kỹ năng quản lý kém.

Ý tôi là, nếu anh ấy thực sự có kỹ năng giao tiếp kém, tôi rất tiếc cho đời sống xã hội của anh ấy, nhưng thực sự, trong công việc, đây không phải là vấn đề của anh ấy nhiều như nó là của bạn . Và hãy đối mặt với điều đó, anh ta thực sự có thể cảm thấy buồn chán bởi khung cảnh làm việc buồn tẻ của bạn, hoặc có những vấn đề riêng tư ảnh hưởng đến hiệu suất của anh ta, hoặc đang âm thầm âm mưu giết chết tất cả các bạn.

Giao tiếp mất ít nhất hai, và sau tất cả, người có kỹ năng người nghèo có thể là bạn. Không bao giờ khiến các thành viên còn lại hòa hợp với nhau khá tốt, tất cả họ đều có thể bù đắp (thậm chí vô tình) cho một số thiếu sót trong giao tiếp mà bạn có và vui vẻ bỏ qua.

Và dù sao đi nữa, đừng đi khắp nơi hỏi internet về những người ngồi cách bạn ba bàn, đi đến chap và hỏi anh ta xem có thực sự có gì sai không và liệu có thể giải quyết được không. (hoặc một cái gì đó buồn tẻ có thể được tối ưu hóa hoặc cải thiện)

Có lẽ anh ta chỉ ghét vị trí bàn làm việc của mình (anh ta đang đối mặt với nhà vệ sinh phải không?) Và điều này khiến anh ta rơi vào tâm trạng tồi tệ.

Gợi ý: lắng nghe câu trả lời, giống như anh ấy là một con người đa cảm, không phải là một nguồn nhân lực.

(ví dụ: thử giải thích chi tiết cho anh ta về sự cần thiết của một số thực tiễn nhất định và ý nghĩa của một số quyết định nhất định, một số người đào chi tiết, vì họ cho họ cảm giác có một thuyền trưởng không lái tàu vào vách đá)


9
-1: Anh ấy không đổ lỗi cho bất cứ ai. Anh ta xác định rằng một anh chàng kém giao tiếp hơn, và do đó anh ta đã tránh được một số công việc nhàm chán hơn mà người khác phải làm. Tôi không chắc làm thế nào bạn kết luận rằng điều này biểu thị sự quản lý kém hoặc OP đấu tranh để giao tiếp ... Điều đó nói rằng, tôi hoàn toàn đồng ý rằng việc nói chuyện với anh chàng trong câu hỏi nên là một phần của bất kỳ giải pháp nào.
cjmUK

1
@cjmUK Điều mà người trả lời này chỉ ra là thiếu tất cả thông tin thật khó để đưa ra quyết định. Một ví dụ, vợ tôi từng làm việc cho một người nghĩ rằng vợ tôi thật kinh khủng, bây giờ vợ tôi làm việc với mọi người và được coi là người có thành tích cao. Vì vậy, vợ tôi là vấn đề, hay đồng nghiệp là vấn đề?
Paul

3
-1 Tôi nghĩ không cần thiết phải nói rằng tôi có kỹ năng quản lý kém vì tôi đang đổ lỗi cho mọi người. Anh ấy là một chàng trai tốt và có lẽ có một lý do chính đáng tại sao anh ấy ít giao tiếp. Hành động của tôi trong việc giải quyết vấn đề này là hai lần - a) cố gắng khắc phục tình hình với anh ta và b) quyết định cách phân bổ công việc dựa trên thành tích trong quá khứ của đội. Tôi đang "hỏi internet" để được trợ giúp với tùy chọn b)
djcredo

2
+1 "Gợi ý: lắng nghe câu trả lời, giống như anh ấy là một con người đa cảm, không phải là một nguồn nhân lực." Nếu chỉ có nhiều người quản lý nghĩ như thế này ... thở dài.
demongolem

8

Mỗi người mỗi khác. Là người quản lý, bạn cần đối xử với mọi người khác nhau (nhưng công bằng!) Để tận dụng tối đa đội ngũ của bạn.

Điều đó nói rằng, có lẽ tốt cho nhà phát triển có kỹ năng mềm kém để làm việc với họ. Tôi sẽ tìm ra thứ không mã hóa mà nhà phát triển thích (hoặc muốn làm) liên quan đến nhiều kỹ năng mềm hơn. Để họ tham gia vào nhiệm vụ đó, và lý tưởng nhất là họ sẽ cải thiện các kỹ năng mềm như một tác dụng phụ.

Mọi người thường không tệ ở một cái gì đó để thoát khỏi công việc; họ xấu về điều đó bởi vì họ không thích nó hoặc có năng khiếu về nó. Bạn không thể giúp cái sau, vì vậy hãy làm việc trước.


6

Chia 30/70 có thể là nơi tất cả các vấn đề của bạn bắt đầu. Tôi chưa bao giờ thấy các nhà phát triển hài lòng với việc phân chia như vậy.

Tôi đã thấy các nhà phát triển cảm thấy thoải mái với 10, 15% công việc khác (và bản thân tôi rất vui vì điều đó thật thú vị khi đúng liều ) nhưng 30% là quá nhiều. Tôi muốn nghĩ rằng các thành viên khác trong nhóm không muốn nói lên suy nghĩ của họ hơn là chỉ có một người không thích "30% công việc khác".

Tôi cũng nghĩ điều quan trọng là điều chỉnh "toán năng suất" của bạn thành các số liệu thực tế hơn. Nó sẽ không bao giờ thêm tới 100% vì những tổn thất không thể tránh khỏi tại "chuyển đổi ngữ cảnh".

  • 30 + 70, tổng năng suất lên tới 100% khi chuyển đổi giữa lập trình và công việc khác , sẽ không bao giờ xảy ra trong cuộc sống thực; nhiều khả năng khoảng 20 + 50 hoặc thậm chí 20 + 40. Các công tắc bối cảnh đặc biệt gây đau khổ cho các nhà phát triển phần mềm - nếu bạn quan tâm, hãy kiểm tra bài viết này để biết giải thích hay về lý do tại sao: ĐỪNG BỎ L PR CHƯƠNG TRÌNH!
    Các lập trình viên coi trọng năng suất của họ đương nhiên sẽ không hài lòng về những mất mát như thế.

Đối với việc chạy thử nghiệm một phần của công việc, bạn đã xem xét chuyển nó cho người thử nghiệm chưa? Việc các lập trình viên có thể làm điều đó (tôi nghĩ rằng bất kỳ lập trình viên có kinh nghiệm nào cũng có khả năng đó) không có nghĩa là họ nên làm vậy . Người kiểm tra cũng có thể làm điều đó và họ làm điều đó tốt hơn và họ sẽ không bị giảm năng suất tại "công tắc ngữ cảnh".

Một điểm khác khiến tôi tự hỏi làm thế nào bạn sử dụng tài nguyên QA là việc bạn đề cập đến Hỗ trợ / Điều tra . Những người kiểm tra chuyên nghiệp mà tôi từng làm việc có xu hướng "nói trước" trong những thứ như thế.

  • Là một người thử nghiệm bản thân, tôi hiểu họ khá rõ - các vấn đề sản xuất đối với tôi (với tư cách là người thử nghiệm) là một nguồn dữ liệu vô giá để tìm hiểu về phạm vi thử nghiệm ("vấn đề này có được kiểm tra đúng cách không?") Và cho ưu tiên khuyết tật ("được rồi, nó đã được kiểm tra và báo cáo trước khi phát hành, nhưng tôi đã đặt mức độ ưu tiên / mức độ nghiêm trọng phù hợp rồi phải không?").

Người kiểm tra giỏi có thể dễ dàng tìm ra khi nào nên vượt qua cuộc điều tra vấn đề hỗ trợ cho các nhà phát triển và điều này không xảy ra rất thường xuyên. Những lý do để quá tải các nhà phát triển với điều này chỉ đơn giản là thoát khỏi tâm trí của tôi. Như tôi đã viết, họ chắc chắn có thể làm điều đó (tôi thường mong muốn nhà phát triển cấp cao biết cách làm bất cứ điều gì QA làm) nhưng điều đó không có nghĩa là họ nên làm .


4

Tôi có 2 điều để nói về điều này

  1. Bạn đã tuyển dụng một lập trình viên hay nhà phát triển phần mềm chưa?
    Khi bạn đang xem xét một nhà phát triển phần mềm, tất cả những điều bạn đã đề cập là một phần và phần của sự phát triển phần mềm. Bạn không thể bỏ qua bất kỳ điều gì trừ khi bạn đã tuyển dụng cho một nhiệm vụ cụ thể. IMO 50% tổng số phát triển phần mềm là phần còn lại mã hóa là thiết kế, phân tích, kiểm tra, tài liệu, v.v.

  2. Không ai được sinh ra hoàn hảo.
    Nó không thể là bạn có thể tìm thấy một người tốt trong mọi thứ. Bạn phải làm cho họ đấu tranh và làm cho họ học hỏi mọi thứ.

Là người quản lý, bạn phải tận dụng tốt nhất trong số họ Tôi đồng ý nhưng về lâu dài bạn có thể gặp phải vấn đề. Hãy giao cho họ những nhiệm vụ nhẹ nhàng để họ có xu hướng nắm bắt được nó. Hãy cho họ cảm giác rằng tôi không giỏi trong việc này / Tôi không đủ khả năng để làm điều này . Hầu hết tất cả đều đối xử bình đẳng với mọi người sẽ nhận được đầu ra hiệu quả nhất từ ​​nhóm của bạn.


+1 - Tôi đồng ý với cả hai điểm. Một nhà phát triển nên được làm tròn hợp lý. Và với sự hỗ trợ và khuyến khích thích hợp, có thể không có lý do nào khiến anh chàng không thể chơi trò chơi của mình.
cjmUK

Vâng, "coder" vs "dev dev" là một cách tuyệt vời để đóng khung nó. Tất nhiên tất cả chúng ta chỉ muốn viết mã vui vẻ. Nhưng làm tất cả những thứ khác đi với nó thực sự là lý do tại sao hầu hết chúng ta được trả tiền. Tôi có thể lập trình viên ngoài khơi ngay lập tức. Việc bảo vệ các nhà phát triển phần mềm hiểu về lĩnh vực kinh doanh hiện tại khó khăn hơn nhiều.
Graham

@Graham đó là những gì có thể khiến bạn trở thành tài sản của công ty
Shirish11

4

Nếu mọi người trong đội ngũ nhân viên của bạn có cùng tiêu đề / mô tả công việc và mô tả công việc bao gồm mọi thứ bạn đã liệt kê thì lập trình viên này cần phải có những kỹ năng khác được mài giũa bằng cách giao thêm các nhiệm vụ không phải lập trình viên khác này. Tương tự như vậy, các nhân viên khác của bạn sẽ không được rèn luyện các kỹ năng lập trình nếu họ liên tục phải làm việc với các nhiệm vụ không lập trình (sử dụng hoặc mất nó).

Nhưng tôi vẫn nghĩ rằng ưu tiên chính của bạn có lẽ nên đáp ứng thời hạn của bạn (điều mà bạn vẫn có thể làm được trong khi phân phối công việc một cách đồng đều).

EDIT: Nếu bạn có một nhóm nhỏ, có lẽ sẽ có ý nghĩa khi tất cả các thành viên có thể đội nhiều mũ. Nếu bạn có một nhóm đủ lớn, có thể có ý nghĩa khi có các nhóm chuyên về các lĩnh vực khác nhau. Từ bài đăng của bạn, có vẻ như bạn không có một nhóm đủ lớn để có các nhóm chuyên gia.


4

Không rõ từ bài viết gốc của bạn chính xác những gì thiếu về kỹ năng giao tiếp của nhà phát triển này. Việc không quan tâm đến việc đi họp hoặc làm công việc lập kế hoạch / phối hợp (ví dụ) không nhất thiết cho thấy kỹ năng giao tiếp kém. Có lẽ nhà phát triển chỉ đơn giản cảm thấy rằng loại công việc này là công việc của người quản lý và cắt giảm năng suất của anh ta như một nhà phát triển? Hoặc có thể anh ta cảm thấy rằng có quá nhiều tổ chức và đây là một hình thức phản đối những gì anh ta cảm thấy chỉ là lãng phí thời gian? Rốt cuộc, vấn đề ngược lại, nơi mọi người nói chuyện cả ngày và không bao giờ làm được gì cũng khá phổ biến trong văn phòng.

Điều quan trọng là bạn nói chuyện với nhà phát triển này theo cách không đối đầu và cố gắng tìm hiểu lý do tại sao anh ta tránh các nhiệm vụ không lập trình. Có lẽ đó không phải là một lý do duy nhất, anh ta có thể có nhiều lý do khác nhau như có nhiều loại nhiệm vụ khác nhau. Hãy chắc chắn rằng anh ấy hiểu rằng mục đích của cuộc trò chuyện là để bạn có thể học cách cải thiện hiệu quả năng suất của nhóm và sự hài lòng trong công việc cho tất cả các thành viên trong nhóm (bạn không tham gia để có được anh ấy). Đây là thời gian để bạn lắng nghe, và không tranh luận hay cố gắng giải quyết mối quan tâm của anh ấy bằng phản ứng giật đầu gối. Bạn có lẽ cũng nên gặp các thành viên khác trong nhóm, có lẽ họ hoàn toàn ổn khi để anh chàng này làm công việc nặng nề trong khi họ tập trung vào khía cạnh chuyên nghiệp hơn.

Sau cuộc họp này, hãy dành thời gian suy nghĩ về các cuộc trò chuyện bạn đã có và cố gắng xem xét quan điểm của nhân viên này với một tâm trí cởi mở. Có thể cảm xúc ban đầu của bạn là chính xác và anh ta đang thiếu một số kỹ năng quan trọng mà bạn nên thúc đẩy anh ta phát triển. Hoặc có thể anh ta đưa ra một số thách thức hợp lệ cho các giả định của bạn. Có lẽ bạn có thể làm việc với các nhóm khác để chính thức hóa một số quy trình và giảm nhu cầu giao tiếp dư thừa. Có thể các đội khác không giảm cân và bạn cần có một cuộc trò chuyện thân thiện với quản lý của họ . Có nhiều khả năng bạn có thể không xem xét.

Cuối cùng, và quan trọng nhất, có cuộc trò chuyện tiếp theo với các cá nhân, hoặc một cuộc họp nhóm nếu thấy phù hợp. Nếu bạn đã xác định được các vấn đề tổ chức thực sự nằm trong khả năng ảnh hưởng của bạn, hãy nói với nhân viên của bạn về các hành động bạn sẽ thực hiện để cải thiện tình hình công việc của họ. Nếu bạn vẫn tin rằng từng nhân viên sai, hãy ngồi xuống với anh ta và giải thích những thay đổi bạn cần từ anh ta và tại sao. Các nhà phát triển có xu hướng đáp ứng tốt với các giải thích hợp lý / thực tế. "Thật không công bằng với các đồng nghiệp của bạn để mang đến cho bạn tất cả công việc thú vị. Chúng tôi muốn tất cả các bạn là những nhà phát triển thuần túy nhưng đó không phải là thực tế của tình huống nên chúng tôi cần chia sẻ gánh nặng của công việc nhảm nhí."

Tất nhiên, nếu anh chàng này chỉ là một thằng khốn khó chịu, từ chối cho bạn biết lý do tại sao anh ta không vui, sẽ không trả lời lý do và không được các đồng nghiệp của anh ta tôn trọng ... tốt ... đó là thời gian cho Kế hoạch cải thiện hiệu suất.


2

Mặc dù bạn đang cố gắng quản lý một nhóm và muốn giữ cho mọi người có động lực (có cảm giác công bằng giúp đỡ), nhưng bạn có đang hy sinh dự án bằng cách không có lập trình viên lập trình tốt nhất của bạn? Ý tôi là, đây không phải là vấn đề.

Bạn không sợ lạm dụng và / hoặc có nguy cơ mất nhà phát triển tốt nhất của bạn? Công việc của bạn là cố gắng và giảm bớt các loại nhiệm vụ từ mọi người.

Được đối xử bình đẳng không có nghĩa là bạn đối xử với mọi người như nhau. Nếu những người khác muốn thực hiện các nhiệm vụ phi lập trình để được giao nhiều nhiệm vụ lập trình hơn, thì họ cũng không có nguy cơ trở nên giỏi?

EDIT: Khác với cảm xúc cá nhân của bạn, bạn chưa xác định được vấn đề. Tại một số điểm thiếu giao tiếp cản trở một lập trình viên. Những người khác sẽ thể hiện sự phẫn nộ và công việc của họ có thể bị ảnh hưởng. Cho đến nay, bạn dường như là người duy nhất gặp vấn đề. Trừ khi có điều gì khác mà bạn không chia sẻ?

EDIT 2 Cuối cùng, mọi người sẽ yêu cầu một đặc ân. Người này ít giao tiếp và mã hóa nhiều hơn (mà anh ta nên bằng tất cả các tài khoản). Một số người khác muốn đến sau một chút. Một người khác sẽ cần phải bỏ qua một cuộc họp để hoàn thành một thời hạn. Một người đồ họa có được một màn hình lớn hơn. Khi bạn quá chú trọng vào việc giữ điểm, bạn sẽ quên những gì quan trọng.


Không ai nói ông là lập trình viên giỏi nhất . Và ngay cả khi anh ta là như vậy, không có gì để nói rằng yêu cầu anh ta hoàn thành một vai trò rộng hơn là sai. Tôi đồng ý rằng công bằng không nhất thiết có nghĩa là coi mọi người là người vô tính - nhưng có thể có một cách trung gian, nơi mọi người được giao những nhiệm vụ phù hợp và quan tâm đến họ, nhưng ở đó tất cả họ đều làm việc với những nhiệm vụ ít hấp dẫn hơn ở một mức độ nào đó.
cjmUK

1
@cjmUK - và không ai nói các thành viên khác trong nhóm có vấn đề với điều này. Xem Chỉnh sửa 2.
JeffO

2
@Jeff O "Thật công bằng khi nói rằng các Nhà phát triển sẽ thích mã hóa hơn". Xin lỗi, nhưng nếu các nhà phát triển khác không có vấn đề gì với anh chàng đang nghi vấn, cuối cùng họ sẽ làm. djcredo đang chủ động trong việc cố gắng kiểm soát điều này trước khi nó đi theo con đường đó.
Graham

2

Tôi là một quản trị viên linux gắt gỏng, người viết rất nhiều kịch bản, và tôi nhận thấy rằng tôi có kỹ năng giao tiếp kém. Tôi nghe rất giống anh chàng của bạn. Trên thực tế, đó là lĩnh vực duy nhất tôi nhận được trong các bài đánh giá hiệu suất. Mặt khác, tôi liên tục dẫn dắt nhóm của mình trong việc đổi mới và giải quyết vấn đề, và đã tạo ra và dẫn đường đến nền tảng mới mà chúng tôi triển khai và đã tiết kiệm cho nhóm của tôi rất nhiều thời gian và công ty của tôi rất nhiều tiền bằng cách được phép là chính mình

Sếp cũ của tôi đã được yêu cầu gia đình / vợ của anh ấy VÀ quản lý cấp cao của công ty chúng tôi rời khỏi vị trí của anh ấy .... đồng thời. Anh ấy làm việc không mệt mỏi để cân bằng các trách nhiệm một cách công bằng và tự mình gánh vác rất nhiều tải trọng. Trong bất kỳ tương tác với bất kỳ ai bên ngoài bộ phận, nếu có một sự hiểu lầm trong giao tiếp đã trở lại với anh ta, anh ta đã nhanh chóng, ah, trừng phạt nó một cách trừng phạt. Anh ta rất kém trong việc "quản lý trở lên", vì vậy nhóm của chúng tôi là người cuối cùng nhận được tài nguyên cho đến khi nó là một trường hợp khẩn cấp, và sau đó công ty đã trả tiền cho các nhà cung cấp với các mức bán hàng lắt léo cho phần cứng chưa được kiểm tra mà không hỏi ý kiến ​​nhóm sẽ sử dụng các công cụ đó. Trong nỗ lực tạo ra một nhóm "cân bằng tốt", anh ấy đã vi mô hóa danh sách nhiệm vụ của chúng tôi và cố gắng cân bằng các nhiệm vụ để các thành viên trong nhóm có thể cải thiện bộ kỹ năng của họ ở những nơi họ không tuyệt vời, dẫn đến RẤT NHIỀU mã bị hỏng hoặc triển khai kiến ​​trúc kém. Trong khi những người khác ngoài tác giả được giao nhiệm vụ hỗ trợ cụ thể cho mã bị hỏng đó để họ có thể "học" - việc triển khai, mã và kiểm tra được kiến ​​trúc kém tạo ra rất nhiều thiện chí kém giữa các thành viên trong nhóm và thực sựsự xuất hiện gia tăng của "trò chơi đổ lỗi", đó là một con đường nhanh đến trạng thái đội độc hại.

Sếp hiện tại của tôi là một cá nhân điềm tĩnh, thu thập, xuất thân từ vai trò quản trị viên cơ sở và đã làm việc theo cách của mình. Anh ấy đưa ra quyết định tốt và dựa nhiều vào các thành viên trong nhóm để đặt ưu tiên của riêng họ. Anh ấy là một người giao tiếp tuyệt vời và phản ứng bình tĩnh và phối hợp với người giám sát của anh ấy với bất kỳ vấn đề, ý tưởng hoặc nhu cầu giao tiếp nào được thể hiện bởi nhóm của tôi. Anh "làm việc trở lên" không mệt mỏi. Anh ấy chậm chạp trong việc thay đổi kiến ​​trúc lớn, và tư vấn kỹ lưỡng với toàn bộ đội trước khi thay đổi môi trường của chúng tôi và thoải mái dựa vào các đặc sản của các thành viên trong nhóm.

Theo người quản lý mới, thời gian chết của chúng tôi đã giảm xuống gần như bằng không (điều này cũng đã giảm phần trăm thời gian chúng tôi dành cho các nhiệm vụ hỗ trợ từ khoảng 40% xuống còn khoảng 10%), sự hài lòng của nhóm chúng tôi đã đi qua mái nhà, và chúng tôi trên đường đã chuyển từ 'phá vỡ ngân hàng trên phần cứng mới cứ sau ba đến năm năm' sang một kế hoạch mua lại liên tục sẽ giúp công ty tiết kiệm được một triệu đô la mỗi năm trong vòng năm năm. Kế hoạch đó là một chương trình cơ sở chưa từng xảy ra dưới thời người quản lý trước nhưng được người quản lý mới tích cực đẩy lên quản lý cấp cao và phụ thuộc vào việc tìm kiếm RẤT NHIỀU hiệp lực trong bộ kỹ năng của đội. Chúng tôi đã được CIO thông báo một cách không chính thức rằng chúng tôi hiện là nhóm duy nhất trong công ty thực sự "có chung sở thích" và anh ấy ' Sẽ can thiệp vào môi trường làm việc của chúng tôi càng ít càng tốt và xáo trộn càng nhiều tài nguyên đối với các khu vực có vấn đề mà chúng tôi xác định càng tốt. Điều này đã thành sự thật và nó khiến cho "chi phí" hỗ trợ của chúng tôi thậm chí còn thấp hơn, mặc dù nó đã phá vỡ khối lượng công việc của một số nhóm khác - nhưng điều đó cũng khiến chi phí hỗ trợ của các đội đó thấp hơn.

Hãy nhìn xem, nơi để các nhà phát triển cải thiện bộ kỹ năng của họ là ở trường hoặc vào thời gian riêng của họ. Nơi để họ sản xuất mọi thứ là vào thời gian của công ty bạn. Cách tốt nhất để sản xuất mọi thứ là bằng cách sản xuất những gì họ biết tốt nhất. Khi làm việc trong các khu vực mà một nhà phát triển không thoải mái, họ nên tìm kiếm một nhà phát triển thứ hai chuyên về và làm việc theo nhóm hoặc nhà phát triển chuyên ngành nên viết mã và tạo tài liệu và sơ đồ. Định tuyến nhiệm vụ hỗ trợ cho những người đã viết mã. Có, điều này làm tăng cái mà chúng tôi gọi là "yếu tố xe buýt" của bạn - khả năng bộ phận của bạn gặp sự cố về tốc độ nếu chuyên gia nên bị xe buýt đâm. (Hoặc bị sa thải, hoặc chuyển đổi công việc, hoặc ...) Sự thật của nó là sự suy giảm năng suất của bạn từ nỗi sợ hãi đó là những đơn đặt hàng có cường độ cao hơn so với tổn thất thực tế khi "sự kiện xe buýt" xảy ra. Điều thường xảy ra trong một "sự kiện xe buýt" là người thừa kế công việc của chuyên gia làm lại nó bằng hình ảnh của chính mình để anh ta có thể hỗ trợ nó một cách hiệu quả nhất, nói chung là giải quyết một loạt vấn đề và giảm thời gian dành cho hỗ trợ hơn nữa, và cuộc sống tiếp tục trên, bật.

Chỉ định mọi thứ cho những người có thể làm chúng tốt nhất. Làm cho họ hỗ trợ và tài liệu công việc của họ. Thúc đẩy sự sáng tạo của họ và cho phép họ tập trung mà không bị phân tâm hoặc quản lý vi mô. Mọi thứ khác là BS của trường quản lý, điều không may là có vẻ như công ty của bạn đang bơi vào. Điều đó không có nghĩa là nhóm của bạn cũng cần phải bơi trong đó.

Từ quan điểm của một công ty, một người quản lý tốt sẽ thúc đẩy các giá trị của công ty trong khi thực hiện các nhiệm vụ theo các giá trị đó. Từ quan điểm của một nhân viên CNTT, một người quản lý giỏi cho phép nhóm làm những gì đúng đắn và nhanh chóng nhất có thể và đóng vai trò như một rào cản chống lại quản lý cấp cao đẩy các giá trị mà họ học được trong các lớp MBA cuối tuần xuống cổ họng của những kẻ dưới quyền. Bạn đang là người của công ty và điều đó có thể không phải là tốt nhất cho nhóm của bạn. Những người có kỹ năng giao tiếp "tốt" thì quá lịch sự để nói điều đó.


0
  • Hãy chắc chắn rằng nhân viên biết các kỹ năng giao tiếp quan trọng như thế nào đối với mô tả công việc của anh ta. Làm việc với anh ấy / cô ấy để cải thiện.
  • Đừng khăng khăng rằng họ giỏi như các thành viên khác trong các nhiệm vụ đó.
  • Phân công nhiệm vụ theo các nguyên tắc mà bạn tin tưởng. Tìm sự cân bằng giữa việc giao nhiệm vụ hiệu quả cho các kỹ năng và sự công bằng / vui vẻ.

Đây chỉ là những ý tưởng tóm tắt, hy vọng ai đó sẽ đánh cắp những điểm này và xếp chúng vào một trong những câu trả lời khác. ;-)


0

Hiệu suất là tất cả. Đưa cho anh ta các nhiệm vụ lập trình. Đừng nói chuyện này với phần còn lại của bộ phận. Tùy chọn đưa ai đó vào để thực hiện các nhiệm vụ com hoặc chỉ giao cho ai đó trong các nhiệm vụ com. Đừng nghĩ đến việc lập trình để vui chơi. Mọi thứ đều "vui vẻ" từ POV của bạn.

Nếu bạn không, bạn sẽ tạo ra một tình huống cực kỳ khó quản lý và kém hiệu quả hơn mức có thể.


0

Thật là một câu hỏi hay, đó là điều mà tất cả các trưởng nhóm, giám sát viên, quản lý công nghệ nên nghĩ đến. Tôi thích cách tiếp cận của bạn, mọi người nên có một nhiệm vụ 'vui vẻ'. Lấy nó tiếp tục có một đội ngũ mà lon đón nhiệm vụ khác nhau và là ngăn chặn được đào tạo chéo các Nguyên tắc Peterbilt từ gây tàn phá 'đội lá thành viên trong nhóm indesipensible hoặc thậm chí mất thở hổn hển một kỳ nghỉ'.

Bây giờ, như được chỉ ra bởi rất nhiều bài viết, công việc không công bằng và không nên. Các nhà quản lý được đo lường về số lượng công việc có giá trị được thực hiện.

  • Người quản lý phù hợp với nhiệm vụ cho các cá nhân dựa trên kỹ năng.
  • Người quản lý giỏi phù hợp với các nhiệm vụ dựa trên kỹ năng, tăng trưởng, sở thích và năng suất xây dựng của nhóm.
  • Các nhà quản lý tuyệt vời có được nhóm của họ để làm điều này với một chút trợ giúp và hướng dẫn. Tức là không có người quản lý dành cả ngày cho nó.

Nói chuyện với lập trình viên giỏi của bạn, hỏi anh ta nếu có những điều anh ta muốn học. Những nhiệm vụ khác anh ta sẽ chấp nhận ... ngay cả những gì ít phản đối nhất đối với anh ta. Anh ấy có thể giúp các thành viên khác trong nhóm với chương trình của họ ... cố vấn cho họ không. Vâng, tôi biết giao tiếp là một vấn đề, vì vậy có lẽ anh ấy nên làm việc đó.

Một cách khác để đóng gói này là có một danh sách các nhiệm vụ và để mỗi nhân viên chọn thứ gì đó. Hãy để lập trình viên tốt của bạn chọn đầu tiên. Nếu bạn cảnh báo anh ta trước và cho anh ta thấy danh sách các nhiệm vụ thậm chí còn tốt hơn.

Nếu bạn có được sự phản kháng, điều mà bạn hầu như luôn luôn làm với sự thay đổi, hãy tìm một điểm bán hàng, một cái gì đó có giá trị với anh ta, tại sao anh ta sẽ có lợi. Cuối cùng, bạn chỉ có thể nói với anh ấy để làm điều đó cho đội.

Cũng mong đợi những sai lầm và năng suất thấp hơn để bắt đầu, đó là một dấu hiệu mọi người đang học hỏi. Dự án này có thể bị ảnh hưởng, nhưng tiếp theo sẽ tốt hơn.

Cuối cùng, công việc của bạn là đảm bảo mọi thứ được hoàn thành, nhưng nhân viên của bạn cũng đang phát triển và nếu bạn có thể thu hút họ vào quy trình thậm chí còn tốt hơn. Một số người có thể nói cách tốt nhất để đảm bảo công việc được hoàn thành là một nhóm biết những gì cần hoàn thành và sở hữu kết quả.

Chỉnh sửa: Oh và tiếp tục cố gắng, lời khuyên ở trên xuất phát từ nhiều năm mắc lỗi, nhưng tôi luôn biết rằng tôi muốn giúp đội của mình phát triển và tôi biết năng suất là vua, vì vậy tôi đã tiếp tục thử những điều mới khi lần thử cuối cùng thất bại.


0

Câu trả lời hay nhất đã được chấp nhận, nhưng tôi ngạc nhiên không ai chỉ ra rằng "phân công nhiệm vụ" không phải là điều duy nhất người quản lý có thể làm việc. Có một "lập trình viên trên avg" cũng có "kỹ năng giao tiếp trên avg" (tất cả những thứ khác đều bằng nhau) sẽ là một nhà phát triển được trả lương cao hơn / cao hơn so với người có kỹ năng lập trình tương tự và kỹ năng giao tiếp yếu. Điều này có thể giúp bù đắp bất kỳ "thiên vị" nhận thức nào từ nhóm. (Trong một số org, có các kỹ năng avg trên "Phân tích yêu cầu" và các kỹ năng avg ở các lĩnh vực khác có thể có giá trị hơn nhiều đối với công ty do loại công việc đang được thực hiện. Là người quản lý, bạn cần quyết định cách xử lý việc này .)

Một điều khác cần chú ý: không đưa ra câu hỏi nào cho người khác ngoài nhiệm vụ lập trình sẽ dẫn đến sự cô lập lâu dài. Hãy chắc chắn tiếp tục giao cho họ một số nhiệm vụ khác (nhưng những nhiệm vụ họ có thể làm tốt, đừng thiết lập chúng cho phản hồi tiêu cực !!) để cả hai đều có thể nhìn thấy và có thể nhìn thấy với các bộ phận / nhóm khác.

Cuối cùng ... kiểm tra với các thành viên khác trong nhóm nếu họ thấy bất kỳ sự bất bình đẳng nào trong các bài tập nhóm theo định kỳ. Đây có thể là một mối quan tâm lớn đối với bạn, nhưng # 15 trong danh sách của mọi người khác.


1
Thật không may, anh ta có ít hơn các kỹ năng giao tiếp trung bình rõ ràng.
Matthieu M.

-1

Vì theo đánh giá của riêng bạn, một lập trình viên này là người giỏi nhất trong nhóm, theo cách "công bằng" là giao cho người đó công việc mong muốn (kết quả là đã chứng minh được khả năng tốt nhất để làm việc đó). Rốt cuộc, có lẽ có những người thích làm việc ở công ty này nhưng không được thuê chút nào - nhưng không ai sẽ nói rằng nó không "công bằng" với họ rằng họ không được làm mã hóa này.

Tôi nghĩ rằng một cách tiếp cận công bằng sẽ là nói với một thành viên khác, ít kỹ năng hơn trong nhóm, người muốn thực hiện nhiều mã hóa hơn: "chúng tôi đang để (và vì thế) dẫn đầu về vấn đề này. Có lẽ bạn có thể dẫn đầu điều tiếp theo sẽ đến, nếu bạn có thể chứng minh đã học được các kỹ năng x và y. "


2
"Tuy nhiên, một thành viên của nhóm có thể có kỹ năng mã hóa trên trung bình". Anh ấy không phải là người giỏi nhất. Anh ấy trên trung bình. Có thể có khoảng 1/3 nhóm nghiên cứu về mã hóa tốt hơn.
Graham

-1

Giống như một số người khác đã trả lời, tôi hiểu vị trí của bạn và tôi sẽ có tham vọng tương tự.

Mặc dù đây là một trường hợp để nói rằng thật hợp lý khi giao nhiệm vụ cho những người được trang bị tốt nhất để thực hiện chúng, nhưng cũng có ý nghĩa trong việc mở rộng các kỹ năng của mọi người để cung cấp một đội ngũ năng động và linh hoạt.

Nếu anh chàng này được yêu cầu thực hiện các yếu tố không mã hóa trong vai trò của mình, nhưng kỹ năng giao tiếp của anh ta kém hơn thực sự cần thiết, anh ta cần phải cải thiện. Giả định rằng bạn có một số loại hệ thống đánh giá / thẩm định phát triển, đây là lúc để nêu vấn đề.

Các vấn đề chính là vạch ra rõ ràng những gì bạn yêu cầu ở anh ấy, đánh giá xem anh ấy có kỹ năng tuân thủ hay không và lập kế hoạch đào tạo để cho phép thực hiện điều đó. Đào tạo không nhất thiết phải chính thức, nhưng bạn cần giúp anh ta đạt được các kỹ năng cần thiết.

Nếu anh ta đơn giản là không thể bị làm phiền, thì cuối cùng nó sẽ đi đến một vấn đề kỷ luật. Nếu anh ta không có khả năng, mặc dù đã cố gắng và được bạn hỗ trợ, thì có thể có các biện pháp kỷ luật (mà tôi cho rằng sẽ khắc nghiệt và phản tác dụng) nhưng bạn cũng có thể chấp nhận rằng anh ta không chấp nhận cắt ra cho một số nhiệm vụ nhất định.

Nói chuyện với anh chàng sẽ là một trong những cổng gọi đầu tiên của bạn . Bạn có thể thấy rằng anh ta thiếu tự tin hoặc hiểu biết. Bạn cũng có thể thấy rằng anh ấy rất nhanh nhạy và sẽ đánh giá cao cơ hội để cải thiện bản thân.


-1

Bạn nên thuê một đàn em để làm tất cả các công việc nặng nề, và cho mọi người biết rằng họ cần giúp anh ta bất cứ điều gì anh ta / cô ta yêu cầu giúp đỡ.

Họ sẽ có xu hướng làm phiền nhiều hơn về bộ mã hóa trên mức trung bình của người Viking vì khả năng của họ và phần còn lại của đội có được một con lừa mới. Các thiếu niên được học hỏi từ đầu và cuối cùng công ty có một nhân viên tròn trịa.


1
Vui lòng xem xét việc làm lại câu trả lời này để trôi chảy hơn một chút để thể hiện mối quan hệ của lập trình viên mới, bao gồm cả việc chúng tôi lấy tiền để trả tiền cho người mới (ban đầu, tôi nghĩ rằng đó là bằng cách loại bỏ người giao tiếp kém). Trong câu trả lời của bạn, làm việc với anh chàng mới có phải là cách để anh chàng hiện tại xây dựng kỹ năng giao tiếp? Anh chàng nào kết thúc tốt đẹp?
Nhà phát

-2

Hy vọng rằng tất cả mọi người sẽ có các kỹ năng giao tiếp giống nhau là hợp lý như mong đợi bạn sẽ dạy người đàn ông què quặt chạy nhanh như các thành viên còn lại trong đội.

Mọi người khác nhau, họ có những kỹ năng khác nhau và điểm yếu khác nhau. Bắn một lập trình viên tuyệt vời chỉ vì anh ta không thể bắt kịp những người khác về kỹ năng giao tiếp sẽ giống như sa thải một người đàn ông què quặt vì anh ta không thể đi nhanh như những người khác. Nó sẽ không công bằng từ quan điểm đạo đức và nó sẽ đi ngược lại lợi ích kinh tế của chính bạn - để hoàn thành công việc.

Trước tiên, bạn nên làm điều đó trong quá khứ, hãy đọc về hội chứng Asperger . Kỹ năng xã hội kém là chỉ số chính của hội chứng đó.

Thứ hai, bạn có thể thuê và sa thải bất cứ ai bạn muốn, nhưng nếu bạn không đối phó với những điểm yếu và điểm yếu của nhân viên, bạn sẽ kết thúc với một nhóm lập trình viên trung bình, bởi vì người giỏi nhất sẽ rời đi (nếu không bị sa thải trước) .

Có một bộ phim, Adam , trong đó lập trình viên thể loại bị sa thải chỉ vì anh ta đã viết một cái gì đó mà anh ta không mong đợi. Ý tưởng của anh ta có thể mang lại rất nhiều tiền cho nhà tuyển dụng, nhưng anh ta không thể sử dụng cơ hội này vì anh ta tập trung vào "nguyên tắc" của mình.


1
Chỉ cần rõ ràng - không ai bị sa thải ở đây. Tất cả chúng tôi làm việc rất tốt với nhau, và anh ấy là một thành viên cực kỳ giá trị của đội dev. Tôi đang nói về cách phân công công việc trong tương lai và cách cải thiện hiệu suất và tinh thần của toàn đội.
djcredo
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.