src: thinhnotes.com

Quy trình làm dự án

Đầu tiên sẽ là quy trình tổng quan như sau.

Quy trình dự án

Như anh em thấy quy trình làm phần mềm nó gồm 6 bước:

• Analysis: phân tích xem mình sẽ làm những gì

• Design: mình sẽ thiết kế phần mềm như thế nào

• Develop: mình sẽ code ra sao

• Test: phần mềm được đem đi test

• Deploy: phần mềm được đưa vào sử dụng

• Maintain: giai đoạn bảo trì, hỗ trợ khách hàng sử dụng phần mềm.

Quy trình dự án về cơ bản gồm 6 bước trên, nhưng thực tế nó sẽ linh hoạt theo từng phương pháp quản lý dự án (project management methodology).

Phương pháp quản lý dự án là những thứ như: Scrum/Agile, Waterfall, Kanban, Lean…

Ví dụ đối với Waterfall thì quy trình sẽ đi theo trình tự từ trái qua phải (không đi ngược lại), mỗi bước chỉ đi qua 1 lần.

Cụ thể như analysis xong rồi, thì mới tới giai đoạn design, rồi xong design thì mới tới develop, tương tự là test >> deploy >> maintain.

Tức mình phải đợi dự án chạy từ đầu tới cuối thì mới dòm được thành phẩm cuối cùng hình dạng nó ra sao.

Còn đối với Scrum thì anh em sẽ chia nhỏ requirements ra thành các User Story, gom vào từng Sprint Backlog để làm dần dần. Tức mình chia nhỏ ra thành từng cục để làm.

Vậy thì quy trình trên sẽ không đi từ đầu tới cuối 1 lần duy nhất, mà đi nhiều lần từ analysis -> deploy, tạo thành nhiều sprint, nhiều vòng lặp. Mỗi vòng lặp sẽ làm một số tính năng nhất định, nên thời gian sẽ được rút ngắn còn khoảng từ 2-4 tuần/ sprint.

Do đó, khách hàng sẽ thấy ngay được sản phẩm của mình thành hình dần dần, từ đó góp ý để cải thiện sản phẩm ngày một phù hợp hơn với họ.

Mình nói đoạn này để anh em hiểu bản chất làm dự án phần mềm nó cũng chỉ gồm 6 bước thôi, dù cho có làm Scrum hay Waterfall, hay bất cứ phương pháp nào.

(mặc dù ở mỗi phương pháp nó có 1 tí râu ria liên quan khác nhau, cái này mình sẽ nói sau nhé anh em…)

Một điểm nữa là requirement sẽ đi xuyên suốt từ đầu đến cuối dự án thông qua 6 bước này. Là BA, chúng ta cũng sẽ phải đi xuyên suốt từ đầu đến cuối dự án qua 6 bước này luôn.

Requirement xuyên suốt từ đầu đến cuối dự án

Giờ mình sẽ nói chi tiết về từng bước có trong dự án, và BA làm gì ở trỏng nhé anh em 😎

1. Analysis

Analysis là giai đoạn team dự án sẽ phân tích để hiểu được vấn đề của khách hàng và những gì mà họ đang mong đợi.

Đối với BA, đây chính là giai đoạn lấy yêu cầu.

Anh em sẽ làm rất nhiều bước nhỏ trong bước Analysis này để lấy yêu cầu một cách bài bản nhất (chứ không phải nói “lấy yêu cầu” là bay zô làm cái một, hỏi tùm lum tùm la là được)

Cụ thể Analysis gồm 6 bước nhỏ sau.

Thực chất mình chỉ cần focus vào 2 bước Elicitation và Analysis, vì các bước còn lại khá đơn giản, đều là những bước hiển nhiên mình phải làm.

1.1. Project Definition

Mục đích của bước này là để anh em BA chúng ta hiểu được project. Hiểu được project này làm gì, khách hàng là ai, lĩnh vực gì, vấn đề của họ ra sao, mục tiêu của họ là gì, scope dự án như thế nào…

Problem to be solved

