Mục tiêu SMART có hữu ích cho lập trình viên không? [đóng cửa]

Một số tổ chức tôi biết sử dụng mục tiêu SMART cho lập trình viên của họ. SMART là từ viết tắt của Cụ thể, Đo lường được, Có thể đạt được, Có liên quan và Giới hạn Thời gian. Chúng khá phổ biến trong các tập đoàn lớn.

Kinh nghiệm trước đây của tôi với các mục tiêu SMART không phải là tất cả tích cực. Các lập trình viên khác có tìm thấy cho họ một cách hiệu quả để đo lường hiệu suất không? Một số ví dụ về các mục tiêu SMART tốt cho các lập trình viên (nếu chúng tồn tại).

Trong một từ

Không

Thứ nhất: Tôi chưa bao giờ có các dự án của mình đủ ổn định để tôi có thể thiết lập các mục tiêu SMART với bất kỳ ý nghĩa nào. Khoảng thời gian giữa khi vai trò của tôi thay đổi trong một dự án và khi đánh giá hoàn hảo được thực hiện quá xa so với đồng bộ hóa.

Thứ hai: Đo lường hiệu suất của từng cá nhân là một cách tuyệt vời để tạo ra tâm lý "không phải việc của tôi" và cạnh tranh tiêu cực giữa các cá nhân và / hoặc các nhóm phụ khác nhau trong một tổ chức. Thật dễ dàng để chơi trò chơi hệ thống và đảm bảo rằng bạn đang tự mình tìm kiếm và không thực sự giúp đỡ toàn bộ đội. Chúng ta nên khuyến khích mọi người trở thành người chơi trong đội, nhưng sau đó các tổ chức của chúng ta lại làm điều ngược lại.

Hầu hết các loại hệ thống này là phản đối với việc xây dựng đội ngũ. Mary Poppendieck đã thực hiện công việc này rõ ràng hơn nhiều so với những gì tôi có thể làm trong LeanEssays: Bồi thường cho đội .

Sue nhận được một cuộc gọi từ Janice trong nguồn nhân lực. Cúc Sue, cô nói, một công việc tuyệt vời mà đội của bạn đã làm! Và cảm ơn vì đã điền vào tất cả các mẫu đầu vào thẩm định. Nhưng thực sự, bạn không thể cho mọi người đánh giá hàng đầu. Xếp hạng trung bình của bạn phải là 'đáp ứng mong đợi'. Bạn chỉ có thể có một hoặc hai người 'vượt quá mong đợi' ...

... Một trong những nhà lãnh đạo tư tưởng vĩ đại nhất của thế kỷ 20, W Edwards Deming, đã viết rằng thiệt hại không thể đo lường được tạo ra bằng cách xếp hạng con người, hệ thống công đức và trả lương khuyến khích. Deming tin rằng mỗi doanh nghiệp là một hệ thống và hiệu suất của các cá nhân phần lớn là kết quả của cách hệ thống vận hành. Theo quan điểm của ông, hệ thống gây ra 80% các vấn đề trong một doanh nghiệp và hệ thống là trách nhiệm của ban quản lý. Ông viết rằng sử dụng những lời hô hào và khuyến khích để khiến các cá nhân giải quyết các vấn đề quản lý đơn giản là không hiệu quả. Deming phản đối xếp hạng vì nó phá hủy niềm tự hào về tay nghề, và công đức tăng lên vì họ giải quyết các triệu chứng, chứ không phải là nguyên nhân, của các vấn đề.

... Chúng ta hãy nhìn sâu hơn vào các hệ thống đánh giá và khen thưởng nhân viên, và khám phá những gì khiến họ trở nên rối loạn ...

Chúng tôi đã sử dụng các mục tiêu SMART trong tập đoàn lớn nơi tôi làm việc. Chúng hầu như vô nghĩa đối với hầu hết các phần.

Mục tiêu đi xuống từ quản lý cấp trên và cao cả và trừu tượng. Liên quan chúng với các dự án cụ thể và phát triển thường là một trò đùa. Hầu hết các dự án đi vào nhóm đến từ doanh nghiệp và để đáp ứng một nhu cầu kinh doanh cụ thể. Vì vậy, bạn mã hóa dự án, đưa nó vào sản xuất và làm một công việc tuyệt vời như bình thường. Làm thế nào mà liên quan đến một mục tiêu mà ai đó trong quản lý cấp trên đã đưa ra?

