5 điều nghiệm thu được từ dự án đầu tay
5 điều nghiệm thu được từ dự án đầu tay
Hế lô anh em, hôm nay là sáng thứ bảy và mình cũng khá rảnh. Giờ mình sẽ ngồi chém gió đôi chút về dự án đầu tay của mình cho anh em cùng nghe rồi bình loạn nhé.
Bài này sẽ viết về những chiêm nghiệm của mình. Những điều mà mình hiểu và rút ra được từ dự án đầu tay. Mong những chia sẻ của mình sẽ giúp ích được cho anh em. Chí ít là không mắc phải những thứ củ chuối mà mình và team đã gặp… 
Như giới thiệu thì mình có nói là mình đang làm Business Analyst ở RBVH. Và mình làm triển khai về giải pháp Microsoft Dynamics 365.
Dự án đầu tay của mình là làm cho một doanh nghiệp sản xuất nhựa. Doanh nghiệp này muốn áp dụng CRM để quản lý khách hàng và quản lý các cơ hội kinh doanh của mình một cách tốt hơn.
Hồi đó làm dự án là mình nhớ là có nhiều cái để nói lắm. Mà sao giờ bay hết trơn. Thôi vô bài luôn :v Cái đầu tiên là:
Nội dung [Hide]
- 1. BA mà thiếu thông tin là… tèo ngay
- 2. Hạn chế coding trong dự án triển khai
- 2.1. Chuẩn rồi, sao phải coding thêm chi nữa ?!?
- 2.2 Không lường trước được… bug!
- 3. Mindset của người làm Business Analyst?
- 4. Đi training nói gì cho hấp dẫn?
- 5. Việc gì người ta lại sử dụng hệ thống của mình?
- 5.1. How can I help you?
- 5.2. Tản mạn về users
- 6. Kết
1. BA mà thiếu thông tin là… tèo ngay
Thiệt ra là mình không được tham gia dự án ngay từ đầu đâu. Lúc mình mới vào thì dự án đã chạy được phase 1 – lấy requirement rồi. Nhưng cũng chỉ mới requirement ở mức sơ khởi.
Hồi đó team mình làm từng function nhỏ rồi deliver cho khách hàng, nhận feedback và re-design lại cho khớp. Kiểu kiểu agile vậy đó. Chạy song song cả module Sales lẫn Marketing luôn. Lúc mình vào vì chưa có kinh nghiệm gì nhiều nên support anh em là chủ yếu.
Trong ngành thường hay nói “KT”. KT là Knowledge Transfer. Tức là truyền đạt lại kiến thức, tài liệu. Nói chung là toàn bộ thông tin của dự án cho người khác.
Vì cả mình và team không chú trọng đến đoạn này nhiều, nên mình khá mơ hồ về thông tin khách hàng. Cực kỳ mơ hồ luôn. Từ những cái tổng quan đến những requirement cơ bản nhất. Mình đã gặp rất nhiều khó khăn để bắt kịp tiến độ được với mọi người.
Điều nay thì vô cùng khó chịu. Trong các buổi họp bạn khó mà hiểu được team đang nói đến cái gì. Gặp khách hàng cũng không tự tin vì thông tin nắm không vững.
Thiệt ra thì vấn đề này không phải đến từ team hay PM, mà đến từ chính mình. Hồi đó gà gà còn bị động lắm. Ngáo ngáo chả biết hỏi ai hết. Mà nghĩ lại, sao hồi đó vẫn sống tốt. Cho đến lúc gặp khách hàng thì mới biết mình… chả làm gì được hết ráo!!!
Họp hành các kiểu mà thiếu thông tin là bị bay ra ngoài đảo hoang liền
Nguồn: Xào nấu lại dựa trên tranh của Lisa Benson
Làm BA mà nắm quá ít thông tin thì đương nhiên là chả làm được gì. Không nói chuyện được với người ta, không teamwork được với team. Mọi thứ lúc đó đối với mình mịt mờ lắm anh em.
Mà thiệt ra thì để lấy được thông tin, không nhất thiết phải đi hỏi, phải làm workshop. Hay cũng chả cần tổ chức một buổi offical KT gì cho hoành tráng cả. Đơn thuần chỉ cần đọc lại mấy tài liệu của team, có bao nhiêu đọc bấy nhiêu. Hoặc lên web khách hàng xem thông tin của họ.
Mình làm CRM mà, tìm hiểu về thị trường, các kênh bán hàng, các loại sản phẩm là quan trọng. Chỉ cần mình muốn thì sẽ có rất nhiều cách để nắm được thông tin.
Do đó, dù có làm gì thì cũng đừng để miss thông tin. Tìm mọi cách để update và hiểu vấn đề ngay có thể nhé anh em. BA cần thông tin để làm, cũng giống như con người mình cần Oxy để thở vậy.
BA thiếu thông tin chả khác nào cá thiếu nước
Nguồn: Chôm từ In-tờ-nét
2. Hạn chế coding trong dự án triển khai
Đây là điều mình sẽ luôn aware đầu tiên cho bất cứ dự án nào sau này. Làm dự án triển khai thì rất nên… né việc coding. Thay vào đó hãy cố gắng dùng các chức năng mặc định của hệ thống. Vì sao?
2.1. Chuẩn rồi, sao phải coding thêm chi nữa ?!?
Thứ nhất, bộ chức năng của hệ thống có sẵn đã quá chuẩn rồi. Bất kỳ hệ thống nào đi nữa thì đội ngũ phát triển họ đã nghiên cứu rất kỹ nhu cầu sử dụng của khách hàng. Rồi từ đó, họ mới develop thành các chức năng mặc định của hệ thống. Chứ chả có ông nào tự dưng bưng ba cái gì đâu bỏ vô hệ thống cho mình xài đâu.
Thiệt ra thì cũng chả bao giờ có chuyện hệ thống này chỉ áp dụng được với doanh nghiệp này. Còn đưa vô doanh nghiệp khác thì bó chiếu hết. Vụ này hiếm lắm.
Đối với các sản phẩm nổi tiếng như: Microsoft Dynamics, Salesforce, SAP hay Oracle. Các chức năng của họ đã quá chuẩn rồi. Anh em thử nghĩ đi, nếu mình làm một cái gì đó quá lệch với những cái chuẩn thì rõ ràng là không ổn rồi. Dù mình có thấy nó hợp lý thế nào đi nữa.
Đồng ý là sẽ có một vài sự chênh lệch giữa requirement và các chức năng mặc định của hệ thống. Nó có thể đến từ sự khác biệt giữa các quốc gia, khu vực. Như bên châu Mỹ thì có thể họ không cần contract khi ra hợp đồng .Mà họ xem luôn báo giá như là một giấy tờ chứng minh việc mua hàng. Hay quy trình kinh doanh của người ta có quá nhiều điểm đặc biệt. Nhưng chắc chắn, sẽ luôn có sự chênh lệch giữa requirement và các chức năng chuẩn của hệ thống.
Đây chính là lúc giá trị của một người làm Functional Consultant (BA) phát huy tốt nhất. Là BA, mình phải luôn biết được hệ thống mình làm được gì, team mình làm được gì. Đâu là giải pháp tốt nhất với khách hàng, đâu là giải pháp không nên làm.
Guide cho người ta đi theo những chức năng chuẩn của hệ thống là điều cần thiết. Bằng cách này hoặc cách khác, bằng góc nhìn này hoặc góc nhìn khác. Mình phải cố giải quyết bài toán của khách hàng bằng chức năng chuẩn của hệ thống, zị mới hết sảy con bà bảy!!!
Giá trị của Business Analyst (Functional Consultant)
Nguồn: Modern Analyst đã qua xào nấu chút xíu
Đối với một dự án triển khai, việc guide khách hàng đi theo những hệ thống chuẩn ngay từ đầu rất quan trọng. Nó hướng cho khách hàng biết được rằng, hệ thống chắc chắn sẽ giải quyết được những vấn đề nào của họ. Do đó, rất nên lấy những chức năng mặc định của hệ thống, để bắt đầu câu chuyện lấy requirement với khách hàng!
Thực tế thì ở dự án sau đó, mình mới rút kinh nghiệm được điều này. Mình làm về Microsoft Dynamics 365 for Sales, gọi tắt là D365.
Để có một cái nút mới (button) trong D365 thì phải coding thêm, chứ không configure được. Requirement ở đoạn này là: user 1 nhấn cái nút để yêu cầu duyệt báo giá. Sau khi nhấn nút, email sẽ tự động gửi tới Manager của người nhấn nút để yêu cầu duyệt. Manager sẽ nhấn nút “approve” hoặc “reject” để duyệt báo giá. Sau đó, cũng có 1 email gửi trả báo giá về cho user kèm thông báo. Thì lúc này mình sẽ có 3 cái nút đúng không nào:
- Nút Request Approval (dành cho user)
- Nút Approve (dành cho Manager)
- Nút Reject (dành cho Manager)
Nhưng khoan, thay vì làm cả 3 cái nút tốn nhiều effort như vậy, mình còn 1 vài cách nữa.
D365 hỗ trợ cho Functional Consultant (FC) configure được khá nhiều trên hệ thống. Thay vì nhấn 1 cái nút yêu cầu duyệt, user có thể chuyển 1 dữ liệu thành Yes để yêu cầu duyệt báo giá!!! FC chỉ cần tạo 1 dữ liệu tên là “Request Approval”, kiểu dữ liệu là option set (Yes/ No) và xem như nó là 1 cái cờ là ok.
User muốn yêu cầu duyệt thì bật cờ lên “Yes”, còn không thì để cờ ở “No”. Rồi configure thêm 1 cái workflow để nó lắng nghe dữ liệu Request Approval. Nếu Request Approval là “Yes” thì gửi email, còn “No” thì thôi. Còn phía Manager cũng tương tự với việc tạo một dữ liệu. Tên là “Approve” đi chẳng hạn và để mặc định là Null. Manager bật “Yes” thì là duyệt, “No” thì không. Và chắc chắn là còn nhiều cách nữa để hoàn thành requirement này mà không cần đến coding.
Microsoft Dynamics 365 hỗ trợ Functional Consultant configure rất nhiều trên hệ thống
Dĩ nhiên, BA sẽ phải chọn cách tốt nhất để deliver cho khách hàng. Nếu việc configure trên hệ thống không đáp ứng được requirement lẫn non-requirement, thì sẽ quay lại phương án coding.
D365 là một hệ thống mà nó hỗ trợ Functional Consultant thao tác configuration rất nhiều. Có thể những hệ thống khác không hỗ trợ nhiều như vậy. Nhưng dù gì đi chăng nữa, túm cái váy lại thì mindset hạn chế coding vẫn rất quan trọng trong những dự án triển khai.
2.2 Không lường trước được… bug!
Bug là hệ quả chắc chắn xảy ra khi coding quá nhiều. Bug thì dự án nào cũng có, nhiều hay ít mới quan trọng.
Mình gặp ngay vấn đề này ở dự án đầu tay. Lúc anh em đang làm trên môi trường dev, vì 1 số lý do về requirement mà team mình phải coding khá nhiều.
Xong xuôi hết, đưa lên môi trường Test, rồi Production. Mình kể nhanh vậy thôi, chứ việc đưa từ môi trường này sang môi trường khác team mình gặp cực kỳ nhiều vấn đề. Vì coding nhiều, mà lại không quản lý được sự thay đổi trên hệ thống. Code cái gì, sửa cái gì, configure cái gì, không keep track được. Nên việc đưa qua đưa lại giữa các môi trường nó không tương thích, nên gặp nhiều vấn đề lắm.
Fix tới fix lui thì cũng UAT được, rồi Go-live thành công. Đoạn tới 1 ngày đẹp trời, Microsoft tự động nâng cấp hệ thống, lên version mới. Bug bắt đầu xuất hiện. Mà trong đó khoảng gần 1 nửa bắt nguồn từ coding.
Team cũng dần dần fix được. Nhưng duy nhất có 1 lỗi không detect được và cũng không giải quyết được. Đành raise ticket nhờ support từ Microsoft. Khoảng 2 tuần sau thì Microsoft hỗ trợ thành công.
Mình cũng có nghe kể từ 1 anh, đến nỗi bug phát hiện ra gửi Microsoft nhờ support. Microsoft cũng bó chiếu luôn!!! Vì đơn giản là 1 hệ thống khủng như vậy, nội đến chuyện Microsoft họ tự quản lý các issue phát sinh trong quá trình sử dụng chức năng chuẩn còn khó. Nói gì đến việc giải quyết được bug do coding. Đây là sự thật 100%. Do đó, nếu không cần thiết thì hẳn khoan coding!
Thiệt ra thì bug cũng chỉ là 1 chức năng bonus thêm cho anh em thôi :3
3. Mindset của người làm Business Analyst?
Anh em cũng biết, BA thì có nhiều lĩnh vực, nhiều domain knowledge khác nhau. Có người chuyên về CRM, chuyên về ERP, về HR, về DMS hay thậm chí là cả về Marketing.
Cái cách tiếp cận dự án của BA quan trọng ở chỗ này. Làm dự án nào thì nên tiếp cận dự án theo mindset đó. Không thể đem mindset của ERP áp dụng cho một dự án làm CRM được. Cái này mấy anh trong team aware lớp trẻ khá nhiều.
Thông thường một hệ thống CRM được sử dụng chủ yếu bởi nhân viên sales và marketing. Mà cái ớn nhất của Sales là việc báo cáo, là report. Như một ngày làm sales quá trời quá đất, từ email đến điện thoại, chưa kể sales đi field thị trường nữa. Tối về còn phải tổng hợp số liệu là một cực hình đối với họ. Chưa kể nói về Sales thì có rất nhiều trường hợp có thể xảy ra. Nên quy trình sales trên hệ thống phải rất linh động.
Hiểu được công việc của họ, đem mindset của người làm sales áp dụng vào hệ thống. Làm CRM, hãy chắc chắn rằng hệ thống của mình đừng nên “quá chặt chẽ”. Mà hãy “nới lỏng” ra một chút.
Tưởng tượng bạn là 1 nhân viên sales phải tạo mới 1 khách hàng trong hệ thống. Hệ thống bắt phải nhập đủ thứ, từ dữ liệu này tới dữ liệu khác mới cho lưu thì thực sự nó chả sát thực tế tí nào.
Chưa kể chưa nhập xong thì phải lo tiếp nhận một khách hàng khác, rồi phải tiếp tục đi chào cho kịp số. Chắc chắn người dũng sẽ không happy và dường như hệ thống này sinh ra không phải để dành cho họ.
Cái mình nhận được từ dự án đầu tay là: CRM luôn có độ nới lỏng nhất định đối với hành vi của users. Còn ERP thì mang tính quản trị số liệu nên cần sự chặt chẽ hơn.
Dự án đầu tay mình làm có quy trình duyệt giá và xin giá rất chặt chẽ. Bước 1 xong thì phải qua bước 2, tới đích thị ông này, bà kia. Ông này mà không duyệt xong thì không cho qua. Duyệt xong thì qua bước 3. Mà bước 3 phải tiếp nhập đủ cái này, đủ cái kia. Nói chung là phải đúng và đầy đủ thì hệ thống mới cho qua.
Về mặt requirement thì process này đáp ứng đầy đủ 100%. Nhưng trong tương lai, nếu khách hàng thay đổi quy trình một chút thì gãy hết. Vì tất cả làm bằng coding nên khó mà thay đổi quy trình linh hoạt được các bạn à.
Trong tháng cuối dự án chuẩn bị Go-Live, khách hàng họ thay đổi template report cho sales liên tục. Mình nhớ đâu đó tới 4 lần. Mà mỗi lần là 1 cấu trúc khác nhau. Vì nhu cầu quản trị, nên đó hoàn toàn là điều bình thường. Do đó hệ thống cần phải linh hoạt và thích nghi được với mọi sự thay đổi.
4. Đi training nói gì cho hấp dẫn?
Thú thật với anh em là đi train cho người ta thì đừng có nổ banh xác là hệ thống của tui làm được cái này, cái kia Người ta ngáp dài hết mất. Cái cần nói là hệ thống của mình giúp gì được cho họ. Cái này quan trọng à nhen.
Hồi đó mình đi training cũng nói nhiều về hệ thống của mình lắm. Nhưng mindset của mỗi người là khác nhau. End-users thì thường không phải là Sếp.
Cái họ cần quan tâm là: hệ thống giúp họ giải quyết được gì trong mớ bồng bông công việc. Mà để nói được cái này thì chắc chắn phải hiểu được… công việc của họ!
Cái này ngó bộ dễ mà thiệt ra hồi đó mình chả quan tâm. Bản thân mình phải tự trả lời được câu hỏi:
Lúc lấy requirement, mình đã hiểu khách hàng hết chưa? Mình đã hiểu đầy đủ công việc hằng ngày của họ chưa, hay chỉ là đang mường tượng ra “cái-quy-trình” mà họ làm thường ngày thôi?!?
Thường thì phải ngồi trực tiếp, quan sát users làm thực tế thì mới clear được toàn bộ requirement. Mà điều này chỉ thường xảy ra khi bạn đi on-site support users. Tức là tới công ty người ta, ngồi làm việc chung với khách hàng, giống hệt bạn là nhân viên của công ty khách hàng vậy. Nhưng mục đích là để ngồi support users sử dụng hệ thống.
Đây là cơ hội không thể tốt hơn để anh em hiểu requirement thực sự của khách hàng. Tại sao họ lại yêu cầu vậy, mà không yêu cầu khác. Chưa hết, mình còn có cơ hội biết được hệ thống trước họ sử dụng như thế nào nữa. Hoặc các hệ thống liên quan hình thù nó ra sao nữa.
Biết được cái này vô cùng quan trọng nhen, đặc biệt trong các dự án mà có tích hợp nhiều hệ thống với nhau. Đây là cơ hội quá tốt. Nhưng tiếc cái, nếu chờ tới lúc on-site support mà mới tiếp cận được những thông tin này thì đã quá trễ. Vì thường thì lúc này đang chuẩn bị Go-Live xong hoặc đã Go-Live xong quéo rồi.
Do đó ngay lúc lấy requirement, hãy tận dụng các cơ hội được quan sát và ngồi trực tiếp với users. Lúc họ thực hiện nghiệp vụ thường ngày. Có như vậy, mình mới nắm được thực tế và chính xác công việc hằng ngày của họ được.
(Đọc thêm: 11 cách lấy requirement phổ biến cho BA)
Lúc này khi đã biết rõ được công việc thực tế hằng ngày của end-users, mình sẽ mapping nó vào hệ thống lúc training.
Ví dụ trong concept CRM thì có Lead, tức là 1 đầu mối kinh doanh. Nhân viên Marketing hoặc Sales sẽ chăm sóc Lead này thành một cơ hội kinh doanh thực thụ. Để rồi mục tiêu cuối cùng là ra được đơn hàng.
Mapping công việc thực tế của users vào hệ thống thực ra cũng không khó đâu. Chỉ cần show cho họ thấy được thực tế. Ví dụ như:
Lúc trước là bên Marketing phải copy toàn bộ data khách hàng (chẳng hạn như mua được từ Viettel) vào excel. Rồi gọi điện từng ông confirm, rồi lại nhập thông tin vào Excel. Sau đó lọc những Lead nào ổn ổn, rồi gửi cho Sales làm việc tiếp. Cái nào gửi rồi, note lại, cái nào chưa thì đánh dấu. Công việc cứ tiếp diễn, đến kỳ báo cáo thì ngồi lấy lại toàn bộ file excel trước đó. Lọc qua hai ba lượt rồi kéo biểu đồ, số liệu này nọ ra, gửi sếp report.
Nhưng bây giờ có hệ thống, thì công việc sẽ được rút ngắn hơn. Mình chỉ việc tạo một cái Lead (hoặc import danh sách Lead vào hệ thống). Gọi điện và cập nhật dữ liệu lên hệ thống. Bấm nút “Qualify” một cái bụp, Lead tự động được gửi tới nhân viên Sales cần nhận. Thế là xong! Cuối kỳ không cần phải báo cáo gì hết, vì đã có hệ thống tự làm!
Đó, mình chỉ cần cho user thấy được cái THỰC TẾ trước mắt họ sẽ làm, cái đó giúp họ được gì. Thì chắc chắn buổi training của mình có giá trị và gây hứng thú tới người nghe thôi 
Nói về cái mình có luôn là thứ gây buồn ngủ nhất trên đời!!!
Nguồn: Business Ilustrator
5. Việc gì người ta lại sử dụng hệ thống của mình?
5.1. How can I help you?
Đây là câu hỏi mình suy nghĩ rất nhiều trong quá trình training. Thường thì con người ta có khuynh hướng co lại khi tiếp cận một cái mới. Kể cả người lớn tuổi lẫn người trẻ.
Luôn có một câu hỏi ngầm đặt ra trong đầu end-user. Mà thường thì họ chẳng bao giờ nói ra là: “Việc gì mình lại sử dụng phần mềm này cơ chứ?”
Trả lời được câu hỏi này. Anh em chắc chắn đang làm đúng giá trị của một người BA: đem lại chính xác thứ mà khách hàng cần, đó là giải pháp.
Cần phải chắc chắn rằng, hệ thống đã “gãi đúng chỗ ngứa” của khách hàng.
Nhưng mình quên bà mất cái này trong dự án đầu tay. Nhiều lúc dồn lực, dồn sức cho mấy cái requirement, mà bản thân nghĩ cứ nghĩ nó là quan trọng. Nhưng làm xong lại thấy chả có kí lô nào trong mắt khách hàng hết.
Những quy trình như tạo khách hàng, qualify Lead, duyệt giá, xin giá hay lên đơn hàng. Đó đúng là những requirement và mình cần phải tuân theo. Nhưng hoàn thành 100% những requirement này lại không đảm bảo sự thành công của dự án.
Nó còn nằm ở Non-requirement nữa. Điều này thực sự rất quan trọng. Lúc trước mình chả biết gì về mấy cái này đâu. Users có tiện dùng chức năng đó hay không. Họ có thấy happy khi dùng hệ thống hay không. Liệu hệ thống có thực sự rút ngắn thời gian của họ. Hay nó lại là một gánh nặng “bắt buộc phải làm theo chỉ đạo của sếp”!?!
Phía users Sales họ thao tác trên email rất nhiều. Thông thường trong 1 công ty, bất kể bộ phận nào, 2 phần mềm họ sẽ luôn dùng nhiều nhất là: Excel và Outlook.
Hồi mình làm dự án đầu tay, anh Sales Manager bên khách hàng yêu cầu toàn bộ nhân viên phải gửi mail bằng D365 hết. Anh nào gửi mail bằng Outlook là bị “xử trảm” liền.
Để tiện keep track chứ chả có gì hết ráo. Sếp muốn xem thử, mức độ chăm sóc khách hàng của sales đã đủ “hot” hay chưa.
Mà kẹt cái, chức năng gửi email của D365 thì lại rất cùi bắp. Nó hạn chế tùm lum thứ như: font, size, signature, đính kèm hình, file, abc, xyz… Cái đâm ra end-users bên phía khách hàng bất bình lắm.
Best practice muốn sử dụng email tốt trên D365 thì phải cài 1 cái app bổ sung (D365 Apps for Outlook). Thế là lúc Go-Live, anh em cứ tự tin là solution đã đáp ứng hoàn toàn requirement. Nhưng lại quên mất 1 cái non-requirement quan trọng là: chức năng gửi email!
Anh em cứ tưởng tượng xem. Ngày nào mình cũng uống nước bằng ly. Tự nhiên đùng 1 cái, bắt mình ngày nào cũng uống nước bằng… dĩa!!! Ai mà chả khó chịu đúng không. Uống bằng ly quen rồi, uống được nhiều mà dễ nữa. Tự nhiên giờ bắt uống bằng dĩa, chả uống được bao nhiêu mà còn dễ bị đổ nữa.
Cái này cũng giống như việc trước giờ bạn gửi email qua Outlook quen rồi. Mà giờ bắt bạn gửi email qua 1 cái phần mềm hạn chế đủ trò, từ font chữ cho tới ký tự. Không khó chịu mới lạ.
Chính vì vụ gửi email này làm dự án bị delay hơn cả 1 tuần để configure thêm. Users cũng khó chịu, phía team triển khai cũng tốn thêm thời gian.
Thiệt ra thì chỉ cần focus vào 20% những requirement quan trọng, nhưng nó đem tới 80% mức độ hài lòng của khách hàng. Và chức năng email là 1 trong số 20% requirement quan trọng kia.
5.2. Tản mạn về users
Hồi mình đi training cho users trong dự án đầu tay, có 1 bà chị bên sales. Chị đó là người chăm chú lắng nghe nhất. Và cũng là người năng nổ nhất trong việc đặt câu hỏi trong buổi training.
Mình nghĩ bụng phải ai mà cũng nhiệt như bả thì đỡ biết mấy. Thực tế thì chị đó rất chịu khó mày mò dùng hệ thống mới. Nên rất hay come up ra những câu hỏi hay.
Training xong, đoạn users sử dụng thực tế để test, thì chị này cũng là người năng nổ nhất. Nhưng lại là người năng nổ… complain nhất.
Thực tế thì cũng không có gì. Vấn đề là ở vụ email như mình có nói ở trên. Việc một người users có cảm xúc mạnh như vậy cũng là một điều dễ hiểu.
Điều đáng nói là chính vì những phản ứng và cảm xúc đó mà mình mới thấy được đâu là cái khách hàng quan tâm thật sự.
- Cái họ muốn nhận được là một thứ giúp họ tiện lợi hơn trong công việc. Chứ không phải cản trở họ.
- Cái họ muốn nhận được là một hệ thống CRM giúp họ theo dõi được khách hàng, chứ không phải một mớ bồng bông các chức năng trên trời.
- Cái đó muốn nhận được là những báo cáo công việc hằng ngày của chính họ. Hiển thị rõ ràng, chính xác và đẹp đẽ trên dashboard. Chứ không phải là những phân tích hay dự đoán đao to búa lớn mà mình cứ chăm chăm vào build cho bằng được.
Anh em mình cần tập trung vào những gì Users làm được trên hệ thống. Thay vì những gì hệ thống có thể làm được.
Xong giai đoạn support, khi mọi thứ đã vào guồng thì mình mới thật sự yên tâm và thở phào nhẹ nhõm. Không phải vì công việc quá nhiều hay quá áp lực. Mà thở phào vì công sức của cả team cũng được người ta công nhận. Mình được tận mắt chứng kiến, những solutions đó giúp được thực tế cho khách hàng, chứ không phải là những thứ trên trời.
6. Kết
Đây là dự án mà mình thấy được nhiều vấn đề, và cũng học hỏi được rất nhiều từ đó. Nói dự án thành công 100% thì chắc chắn là chưa. Nhưng với nỗ lực của anh em, đâu đó mình nghĩ cũng đáp ứng được tầm 65% mức độ hài lòng của khách hàng.
Trên là những chiêm nghiệm mà mình rút ra được từ dự án đầu tay. Cảm ơn anh em đã đọc tới đây Hẹn gặp anh em những bài sau nhé! See yaaa!!!
Nguồn: thinhnotes.com
