Cách chứng minh với ban quản lý rằng các nhà phát triển tầm thường đang làm tổn hại đến nhóm [đã đóng cửa]


82

Tôi đang ở vị trí bấp bênh khi “quản lý” một nhóm các nhà phát triển tại một công ty nhỏ. Tôi nói "quản lý" bởi vì mặc dù tôi phân công công việc và cung cấp phản hồi về hiệu suất của họ, tôi không có quyền nào trong việc thực sự kỷ luật một cá nhân.

Một số người trong nhóm của tôi mà tôi không biết phải làm gì, họ không thể tự làm việc, đòi hỏi lượng lớn người dùng nắm giữ và khi bị bỏ lại thường tàn phá dự án thường đến mức thất bại. Khi thất bại xảy ra, tôi còn lại để cứu vãn dự án và đẩy nó (đôi khi đi khập khiễng) qua vạch đích.

Những nhà phát triển này không chỉ thiếu kỹ năng về các khái niệm lập trình mà còn thiếu khả năng hình thành giải pháp cho một vấn đề trong mã. Những thứ đơn giản như viết vòng lặp đã khó đối với họ, chưa nói đến việc thiết kế và triển khai giải pháp cho một vấn đề.

Chúng tôi đã thử lập trình theo cặp, đề nghị trả tiền cho các lớp học, mua sách, phân bổ thời gian trong ngày làm việc để đào tạo và thậm chí dành cả ngày để đào tạo nhóm.

Các nhà phát triển cấp cao khác và tôi không biết phải làm gì, nhưng năng suất của chúng tôi đang bị hạn chế khi phải đối phó với những cá nhân này hàng ngày. Ban quản lý buộc chúng tôi phải giao cho họ công việc và họ phàn nàn chính là làm thế nào mọi thứ không được hoàn thành đủ nhanh.

Không ai trong nhóm quản lý của chúng tôi làm việc trực tiếp với bất kỳ nhà phát triển nào ngoài tôi và nhà phát triển cấp cao khác. Việc quản lý không mang tính kỹ thuật và tin rằng mọi nhà phát triển đều được tạo ra như nhau và rõ ràng là chúng tôi cần nhiều người hơn trong các dự án này để hoàn thành chúng nhanh hơn.

Tôi đã chuẩn bị một tài liệu với các phần từ "Tháng người đàn ông thần thoại" và "Hoàn thành mã" để gửi cho ban quản lý để hy vọng minh họa bằng số liệu thống kê rằng những gì thực sự cản trở chúng tôi đang phải kéo những người tầm thường vượt qua chu kỳ phát triển.

Những tài nguyên nào khác ngoài đó? Sách, bài báo, lời khuyên chung bất cứ điều gì sẽ hữu ích.


20
Lúc đóng cửa: Thôi! Nắm chặt lấy!
Peter

6
Thêm câu hỏi này vào mục yêu thích của tôi là không đủ. Tôi phải đặt nó làm hình nền.
Manos Dilaverakis,

