Chào bà con, cũng mấy năm rồi mới ngồi lại viết. Có 2 lý do chính, một là bận, hai là hết chữ. Nhưng lý do chính là cái số 2. Trong mấy năm vừa qua mình tập trung vào việc trau dồi kỹ năng Requirement và Consultant, nôm na là tư vấn nghiệp vụ – công nghệ, và định nghĩa yêu cầu giúp khách hàng. Cũng thu được một chút ít kinh nghiệm nên nay sẽ viết trở lại. Trước mắt là Requirement Define (sâu hơn phần 1), sau đấy tới phần thiết kế và tư vấn giải pháp.
Mình nhắc lại một chút kiến thức như đã nói ở phần trước (viết cách đây 5 năm), vì cũng có nhiều bạn trẻ chưa hình dung được luồng dự án. Một dự án thông thường sẽ chạy qua các step sau.
1. Bối cảnh, mục đích, ý tưởng
2. Phân tích tài chính, được – mất và phương châm triển khai
3. Tư vấn giải pháp, chiến lược
4. Tìm đối tác (một hoặc nhiều) : 3 và 4 có thể đảo ngược tuỳ bối cảnh
5. Assessment : bao gồm business, technology, risk
6. PROJECT DEVELOPMENT
Trong [giai đoạn 6] thì sẽ có các [công đoạn] sau :
Trong bài viết này mình sẽ đi qua các mục bên dưới :
– Khái niệm
– Thành Phần
– Cách tiến hành
Khái Niệm và câu hỏi tiền đề
Định Nghĩa Yêu Cầu – 要件定義 (RD) là công đoạn đầu trong chuỗi qui trình phát triển phần mềm, nhằm mục đích tài liệu hoá các yêu cầu về tính năng hệ thống. Gồm 3 phần chính : nghiệp vụ, chức năng và phi chức năng
RD : viết tắt của Requirement Define
Có nhiều người sẽ nhảy bổ vào phán : Thời nay người ta làm Scrum-Agile, ai còn ngồi làm mấy cái RD vớ vẩn nữa, vừa tốn thời gian, chả được tích sự gì. Cũng giống như lúc bạn đang xây nhà cấp 4, sẽ có mấy ông bà rảnh việc đi ngang xỉa xói : thời buổi nào rồi còn xây nhà cấp 4, sao không xây nhà cao tầng, biệt thự. Dám cá luôn là giao cho họ cái chuồng heo cũng chưa chắc làm nổi. Vậy nên kệ đi, mình cứ học dần, làm dần, đắp từng viên gạch một, kiên trì tới 1 ngày nào đấy thành quả thu được sẽ hơn cả sức tưởng tượng của bản thân cũng như mấy ông hàng xóm “tốt bụng”.
Vậy thử đặt câu hỏi, có cần thiết phải làm RD không (Có nghĩa là bạn đủ năng lực để làm nhưng cân nhắc có nên làm hay không, khác với việc không làm được và chọn cách tránh né). Trả lời : Cái đấy còn tuỳ. Nó không phụ thuộc vào Model phát triển phần mềm (Agile/WaterFall) như các bạn vẫn lầm tưởng, mà phụ thuộc vào mục đích và ý tưởng của khách hàng. Khi mọi thứ chưa được rõ ràng, ngay cả khách hàng cũng không biết họ muốn gì thì thường sẽ áp dụng theo cách vừa làm vừa sửa, Agile được sinh ra như một hệ quả tất yếu để tiết kiệm chi phí – thời gian, và giảm risk cho cách làm cũ theo water-fall hay V-Model. Bởi vậy nên trong trường hợp này, requirement là không cần thiết hoặc được tinh giảm tối đa ở mức có thể biểu đạt ý tưởng bằng một vài câu chữ hoặc biểu đồ đơn giản – vì còn phải sửa đi sửa lại.
Câu hỏi 2, vì sao các dự án làm với Nhật đa phần đều có Requirement Define – Design rồi mới tới Code-Test ? Lý do thì có nhiều, nhưng có 2 lý do chính : Thứ nhất là văn hoá chắc cú đã ăn sâu vào tiềm thức của người Nhật, họ rất ghét sự mất kiểm soát – thay đổi liên tục. Thứ hai là trong một dự án lớn với nhiều bên tham gia, nó không phải đơn giản như việc code 1 cái app nhỏ demo-update, mà là các hệ thống với hàng trăm người cùng làm việc đồng thời. Bởi vậy cần có in-out rõ ràng.
Câu 3 : Có nên nhận làm RD hay để khách làm.
Câu 4 : Làm sao để xác định được độ sâu cần thiết (độ sâu = độ chi tiết)
Câu 5 : Thành phần bao gồm những gì, có cần thiết phải làm hết không hay chỉ 1 phần.
Câu 6 : Yếu tố cốt lõi của một RD tốt là gì
Câu 7 : Làm sao để nâng cao năng lực
Mình sẽ viết, còn việc hiểu và giải đáp lần lượt từng câu hỏi là của các bạn.
Thành Phần
Trên đây là danh sách gần như đầy đủ các file tài liệu cần thiết trong công đoạn.
Với những application đơn giản về mặt nghiệp vụ – kỹ thuật, không quá 20MM (man-month effort) Code-Test, hoặc các system thuộc loại Renew/Migration mà không thay đổi nhiều về mặt nghiệp vụ thì chỉ cần làm một số file : Flow nghiệp vụ tổng quan, danh sách màn hình và luồng di chuyển. Còn đối với các dự án lớn, phân bổ nhiều team thì cần làm hầu như toàn bộ.
Nghiệp vụ
Sau khi tiến hành, chúng ta sẽ có được bộ tài liệu cơ bản như này. Khi estimate các bạn cần chú ý về tỉ lệ % effort giữa Code-RD tuỳ vào độ sâu – độ rộng của tài liệu. Với hình trên thì rơi vào tầm 0.5–>0.7, tức là 10MM code thì cần 5–>7MM để RD, việc chênh lệch tuỳ vào lĩnh vực nghiệp vụ (quản lý sản xuất, tài chính – ngân hàng, bảo hiểm, quản lý nội bộ doanh nghiệp …) để điều chỉnh.
Với mỗi một loại tài liệu, cần chia làm 2 bước, bước 1 tổng quan – lấy xác nhận OK của khách trước khi tiến hành làm chi tiết hoá. Ví dụ : trước khi vẽ Flow, cần tạo 1 list danh sách tính năng hệ thống, đưa khách xem họ có bổ sung thêm bớt gì không, sau đấy mới ngồi vẽ lại sơ đồ hệ thống. Mặc dù biết là sau khi vẽ xong khách sẽ có yêu cầu thay đổi 1 đôi chỗ, nhưng chia làm 2 bước sẽ giảm thiểu thời gian re-work. Các bạn BrSE/PM cần chú ý chỗ này.
Với trường hợp hệ thống phức tạp, ở bước 1 thì ngoài file liệt kê chức năng, cần có flow hệ thống như file bên dưới để khách dễ hình dung.
Chức năng
Sau khi khách đã xác nhận, chúng ta tiến hành bước tiếp theo là chi tiết hoá Flow nghiệp vụ ở level [Cụm chức năng], trong đó có 3 thông tin chính : 1.Chức năng, 2.InputData, 3. OutputData. Data ở đây chưa cần tới mức table – field mà chỉ cần loại data như : thông tin khách hàng, thông tin sản phẩm, thông tin kho …
Ứng với từng nhóm chức năng, sẽ có tiếp 2 step nữa.
Step 1. Tách nhóm thành nhiều màn hình riêng lẻ và flow di chuyển. Ví dụ nhóm quản lý order bao gồm : Search Order, Order Detail, Order Update, Order Delete …
Step 2. Danh sách màn hình và detail chức năng – nhiệm vụ của màn hình.
Sau khi nhóm tất cả lại với nhau chúng ta sẽ có được bộ tài liệu về ScreenList-ScreenFlow cho toàn bộ hệ thống. Tới bước này thì mọi thứ đã gần như rõ ràng và có thể tiến hành Basic Design được rồi.
Phi chức năng
Phần này mọi người thường hay bỏ qua. Cũng đúng vì đa phần là làm theo thói quen hoặc khách hàng sẽ là người làm. Ví dụ qui định về tính bảo mật, tuỳ vào hệ thống để thiết lập network riêng, như admin system cần phải VPN mới access được chẳng hạn. Hoặc là điều kiện vận hành – bảo trì, cơ chế backup-revert data định kỳ hoặc khi xảy ra sự cố…
Cách Tiến Hành
Nhìn vào sơ đồ trên mọi người cũng hiểu được luồng rồi, có một chú ý ở phần phân tích tính khả thi về mặt kỹ thuật – nghiệp vụ. Người làm RD cần tỉnh táo và nhạy bén để biết được yếu tố nào cần cải tiến – thêm bớt – loại bỏ để đáp ứng được technical cũng như cost. Trong trường hợp có thể đáp ứng được nghiệp vụ – kỹ thuật nhưng phải mua library với mức giá rất cao mới làm được thì nên suggest phương án thay thế chẳng hạn. Lúc này RD đóng vai trò là Consultant.
Với chi tiết từng step cần – nên làm gì chắc mình sẽ chia sẻ trong 1 dịp khác.
Kết
Trên đây là bài viết chi tiết hơn 1 chút sau 5 năm lăn lộn bổ sung thêm kiến thức kể từ phần 1. Tính ra cũng chưa sâu lắm, để mình làm thêm ít năm nữa rồi viết phần 3. Cũng có khi lúc đấy người ta chả cần làm RD, 1 phát ăn Code luôn, hoặc cũng có thể không còn cần Code nữa mà sử dụng các FW-Platform No-Code, Low-Code để tiến hành …kéo thả. Có khi vậy cũng nên.
Nhưng các bạn đừng lo, làm được cái này không đói đâu. Đây là nền tảng để xây nên mọi thứ. Kể cả No-Code, muốn sinh ra 1 hệ thống kiểu vậy, hoặc để hiểu và vận hành các Platform đó cũng cần có mức độ sâu sắc về phân tích nghiệp vụ để đưa ra giải pháp. Như ví dụ từ đầu bài, kinh nghiệm xây được nhà cấp 4 sẽ giúp bạn xây được nhà cao tầng, và đừng bao giờ để tâm đến mấy lời xỉa xói từ những đứa ngay cả cái chuồng heo cũng không làm nổi.