Chào mọi người, cũng lâu lắm mới lại cầm bút … ah gõ phím. 2 năm ” timeskip” đã giúp mình có thời gian để trau chuốt thêm một vài kỹ năng. Càng làm càng thấy có nhiều thứ chưa nói hết. Đặc biệt là với hàng tá công việc không tên, đủ mọi vấn đề phát sinh từ cái role BrSE này. Vậy nên mình sẽ quay lại để gõ. Hy vọng là anh chị em bà con sẽ tiếp tục đón nhận.
Quay lại chủ đề chính về việc onsite. Nhiều người sẽ bảo là cứ lao vào mà làm thôi, cần gì trình tự, tới đâu gỡ tới đó, còn thở là còn gỡ … Cũng đúng, nếu bạn đã có kinh nghiệm, còn với các búp măng non mới vào nghề thì khó cho các bạn quá, càng gỡ đôi khi càng rối.
4 tháng vừa rồi mình đã tham gia một dự án với nghiệp vụ hoàn toàn mới, khách mới, team mới và mọi thứ đều mới. Nói cho oách vậy chứ với BrSE thì dự án nào chả mới, hiếm lắm thì gặp cái giống giống (chắc cỡ 30%). Nội dung công việc cũng “tả pí lù”, tùm lum thứ. Mấy ngày đầu là RD, BD, tiếp theo thì xây Database, sau đó tới build môi trường DEV-Test và tiến hành vừa debug vừa test. Mà cái hay ở khách này là qui trình test rất chuyên nghiệp và linh hoạt từ UT, Ita, Itb, ST và AT.
Dành cho bạn nào chưa hiểu về test thì UT là UnitTest, tức là kiểm thử từng module/màn hình, còn Ita và Itb thì sẽ test theo 1 luồng nhiều function/màn hình có liên quan tới nghiệp vụ, ST là nhiều system liên kết nhau còn AT là nghiệm thu từ view của Enduser lúc dùng sản phẩm.
Nói dài vậy để các bạn hình dung ra bối cảnh mà dự án mình vừa tiếp cận để lấy làm ví dụ cho bài viết này. Và dưới đây xin mạn phép vẽ ra các step từ khi lấy thẻ bước vào cổng công ty khách hàng cho tới khi trở thành 1 key member trong dự án.
Step 1. Hiểu rõ yêu cần ngắn hạn và dài hạn
Step 2. Hình dung bối cảnh dự án
Step 3. Tiếp nhận Handover
Step 4. Gia nhập và chạy đà
Step 5. Tăng tốc
Step 6. Kéo dự án và triển khai
Step 1. Hiểu rõ yêu cần ngắn hạn và dài hạn
Yêu cầu có thể đến từ 2 phía, phía khách hàng và phía đội nhà. Mỗi bên đều có những mục tiêu riêng, và để đi được xa thì cả 2 phải có 1 điểm chung. Ví dụ khách chỉ muốn mình vào ngồi cho đủ team trong khi đội nhà đặt chỉ tiêu phải xây dựng team 50 người offshore thì fail. Với tư cách là người onsite thì đôi khi bạn chỉ cần làm tốt nhiệm vụ khách giao là ổn rồi, tuy nhiên nếu nắm được yêu cầu ngắn-dài hạn từ 2 phía thì sẽ rất thuận tiện cho việc phát triển lâu dài. Lấy 1 ví dụ về dự án mình làm cách đây 8 năm, ngày đó quả thật là khách chỉ muốn vào ngồi cho đủ team, tuy nhiên kết quả là sau 3 năm mình đưa về doanh thu hơn 1 triệu đô, con số này có thể là to/nhỏ tùy góc nhìn, tuy nhiên đối với bản thân thì thấy đó là kết quả của sự nỗ lực cộng với việc nắm bắt được nguyện vọng từ cả 2 phía để đưa ra đề xuất đúng thời điểm.
Step 2. Hình dung bối cảnh dự án
Thứ nhất mọi người cần hiểu chữ WHY, tại sao khách cần mình vào onsite. Có thể là chữa cháy 1 dự án gần ngày release như dự án cho khách hàng hệ thống kho Socola toàn quốc mình làm hồi năm ngoái. Hoặc cũng có thể là vào để test năng lực xem tụi VN làm được gì. Còn khỏe nhất là Boss 2 bên đã thống nhất lộ trình vài năm hợp tác, mình chỉ là người thực thi. Khỏe nhưng chưa hẳn là tốt, vì trong trường hợp này mình không nắm hoặc không có nhiều giá trị mang tính quyết định.
Thứ 2 là ngay thời điểm trước ngày bắt đầu, các bạn cần có 1 Q&A list để gửi khách nhờ họ đưa ra cho mình một danh sách những thứ cần nắm về kỹ thuật, nghiệp vụ. Với những mảng việc mới, ngôn ngữ công nghệ mà mình chưa từng có kinh nghiệm thì phải tự học, còn muốn nhanh hơn thì nhờ người có kiến thức sâu giúp đỡ nhằm rút ngắn thời gian. Phải nhớ là đọc để nắm tổng quan dựa trên dữ kiện từ câu trả lời của khách hàng mà bạn đã gửi câu hỏi đi trước đó, bám vào đấy để điều tra – tìm hiểu.
Step 3. Tiếp nhận Handover
Có một thực tế là đa phần các dự án onsite thì không có file Handover (truyền đạt nội dung công việc) bài bản. Vậy nên với các bạn có được file chỉ đường này là cực kỳ may mắn khi gặp được khách hàng chuyên nghiệp. Còn nếu không thì chúng ta vẫn có một số giải pháp để khắc phục.
Đầu tiên phải xác định rằng với mỗi dự án thì hầu hết đã có một hoặc nhiều team làm xong phần việc nào đó, có thể là đã xong RD và bắt đầu tới giai đoạn BD chẳng hạn, và dự án mình làm đang tới giai đoạn nào. Để làm được việc này thì có 2 cách, 1 là hỏi trực tiếp madoguchi – tức là người PM/PL phía khách, 2 là tìm tài liệu về Plan hoặc WBS để đọc, nếu folder quá lớn và khó tìm thì bạn cần có 1 số key-work như 計画, ステータス, 概要 …
Tiếp đến là hình dung được công việc sắp tới của mình nằm trong mảnh ghép nào trên một bức tranh toàn cảnh về cấu trúc team cũng như dòng chảy của dự án. Tức là không chỉ một mà nhiều team cùng làm, mỗi đội phụ trách một phần công việc. Ví dụ dự án xây dựng hệ thống quản lý kho, nếu chia theo chức năng thì ít nhất phải có 3 đội : đội 1 làm về xuất nhập kho, đội 2 làm chức năng điều chỉnh và đồng bộ số liệu, đội 3 sẽ làm về hệ thống đơn hàng – phân phối thu mua – vận chuyển.
Cuối cùng mới đi đến chi tiết công việc sắp tới mình sẽ phải đảm nhận là gì. Có thể là thiết kế màn hình, hoặc database, hay có thể chỉ là đọc hiểu tài liệu và làm mẫu Detail Design để chuyển về offshore coding.
Step 4. Gia nhập và chạy đà
Đây là khoảng thời gian cực kỳ gian nan, đặc biệt là trong vài tuần đầu tiên. Các bạn sẽ phải đọc, học và làm những công việc mà thậm chí không hiểu đang đọc gì, đang làm gì. Trong giai đoạn này có một kinh nghiệm xương máu mà mình phải nhắc đó là NGỦ đủ. Thật chứ không đùa, vì khi cắm mặt vào 1 file tài liệu gần cả ngày mà vẫn không hiểu gì thì rất dễ ngủ gục ngay trên bàn làm việc nếu bị thiếu ngủ. Và liên tiếp trong vài ngày, vài tuần, từ chỗ không biết gì thì dần dần sẽ hiểu được luồng nghiệp vụ cũng như qui trình thực hiện. Có một điều mà đa phần các bạn trẻ hay gặp phải đó là ngại hỏi. Không nói đâu xa, bản thân mình cũng đã từng bị như vậy. Nhớ hồi 10 năm trước, lần đầu tiên ngồi đọc tài liệu phương châm thiết kế, tiếng nhật gọi là 設計方針. Thời điểm đó ngay cả thiết kế là gì, phải làm như thế nào một chữ bẻ đôi còn không biết thì làm sao mà có thể ngấm được tài liệu khó nhằn này. Nhưng mà ngại hỏi nên thành ra 1 tuần đầu cứ gục lên gục xuống liên tục, lâu lâu phải chạy đi rửa mặt, có khi phải lao ra ngoài trời lạnh 3-4 độ một lúc cho tỉnh rồi quay lại … gồng tiếp. Nghĩ lại đúng cực hình. Nhưng rồi khách thấy tội quá nên dắt vô phòng họp, vẽ lại một cách trực quan luồng qui trình cũng như cách để tạo ra một file thiết kế, từ đó mới mơ hồ hiểu được và biết cách để đọc tài liệu.
Step 5. Tăng tốc
Lúc đã nắm được tổng quan cũng như công việc trong ngắn và dài hạn thì đây là lúc chúng ta dốc hết sức. Thường thì sẽ có 2 mức độ 1 là tròn vai, 2 là vượt kỳ vọng. Với những bạn mới, chúng ta chỉ cần nhắm tới mức độ 1. Và để tròn vai, tức là đáp ứng được hết tất cả những yêu cầu từ khách không phải điều dễ. Các bạn cần hình dung được danh sách task và deadline cho từng việc rồi sau đó mới tập trung xử lý từng chút một, và phải nhớ cố gắng hết sức để hoàn thành đúng, thậm chí sớm hơn dự kiến để đề phòng một số task sẽ khó hơn và lâu hơn estimate ban đầu. Với mức độ 2 thường là dành cho các bạn đã có một vài năm kinh nghiệm. Lúc này việc tiếp nhận một dự án với các bước đã gần như thành thạo. Vậy nên chúng ta sẽ có đủ tự tin và mức độ tập trung cao để hoàn thành task với chất lượng tốt hơn kỳ vọng cũng như tự giác nhận thêm việc với độ phức tạp cao.
Step 6. Kéo dự án và triển khai
Như đã nói ở step 1. Với trường hợp khách chỉ cần mình ngồi cho đủ team và họ không có ý định mở rộng thì mình có xuất sắc tới mấy cũng không giải quyết được gì ngoài việc tạo cho họ sự tin tưởng ở trong … tương lai. Còn với khách đã có plan triển khai một team offshore ngay từ đầu thì độ lớn của team sẽ tương đương với năng lực của BrSE. Về việc triển khai thì sẽ có một số gạch đầu dòng bên dưới :
– Bảo mật thông tin : đây là ưu tiên số 1. 2 bên cần thống nhất một số quy định về hình thức giao tiếp, tool sử dụng trong dự án, gửi và nhận file …
– Plan : trong ngắn hạn và dài hạn
– Release và Deadline : Cần có danh sách sản phẩm release, yêu cầu về chất lượng và khối lượng, ngày giờ release. Để cho an toàn thì có 1 mẹo nhỏ mà các BrSE kinh nghiệm đều biết đó là luôn đặt ra 2 mốc deadline, 1 cho nội bộ và 1 để gửi khách.
– Điều kiện tiền đề và căn cứ để xác định và quản lý bug, CR
– Quản lý rủi ro : về mặt nghiệp vụ, kỹ thuật và nhân sự.
Với mỗi mục ở trên để mà nói kỹ thì sẽ rất dài vậy nên hẹn các bạn ở một dịp khác mình sẽ chia sẻ thêm.
Kết
Với mỗi dự án để việc triển khai được suôn sẻ thì cách tiếp cận đúng chính là điều kiện tiên quyết, kiểu như đầu xuôi đuôi lọt. Lý thuyết là vậy nhưng trong thực tế sẽ có rất nhiều tình huống phát sinh, những thứ chưa làm và chưa từng nghe tới, những vấn đề lần đầu tiên gặp phải mà không biết cách nào để giải quyết cả. Đó chính là lúc kỹ năng tự học và bản chất chai lì phát huy tác dụng. Đã có lần có bạn hỏi mình tố chất để trở thành BrSE giỏi là gì, lúc đó mình đã trả lời chỉ cần chai lì là ổn. Thực chiến bao giờ cũng khác xa với sách vở, nhưng không vì vậy mà các chiến tướng coi nhẹ binh pháp. Các bạn cần có cho mình một hoặc nhiều phương pháp tiếp cận, vì “đánh” dự án về một mặt nào đấy cũng chả khác gì đánh trận cả. Trong bài này mình đưa ra luồng step đã tích lũy và kiểm nghiệm trong hơn 10 năm làm nghề, nó có thể hợp lý hoặc …không tùy theo hoàn cảnh. Các bạn tự trải nghiệm và đúc kết sau này gom lại thành “bí kíp” để còn share lại cho lớp sau.