Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Designer, FE, mobile, BE, DBA và fullstack — mỗi người quyết được gì, chặn được gì, và vì sao cái sơ đồ "BA → designer → FE → BE → QC" mà bài nào cũng vẽ lại là sai.
Gần như bài viết nào về chủ đề này cũng có một cái sơ đồ: BA → Designer → FE → BE → QC → lên production, một mũi tên thẳng từ trái sang phải. Nhìn rất gọn, và nhớ rất dễ.
Vấn đề là nó sai, và sai theo kiểu tốn tiền. Ai tin cái sơ đồ đó sẽ đi hứa với khách một cái lịch cộng dồn từng chặng — designer ba ngày, FE năm ngày, BE bốn ngày, QC hai ngày, vị chi hai tuần — rồi vỡ ngay tuần thứ hai, lúc phát hiện ra BE đã bắt đầu từ trước khi designer vẽ xong, còn người kiểm thử thì đã bới ra một câu hỏi mà lẽ ra phải trả lời từ hôm đầu.
Bài này mình muốn kể lại chuyện đó theo cách gần với thực tế hơn: trong một team phần mềm có những ai, mỗi người thật sự quyết được cái gì, và bạn nên gõ cửa ai trước khi hứa với khách bất cứ điều gì.
Bài này không dạy lại Scrum hay Waterfall, không dạy cách phối hợp và xử lý bất đồng với dev và QC, cũng không phân tích Product Owner, Product Manager hay Project Manager — mấy phần đó có bài riêng trong khoá. Ở đây chỉ có một việc: nhận mặt các vai trong team làm ra phần mềm, và biết ai lo phần nào. Vì danh sách hơi dài nên mình tách làm hai bài: bài này là nhóm trực tiếp làm ra sản phẩm, bài sau là nhóm giữ chất lượng, chốt kỹ thuật và vận hành.
Nếu bạn tra Google, thứ nhận về sẽ là một bảng ba cột: Vị trí | Mô tả | Kỹ năng cần có. Bảng đó viết cho người đang muốn đi xin việc FE, không viết cho người sắp ngồi họp với FE. Đọc thuộc "FE làm giao diện, BE làm logic" xong, bạn vẫn đứng hình khi khách báo màn hình danh sách đơn hàng load mất nửa phút.
Nên mình đề nghị đổi cách đọc. Với mỗi vai, hỏi đúng ba câu:
Ba câu này áp cho mọi vai, kể cả những vai có chức danh nghe rất lạ. Chúng còn dùng được cả khi team bạn không có ai mang đúng chức danh đó — bạn vẫn tìm ra người đang gánh phần việc ấy.
Nhưng phải nói rõ chữ "quyết". Thứ mỗi vai quyết là cách làm trong phần chuyên môn của họ. Còn làm cái gì, để phục vụ điều gì thì vẫn là quyết định nghiệp vụ — của khách, của người phụ trách sản phẩm, và của bạn trong vai người làm rõ. Lẫn hai thứ đó với nhau là nguồn gốc của rất nhiều tính năng chạy đúng code mà sai ý.
Một chuyện nên nói ngay để tránh hiểu nhầm: mấy chức danh dưới đây không phải quy định của phương pháp làm việc nào cả. Scrum Guide bản 2020 gọi chung tất cả những người tạo ra sản phẩm trong Sprint là Developers, không hề bắt team phải có FE, BE hay QC riêng. Việc chia nhỏ ra thành các title là cách từng doanh nghiệp tổ chức công việc của họ, nên hai công ty gọi giống nhau mà việc khác hẳn nhau là chuyện bình thường.
Để mấy câu trên không thành lý thuyết, cả bài này lẫn bài sau đều bám một tính năng duy nhất:
Người dùng vào app, chọn bác sĩ, chọn một khung giờ còn trống, bấm xác nhận. Trước ngày khám một hôm, hệ thống gửi tin nhắn nhắc.
Nghe như vài màn hình. Nhưng trong đó có sẵn một câu hỏi mà tài liệu của BA hay quên: nếu hai người cùng bấm vào một khung giờ trong cùng một giây thì sao? Giữ câu đó trong đầu — nó sẽ đi qua tay gần như mọi người trong cả hai bài.
Designer hay bị mô tả là người làm cho sản phẩm đẹp và dễ nhìn. Mô tả đó vừa nhẹ vừa lệch. Mâu thuẫn thật giữa BA và designer gần như không bao giờ là đẹp hay xấu — nó là ai quyết luồng màn hình. Với tính năng đặt lịch: chọn bác sĩ trước rồi mới chọn giờ, hay chọn giờ trước rồi lọc ra bác sĩ nào rảnh? Gộp cả ba bước vào một màn hay tách ra? Đó là phần họ đề xuất và chịu trách nhiệm, dựa trên thứ bạn mô tả về người dùng. Ai ký duyệt cuối cùng thì tuỳ team — có nơi là khách, có nơi là người phụ trách sản phẩm — nhưng người nghĩ ra luồng thì thường là họ, không phải bạn.
Có một cái bẫy ở đây mà người mới hay dính. Bạn vẽ tạm một cái phác thảo bằng ô vuông và mũi tên để minh hoạ ý tưởng cho dễ nói. Xong buổi họp, cả team lưu cái ảnh đó lại và coi nó là bản chốt. Designer mất luôn phần việc của mình mà không ai kịp nhận ra, còn bạn thì tự nhiên phải chịu trách nhiệm cho một thiết kế mình không có chuyên môn để bảo vệ. Cách tránh đơn giản: mỗi lần đưa hình vẽ tay ra, nói kèm một câu rằng đây là để mô tả ý, không phải bản thiết kế.
FE là người dựng phần giao diện chạy được. Chỗ mà mô tả "làm những gì bạn nhìn thấy trên màn hình" giấu mất là: phần lớn những ca lạ trong tài liệu của bạn cuối cùng đều rơi vào tay FE. Bác sĩ đó hôm nay không còn giờ trống thì màn hình hiện gì? Đang tải thì hiện gì? Bấm xác nhận đúng lúc rớt mạng thì sao? Cùng cái màn hình đó trên điện thoại màn nhỏ thì trông thế nào? Mỗi câu bạn không trả lời là một chỗ FE phải tự đoán, và họ đoán theo hướng dễ code nhất chứ không phải hướng đúng nghiệp vụ nhất.
Mobile xuất hiện khi sản phẩm có app riêng cho điện thoại, và đây là chỗ người mới hay ước lượng hụt. Một thay đổi nhỏ trên web có thể chỉ mất một buổi; cùng thay đổi đó trên app thì phải làm cho cả hai hệ điều hành, rồi còn phải chờ được duyệt lên chợ ứng dụng, mà cái chờ đó không ai trong team ép nhanh được. Team vẫn có cách đi vòng — bật tắt tính năng từ xa, hoặc phát hành phần web trước — nhưng đó là những cách phải bàn từ đầu, không phải thứ moi ra được vào phút chót.
BE là người xử lý phần chạy trên máy chủ. Và đây chính là nơi câu hỏi hai người bấm cùng một khung giờ được trả lời. Có nhiều cách xử lý: khoá khung giờ ngay khi người dùng mở màn hình chọn giờ, giữ chỗ trong vài phút rồi nhả ra, hoặc để ai bấm xác nhận trước thì được, người sau nhận thông báo hết chỗ. Mỗi cách cho ra một trải nghiệm khác nhau và một khối lượng công việc khác nhau.
Và đây là chỗ rất dễ đi sai, nên mình nói kỹ. Ba cách trên nghe như ba phương án kỹ thuật, nhưng thật ra chúng là ba quy tắc nghiệp vụ khác nhau: giữ chỗ bao lâu, người bấm sau nhìn thấy gì, có ưu tiên ai không. Nếu bạn để BE tự chọn rồi mình chỉ ghi lại, bạn vừa đẩy một quyết định kinh doanh sang người không có thông tin để quyết. Việc đúng là bạn hỏi cho ra các phương án, mô tả mặt được mặt mất của từng cái bằng ngôn ngữ nghiệp vụ, rồi đưa người có quyền quyết nghiệp vụ chốt. Sau khi chốt xong, cách hiện thực hoá — khoá ở đâu, giữ chỗ bằng cơ chế gì — mới là phần của BE.
Câu hỏi đáng hỏi BE nhất, ở gần như mọi tính năng: "cái này hệ thống hiện tại có sẵn chưa, hay phải làm mới?" Trả lời được câu đó là bạn phân biệt được một yêu cầu mất nửa ngày với một yêu cầu mất hai tuần, trước khi lỡ miệng với khách.
DBA là người lo phần dữ liệu — cấu trúc lưu trữ, ràng buộc, hiệu năng khi bảng phình to. Nhiều team ở Việt Nam không có vai này riêng, một bạn BE cứng ôm luôn. Bạn ít khi làm việc trực tiếp với họ, nhưng khi cần thì thường là chuyện lớn: dữ liệu lịch hẹn cũ từ hệ thống trước đổ sang thế nào, lịch sử đổi lịch có giữ lại không, ai được xem lịch của bác sĩ nào.
Còn fullstack thì cần một lời cảnh báo. Trên lý thuyết là người làm được cả hai phía. Trên thực tế, gần như luôn có một bên là nghề chính và một bên là đỡ được. Không phải chuyện họ kém — làm được cả hai ở mức dùng được đã là nhiều. Nhưng nó có nghĩa là khi giao một việc nặng về phía họ không mạnh, bạn nên soi kỹ hơn ở phần đó, và đừng ngạc nhiên nếu nó lâu hơn dự kiến.
Giờ quay lại cái sơ đồ ở đầu bài, với đúng bốn vai vừa kể.
BE thường bắt đầu song song với designer, có khi trước, vì phần dữ liệu và quy tắc nghiệp vụ không phải chờ màn hình. FE dựng giao diện với dữ liệu giả trong lúc BE còn đang làm. Còn người kiểm thử thì vào từ lúc đọc tài liệu của bạn chứ không phải lúc có bản chạy được — mình nói kỹ chuyện đó ở bài sau, nhưng riêng chi tiết này thì cần biết ngay, vì nó phá vỡ hẳn hình dung "test là khâu cuối".
Rồi có những đường quay ngược. FE dựng tới màn chọn giờ mới phát hiện tài liệu không nói khung giờ đã kín thì hiện gì — quay lại chỗ bạn. Bạn hỏi lại team về cách khoá khung giờ — quay tiếp một vòng nữa. Có người thử bấm xác nhận hai lần thật nhanh, ra hai lịch hẹn — quay lại BE, và có khi quay lại cả designer nếu cách sửa là làm mờ cái nút sau khi bấm.
Nhìn thì tưởng team làm việc lộn xộn. Không phải: quay lại sớm và quay lại nhiều lần ở giai đoạn đầu chính là thứ giữ cho dự án không vỡ ở giai đoạn cuối. Thứ cần rút ra chỉ là đừng ước lượng thời gian bằng cách cộng dồn từng chặng — con số đó luôn thiếu phần quay lại, và phần quay lại gần như không bao giờ bằng không.
Bốn vai trên mới là những người trực tiếp làm ra thứ khách nhìn thấy. Nhưng trong phòng còn mấy người nữa mà một BA mới thường không biết phải nói chuyện thế nào: người đi tìm chỗ hở trong tài liệu của bạn, người có quyền nói "làm kiểu này sẽ phá thứ đang chạy", người lo cho hệ thống sống được ngoài đời, và những vai chỉ ở Việt Nam mới gặp nhiều.
Bài tiếp theo nói về nhóm đó, vẫn với tính năng đặt lịch khám, và kết bằng câu hỏi khó nhất: khi một người ôm ba vai cùng lúc — chuyện rất bình thường ở các team năm tới tám người — thì ba câu hỏi ở đầu bài này còn dùng được không.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận