Những vấn đề “kinh điển” trong IT project khi làm sản phẩm từ con số 0 – bài học rút ra cho Business Analyst
Học từ những vấn đề dự án gặp phải để biết cách giải quyết vấn đề trong tương lai.
Dự án hiện tại mình đang làm là dự án xây dựng sản phẩm từ con số 0 thay vì triển khai một gói sản phẩm có sẵn hoặc thiết kế lại quy trình nội bộ. Những công việc Business Analyst (BA) trước đây của mình đều triển khai những sản phẩm đã hoàn thiện, nên chủ yếu tập trung phân tích các chức năng bổ sung hoặc điều chỉnh thay vì xây dựng sản phẩm từ đầu. Chính vì thế mình không hình dung hết được những vấn đề có thể gặp phải khi xây dựng một sản phẩm từ con số 0.
Sau 3 năm tham gia vào toàn bộ quá trình phát triển hệ thống, dưới đây là những vấn đề của dự án mình quan sát được và bài học mình rút ra dưới góc nhìn của một BA. Mình hy vọng bài viết sẽ giúp bạn chuẩn bị tốt hơn nếu muốn tham gia vào một dự án IT xây dựng sản phẩm từ đầu, từ đó có sự chuẩn bị thật tốt để làm công việc BA thật tốt.
Tầm nhìn và yêu cầu không rõ ràng
Vấn đề:
Nhớ lại khi bắt đầu, mình chủ yếu là tạo các test case (kịch bản kiểm thử) để kiểm tra xem chức năng đã đúng với yêu cầu ở trong user story chưa. Tuy nhiên chỉ sau một buổi họp với khách hàng những test case đã tạo đều không còn hiệu lực vì yêu cầu thay đổi. Ban đầu mình rất thắc mắc: “Yêu cầu đã viết rõ ràng rồi thì sao lại đổi?”. Mình hơi sốc vì công phân tích, thiết kế và thậm chí dev đã xây xong một phần chức năng… vậy mà bị loại bỏ..
Sau này mình mới hiểu: yêu cầu được viết từ 1–2 năm trước khi dự án bước vào giai đoạn thiết kế chi tiết và đến thời điểm hiện tại không còn phù hợp nữa thì việc thay đổi là điều tự nhiên. Hơn nữa, vì đây là dự án xây sản phẩm mới hoàn toàn, toàn bộ team kể cả BA đều chưa từng làm sản phẩm tương tự, nên ý tưởng mơ hồ, kỳ vọng sai lệch và ước tính thường thiếu thực tế. Đây thực sự là vấn đề nhức nhối vì việc lên kế hoạch có thể đổ bể vì không thể dự trù chính xác thời gian và phạm vi của dự án.
Bài học cho BA là gì?
Thay đổi là điều tất yếu, BA cần linh động và nắm rõ quy trình để ghi nhận mọi thay đổi trong dự án.
Luôn luôn đảm bảo trao đổi với Project Manager và Dev Lead để đảm bảo sự thay đổi là đúng và kịp thời.
Hơn nữa trước khi cân nhắc và ước tính thời gian cho user story cần đảm bảo dự trù thời gian cho độ phức tạp của hệ thống. Tạo trước prototype để đối chiếu với khách hàng nhằm giảm thiểu sự thay đổi sau này.
Luôn luôn có khả năng hiểu nhầm thông tin
Vấn đề:
Khi công việc của bạn là môi trường đa quốc gia và sử dụng tiếng Anh là ngôn ngữ chung thì không tránh khỏi những lần hiểu nhầm ý nhau. Cường độ công việc thường đòi hỏi cao và yêu cầu BA cần nắm bắt nhanh là một trong những điều rất quan trọng. Tuy nhiên, vì luôn phải theo một nhịp độ nhanh để kịp với kế hoạch của dự án đã đề ra sẽ dễ gây ra thông tin truyền đạt chưa chính xác.
Ở bước thu thập yêu cầu, nếu khách hàng chưa rõ họ thực sự muốn gì, BA sẽ gặp rất nhiều khó khăn ở phần thiết kế và phân tích. Một yêu cầu mơ hồ có thể dẫn đến một giải pháp hoàn toàn không giải quyết được vấn đề cốt lõi của doanh nghiệp mà còn làm phức tạp thêm quy trình hiện tại của doanh nghiệp.
Bài học cho BA là gì?
Ask then ask again. Phương châm của BA là mọi thứ đều phải cố gắng rõ như ban ngày để giảm thiểu tối đa nhất sự hiểu sai giữa các bên với nhau từ khách hàng với BA, rồi BA với Dev và Tester.
Luôn luôn xác nhận thông tin một cách kỹ càng giữa các bên để có sự thống nhất cao, đảm bảo tất cả mọi người đều hiểu đúng và giống nhau.
Phát sinh thêm chức năng trong quá trình phát triển hệ thống
Vấn đề:
Trong quá trình phát triển, việc khách hàng phát sinh thêm yêu cầu hoặc điều chỉnh lại yêu cầu là chuyện thường xuyên. Một thay đổi nhỏ có thể làm xáo trộn cả cấu trúc hệ thống, kéo theo việc sửa database, hoặc các quy trình liên quan. Khi những thay đổi nhỏ tích lũy, chúng trở thành một rủi ro lớn cho tiến độ và chất lượng sản phẩm. Với BA, việc thay đổi liên tục yêu cầu thực sự là một thách thức vì nếu không phân tích kỹ càng việc có những “lỗ hổng” chưa được cân nhắc khi đưa ra giải pháp mới có thể khiến lỗi hoặc hệ thống không xử lí được sau này.
Bài học cho BA là gì?
Cố gắng quản lí những nhiệm vụ tồn đọng chặt chẽ, nếu có bất cứ thay đổi phát sinh nào cũng cần qua quy trình yêu cầu thay đổi và được phê duyệt của những bên liên quan.
Cần phải tìm ra những chức năng chủ chốt và quan trọng cần được thiết kế và xây dựng trước để đảm bảo chức năng chính sẽ sẵn sàng cho khách hàng. Sau đó mới những chức năng ‘nice to have’ và chỉ phát triển chúng khi thời gian trong dự án cho phép.
Luôn luôn trao đổi rõ ràng với khách hàng về những hệ quả của việc thay đổi yêu cầu và những điều mà khách hàng cần cân nhắc (thêm budget, gia hạn thời gian)
Ước tính thời gian và chi phí chưa đủ
Vấn đề:
Trước khi bắt đầu quá trình tìm hiểu và ghi nhận yêu cầu chi tiết, dự án cần qua bước nộp Business Case (Đề án cho dự án) cho khách hàng và phân tích kỹ càng về các giải pháp có sẵn và giải pháp tối ưu mà dự án đề xuất, Business Case cũng bao gồm thời gian và ngân sách dự kiến cho dự án. Thường lúc này với những thông tin phân tích ban đầu quản lí dự án sẽ đề xuất giải pháp ở mức tổng quan và thời gian cần để xây dựng hệ thống. Tuy nhiên vấn đề là ở bước này, mọi thông tin chi tiết chưa được cân nhắc, nhiều rủi ro còn ẩn, và sản phẩm mới hoàn toàn chưa có bất kỳ chuẩn hóa ban đầu. Vì vậy ước tính thời gian thường thiếu thực tế, dẫn đến đội dự án phải kéo dài tiến độ và phát sinh chi phí.
Với một sản phẩm xây dựng từ con số 0, mọi thứ đều không có sự chuẩn hóa. Các chức năng đều đến từ các ý tưởng của sản phẩm trước khi phát hiện ra nhiều vấn đề khi sản phẩm dần hoàn thiện. Điều này dẫn đến việc thời gian của dự án phải kéo dài hơn, chi phí phát sinh thêm là điều không thể tránh khỏi.
Bài học cho BA là gì?
BA cần dành nhiều thời gian nghiên cứu domain, phân tích rủi ro và trao đổi với team kỹ thuật trước khi đưa ra ước tính.
Việc này thực sự khó vì có rất nhiều thông tin không được biết ở thời điểm lên Business Case. Với dự án xây từ đầu, nên cân nhắc dự phòng chi phí và thời gian cao hơn bình thường vì mức độ không chắc chắn rất lớn.
Bất cứ khi nào tiếp nhận yêu cầu thay đổi từ khách hàng mà BA cảm thấy thay đổi này có thể ảnh hưởng lớn đến tiến độ dự án cần đề xuất với quản lí dự án để có phương án xử lí kịp thời và phù hợp.
Thiếu vai trò quan trọng
Vấn đề:
Việc thiếu đi một số vai trò quan trọng trong dự án có thể kéo theo rất nhiều hệ lụy, và sản phẩm có thể sẽ phải làm lại vì sự không đồng nhất giữa các thành phần của hệ thống.
Thiếu UX/UI designer ngay từ đầu khiến thiết kế bị chắp vá, mỗi BA tự làm theo một kiểu, Dev hiểu theo nhiều cách khác nhau không có bất cứ một chuẩn mực nào cho hệ thống (từ format, màu sắc, các nút bấm, cỡ chữ). Kết quả là sản phẩm thiếu thống nhất và cần sửa đi sửa lại rất nhiều.
Thiếu team lead (BA lead, Test lead…) khiến không ai nắm tổng thể hệ thống, dẫn đến mỗi người làm mỗi hướng, không có ai định hướng hoặc review giải pháp từ góc nhìn tổng quan. Để sau này khi mỗi component của hệ thống ghép lại với nhau, hệ thống bị mâu thuẫn và không thể chạy được.
Bài học cho BA là gì?
Luôn cân nhắc xây dựng RACI trước khi dự án đi vào thực hiện. Ma trận RACI phân chia vai trò của mỗi nhân sự theo từng nhóm, là Hành động (R – Responsible), Phê duyệt (A –Accountable), Tư vấn (C – Consulted) và Thông tin (I – Informed).
Việc biết được ai chịu trách nhiệm hay phê duyệt sẽ giúp từng nhiệm vụ luôn được rà soát đảm bảo thông tin thống nhất. Đây là yếu tố giúp dự án vận hành trơn tru và thống nhất.
Luôn luôn cân nhắc nếu cần có các thành viên chủ chốt trong dự án để đảm bảo mọi thiết kế, chức năng đều dựa trên một standard nhất định và tăng sự đồng nhất.
Giải pháp quá phức tạp hoặc quá đơn giản
Vấn đề:
Đôi khi dự án rơi vào tình huống hoặc là “over-engineering” làm quá mức cần thiết, hoặc “under-engineering” giải pháp quá đơn giản không đủ đáp ứng nghiệp vụ. Giải pháp phức tạp khiến timeline bị kéo dài, dev mệt mà không hiệu quả vì người dùng cũng sẽ không sử dụng đến những chức năng cao siêu như vậy. Nhưng giải pháp quá đơn giản lại làm hệ thống bị thiếu chức năng quan trọng, khó mở rộng về sau. Cuối cùng thì cả team đều quay lại vòng lặp sửa – chỉnh – sửa vì giải pháp ban đầu không phù hợp.
BA và UXUI designer thường mong muốn thiết kế dễ cho người dùng tuy nhiên với Dev việc thiết kế nhiều chức năng có thể gây phức tạp và tốn thời gian khi xây dựng. Việc tìm được điểm cân bằng giữa giải pháp và nguồn lực là vô cùng quan trọng.
Bài học cho BA là gì?
BA cần tìm điểm cân bằng. Hãy giữ những gì thực sự mang lại giá trị cho người dùng và doanh nghiệp. Những gì quá phức tạp nên cân nhắc và tìm các hướng khác nhau để đàm phán với khách hàng nhằm tìm ra giải pháp tốt nhất.
Luôn tham khảo ý kiến khách hàng và Dev để điều chỉnh kịp thời, tránh sửa đi sửa lại.
Thiếu tài liệu
Vấn đề:
Một trong những hệ quả của việc phát triển nhanh các tính năng để cho kịp tiến độ đó là dự án không có tài liệu một cách rõ ràng. Việc BA không có đủ thời gian để phân tích yêu cầu dẫn đến user story thiếu chất lượng, không phân tích kỹ càng. Đội Dev cũng thay đổi thiết kế cơ sở dữ liệu mà không có thời gian để ghi chép đầy đủ những thay đổi đó. Khi bắt đầu có yêu cầu mới phát sinh sẽ rất khó để quay lại và tìm kiếm thông tin trước đó nếu yêu cầu trước đó nhiều năm.
Một hệ quả nữa là người mới tham gia vào dự án cũng dễ “bơi” trong hàng loạt user story bởi không có một nguồn thông tin đáng tin cậy về bất cứ chủ đề nào, việc thay đổi nhanh chóng trong yêu cầu cũng khiến các thông tin không được cập nhật đầy đủ.
Bài học cho BA là gì?
Ghi chép là yếu tố sống còn. BA cần duy trì một nguồn thông tin duy nhất (Single Source of Truth) trên Confluence hoặc tool tương tự.
Cập nhật thường xuyên và sử dụng ngôn ngữ nhất quán để mọi người dễ tra cứu.
Thảo luận với team để đảm bảo tất cả đều có trách nhiệm ghi chép thông tin và chia sẻ rộng rãi trong nội bộ.
Tích hợp kéo dài hoặc thất bại
Vấn đề:
Tích hợp (integration) luôn là phần “khó nhằn” nhất của dự án. Chỉ cần format dữ liệu không khớp, hoặc môi trường bên thứ ba chưa sẵn sàng… là cả timeline có thể bị kéo dài và không thể hoàn thành đúng như tiến độ đề ra. Chưa kể để có thể tích hợp được dữ liệu giữa các hệ thống với nhau cần rất nhiều nỗ lực trong việc mapping data. Việc này đảm bảo dữ liệu chuẩn khi chuyển giữa các hệ thống với nhau đúng và chính xác. Trong khi đó hệ thống mới chưa ổn định và Database chưa ổn định càng khiến việc tích hợp phức tạp hơn.
Mình từng tham gia kiểm tra chất lượng data (Quality of Data), và nhận ra thiết kế database không tối ưu gây trùng lặp dữ liệu, làm giảm hiệu suất hệ thống.
Bài học cho BA là gì?
Document rõ mọi thay đổi của Database và duy trì Data Dictionary để việc mapping và chuyển đổi dữ liệu trở nên dễ dàng hơn.
Với BA tham gia vào quá trình tích hợp cần dành thời gian nhiều hơn để hiểu về data và bản chất của chúng từ đó mới có thể tìm ra các quy tắc chuyển đổi đúng giữa các hệ thống với nhau.
Kì vọng sai lệch về mong muốn một sản phẩm hoàn hảo
Vấn đề:
Vì việc xây dựng một sản phẩm từ đầu và khách hàng đã có một kì vọng nhất định rằng sản phẩm sẽ giúp giải quyết hết tất cả các vấn đề của doanh nghiệp đang gặp phải. Đồng thời, hệ thống sẽ tối ưu toàn bộ quy trình của doanh nghiệp. Những điều đó hoàn toàn dễ hiểu, tuy nhiên có một vấn đề là khách hàng sẽ có xu hướng muốn rất nhiều hay các chức năng cực kỳ hiếm khi xảy ra (1% case). Vì vậy việc dự án cứ kéo dài mãi vì sự thay đổi yêu cầu liên tục của khách hàng để “đề phòng” và với tư duy “có vẫn tốt hơn”. Điều này gây nhiều khó khăn cho team dự án khi mà phải thích ứng với mọi thay đổi cả về quy trình và Database.
Bài học cho BA là gì?
BA cần xác nhận yêu cầu rõ ràng thông qua email, meeting có recording hoặc văn bản chi tiết.
Khi có thay đổi, cần phân tích mức độ ảnh hưởng và nguồn lực cần thiết để đảm bảo khách hàng hiểu tác động của yêu cầu đó.
Luôn trao đổi với khách hàng nắm rõ chức năng nào thực sự cần để tập trung trước, đồng thời phân tích những rủi ro nếu kì vọng một sản phẩm ‘hoàn hảo’ thì có thể dự án sẽ không thể kết thúc. Tìm được điểm cân bằng giữa kì vọng phù hợp và thực tế với sản phẩm mà dự án có thể làm ra.
Kết bài
Hành trình làm BA trong một dự án xây dựng sản phẩm từ đầu thực sự không dễ dàng. Nhưng chính những khó khăn đó đã giúp mình trưởng thành hơn, hiểu sâu hơn về hệ thống và cách một sản phẩm được sinh ra, mình nhận ra mỗi thách thức đều là một cơ hội để học thêm điều mới. Và một BA giỏi không chỉ hiểu nghiệp vụ mà còn phải kiên nhẫn, linh hoạt và luôn giữ tinh thần học hỏi. Nếu bạn đang bước vào một dự án xây dựng sản phẩm từ con số 0, mong rằng bài viết này sẽ là chiếc “bản đồ nhỏ” giúp bạn định hướng rõ ràng hơn.
Cám ơn bạn đã luôn ủng hộ và dõi theo các bài viết của mình trên blog. Mình vô cùng trân trọng và biết ơn bạn. Chúc bạn cuối tuần nhiều năng lượng và bình an.
Nếu bạn đang làm trong quá trình xây dựng sản phẩm từ số 0 thì chia sẻ cho mình biết có vấn đề nào bạn cũng gặp ở dự án của bạn nhé?
Mến thương,
Thơ Nguyễn