Ví dụ như khách hàng đang dùng hệ thống SAP gặp lỗi nhiều quá, họ muốn build mới một hệ thống khác chạy ngon hơn.

Hoặc họ đang không có hệ thống quản lý kho bãi, vẫn đang tốn tiền nhân công, hiệu suất thấp, và sai sót vẫn còn xảy ra; thì đây chính là vấn đề họ cần giải quyết

Business Goal

Ví dụ họ muốn quản lý quan hệ khách hàng bằng một phần mềm nào đó. Hoặc triển khai thành công hạ tầng IoT cho 5,000 hecta cà phê đang trồng chẳng hạn.

Business Case

Là những hiện trạng cụ thể của khách hàng. Ví dụ công ty con này mới thành lập được 5 năm, hoặc công ty mới vừa bán hàng cho thị trường Châu Mỹ được gần 1 năm.

Project Scope

Phạm vi của dự án. Là BA, anh em cần phải hiểu rõ khoản này. Thường anh em sẽ chú ý tới:

• Organization Scope: ví dụ dự án được thực hiện tại Head Office ở Hồ Chí Minh, địa chỉ bao nhiêu đó. Công ty con ở Đà Nẵng hay Hà Nội không được áp dụng.

• Users Scope: hệ thống có bao nhiêu người dùng, thuộc những bộ phận nào.

• Functional Scope: cái này quan trọng nhất – mô tả những chức năng của hệ thống mà khách hàng mong muốn.

• Integration Scope: thực chất nó là 1 Non-Functional Requirement, nhưng được tách ra phần riêng, mô tả phạm vi tích hợp: hiện tại khách hàng đang dùng những hệ thống gì, cần tích hợp những components nào, tần suất ra sao, vâng vâng…

• Và cuối cùng là OUT OF SCOPE: anh em xác định trước những thứ sẽ nằm ngoài phạm vi dự án, kiểu như rào trước vậy đó.

Project Plan

Anh em đã nắm được lịch dự án của PM hay chưa, có khó khăn về thời gian không, theo lịch thì có đoạn nào cần gấp, dồn sức nhiều hay không… Và cuối cùng là.

Success Criteria

Cái này anh em có thể trao đổi với PM để hiểu hơn về dự án, về khách hàng: đâu là điểm họ kỳ vọng nhất, làm họ happy nhất. Focus vào điểm đó, anh em sẽ dễ đóng dự án hơn rất nhiều!

…

Sau khi hiểu được tổng quan dự án, anh em sẽ bắt đầu vô bước MOI MÓC YÊU CẦU – Elicitation 😎

1.2. Elicitation

Elicitation tức là moi móc thông tin, moi móc yêu cầu từ phía khách hàng. Moi móc nghĩa là nó không có sẵn để anh em lấy, mà phải làm tùm lum tùm la mới ra được.

Sự khác biệt giữa Collect và Elicit.(Nguồn ảnh: ModernAnalyst.com)

Ở bước Elicitation, anh em cần nắm được các phương pháp moi móc thông tin. Phổ biến nhất có 11 phương pháp sau:

1. Meeting

2. Data Analysis

3. Interface Analysis

4. Prototyping

5. Business Rules Analysis

6. Observation

7. Bench Marking

8. Mind Mapping

9. Process Analysis and Modeling

10. Survey

11. Document Analysis

Sau khi nắm được 11 phương pháp, anh em sẽ đi vào quy trình Elicitation, gồm 4 bước nhỏ sau.

Mình có 2 bài note nói về nội dung này, anh em bấm vào link dưới tham khảo thêm nhé:

• 11 phương pháp moi móc yêu cầu

• 4 bước moi móc yêu cầu (như link trên)

• Những lưu ý khi lấy yêu cầu

Sau bước này anh em sẽ có output là thông tin, rất nhiều thông tin.

Trong mớ thông tin này, anh em có thể có luôn yêu cầu cụ thể, yêu cầu mơ hồ, câu trả lời từ phía khách hàng; hoặc đơn giản chỉ là những thứ mà khách hàng nói với mình vì họ nghĩ những thông tin đó là cần thiết.

1.3. Analysis

Sau khi anh em đã hiểu dự án (project definition) và moi móc được một mớ thông tin (elictation), giờ anh em sẽ lấy mớ thông tin đó ra, và bắt đầu phân tích nó.

Thường thì mọi người không hiểu “phân tích” cụ thể sẽ làm những gì. Mình cũng vậy, cho đến khi mình gặp 1 anh Manager đẹp chai mà mình rất hâm mộ. Ảnh nói rằng:

Phân tích đơn giản chỉ là sắp xếp & phân loại mọi thứ lại cho đẹp đẽ, sạch sẽ mà thôi 🙂

Hay Sandhya Jane (tác giả cuốn Business Analysis: The question and answer book) cũng có nói rằng:

“Analysis means simply breaking down the information of an object, entity, process, or anything else to understand its functioning“

Sandhya Jane

Ngẫm đi ngẫm lại thì đúng là vậy anh em ạ.

Giám đốc ngân hàng yêu cầu phân tích xem: vì sao quý này nợ xấu lại tăng cao đến như vậy?

Lúc này bộ phận kinh doanh sẽ làm gì? Chẳng phải anh sếp kinh doanh ảnh sẽ yêu cầu đổ toàn bộ dữ liệu các giao dịch cho vay trong khoảng thời gian phù hợp. Rồi phân loại rõ ràng theo các tham số: đối tượng khách hàng, phân khúc sản phẩm, hạn mức, kỳ hạn trả, vâng vâng và vâng vâng…

Anh em có nhận ra anh sếp kinh doanh này đang làm gì không? Chính xác là ảnh đang sắp xếp & phân loại mọi thứ cho ra ngô ra khoai 🙂

Để từ đó ảnh mới có thể làm tiếp công việc mà ảnh được trả hàng nghìn đô một tháng để làm, đó là: nhìn số liệu >> tìm ra vấn đề >> và giải quyết.

…

Phân tích với BA cũng tương tự như vậy.

Khi khách hàng có vấn đề trong bộ máy hoạt động, họ sẽ tìm đến mình. Và sau một loạt các buổi elicit requirement, chúng ta sẽ lấy được rất rất nhiều thông tin từ khách hàng (hoặc không).

Nhiệm vụ của anh em là phải xác định được: Đâu mới là vấn đề thực sự của khách hàng, và đâu mới là cái họ cần nhất ngay lúc này.

Hãy tưởng tưởng từ một mớ hỗn độn thông tin lấy được, chúng ta sẽ rất khó để biết được:

• Đâu mới là vấn đề thực sự của họ

• Đâu là những yêu cầu thực tế

• Đâu là những yêu cầu tầm bậy tầm bạ

• Và đâu là những thứ khách hàng thực sự nên ưu tiên vào lúc này…

Bước Analysis sẽ giúp anh em làm rõ những điều trên. Cụ thể ở bước này anh em sẽ làm những thao tác sau.

Theo trình tự, anh em sẽ:

(1) Organize

Tức là sắp xếp, tổ chức lại các requirement.

Ví dụ: tệp ảnh ra tệp ảnh, tệp ghi âm ra tệp ghi âm, thông tin về nhóm nghiệp vụ quản lý khách hàng gom chung lại 1 chỗ, nghiệp vụ quản lý chất lượng gom chung lại 1 chỗ khác, ví dụ vậy. Để mình có cái nhìn tổng quan nhất.

(2) Functional Decompose

Bước này anh em sẽ phân rã các yêu cầu thành các yêu cầu nhỏ hơn, cụ thể hơn. Mục đích là để có cái nhìn thực tế nhất về tính khả thi của các yêu cầu này.

Ví dụ họ muốn hệ thống có khả năng nhắc nhở các buổi họp định kỳ với đối tác của khách hàng (\).*

Vậy thì anh em sẽ phân rã ra, để làm được yêu cầu trên thì hệ thống phải có chỗ ghi nhận được các buổi họp định kỳ đúng không anh em? Sau đó phải có một cái job nó chạy định kỳ, cứ trước 3 ngày diễn ra cuộc họp là gửi email nhắc nhở.

