Archive for Quản lý

Bên kia núi cỏ có xanh hơn

tumblr_o2e5yrXDfe1qzcciuo1_500

ĐỪNG ĐI EM ƠI. BÊN KIA NÚI ĐÂU CÓ THẢM CỎ XANH HƠN….

Nếu có ý định nhảy việc, nên tuân thủ những nguyên tắc sau

Read more

Hệ thống quản lý OKR

g22re
Một phương pháp rất hay, dễ áp dụng thực hiện với mọi cấp độ công ty. Phương pháp này gần giống với Agile Result , rất hiệu quả khi kết hợp cả 2 để giữ sự ổn định vào mục tiêu đã chọn , không bị chệch hướng.
Tóm gọn lại phương pháp này là đi từ trên xuống (từ tập doàn -> cty -> lãnh đạo -> quản lý -> nhân viên), ở mỗi cấp sẽ đề ra các mục tiêu  phù hợp, hỗ trợ hoàn  thành yêu cầu của cấp cao hơn.
Một bộ bao gồm:
  • một mục tiêu chính
  • 3 kết quả then chốt cần đạt được.
  • Kết quả đánh giá: k0 được  quá thấp (<0.5 -> quá khó , cần điều chỉnh lại mục tiêu và kết quả then chốt) hoặc quá cao ( > 0.9 -> mục tiêu quá dễ)

Read more

Một số phương pháp đánh giá năng lực nhân viên

Ðịnh nghĩa và mục đích của việc đánh giá.

Ðịnh nghĩa.

Ðánh giá năng lực thực hiện công việc hay còn gọi là đánh giá thành tích công tác (performance appraisal) là một hệ thống chính thức được duyệt xét và đánh giá sự hoàn thành công tác của một cá nhân theo định kỳ.

Qua định nghĩa cho ta thấy đây là một hệ thống chính thức, như vậy phải hiểu rằng nó bao gồm cả một tiến trình đánh giá khoa học, có tính hệ thống và phải được thực hiện theo định kỳ tùy theo tính chất công việc, quy mô kinh doanh của doanh nghiệp.

Mục đích của đánh giá       .

Ðánh giá năng lực thực hiện công việc của nhân viên là một hoạt động quan trọng của quản trị nhân sự, giúp doanh nghiệp có cơ sở để hoạch định, tuyển chọn, đào tạo và phát triển nhân sự. Ðể đánh giá đúng năng lực thực hiện công việc của nhân viên, nhà quản trị cần phải hiểu được mục đích của việc đánh giá:

     – Nâng cao khả năng thực hiện công việc và cung cấp những thông tin phản hồi cho nhân viên biết được mức độ thực hiện công việc, từ đó có biện pháp nâng cao và hoàn thiện hiệu năng công tác.

     – Ðánh giá năng lực thực hiện công việc giúp doanh nghiệp có những dữ liệu cho biết khả năng thăng tiến của nhân viên. Nhờ sự đánh giá này doanh nghiệp có thể có cơ sở để hoạch định tài nguyên nhân sự.

     – Giúp nhân viên điều chỉnh, sửa chữa các sai lầm trong quá trình làm việc, đồng thời làm cơ sở để khuyến khích  động viên họ.

     – Ðánh giá năng lực thực hiện công việc giúp cho doanh nghiệp có cơ sở dự báo về nhân sự trong tương lai, từ đó có kế hoạch đào tạo, bồi dưỡng phát triển nguồn nhân sự.

     – Thông qua đánh giá năng lực thực hiện công việc của nhân viên, nhà quản trị có thể điều chỉnh việc bố trí sử dụng nhân viên cho phù hợp với công việc, phát hiện những tiềm năng còn ẩn giấu trong nhân viên giúp họ phát triển.

Tiến trình đánh giá thực hiện công việc

Read more

SCRUM – Một số quy tắc trong quy trình thực hiện

ScrumMaster là người chịu trách nhiệm đảm bảo tất cả những ai liên quan đến dự án, kể cả “gà” và “heo”, đều phải tuân thủ theo những quy tắc đặt ra của Scrum. Những quy tắc này được đút kết qua quá trình thực hiện thành công của hàng nghìn dự án trước đó.

Sprint Planning Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 8 giờ, bao gồm 2 phần, mỗi phần cố định 4 giờ. Phần thứ nhất là xác định Product Backlog, phần thứ hai là dành cho việc chuẩn bị một Sprint Backlog.

– Những người tham gia là ScrumMaster, Product Owner và Scrum Team. Ngoài ra, có thể mời thêm những người khác tham dự (nếu cần thiết khi cần thêm thông tin hoặc tư vấn về nghiệp vụ hoặc công nghệ). “Gà” không có chỗ trong cuộc họp này.

– Product Owner phải chuẩn bị trước Product Backlog. Trong trường hợp vắng Product Owner hoặc thiếu Product Backlog, ScrumMaster phải thực hiện xây dựng trước Product Backlog và đảm nhiệm vị trí của Product Owner.

– Mục tiêu của phần đầu, của 4 giờ đầu tiên, là để cho Scrum Team chọn các Product Backlog item mà họ cảm thấy đó tính năng quan trọng trong sản phẩm cần thực hiện. Scrum Team sẽ chứng minh cho Product Owner và các stakeholder tại Sprint Review Meeting và cuối Sprint về những gì mà họ đã chọn.

– Team có thể đưa ra các gợi ý, nhưng quyết định chọn Product Backlog nào để thực hiện trong Sprint là trách nhiệm của Product Owner.

– Team chịu trách nhiệm xác định có bao nhiêu Product Backlog mà Product Owner muốn thực hiện trong suốt Sprint.

