Phải đặt mục tiêu cho nhà phát triển, mặc dù mục tiêu không hoạt động [đã đóng]

Người ta thường chấp nhận rằng việc đặt ra các mục tiêu có thể đo lường được đối với các nhà phát triển phần mềm là không hiệu quả , vì quá tập trung vào các mục tiêu có thể dẫn đến hành vi đi ngược lại các mục tiêu của tổ chức (được gọi là " rối loạn chức năng đo lường ").

Tuy nhiên, trong công ty của tôi, chúng tôi được yêu cầu đặt ra các mục tiêu cho tất cả nhân viên và được Bộ phận Nhân sự khuyến khích để họ trở nên THÔNG MINH . Trước đây, các đồng nghiệp quản lý cấp một của tôi (trưởng nhóm) và tôi đã thử một số cách tiếp cận:

1. Đặt các mục tiêu có thể đo lường bổ sung cho công việc bình thường, như "Đào tạo về công nghệ X", "Tạo tài liệu cho đoạn mã Y mà không ai hiểu", v.v. Khi nói đến đánh giá hiệu suất hàng năm, đánh giá các nhà phát triển không dựa trên các mục tiêu đã viết, mà dựa trên quan điểm của tôi về giá trị không thể đo lường của công việc bình thường của họ, vì đó thực sự là điều mà công ty quan tâm.
2. Đặt ra các mục tiêu rất cụ thể như "số ngày làm việc được hệ thống quản lý tác vụ ghi lại", "số lượng lỗi được đưa vào", "số lần sản xuất đã gây ra". Điều này dẫn đến ước tính bị thổi phồng và phân loại lỗi không chính xác, nhằm đạt được "điểm số" tốt hơn. Điều thú vị là ngay cả những nhà phát triển đạt điểm cao trên hệ thống này cũng không thích nó, vì lòng tin nội tại trong đội đã bị tổn hại và họ không phải lúc nào cũng cảm thấy mình xứng đáng với vị trí cao của mình.
3. Đặt các mục tiêu mơ hồ là biến thể của "Làm tốt công việc bình thường của bạn". Khi nói đến đánh giá hàng năm, xếp hạng của họ phản ánh hiệu quả hoạt động so với các mục tiêu, nhưng bản thân các mục tiêu không thể đo lường hoặc có thể đạt được, điều này không được chấp nhận.

Không ai trong số này là lý tưởng. Nếu bạn từng ở trong tình huống tương tự khi phải tạo ra các mục tiêu có ý nghĩa, có thể đo lường được cho các nhà phát triển phần mềm bất chấp bằng chứng chống lại tính hiệu quả của chúng, thì cách tiếp cận nào phù hợp nhất với bạn?

Các câu hỏi liên quan mà tôi thấy không hoàn toàn giải quyết cùng một điểm:

• Một số mục tiêu hiệu suất tốt cho một kỹ sư phần mềm là gì?
• Đặt mục tiêu Hiệu suất cho Nhà phát triển
• Các chỉ số hiệu suất phù hợp cho lập trình viên là gì?
• Kỹ thuật đo lường năng suất công bằng cho lập trình viên là gì?
• Tôi cần một số "Mục tiêu" nghề nghiệp cho năm tới

Cập nhật (ngày 18 tháng 11 năm 2009): Có 10 phiếu ủng hộ cho câu hỏi của tôi và các câu trả lời được xếp hạng cao nhất chỉ có 4 phiếu ủng hộ (trong đó có một phiếu bầu của tôi). Tôi nghĩ rằng điều này cho chúng ta biết điều gì đó: có lẽ Joel và những người khác đã đúng, và sự khôn ngoan kết hợp của stackoverflow không thể đưa ra bất kỳ mục tiêu hấp dẫn, có thể đo lường nào cho các nhà phát triển. công việc. Cảm ơn vì đã cố gắng!

cách tiếp cận nào phù hợp nhất với bạn?

Chỉ có một mục tiêu: vượt qua kiểm tra mã / đánh giá ngang hàng, với tôi là người đánh giá, mà tôi không tìm thấy bất kỳ lỗi nào hoặc có bất kỳ lời chỉ trích nào khác, điều đó khiến tôi yêu cầu bạn làm lại điều gì đó.

Ghi chú:

• Tôi đã không đo lường khả năng hoàn thành nhanh chóng của những người mới thuê và không khuyến khích họ: Tôi muốn mọi người học cách hoàn thành tốt (vì nếu hoàn thành không tốt thì cũng không xong)
• Mọi người đã học được những gì tôi tìm kiếm trong một lần đánh giá mã: vì vậy đó là cơ hội học hỏi và thước đo kiểm soát chất lượng, chứ không chỉ là mục tiêu quản lý
• Nhận xét của tôi sẽ có hai loại:
  1. Đây là một lỗi: bạn phải sửa lỗi này trước khi đăng ký
  2. Như một gợi ý, tôi sẽ làm như vậy và tương tự
• Sau một thời gian, các đánh giá của tôi về mã của một người sẽ ngừng tìm thấy bất kỳ mục "phải sửa" nào (tại thời điểm đó, tôi sẽ không cần phải xem lại công việc của họ nữa).

