【Project 007】Một số điểm quan trọng khi vận hành dự án có nhiều site

Hôm nay mình sẽ chia sẻ với mọi người một số kinh nghiệm khi làm dự án nhiều site. Hiện giờ chúng ta chủ yếu làm dự án 2 site hoặc 3 site, nhưng trong thời gian sắp tới có khả năng chúng ta phải làm các dự án 4-5 site. Trước đây mình từng có kinh nghiệm làm việc ở vị trí PMO cho 1 dự án có 5 site gồm HCM, ĐN, Hà Nội (2site), Cebu (Philippine) tạm đặt tên là Project 007, mọi người có thể tham khảo các thông số của dự án ở dưới cùng. Đây là dự án với volume rất lớn và đặc biệt chạy trong khoảng thời gian ngắn so với volume nên bản thân mình học được rất nhiều kinh nghiệm thực tế từ dự án này. Qua bài viết này mình hy vọng những kinh nghiệm này sẽ giúp mọi người có thêm thông tin để tham khảo, từ đó làm tốt hơn trong việc vận hành, quản lý các dự án nhiều site.

**I. Những điểm đã làm tốt

1. Communication** Việc này mình để ở vị trí số 1 vì nó là quan trọng nhất. Việc giao đổi giữa các PM, TL, member ở dự án 1-2 site thì cũng có thể có một vài vấn đề nhưng xử lý không khó và ít mất thời gian. Nhưng ở dự án 5 site thì cả vấn đề, ví dụ điển hình là ở buổi họp PMO buổi sáng giữa 5 site development và 1site của team onsite (lúc đó mình ngồi ở team onsite), chỉ thị mới từ phía khách hàng là A, rồi đến chiều hỏi lại TL ở các site thì nó lại thành A1, A2, A3, có chỗ lại hiểu thành B. Thời gian đầu luôn có những vấn đề kiểu như vậy cả những chỉ thị liên quan tới scope, schedule, hay cả các vấn đề liên quan tới technical… Để làm tốt việc communication thì trước tiên team PMO tiến hành họp 2 lần một ngày vào 9h sáng và khoảng 24h-1h sáng (JP time) (khoảng 3 tháng cuối thì giảm xuống họp 1 lần/ 1 ngày). Ở level Team lead (TL) hay member thường gặp các vấn đề kỹ thuật thì call luôn qua skype, nếu có vấn đề hay sắp xảy ra vấn đề nào đó thì một số member cứng có thể đi công tác tới site cần hỗ trợ luôn và ngay được. Những việc kiểu như đêm nay họp thấy có vấn đề, vài member ngày mai bay đi site khác để trực tiếp support là việc bình thường. Tức là việc xử lý các vấn đề liên quan tới miscommunication rất nhanh và quyết liệt. Ngoài hệ thống chat của formal còn sử dụng các group chat trên skype để có thể nắm và xử lý tình hình ở bất cứ chỗ nào. Trên facebook cũng có group riêng cho dự án và bắt buộc tất cả các PM phải add member của dự án vào group này. Nếu member thấy có vấn đề hoặc các đề xuất cũng có thể đưa thẳng lên group để cùng thảo luận, tháo gỡ. Cũng có vài vụ member do không kiềm chế được đưa những ý kiến khá tiêu cực nhưng nhìn chung thì các group skype, facebook này đem lại những hiệu quả rất lớn trong việc kết nối và giúp mọi người hiểu nhau hơn. (tất nhiên sau khi dự án sang phase khác thì đã xóa bỏ các group này).

