nguyenhongduc

Tác giả: Duc Nguyen

  • Những thứ BA phải xong trong 1 dự án.

    Những thứ BA phải xong trong 1 dự án.

    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 đó.

  • Khái quát về ERD (Entity Relationship Diagram

    Khái quát về ERD (Entity Relationship Diagram

    ERD – Entity Relationship Diagram (hay sơ đồ mối quan hệ thực thể)

    Nghe tên là thấy sặc mùi kỹ thuật rồi. BA xuất thân business giờ nhiều lắm (chẳng hạn như mình), nên cái gì nặng kỹ thuật thì ngán lắm.

    Nhưng mà cái này nên biết, hoặc có thể nói là phải học vì nó giúp ích rất nhiều.

    ERD giúp gì?

    ERD giúp bạn hình dung mọi thứ dưới góc nhìn của developer, tư duy hướng đối tượng.

    Nắm được mô hình này, bạn sẽ hình dung các đối tượng quan hệ với nhau ra sau và dữ liệu được lưu vào Database như thế nào. Sẽ bắt đầu hình dung được Scope của hệ thống này rộng tới đâu.

    Từ đó tránh được việc lấy thiếu yêu cầu về tính năng, về các đối tượng của hệ thống, dẫn đến đánh giá sai phạm vi dự án (Scope), chi phí, thời gian…

    Ví dụ cho dễ hiểu:

    ### Không có ERD

    Một khách hàng đặt hàng hàng trên website mua 1 hoặc nhiều sản phẩm cho cùng 1 đơn hàng.

    Hệ thống cần lưu thông tin khách hàng gồm (tên, số điện thoại, địa chỉ) và đơn hàng (ngày đặt, sản phẩm, giá từng sản phẩm, tổng giá đơn hàng, nhân viên xác nhận).

    Nhân viên bán hàng cần xác nhận thông tin đơn hàng.

    Mỗi đơn hàng chỉ được đặt bởi 1 khách hàng và xác nhận bởi 1 nhân viên.

    ### Có ERD
    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Đấy, 1 tấm hình hơn ngàn câu nói. Nếu biết cách đọc ERD, bạn sẽ nắm bắt tổng quát nhanh chóng mà không gặp rắc rối với mớ từ ngữ lẫn lộn.

    Vậy nó có khó không? Mình thấy khá dễ. Bạn chỉ cần nắm những gì tổng quát là đủ để sử dụng.

    Những điều quan trọng của ERD

    Vì đây là lược đồ mối quan hệ giữa các đối tượng, nên 2 thứ quan trọng nhất đó chính là Đối tượng và Mối quan hệ

    Đối tượng (Entity)

    Khi đọc requirement về 1 quy trình hoặc 1 tính năng, hãy xác định các danh từ, trạng từ chỉ đối tượng, người, vật, hệ thống… mà cần phải lưu lại thông tin vào hệ thống để thực hiện các nghiệp vụ sau này.

    Ở ví dụ trên:

    • Khách hàng đặt hàng thì hệ thống phải lưu thông tin khách đúng không, vậy khách hàng là 1 đối tượng cần đưa vào ERD
    • Website, cũng là 1 danh từ, là nơi mà khách hàng mua hàng. Nhưng đọc requirement thì không thấy đề cập việc lưu lại thông tin này, vậy nên không cần đưa đối tượng này vào ERD. Giả sử shop này bán hàng trên nhiều website và thông tin đơn hàng cần lưu lại khách mua từ web nào thì lúc đó Website hoặc Nguồn bán sẽ được cân nhắc thể hiện vào ERD.
    • Đơn hàng, sản phẩm, nhân viên cũng là những đối tượng được yêu cầu lưu lại thông tin trong suốt quá trình mua hàng này.

    Khi xác định được đối tượng, bạn sẽ quan tâm đến

    • Tạo bảng: 1 bảng đại diện cho 1 đối tượng. Hãy tạo các bảng tương ứng với những đối tượng đã xác định
    • Khóa chính (primary key): là thuộc tính định danh của đối tượng. Định danh có nghĩa là không được trùng lặp và không được để trống. Giả sử đối tượng Đơn hàng có khóa chính mà Mã đơn hàng. Có nghĩa là dù shop này có 100 hay 1000 đơn hàng đi nữa, thì mỗi đơn hàng phải có 1 mã đơn khác nhau, không được trùng. Hay nói ngược lại, cho 1 mã thì chỉ tìm ra được 1 và chỉ 1 đơn có mã đó thôi. Tìm ra 2 đơn là tào lao liền. Mỗi bảng bắt buộc phải có 1 khóa chính (\*).
    • Thuộc tính: là những thông tin liên quan của một đối tượng. Đóng vai trò mô tả, làm rõ đối tượng, lưu trữ thông tin về đối tượng. Ví dụ đối tượng Khách hàng cần thuộc tính Tên, số điện thoại, địa chỉ… để mô tả về 1 khách hàng. Những thứ phức tạp hơn như Kiểu dữ liệu, Not Null, Unique thì chắc tạm thời mình không đề cập ở bài tổng quan này.
    • Đặt tên: mình không tìm hiểu một quy tắc chuẩn nào hết. Mình tự đặt theo quán tính thôi, nguyên tắc đặt tên của mình là

      • Bảng: Dùng dạng số nhiều, viết hoa ký tự đầu của mỗi từ, dùng dấu cách
      • Thuộc tính: viết lower-case, thay các dấu cách bằng dấu gạch dưới ( \_ )
      • Khóa chính: Tên đối tượng cộng với “id” (dạng số ít, viết theo cú pháp thuộc tính)

    (*) Trường hợp những bảng không dùng khóa chính mà dùng các cặp thuộc tính để định danh mình sẽ đề cập ở bài khác

    Mối quan hệ (Relationship)

    Xác định các mối quan hệ trực tiếp giữa các đối tượng trong quy trình hoặc tính năng.

    Cú pháp để xác định các mối quan hệ là:

    Một <đối tượng A> có thể sinh ra/thuộc về mấy <đối tượng B>
    và ngược lại Một <đối tượng B> có thể sinh ra/thuộc về mấy <đối tượng A>

    Đi vào ví dụ luôn nha:

    • Khách hàng và đơn hàng:

      • 1 khách có thể đặt nhiều đơn (cùng 1 khách, hôm nay mua 1 đơn, ngày mai có thể quay lại mua tiếp và tạo thành 1 đơn khác)
      • 1 đơn chỉ thuộc 1 khách (1 đơn hàng là do 1 ông khách tạo thôi, không có chuyện 2 – 3 ông cùng đặt 1 đơn hay là không có khách nào đặt mà đơn tự sinh ra được)
      • → Quan hệ 1 – nhiều
    • Đơn hàng và nhân viên

      • 1 nhân viên có thể xác nhận nhiều đơn hàng
      • 1 đơn hàng được xác nhận bởi chỉ 1 nhân viên
      • → Quan hệ 1 – nhiều
    • Đơn hàng và sản phẩm

      • 1 đơn hàng có thể gồm nhiều sản phẩm
      • 1 sản phẩm có thể nằm trong nhiều đơn hàng
      • → Quan hệ nhiều – nhiều

    Ta thấy ví dụ trên có 3 cặp quan hệ chính cần thể hiện lên ERD

    Mục tiêu bây giờ là xác định loại kết nối giữa các cặp đó.

    Để kết nối 2 bảng với nhau để tạo mối quan hệ thì ta đặt khóa chính của bảng này vào làm thuộc tính của bảng kia với vai trò là khóa ngoại.

    Ví dụ luôn. Giả sử để tạo mối quan hệ Khách hàng – Đơn hàng (1 – n) ta đặt khóa ngoại customer_id vào bảng Orders. Dễ dàng thấy ngay customer_id chính là khóa chính của bảng customer đúng không. Điều này mang ý nghĩa là, nhìn vào 1 order, ta biết được order này được đặt bởi ông customer có mã định danh là customer_id.

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa
    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Các kiểu quan hệ

    Về cơ bản thì mối quan hệ được biểu diễn ở dạng một đường thẳng nối giữa hai bảng và có ký hiệu “vết chân chim” ở hai đầu đường thẳng.

    Bạn sẽ cần hiểu các ký hiệu này để đọc và vẽ được ERD.

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Dạng nâng cao hơn là sự kết hợp giữa các ký hiệu này để thể hiện giá trị min-max. Khuyến khích dùng dạng này khi vẽ cho rõ nghĩa.

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Cách đọc ERD

    Xét mô hình tổng quát quan hệ giữa 1 cặp đối tượng như sau:

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Ta sẽ thấy có 2 chiều đọc theo hành động từ đối tượng A → B và ngược lại. Công thức đọc (phát biểu) tổng quát là:

    • Chiều A → B:


    1 + \[Đối tượng A\] + \[hành động 1\] + tối thiểu + \[số lượng min 1\] + và tối đa + \[số lượng max 1\] + \[Đối tượng B\]

    • Chiều B → A:


    1 + \[Đối tượng B\] + \[hành động 2\] + tối thiểu + \[số lượng min 2\] + và tối đa + \[số lượng max 2\] + \[Đối tượng A\]

    Ráp thử với ví dụ Customers – Orders nhé:

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Hành động 1 mình gọi là đặt: vì theo ngôn ngữ kinh doanh là khách hàng đặt đơn hàng

    Hành động 2 là thuộc về: 1 đơn hàng sẽ thuộc về (hoặc dùng được tạo ra bởi cũng được, nhưng mà nó dài)

    • Phát biểu 1:


    1 khách hàng đặt tối thiểu 0 và tối đa không giới hạn đơn hàng.

    • Phát biểu 2:


    1 đơn hàng thuộc về tối thiểu 1 và tối đa 1 khách hàng

    Đó là cấu trúc chuẩn, giờ bạn có thể diễn đạt lại với từ ngữ mượt mà uyển chuyển hơn


    1 khách hàng không bắt buộc phải đặt đơn hàng nào và được phép tạo nhiều đơn hàng khác nhau. (Việc tạo 1 khách hàng thì không quan tâm khách có đơn hàng hay chưa, 1 khách hàng tạo được nhiều đơn)


    1 đơn hàng bắt buộc phải thuộc ít nhất 1 và chỉ 1 khách hàng duy nhất. (tạo đơn hàng thì bắt buộc phải biết khách hàng sở hữu đơn đó là ai, và chỉ gắn với 1 khách thôi, không có khách thứ 2)

    Đó là chúng ta đang đọc từ 1 ERD có sẵn thành ngôn ngữ kinh doanh. Ngược lại, khi bạn xác định được yêu cầu của khách hàng rồi, bạn có thể dựa vào cú pháp này để vẽ ra được 1 ERD hoàn chỉnh.

    1 số ví dụ về việc đọc ERD

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Khái quát về ERD (Entity Relationship Diagram — hình minh họa

    Okay, tạm dừng bài viết dài dằng dặc này ở đây. Hy vọng bạn đã nắm được khái quát những gì ERD có thể làm và cách để tạo ra nó.

    ERD giúp tư duy hướng đối tượng, hiểu quan hệ và dữ liệu trong Database. Nó bao gồm Đối tượng và Mối quan hệ.

    ERD, hay Entity Relationship Diagram, là công cụ giúp mô phỏng mối quan hệ và dữ liệu trong cơ sở dữ liệu thông qua việc xác định các Đối tượng và Mối quan hệ giữa chúng. Việc đọc và vẽ ERD giúp người dùng phát triển kỹ năng tư duy hướng đối tượng, giúp họ dễ dàng hình dung các đối tượng quan hệ và dữ liệu được lưu trữ trong cơ sở dữ liệu như thế nào.

  • Câu hỏi “ngu nhất” khi làm Business Analyst

    Câu hỏi “ngu nhất” khi làm Business Analyst

    Đó 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.

  • Cách quản lý Change Request

    Cách quản lý Change Request

    Bạn đã define requirement một cách ngon lành, dự án đang chạy, team đang deliver đúng tiến độ. Bỗng nhiên, business requirement có sự thay đổi.

    Trong một thị trường chuyển động nhanh và cạnh tranh khốc liệt như hiện nay, việc kỳ vọng những yêu cầu business luôn cố định một chỗ và stakeholder luôn biết rõ họ cần phải làm gì là phi thực tế.

    Sự thay đổi luôn đến và mang theo rất nhiều rắc rối. Nếu chúng ta không quản lý tốt các thay đổi trong requirement, những sự thay đổi đó sẽ xoay cả team vòng vòng không hồi kết. Là một BA, sứ mệnh của bạn là không để cho sự thay đổi gây ra hỗn loạn, cứu team khỏi tình trạng phải “đập đi xây lại” mọi thứ, và ảnh hưởng đến năng lượng làm việc của mọi người.

    Hôm nay chúng ta sẽ nói về 4 bước quản lý thay đổi trong requirement:

    Cách quản lý Change Request — hình minh họa

    Bước 1: Xác định phạm vi thay đổi

    Đừng vội xác nhận hay hứa hẹn gì khi vừa nhận change request. Bạn cần thực hiện phân tích phạm vi ảnh hưởng của yêu cầu này. Đây là ảnh hưởng ở cấp độ nào:

    • Business requirement
    • User requirement
    • Functional requirement
    • Data requirement

    Tham khảo technical lead về đánh giá của bạn, họ có thể cho 1 vài ý kiến về những “side effect” có thể xảy ra khi triển khai change request này.

    Bên cạnh việc khoanh vùng ảnh hưởng, cần nắm rõ lý do thực sự cần thực hiện thay đổi này. Triển khai nó thì được gì, mà không làm thì mất gì. Liệu rằng có xứng đáng để đánh đổi thời gian và nguồn lực cho việc thay đổi này không.

    Hãy đối xử với change request như 1 requirement mới, việc đó giúp bạn đánh giá khách quan và hiệu quả hơn. Đừng bị “bias” bởi tư duy không muốn thay đổi, muốn giữ cái cũ.

    Bước 2: Xác định các bước thực hiện

    Bạn đã xác định được cái gì cần thay đổi và tại sao. Giờ thì hãy nhìn vào thực tế dự án, tiến độ, những output đang có, bối cảnh về con người và nguồn lực… Bắt đầu breakdown các bước cụ thể cần thực hiện (1 cách tổng quát) để đạt được sự thay đổi. Technical design sẽ cần làm gì, project roadmap sẽ thay đổi như thế nào, sprint schedule, plan,… Từ đó nhìn thấy được khái quát khối lượng công việc tăng thêm để triển khai thay đổi.

    Tham khảo ý kiến của dev team, PM và stakeholder để có thêm thông tin và bắt đầu đề xuất. Đưa ra 1 vài option để có sự cân nhắc đa dạng hơn. Bạn có thể đề xuất loại bỏ bớt những công việc có độ ưu tiên thấp hơn, hoặc thay đổi thứ tự thực hiện chúng trong product backlog.

    Bước 3: Thông qua nhu cầu thay đổi

    Sau bước 1 và 2, bạn đã có đủ thông tin và cũng đã đưa ra 1 vài đề xuất thực hiện thay đổi. Hãy tổng hợp chúng vào 1 form Change Request (google là có đủ template). Đặt những thông tin cần thiết vào form. Output từ 2 bước trên sẽ giúp bạn điền vào chỗ trống nhanh thôi.

    Bây giờ bạn sẽ cần thông qua các bên liên quan để bắt tay vào tiến hành thay đổi. Change request không phải lúc nào cũng cần thông qua 1 cấp nhất định. Hãy xác định mức độ ảnh hưởng của yêu cầu và từ đó xem xét mình sẽ cần sự đồng thuận của ai để triển khai

    • Nếu 1 yêu cầu đòi hỏi 1 ngày để thực hiện, bạn có thể đơn giản thông qua bằng cách làm việc với dev team
    • Nếu yêu cầu cần 1 tuần hoặc nhiều hơn, có thể bạn cần ý kiến và xác nhận của PM hoặc PO để thực hiện. Với phạm vi này, thay đổi có thể ảnh hưởng đến product roadmap
    • Nếu yêu cầu cần 1 tháng hoặc nhiều hơn, bạn sẽ cần chữ ký của cấp lãnh đạo để có thể bắt đầu tiến hành. Điều này có thể ảnh hưởng đến những dự án khác và có thể là chiến lược của công ty.

    Một số công ty có quy trình rõ ràng và chuyên nghiệp sẽ có quy định rõ về việc bộ phận nào hoặc ai sẽ có quyền approve những yêu cầu thay đổi nào.

    Bước 4: Thông báo và triển khai

    Khi đã được thông qua, bắt đầu đến với giai đoạn triển khai.

    Hãy đảm bảo và tất cả những bên liên quan đến thay đổi đều được thông báo và nhận thức được về thay đổi này. BA hoặc PM sẽ có trách nhiệm truyền thông về thay đổi.

    Thực hiện những thay đổi liên quan đến cập nhật tài liệu, quy trình và sản phẩm đầu ra có liên quan.

    Ví dụ: BA sẽ quan tâm đến việc điều chỉnh các tài liệu, requirement liên quan đến thay đổi. Designer sẽ quan tâm đến update version design mới, QA sẽ cập nhật test case và test plan, PM/PO sẽ điều chỉnh project plan và update product backlog…

    Lời kết

    Không ai muốn gặp quá nhiều thay đổi hay rắc rối trong quá trình làm dự án. Chúng ta muốn một dự án trơn tru từ đầu đến cuối. Nhưng đừng vì vậy mà ngại việc thay đổi, đôi khi có những cơ hội cần nắm bắt, miễn sao tạo được nhiều giá trị nhất cho khách hàng và dự án là được. Hãy chắc chắn rằng, thay đổi xứng đáng để đánh đổi thời gian và công sức của cả team.

    Bài viết giải thích 4 bước quản lý thay đổi yêu cầu trong dự án: Xác định phạm vi thay đổi, xác định các bước thực hiện, thông qua nhu cầu thay đổi, và triển khai.

    “4 Bước Quản Lý Thay Đổi Yêu Cầu Trong Dự Án Agile”

  • Làm gì khi dev nói: “Không làm được!”

    Làm gì khi dev nói: “Không làm được!”

    Outline

    • Dev sẽ nói câu này trong tình huống nào?
    • Tại sao họ nói vậy, gốc rễ vấn đề, có nguyên nhân nào xuất phát từ BA hay không.
    • Có hiểu lầm nào có thể xảy ra không
    • Có thể giải quyết không? Giải quyết như thế nào?
    • Mindset để tiếp cận việc này là gì
    • Có thường xảy ra không, BA có cần deal với nó không.
    • Làm sao để việc này không lặp lại thường xuyên trong tương lai.

    Viết

    Là BA việc của bạn là thu thập requirement của khách hàng 1 cách chính xác, đầy đủ nhất. Sau đó đề xuất những giải pháp phù hợp với requirement đó.

    Sau chuỗi ngày dài dằng dặc lấy requirement. Bạn đã define được 1 giải pháp đơn giản, hiệu quả, hoàn hảo cho những vấn đề của business.

    Và khi bạn chuẩn bị present nó với technical team để bắt đầu triển khai thì một câu nói sét đánh ngang tai xuất hiện: “Cái này không làm được đâu em!” hoặc “muốn làm cái này chắc phải cả tháng” trong khi ngân sách chỉ gói gọn trong 1 tuần.

    Vậy BA sẽ làm gì trong tình huống này. Bạn có thể mặc kệ? Kiểm soát thời hạn không phải thẩm quyền và trách nhiệm của bạn, nếu không đồng thuận được với dev về hướng xử lý, bạn có thể đá trái banh qua cho PM. Miễn là requirement đã đúng và đủ.

    Nhưng không! Bản năng bao đồng của BA không cho phép bạn làm điều đó. Bạn sẽ muốn nhúng tay vào để giải quyết vấn đề này.

    Vì 1 BA giỏi không đơn giản chỉ là người define requirement giỏi, mà là người tạo ra sự thay đổi và giải quyết vấn đề.

    Đầu tiên, hãy hít thở. Lấy 1 hơi thật sâu và thư giãn. Những tình huống như vầy có thể nhanh chóng dẫn tới căng thẳng, tim đập nhanh và đổ mồ hôi hột. Đừng mắc sai lầm này. Cứ giữ bình tĩnh và nghĩ xem, bạn muốn giải quyết những vấn đề business đã được define đúng không.

    Nguyên nhân gốc rễ là gì?

    Đây là việc thường xảy ra và BA sẽ phải deal với điều đó. Giờ nghĩ xem, tại sao team phát triển rất dễ dàng để phủ định hoặc kháng cự với đề xuất của BA.

    Có thể đề xuất của bạn đủ tốt và đủ rõ ràng để có thể thực hiện. Nhưng vấn đề là bạn đã không lấy ý kiến của dev team ở những giai đoạn đầu dự án. Bạn cần lôi dev team vào làm giải pháp càng sớm càng tốt.

    Đôi lúc BA quá hào hứng với ý tưởng và giải pháp của mình và cố gắng dọn sẵn mọi thứ trên bàn. Khi đó tính thử thách của vấn đề hầu như biến mất, không còn sự thú vị khi giải quyết 1 bài toán khó nữa. Nếu bạn là họ, có thể bạn cũng cảm thấy muốn kháng cự.

    Lập trình viên là những người làm việc độc lập và có tinh thần vượt khó. Hãy đưa bài toán cho họ và đề xuất ý tưởng của bạn.

    Làm sao để xử lý

    Okay, bạn đã hình dung được lý do tại sao gặp phải sự chống đối từ dev team, giờ hãy nghĩ cách giải quyết. Chỉ có 2 hướng thôi:

    • Thuyết phục team phát triển chấp nhận giải pháp của bạn
    • Thay đổi thành 1 giải pháp mới

    Đầu tiên, hãy cho họ biết là bạn cũng muốn nghe những ý kiến của họ về đề xuất đang có sẵn. Khuyến khích họ đặt ra những câu hỏi phản biện. Hãy chắc chắn rằng bạn trả lời được những câu hỏi đó và giải quyết được những khúc mắc chưa rõ. Từ từ làm rõ ra là đề xuất của bạn là khả thi và hợp lý ở nhiều khía cạnh.

    Lắng nghe những góp ý với 1 thái độ open. Tôn trọng và tin tưởng kinh nghiệm của dev team là chắc chắn sẽ có 1 giải pháp còn tốt hơn nữa. Ghi nhận góp ý của team và bổ sung vào đề xuất ban đầu của bạn.

    Nếu team vẫn khăng khăng về quan điểm reject toàn bộ đề xuất ban đầu. Okay bạn sẽ cần gác nó qua 1 bên để tìm kiếm những giải pháp khác. Team có thể brainstorm để tìm ra 1 vài giải pháp khả quan. Sau đó chọn ra 3-4 idea để đào sâu hơn.

    Hãy nhớ lắng nghe với thái độ cởi mở và khách quan. Chỉ lên tiếng nếu cảm thấy 1 idea nào đó không thể đáp ứng được nhu cầu kinh doanh hoặc vượt khỏi scope of work.

    Và điều thú vị là, nếu bạn làm giải pháp ban đầu một cách cẩn thận, thì sau buổi brainstorm, những đề xuất mới cũng sẽ không đi quá xa đề xuất ban đầu của bạn. Nhưng đừng đắc ý chỉ ra điều đó.

    Là 1 BA, việc bạn biết cách để giải quyết vấn đề không quan trọng. Làm cho dev team của bạn cảm thấy tự tin để xử lý vấn đề đó trong khung thời gian và ngân sách mới là quan trọng.

    Bạn không thể chỉ đơn giản bắt họ code giải pháp của bạn. Hãy trao đổi, dẫn dắt và biến giải pháp của bạn thành của họ.

    Để tránh lặp lại sự khó xử này, hãy chắc chắn rằng bạn luôn kéo team dev vào ở những giai đoạn đầu và solution đã có sự nhúng tay vào của tech lead hoặc 1 ai đó trong dev team. Như vậy sẽ dễ dàng đạt được sự đồng thuận.

  • Product backlog – mấy điều cơ bản

    Product backlog – mấy điều cơ bản

    Có lẽ ai làm công nghệ theo mô hình agile cũng sẽ quen với khái niệm product backlog. Nếu lên mạng để search từ khóa product backlog là gì, chắc chắn sẽ có rất nhiều bài viết về nó. Nên ở bài viết này, mình sẽ không nói lại quá nhiều những thứ chuyên ngành, đặc điểm hay lý thuyết về nó nữa. Mình sẽ chia sẻ những góc nhìn của bản thân về product backlog, và bạn hãy xem như đó là một góc nhìn tham khảo thêm từ 1 BA.

    Sơ lược về product backlog

    Team mình thường sử dụng Jira để quản lý product backlog và sprint backlog. Product backlog có vai trò là 1 todo list cho toàn team phát triển. Nó giống như 1 cái “hồ chứa task” thập cẩm đủ loại cho tất cả các member trong team.

    Với vai trò BA và kiêm luôn PO của sản phẩm, mình sẽ là người chịu trách nhiệm chính đưa các Product backlog items (PBI) lên jira. Việc này được thực hiện khi các yêu cầu đã rõ ràng, các tài liệu BRD đã được thông qua. Team cần một kế hoạch hành động cụ thể để có thể hiện thực hóa các tính năng.

    Trong suốt quá trình thực hiện dự án, product backlog sẽ liên tục được sàng lọc, bổ sung, điều chỉnh.

    1 product backlog ra đời như thế nào

    Quá trình tiến hóa của 1 product backlog có thể hình dung như sau:

    • Giai đoạn 1 – Khai sinh backlog: đặt vào backlog những Epic lớn và những user story “must have” cho mỗi epic. Việc breakdown này dựa trên tài liệu BRD, làm thành khung sườn của sản phẩm. Cần sắp xếp 1 cách tương đối về thứ tự thực hiện của các Epic lớn để có cái nhìn toàn cảnh về roadmap.
    • Giai đoạn 2 – Sprint backlog: đầu mỗi sprint, các PBI sẽ được kéo thả hợp lý vào sprint sao cho phù hợp với ưu tiên và tiến độ dự án. Động tác này có thể bao gồm luôn việc estimate thời lượng xử lý PBI đó nếu trước đó team chưa thực hiện.
    • Giai đoạn 4 – Backlog escalation: đây là giai đoạn mà các PBI xuất hiện ngày càng nhiều hơn. Các PBI giờ đây không chỉ gồm requirement (đại diện bởi user story) nữa. Xuất hiện các PBI khó chịu như bug (được QA tạo), improvement. Những requirement mới cũng được cân nhắc để bổ sung.
    • Giai đoạn 3 – Backlog refinement: role PO hoặc BA tùy dự án sẽ đảm bảo việc thực hiện sắp xếp thứ tự ưu tiên cho các PBI trong backlog, loại bỏ các PBI lỗi thời, breakdown hoặc group các PBI sao cho việc thực thi backlog hiệu quả nhất.

    Lưu ý khi làm việc với product backlog

    Khi làm Product backlog, có 1 số điều cần lưu ý:

    • Các PBI phải được mô tả chi tiết, definition of done rõ ràng, đủ để team phát triển có thể thực thi. Có thể đính kèm các tài liệu từ Confluence hoặc 1 tool quản lý wiki nào đó chứ không nhất thiết viết dài ngoằng vào description issue trên Jira.
    • Các PBI phải được estimate thời gian: 1 số PBI cần sự tham gia của nhiều member, cần xác định thời gian tối đa để hoàn thành PBI đó.
    • Các PBI phải được sắp xếp ưu tiên: Chú trọng việc đánh giá và sắp xếp mức độ ưu tiên giữa hàng đống PBI trong product backlog, tránh việc không biết phải làm gì tiếp theo.
    • Workflow giữa các thành viên trong team liên quan tới backlog phải được quy ước rõ. Các thành viên phải tuân thủ việc chuyển trạng thái task, comment những vấn đề còn chưa rõ hoặc thực hiện việc breakdown sub-task khi cần thiết.
    • Mỗi PBI có thể dính tới nhiều bên liên quan, cần xác định rõ ai là người chịu trách nhiệm, ai là người support. Đảm bảo không bỏ con giữa chợ.
    • Việc brainstorm và refinement các PBI nên có sự có mặt của cả team và nên thực hiện định kỳ. Giữ cho Product backlog ở trạng thái được cập nhật mới nhất.

    Một số mẹo khi làm việc với product backlog, dù bạn là BA, PO, Dev hay QA… hãy giữ những thói quen này:

    • Khi đã xác định được 1 yêu cầu hay 1 việc cần phải làm, hãy nhanh chóng đặt nó vào product backlog để tránh quên. Nếu siêng nữa thì ngay lập tức estimate thời gian, ưu tiên thực hiện. Hoặc nếu bận, hãy lưu nó ở đâu đó và cuối ngày, đặt nó vào product backlog.
    • Vào đầu mỗi ngày, hãy review lại backlog của bản thân và của dự án, đánh giá xem những gì đang làm hiện tại có phù hợp với tiến độ hoặc cần điều chỉnh gì hay không. Có việc nào gấp cần đẩy lên làm trước hay không.
    • Luôn cập nhật trạng thái task, dùng product backlog như 1 công cụ quản lý hiệu suất cá nhân (ở mức độ subtask).

    Okay, đó là một số chia sẻ của mình về product backlog, hy vọng giúp các bạn có một góc nhìn về cách sử dụng Product backlog.

    Bài viết chia sẻ về quản lý Product Backlog trong Agile. Đề cập đến vai trò và quy trình tạo và cập nhật backlog, cùng những lưu ý và mẹo khi làm việc với nó.

  • 7 câu hỏi giúp lấy thêm thông tin từ stakeholder

    7 câu hỏi giúp lấy thêm thông tin từ stakeholder

    Là 1 BA, việc đặt ra những câu hỏi để có thật nhiều thông tin càng tốt và càng sớm càng tốt là 1 kỹ năng thiết yếu.

    Nhưng đôi khi trong các cuộc thảo luận, chúng ta cảm thấy mình phải hỏi 1 câu gì đó, nhưng chẳng có 1 câu hỏi nào xuất hiện ra để hỏi cả. Và buổi trao đổi đó có thể khép lại với 1 cảm giác “thiếu thiếu gì đó”, nhưng không chắc đó là gì.

    Trong bài viết này, mình sẽ giới thiệu 1 bộ câu hỏi sẵn sàng sử dụng khi không có 1 câu hỏi cụ thể nào để hỏi.

    Khi mới nhận task BA

    Đã làm gì để giải quyết vấn đề này chưa?

    Đôi khi 1 BA tham gia dự án ở giai đoạn giữa, khi mọi thứ đã chạy 1 thời gian. Nghĩa là BA cần xác định những gì đã được làm trước đó, có hiệu quả không, cái gì không nên làm. Điều này tránh việc lặp lại những gì việc đã làm. Thậm chí khi tham gia 1 dự án mới hoàn toàn, BA cũng nên khai thác việc stakeholder nghĩ như thế nào về vấn đề và 1 vài ý tưởng của họ về việc định hình nó.

    Anh/chị cần output gì nhất từ em?

    Sẽ có rất nhiều kỳ vọng từ stakeholder gán lên người BA. Hãy làm rõ nó trong các buổi họp và thảo luận. Chỉ ra cụ thể BA cần tạo ra cái gì, mô hình nào, sơ đồ gì cần vẽ…

    Đôi khi cái stakeholder nghĩ rằng họ cần chưa đã là thứ họ thật sự cần. Vậy nên câu hỏi này có thể giúp BA hiểu kỳ vọng của stakeholder để có thể yên tâm thực hiện hoặc đề xuất những output mà bạn nghĩ là hợp lý hơn với tư cách là 1 BA.

    Khi bắt đầu lấy requirement chi tiết

    Anh/chị cho em một ví dụ về cái vừa nói được không?

    Khi bạn cảm thấy có khá nhiều logic, business rule đan xen và bạn không nắm được bức tranh toàn cảnh. Hãy đặt câu hỏi này, 1 ví dụ có thể chỉ ra 1 cách trực quan và dẫn đến nhiều tình huống hơn. Hãy đảm bảo việc yêu cầu ví dụ được thực hiện thường xuyên để bạn cover được hết các tình huống.

    Chúng ta đang cố gắng giải quyết vấn đề gì?

    2 trong những nguyên nhân gây mâu thuẫn nhiều nhất trong dự án là sự khác biệt về mục tiêu business và sự hiểu lầm về các thuật ngữ.

    Đối với vấn đề khác biệt về mục tiêu, hãy ngăn chặn nó bằng cách truy ra gốc rễ vấn đề cần giải quyết. Có thể các stakeholder khác nhau đang hướng đến những vấn đề khác nhau, và nếu không sớm làm rõ các mục tiêu chung thì dự án có thể bị kéo lệch hướng rất nhanh.

    Hãy đặt câu hỏi này 1 cách khéo léo và có thể phải hỏi nhiều lần, mỗi lần bóc ra 1 lớp vỏ để thấy được bản chất vấn đề bên trong.

    Điều này có nghĩa là gì?

    Để giải quyết vấn đề dễ gây xung đột thứ 2, đó chính là không thống nhất các thuật ngữ. Nếu tiếp xúc 1 khái niệm lạ, 1 biến thể mới nghe có vẻ giống cái bạn đã biết nhưng bạn không chắc, hãy hỏi lại định nghĩa 1 lần nữa để làm rõ. Thỉnh thoảng sau khi đặt câu hỏi này, bạn sẽ thấy các stakeholder của mình bắt đầu đưa ra những định nghĩa khác nhau của họ. Vậy đây là lúc hoàn hảo để setup lại các khái niệm, tránh “hậu họa” về sau.

    Hãy đặt những câu hỏi về từ viết tắt, thuật ngữ khó hiểu và cụm từ dành riêng cho tổ chức hoặc cho ngành nghề. Kể cả những từ ngữ nghe có vẻ dễ hiểu và chung chung như: người dùng, khách hàng, đơn hàng… có thể mỗi stakeholder đang giả định những từ đó 1 cách khác nhau về ý nghĩa của nó.

    Chốt lại cuộc thảo luận

    Còn vấn đề nào chưa được thảo luận hay không?

    Chúng ta thường hỏi stakeholder có câu hỏi nào cần hỏi nữa không vào cuối buổi thảo luận. Câu hỏi như vầy thường không hiệu quả, thay vào đó, hãy hỏi họ xem còn vấn đề nào bị bỏ sót không. Và có thể stakeholder sẽ dễ dàng điền vào những khoảng trống trong cuộc thảo luận.

    Còn vấn đề nào cản trở việc bắt đầu tiến hành không?

    Đây là 1 câu hỏi có tính chất yêu cầu sự cam kết thực hiện của các stakeholder về những vấn đề đã thảo luận. Dùng ở cuối buổi thảo luận để chốt lại outcome và sẽ dễ dàng đạt được sự đồng thuận về sau ở các bước ký nhận thông qua.

    7 câu hỏi giúp BA lấy thông tin từ stakeholder: Đã thử giải quyết vấn đề? Mong đợi gì từ BA? Cung cấp ví dụ? Vấn đề cần giải quyết? Định nghĩa thuật ngữ? Vấn đề bỏ sót? Cản trở nào?

    7 câu hỏi cho BA: Làm gì để giải quyết? Mong đợi gì từ BA? Cung cấp ví dụ? Vấn đề cần giải quyết? Định nghĩa thuật ngữ? Vấn đề bỏ sót? Cản trở nào?

  • “Cầm tay chỉ vẽ” BPMN

    “Cầm tay chỉ vẽ” BPMN

    Trong bài nói về các loại diagram nên dùng trong tài liệu BRD, mình đã dùng 1 ví dụ sơ đồ BPM dưới đây.

    “Cầm tay chỉ vẽ” BPMN — hình minh họa

    Hôm nay chúng ta hãy đi sâu vào và phân tích từng bước để ra được sơ đồ nhé. Let’s go!

    1. Lấy requirement

    Bằng mọi thủ đoạn, hãy lấy được requirement càng chi tiết càng tốt về quy trình cần phân tích. Ví dụ quy trình bán hàng as-is (khi chưa có website) được client mô tả như sau:

    Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàng vô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.

    Đọc xong quy trình này, bạn sẽ bắt đầu ngợp bởi khá nhiều thông tin. Đặc biệt nếu không phải người trong ngành nghề/lĩnh vực đó.

    2. Phân tích requirement

    Phân tích hiểu đơn giản chính là chọn lọc → phân loại thông tin.

    2.1 Chọn lọc

    Hãy scan qua requirement 1 lần nữa, nhưng lần này highlight từ khóa lên, bỏ qua những từ gây nhiễu. Chú ý đến loại từ khóa sau:

    • 1 đối tượng (actor)- màu vàng
    • 1 hành động (action) – màu đỏ
    • 1 thực thể (object)- màu xanh dương
    • 1 điều kiện (logic)- màu xanh lá

    Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàngvô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.

    2.2 Phân loại

    Tổng hợp các từ khóa theo từng nhóm, 1 số từ dùng đồng nghĩa cũng cần lưu ý gom lại:

    Loại Từ khóa Chú giải
    Đối tượng (actor) \* Khách hàng
    \* Nhân viên tư vấn
    \* Hệ thống quản lý kho
    \* Nhân viên kho
    \* Đơn vị vận chuyển     		Là 1 người hoặc hệ thống đang thực hiện ít nhất 1 hành động nào đó trong quy trình trên.
    Hành động (action) \* Liên hệ cửa hàng
    \* Trả lời khách hàng
    \* Check hàng tồn
    \* Yêu cầu thanh toán
    \* Thanh toán
    \* Tạo đơn hàng
    \* Nhận thông báo đơn hàng mới
    \* Xuất kho
    \* In bill
    \* Giao hàng cho nhà vận chuyển
    \* Giao hàng cho khách
    \* Thanh toán COD
    \* Trả hàng về kho
    \* Nhập kho hàng trả     		Hành động được thực hiện bởi 1 actor trong quy trình, cho ra 1 output cụ thể.
    Thực thể (object) \* Fanpage FB
    \* Sản phẩm
    \* Size
    \* Giá
    \* Kho
    \* Đơn hàng
    \* Bill     		Thực thể mang thông tin mô tả dữ liệu đầu vào hoặc đầu ra của 1 action bất kỳ trong quy trình.
    Điều kiện (logic) \* Sản phẩm cần tìm còn hàng hay không?
    \* Khách hàng lựa chọn cách thanh toán nào?
    \* Khách hàng thanh toán đủ hay không?
    \* Khách có nhận hàng hay không?     		1 điều kiện có thể chia quy trình thành các nhánh nhỏ hơn. Điều kiện phải thỏa thì các action phía sau mới thực hiện tiếp.

    3. Tạo pool và lane

    Giai đoạn phân tích đã xong, giờ bắt đầu vẽ thôi:

    Dựa trên việc phân tích, chúng ta đã biết có bao nhiêu actor tham gia quy trình. Bây giờ tiến hành tạo pool và lane cho từng actor.

    Ở ví dụ này Tư vấn viên và Nhân viên kho đều thuộc Shop nên mình gom lại thành 2 lane của 1 pool. Các đối tượng khác tương đối độc lập nên mình tách thành mỗi đối tượng 1 Pool.

    Việc gom pool và lane phụ thuộc vào tình huống cụ thể. Khi vẽ nhiều các bạn sẽ rút ra được “best practice” cho mình.

    Có thể tô màu để dễ phân biệt giữa các pool.

    Riêng Pool Hệ thống quản lý kho mình sẽ coi nó như 1 cái “hộp đen” và sử dụng Pool rỗng. Nghĩa là không quan tâm action của nó, chỉ quan tâm input và output khi đi qua nó thôi.

    “Cầm tay chỉ vẽ” BPMN — hình minh họa

    4. Xác định Start – End của từng lane

    Hãy đặt câu hỏi Điểm bắt đầu và điểm kết thúc của từng vai trò trong quy trình này là gì?

    • Khách hàng: Nhu cầu muốn mua hàng → Nhận được hàng thành công
    • Tư vấn viên: Khách hàng inbox (Bắt đầu quy trình tư vấn) → Tư vấn xong
    • Nhân viên kho: Hệ thống báo có đơn hàng mới (Bắt đầu quy trình xuất hàng) → Hoàn thành xuất hàng cho bên vận chuyển
    • Đơn vị vận chuyển: Nhân viên kho bàn giao hàng (Bắt đầu quy trình giao hàng) → Hoàn thành giao cho khách

    Pool Hệ thống quản lý kho không cần phân tích bước này vì là Pool rỗng.

    Sau khi phân tích xong, hãy đặt các Start event và End event vào đầu và cuối từng pool tương ứng.

    “Cầm tay chỉ vẽ” BPMN — hình minh họa

    5. Tạo task

    Từ bảng phân loại, bắt đầu tạo các task theo thứ tự từ trên xuống dưới và đặt vào pool tương ứng

    Ở bước này không chỉ đơn giản là tất cả các action phân tích ở trên được đều được đặt vào đây. Hãy nhớ những quy tắc cần thiết để giữ cho sơ đồ tinh gọn và có tính tổng quát.

    Gom các action liên quan thành 1 sub-process.

    Mỗi lane giới hạn khoảng 3 – 4 task / sub-process.

    Tập trung vào happy flow (main flow), các case ngoại lệ hạn chế thể hiện lên sơ đồ.

    Sắp xếp các task theo thứ tự diễn ra (xét trên từng lane)

    Sử dụng Động từ + Danh từ để đặt tên cho task.

    “Cầm tay chỉ vẽ” BPMN — hình minh họa

    6. Vẽ luồng đi và logic

    Dựa vào trình tự action từ bảng phân loại, vẽ sequence flow (liên kết cùng pool) hoặc message flow (liên kết khác pool) để kết nối các task và event.

    Hãy tư duy như vầy, khi vẽ flow cho task:

    • Task đó cần input gì để thực hiện được: sau khi xác định được, hãy nhìn xem task/event đứng trước nó có trả ra đủ thông tin mà task đó cần hay không.
    • Nếu cảm thấy thiếu input cho 1 task, có nghĩa là bạn đã xác định thiếu action trong bước phân tích. Hãy bổ sung thêm task hoặc event để không lủng logic.

    Chọn cổng phù hợp để thể hiện logic diễn ra. Mình rất ít khi sử dụng cổng AND và cổng OR, cục nào mà nhiều task AND hoặc OR thì mình gom thành sub-process hết cho gọn. Chủ yếu dùng cổng XOR để biểu thị các case dị biệt.

    Ở ví dụ này mình chọn thể hiện 2 case dị biệt đó là : Khách hàng thanh toán không thành công và Khách hàng không đồng ý nhận hàng.

    Còn 1 case nữa là khách chọn hình thức thanh toán nào (COD hay chuyển khoản 100%) mình quyết định không đưa vào BPM mà sẽ mô tả bằng Business Rule để thể hiện chi tiết hơn. Nếu vẽ chi tiết ở sub-process Thực hiện thanh toán của khách hàng thì có thể mình sẽ phân nhánh cho case này.

    Bổ sung event cần thiết, điều chỉnh loại start-end cho phù hợp: ở ví dụ này, start event của khách hàng chính là trigger đầu tiên, các start event của những role khác đều cần input từ 1 action khác → Đổi lại sử dụng kiểu Message start event.

    “Cầm tay chỉ vẽ” BPMN — hình minh họa

    7. Sắp xếp gọn gàng

    Bạn đã hoàn thành 99% công việc, tiếp đến chính là sắp xếp gọn gàng, điều chỉnh các flow sao cho không bị chồng chéo như tơ nhện. Note thêm chi tiết cho các message flow nếu cần.

    Okay hoàn thành rồi. Giờ thì hãy tự tin đặt chiếc sơ đồ này vào tài liệu của bạn nhé.

    Hãy tập luyện nhiều hơn để thuần thục các bước. Đến 1 lúc nào đó, bạn có thể lướt rất nhanh qua các bước phân tích mà nhảy thẳng vào việc vẽ luôn.

    P/s: Mình có biến tấu cách vẽ 1 chút so với nguyên tắc của BPMN 2.0 để phù hợp với nhu cầu sử dụng và tinh gọn hơn cho sơ đồ BPM. Lược bớt 1 số rule rườm rà, chỉ cần đủ để người đọc hiểu là được. (Ví dụ có 1 số quy ước là liên kết task giữa các pool phải có throw task để gửi message và catch event để bắt message đó trước khi đi tiếp. Mình cảm thấy lược bỏ cũng không ảnh hưởng logic và người đọc vẫn hiểu được nên mình dẹp luôn cho gọn)

  • Các loại diagram “thần thánh” khi viết BRD (P3 – SM)

    Các loại diagram “thần thánh” khi viết BRD (P3 – SM)

    Bài trước chúng ta đã bàn về BPM và SCD. Và bây giờ là diagram cuối cùng trong chuỗi bài.

    Scope model – SM

    Nếu SCD và BPM là 2 loại sơ đồ ở “tầng cao”. Cho bạn 1 cái nhìn overview thì Scope model – hay Sơ đồ phạm vi sẽ giúp bạn bước 1 chân vào phân tích làm sao để đạt được các mục tiêu đó.

    BRD (Business Reaquirement Document) là loại tài liệu chứa những yêu cầu về kinh doanh – thế giới của vấn đề và nhu cầu

    FRS (Functional Requirement Specification) là vùng đất của giải pháp. Danh sách chi tiết những tính năng cần làm để đáp ứng nhu cầu đó

    Và để liên kết BRD và FRS, làm sao cho những giải pháp đưa ra phục vụ đúng với các nhu cầu kinh doanh. Đó chính là lúc cần tới Scope model.

    Nếu hỏi: “Làm sao để bán được nhiều hàng trên website?” Thì đó là 1 nhu cầu đúng không? Nhưng nó quá mơ hồ, có hàng trăm nghìn việc phải làm, nên làm và có thể làm. Tương tự những thứ không nên làm cũng nhiều vô kể.
    Scope model hay có thể gọi là Work Breakdown Structure – là cách giúp chia nhỏ những vấn đề khó nuốt thành những mảnh nhỏ hơn. Giúp chúng ta khoanh vùng, chọn ra những việc phải làm một cách nhanh chóng và hợp lý.

    Ví dụ: Scope model cho Website bán hàng

    Chọn ra 1 nhu cầu chủ đạo nhất, sau đó tiếp tục tách nhỏ theo từng lớp với công thức như trên. Bạn sẽ có được 1 Scope model sơ bộ như sau:

    Các loại diagram “thần thánh” khi viết BRD (P3 - SM) — hình minh họa

    Nhìn vào sơ đồ này sẽ cho thấy phạm vi những việc cần làm 1 cách bao quát nhất. Tất nhiên là không thể đầy đủ. Vì đầy đủ không phải là mục tiêu.

    Hãy sử dụng các mindset sau để breakdown:

    • Ở mỗi level của Scope, ưu tiên những nhu cầu / nhóm tính năng Must have. Đừng vội đặt những thứ Nice to have vào.
    • 3-levels: Ở mỗi cấp, hãy brainstorm tối đa 3 nhánh nhỏ hơn. Nếu bạn cảm thấy có quá nhiều thứ muốn bỏ vào và 3 nhánh không đủ. Vậy thì có thể cách tiếp cận của bạn chưa hợp lý. Hãy nhìn rộng ra nữa, làm sao cho chỉ cần tối đa 3 nhánh có thể cover hết những thứ Must have. Đừng đi quá sâu vào chi tiết, dừng lại ở nhóm tính năng cấp 3 là đủ.
    • Việc brainstorm các nhánh con sẽ dựa vào:
      • Sự am hiểu về domain
      • Requirement lấy được từ user
      • Sự hỗ trợ và đề xuất từ dev.
      • Sự sắc bén và kinh nghiệm của BA

    Hãy sử dụng sơ đồ này để chốt lại tài liệu BRD và khởi đầu cho việc viết Function list trong tài liệu FRS. Nó sẽ là 1 chỉ dẫn rất cần thiết để tham khảo trong quá trình làm solution sau này.

  • Các loại diagram “thần thánh” khi viết BRD (P2 – BPM)

    Các loại diagram “thần thánh” khi viết BRD (P2 – BPM)

    Business Process Model – BPM

    Phần trước chúng ta đã nói về SCD – một cái nhìn toàn cảnh. Hôm nay sẽ bàn về 1 loại tài liệu khác chứa đựng nhiều thông tin hơn. Đó là BPM – lược đồ quy trình nghiệp vụ

    Nếu SCD là 1 cái địa đồ thô sơ thì BPM sẽ ở tầm Google Map. BPM bắt đầu chỉ rõ các con đường kết nối với nhau như thế nào, ở ngã ba nên rẽ trái hay phải , chỗ nào bị sạt núi…

    BPM giúp gì?

    BPM giả lập trình tự và logic mà các đối tượng trao đổi dữ liệu để đạt được 1 kết quả cụ thể cuối cùng.

    Bạn sẽ dùng tới công cụ này khi phải đối mặt với:

    • 1 quy trình cụ thể: có 1 kết quả cuối cùng cụ thể cần đạt được
    • Có nhiều đối tượng liên quan đến quy trình
    • Có nhiều hành động được thực hiện để đạt kết quả cuối cùng
    • Có nhiều logic và tình huống có thể xảy ra.

    Không phải quy trình nào cũng đè ra vẽ BPM làm chi, chừng nào bạn cảm thấy sẽ rất khó hiểu nếu mô tả bằng chữ thì hãy cân nhắc.

    Cách vẽ BPM

    Để tránh sa đà vào chi tiết, bài viết này chỉ giới thiệu sơ lược và đưa ra ví dụ khái quát. Mình đã viết 1 bài hướng dẫn từng cụ thể, chi tiết từng bước để ra được 1 BPMN xài được.

    Ví dụ

    Quy trình bán hàng as-is (khi chưa có website) được client mô tả như sau:

    Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàng vô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.

    Một đoạn text dài, nhiều thông tin đan chéo nhau đúng không.

    Vì ghi theo văn nói, nên sẽ không theo 1 trình tự nhất định, nhiều khi nói cái này thì nhảy sang cái kia. Rồi lâu lâu lại lòi ra 1 “nhân vật” bất ngờ nào đó không báo trước. Đừng có viết vào document. Dev đọc được lại chửi cho.

    Bỏ ra tầm 30-45p để “chuyển hóa” nó thành 1 bức ảnh như thế này sẽ nâng tầm giá trị của 1 BA.

    Các loại diagram “thần thánh” khi viết BRD (P2 - BPM) — hình minh họa

    Giờ thì đã thấy rõ quy trình này gồm những ai cùng tham gia, thực hiện những hành động gì, theo trình tự nào.

    Nhìn vào sơ đồ này, dễ dàng thấy ngay được:

    • Các đối tượng tham gia vào quy trình
    • Điểm bắt đầu và kết thúc của từng nhóm đối tượng trong quy trình
    • Chọn ra 1 action bất kỳ trong bức tranh này cũng thấy có thể suy ngược ra được cần điều kiện gì để action này xảy ra (input), và sau khi nó xảy ra thì trả ra thông tin gì (output)

    So sánh 1 chút để thấy được sự ưu việt của sơ đồ quy trình

    • Lược bỏ tất cả từ ngữ dư thừa
    • Các hành động đều có PIC, input, output rõ ràng
    • Sắp xếp và phân loại rất rõ, đưa sơ đồ này cho 1 role bất kỳ trong quy trình, họ có thể thấy được ngay tất cả các action họ phải làm, trình tự và kết quả cần đạt được

    Lưu ý:

    • Đừng tham lam dồn tất cả thông tin vào 1 sơ đồ BPM. Hãy gói gọn trong 1 hoặc 1/2 trang giấy
    • Nếu 1 role nào đó có quá nhiều action cần thực hiện trong 1 quy trình, hãy cố gắng gom nhóm các action đó lại thành 1 quy trình riêng biệt (Sub-Process). Bạn có thể làm rõ các Sub-process đó trong 1 sơ đồ khác. Keep it simple stupid!
    • Lưu ý 1 chút về tính thẩm mỹ và các cách sắp xếp, không có đúng hoặc sai trong cái này. Nhưng mục đích của BPM là làm mọi thứ rõ ràng chứ không phải rối hơn. Đừng ẩu!
    • Mindset thần thánh 3-levels
      • Mỗi role, hãy cô đọng lại thành 3 hoặc 4 task / Subprocess chính họ cần làm.
      • Chọn ra 3 hoặc 4 logic cốt lõi.
      • Hạn chế thể hiện alternative và exception flow. Chỉ 1 flow vui vẻ đã có thể ngốn hết thời gian rồi. Hãy tách riêng chúng ra.

    Đón xem phần 3 trong chuỗi 3 bài tại đây.