Cá nhân tôi cố gắng đặt ra hai loại mục tiêu:

• Mục tiêu tập trung vào kinh doanh (đây là lý do tại sao chúng tôi được trả tiền). Ví dụ: "hoàn thành dự án X trước ngày 1 tháng 6 năm 2009"). Các mục tiêu này thường được chia sẻ giữa một số thành viên trong nhóm (và họ nhận thức được điều này). Nhóm có thể vượt mục tiêu bằng cách đưa dự án vào sớm hoặc vượt quá chức năng cần thiết. Các cá nhân có thể vượt mục tiêu bằng cách tạo ra nhiều chức năng hơn, có ít lỗi chống lại họ hơn hoặc huấn luyện và hỗ trợ các thành viên khác trong nhóm.

• Các mục tiêu phát triển cá nhân, chẳng hạn như hoàn thành một dự án liên quan đến công nghệ mà nhà phát triển muốn thêm vào bộ kỹ năng của họ, hiểu miền của người dùng tốt hơn, đạt được kinh nghiệm lãnh đạo, v.v.

Tôi cảm thấy rằng điều quan trọng là:

• Mục tiêu là THÔNG MINH
• Mục tiêu phù hợp với nhu cầu của doanh nghiệp
• Bạn bao gồm "công việc bình thường" trong các mục tiêu, trên thực tế đây là những mục tiêu quan trọng nhất!
• Nhân viên có một số cơ hội để vượt qua các mục tiêu bạn đặt ra

Cuối cùng, tôi sẽ tránh xa các chỉ số phần mềm làm mục tiêu - chúng quá dễ chơi và có thể sẽ không cung cấp cho bạn những gì bạn cần. Tôi sẽ chỉ sử dụng một số liệu mà tôi muốn huấn luyện ai đó trong hoặc ngoài một hành vi cụ thể.

Tất cả những điều này đều dẫn đến một thực tế là "cấp quản lý đầu tiên", và hầu hết mọi cấp quản lý đều không biết nhân viên của họ. Thay vì là một phần của việc lập kế hoạch và phát triển hàng ngày, những thứ như SMART xuất hiện. Nếu các nhà quản lý dành nhiều thời gian hơn cho những người làm công việc thực tế, thì điều này sẽ không cần thiết.

Cá nhân tôi, tôi thích làm việc trong một môi trường nhanh nhẹn, nơi rõ ràng ai trong số các nhà phát triển thực hiện về năng suất và nhận thức về chất lượng. Một phương pháp tiếp cận nhanh thực sự yêu cầu không chỉ các nhà phát triển, mà các nhà thiết kế, người thử nghiệm, khách hàng và người quản lý sản phẩm đều phải tham gia vào quy trình. Điều này đương nhiên dẫn đến những hiểu biết tốt hơn từ quan điểm của các nhà quản lý.

Các mục tiêu có thể đo lường mà tôi đã thấy cho đến nay:

• Vượt qua kỳ thi chứng chỉ
• Nghiên cứu công nghệ X và tổ chức một buổi thuyết trình về nó
• Số lượng thay đổi phá vỡ bản dựng được cam kết
• Số lượng bài báo wiki được viết về quản lý tri thức nội bộ

Làm thế nào về việc hỏi trực tiếp các nhà phát triển của bạn nếu họ có một số ý tưởng để phát triển cá nhân mà sau đó có thể được sử dụng cho các mục tiêu?

Phải đặt mục tiêu cho nhà phát triển, mặc dù chúng không hoạt động

Nếu các nhà phát triển của bạn không hoạt động, có lẽ một số mục tiêu chỉ là thứ họ cần để khuyến khích họ? ;-)

"Đảm bảo rằng ít nhất n% mã của bạn được kiểm tra bằng thử nghiệm đơn vị phù hợp" Sử dụng công cụ xác minh để chứng minh điều đó và nhờ người khác đánh giá về chất lượng thử nghiệm.

Tôi nghĩ rằng có những mục tiêu rất cụ thể ở phía trước, tức là SMART (có thể chúng tôi thực sự làm việc ở cùng một nơi), có vẻ là một ý tưởng hay nhưng nó không thực tế cho hầu hết các đội.

Vấn đề thực sự là sự thay đổi mục tiêu gia tăng của chúng tôi. Công việc kinh doanh thay đổi và với tư cách là nhà phát triển, chúng ta cần phản ứng và phản ứng đúng cách và trong một khung thời gian hợp lý.

Cân nhắc thiết lập các mục tiêu gắn liền với nhóm của bạn hoặc mục đích của nhóm trong tổ chức. Nhóm của bạn sẽ không được tài trợ nếu nó không phục vụ một mục đích - mục đích vĩ mô. Có các mục tiêu chung tồn tại trong toàn bộ nhóm của bạn và phù hợp với doanh nghiệp. Trao cho mọi người trách nhiệm và quy trách nhiệm cho mọi người. Kỷ niệm những thành công và thất bại của họ (nếu đôi khi chúng ta không thất bại thì có thể chúng ta đang không cố gắng và đó là điều bạn muốn ở mọi người). HTH

Chúng tôi có một số chỉ số được thu thập khi các lập trình viên làm việc, chẳng hạn như:

• Số SLOC đã thay đổi / thêm vào
• Số lỗi / lỗi được đưa vào trong các giai đoạn khác nhau của quy trình (trong quá trình đánh giá ngang hàng, bài đánh giá ngang hàng, sau khi phát hành)
• Thay đổi các yêu cầu được thực hiện / bị từ chối
• Tài liệu chính thức (mô tả phiên bản phần mềm, tài liệu thiết kế, v.v.)

Tất cả những điều này là những thứ hữu hình mà tôi thấy hữu ích trong các bài thuyết trình để quản lý và đảm bảo chất lượng phần mềm. Nhưng tôi chưa bao giờ thấy chúng cực kỳ hữu ích trong các đánh giá thực tế về hiệu suất của mọi người - đó là điểm được thực hiện bởi một số liên kết bạn đã liệt kê. Tôi thấy rằng những điểm của Joel ở đây là hợp lệ - các chỉ số không bao giờ thúc đẩy bầu không khí nhóm tốt.

Thật không may, tất cả chúng ta đều đang sống trong một thế giới mà các chỉ số được yêu cầu bởi những người khác (quản lý, đảm bảo chất lượng, nhà thầu bên ngoài, v.v.). Tôi nhận thấy rằng hành động cân bằng là bắt buộc - cung cấp các số liệu đó, nhưng cũng cung cấp bằng chứng về tính vô hình - vô hình là những gì mà mỗi lập trình viên đã hoàn thành mà không nhất thiết phải được theo dõi. Ví dụ, tôi có một lập trình viên đã dành rất nhiều thời gian để điều tra mã kế thừa mà không ai khác muốn chạm vào. Mặc dù các chỉ số của anh ấy thấp trong khoảng thời gian đó, nhưng nỗ lực đó là vô giá.

Cách duy nhất tôi tìm thấy để đưa những thứ như vậy vào là thúc đẩy việc tạo ra một danh mục vô hình bổ sung và cân bằng nó với các chỉ số khác. Thông thường, điều này là đủ để cân bằng cho một lập trình viên cụ thể.

Một trong những vấn đề dường như là các tổ chức CNTT của một bộ phận / phòng ban không có các mục tiêu chiến lược có thể đo lường được. Nếu họ làm được thì việc đặt mục tiêu cho các cá nhân sẽ dễ dàng hơn.

Ví dụ: Nếu có một sáng kiến ​​của bộ phận để giảm số lượng phiếu vấn đề được nêu ra, thì bạn có thể đặt mục tiêu cho từng cá nhân dựa trên số lượng phiếu liên quan đến phần mềm mà họ trông coi.

Vì phát triển phần mềm chủ yếu là so sánh nên sẽ có ý nghĩa hơn nếu đặt mục tiêu ở cấp độ nhóm, và sau đó xếp hạng các cá nhân theo đóng góp của họ cho nhóm.

Một mục tiêu mà tôi thích là:

Thu hút N đánh giá tích cực về sự tham gia của bạn vào một dự án từ khách hàng của dự án.

Điều này rất hữu ích vì luôn có một số phản hồi tích cực bằng văn bản từ khách hàng (nội bộ hoặc bên ngoài). Nó không khó để có được, nó phù hợp và nó là một đánh dấu dễ dàng, nhưng không vô nghĩa trong danh sách.

Tôi nghĩ rằng làm thế nào để gắn kết sự phát triển cá nhân với các dự án đang thực hiện là một điểm mấu chốt. Việc để các nhà phát triển tự phân tích để tìm ra điểm yếu cùng với phản hồi về những người khác có thể là một cách để tìm ra những gì có thể được cải thiện và sau đó tìm cách đo lường nó. Ví dụ, tôi có thể thấy rằng tôi hiếm khi ghi lại các hạng mục đã hoàn thành và vì vậy, đối với mục tiêu của tôi trong năm, tôi có thể nói rằng tôi muốn cải thiện điều này và số lượng tài liệu tôi tạo ra có thể là thước đo cho điều đó. Nó có thể hoạt động hoặc nó có thể phản tác dụng tùy thuộc vào cách tôi làm theo nó thực sự. Một mặt, có thể có những mối quan tâm xác đáng về việc này là cách tôi cải thiện công việc của mình và làm những gì có thể được xem là cách thích hợp trong khi quan điểm hiếu chiến hoặc ấu trĩ thụ động sẽ tạo ra một núi tài liệu nếu không phải như vậy '

Xác định một nhà phát triển hiệu quả là một yếu tố khác cho vấn đề này. Đó có phải là người sửa lỗi tốt nhất? Công việc mới có nhanh nhất không? Công việc mới có hoàn thành với các bài kiểm tra và tài liệu mặc dù nó không được thực hiện nhanh chóng không? Những gì bạn đang gọi là hiệu quả vì phản hồi tiêu chuẩn "nó phụ thuộc" cần được làm rõ ở đây.