Dev báo bug, hỏi chỗ này hồi đó chốt thế nào anh, và bạn mở máy ra tìm mà không thấy gì, không phải vì tài liệu bị xóa, mà vì nó chưa bao giờ được viết, lúc triển khai mọi thứ toàn nói miệng trong họp hoặc gõ vội qua tin nhắn. Bài này mình viết từ chính mấy lỗi documentation mình đã mắc, chứ không phải từ sách.
những lỗi documentation mình đã mắc#
Lỗi đầu tiên nghe rất tầm thường, bận quá nên quên gửi meeting note, theo mình cái giá của nó là người dự họp mỗi người nhớ một kiểu, mà chẳng có văn bản nào để đối chiếu.
Lỗi thứ hai là tài liệu không ghi version, không có lịch sử sửa, một file bị sửa nhiều lần như vậy thì nhìn vào chẳng biết bản nào mới nhất, ai sửa, sửa vì lý do gì.
Lỗi thứ ba là không lưu trữ tài liệu dự án cho đàng hoàng, không có chỗ lưu tập trung thì truy vết lại một quyết định khó vô cùng.
Hậu quả của cả ba dồn vào đúng một thời điểm, lúc dev bắt bug, mình cần tài liệu để đối chiếu mà không tìm được, vì hồi triển khai mọi thứ chỉ nói miệng hoặc nhắn tin, không có bằng chứng nào cho thấy yêu cầu đã được chốt ra sao.
Buồn cười là môi trường làm việc khá hiền hòa, không ai cãi nhau, nhưng không cãi nhau đâu có nghĩa là không mất thời gian, thiếu tài liệu thì người ta vẫn phải nhớ lại, đoán lại rồi mới fix được. Hiền hòa chỉ làm cái giá đó bớt ồn ào thôi.
vì sao nói miệng cho nhanh lại thành chậm#
Theo mình nói miệng với nhắn tin chẳng có lỗi gì, chúng nhanh, tự nhiên, nhiều quyết định nhỏ đúng là nên chốt như vậy, vấn đề nằm ở chỗ quyết định đó không được đưa về một nơi chính thức sau khi chốt. Tin nhắn trôi rất nhanh, một tuần sau nó nằm dưới hàng trăm tin khác, vài tháng sau người trong cuộc có khi đã chuyển team hoặc nghỉ việc, lúc đó câu đã chốt gì không còn ai trả lời chắc được, bên nào cũng giữ một phiên bản trí nhớ của riêng mình.
Trong BABOK Guide v3, mảng này nằm trong phần quản lý vòng đời yêu cầu (requirements life cycle management), trong đó có traceability, tức là khả năng lần ngược từ một chức năng về yêu cầu gốc và quyết định đã sinh ra nó. Mình không dẫn nguyên văn ở đây, nhưng ý thì đơn giản, không lần ngược được thì bạn không biết một hành vi của hệ thống là bug hay là đúng như đã chốt.
viết tài liệu nhiều thì chậm, Agile mà#
Đây là lý do phổ biến để không viết, và nó đúng một nửa. Agile Manifesto đặt phần mềm chạy được lên trên tài liệu đầy đủ, nhưng ưu tiên hơn không có nghĩa là bỏ hẳn, chỗ hiểu sai là đánh đồng documentation với việc viết một bộ tài liệu dày cho đẹp. Thứ cần giữ thật ra không nhiều, quyết định nào được chốt, ai chốt, khi nào, vì sao, vài dòng là đủ, còn thứ tốn thời gian thật không phải viết vài dòng đó, mà là lúc bắt bug phải ngồi tái dựng chúng từ trí nhớ của nhiều người.
Một kiểu hiểu sai khác là nghĩ tin nhắn cũng là bằng chứng rồi, về lý thuyết thì có, nhưng không ai tìm lại được thì cũng như không, bằng chứng phải nằm ở chỗ người khác biết mà tìm.
theo mình nên làm thế nào#
Từ mấy lỗi trên, đây là những thói quen mình nghĩ BA nên giữ, quan điểm của mình thôi, bạn chỉnh theo dự án.
Đầu tiên là gửi meeting note trong ngày, kể cả khi chỉ có ba dòng, một meeting note ngắn gửi ngay có giá trị hơn một biên bản đầy đủ không bao giờ được gửi, chỉ cần ghi đã chốt gì, ai làm gì tiếp, còn câu hỏi nào mở, bận quá thì gửi bản nháp ghi rõ sẽ bổ sung, vẫn hơn im lặng.
Thứ hai là đưa quyết định từ tin nhắn về tài liệu chính thức. Giả sử key user nhắn bỏ bước duyệt thứ hai cho đơn dưới một mức tiền nào đó cũng được, việc của BA lúc đó là cập nhật vào tài liệu yêu cầu, ghi ngày và người đồng ý, rồi nhắn lại một câu xác nhận, tin nhắn vẫn là nơi trao đổi, còn tài liệu là nơi lưu kết luận.
Thứ ba là tài liệu nào cũng có version và lịch sử sửa, không cần công cụ xịn, một bảng nhỏ đầu file gồm số version, ngày, người sửa, nội dung thay đổi là đủ trả lời câu bản này khác bản trước ở đâu, cũng là tinh thần của configuration management, biết chính xác đang dùng bản nào.
Thứ tư là một chỗ lưu trữ duy nhất cả team đều biết, chứ không phải mỗi người một thư mục trên máy, dev hỏi tài liệu ở đâu thì câu trả lời nên là một đường dẫn, không phải để anh tìm lại đã.
Giả sử bạn làm đủ bốn việc này rồi dev báo bug, bạn mở tài liệu ra là thấy version nào chốt yêu cầu đó, ai đồng ý, ngày nào, cuộc nói chuyện chuyển từ hồi đó hình như sang đây là cái đã chốt, giờ mình xem có cần đổi không. Nhanh hơn, mà cũng nhẹ người hơn cho cả hai bên.
documentation đi cùng tài liệu nào#
Còn rối giữa các loại tài liệu yêu cầu thì bài BRD, SRS, FS khác nhau thế nào giúp phân biệt nên ghi quyết định vào đâu, đội bạn làm theo user story thì đọc thêm use case và user story để thấy phần để làm gì cũng là một dạng bằng chứng, và tới giai đoạn kiểm thử thì kịch bản UAT trong dự án ERP là nơi tài liệu đã chốt được đem ra đối chiếu thật.
Documentation không phải giấy tờ cho sếp xem, nó là bằng chứng để sau này bạn, dev và khách khỏi phải đoán lại những gì đã chốt, bắt đầu từ việc nhỏ nhất là cuộc họp tiếp theo, gửi meeting note ngay trong ngày. Bạn đã bao giờ mất dấu một quyết định chỉ vì nó nằm trong tin nhắn chưa? Kể mình nghe qua Facebook hoặc LinkedIn nhé.