2. Transparency Mình sẽ nói về việc minh bạch và thực thi việc minh bạch hóa trong dự án như thế nào. Trước tiên việc minh bạch được thực hiện ở mức dự án bằng cách các số liệu hết sức rõ ràng và chính xác. Thường thì mỗi site có 1-2 người phụ trách việc này và thuộc PMO chứ ko phải dưới quyền của PM nên PM muốn che giấu số liệu hay tình hình tiến độ cũng không được. Bạn phụ trách việc này cả ngày chỉ lo đi lấy các số liệu để báo cáo tình hình một cách chính xác. Từ các báo cáo này có 1 người chuyên tổng hợp báo cáo từ các site để tạo thành báo cáo cho cả dự án. Từ báo cáo này sẽ tạo thành 1 báo cáo để gửi khách hàng. Số liệu từ các site đưa ra như thế nào thì sẽ đưa cho khách hàng đúng như thế. Như vậy tính minh bạch được thực hiện thông suốt từ phía offshore, onsite cho tới báo cáo với khách hàng. Sau đó các báo cáo này được đưa lên bản tin hàng ngày, như vậy tất cả các member, tất cả những người liên quan tới dự án đều thấy được tình hình hiện tại. Thoải mái trao đổi và đồng thời check chéo làm cho việc transparency được thực thi một cách triệt để giữa dev, quản lý, các sếp và cả khách hàng. Về phía khách hàng, họ còn thuê hẳn 1 team quản trị dự án cực kỳ chuyên nghiệp, nghe đồn chi phí gấp đôi cho 1 member onsite chúng tôi. Họ ngồi ở ngay cửa phòng, nên mỗi khi đi qua là lại thấy mấy bác chúi đầu vào cái màn hình to đùng với đủ các loại đồ thị và số liệu. Nên số liệu có vấn đề hay trình bày không logic là nhận ngay email hoặc các câu hỏi rất sắc trong các buổi họp tiến độ. Vì các thông tin được nhìn đa chiều như vậy nên tạo được báo cáo có tính minh bạch cao. Đồng thời các thông tin minh bạch cũng được truyền đạt tới tất cả những người liên quan một cách nhanh nhất qua công cụ Facebook.

3. Common team Yếu tố 1-communication và 2-transparency ở trên để giải quyết những vấn đề chung, những vấn đề về tiến độ, về scope... Nhưng còn những vấn đề liên quan tới technical thì cần 1 cách thức khác. Vì thế common team được thành lập, là những người có kinh nghiệm chinh chiến và rất giỏi về technical. Mục tiêu hoành tráng và có vẻ đúng đắn nhưng khi đưa vào thực hiện thì có rất nhiều vấn đề. Điển hình nhất là một số member có technical ngon trong 1 site không phục và không chịu thực hiện theo chỉ thị từ common team... Nhưng thực hiện theo kiểu quân lệnh như sơn-common team quyết định thì tất cả apply theo. Kết hợp với PM, TL tâm sự, lắng nghe anh em nhiều hơn để tìm cách giải quyết vấn đề thì dần dần việc triển khai team common cũng đi vào ổn định. Với kiểu dự án chạy song song giữa khâu development, và khâu hoàn thiện các phần middle ware, framwork và vẫn phải nhận những CR to liên quan tới logic thì team common sẽ giúp việc apply các CR phát sinh đỡ rủi ro hơn. Đặc biệt là hiện tượng degrade, lúc đầu khá hồn nhiên trong việc apply các version up của middle ware, framwork nên hiện tượng derage đã xảy ra khá thường xuyên nhưng sau đó team common đã dành thời gian phân tích kỹ hơn, apply thử..nên đã hạn chế được rất nhiều tình trạng degrade. Gọi là common team nhưng thực tế là core technical team. Team này cũng phát huy hiệu quả khi số lượng người mới join 1 team nhiều cần training, support nhiều về mặt kỹ thuật. Hay điều người từ common team đi cứu 1 team khác đang yếu về mặt kỹ thuật...Tuy team này phát huy được sức mạnh và có những đóng góp rất lớn nhưng do volume dự án lớn và chạy trong thời gian ngắn nên cũng không xử lý được triệt để tất cả các vấn đề liên quan tới kỹ thuật. Nhưng ngược lại nếu không có team này thì chắc chắn dự án 007 này không thể về đích đúng theo kế hoạch ban đầu được.

**II. Những khó khăn đã phải đối mặt