Chúng tôi làm tốt hơn nhiều khi là một nhóm khi chúng tôi đưa ra các mục tiêu của riêng mình. Đôi khi chúng bao gồm đào tạo về một chủ đề cụ thể hoặc thực hiện thay đổi quy trình mới, một cái gì đó thực sự có thể liên quan đến những gì chúng ta làm. Chúng vẫn không thực sự liên quan đến hoạt động mã hóa hàng ngày bởi chúng ít nhất là những thứ giúp di chuyển nhóm trong môi trường công ty.

BIÊN TẬP

Như Mnementh đã chỉ ra rất chính xác, câu trả lời của tôi dựa trên các mục tiêu SMART không phải là, tốt, SMART. Tôi sẽ thêm vào câu trả lời của tôi rằng nếu bạn là người quản lý lập trình viên và muốn thực hiện các mục tiêu SMART, hãy chắc chắn rằng họ là SMART. Sử dụng ví dụ của người quản lý của tôi như một cách KHÔNG để thực hiện các mục tiêu SMART. Nếu bạn không quản lý lập trình viên và ai đó nói với bạn rằng bây giờ bạn sẽ bắt đầu sử dụng các mục tiêu SMART và họ kết thúc giống như chúng ta đã làm, thì hãy hiểu rằng bạn đã có những người trong ban quản lý cấp cao thích những từ buzz và có thể kiểm tra họ ra khỏi một danh sách những điều họ đã thực hiện.

Có rất nhiều nghiên cứu để chỉ ra rằng các lập trình viên sẽ làm một công việc tuyệt vời với bất kỳ tiêu chí nào được trình bày cho họ, với chi phí cho các mục tiêu khác có thể.

Điều này có nghĩa là họ sẽ làm tốt việc đạt được các mục tiêu cụ thể và có thể đo lường được, và kém hơn ở bất cứ điều gì không được liệt kê cụ thể. Điều đó có nghĩa là bạn phải cực kỳ cẩn thận trong việc thiết lập mục tiêu.

Bạn không muốn đặt các dòng mã làm mục tiêu. Tin tôi đi Đặt lỗi đã được sửa dẫn đến việc viết mã lỗi để bắt đầu. Yêu cầu sửa lỗi trong mã hiện tại sẽ dẫn đến các định nghĩa rất tự do về "lỗi" (và có thể là "sửa"). (Ngoài ra, phần "có thể đạt được" phụ thuộc vào mức độ lỗi của mã.) Yêu cầu tính đầy đủ của tính năng trong một thời gian nhất định, tốt ....

Những gì bạn muốn lập trình viên của bạn làm là viết những thứ hữu ích trong một khoảng thời gian hợp lý với chất lượng mã tốt, và nâng cao và sửa đổi nó trong khi duy trì chất lượng mã. Bản thân tôi chưa bao giờ thấy các mục tiêu cụ thể và có thể đo lường được sẽ là tiêu chí tốt.

Chúng tôi trải qua bài tập này mỗi năm. Vấn đề là các nhà phát triển ở đây có xu hướng tự chủ rất ít đối với những gì họ làm (nhiệm vụ được xác định bởi người quản lý sản phẩm). Chúng tôi may mắn rằng, ít nhất là trên giấy tờ, chúng tôi có thời gian dành riêng để theo đuổi mục tiêu của mình. Trên thực tế, chúng ta nhận được ít hơn nhiều, tuy nhiên.

Trong khuôn khổ đó, tôi đã thấy rằng việc thiết lập các mục tiêu tự phát triển hoạt động thực sự tốt. Ví dụ: hai mục tiêu của tôi từ năm ngoái là:

1. Để đọc các mẫu thiết kế và viết các dự án đồ chơi để tìm hiểu và trình diễn từng mẫu vào năm tới. Điều này đã kết thúc mất 2 năm, nhưng sự cải thiện về mã hóa của tôi đã được chú ý.
2. Để nghiên cứu các tính năng ngôn ngữ .NET 3.5 và thực hiện một bài thuyết trình cho đồng nghiệp của tôi mỗi quý. Điều này đã kết thúc là 1 bài thuyết trình về LINQ mà đồng nghiệp của tôi đánh giá cao ở nhiều mức độ khác nhau giữa sự thờ ơ và quan tâm nhẹ. Tuy nhiên, tôi đã học được rất nhiều và đã chứng minh kiến ​​thức C # của mình Tôi đã được chuyển sang làm việc trong một dự án mới khá tuyệt vời.