Vậy thì sau khi phân rã (\)*, anh em sẽ có như sau:

• Tính năng lưu trữ thông tin cuộc họp

• Tính năng gửi email nhắc nhở dựa trên thời gian cuộc họp.

Để sau này khi ngồi lại với dev, anh em sẽ dễ dàng giải thích và cũng dễ để xác nhận với khách hàng hơn, là: “à tụi em sẽ làm như vầy, như vầy nha chị…”. Kiểu vậy.

(3) Prioritize

Bước này là bước đánh số thứ tự ưu tiên cho từng yêu cầu cụ thể của khách hàng.

Ví dụ có 3 yêu cầu sau:

• Hệ thống phải lưu trữ được thông tin khách hàng (a)

• Hệ thống phải tự động thông báo những khách hàng đã mua hàng trên 5,000,000đ trong tháng (b)

• Hệ thống phải tạo được đơn hàng với thông tin bảng giá lấy từ hệ thống quản lý bán lẻ A Á Ớ Bờ Cờ (c)

Thì mình sẽ đánh giá mức độ ưu tiên của yêu cầu (b) thấp hơn yêu cầu (a) và (c). Vì phải có dữ liệu khách hàng và đơn hàng thì mới có thể lọc được thông tin khách mua hàng trên 5 triệu trong tháng.

Anh em có thể tham khảo một vài tiêu chí phân loại Requirements dưới đây.

Tiếp theo là 2 bước Validate và Verify. 2 bước này đều là 2 bước xác nhận, nhưng nó khác nhau ở chỗ:

(4) Validate

Do the thing right

(5) Verify

Do the right thing

…

Nói về bước Analysis, anh em tham khảo thêm bài note này nhé, mình có nói chi tiết kèm ví dụ ở note này: Hiểu về Requirement như thế lào cho đúng???

Sau 3 bước quan trọng đầu tiên: Project Definition >> Elicitation >> Analysis, anh em sẽ đi tiếp tới 3 bước cuối cùng.

Nãy giờ chúng ta đã đi được 3 bước này.

1.4. Documentation

Bước documentation nôm na nghĩa là anh em sẽ tài liệu hóa, tức là đem toàn bộ những thứ làm được nãy giờ bỏ vô tài liệu.

Tài liệu đó chính là SRS, hoặc FRD, tùy loại dự án mà mình có những loại tài liệu khác nhau nhé anh em. Nhưng mục đích chung thì vẫn là để mô tả chi tiết yêu cầu của khách hàng.

Để document thì anh em sẽ áp dụng 2 thứ sau:

1. Tận dụng các template có sẵn

2. Dùng ngôn ngữ mô hình hóa để document.

Ngôn ngữ mô hình hóa có khoảng 20 loại. Trong đó có 2 loại phổ biến nhất là BPMN và UML.

Template thì tùy công ty. Công ty của anh em dùng template gì thì anh em cứ dùng template đó thôi. Có thời gian mình sẽ share về các template này sau nhé.

1.5. Verification

Sau khi document xong, anh em sẽ chuyển cho team verify lại một lần nữa. Cụ thể là QA hoặc PM.

Họ sẽ kiểm tra lại xem thử anh em đã document đúng chưa, đủ các phần yêu cầu chưa. Đặc biệt là PM sẽ kiểm tra lại các yêu cầu của khách hàng đã được document chính xác và hợp lý hay chưa.

1.6. Management

Bước cuối cùng là management, tức là anh em sẽ quản lý các document sau khi đã xong xuôi. Quản lý ở đây là quản lý gì?

Ví dụ nếu requirement thay đổi, tức nội dung của tài liệu SRS hoặc FRD thay đổi, thì anh em phải đánh dấu version như thế nào, duyệt nội bộ rồi gửi cho khách hàng duyệt như thế nào.

