it-swarm-vi.com

Các mục tiêu SMART có hữu ích cho các lập trình viên không?

Một số tổ chức tôi biết sử dụng THÔNG MINH mục tiêu cho các 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 riêng tôi với SMART mục tiêu không tích cực lắm. Các lập trình viên khác có thấy chúng là cách hiệu quả để đo lường hiệu suất không? Một số ví dụ về good SMART = mục tiêu cho lập trình viên (nếu chúng tồn tại).

57
Craig Schwarze

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 dự án và khi hoàn thành đánh giá hoàn hảo chỉ là quá xa đồng bộ.

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 có thể đánh giá cao cho mọi người. 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 này gây ra 80% các vấn đề trong một doanh nghiệp và hệ thống này chịu trách nhiệm 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ý chỉ đơn giản là không làm việc. 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 đề.

... Hãy để Lôi nhìn sâu hơn vào hệ thống đánh giá và khen thưởng nhân viên, và khám phá điều gì khiến họ trở nên rối loạn ...

52
MIA

Chúng tôi đã sử dụng SMART mục tiêu trong tập đoàn lớn nơi tôi làm việc. Phần lớn chúng vô nghĩa.

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.

CHỈNH SỬA

Như Mnementh đã chỉ ra rất chính xác, câu trả lời của tôi dựa trên SMART mục tiêu không được, thông thường, tôi sẽ thêm vào câu trả lời của mình 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 = SMART mục tiêu, hãy chắc chắn rằng chúng là SMART. Sử dụng ví dụ về trình quản lý của tôi như một cách KHÔNG thực hiện SMART mục tiêu. Nếu bạn không quản lý lập trình viên và ai đó cho bạn biết rằng bây giờ bạn sẽ bắt đầu sử dụng SMART mục tiêu và chúng kết thúc giống như mục tiêu của chúng tôi, sau đó 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.

14
Walter

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.

10
David Thornley

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 Mẫu thiết kế và viết dự án đồ chơi để tìm hiểu và trình diễn từng mẫu vào năm tới. Việc này đã kết thúc sau 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ý. Đây là một 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 giỏi SMART mục tiêu có liên quan nhiều hơn đến sự ác cảm đầu gối đối với công ty nói.

9
Robert Gowland

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: người ta không đặt cùng một mục tiêu 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 nồi 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 các 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 của mình. Tôi không có lời chỉ trích về SMART: Tôi do có những lời chỉ trích về những người quản lý kém ...

8
gbn

Là khung hiệu suất, SMART chỉ hiệu quả như mức độ mục tiêu của bạn được liên kết chặt chẽ với các nhà quản lý của bạn. Đôi khi, các mục tiêu SMART của bạn phải giảm xuống trước tiên , tức là làm cho chúng:

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

Nghe có vẻ lạ.

5
AAology

Cài đặt mục tiêu loại 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ó khả năng 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 ý các từ viết tắt SMART có nghĩa là gì: a tìm kiếm nhanh trên Google tìm thấy định nghĩa khác nha :

  • 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 đà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 phải đượ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á SMART mục tiêu. Tôi đã đặt câu hỏi ở đây ...

4
Mike Woodhouse

Vấn đề với SMART mục tiêu 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), = SMART mục tiêu luôn thất bại trong đánh giá hiệu suất theo kinh nghiệm của tôi. Và đôi khi mọi thứ xuất hiện có thể đo lường được nhưng không phải là 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 một năm, xác định xem đó là thông tin hay 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 lắng nghe bản ghi âm của tất cả các cuộc gọi điện thoạ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 ... Và email đó đã được gửi cho tôi vào tối thứ bảy lúc nửa đêm ...)

4
HLGEM

Đố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 SMART đủ.

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.

P.S: 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 gì đó mà tôi không biết :-)

3
Geek

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ó SMART sẽ đặt mục tiêu dù sao đi nữa, nhưng chúng sẽ khó khăn hơ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ì định hướng của dự án rõ ràng hơn, các khung thời gian được thiết lập và cứ thế.

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

3
Mnementh