it-swarm-vi.com

Ví dụ về mục tiêu tốt SMART cho lập trình viên là gì?

Tiếp theo từ câu hỏi này , tôi tự hỏi liệu dân gian có thể đề xuất một số mẫu về mục tiêu "tốt" trong chu trình đánh giá định kỳ cho lập trình viên không?

Hãy xác định SMART từ các định nghĩa phổ biến nhất trong mục nhập Wikipedia :

  • Riêng
  • Đo lường được
  • Có thể đạt được
  • Liên quan, thích hợp
  • Giới hạn thời gian
20
Mike Woodhouse

Tôi đã nhận ra rằng SMART mục tiêu được sử dụng tốt nhất khi mọi người bị thiếu sót cần sửa, và không tốt cho những lúc bạn muốn mọi người phát triển hoặc đi từ tốt đến vĩ đại. Nếu chẳng hạn như ai đó không làm bảng chấm công và điều này gây tổn hại cho công ty vì đôi khi bạn phải trì hoãn việc lập hóa đơn, bạn có thể có một mục tiêu thông minh như "trong 6 tuần tới, ít nhất 5 tuần sẽ hoàn thành sau 10 giờ sáng sáng thứ hai tuần sau. "6 tuần sau bạn có đúng hoặc sai; nhà phát triển đã thực hiện hoặc bỏ qua nó. Hoặc là thói quen mới được áp dụng hoặc bạn có thể quyết định xem bạn có muốn thuê người không trì hoãn việc lập hóa đơn của bạn không . Hoạt động cho những người có thói quen xấu khác: "trong hai tuần tới, ít nhất 75% số lần đăng ký của bạn sẽ có nhận xét đăng ký theo hướng dẫn đăng ký (liên kết đến tài liệu nội bộ)."/đã không ở cuối thời gian ngắn đó.

Nơi tôi thấy các cấu trúc này ít hữu ích hơn là khi khung thời gian kéo dài, khi thành tích bạn muốn mờ (học một ngôn ngữ, hữu ích hơn) hoặc khi nó không đạt được nếu mục tiêu không đạt được (bạn có thể coi trọng chứng chỉ, nhưng nếu ai đó thất bại thử nghiệm của họ có lẽ bạn sẽ không có hành động kỷ luật.) Đột nhiên tất cả lợi ích của mục tiêu thông minh giảm đi. Đừng cố sử dụng chúng cho bất kỳ điều gì khác ngoài các hành động khắc phục và chúng dễ viết, chúng giúp nhà phát triển đạt đến mức mong đợi và chúng dễ dàng kiểm tra khi hết thời gian. Gặp khó khăn khi viết chúng có nghĩa là chúng không phải là công cụ phù hợp cho mục tiêu này.

37
Kate Gregory

Vì tôi sắp đi vào một cuộc trò chuyện thiết lập khách quan với sếp của mình, tôi nghĩ rằng tôi đã thêm một vài ví dụ tương tự như một số tôi đang xem xét đề xuất cho chính mình:

  • Tăng độ bao phủ thử nghiệm cho mã trong Dự án X lên ít nhất 95% vào ngày 31 tháng 3.
  • Hoàn thành và phân phối bản thảo đầu tiên của tài liệu Kiến trúc Dự án Y trước ngày 30 tháng 4
  • Thu thập nhận xét đánh giá cho tài liệu kiến ​​trúc, cập nhật khi cần thiết và phát hành v1.-0 của tài liệu trước ngày 30 tháng 6

Tôi hy vọng công việc bổ sung sẽ thành hiện thực trong thời gian tôi đã chỉ định (sau tất cả luôn luôn có trước đó) và công việc đó có thể có ảnh hưởng đến khía cạnh "Đúng lúc". Đó không phải là một vấn đề: các mục tiêu nên được xem xét thường xuyên để đảm bảo rằng chúng tiếp tục đáp ứng tiêu chí "Có thể đạt được". Tôi sẽ cần đảm bảo rằng tôi sẽ giữ người quản lý của mình trong vòng lặp này - không ai thích những bất ngờ cuối năm khó chịu ...

7
Mike Woodhouse

Nếu bạn bán phần mềm hoặc sản phẩm có phần mềm trong đó ...

Tăng doanh số n%.

Có thật không.

Nếu phần mềm không hoạt động, bạn sẽ không bán được nhiều.

Nếu phần mềm hoạt động THẬT SỰ THỰC SỰ, bạn sẽ bán được nhiều.

(Điều này sẽ có những kẻ phần mềm theo dõi những người bán hàng như diều hâu đảm bảo họ không thổi phần thưởng hiệu suất của họ.)

Nếu phần mềm của bạn là hệ thống nội bộ :

cắt giảm chi phí kinh doanh n%.

Nếu các hệ thống phần mềm mới mất gấp 10 lần thì sẽ phải trả tiền cho công ty. Nếu hệ thống mới nhanh và ngăn ngừa lỗi, công ty sẽ tiết kiệm tiền.

Cách tiếp cận này có vẻ như áp dụng cho những người bán hàng hoặc có thể là VP của quá trình thay đổi doanh nghiệp, nhưng thực sự, các nhà phát triển phần mềm là tiền tuyến cho cả hai loại quy trình.

Ý tưởng cơ bản của tôi ở đây là cố gắng sắp xếp rõ ràng cơ cấu khen thưởng nhân viên với kết quả tốt nhất có thể cho công ty.

2
Tim Williscroft