Quản lý requirement sao cho dễ keep track cũng là một vấn đề khá nhức nhối :)) anh em nào có kinh nghiệm share bên dưới cho mình nhé.

Stop station…

Dừng chân recall một chút về 6 bước nãy giờ nhé anh em. Mục đích mình làm bài bản 6 bước này là để ra được 1 loại document mô tả chi tiết yêu cầu của khách hàng.

Như mình nói ở trên nó là SRS (Software Requirement Specification) hoặc FRD (Functional Requirement Document). Và có thể là 1 số loại template khác nữa, tùy công ty.

Trong 6 bước này, anh em lấy bước Elicitation và Analysis làm trọng tâm. Vì hầu như các bộ kỹ năng cứng của BA đều nằm ở đây hết.

Cái BA mình cần deliver được sau 2 bước này chính là REQUIREMENT. Nếu nhìn xuyên suốt qua cả 2 bước, anh em sẽ thấy requirement nó đi như sau:

2. Design

Ở bước này, tùy level, trách nhiệm, và loại dự án, mà BA sẽ tham gia vào ít hoặc nhiều.

Thực tế xảy ra là: hiếm khi BA ghi nhận các được yêu cầu một cách chi tiết ngay ở bước analysis. Nếu có thì chỉ ở mức độ high level. Còn tiểu tiết như từng User Story thì rất khó.

Do đó thường thì ở giai đoạn này (và có thể là các giai đoạn sau), BA sẽ phải trao đổi thêm với khách hàng để làm rõ các yêu cầu (những anh em nào đã kinh nghiệm, có khả năng clarify rõ ràng mọi thứ ngay từ đầu thì những giai đoạn sau này sẽ đỡ hơn rất nhiều).

Chưa kể nếu dự án triển khai theo Agile thì yêu cầu thay đổi liên tục, đòi hỏi anh em phải quản lý các requirement bài bản và làm việc với khách hàng nhiều về các yêu cầu thay đổi này.

Đó là phía mình, còn về phía khách hàng, nhiều khi họ còn chưa chắc về những yêu cầu họ đưa ra. Mà business thay đổi thì là chuyện một sớm một chiều.

Nên đây là chuyện hết sức bình thường: Requirement sẽ luôn thay đổi không ít thì nhiều xuyên suốt dự án. Đó là lý do vì sao mình vẽ đường //Requirement// màu xanh lá trên cùng chạy xuyên suốt dự án đó anh em 😎

Ở bước design, anh em sẽ can thiệp sâu một ít về kỹ thuật, bao gồm những thứ như:

• Thiết kế Database

• Vẽ Data Flow

• Vẽ Mockup

• Thiết kế UX/UI

• Thiết kế Business Process Flow

• Thiết kế bộ phân quyền hệ thống

• Vẽ Solution Architect

• …

Nghe tùm lum tùm la nhưng những điểm trên không phải một mình BA thầu hết (may quá), mà phải có sự can thiệp/ support của các anh em khác, có thể là Dev, Technical Architect, hoặc PM…

Và những thứ này sẽ linh động theo tùy loại dự án. Như những dự án triển khai thì sẽ không cần thiết kế UX/UI hay vẽ mockup.

Tuy nhiên mình thấy trong các thứ trên, hầu như BA sẽ thầu hết 70%.

Solution Architect thì TA sẽ làm. Database thì BA làm cũng được, nhưng cần có sự review từ toàn team vì nó sẽ ảnh hưởng đến những thứ trong tương lai. Còn về UX/UI thì có anh em designer làm chứ BA mình không có chuyên môn để làm phần này (và thường thì cũng chẳng có BA nào đi design UX/UI cả – trừ khi thiếu resources dữ lắm thôi).

Sau cùng cả team sẽ gom các kết quả lại để ra được thành phẩm cuối cùng là: Tài liệu thiết kế.

Để cho sang thì anh em hay gọi là SDD (Software Design Document) hoặc FDD (Functional Design Document).

…

Ô kê, vậy là qua 2 giai đoạn (Analysis và Design), chúng ta đã có được 2 tài liệu quan trọng:

