nguyenhongduc

Danh mục: Triển khai

  • 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.

  • Làm BA timeline – requirement estimation

    Làm BA timeline – requirement estimation

    Khi bạn tham gia 1 dự án kể từ lúc nó bắt đầu. Có rất nhiều việc để làm với vai trò BA. Bạn nhận yêu cầu từ PM nhà bạn bảo rằng đây là ưu tiên số 1 bây giờ. Đọc qua 1 hồi file brief mà user gửi và…chẳng hiểu gì hết.

    Bạn đang setup việc gặp stakeholder để hỏi 1000 câu hỏi vì sao và chuẩn bị cho các bước tiếp theo. Bỗng nhiên PM ghé qua hỏi 2 câu rất chí mạng: “Em nghĩ tầm bao lâu thì xong phân tích? Khoảng 1 tuần không?”. Sếp neo luôn cái mốc này và cho rằng có vẻ như là đủ để hoàn thành việc phân tích trong thời gian này. Tự nhiên bạn sẽ cảm thấy nhức nhức cái đầu, tim đập loạn xạ, hơi thở bắt đầu gấp gáp hơn. Nhưng tạm thời để cái estimate đó sang 1 bên đã. Hãy hít một hơi thật sâu và … câu giờ.

    Cả bạn và PM đều biết rằng, đây là 1 dự án hoàn toàn mới, người dùng mới, hệ thống mới. Sẽ chẳng thể cam kết 1 con số hợp lý nào cả cho đến khi chúng ta hiểu rõ hơn về dự án. Ít nhât, bạn sẽ cần hiểu rõ phạm vi dự án và team kỳ vọng bạn phân tích và deliver ở mức độ chi tiết như thế nào. Đây là 1 lý do hợp lý để kéo thêm thời gian, mà từ đó bạn có cơ hội xử lý các bước tiếp theo.

    Hiểu rõ hơn về stakeholder

    Hãy chắc chắn rằng bạn biết rõ tất cả các stakeholder mà bạn cần phải “va chạm” trong dự án. Biết được cách mà họ làm việc với BA trong những dự án trước đó. Hỏi họ những câu hỏi cơ bản về dự án để hình dung được họ nắm sâu cỡ nào về phạm vi vấn đề cần giải quyết

    Hiểu rõ về business objective

    Sau khi xác định được Stakeholder, hãy tiếp cận người chịu trách nhiệm chính về mục tiêu kinh doanh.

    Stakeholder này muốn đạt được gì từ dự án này. Đây là tầng nhu cầu cao nhất mà BA cần phải đạt được để có cái nhìn tổng quan. Khách hàng muốn tăng doanh số lên 5%, tăng khách hàng tiềm năng lên 20%, tăng tỷ lệ chuyển đổi lên 30%… Hãy tìm hiểu xem, stakeholder nào sẽ cho bạn được những thông tin ở tầng business object này

    Sau khi thu thập những thông tin này từ những stakeholder khác nhau thì hãy xác nhận lại với PM 1 lần nữa để chắc chắn những bạn đang đi đúng hướng

    Thảo luận với Tech lead

    Thảo luận với tech lead của dự án, có thể là 1 buổi ăn trưa hoặc 1 chầu cafe để tạo lập quan hệ. Hãy hỏi thăm cách mà team dev làm việc cùng BA trong những dự án trước đó, thăm dò thử xem mức độ chi tiết, chuyên sâu về kỹ thuật của tài liệu mà họ cần ở mức nào. Từ đó hình dung được khối lượng output BA phải chuyển giao.

    Bạn có thể trao đổi về 1 số vấn đề cần phải làm với techlead. Họ có thể đưa ra 1 vài giải pháp khả dĩ, chỉ ra 1 số điểm bất khả thi hoặc nút cổ chai có thể làm kéo dài thời gian dự án.

    Đến thời điểm này, bạn vẫn chưa đủ để có thể đưa ra ước lượng hoàn chỉnh, nhưng đừng lo, bạn đang đưa dự án tiến về phía trước và đã rất gần rồi

    Thảo luận về giải pháp

    Sau tất cả những bước trên, bạn đã có trong tay 1 số giải pháp phù hợp. Hãy sắp xếp 1 cuộc họp với stakeholder chịu trách nhiệm chính của dự án, thảo luận về các điểm mạnh và hạn chế của từng giải pháp. Kết quả cuối cùng đó là stakeholder đưa ra lựa chọn cho giải pháp cuối cùng. Từ đây, bạn đã có đầy đủ những thứ cần thiết để lên 1 bản nháp cho tài liệu Phạm vi dự án.

    Bạn đã có cho mình các câu trả lời cho

    • Stakeholder của bạn là ai
    • Business objective (mục tiêu và vấn đề business cần giải quyết)
    • Team dev gợi ý giải pháp nào
    • Team dev cần các tài liệu nào để triển khai
    • Stakeholder lựa chọn giải pháp như thế nào.
    • Phạm vi dự án chốt ở mức nào.

    Khá là đầy đủ tài nguyên để bạn biết được tiếp theo cần làm gì và cần làm trong bao lâu. Hãy lựa chọn đầu việc, sắp xếp thứ tự ưu tiên, ước lượng thời gian và xếp chúng vào 1 bảng tính như ví dụ dưới đây để có được 1 BA timeline cơ bản.

    ID Deliverable name Estimate Effort Start date End date Status Who involved Assumptions

    Sau khi đưa ra được 1 BA timeline, những việc tiếp theo đã trở nên rất rõ ràng và cụ thể hơn. Bạn đã có cơ sở để làm việc với stakeholder, 1 con số được chống lưng bởi tất cả những research mà bạn có thể đã mất 3-4 ngày để thực hiện. Không còn 1 sự ước đoán mơ hồ, mông lung có thể khiến tim bạn nhảy ra khỏi lồng ngực khi có gì đó bất trắc xuất hiện nữa.