– Phần thứ hai của cuộc họp, 4 giờ tiếp theo, Product Owner phải luôn có mặt để trả lời các câu hỏi về Product Backlog của Scrum Team.

– Kết quả của phần thứ 2 của cuộc họp này là một danh sách, được gọi là Sprint Backlog, bao gồm các công việc, ước lượng của từng công việc, và phần chỉ định.

Daily Scrum Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 15 phút bất kể có bao nhiêu thành viên của Scrum Team lúc đó.

– Tổ chức cuộc họp tại cùng địa điểm vào cùng thời điểm mỗi ngày làm việc. Cuộc họp nên được tổ chức vào đầu ngày làm việc để Scrum Team có thể tổng kết lại những gì đã làm được ngày hôm trước và vạch ra kế hoạch thực hiện ngày hôm nay.

– Thành phần tham dự là tất cả thành viên của Scrum Team. Nếu vì lý do nào đó mà thành viên không thể tham dự, người đó phải tham gia theo hình thức khác (như qua điện thoại, chat voice, live meeting,…), hoặc nhờ 1 thành viên khác báo cáo về tình trạng vắng mặt của mình.

– Các thành viên của nhóm phải được nhắc nhở. ScrumMaster bắt đầu cuộc họp vào thời gian đã thông báo, bất kể lúc đó có thành viên nào hiện diện. Bất kỳ thành viên nào trễ đều phải bị phạt ngay lập tức Smile.

– ScrumMaster bắt đầu cuộc họp bằng việc chọn một thành viên nào đó trong Team để báo cáo, và xoay vòng cho đến khi tất cả thành viên đều đã báo cáo.

– Mỗi thành viên chỉ nên trả lời 3 câu hỏi sau đây:

+ Bạn đã làm gì từ sau cuộc họp trước mà liên quan đến dự án này?

+ Bạn sẽ làm gì sau khi cuộc họp này kết thúc?

+ Điều gì cản trở bạn thực hiện công việc của mình?

– Các thành viên không nên lạc đề khỏi 3 câu hỏi trên vào các lỗi, thiết kế, thảo luận cách giải quyết vấn đề, hoặc nói linh tinh. ScrumMaster chịu trách nhiệm luân phiên việc báo cáo từ người này sang người khác.

– Trong suốt cuộc họp, chỉ duy nhất 1 người nói vào 1 thời điểm. Người đó là người đang thực hiện việc báo cáo tình trạng của mình, những người còn lại lắng nghe. Không ai được lên tiếng hoặc làm việc riêng lúc này.

– Sau khi một thành viên nào đó báo cáo về một điều gì đó gây thích thú cho các thành viên còn lại, hoặc cần sự trợ giúp của các thành viên khác, bất kỳ thành viên nào cũng có thể ngay lập tức sắp xếp tham gia cùng nhau sau khi cuộc họp kết thúc.

– “Gà” không có “tiếng nói” trong cuộc họp này. “Gà” đứng ở khu vực ngoại vi của Team để không gây ảnh hưởng đến cuộc họp này.

– Nếu có quá nhiều “gà” tham dự cuộc họp này, ScrumMaster có thể giới hạn lại số lượng người tham dự để đảm bảo sự ổn định và tập trung.

– “Heo” hoặc “gà” người mà không thể hoặc không theo những quy tắc ở trên sẽ bị loại khỏi cuộc họp (“gà”) hoặc loại khỏi nhóm (“heo”).

Sprint Review Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 4 giờ.

– Team không nên mất hơn 1 giờ để chuẩn bị cho cuộc họp.

– Mục đích của cuộc họp là để cho Team trình bày cho Product Owner và stakeholder về những gì mà họ đã làm được.

– Những phần chưa hoàn thành xong sẽ không được trình bày.

– Những phần không thuộc về chức năng có thể không được trình bày ngoại trừ khi nó được dùng để hỗ trợ. Những thành phần không được trình bày chẳng hạn như những work product, và việc sử dụng của chúng phải được tối giản nhất để tránh gây nhầm lẫn cho stakeholder hoặc yêu cầu họ hiểu việc phát triển các hệ thống làm việc như thế nào.

– Chức năng nên được trình bày trên máy trạm của thành viên trong nhóm và được thực thi từ máy chủ gần nhất để release – thông thường là một máy chủ môi trường đảm bảo chất lượng (quality assurance environment server).

– Cuộc họp bắt đầu với một thành viên trong nhóm trình bày về mục tiêu của Sprint, Product Backlog đã cam kết và Product Backlog đã hoàn thành. Những thành viên khác sau đó có thể tham gia thảo luận về những gì đã làm được và những gì chưa làm được trong Sprint đó.

– Vào cuối những bài trình bày, các stakeholder được biểu quyết để lấy ý kiến, cũng như những thay đổi mong muốn và độ ưu tiên của chúng.

– Product Owner thảo luận với stakeholder và Team về việc xếp lại Product Backlog dựa trên đánh giá phản hồi.

– Stakeholder có thể xác định tính năng nào không được giao hoặc không được giao như mong đợi và yêu cầu tính năng thay thế trong Product Backlog.

– Stakeholder có thể xác định bất kỳ tính năng mới xuất hiện khi họ xem phần trình bày và yêu cầu bổ sung tính năng mới vào trong Product Backlog.

– ScrumMaster nên “cố gắng” xác định số lượng mong muốn tham dự cuộc họp và tổ chức cộc họp để phù họp với họ.

– Vào cuối cuộc họp, ScrumMaster công bố thời gian và địa điểm của cuộc họp kế tiếp cho Product Owner và stakeholder.

Theo blog của bạn Huy Tran

Follow

Get the latest posts delivered to your mailbox: