Kyanon Digital Leader Talk On The Road To Engineering

Trong buổi Leader’s Talk #11 với chủ đề On The Road To Engineering Excellence, anh David Lapetina, VP – Engineering & Technology, Kyanon Digital đã chia sẻ, thảo luận cùng các anh chị quản lý về vai trò và trách nhiệm của ba vị trí quan trọng trong công ty: Technical Lead, Solution Architect và Engineering Lead cùng với những vấn đề xoay quanh “The Grey Zone” – tình trạng xảy ra khi trách nhiệm của các vai trò này chồng chéo nhau qua những tình huống thực tế.

Cùng tìm hiểu bài viết tại đây.

1. Tại sao một dự án cần những vai trò và trách nhiệm khác nhau?

Phụ thuộc vào quy mô và độ phức tạp của mỗi dự án, doanh nghiệp sẽ cần phân bổ nhiều kỹ năng và chuyên môn cụ thể khác nhau, vì vậy cần đòi hỏi có nhiều vai trò khác nhau để thực hiện dự án.

Phụ thuộc vào những chuyên môn khác nhau, nhân sự được yêu cầu phải có kiến thức rộng của nhiều chuyên môn trong lĩnh vực (horizontal knowledge) hoặc phải có kiến thức chuyên sâu vào một chuyên môn nào đó (vertical knowledge).

Các yêu cầu của dự án phụ thuộc vào sự ưu tiên tập trung khác nhau:

  • Tập trung vào phát triển nội bộ team, giúp các thành viên trong team phối hợp hiệu quả hoặc tập trung phát triển sự phối hợp giữa team dự án và các team khác.
  • Tập trung vào công nghệ hay tích hợp.
  • Tập trung vào yêu cầu của dự án hay cân nhắc về mặt kỹ thuật.
Cac-yeu-cau-cua-du-an-phu-thuoc-vao-su-uu-tien-tap-trung-khac-nhau

Mỗi dự án có những yêu cầu và sự tập trung ưu tiên khác nhau

2. Tổng quan vai trò và trách nhiệm trong mỗi dự án phát triển phần mềm

Cùng tìm hiểu tổng quan về vai trò và trách nhiệm của mỗi thành viên trong dự án như sau.

  • Engineering Lead: Chịu trách nhiệm cho sự phát triển, quản lý chất lượng dự án ở cấp độ toàn công ty, và đảm bảo phân bổ nguồn lực và hỗ trợ kịp thời.
  • Solution Architect (SA): Chịu trách nhiệm cho chiến lược và tầm nhìn về mặt kỹ thuật, thiết kế và giám sát thực thi dự án.
  • Tech Lead: Chịu trách nhiệm về mặt kỹ thuật, chất lượng “code” trong dự án. Trao đổi với Solution Architect hoặc Engineering Lead khi cần.
  • Quality Control Lead (QC Lead): Chịu trách nhiệm cho quá trình testing và đảm bảo chất lượng của dự án trong squad.
  • Project Manager (PM): Chịu trách nhiệm xác định cấu trúc team và phối hợp với Engineering Lead để phân bổ nguồn lực team. Chịu trách nhiệm ưu tiên các hoạt động bao gồm CR, tính năng, NFR, lỗi, vấn đề hiệu suất, v.v.
  • Delivery Team: Chịu trách nhiệm chuẩn chỉnh toàn bộ tài liệu của dự án (Business Analyst chịu trách nhiệm về yêu cầu dự án, Developers chịu trách nhiệm về tài liệu kỹ thuật). Chịu trách nhiệm cho phản hồi cho Engineering Lead tương ứng trong trường hợp gặp khó khăn khi áp dụng hoặc hiểu các hướng dẫn và/hoặc sử dụng các công cụ đã được xác định.

Vai-tro-cua-mo-hinh-Composable-Business-trong-boi-canh-thi-truong-hien-nay

Vai trò và trách nhiệm của các thành viên trong dự án