1. Khác nhau về văn hóa giữa các site** Dự án có 5 site, trong đó chỉ có 1site ở Cebu là nằm ở nước ngoài nhưng khi chạy thực tế thì phát sinh nhiều vấn đề liên quan tới văn hóa, cách làm việc ở các site. Site Cebu cực kỳ professional, từ câu Q&A hỏi khách hàng tới nội dung báo cáo, tinh thần làm việc máu lửa, sẵn sàng OT đến 23-24h, ở giai đoạn căng thẳng có bạn tester bị ngất phải vào bệnh viện cấp cứu, nhưng sau khi khỏe lại thì lập tức đòi đến công ty để làm việc tiếp. Nói chung chốt lại thì bọn Phi vẫn chuyên nghiệp hơn mình, năng suất cũng ngon hơn. Hai site ở Hà Nội làm việc cũng máu lửa, chấp nhận OT khi dự án bốc khói. Nhưng báo cáo rất hay có vấn đề, thỉnh thoảng lại có vụ số liệu báo cáo không chuẩn hay báo cáo tiến độ muộn. Nhưng nói chung 2site ở HN dần đóng vai trò quan trọng trong dự án vì có những member ngon về technical và cày trâu. Site ở HCM cũng có nhiều member cứng về technical nhưng sự thiếu máu lửa và quyết tâm làm cho tình hình tiến độ gần như lúc nào cũng bị chậm. Đôi khi một số member thiếu sự mềm dẻo nên cũng hay xảy ra vấn đề này vấn đề kia khi phải làm việc với các member của site khác. Vì vậy khi dự án vào phase 2 thì site HCM chỉ đươc giao một khối lượng nhỏ và không quá khó về mặt technical. Site Đà Nẵng, gồm rất nhiều người trẻ, khoảng 2/3 là những bạn sinh viên mới ra trường hoặc chuẩn bị tốt nghiệp. Mặc dù hơi yếu về technical nhưng bù lại bằng cách chịu khó hỏi, cầu thị và OT nhiều nên đã cover lại được mặc dù sau khi kết thúc phase 1 thì site ĐN bị trễ nhiều nhất. Team ĐN có sự chuyên nghiệp, nhiệt tình, báo cáo với số liệu thật, ko che giấu nên khi làm việc với team này ít mất thời gian để communicate nhất. Đúc rút lại là khi làm việc giữa các site khác nhau, sự khác nhau về văn hóa, hay sự chưa hiểu rõ cách làm, cách hành xử của nhau là không tránh khỏi. Việc đặt mình vào vị trí của đối phương, cố gắng mềm dẻo, cùng nghĩ về mục đích chung là những điều mọi người nên lưu tâm.

2. Chênh lệch về trình độ kỹ thuật giữa các site và quá nhiều member chưa có kinh nghiệm Sự chênh lệch về kinh nghiệm và trình độ kỹ thuật ở dự án có nhiều site là một vấn đề. Lúc đầu có đưa các bạn cứng đi ngồi ở các site support, training rồi có cả team common để hỗ trợ thêm. Có bạn từng ngồi ở 4site trong dự án tùy từng điểm. Lúc đầu là HCM rồi ra HN học về một số funtion mới, rồi sang Philipine để triển khai và làm cầu nối với các site ở VN, đến giai đoạn cuối thì sang Nhật fix bug. Việc đi onsite ở site khác 1-2tuần để chữa cháy là bình thường trong dự án. Nhưng cũng do volume lớn và có rất nhiều bạn mới hoặc sắp tốt nghiệp ĐH vào dự án nên vấn đề trình độ kỹ thuật có độ vênh giữa các site không được xử lý triệt để. Vấn đề không được xử lý triệt để nên ở giai đoạn fix bug là khổ và căng thẳng nhất, OT hàng ngày và OT cuối tuần liên tục diễn ra. Khách hàng claim liên tục vì degrade, vì main logic business không chạy được khiến team test của họ phải dừng lại… Trong khi đó các member trong dự án cũng mệt mỏi. Nhiều lúc tưởng như dự án sẽ cháy rực rõ. Nhưng cũng rất may mắn cùng với sự quyết tâm và bằng nhiều phương thức khác nhau dự án đã không bị cháy như nhiều người dự đoán lúc ban đầu. Nếu thu xếp được nhiều thời gian chuẩn bị hơn để training, để tìm nhiều người có kinh nghiệm hơn thì có lẽ giai đoạn fix bug đỡ vất hơn nhiều. Nhưng đây cũng là kinh nghiệm quý báu để thấy quá trình training kỹ càng và chuẩn bị kỹ là tiền đề giúp cho dự án thành công.

★★★★★★★★★★★★★ Một số thông số của Project 007:

• Chạy trong 6 tháng, volume hơn 2,000 MM. (Gần 500 người lúc peak time)
• Scope 90 funtions, 1150 screen.
• 5 site gồm HCM, ĐN, Hà Nội (2site), Cebu (Philippine)
• Làm việc trực tiếp với end user
• Team onsite ngồi tại văn phòng của khách hàng, pick time có 30 người.