Hế lô anh em. Số là vừa rồi mình mới nhận KT một dự án, khá chua. Nên hôm nay mình có đôi lời chia sẻ với anh em về “cái cột mốc” quan trọng có một không hai này.
(KT là Knowledge Transfer, tức là bàn giao, chuyển giao công việc nhé anh em, nói KT cho nó nguy hiểm )
Vào một ngày không được đẹp trời cho lắm, mình nhận được email từ anh síp, bảo rằng sắp tới anh A sẽ nghỉ việc.
Cảm xúc lẫn lộn, nửa vui nửa buồn. Vì trước giờ mình cũng đã từng đi… “đổ vỏ” khá nhiều cho anh này. Và lần này là một linh cảm không lành khi đọc những dòng đầu tiên trong email.
Và xác định, y như rằng, mình sẽ nhận KT dự án từ anh A. Tiếp tục nhiệm vụ chua chát: đóng thành công dự án đã quá nát này…
Thiệt ra lúc trước mình đã có mấy lần support dự án này, nên mình hiểu được nó chua đến cỡ nào. Và mình tin rằng lý do chủ yếu đến từ team dự án, chứ không phải khách hàng.
(Mình không blame ai hết, nhưng thực tế nó là như zậy…)
Và với vai trò một người nhận handover, mình đã không ít lần lên bờ xuống ruộng với dự án này. Phần vì bản thân dự án đã khá nát, phần khác vì mình đã mắc phải một số sai lầm cơ bản trong quá trình KT dự án.
Và bài này mình sẽ rút chích lại một số lưu ý cho anh em khi KT dự án. Kể cả dự án có nát hay chưa thì hi vọng những điều dưới đây sẽ giúp anh em KT một cách hiệu quả nhất.
Đứng ở vai trò người KT dự án, anh em cần chuẩn bị trước được những thứ sau đây.
2.1. Thời gian
KT không phải 1 ngày, 1 buổi, mà là cả quá trình. Cần phải xác định rõ thời gian tổ chức KT là gồm bao nhiêu buổi. Mỗi buổi từ mấy giờ đến mấy giờ.
Những cái này anh em phải xác định kỹ, vì nó ảnh hưởng trực tiếp đến cost của dự án.
Hãy thử tưởng tượng mấy anh em không lo làm dự án, cứ suốt ngày cắm đầu ngồi KT, thời gian càng kéo dài, mình là người bị lỗ, chứ không phải khách hàng. Còn nếu KT mà lơ tơ mơ, bèo nhèo cức mèo thì mai mốt vô chạy dự án là ăn hành ngán luôn anh em.
2.2. Thành phần tham gia
Dù anh em là người đi KT hay người nhận KT, thì hãy cố gắng kêu gọi đầy đủ những người liên quan tới cùng tham gia. Vì như vậy, thông tin mới được trong suốt và minh bạch.
Ví dụ như mình vô KT với anh A. Nghe nói rằng User Manual đã được ảnh và chị B update đầy đủ lên Sharepoint. Mà về mở lên chả thấy khiri khô đâu, thấy toàn version từ hồi napoleon chưa mọc lông, cũ lắc cũ lơ.
Giờ quay sang nói thì lại tốn thêm thời gian, rồi người này đổ cho người khác, tùm lum tùm la hết. Nên cái gì dứt điểm được gọn, thì dứt luôn tại chỗ. Ai xác nhận được gì thì hãy xác nhận ngay.
Và bắt buộc phải chuẩn bị trước check list cho các task cần làm sau buổi KT. Ai là người chịu trách nhiệm (PIC - Person In Charge), ghi rõ vào, và người đó phải được join vào buổi KT để xác nhận mình sẽ chuẩn bị tasks đó.
Và điều quan trọng nhất là…
2.3. Nội dung
Nếu anh em là người đi KT cho người khác thì chắc chắn anh em phải chuẩn bị thật kỹ nội dung: KT những mục gì, nội dung gì, nội dung theo các buổi ra sao.
Nếu anh em là người nhận KT, thì anh em phải đòi cho được nội dung KT ngay trước giai đoạn KT. Hoặc chí ít là cần biết được: buổi hôm đó mình sẽ làm gì, buổi tiếp theo sẽ làm gì nữa.
Để từ đó có cái nhìn tổng quan, tránh bị rối khi người KT họ không tự cấu trúc, sắp xếp mọi thứ lại một cách rõ ràng. Và kịch bản tệ nhất, sẽ là một đám rối nùi trong phòng họp.
Nhớ gì nói đó, không checklist, không cấu trúc rõ ràng, dẫn tới thông tin bị rơi rớt. Và tệ nhất là cái ông nhận KT sau này ổng đi chế ra thông tin, rồi tự biên tự diễn.
Đó là con đường nhanh nhất để kéo dự án xuống vực đó anh em ?. Vì đi lệch đường bà nó rồi, khách hàng kêu làm cái tô, mà đi làm cái bô là chết toi.
2.4. Pho mồ
Đối với người nhận KT, anh em hãy cố gắng làm buổi KT trở nên formal hết sức có thể. Vì sao?
Vì tâm lý cái ông đi KT cho người khác là ổng sắp nghỉ, nên chữ “trách nhiệm” đến lúc này là nó tự động rơi rụng hết à. Lạ kỳ vậy đó.
Cho nên thường họ sẽ KT cho có, cho nhanh để còn thu xếp mà nghỉ. Hoặc đơn giản là vô KT: “mày hỏi gì thì hỏi đeiii, tao trả lời”. Chứ không chuẩn bị khỉ khô gì hết ráo.
Ai đàng quàng thì không sao, team đó quá may mắn. Ai mà ẩu tả thì thôi rồi. Nên tốt nhất là anh em cứ nên chủ động trước.
Đừng để lúc nước dâng tới háng rồi mới nhảy thì đã… ướt quần rồi.
Anh em hãy cứ nghiêm túc, làm theo đúng quy trình của công ty. Nếu công ty không có quy trình rõ ràng thì hãy hỏi những anh chị Senior trong team:
- Cần vạch ra bức tranh tổng quan như thế nào?
- Master data cần có?
- Checklist gồm những gì?
- Handover document, ký tá ra sao?
- Nhóm thông tin bên phía khách hàng?
- Tài liệu dự án đã có đủ?
Riêng khoản ký tá. Hãy chắc chắn khi nào KT xong, thì hẳn ký. Mà khi nào mới KT xong? Đọc tiếp phần dưới nhé anh em.
Những thứ dưới đây nghe có vẻ hơi lạ, nhưng theo kinh nghiệm thực tế của mình thì mình tin nó rất hữu ích. Đó là: Data và Buttons.
Anh em để ý thử xem, 100% tất cả các requirement đều liên quan đến 2 thứ này.
Trong phần mềm, nếu data là máu,
thì button đích thị là bộ xương của cơ thể.
Phải có máu thì cơ thể mới tồn tại được. Không có một phần mềm nào tồn tại được mà không có data chảy trong nó.
Cũng như: phải thông qua các button, mà người dùng mới có thể thực hiện các thao tác nghiệp vụ trên hệ thống. Giống với việc cơ thể phải có bộ xương thì mới cử động, làm cái này, cái kia được.
3.1. Data
Một trong những điểm quan trọng nhất khi KT dự án là anh em cần phải nắm chắt hiện trạng của dự án lúc mình nhận.
Tức là sao?
Tức là anh em phải hiểu hết các chức năng cần có trên hệ thống. Hay nói cách khác, anh em phải nắm rõ được, nắm rõ được: Hệ thống này giúp ích được gì cho công việc của user?
Và một trong những cách tốt nhất để làm việc này, đó là:
Hãy đảm bảo anh em đã hiểu rõ hết ý nghĩa của những dữ liệu có trên hệ thống?
Cụ thể, anh em cần phải nắm rõ được: trường dữ liệu này ý nghĩa gì, để làm gì, lấy dữ liệu đầu vào từ đâu, dữ liệu đầu ra đi đâu. Phải hiểu được hết 100% toàn bộ hệ thống.
Có thể anh em thấy cách này sẽ tốn thời gian. Và cách tốt nhất là chỉ cần đọc tài liệu yêu cầu và thiết kế hệ thống. Đại loại như: FRD, FDD, SRS hay Blueprint nói chung là được.
Nhưng thực tế là, việc duy trì những tài liệu này đúng với thiết kế hiện trạng của hệ thống là rất khó. Vì xuyên suốt từ đầu dự án đến khi anh em nhận KT, mình không chắc được rằng:
- Team hiện tại có quản lý tốt requirement hay không?
- Họ có trace lại những gì thay đổi hay không (changeability)?
- Tài liệu Change Request có cung cấp đủ thông tin hay không?
Anh em nên nhớ đây là giai đoạn để mình hiểu HIỆN TRẠNG của hệ thống. Anh em cần nắm rõ:
- Hệ thống đang có gì?
- Hệ thống đang được thiết kế ra sao?
Thì mới nói tới chuyện:
- Hệ thống có đang đi đúng yêu cầu hay không?
- Vấn đề hiện tại đang nằm ở chỗ nào?
- Đâu sẽ là story tốn nhiều effort nhất?
- Thiết kế như vậy đã đúng hay chưa?
- Và hàng ngàn câu hỏi khác nhằm: xác định những bước đi tiếp theo khi nhận dự án.
Đúng là cách này sẽ tốn thời gian. Rất rất tốn thời gian. Nhưng tốn thời gian bây giờ, còn hơn là khi để mọi thứ rối nùi lên mới lo tìm hiểu, tổng hợp thì đã quá trễ.
Như lúc trước mình chỉ đọc trong bộ tài liệu thiết kế yêu cầu. Và biết được rằng: à nó có 5 quy trình, đối tượng này, đối tượng kia, có dữ liệu này, dữ liệu kia.
Và mình khá tự tin với việc đọc rất kỹ mớ document này. Đến khi monthly meeting với khách hàng, có cha kia (hình như mới vô dự án) hỏi: “Hế nhô, cho anh hỏi, cái field này là để làm gì zị em?”
Mình dòm trên màn hình thấy lạ quắt. Nghĩ trong đầu: “Quát đờ phở, ở đâu tự nhiên phọt ra dữ liệu lạ quắt zị taaa????”
Rối bời quá không biết làm sao, đành trả lời: “Dạ để em check lại. Có thể đó là một bất ngờ nho nhỏ bên em dành tặng cho bên anh thôi chứ hông có gì đâu, ahihi…”
Đắng lòng hơn, là cái field đó liên quan đến tính năng approve đơn hàng. Là thêm một mớ quy trình bồng bông phía sau mà mình đã bỏ lỡ. Mớ bồng bông chỉ mới được thêm vô cách đây chưa đầy 1 tháng.
Và-hoàn-toàn-không-được-cập-nhật-lại-ở-bất-kỳ-document-nào…
3.2. Buttons
Theo logic mà nói:
User dùng hệ thống để giải quyết vấn đề của họ (lưu trữ cái gì đó, tự động hóa cái gì đó…). -> Hay nói cách khác, hệ thống có các chức năng giúp giải quyết vấn đề của user. —-> Để sử dụng các chức năng của hệ thống, user phải thực hiện một sốthao tác trên hệ thống. ——-> Muốn thực hiện thao tác, user phải… BẤM NÚT. ———-> Vậy nếu hiểu được các nút bấm, quay ngược lại, anh em đã hiểu được chức năng của hệ thống. —————> Từ đó, anh em đã hiểu được hệ thống hiện tại đã được design đến đâu cũng như tình trạng các chức năng hiện có.
Do đó hãy dành thời gian ngồi list down ra các nút bấm có trên hệ thống khi anh em nhận bất kỳ một dự án nào đang dang dở.
Mình chắc chắn anh em sẽ bỏ sót một số nút nào đó. Kéo theo đó có thể là bỏ lỡ một vài chức năng. Những chức năng được “thêm mới thoải mái without document” như ví dụ bên trên của mình.
Người ít kinh nghiệm nhìn con heo ra con heo. Người nhiều kinh nghiệm nhìn con heo là ra ngay dĩa đồ lòng 7 món.
Khi KT dự án, một cái nhìn rộng, bao quát là chưa đủ. Anh em cần phải nhìn sâu hơn những rủi ro có thể phát sinh trong tương lai.
Ví dụ sắp tới cái chị Contact Point bên phía khách hàng… nghỉ đẻ thì sao?
Đa phần anh em sẽ nghĩ đó là chuyện bình thường. Nhưng đối với những người có kinh nghiệm, đó là một rủi ro thật sự. Contact Point là một trong những vai trò chính yếu, không thể thiếu bên phía khách hàng.
Có không ít những dự án đang chạy trơn tru, những tưởng là sắp về đích thành công. Nhưng rồi tự nhiên bị khựng lại và cứ đi lòng vòng miết khi người Contact Point gặp vấn đề, và phải nghỉ việc.
Nếu trong trường hợp biết được tin Contact Point bên phía khách hàng sắp nghỉ để, có thể anh em sẽ để ý hơn đến kế hoạch của người này, hỏi chỉ khi nào thì đẻ, chị đã bàn giao lại cho ai hay chưa?
Nếu chưa thì mình phải chủ động raise lên phía khách hàng, hoặc nhắm sẵn những key-users khác có thể đảm nhiệm vị trí thay cho chị Contact Point này.
Do đó khi KT dự án, hãy hỏi hết toàn bộ tình hình của khách hàng mà anh em có thể. Đặc biệt là chú ý đến mấy bác Decision Maker. Tránh trường hợp làm cho đã, rồi cứ sếp này lên, thay sếp cũ là kêu đập hết làm lại thì cũng y như rằng.
Đối với anh em BA mình, mặt kỹ thuật thì có vẻ khó để nhìn trước rủi ro, nên mình cứ chú trọng đến mặt con người là chắc nhất.
Đây cũng là một điểm rất quan trọng. Xác định ở đây không chỉ là biết được người này, người kia đóng vai trò gì trong dự án. Mà còn phải hiểu về cách làm việc của họ nữa.
- Anh Contact Point này trước giờ có theo sát dự án không?
- Background của ảnh là gì, mindset của ảnh ra sao?
- Chị PM này có thật sự hiểu về dự án đang làm hay không?
- Users bên phía khách hàng có hợp tác, niềm nở hay không?
- Trước giờ đã có scandal gì chưa, impact ra sao?
- Mức độ hỗ trợ của anh Manager này, chị Manager kia như thế nào?
- Và hàng ngàn câu hỏi khác cần quan tâm đến những người giữ vai trò quan trọng trong dự án.
Tuy nhiên, anh em cần phải nắm rõ được: những ai là người có ảnh hưởng lớn đến dự án, đến chuyện ký tá trong dự án. Đó không nhất thiết là CEO, mà thường là các Manager ở các bộ phận, và PM của dự án.
Khi tiếp nhận dự án mới, biết được họ cần gì, muốn gì, sẽ giúp anh em dễ dàng tiếp cận và trao đổi công việc với họ được thuận tiện hơn.
Tuy nhiên, quan tâm team nhà người ta, thì cũng phải quan tâm đến team nhà mình.
Cái này thì anh em có thể trao đổi riêng với người KT: hỏi về các thành viên còn lại trong team, từ Dev, QC và đến cả PM nữa. Hỏi để nắm được “phong thái, thần thái” làm việc :3
Biết được anh nào hay vô trễ, anh nào hay vô sớm để tiện sắp xếp, bàn bạc công việc. Biết được anh nào hay “quên task” để biết ngõ focus vào nhiều hơn ?
Check dependencies, đặc biệt là về kỹ thuật.
Anh em phải nắm được là trong hệ thống của mình, có các services nào đang chạy, mà bị phụ thuộc vào bên thứ ba hay không.
Ví dụ hệ thống mình đang chạy ngon, một ngày đẹp trời, lỗi ở đâu phọt ra tùm lum. Chức năng này bị thọt, chức năng kia bị thọt. Thì có thể là do các services chạy background bên dưới gặp vấn đề.
Nếu có thì phải biết mình đang dùng services của bên nào, hãng nào, contact ra sao, để khi có chuyện, mình chủ động được tình hình mà xử lý.
Như mình bữa nhận được một case: sáng thứ Bảy đẹp trời, user dùng hệ thống mà không thực hiện lấy tồn kho được (chức năng tích hợp với hệ thống của khách hàng). Thế là quy trình bị đứng một cục.
Bà con la làng quá trời quá đất. Té ra là do server bên khách hàng có vấn đề. Ngay lập tức phải liên lạc với đội IT bên đó để khắc phục sự cố. Nếu mình không nắm được thông tin liên lạc, cũng như không biết gì về những dependencies này khi KT, thì có lẽ mọi chuyện đã bị đẩy đi rất xa rồi.
Vâng, và đây là câu hỏi quan trọng nhất bài này. Anh em sẽ nói: “TUI ĐÃ KT XONG, VÀ HOÀN TOÀN SẴN SÀNG”, khi:
Anh em có thể tự tin xác định được: cái gì in scope, cái gì out of scope.
Tin mình đi, vì những thứ trên hoàn toàn sẽ quy về câu chuyện scope hết.
Một khi anh em đã hiểu dự án, là khi anh em đã hiểu được hiện trạng dự án làm tới đâu và mong đợi khách hàng là gì.
Hay nói cách khác, là anh em phải biết được: Mình đã đi được tới đâu, và mình cần phải đi đâu?
Trên con đường mình đi sau khi tiếp nhận dự án, sẽ có vô vàn “hố gà” và “đường tắt” mà anh em phải đề phòng.
- “Hố gà” là những vấn đề, những khó khăn mà team sẽ gặp phải. Anh em phải thật sự hiểu được team mình, hiểu năng lực của anh em thì mới có thể tìm cách vượt qua được những “hố gà” này.
- Còn “đường tắt” là thứ nguy hiểm nhất. Đó là khi anh em bị khách hàng “dắt mũi” dẫn đi tùm lum tùm la hết.“Tui muốn cái này, tui muốn cái kia, ơ cái này ngay từ đầu nói rồi mà, cái kia giờ đổi rồi, quy định công ty đổi rồi, nên quy trình đổi theo đeiiii…” Và hàng nghìn thứ lý do khác, sẽ dẫn anh em đi lòng vòng mà không bao giờ cán được đích.
Do đó, nếu không biết rõ mình đang ở đâu, và mình muốn đi đâu, thì anh em sẽ rất dễ bị dắt vào những đường vòng, mà cứ ngỡ đó là đường tắt.
Và đặc biệt đừng để khách hàng lấy lý do ĐỔI NGƯỜI MỚI, để họ chống chế, đòi thêm yêu cầu mới, dẫn đến kéo dài dự án không đáng có.
Không chỉ những dự án làm Agile, mà những dự án bình thường khác mình thấy cũng rất cần thiết để warm up với khách hàng hằng ngày.
Sẽ chẳng có ai mà thoải mái bàn bạc, xử lý công việc với anh em khi anh em là người lạ cả.
Anh em phải aware được: mình là người mới. Chỉ sau 1 buổi giới thiệu thì khách hàng họ cũng chả nhớ, và chả quan tâm mình là ai hết. Đặc biệt là phía key-users.
Và một điều cực kỳ quan trọng cần lưu ý là: khi khách hàng đã quen với mình, có thiện cảm với mình, thì mọi thứ làm việc sau này sẽ vô cùng thuận lợi và dễ dàng.
Do đó, một trong những điều đầu tiên mà phần lớn mọi người hay quên (kể cả mình), là không chịu giao tiếp, liên lạc với họ thường xuyên để giữ mối quan hệ, đặc biệt là với các key-users.
Mỗi dự án, mỗi phương pháp triển khai sẽ có những cách KT đặc thù của nó. Nhưng nhìn chung, anh em hãy cố gắng làm mọi thứ CLEAR hết sức có thể.
Hi vọng anh em sẽ tìm thấy gì đó có ích từ bài viết này. Bái bai và hẹn gặp anh em ở những bài viết sau
