Tìm hiểu sơ về chức vụ Delivery Lead
agile
8
White

Lơi Rệ viết ngày 27/05/2015

Nếu độc giả nào xa lạ với các khái niệm về Agile Methodology thì chắc hẳn sẽ tò mò khi đọc qua cái tựa đề của bài viết này. Sau một vài tháng huấn luyện để trở thành Delivery Lead ở Envato, tôi muốn viết xuống một vài dòng cắt nghĩa chức vụ này là gì và tại sao nó lại quan trọng với doanh nghiệp. Tôi cũng hi vọng nhận được thêm nhiều phản hồi từ các bạn làm Agile ở nhà, thực sự mảng này khá là mới mẻ với tôi và sẽ còn lấy nhiều thời gian của tôi trong thời gian tới.

Thế nào là Delivery?

Delivery có nghĩa là chuyển giao hay giao hàng, dịch thoáng ra đạt được những mục tiêu đã đề ra. Ở dưới khái niệm quản lý team trong ngành phần mềm đó là đạt được những chi tiêu đặt ra theo tuần, theo sprint.

Thế nào là Delivery Lead?

Delivery Lead hay dịch ngô nghê ra tiếng Việt Phụ trách chuyển giao, chức vụ này theo tôi định nghĩa là một người vác tù và đôn đốc team đạt được:

  • Đề ra các mục tiêu phải đạt được cho tương lai
  • Theo dõi và gỡ rối cho các mục tiêu hiện tại
  • Rút kinh nghiệm và cải tiến chất lượng dựa trên kết quả các mục tiêu trong quá khứ

Tại sao lại cần chức vụ này?

Khi làm việc trong một công ty lớn với nhiều team, rất là quan trọng để cấp lãnh đạo và quản lý nắm bắt được các team đang làm gì, có hiệu quả không. Thêm vào đó chức vụ này là cầu nối quan trọng giữa khách hàng và doanh nghiệp, nó đảm bảo là doanh nghiệp định hướng các chức năng hay công việc phải làm để đạt được những yêu cầu của khách hàng, lấy một ví dụ cụ thể là khi Delivery Lead nhận được một phản hồi chưa tốt của một chức năng A thì người này sẽ đảm nhiệm luôn công tác thông báo cho các sếp và team này để đảm bảo rằng các kế hoạch làm gì trong thời gian tới sẽ khắc phục được vấn đề.

Thế các bạn hỏi chức vụ này có áp dụng được trong các doanh nghiệp nhỏ hay startup không? Theo ý kiến của tôi là có, có thể sẽ không là một người chuyên làm nhiệm vụ này, nhưng các trách nhiệm của chức vụ này sẽ được đảm nhiệm bới một người kiêm các trách nhiệm khác.

Delivery Lead phải làm gì?

Làm gì cũng được, miễn là đạt được 3 mục đích nêu trên. Người ta có thể áp dụng nhiều practices như Kanban, Working Agreement, Retrospectives, vẽ rồng vẽ rắn, vv. Điểm mấu chốt của chức vụ này có thể tóm gọi trong 1 câu "inspect and adapt", hay "theo dõi và thích nghi". Theo dõi tiến độ của team và nếu có bất kì vấn đề gì phát sinh thì phải thích nghi và thay đổi để cố đạt được các chỉ tiêu đề ra.

Điểm mấu chốt là communication, hay giao tiếp và trao đổi. Chức vụ này phải kết nối được mọi thành viên trong team với nhau, giúp cho mọi thành viên hiểu được team mình đang làm cái gì? Đang ở đâu? Có bị bế tắc khúc nào? Và có cách nào để làm tăng hiệu suất chuyển giao được các chỉ tiêu đưa ra?.

Các kỹ thuật được áp dụng cho chức vụ này là gì?

Tôi xin lỗi các độc giả nếu nói quá nhiều về những thứ lý thuyết trừu tượng và nhàm chán trên. Để cho đề tài nó đỡ buồn ngủ hơn, hãy bàn một tí về một số kỹ thuật được áp dụng.

Họp giao ban hay Standup Meeting

Tổ chức họp giao ban mỗi sáng là một trong những hoạt động tiêu biểu của Delivery nhưng thực sự tôi nhận thấy là ít có người nào hiểu sâu về hoạt động này, thế chúng ta muốn rút ra được gì trong hoạt động trên. Thứ nhất là về format của standup, các thành viên nên nói gì, thời lượng nói bao nhiêu. Theo tôi thì standup là để tổng kết ngắn những gì diễn ra vào ngày hôm trước, mỗi thành viên sẽ tóm tắt rất ngắn họ đã và đang làm gì, và có gặp vấn đề gì không và cần gì để gỡ bế tắc. Xin lưu ý là tối kị diễn giải dài dòng vấn đề (giới hạn 1 phút/người), vì phần tìm hiểu thêm về các vấn đề mắc phải có thể bàn kĩ qua một cuộc họp riêng sau đó; và cũng tránh nói về những gì làm trong tương lai, chỉ tập trung để đạt được các chỉ tiểu đề ra trong tuần thôi. Sau đó một practice khác đi cùng standup lấy chỉ số "confidence level", hay lấy "chỉ số tự tin" của mỗi thành viên, đơn vị lấy tuỳ vào mỗi team, có thể lấy theo chuẩn từ 1 đến 10 hay 1 đến 5 với càng cao là càng tự tin đạt được mục tiêu đề ra. Chỉ số này sẽ được Delivery Lead thu thập và lên biểu đồ, chỉ số này được dùng để theo dõi giúp tìm ra các pattern hay các vấn đề gây tắc nghẽn. Xin nói thêm là chỉ số này không phải để lấy tốc độ trung bình của nhóm, vì công việc thay đổi liên tục, và chỉ số của quả táo không thể so sánh với chỉ số của quả cam được.

