Tôi từng được tham gia phỏng vấn với mấy anh chị leader team BA lúc trước. Họ thường hỏi ứng viên câu hỏi là: Theo em khi nào thì BA hoàn tất việc thu thập yêu cầu?

Câu trả lời thường thấy nhất là: Không bao giờ kết thúc?

Và thường câu trả lời này đến từ các bạn Fresher, Junior còn ít kinh nghiệm.

Có thể do bạn không hình dung được toàn cảnh mình phải làm gì (What to do) trong 1 dự án. Hoặc bạn biết phải làm gì những không biết để làm xong việc đó thì phải cho ra output nào, đạt những yêu cầu nào .

Thực ra có thể việc của BA có thể rất nhiều, rất dàn trải và không có định hướng. Nhưng nếu giữ mindset là việc sẽ ở đó và còn hoài thì mỗi sáng thức dậy đến công ty đi làm là một áp lực khủng khiếp. Nên hãy thay đổi tư duy, để nhìn thấy đâu là những thứ mà BA có thể kê cao gối ngủ khi đã bàn giao xong.

Tóm lại, BA có thể làm xong việc hay không? Câu trả lời là CÓ!

Các tiêu chí để gọi là xong:

1. Output phù hợp với từng giai đoạn.
2. Output đạt chất lượng (chính xác, rõ ràng, không dư thừa)
3. Output đúng deadline
4. Output của BA cần được confirm bởi stakeholder liên quan để chính thức khép lại 1 task của BA.
   

1. Output phù hợp giai đoạn

Để thấy được toàn bộ các giai đoạn của dự án và nhiệm vụ của BA thì bạn hãy xem lại bài viết về BA Framework. Hãy đảm bảo bạn đã nắm được chiếc “xương sườn” này thật chắc. Đây là nền tảng cho những thứ khác bám vào.

Có thể chia các giai đoạn của dự án ra thành

Khởi động – Tiến hành xây dựng giải pháp – Bàn giao giải pháp.

BA đều cần tham gia 3 giai đoạn này, và output của BA sẽ là input của các bộ phận khác trong team phát triển.

Việc lựa chọn output nào trong từng giai đoạn là rất quan trọng. Trong giai đoạn Khởi động, nếu bạn chọn tạo ra quá nhiều những document đi sâu vào mô tả chi tiết giải pháp thì có thể dễ dàng miss business requirement và dần dần lạc lối. Hoặc nếu đã bước qua giai đoạn bàn giao rồi mà vẫn quanh quẩn đi tổng hợp meeting minute thì quá là không ổn.

2. Output đạt chất lượng

Các output sau khi đã được xác định rồi thì cần phải được xây dựng thật chất lượng.

Có 1 vài yếu tố để nói lên chất lượng output của BA

Đúng – Đừng sai
Đủ – Đừng thừa, đừng thiếu
Rõ – Đừng phức tạp, đừng khó hiểu

Đây là kỹ năng mà BA cần phải rèn dũa qua thời gian. Đôi khi biết được mình phải làm gì là một chuyện. Làm ra output với một chất lượng đảm bảo lại là chuyện khó hơn và cần đổ mồ hôi để thành thạo.

Đúng

Gặp đúng người, hỏi đúng câu hỏi, lấy đúng thông tin, truyền đạt đúng ý nghĩa, sử dụng đúng format tài liệu… Một chữ Đúng này yêu cầu rất nhiều yếu tố cộng hưởng với nhau.

Đủ

Những kỹ thuật tránh miss requirement đọc thêm ở đây.

BA cần đề cao tính tối giản của tài liệu nhưng KHÔNG BAO GIỜ được miss requirement.

Việc viết 1 tài liệu đủ thông tin nhưng vẫn đơn giản mất thời gian hơn nhiều so với việc nhồi cả đống thông tin không sàng lọc vào 1 nồi lẩu thập cẩm. Điều đó phụ thuộc nhiều vào việc BA chọn đúng format để cấu trúc thông tin cho tài liệu đó, áp dụng các tuyệt kỹ đánh index, highlight keyword, reference, ….

Dev đọc vào 1 tài liệu và cảm thấy có đầy đủ input mà họ cần để bắt tay vào làm. Không cảm thấy rối rắm bởi các thông tin gây nhiễu. Tester cảm thấy nhìn vào document là có đủ input để viết test case,… Đó chính là khoảnh khắc “Oh Yeah!” mà BA mang lại.

Rõ

1 tổ chức, 1 dự án có hàng tá con người, mỗi người lại có background, cách diễn đạt, mục tiêu làm việc riêng. Nó giống như hàng đống vector đang kéo ra vô số hướng. Khi các vector không cùng hướng, chúng sẽ triệt tiêu lẫn nhau. Kết quả cuối cùng là dự án, tổ chức đó đứng yên hoặc tệ hơn là đi lùi.

Tác dụng của BA khi được thuê về là gom các vector đó về cùng 1 hướng.

10 người đọc 1 tài liệu và hiểu như nhau. Đó là rõ. Nếu 2 người đọc cùng 1 dòng nhưng lại hiểu theo 2 ý, vậy là chưa đạt.

Đọc thêm về cách viết requirement rõ như ban ngày ở đây.

3. Output đúng deadline

Cái này thì dễ hiểu rồi. Output của BA là input của nhiều bộ phận khác trong team. Hãy đảm bảo đúng deadline đã cam kết với team trong BA Plan. Cách viết BA Plan xem thêm ở đây.

Đôi khi bạn không kiểm soát hoàn toàn được các deadline của mình do bị phụ thuộc bởi sự hợp tác của stakeholder của mình. Hãy chủ động trong việc này, nhận định tình hình và tìm sự trợ giúp để đảm bảo hoàn thành được deadline sớm nhất có thể.

4. Output cần được confirm bởi stakeholder

Bạn viết document ra là để stakeholder xài. Vậy thì bạn cần sự xác nhận của chính người dùng cuối của các document hay tổng quát hơn là output của bạn.

Để đạt được sự confirm từ họ, ngay từ bước định hướng bạn đã phải biết stakeholder của mình kỳ vọng gì ở bạn rồi. Và bạn biết rõ khi output được tạo ra, nó đáp ứng trực tiếp cái mà stakeholder cần, kể cả về nội dung lẫn hình thức phù hợp với stakeholder.

Mục số 4 này có thể xem như là điều kiện đủ để BA hoàn thành công việc của mình một cách toàn vẹn. Bởi vì stakeholder sẽ chỉ thực sự signed-off 1 tài liệu hay output nào đó khi nó đúng, đủ, rõ và phù hợp với mong đợi của họ.

Okay, ngay khi nhận được sự confirm từ stakeholder. Bạn đã gạch bỏ được 1 task trong todolist của mình rồi đó.

Đó là câu hỏi mà bạn không hỏi.

Bất ngờ chưa bà già! Đúng rồi, nếu bạn có 1 câu cần hỏi stakeholder và bạn không thốt ra được câu hỏi đó khỏi miệng. Đó chính là bẽn lẽn không cần thiết và có thể dẫn tới một sai lầm.

Khi đặt 1 câu hỏi, bạn có thể tưởng tượng ra trong đầu cái cảnh, mấy người họp chung tủm tỉm cười, thì thầm nói xấu bạn, “sao có thể hỏi 1 câu basic vậy”, hoặc “vậy mà cũng hỏi, mà cũng đòi làm BA”.

Stop! Do not give a shit. Người ta không quan tâm nhiều vậy đâu và bạn cũng đừng quan tâm nhiều như vậy. Đó là việc của bạn.

Tại sao bạn không hỏi

Tất nhiên, để có được thông tin thì nghiệp vụ của bạn là đặt những câu hỏi có chủ đích và khui được nhu cầu ra. Nhưng đôi khi bạn cảm thấy không biết có nên hỏi hay không. Có thể là vì

1. Câu hỏi này quá basic, bạn nghĩ là đáng lẽ mình phải biết câu trả lời. Điều này xảy ra khi bạn làm BA cho 1 domain còn khá mới.
2. Câu hỏi này có vẻ như ai cũng biết, nếu không thì chắc đã có ai đó hỏi rồi.
3. Câu hỏi này bạn đã hỏi rồi, nhưng câu trả lời chưa khiến bạn hài lòng.

Cách xử lý

Cái ổng mới nói là gì ta, rồi nó liên quan gì tới quy trình trời???

Với những câu hỏi loại 1, việc bạn cần làm là làm quen với domain nhanh nhất có thể để có thể quen thuộc với những khái niệm và quy trình nền tảng của domain. Việc liên tục hỏi những câu như thế này chứng tỏ bạn “dốt” trong domain đó. Đó là thực tế, nhưng giấu dốt không phải việc BA nên làm. Nếu sợ quê thì hãy research thật kỹ, và khi nhận ra bị hổng kiến thức, hãy hỏi ngu một cách dũng cảm.

Có thể trong 1 hoặc 2 buổi họp đầu tiên với stakeholder, những câu như thế này sẽ xuất hiện dày đặc. Bạn có 2 hướng xử lý:

• Hỏi ngay lúc đó: nếu khái niệm hoặc 1 đoạn nào đó được trích dẫn nhiều và bắt buộc phải hiểu để có thể nắm được các ý phía sau. Hãy yêu cầu stakeholder giải thích ngắn gọn để bạn nắm được concept.
• Ghi chú và tham khảo sau: nếu nội dung bạn chưa nắm rõ không liên quan nhiều đến mạch thông tin chính, bạn có thể note lại vào sổ hoặc đâu đó trên laptop với 1 dấu ? to đùng. Tìm hiểu hoặc hỏi về nó khi có thời gian để hiểu hơn về domain.

---

Ủa sao không ai thắc mắc ta?

Với câu hỏi loại 2, rào cản duy nhất là tâm lý, là nỗi sợ nho nhỏ bạn tưởng tượng ra.

Bạn nghĩ ai cũng chắc ai cũng biết câu trả lời, giờ mà hỏi thì thành ra đứa dốt nhất phòng. Thực ra là không, có thể họ cũng không biết đáp án.

Rất nhiều lần mình hỏi 1 câu mà kiểu: “Xin lỗi cả nhà, em ngắt ngang xíu, nhưng mà e chưa phân biệt được A với B nó khác nhau như thế nào, a giải thích ngắn gọn giúp e được không ạ”.

Và sau khi hỏi xong thì nhận ra, có nhiều người cũng lót dép hóng, và khi stakeholder trả lời xong thì còn có người tranh luận về đáp án đó nữa. Chỉ là họ cũng ngại hỏi, khi đó bạn là người dũng cảm duy nhất đứng ra nói thay đám đông.

Có rất nhiều câu tưởng đơn giản, nhưng mỗi người là “ờ sum” theo một cách khác nhau. Đó chính là mầm mống của mâu thuẫn sau này.

Cho nên cách xử lý duy nhất và hiệu quả nhất là, hỏi ngay khi có cơ hội.

Nhớ lại đi, có bao giờ bạn đi họp với một ai đó mà người đó luôn đặt ra những câu hỏi là thắc mắc chung của cả phòng họp. Luôn hỏi rất nghiêm túc và da mặt rất dày, hỏi liên tục. Dần dần, bạn có 1 cảm giác an tâm, nếu họ không hỏi gì nữa thì bạn biết là tất cả vấn đề đã được ghi nhận. Họ sẽ luôn rời khỏi phòng họp với nhiều thông tin nhất. Sự tin tưởng sẽ được tạo ra.

---

Em biết là nãy anh trả lời rồi, nhưng mà…?

Kiểu câu hỏi này thì dễ xử lý hơn, khi bạn đã hỏi câu đó rồi nhưng đáp án không thật sự thỏa mãn và vẫn còn khúc mắc. Hãy tóm tắt, giả định và xác nhận.

Bạn hãy trình bày tóm tắt câu trả lời của họ theo cách hiểu của bạn. Và khi stuck ở chỗ nào, hãy giả định và xác nhận lại với họ xem bạn hiểu đúng không. Đó là lúc mà bạn sẽ nhận được câu trả lời kiểu “Ừ đúng rồi, nhưng mà ABCXYZ…”.

Đó là lúc những requirement sẽ lòi ra, họ sẽ giúp bạn trám vào những lỗ hổng kiến thức, tránh những giả định tào lao. Cách này cũng show cho stakeholder thấy khả năng lắng nghe tốt và đơn giản hóa những khái niệm phức tạp.

---

Việc lờ đi một câu nên hỏi có thể khiến bạn thoải mái một chút ngay lúc đó. Nhưng rồi nó sẽ quay lại, bay thẳng vô mặt bạn như cái boomerang. Cách đẹp nhất để xử nó là nhổ cỏ tận gốc. Đừng để 1 vấn đề nhỏ trở nên khó chịu trong tương lai.

Bài viết khuyên rằng Business Analysts (BA) không nên ngần ngại đặt câu hỏi, kể cả những câu hỏi cơ bản, để hiểu rõ vấn đề và tránh sai lầm.

Tại sao BA cần 1 framework?

Khi mới vào nghề, chúng ta có xu hướng bắt đầu từ các kỹ thuật BA, học cách viết các tài liệu và làm sao để lấy yêu cầu. Bạn gặp may nếu ở công ty của mình cádfasdfó 1 quy trình chuẩn, 1 người leader luôn nói cho bạn biết phải làm gì.

Bạn không biết lý do tại sao mình làm việc này ở thời điểm này. Bởi vì bạn không có 1 cái nhìn toàn cảnh về những gì BA phải làm – 1 bộ khung công việc của BA, aliền với vòng đời của dự án.

Giai đoạn 1: Định hướng

Đây là bắt đầu bước vào 1 dự án mới hoàn toàn hoặc đã được bắt đầu trước đó. Chúng ta sẽ có rất nhiều câu hỏi mơ hồ trong đầu kiểu: Dự án này là gì? Tại sao cần làm dự án này? Đó là những câu hỏi tổng quan đầu tiên và việc của bạn là tìm 1 câu trả lời rõ ràng.

Đừng vội đi vào chi tiết quá sớm. Bạn muốn bắt tay ngay vào tìm vấn đề và làm giải pháp ngay từ ngày đầu tham gia dự án. Nhưng điều đó rất dễ khiến mọi thứ chệch hướng hoàn toàn.

Đây là thời điểm để bạn tìm hiểu về những điểm còn mù mờ trong dự án, những thứ mà “bạn không biết là mình không biết”.

Những câu hỏi bạn cần trả lời và việc cần làm trong giai đoạn này:

• Dự án này là gì? Mục tiêu lớn nhất của nó là gì?
• Vai trò của bạn trong dự án là gì? Bạn cần tạo ra những output nào để đáp ứng nhu cầu của stakeholder.
• Các stakeholder chủ chốt là ai? Bạn sẽ tiếp cận họ như thế nào để lấy business goal và xác định scope của dự án?
• Nắm được tình hình dự án cho đến thời điểm hiện tại. Tránh việc làm lại những thứ đã được làm rồi.
• Hiểu được những thứ hệ thống đang có và những gì hệ thống làm được

Bạn có thể vượt qua giai đoạn này nhanh chóng bằng cách phương pháp gợi ý sau:

• Trân trọng những buổi brief mà stakeholder, PM hoặc PO dành cho bạn, cố gắng khai thác và hỏi càng nhiều càng tốt.
• Nhanh chóng xác định được stakeholder chủ chốt và tạo kết nối tốt với họ. Tận dụng việc trao đổi thông tin với họ cả trong các buổi họp chính thức và các cuộc trò chuyện không chính thức (1 buổi ăn trưa hay chầu cafe).
• Đọc tài liệu: lục tìm, hỏi xin tất cả tài liệu có sẵn của dự án để hiểu hơn về dự án. Tất nhiên, hãy cẩn thận những tài liệu outdate và không còn sát với thực tế.

Giai đoạn 2: Xác định nhu cầu business

Khi đã có được những thấu hiểu cơ bản về dự án. Bước tiếp theo đó là xác định Business Goal. Đây là loại input quan trọng nhất để đảm bảo dự án không lệch hướng trong tất cả giai đoạn tiếp theo.

Technical team có thể đảm bảo việc sản phẩm cho ra đáp ứng được Product Backlog. Nhưng BA sẽ là người chịu trách nhiệm đặt vào backlog những tính năng, những story giúp giải quyết Business Goal. Đó chính là kim chỉ nam của dự án.

Những gì cần làm trong giai đoạn này:

• Xác định Goal theo từng cấp độ:
  • Business: Cấp độ cao nhất, là vấn đề/nhu cầu cốt lõi mà dự án phải giải quyết hoặc đạt được. Thường được đưa ra bởi các stakeholder có quyền quyết định cao nhất trong dự án.
  • User: Những mục tiêu cụ thể hơn cần đạt để hoàn thành Business goal. Thường đưa ra bởi những người sẽ trực tiếp sử dụng sản phẩm mà dự án tạo ra.
  • Function and Non-function: Những yêu cầu sơ lược hơn về mặt tính năng hoặc phi tính năng mà hệ thống cần đảm bảo. Thường đối với những dự án mà client là những tổ chức lớn, chuyên nghiệp. Ngoài việc dự án đáp ứng các business goal và user goal thì còn có thêm các tiêu chí mà sản phẩm phải đảm bảo khi bàn giao.
• Bạn có thể bắt đầu tạo tài liệu BRD từ những nhu cầu này.
• Luôn confirm lại cách hiểu của bạn với stakeholder để chắc chắn không hiểu sai. Đây là 1 input rất quan trọng.

Giai đoạn 3: Xác định phạm vi thay đổi

Một phạm vi dự án đã được thông qua bởi các stakeholder là thứ giúp cho bạn và team “an tâm” suốt dự án.

Phạm vi nghĩa là định ra biên giới giữa cái “Phải làm” và cái “Không làm”. Tất nhiên việc tuyệt đối rõ ràng như trắng và đen là bất khả thi. Sẽ luôn có 1 vùng xám “Nên làm” hoặc “Có thể sẽ làm”. Nhưng việc có một hình dung về quy mô dự án sẽ giúp team không đi quá xa khỏi vòng tròn này.

Những gì cần phải làm trong giai đoạn này:

• Bắt đầu tìm hướng tiếp cận giải pháp cho các vấn đề/nhu cầu. Đánh giá xem quy trình và công nghệ sẽ phải thay đổi như thế nào về mặt bản chất để đáp ứng Business Goal.
• Tạo ra những bản phác thảo về phạm vi dự án và liên tục trình bày cho stakeholder chủ chốt cả phía business và phía technical – cho đến khi họ sẵn sàng để ký và thông qua Scope Statement.

Giai đoạn 4: Lập kế hoạch BA chi tiết

Một kế hoạch BA chi tiết xác định các kết quả cụ thể mà BA cần tạo ra cùng với một ước tính thời gian hoàn thành. Dự án sẽ cần output gì từ bạn để có thể làm rõ yêu cầu từ business và công việc tiếp theo cần thực hiện.

Nhiệm vụ của giai đoạn này:

• Chọn được các format output phù hợp để làm rõ requirement. Việc lựa chọn phụ thuộc vào phạm vi dự án đã định nghĩa ở bước 3, dự án chạy theo kiểu waterfall hay agile, nhu cầu của technical team và các yếu tố khác của dự án.
• Xác định được danh sách cụ thể các kết quả BA cần đạt và những stakeholder sẽ tham gia và hỗ trợ quá trình thực hiện. (template excel cho BA Plan)
• Xác định thời gian thực hiện mỗi task.

Nếu không dành thời gian ra để tự lập 1 kế hoạch thực tế và đáng tin cậy thì sẽ có hàng tá kỳ vọng từ stakeholder được gán cho bạn. Thường là những kỳ vọng bất khả thi vì họ không đánh giá đầy đủ được tính phức tạp đến từ nhu cầu.

Giai đoạn 5: Viết detail requirement

Bắt đầu từ giai đoạn này, BA sẽ liên tục giao tiếp với các stakeholder để elicite requirement về các tính năng hoặc quy trình cần thay đổi. Mục đích là viết ra các tài liệu mô tả chi tiết requirement. Đây là output trực tiếp nhất mà team technical cần để phát triển tính năng.

Requirement cần đạt được các yếu tố: cụ thể, đầy đủ và chính xác. Requirement không đầy đủ sẽ dẫn đến việc team triển khai ngụp lặn trong mơ hồ và chắc chắn ảnh hưởng kết quả đầu ra.

Những gì cần làm ở giai đoạn này:

• Thực hiện liên tục việc Elicite stakeholder, có được thông tin cần thiết để thực hiện thay đổi.
• Phân tích các thông tin thu thập được và chuyển hóa nó thành các tài liệu chi tiết cần cho dự án
• Xác nhận các tài liệu đã có với business stakeholder và technical stakeholder để bổ sung những thiếu sót nếu có.

Mức độ hiệu quả mà tài liệu do BA tạo ra sẽ nói lên mức độ hiệu quả của BA đó. Những tài liệu hữu hiệu có giá trị đẩy dự án tiến về phía trước nhanh chóng.

Chú ý đến việc làm rõ những thứ mơ hồ, cắt gọn những gì phức tạp. Hướng tới những cột mốc nhỏ và hoàn thành 1 cách liên tục.

Giai đoạn 6: Hỗ trợ technical team

Giai đoạn 6 yêu cầu BA có sự tham gia vào quá trình team phát triển sản phẩm thực hiện dựa trên requirement đã có.

Những gì cần thực hiện

• BA review các bản thiết kế cho giải pháp, đảm bảo giải pháp đó đang đi đúng hướng requirement đã mô tả. Ngoài ra, có thể gợi ý thêm giải pháp giúp đáp ứng những nhu cầu mở rộng của dự án mà không làm tăng phạm vi kỹ thuật.
• Cập nhập, chia nhỏ hoặc đóng gói các tài liệu requirement chi tiết để phù hợp hơn trong quá trình phát triển.
• Tương tác với chuyên viên kiểm soát chất lượng (QA) để đảm bảo là họ hiểu đúng hướng về requirement. Có thể review qua test plan và test case để đảm bảo đã hiểu rõ nhu cầu.
• Sẵn sàng trả lời khi có ai đó đặt câu hỏi trong suốt quá trình thiết kế giải pháp, lập trình, test của dự án.
• Quản lý các yêu cầu thay đổi, đảm bảo các stakeholder liên quan đều tham gia vào quá trình quyết định thay đổi và tiếp cận với tài liệu mới nhất.
• Nếu có thể, BA sẽ là người lead các buổi UAT (User Acceptance Testing) để đảm bảo sản phẩm đáp ứng nhu cầu business.

Giai đoạn 7: Hỗ trợ business triển khai giải pháp

Sau khi team technical của bạn đã tạo ra 1 sản phẩm xịn sò, đáp ứng mọi nhu cầu business rồi. Nhưng business user không sử dụng sản phẩm đó đúng cách và quay trở lại quy trình, thói quen làm việc cũ. Như vậy sẽ gây lãng phí nguồn lực và không giải quyết được nhu cầu business ban đầu.

BA sẽ phải tham gia luôn vào công đoạn cuối cùng của dự án để hỗ trợ business:

• BA cần phân tích và xác định rõ business process sẽ phải thay đổi như thế nào để đáp ứng sự thay đổi mà project đã tạo ra.
• Hướng dẫn, huấn luyện end-user để chắc chắn họ nắm luồng mới và các thủ tục cần thiết. Hoặc nếu có chuyên viên training riêng biệt thì BA sẽ phối hợp với bộ phận này để tạo ra các tài liệu và chương trình huấn luyện phù hợp.

Những bước ở trên đây là để đảm bảo tất cả các business user sẵn sàng tiếp nhận sự thay đổi được tạo ra bởi dự án

Giai đoạn 8: Đánh giá giá trị giải pháp

Tất cả mọi công đoạn chi tiết của dự án đã hoàn thành, kỳ vọng business đã được thảo luận, những vấn đề cả lớn lẫn nhỏ đã được giải quyết, các mối quan hệ đã được xây dựng, thay đổi đã được quản lý, kỹ thuật đã triển khai, người dùng đã được huấn luyện để sử dụng.

Hàng đống công việc và tập trung vào kết quả đầu ra có thể khiến cho chúng ta mất đi cái nhìn tổng thể. Liệu chúng ta đã và đang đi đúng hướng chứ? Giải pháp mà chúng ta tạo ra có đáp ứng được những kỳ vọng business như đã dự kiến?

Nhiệm vụ chính của giai đoạn này là:

• Đánh giá tiến độ thực sự của dự án dựa trên mục tiêu business để thấy được những kỳ vọng nào đã được đáp ứng.
• Trao đổi kết quả tiến độ với project team
• Đề xuất thêm các giải pháp cho những vấn đề mới phát sinh trong quá trình thực hiện project.

Áp dụng Framework vào dự án của bạn

Đa số BA thường không có 1 khung sườn cụ thể vì dường như mỗi dự án lại đòi hỏi 1 nhiệm vụ và quy trình làm việc khác nhau. Việc không có framework khiến bạn phải luôn nghĩ về việc mình phải làm gì tiếp theo, phải tự “bịa” ra một nhiệm vụ mà bạn cho là phù hợp.

Với 1 Framework gợi ý như trên, bạn sẽ có 1 chỉ dẫn sơ lược nhất về những gì cần thực hiện xuyên suốt 1 dự án công nghệ.

Bạn hoàn toàn có thể thay đổi và áp dụng 1 cách linh hoạt Framework trên để thật sự match với quy trình làm việc của mình.