5
chết tiệt, tôi nên bỏ phiếu để đóng, nhưng tôi thích câu hỏi :(
IAdapter

3
Một điều rất quan trọng bạn phải làm là thuyết phục ban giám đốc rằng bạn và / hoặc đối tác phát triển cấp cao của bạn có tiếng nói trong việc ai được thuê (và bị sa thải hoặc bị kỷ luật). Nếu bạn phải chịu trách nhiệm hướng dẫn họ, ít nhất bạn nên có một số ý kiến ​​về việc họ có phải là thành viên trong nhóm của bạn hay không.
Michael Todd

5
Bình chọn là đóng, chủ quan và biện luận. Nên là wiki cộng đồng nếu mọi người chỉ muốn trút giận.
Joe

Câu trả lời:


26

Vấn đề có phải bắt nguồn từ việc thiếu kỹ năng hoặc năng lực, vấn đề thái độ từ phía các lập trình viên, hay do văn hóa doanh nghiệp không đề cao đạo đức làm việc tốt?

Nếu đó là kỹ năng, bạn đã biết rằng có một số điều bạn không thể dạy. Nếu công ty sẵn lòng (và có vẻ như vậy) và bạn có thể thể hiện sự cải thiện, tôi sẽ tăng cường đào tạo và xem những nhà phát triển nào sẽ tăng lên trong dịp này. Những người không bạn sẽ phải cho đi. Tôi sẽ không thuê thêm nhà phát triển cho đến khi bạn biết rằng bạn sẽ từ bỏ một số nhà phát triển hiện có của mình.

Nếu đó là sự lười biếng hoặc các vấn đề về thái độ khác từ phía các lập trình viên, bạn sẽ phải thuyết phục ban quản lý ủng hộ bạn về các hành động kỷ luật. Ghi lại tất cả các vấn đề, như Scott Vercuski mô tả. Dần dần loại bỏ những lập trình viên không thể tăng lên trong dịp này. Hãy cho những lập trình viên còn lại biết rằng họ phải học các kỹ thuật lập trình tốt và các phương pháp hay nhất và sử dụng chúng.

Có đánh giá mã, nếu bạn chưa làm điều đó. Có rất nhiều tài nguyên giải thích cách thực hiện điều này đúng cách. Chúng không nên là những trận đấu hò hét, mà nên được coi là những phiên chiến lược để tạo ra kết quả mong muốn. Thảo luận về mã. Làm thế nào nó có thể được cải thiện? Viết một số mã mới trong bài đánh giá, nếu cần thiết.

Nếu quản lý là vấn đề, hãy cho họ biết đó là vấn đề và chỉ cho họ cách họ có thể khắc phục nó. Nhưng bạn phải hùng biện và thuyết phục. Bạn phải là người bênh vực họ . Viết một bài báo về vấn đề. Làm một bài thuyết trình và trình chiếu nó. Kêu gọi động cơ lợi nhuận.

Cuối cùng, hãy là người lãnh đạo tốt nhất cho những người của bạn mà bạn có thể trở thành. Giúp họ. Giữ cho họ không bị chặn để họ có thể thực hiện công việc của mình. Một phần công việc của bạn là bảo vệ nhân viên của bạn khỏi chính sách của quản lý cấp trên và duy trì một môi trường làm việc tốt, để họ có thể tập trung làm công việc tốt nhất có thể. Nói cách khác, hãy đảm bảo rằng mọi người có thể tin tưởng bạn.


Quan tâm đến đây Robert. Bạn có bất kỳ liên kết hoặc tài nguyên nào về "Cách Không Thực hiện Đánh giá Mã". Tôi hỏi bởi vì tôi tin rằng tôi đã mắc phải một sai lầm khủng khiếp vào ngày hôm trước ... Tôi muốn có tài liệu bên ngoài khi tôi lên quản lý (một lần nữa) về Kỹ sư cao cấp này. (Tôi thậm chí còn đi xa đến mức từ chối kịch bản của một Cấp cao khác mà tôi từng làm việc dưới quyền và anh ấy đồng tình rằng câu trả lời mà tôi nhận được "có vẻ hơi sai".)
Jason D

@Jason: Không chắc điều gì đã xảy ra khi xem xét mã của bạn, nhưng bài viết này có thể cung cấp một số thông tin chi tiết: it.toolbox.com/blogs/puramu/…
Robert Harvey

không hoàn toàn như những gì tôi hy vọng, nhưng nó đã chỉ ra những sai sót cơ bản khác trong cách chúng tôi thực hiện quá trình xem xét. (ví dụ: không có bên "Người lớn" / không được ủy quyền là bên dẫn đầu đánh giá ...) Tôi sẽ sử dụng liên kết đó với những người khác để thảo luận về các cải tiến đối với quy trình xem xét mã của chúng tôi với ban quản lý và sử dụng kinh nghiệm cá nhân gần đây của tôi như một ví dụ về lý do tại sao nên có người hòa giải công bằng ...
Jason D

32

Thật buồn cười là không ai nói với bạn rằng có thể bạn thiếu kỹ năng quản lý.

Một lần, tôi đã kết thúc việc làm việc với những người không thể viết mã vòng lặp sau một năm rưỡi đào tạo. Tôi đã huấn luyện họ, cho đến khi họ có thể sử dụng một khung web đầy đủ tính năng và chỉ mất một tháng.

Có lẽ bạn nên được đào tạo.

Có lẽ bạn nên đọc một báo cáo về bạn .

Tôi không nói điều đó để tấn công bạn. Không có gì. Tôi hiểu rất rõ vấn đề, vì tôi đã từng thất bại trong việc quản lý các đội trong quá khứ.

Nhưng đừng né tránh quả bóng, bạn phải chịu trách nhiệm chính về những gì đang xảy ra trong đội của mình, bất kể bạn đã đọc bao nhiêu tài liệu thực hành tốt trong đời.

Trong trường hợp đó, hãy ngừng phàn nàn và bắt đầu làm việc. Không phải với tư cách là một lập trình viên, mà là một người quản lý.

Cuối cùng, tôi có thể sai. Có lẽ bạn đã làm đúng mọi thứ. Trong trường hợp đó, bạn có thể và có lẽ nên từ chức. Cố gắng ngăn máy bay rơi bằng cách di chuyển tay là vô ích, cho dù bạn có mạnh mẽ đến đâu. Có rất nhiều đội bình thường sẽ làm nên điều kỳ diệu bằng kỹ năng của bạn để tận dụng tối đa khả năng của họ.


6
Tôi không hiểu tại sao mọi người lại bỏ phiếu cho bạn. Bạn nêu ra quan điểm xác đáng rằng các nhà lãnh đạo / quản lý phát triển từ các kỹ sư bình thường hầu như không được đào tạo về cách quản lý con người. Sai lầm cũ "bạn là một kỹ sư tuyệt vời, bạn sẽ là một nhà quản lý tuyệt vời".
Erich Mirabal

1
Chà, vì không đúng về mặt chính trị khi nói với ai đó đang nhờ giúp đỡ rằng có thể anh ta là nguyên nhân dẫn đến tình trạng của mình. Tôi phải nói rằng, bản thân tôi không thích bị nói như vậy, nhưng đó thường là một cú sốc điện hữu ích.
e-thoả mãn

4
Cảm ơn bạn đã chỉ ra điều này - và tôi cũng không nhận được phiếu bầu thấp. Tôi chưa bao giờ được đào tạo về quản lý. Tôi đã được đưa vào vị trí (bấp bênh) này mà không có bất kỳ kinh nghiệm nào. Tôi hoàn toàn thừa nhận rằng tôi có thể có một phần lỗi. Tôi đã (nhiều lần) yêu cầu thuê một giám đốc phát triển thực tế, một người có kinh nghiệm lãnh đạo một nhóm các nhà phát triển. Yêu cầu dường như đã rơi vào tai điếc.

1
Tôi đã tìm thấy một số mẹo quản lý thực sự tốt tại manager-tools.com Họ có các podcast được chia thành các chủ đề hữu ích. Có lẽ bạn có thể tìm thấy một cái gì đó ở đó để giúp bạn.
Paul Hildebrandt

@Paul - cảm ơn vì điều đó, tôi chắc chắn sẽ kiểm tra nó!

15

Tài liệu là nguồn lực lớn nhất của bạn ... một người quản lý cũ của tôi đã nói với tôi "Nếu bạn không viết nó ra, nó đã không xảy ra.". Nếu các nhà phát triển của bạn cung cấp cho bạn một ước tính bằng văn bản về thời gian cần thiết để hoàn thành một nhiệm vụ và liên tục (và nghiêm trọng) bỏ lỡ những thời hạn đó thì điều đó nên được lập thành văn bản.

Bạn có một số loại hệ thống chấm công? hay các nhà phát triển ghi lại thời gian của họ? Nếu họ nói rằng một vấn đề sẽ mất X số ngày và sau X ngày nó vẫn chưa được giải quyết, bạn có thể đặt câu hỏi tại sao nó không được giải quyết.

Để nhắc lại ... tài liệu là chìa khóa, nếu bạn đột ngột chấm dứt một ai đó và bạn không có đầy đủ tài liệu về lý do bạn có thể tham gia vào lãnh thổ kiện tụng. Bạn càng có nhiều tài liệu, quản lý sẽ dễ dàng thấy rõ rằng các nhà phát triển cấp dưới không kéo trọng lượng của họ và nên được thay thế.

Chúc may mắn cho bạn, tôi e rằng bạn đang đi trên một con đường rất gập ghềnh ... Tôi đã ở đó và đó là một quá trình dài.


Chúng tôi sử dụng hệ thống theo dõi thời gian và công cụ theo dõi lỗi nhưng tôi không có quyền truy cập để xem thời gian của người khác. Tôi chắc chắn sẽ bắt đầu ghi chép kinh nghiệm của mình một cách chăm chỉ hơn.

Nếu bạn thu thập đủ tài liệu về ước tính của họ, bạn có thể đưa những ước tính đó cho người quản lý của mình và yêu cầu họ chạy so sánh bảng chấm công và hy vọng nó sẽ cho thấy rằng nhà phát triển đã ước tính X ngày và sử dụng X + Y ngày trên cơ sở nhất quán, mang lại cho bạn nhiều cơ hội hơn cho quyết định của bạn.

2
Nếu ước tính là vấn đề, hãy nhận ra rằng ước tính tốt cần có thời gian. Để ước tính xem một vấn đề viết mã sẽ mất bao lâu, bạn phải đi đến mức tìm ra những dòng mã nào bạn cần thay đổi, những lớp và phương thức nào bạn cần viết, v.v. và tất nhiên bạn cần phải tính trong thời gian để thử nghiệm. Tin tốt là việc tìm ra những điều này là điều bạn phải làm, vì vậy bạn không thực sự mất thêm thời gian để ước tính.
Ryan Lundy

6

Tôi đã từng ở trong tình huống này và chắc chắn có thể thông cảm. Những gì tôi đã làm là hoàn thành một nhiệm vụ nhỏ, khép kín mà tôi hoặc một nhà phát triển cấp cao khác sẽ mất không quá 2 ngày hoặc lâu hơn. Đối với nhiệm vụ này, tôi sẽ tạo vô số tài liệu xác định cách giải pháp nên được triển khai, bất kỳ thay đổi cơ sở dữ liệu nào, v.v. Sau đó, tôi sẽ ngồi lại với nhà phát triển, cung cấp cho họ hướng dẫn cấp cao về nhiệm vụ và giao nó cho họ. với thời hạn 1 tuần. Vào cuối tuần, bạn có một cái gì đó hữu hình mà bạn có thể so sánh công việc của họ với: Họ có đạt yêu cầu không? Chúng được thực hiện như thế nào? QA đã tìm thấy bao nhiêu lỗi? Họ có phá vỡ quá trình xây dựng hoặc phá vỡ theo bất kỳ cách nào không?

Khi điều đó được thực hiện, giả sử họ đã thất bại, bạn có một cuộc gặp trực tiếp và thẳng thắn với họ để giải thích về việc họ không hoàn thành nhiệm vụ của mình. Làm những điều tương tự một hoặc hai lần nữa và miễn là bạn ghi chép và truyền đạt thông tin theo chuỗi, bạn sẽ có thể đẩy chúng ra. Nó có thể khắc nghiệt, nhưng có vẻ như bạn cần mọi người hỗ trợ và bạn không có người phù hợp để làm điều đó.

Ngoài ra, hãy đảm bảo bạn tham gia phỏng vấn các ứng viên mới.


5

Lời khuyên của tôi là:

Nếu bạn là một nhà quản lý, thì bạn phải có các quyền đi đôi với trách nhiệm của mình. Những quyền này bao gồm kỷ luật những người dưới quyền bạn. Nếu ban lãnh đạo cấp trên từ chối cấp cho bạn những quyền đó, hãy từ chối nhận trách nhiệm đó.

Bạn không nhất thiết phải tỏ ra nghiêm khắc với những người giám sát của mình, nhưng đó là điều cốt yếu của những gì phải xảy ra.


2

Lời khuyên của tôi sẽ là triển khai một trình theo dõi lỗi và giao nhiệm vụ. Điều này sẽ cho thấy năng suất của bất kỳ ai trong nhóm. Lần đầu tiên chúng tôi sử dụng nó, chúng tôi đạt được mục tiêu để tổ chức nhóm và đo lường thời gian chúng tôi dành cho công việc. Một trong những điều tôi thích là khi ai đó giao một nhiệm vụ, nó sẽ gửi một email cho nhân viên và một bản sao cho người khác để kiểm tra nhiệm vụ.

Bằng cách chúng tôi đã sử dụng BugTracker.Net .


Chúng tôi có trình theo dõi lỗi và hệ thống theo dõi thời gian nhưng chúng không được tích hợp. Chúng tôi cũng để nhà phát triển nhập thời gian của họ cho một nhiệm vụ. Tôi có thể phải xem liệu chúng ta có thể theo dõi tổng thời gian dành cho việc hoàn thành bài tập trong trình theo dõi lỗi so với thời gian ước tính hay không.

Khi đó, tôi sẽ nghĩ rằng đó là một vấn đề đạo đức từ nhân viên mà bạn sẽ phải tập trung vào.
Nelson Miranda

Nghe có vẻ là một nơi đáng yêu để dành 8 giờ mỗi ngày ... KHÔNG! Từ khi nào chúng ta lập trình viên trở thành công nhân nhà máy! Tình hình luân chuyển nhân viên tại tổ chức của bạn như thế nào và bạn lãng phí bao nhiêu tiền vì không thể phù hợp với bản chất con người! Có ai làm việc ở đó bị cao huyết áp không! Điều duy nhất bạn có thể quản lý là một tiệm bán đồ cũ. Không ai đáng giá muối của họ muốn làm việc trong môi trường đó. Rất tiếc, đã đến giờ giải lao của tôi. ;-)
Sam

2

Tôi tự hỏi làm thế nào mà những người này vào công ty ngay từ đầu:

Những nhà phát triển này không chỉ thiếu kỹ năng về các khái niệm lập trình mà còn thiếu khả năng hình thành giải pháp cho một vấn đề trong mã.

Những thứ đơn giản như viết vòng lặp là khó khăn đối với họ ...

Không nghi ngờ gì nữa, công ty của bạn cần đầu tư nhiều thời gian và công sức hơn vào việc tuyển dụng lực lượng lao động, như người ta thường nói: vội vàng gây lãng phí.

Bây giờ, khi bạn đang ở trong tình huống đó như bạn mô tả, hãy hoàn thành báo cáo của bạn, (như những người khác đã gợi ý) làm cho nó ngắn gọn và nhấn mạnh rằng điều này khiến công ty tốn bao nhiêu tiền, gửi và chờ đợi điều tốt nhất (như bạn đã nói rằng bạn "không có nhờ vào việc thực sự kỷ luật một cá nhân. ").


3
Nhân viên phát triển không được bao gồm trong quá trình tuyển dụng, đó là cách họ tham gia.

2

Tôi đã đọc điều này một thời gian trước đây về việc khuyến khích các lập trình viên muốn trở thành người giỏi nhất.

Nerd Herding