Họp kiểm điểm hay Retrospetive Meeting

Họp kiểm điểm là một buổi họp sau 1 sprint hay một thời gian chuyển giao được các mục tiêu đề ra để kiểm điểm và rút kinh nghiệm. Thực sự là mình dị ứng với các từ kiểm điểm theo cách nghĩ ở nhà, vì nó nghe hơi giống là một hoạt động đổ lỗi ai làm tốt hay ai làm xấu. Điều đó hoàn toàn không phải là mục đích của cuộc họp này, mục đích của cuộc họp này là tự nhìn nhận xem team đã có thực sự làm tốt nhiệm vụ đề ra hay không và góp ý đề cả team tốt hơn trong lần tới. Ngoài ra nên thu thập ý kiến đề rút ra Working Agreement, những giá trị mà mọi người đồng ý nên cố gắng đặt được, lấy một ví dụ nhé: Tạo ra điều khoản "Mọi người phải đi làm đúng giờ và nếu trễ thì phải báo".

Một lần nữa là format không cố định, muốn làm gì thì làm, những phải xác định được cái nhọt và tìm cách xử lý nó

Kết luận

Delivery Lead là một chức vụ quan trọng trong doanh nghiệp, người đảm nhiệm trọng trách này phải đảm bảo tiến độ của team, làm việc trực tiếp với khách hàng và cấp lãnh đạo để vẽ ra những chính sách chiến lược lâu dài cho sản phẩm.

Xin nhớ câu "inspect and adapt", đây là câu thần chú mà mọi Delivery Lead phải ráng tuân theo, hãy uyển chuyển để giúp gỡ bế tắc cho team. Mấu chốt của thành công là qua trao đổi và giao tiếp trong team.

Giới thiệu một qui trình để quản lý là một con dao hai lưỡi, nếu áp dụng một cách mù quáng không cần thiết thì nó sẽ làm giảm tốc độ được việc của team và tăng lượng việc cho người quản lý. Hãy luôn lắng nghe ý kiến của team và sẵn sàng bỏ đi các qui trình nếu không cần thiết, hay tạo điều kiện tối đa để team được thoải mái tự do nhưng tự do trong khuôn khổ ;). Còn làm làm sao? Không có một công thức nào cả? Hãy sáng tạo và linh hoạt. Và nếu không cần thiết thì không làm.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Lơi Rệ

43 bài viết.
222 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
70 12
Sự sống còn của các công ty kỹ thuật phụ thuộc vào nguồn nhân lực chất xám của họ. Thế nên rất thiết yếu cho việc đầu tư xây dựng team có khả năng ...
Lơi Rệ viết hơn 2 năm trước
70 12
White
40 7
Trời se se lạnh, Melbourne chuyển mùa, ngồi trong quán cafe bắt đầu một ngày làm việc mới với suy nghĩ tại sao các bạn Việt Nam không muốn tham gia...
Lơi Rệ viết 3 năm trước
40 7
White
36 15
Thế nào là làm việc từ xa? Internet, một trong những phát minh vĩ đại nhất của con người thế kỷ 20. Công nghệ này xoả bỏ rào cản vật lý giữa các n...
Lơi Rệ viết hơn 2 năm trước
36 15
Bài viết liên quan
White
6 0
Tiếp theo của phần 1, hôm nay mình sẽ tiếp tục viết về phần 2 quy trình Agile. Lần trước ta nói tới khái niệm của Scrum rồi, bây giờ tìm hiểu làm s...
Bùi Viết Hướng viết hơn 1 năm trước
6 0
White
3 0
Trước đây mình có một bài viết về phương pháp (Link). Hôm nay mình sẽ giới thiệu với các bạn một phương pháp khác là startfish, tạm dịch là sao biể...
Lê Anh viết hơn 2 năm trước
3 0
White
10 2
Chắc hẳn khi học về công nghệ thông tin thì hầu như ai cũng từng học qua về phát triển phần mềm rồi. Và cái thời ngồi trong giảng đường thì khái ni...
Bùi Viết Hướng viết hơn 1 năm trước
10 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
43 bài viết.
222 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!