• Tài liệu mô tả yêu cầu (SRS/FRD)

• Tài liệu thiết kế (SDD/FDD)

Có hàng nóng trong tay, anh em developer sẽ bắt đầu HIỆN THỰC HÓA sản phẩm bằng cách viết những dòng code đầu tiên.

3. Develop

Giai đoạn này anh em BA sẽ hỗ trợ Development Team trong quá trình build sản phẩm.

Ví dụ có Use Case nào chưa rõ, anh em sẽ giải thích để dev họ hiểu hơn về mục đích của Use Case. Hoặc nếu anh em làm giai đoạn Analysis và Design không kỹ, thì giai đoạn Development sẽ lòi ra những lỗi logic giữa các yêu cầu với nhau.

Ví dụ yêu cầu này conflict yêu cầu kia. Thì lúc này anh em BA phải làm việc lại với khách hàng để làm rõ vấn đề, rồi update lại cho Development Team để anh em làm tiếp.

Sau khi Development Team build xong một hoặc nhiều tính năng nào đó, chúng ta sẽ phải test các tính năng này.

4. Test

Giai đoạn test gồm 2 giai đoạn nhỏ: Internal Testing và External Testing.

4.1. Internal Testing

Internal Testing tức là nội bộ team dự án tự kiểm tra với nhau xem thử các tính năng đã được build đúng chưa, trước khi release cho khách hàng.

Đây có thể là nhiệm vụ của BA, hoặc không.

Các Software Development Team luôn có vai trò QC. QC sẽ là người chịu trách nhiệm test các tính năng vừa mới build này. Đảm bảo Dev làm đúng theo như tài liệu yêu cầu/ thiết kế, và đảm bảo team deliver đúng như những gì đã cam kết với khách hàng.

QC sẽ viết các Test Case để kiểm tra từng tính năng một.

Còn đối với các dự án triển khai, Software Implementation Team thường sẽ không có QC. BA trong team sẽ chịu trách nhiệm cho các phần test này luôn.

Vì so với những dự án build mới từ đầu, độ chính xác của các tính năng chuẩn trong các dự án triển khai sẽ cao hơn rất nhiều.

Vì triển khai là triển khai những gì đã có sẵn. Những tính năng này đều do các hãng lớn build sẵn, nên hầu như việc sai sót là không có.

BA trong các dự án triển khai chỉ cần test lại các tính năng “khác lạ so với chuẩn”. Tức là những tính năng customized mà khách hàng yêu cầu. Chứ không cần test lại toàn bộ các tính năng từ nhỏ tới lớn mà dev build như login, authorization, CRUD, import/export…

Ngoài Test Case ra, anh em BA cần phải chuẩn bị một thứ nguy hiểm hơn, đó là: Requirement Traceability Matrix (RTM).

RTM cũng không có gì quá ghê gớm. Anh em chỉ cần lấy Test Cases map với Requirements là sẽ ra được RTM.

Mục đích của Requirement Traceability Matrix là để anh em trace lại được là các Requirement đã được test hay chưa, và test thành công hay thất bại. RTM sẽ giúp anh em control được “sức khỏe” của các requirements xuyên suốt dự án.

4.2. External Testing

Sau khi team đã test nội bộ với nhau và chắc chắn rằng: “à những tính năng này đã được build đúng & build đủ”. BA sẽ thực hiện các buổi User Acceptance Test (UAT) với khách hàng.

User Acceptance Test là buổi mà một vài key-users của khách hàng sẽ ngồi test lại hệ thống từ đầu đến cuối, dựa trên Test Case mà khách hàng tự viết hoặc bên đối tác viết (cái lúc nãy).

Sau khi test xong, nếu có vấn đề gì thì anh em phải sửa lại và thực hiện UAT lại. Còn nếu mọi thứ ô tô kê thì dự án sẽ qua bước tiếp theo: Deploy cho end-users sử dụng 😎

5. Deploy

Đối với BA, anh em có thể hiểu Deploy nghĩa là mình sẽ làm tất cả những thứ để hệ thống sẵn sàng được sử dụng. Những thứ đó có thể là:

