Các vai trò trong một team phát triển phần mềm

Bài viết được sự cho phép của tác giả Phạm Bình

Chào các bạn,

Có phải để tạo ra một sản phẩm phần mềm thì chỉ cần các bạn developer thôi là đủ không? Câu trả lời là vừa có … vừa không. Vì một team bao gồm những ai thì phụ thuộc rất nhiều vào quy mô, cũng như tốc tốc độ phát triển của dự án đó.

Để các bạn hiểu rõ về các vai trò trong một team phát triển sản phẩm, thì mình sẽ mô tả quá trình thay đổi của một team dự án, từ lúc nó bé xíu, cho tới lúc đã có tương đối đủ thành viên, như vậy bạn sẽ dễ hiểu hơn về vai trò của từng thành viên trong team.

Lưu ý: 
Không phải tất cả các dự án phần mềm đều có sự phát triển giống như trong bài viết này. Mình chỉ lấy ví dụ để các bạn dễ hình dung ra vai trò của từng bộ phận trong team hơn thôi nhé.

Vai trò của Developer

Developer là dân kỹ thuật chính hiệu, kỹ năng mạnh nhất của họ chính là viết code để tạo ra phần mềm.

Thời điểm này, dự án chỉ bao gồm 3 developer. Họ có chung ý tưởng, và quyết định hợp tác với nhau để cùng biến ý tưởng đó thành một sản phẩm thực tế. Họ phác thảo ý tưởng ra giấy, rồi phân chia công việc. Họ cũng bầu ra một leader (gọi là developer leader) để chịu trách nhiệm điều phối, và đảm bảo chất lượng sản phẩm.

Giai đoạn này, công việc chủ yếu là code, đôi khi phát sinh một số công việc khác nhưng không nhiều, cũng không quá khó, họ vẫn có thể tự chia nhau hoàn thành.

Sau một thời gian phát triển, họ đã có phiên bản đầu tiên, sẵn sàng ra mắt khách hàng, và hy vọng là sẽ có nhiều khách hàng sử dụng.

Vai trò của Product Owner (PO)

Sau khi ra mắt sản phẩm, cũng có một vài bug, nhưng nó không nghiêm trọng lắm, các developer vẫn làm việc bình thường, và sản phẩm cũng đã “nhen nhúm” có khách hàng sử dụng. Tuy nhiên, ý tưởng ban đầu của họ đã được khai thác hết, tất cả các tính năng cần thiết đều đã xuất hiện trên sản phẩm, họ bắt đầu cạn ý tưởng và không biết phải làm gì tiếp theo.

Các developer cũng bắt đầu ý thức được rằng, việc đưa ra một ý tưởng thì không khó, nhưng đưa ra một ý tưởng thiết thực thì lại rất khó. Trong khi họ là các developer, nên việc tìm ra một ý tưởng như vậy không phải là điều dễ dàng.

Họ bắt đầu đi tìm kiếm một product owner – người sẽ chịu trách nhiệm tìm ra các ý tưởng, sao cho các ý tưởng đó là hay, là thiết thực, vừa đem lại giá trị cho khách hàng, lại vừa đem lại lợi ích cho sản phẩm (gọi chung là tối ưu hóa sản phẩm).

Có Product Owner, các ý tưởng hay liên tục được đưa ra, nhờ đó mà sản phẩm phát triển nhanh hơn rất nhiều so với trước kia – cả về mặt tính năng lẫn số lượng khách hàng sử dụng.

Tham khảo Job FrontEnd HOT trên Station D!

Vai trò của Business Analyst (BA)

Ban đầu, PO và các developer phối hợp với nhau rất tốt, công việc rất trôi chảy, suôn sẻ. Nhưng càng về sau, thì càng xuất hiện nhiều vấn đề, chủ yếu xoay quanh:

• Sản phẩm đã trở nên khá phức tạp, và không một ai trong team có thể nhớ rõ chính xác nó hoạt động như thế nào. Nên các ý tưởng của PO khi đưa ra tuy rất phù hợp về mặt hướng đi, nhưng lại xung đột nhiều với các tính năng đã có.
• Các ý tưởng mà PO đưa ra ngày càng phức tạp, và các developers sẽ không thể “nghe một lần rồi hiểu ngay”, nên họ thường xuyên code “lệch” so với ý tưởng của PO.
• Các developer trễ deadline, do việc việc triển khai ý tưởng mới phải gánh thêm việc giải quyết xung đột với tính năng cũ, trong khi đó, không ai biết chính việc sửa tính năng cũ tốn bao nhiêu thời gian, có thể rất nhiều, hoặc rất ít.