Bài báo tuyệt vời. Liên kết tốt +1
Smalltown2k

Làm tốt vì nhận ra cơ hội không phải là trở ngại.
Sam

1

Bạn đã đề cập rằng đối với nhóm của bạn, bạn "cung cấp phản hồi về hiệu suất của họ".

Vì thế:

  1. Ngồi xuống với nhóm của bạn.
  2. Đưa cho họ bản in của trang này và cho họ biết bạn đã đăng nó về họ.
  3. Hãy để họ đọc nó.
  4. Yêu cầu họ giúp bạn giải quyết vấn đề.
  5. Nghe và viết nó ra.
  6. Đưa điều đó cho nhóm quản lý của bạn.

1

Phần mềm mọi người là một cuốn sách khác nên tham gia vào danh sách của bạn.

Tuy nhiên, khi tôi đọc nó, tôi không thấy nó thực tế vì không ai trong công ty muốn thử các khuyến nghị của nó.


Lần cuối cùng tôi ở trong tình huống đó - tôi bỏ việc và đi nơi khác, bây giờ tốt hơn nhiều khi làm việc với một nhóm phát triển khác, những người thực sự có đủ kỹ năng để phát triển thực sự.
James

0

Có vẻ như bạn đang đi đúng đường.

Nếu bạn cho họ thấy những con số khó, họ sẽ thấy mọi thứ rõ ràng hơn - tạo mã hóa một bài tập và giao nó cho một số lập trình viên khác nhau để họ tự làm. Hãy tự mình kiểm chứng nó.

Giữ thông tin chi tiết về thời gian mỗi cái, mã tạo ra bao nhiêu lỗi.

Hiển thị các con số cho quản lý cấp trên, bây giờ họ sẽ được thuyết phục.


0

Quyển sách

Code Complete: Sổ tay thực hành về xây dựng phần mềm của Steve McConnell

là một nguồn tốt có thể giúp tìm hiểu các phương pháp hay nhất.

Yêu cầu mỗi nhà phát triển đọc và tìm hiểu điều này với các cuộc thảo luận có thể giúp ích một chút nhưng điều quan trọng nhất là định lượng kết quả. Nhận lương của bản thân và những người còn lại trong nhóm, sau đó tính xem bạn có thêm bao nhiêu thời gian để sửa lỗi cho người khác với chi phí cộng thêm cho việc các nhà phát triển làm rối tung mọi thứ bắt đầu.

Sau đó, chỉ ra cách một nhóm các nhà phát triển giỏi hơn có thể cải thiện ROI.


OP đã nói rằng anh ấy sử dụng Code Complete. Bất kỳ cuốn sách hay nào khác?
aaaa bbbb

0

Giữ báo cáo ngắn gọn. Đừng làm cho nó dài dòng. Đặt nó về số tiền họ đang mất cho cái này.


0

Chúng tôi hiện có một công cụ đo lường mức độ phức tạp của các mô-đun mã của chúng tôi. Nó chạy trên các mô-đun PL / SQL của chúng tôi, nhưng tôi tin rằng có những công cụ có sẵn trên các môi trường khác.

Có nhiều phần khác nhau xuyên suốt, nhưng thật khó để quản lý khi một số mô-đun chính của chúng tôi được đánh dấu là 'không thể kiểm tra được'.

Chúng tôi đã kết hợp với một công cụ phân tích chính xác giúp làm nổi bật chức năng trùng lặp và tiếp cận đóng gói tất cả điều này thành một đánh giá về 'nợ kỹ thuật'.

Vì chúng tôi có thể trình bày điều này trên cơ sở từng mô-đun, nên sẽ dễ dàng xác định được thủ phạm (chúng tôi đã làm, nhưng không báo cáo). Như vậy, tổ chức hướng tới sự cải tiến trong tương lai hơn là chỉ tay.

(Ngoài ra, tất cả mã hiện đã được gửi để xem xét và phải cung cấp phân tích mã kèm theo. Mọi thứ chắc chắn đang trở nên tốt hơn ở đây.)


0

Điều này chỉ đơn giản là không thể thực hiện được trừ khi bạn có lực kéo tốt với ban quản lý. Theo kinh nghiệm của tôi, nếu bạn cố ép nó, bạn có thể gặp rắc rối.


0

Chỉ là một ý tưởng.

Tôi giả sử bạn sử dụng hệ thống kiểm soát phiên bản nguồn như SVN. Vì vậy, hãy đưa ra chính sách xem xét các cam kết và từ chối những cam kết không tốt. Sau đó, chỉ cần hiển thị cho các nhà quản lý khác số liệu thống kê về các cam kết bị từ chối để chứng minh rằng các nhà phát triển tầm thường đang phải trả giá đắt cho công ty.


0

Đây là một ý tưởng khác dành cho bạn: Đừng sửa chữa những gì chúng bị hỏng. Gửi lại để làm lại trong email bằng cách cho họ biết điều gì sai và cách khắc phục (chỉ trong điều kiện chung) và quản lý cc. Hãy nhớ lưu ý để cấp quản lý hiểu chính xác điều này sẽ ảnh hưởng như thế nào đến thời hạn cuối cùng của bạn. Điều này tạo ra tài liệu về các vấn đề hiệu suất cho bạn và một số người trong số họ có thể sẽ không còn tệ nữa khi họ phải sửa lỗi của chính mình.

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.