• Build solution từ môi trường Dev lên môi trường Production.

• Migrate data: là chuyển toàn bộ data hiện tại của khách hàng từ hệ thống cũ sang hệ thống mới.

• Thiết lập người dùng như: phân quyền, cập nhật tài khoản, thông tin cá nhân…

• Hướng dẫn người dùng sử dụng hệ thống

• Và một số thứ râu ria khác tùy dự án, như: bật audit hệ thống, kích hoạt các batch job, hoặc chuẩn bị Go-Live Checklist.

Ở bước này mình muốn highlight với anh em dòng “hướng dẫn người dùng sử dụng hệ thống” như nhiệm vụ chính của BA trong giai đoạn này. Các phần còn lại, BA và anh em Developer sẽ cùng phối hợp thực hiện.

Để training end-users, anh em sẽ cần có tài liệu hướng dẫn (User Manual). User Manual có thể có nhiều dạng: tệp pdf, video, hoặc thậm chí là tài liệu prezi,… tùy nhu cầu và cách làm của mình.

Sau khi chuẩn bị xong User Manual, anh em sẽ tiến hành training cho end-users. Sau đó anh em sẽ làm một danh sách các điểm cần chuẩn bị để tiến hành Go-live, gọi là Go-live Checklist.

Ví dụ về Go-live Checklist – những thứ anh em cần chuẩn bị trước khi Go-live

Xong, vậy là coi như anh em đã sẵn sàng để Go-Live, cột mốc quan trọng bậc nhất trong bất kỳ dự án nào 😎

Sau giai đoạn Deploy trước giai đoạn Maintain sẽ là cột mốc Go-live. Giả dụ anh em đã Go-live thành công đi nhé, để mình qua giai đoạn tiếp theo :v

6. Maintain

Sau khi Go-live xong, tức là khách hàng đã thật sự sử dụng hệ thống, anh em sẽ vào giai đoạn cuối cùng trong quy trình làm dự án phần mềm, đó là Maintenance – Bảo trì (hoặc cũng có thể là Warranty – Bảo hành)

Thường thì các dự án mình làm sẽ bảo trì khoảng 1-3 tháng sau Go-live.

Bảo hành tức là mình sẽ hỗ trợ khách hàng, xem thử trong quá trình sử dụng họ có gặp vấn đề gì không, bug chỗ nào để mình hỗ trợ giải quyết kịp thời.

Khi có lỗi phát sinh, khách hàng sẽ gửi lỗi này lên một trang portal để BA và anh em trong team biết mà bay vô support. Hoặc đơn giản người Contact Point bên phía khách hàng sẽ tổng hợp các lỗi định kỳ hàng tuần/ tháng và gửi email cho team dự án.

Trong giai đoạn này, các lỗi đều sẽ được log lại để theo dõi “vòng đời lỗi” (nghe hoành tráng quáaa). Tức là lỗi từ lúc phát sinh đến lúc được giải quyết, ai là người phát hiện ra lỗi, thuộc phân hệ nào, nguyên nhân ra sao, tình trạng thế nào, và thời gian ghi nhận.

Ngoài ra, nếu anh em có các hoạt động support khách hàng tại văn phòng của họ (onsite các kiểu) hoặc online meeting, thì anh em sẽ phải làm những Activity Sheet, ghi nhận những hoạt động đó, để 2 bên có thể dễ dàng quản lý, đặc biệt trong trường hợp có chi phí phát sinh.

.

.

.

Ô kêêê anh em đã thấy mệt chưa. Vậy là coi như chúng ta đã đi xong một quy trình làm dự án!

Cùng nhìn lại những thứ mà BA sẽ deliver xuyên suốt dự án nhé anh em.

Mình nhắc lại là tùy kiểu quản lý dự án (project management methodology) mà quy trình trên sẽ thay đổi, nhưng về bản chất nó sẽ luôn bao gồm 6 giai đoạn trên, và công việc BA cũng sẽ không khác gì mấy trong 6 giai đoạn này.