Vì vậy, cả team quyết định sẽ phân tích kỹ lưỡng, đồng thời mô tả sử thay đổi của sản phẩm ra văn bản, coi nó là tài liệu mô tả yêu cầu trước khi code. Tuy nhiên, không biết nên để công việc này cho ai vì:

• Vai trò của PO là người đi tìm các ý tưởng, và chứng minh là đó là ý tưởng thiết thực mà sản phẩm nên có. Đây là công việc cực kỳ quan trọng, PO không nên tốn thời gian vào việc mô tả chi tiết yêu cầu.
• Nếu PO không làm công việc trên, thì developer lại càng không. Vì trò của developer chủ yếu là về mặt công nghệ – đây cũng là một công việc rất quan trọng, không nên để developer tốn thời gian vào việc viết mô tả chi tiết yêu cầu. Mặt khác, chính các developer sẽ là người chuyển yêu cầu thành code, nếu để họ để họ viết yêu cầu, thì không khác gì bảo họ viết hai lần, một lần bằng ngôn ngữ tự nhiên, và một lần viết bằng code.

Vì thế, team quyết định tìm thêm một bạn làm về business analyst (BA) – Chuyên viên phân tích nghiệp vụ.

BA sẽ đảm nhiệm phân tích ý tưởng ban đầu của PO thành các yêu cầu cụ thể trên sản phẩm (như sản phẩm cần thêm, sửa, xóa tính năng gì), đồng thời văn bản hóa các yêu cầu đó thành tài liệu SRS (*), trực tiếp giải thích cho các developer hiểu. Nếu yêu cầu tính năng quá khó để miêu tả bằng văn bản, thì BA sẽ vẽ các bản mockup (*), prototype (*) để dễ hình dung hơn.

Vai trò của UI/UX Designer

Kể từ khi có BA, công việc lại trở nên ổn định, deadline đã chính xác hơn trước, PO cũng tự tin đưa khi đưa ý tưởng mới mà không lo các developer than “Ui nó ảnh hưởng nhiều lắm, code phức tạp lắm“. Số lượng tính năng mới, và khách hàng vẫn liên tục tăng lên.

Về mặt team phát triển, cơ bản là không có vấn đề gì, nhưng vấn đề lúc này lại đến từ khía khách hàng. Ngoại trừ việc sản phẩm có một vài lỗi nhỏ, thì còn một vấn đề lớn nữa đó là “các tính năng quá khó để sử dụng”. Khách hàng đã tiếp cận với sản phẩm, nhưng rồi lại lặng lẽ đi ra vì … không biết dùng như thế nào.

Cả team từng cho rằng BA sẽ cần phân tích thêm cả việc sản phẩm nên thể hiện như thế nào với khách hàng, nhưng không, BA đang rất bận rộn với việc phân tích yêu cầu của PO. Mặt khác, BA sẽ tập trung trả lời cho câu hỏi “sản phẩm sẽ cần thay đổi những gì về mặt tính năng?“, chứ ít khi trả lời câu hỏi “sản phẩm phải làm thế nào để đẹp hơn và dễ dùng hơn“.

Vì thế, để sản phẩm thu hút hơn, và đem lại trải nghiệm tốt hơn với khách hàng, team đã tìm thêm một bạn UI/UX designer. Bạn này sẽ đảm nhiệm việc thiết kế giao diện (màu sắc, bố cục), và các luồng sử dụng trên sản phẩm, sao cho thân thiết, đẹp mắt, dễ tiếp cận và dễ dàng sử dụng với khách hàng, ngay cả khi họ là người mới.

Sau khi có UI/UX designer, sản phẩm như được lột xác. Bố cục rõ ràng, màu sắc hài hòa, cùng với một tính năng, trước kia khách hàng phải tốn 10 click, thì giờ chỉ tốn 3 click. Tóm lại trải nghiệm được tăng lên đáng kể.

Vai trò của Tester