Ta cần nhìn nhận “Tech Lead” là vai trò trong dự án, không phải mỗi cá nhân cụ thể cho từng vị trí này. Tùy thuộc vào độ phức tạp của một dự án, Delivery Manager/Squad Lead cần giao rõ vai trò và nhiệm vụ cho các thành viên. Đặc biệt, tất cả các vai trò này cần phải được đảm bảo trong dự án, vì nếu không có Tech Lead, sẽ không có người chịu trách nhiệm cho chất lượng lập trình hoặc nếu không có QC Lead, sẽ không có người chịu trách nhiệm cho chất lượng testing, từ đó ảnh hưởng xấu đến chất lượng của toàn dự án.

Giả sử một khách hàng yêu cầu một tính năng hoàn toàn mới. Sau khi thảo luận kỹ lưỡng với đội ngũ thực hiện, Project Manager nhận thấy rằng để hoàn thành yêu cầu này sẽ mất nhiều thời gian hơn dự kiến. Nguyên nhân chính là do đội chưa có nhiều kinh nghiệm với loại tính năng này. Để đảm bảo chất lượng sản phẩm và tránh tình trạng làm thêm giờ quá mức, Project Manager đã quyết định đưa ra một timeline thực tế hơn.

Đồng thời, Tech Lead sẽ đóng vai trò cầu nối giữa đội ngũ kỹ thuật, bao gồm Solution Architect và Engineering Lead. Vai trò của Tech Lead là tìm kiếm những phương pháp làm việc tốt nhất (best practices) để giải quyết yêu cầu của khách hàng. Bằng cách này, đội ngũ có thể đưa ra một giải pháp hiệu quả, đáp ứng đúng yêu cầu của khách hàng mà vẫn đảm bảo tuân thủ timeline đã đề ra.

3. “Vùng Xám – The Grey Zone”: Khi trách nhiệm của các thành viên trong dự án chồng chéo nhau

“The Grey Zone” trong trường hợp này được hiểu là tình huống xảy ra khi trách nhiệm của các vai trò khác nhau giao nhau khi có một vấn đề xảy ra. David đã đưa ra 2 tình huống cụ thể:

  • Tình huống 1: Ở giai đoạn đầu dự án, sau khi đã vẽ ra được một kiến trúc được thống nhất giữa Solution Architect và Tech Lead, trong quá trình UAT với khách hàng, ta phát hiện ra 1 issue: không thể tích hợp với API của bên thứ ba.
  • Tình huống 2: Ta có thể tích hợp được với bên thứ 3 nhưng khách hàng phàn nàn về Transaction per second quá chậm.

Sau phần thảo luận, anh David đã đưa ra một số giải pháp như sau.

3.1. Bước 1a: Đào sâu tìm hiểu nguyên nhân gốc rễ

Trước khi đưa ra giải pháp, chúng ta cần xác định rõ nguyên nhân thực sự gây ra vấn đề. Trong trường hợp cụ thể này, có thể có nhiều yếu tố tác động như:

  • Lỗi từ phía đội dự án: Vấn đề có thể phát sinh từ quá trình thiết kế, phát triển hoặc triển khai.
  • Lỗi từ bên thứ ba: Nếu có sự liên kết với các hệ thống hoặc dịch vụ bên ngoài, chúng ta cần xem xét khả năng xảy ra lỗi từ phía họ.
  • Yếu tố khách quan: Các yếu tố như tốc độ internet, cấu hình hệ thống, hoặc thay đổi trong quy trình làm việc cũng có thể ảnh hưởng.

Để tìm ra nguyên nhân chính xác, Project Manager sẽ tập trung vào việc đánh giá tác động đến tiến độ dự án, trong khi Tech Lead cùng với Solution Architect và DevOps sẽ phân tích kỹ thuật để xác định lỗi cụ thể. QC Lead sẽ kiểm tra lại các trường hợp thử nghiệm để đảm bảo chất lượng phần mềm.

3.2. Bước 1b: Xác nhận lại kỳ vọng của khách hàng

Song song đó, chúng ta cần rà soát lại các thỏa thuận ban đầu với khách hàng để đảm bảo rằng hiểu rõ kỳ vọng của họ. Cụ thể:

  • Hiệu suất hệ thống: Chúng ta đã cam kết hỗ trợ bao nhiêu giao dịch mỗi giây (TPS) cho khách hàng?
  • Phạm vi hợp đồng: Các dịch vụ của bên thứ ba có nằm trong phạm vi hợp đồng ban đầu hay là yêu cầu thay đổi?
3.3. Bước 2: Xây dựng giải pháp toàn diện

Sau khi xác định rõ nguyên nhân và kỳ vọng của khách hàng, Project Manager và Tech Lead sẽ cùng nhau đưa ra giải pháp phù hợp. Tùy thuộc vào tính chất của vấn đề, chúng ta có thể cần sự tham gia của Solution Architect, Engineering Lead, và cả Account Manager.

Quan trọng, để tránh những hiểu lầm không đáng có, ngay từ đầu dự án, chúng ta cần:

  • Xác định rõ ràng yêu cầu: Cả về chức năng và phi chức năng.
  • Phân công rõ ràng trách nhiệm: Ai sẽ đảm nhận vai trò gì trong dự án (PM, Tech Lead, SA,…)
4. Yêu cầu chức năng (Functional Requirements) và Yêu cầu phi chức năng (Non-functional requirements)

Tình huống thực tế: Yêu cầu phi chức năng bị bỏ sót

David đã đặt ra một câu hỏi rất thực tế: “Giả sử chúng ta đã triển khai một nửa dự án và phát hiện ra rằng một số yêu cầu phi chức năng quan trọng, chẳng hạn như hiệu suất hệ thống, chưa được xác định rõ ràng từ đầu. Vậy chúng ta nên làm gì?”

4.1. Bước 1: Phân tích nguyên nhân
  • Thiếu sót trong quá trình thu thập yêu cầu: Có thể do chúng ta đã không đặt ra những câu hỏi đủ sâu để khám phá toàn bộ nhu cầu của khách hàng.
  • Checklist chưa đầy đủ: Công cụ hỗ trợ thu thập yêu cầu của chúng ta có thể chưa bao gồm các yếu tố phi chức năng quan trọng.
  • Thiếu sự phối hợp: SA có thể chưa nhận ra tầm quan trọng của các yêu cầu phi chức năng hoặc chưa có đủ thông tin để đặt câu hỏi.
4.2. Bước 2: Giải pháp và phòng ngừa
  • Đánh giá lại quá trình: Chúng ta cần xem xét lại quy trình thu thập và phân tích yêu cầu để đảm bảo không bỏ sót bất kỳ yếu tố nào.
  • Hoàn thiện checklist: Cập nhật checklist để bao gồm đầy đủ các câu hỏi liên quan đến yêu cầu chức năng và phi chức năng.
  • Tăng cường phối hợp: SA và Technical Architect (TA) cần làm việc chặt chẽ hơn để đảm bảo rằng tất cả các yêu cầu đều được hiểu rõ và đáp ứng đầy đủ.
  • Dự đoán và phòng ngừa: Chúng ta nên chủ động thảo luận với khách hàng về các yêu cầu tiềm ẩn và các tình huống có thể xảy ra ngay từ giai đoạn đầu của dự án.
  • Kiểm tra sớm và thường xuyên: Thực hiện các bài kiểm tra hiệu suất một cách thường xuyên để phát hiện sớm các vấn đề và kịp thời đưa ra giải pháp.
5. Kết luận

Buổi chia sẻ Leader’s Talk #11: On the road to Engineering excellence đã giúp chúng ta hiểu rõ hơn về vai trò quan trọng của Technical Lead, Solution Architect và Engineering Lead trong việc đưa dự án đến thành công. Mỗi vị trí, với những trách nhiệm riêng biệt, cùng nhau tạo nên một bức tranh hoàn chỉnh.

Tuy nhiên, chúng ta cũng nhận thấy rằng ranh giới giữa các vai trò này đôi khi không hoàn toàn rõ ràng. Chính vì vậy, sự hợp tác và giao tiếp hiệu quả là chìa khóa để vượt qua những thách thức này.

Qua những ví dụ thực tế, chúng ta đã thấy được tầm quan trọng của việc cùng nhau làm việc, cùng nhau giải quyết vấn đề và cùng hướng tới mục tiêu chung.

Hãy cùng chờ đón những chủ đề thú vị khác trong các buổi Leader’s Talk sắp tới tại Kyanon Digital nhé!

5/5 - (1 vote)