Vì vậy, yeah, tôi đã được hưởng lợi và vui vẻ trong khi làm điều đó.

Thành thật mà nói, trong công ty của chúng tôi, tôi nghĩ rằng việc thiếu nhà phát triển tốt Các mục tiêu SMART có liên quan nhiều hơn đến sự ác cảm với đầu gối đối với công ty.

Có, nếu được đặt chính xác.

Nếu được đặt chính xác, các mục tiêu có thể cải thiện cả nhóm và từng người. Họ nên được liên kết với công việc quá và thiết kế cho cá nhân.

Tôi đã từng ở những nơi mà cả một đội DBA có cùng mục tiêu nhạt nhẽo, cũng như những cấp độ cao giúp tôi giảm bớt "tuân thủ KPI toàn cầu và khu vực như được xác định bởi ủy ban KPI". Điều mà không ai biết tất nhiên ..

Sau đó, một lần nữa, tôi đã ở những nơi mà người quản lý đặt ra các mục tiêu cá nhân với ý nghĩ trước mắt.

Biên tập:

Tôi đã đọc bài viết Mary Poppendieck và nó không phải là về SMART. "Nhận thức về sự bất khả thi" chẳng hạn "Có thể đạt được".

Mục tiêu nên được đặt ra cho cá nhân, để chia sẻ điểm mạnh của họ, giúp khắc phục điểm yếu, đóng góp cho nhóm. Đo lường là dành cho cá nhân.

Không nên so sánh x vs y.

Các mục tiêu cho x và y phải tương xứng với thứ hạng hoặc vị trí của chúng trong một hệ thống: một mục tiêu không đặt ra các mục tiêu tương tự cho người cao niên và thiếu niên. Thật không công bằng.

Một số điểm chuẩn là cần thiết để đặt tiền thưởng hoặc tiền lương từ một số tiền giới hạn: chúng ta có nên đếm các dòng mã thay thế không? Đánh giá ngang hàng?

Và chỉ cho tôi những lựa chọn thay thế hợp lệ sẽ không yêu cầu tôi thay đổi đạo đức công ty toàn cầu. Tôi không có những lời chỉ trích của SMART: Tôi làm có những lời chỉ trích của các nhà quản lý kém đái ...

Là một khung hiệu suất, SMART chỉ hiệu quả như việc các mục tiêu của bạn được liên kết chặt chẽ với các mục tiêu của bạn như thế nào. Đôi khi, mục tiêu SMART của bạn phải giảm DUMB trước, nghĩa là. làm cho họ:

• Có thể làm được
• Có thể hiểu được
• Quản lý
• Có lợi

Nghe có vẻ lạ.

Cài đặt mục tiêu kiểu SMART có thể hữu ích trong ngữ cảnh lập trình nhưng nó phải được thực hiện một cách thông minh hoặc, như đã chỉ ra trong các câu trả lời khác, nó có thể gây lãng phí thời gian (hoặc tệ hơn).

Để có được các mục tiêu hữu ích, việc đồng ý từ viết tắt SMART có nghĩa là gì: một tìm kiếm nhanh của Google đã tìm thấy các định nghĩa khác nhau :

• S: dường như có sự đồng thuận tại Cụ thể (mặc dù có một số bất đồng về điều đó có nghĩa là gì)
• M: Có ý nghĩa và Động lực là những lựa chọn thay thế cho Phép đo phổ biến hơn
• A: dường như thường xuyên nhất để đại diện cho Thành tựu, nhưng tôi cũng đã thấy Đồng ý
• R: tùy thuộc vào nơi bạn nhìn, bạn có thể tìm thấy Thực tế, Có liên quan, Tập trung vào Kết quả
• T dường như luôn luôn tham chiếu Thời gian, mặc dù sự nhấn mạnh khác nhau

Vì vậy, trước tiên, cả hai bên của quá trình đàm phán thiết lập mục tiêu nên được làm việc từ sự hiểu biết chung về quy trình.

Tiếp theo, các mục tiêu tổng thể cho tổ chức, bộ phận, nhóm, nhóm (hoặc bất kỳ thứ bậc nào có liên quan) cần được giải thích và hiểu rõ. Tại thời điểm đó, cá nhân (IMO, các mục tiêu phải được đặt ở cấp độ cá nhân phải có giá trị) để có thể đồng ý về một số mục tiêu nhỏ sẽ thông báo cho các hoạt động của người đó trong tương lai.

Nếu nó kết thúc ở đó, nó vẫn là một sự lãng phí thời gian của mọi người. Mục tiêu cần được xem xét và điều chỉnh thường xuyên - khi đạt được, cần phải xem xét các mục tiêu mới, khi không đạt được, cần xác định lý do và hành động khắc phục được quy định khi cần thiết.

Mọi người quan tâm nên biết rằng loại bài tập này không có giá trị nếu nó không được thực hiện nghiêm túc, hoặc có lẽ hơn về mặt thuật toán, giá trị được trích xuất tỷ lệ thuận với nỗ lực đưa vào.

Có thể được hướng dẫn để xem những gì mọi người nghĩ có thể hữu ích / đáng giá mục tiêu SMART. Tôi đã đặt ra một câu hỏi ở đây ...

Rắc rối với các mục tiêu SMART là họ phải chọn những gì có thể đo lường được. Vì những gì có thể đo lường được và những gì quan trọng đối với thành công của tổ chức thường không giống nhau (Và hầu như không bao giờ có trong lập trình), các mục tiêu SMART luôn thất bại trong việc đánh giá hiệu suất theo kinh nghiệm của tôi. Và đôi khi mọi thứ dường như có thể đo lường được nhưng không phải là không có quá nhiều nỗ lực (Giống như mục tiêu SMART tôi đã có một lần để trả lời tất cả các email trong vòng 4 giờ. Thực sự ai muốn thử qua hàng ngàn email tôi nhận được trong một năm, hãy xác định xem có phải không là thông tin hoặc cần một câu trả lời và sau đó nhìn vào email đã gửi của tôi để xem tôi đã trả lời chưa và sau đó nghe bản ghi âm của tất cả các cuộc gọi để xem tôi có trả lời không, kiểm tra nhật ký IM của tôi để xem tôi có trả lời không, v.v. những gì về email đã được gửi cho tôi vào tối thứ bảy lúc nửa đêm ...)

Đối với tất cả những người trả lời KHÔNG, các Mục tiêu của bạn có lẽ KHÔNG đủ thông minh.

Tôi đã sử dụng chúng và tôi thấy chúng vô cùng hữu ích. Bạn có thể muốn thử một cái gì đó phù hợp với chúng tôi:

1. Đặt mục tiêu hàng quý.
2. Đặt mục tiêu đo lường được.
3. Chỉ đặt một mục tiêu cho cá nhân
4. Làm cho cá nhân chấp nhận mục tiêu, nếu anh ta nói rằng Mục tiêu quá tham vọng điều chỉnh cho đến khi cả hai bạn đồng ý.
5. Vào cuối quý, đưa ra một giá trị Boolean. Mục tiêu đạt được = đúng hay sai.

Điều này là vô cùng mạnh mẽ, nó tạo ra trách nhiệm cho Nhà phát triển. Những người muốn tìm cớ gà ra sau 6 tháng hoặc lâu hơn.

Tái bút: Tôi có thể hiểu mọi người bỏ phiếu trả lời nhưng xin vui lòng gửi bình luận có liên quan ít nhất Tôi sẽ học được điều mà tôi không biết :-)

SMART là từ viết tắt để ghi nhớ một số tiêu chí cho mục tiêu tốt hơn. Vì vậy, giới thiệu SMART có nghĩa là, quản lý của bạn phải làm tốt hơn theo nguyên tắc này. Nếu không có quản lý SMART sẽ đặt mục tiêu dù sao đi nữa, nhưng chúng có thể sẽ quá khó khăn.

Vì vậy, đối với các lập trình viên không nên thay đổi, ban quản lý phải thay đổi phong cách để thực hiện SMART. Và nếu họ làm đúng, công việc lập trình viên của bạn có thể trở nên dễ dàng hơn, bởi vì hướng của dự án rõ ràng hơn, các khung thời gian được thiết lập và vân vân.

Nếu quản lý không làm đúng, sẽ không có nhiều thay đổi.