Số lượng khách hàng sử dụng bây giờ đã rất nhiều, và các bug ngày trước được coi là nhỏ, thì bây giờ sẽ được coi là lớn, các bug ngày trước được coi là lớn, thì bây giờ không được phép xuất hiện trên sản phẩm.

Mặc dù các developer không cố tình tạo ra bug, họ cũng đã kiểm tra lại kỹ càng các tính năng trước khi đưa cho khách hàng sử dụng. Nhưng suy cho cùng, họ vẫn là con người, không thể tránh được thiếu sót, và các bug “không thể chấp nhận được” vẫn đôi lúc xuất hiện.

Vì vậy, team quyết định tìm thêm một bạn tester – người sẽ đảm bảo chất lượng sản phẩm trước khi nó tới tay khách hàng.

Từ khi có tester, các đợt cập nhật phiên bản mới đều được kiểm tra kỹ càng rồi mới đưa đến tay khách hàng, các bug “không thể chấp nhận được” đã không còn xuất hiện nữa.

Vai trò của team Manager

Điểm lại một chút, lúc này team đã có khá nhiều vai trò: developer, PO, UI/UX designer, tester. Và các bộ phận này này đang gặp một số vấn đề như sau:

• Không biết cách phối hợp với nhau thế nào cho hiệu quả.
• Lúc thì bộ phận này bận SML, còn bộ phận kia thì rảnh và ngược lại.
• Đôi khi có các công việc “không tên”, thì không ai muốn nhận nó về mình, ai có lý do từ chối hợp lý.

Hiện tại thì team vẫn đang có một leader (chính là bạn developer được bầu ra ở level 1). Nhưng suy cho cùng đó là kiêm nhiệm vị trí, và bạn đó vẫn đang làm việc ở vị trí developer nhiều hơn.

Để team hoạt động hiệu quả hơn, team quyết định để bạn developer leader kia lên làm team manager – bạn này chịu trách nhiệm điều phối công việc trong team, cân bằng khối lượng công việc giữa các bộ phận, tìm ra quy trình phù hợp và áp dụng vào team.

Trong thực tế, nếu team không bầu được ai, thì có thể tuyển người mới. Tuy nhiên vị trí này ít khi được tuyển mới mà thường được cất nhắc từ người trong team hiện tại – nhất là với các team nhỏ.

Kể từ khi có team manager, công việc lại trôi chảy hơn nhiều, mọi người đi làm cảm thấy vui vẻ, không còn lo quá nhiều hoặc quá ít việc. Các bộ phận cũng phối hợp hiệu quả hơn do có quy trình làm việc rõ ràng.

Tạm kết câu chuyện của team tới đây, vì nếu mình viết tiếp thì sẽ rất dài, thậm chí không có hồi kết. Cũng như mình chia sẻ ở đầu bài viết, quy mô của dự án sẽ quyết định các vai trò trong team, tuy nhiên, đều tuân theo một quy luật là “nghẽn ở đâu, thì giãn nở ở đó”. Khi dự án phát triển tới mức độ được coi là lớn, thì bất kỳ một công việc nhỏ nào trước kia đều có thể trở nên cực kỳ phức tạp, và cần một bộ phận chuyên trách để xử lý – đó là lúc team cần bổ sung thêm một vai trò mới.

Ngoài các vai trò đã được nếu phía trên, thì dưới đây mình bổ sung thêm một số vai trò điển hình khác:

• Vai trò của DevOps Developer: Chịu trách nhiệm về hạ tầng sản phẩm (server, mạng,…), giúp sản phẩm chạy ổn định với khách hàng.
• Vai trò của Security: Đảm bảo hệ thống an toàn, không bị xâm nhập trái phép.
• Vai trò của Software Architecture: Thiết kế kiến trúc của phần mềm, để sản phẩm có tính mở rộng cao, dễ dàng thay đổi, và ít để lại nợ công nghệ
• SRS: Viết tắt của Software Requirement Specification, được dịch ra tiếng việt là Tài liệu đặc tả yêu cầu. SRS là tài liệu được sử dụng để mô tả chi tiết các yêu cầu chức năng và phi chức năng của hệ thống.

• Prototype, mockup: Ám chỉ các bản vẽ mô tả về sản phẩm.

Bài viết gốc được đăng tải tại phambinh.net

Những bài viết liên quan: