Back-office Centralization

Sau nhiều năm ở Chợ Tốt (chắc cũng phải gần hết thanh xuân), trải qua rất nhiều dự án lớn nhỏ, thì gần đây mình được sếp giao cho một dự án lớn nhất mình từng làm nếu chỉ xét về quy mô đó là Back-office Centralization. Dự án huy động gần như toàn bộ anh em engineers và products (~100 nhân sự) ở Chợ và thực hiện trong gần 4 quý. Nhân dịp cuối năm ngồi nhìn lại những gì đã làm, mình có vài dòng ở đây để chia sẻ với bạn về góc nhìn của bản thân cũng như những bài học rút ra khi đứng ở vai trò là tổng quản của dự án. Nếu có vô tình (hay hữu ý) đọc được bài viết này, mình hi vọng nó sẽ mang lại điều gì đó có giá trị cho bạn trong quá trình xây dựng các sản phẩm công nghệ hoặc nếu không thì hãy xem như đang ngồi nghe một người bạn trải lòng! Trong bài viết sẽ có những chỗ mình sử dụng tiếng anh, mong bạn thông cảm vì có những từ khi dịch ra tiếng việt nó sẽ mang hàm ý chưa tích cực hoặc là không diễn giải đúng thuật ngữ trong ngành IT.

Chợ Tốt tính đến 2023 đã tròn 10 năm. Sản phẩm dành cho người dùng không ngừng được cải tiến, tăng thêm về số lượng. Tuy nhiên hệ thống vận hành nội bộ (Back-office) vẫn được giữ nguyên kể từ khi công ty bắt đầu (2013). Hơn 100 modules nằm rải rác ở 6 hệ thống khác nhau, gây ra nhiều “nỗi đau” về mặt technical, product lẫn business. Việc tạo module mới tốn nhiều thời gian vì sử dụng công nghệ cũ. Các module chưa được phân quyền chặt chẽ, và gần như không thể audit. Lý do mà nó chưa được dọn dẹp bởi vì đây là phần “behind-the-scenes” của sản phẩm, người dùng sẽ không thấy, không trải nghiệm nó nên dù có xấu xí hay khó dùng đến đâu thì miễn còn đáp ứng được nhu cầu là vẫn còn được sử dụng. Nên như sếp mình nói, muốn giải quyết nó thì phải chờ "thời tới" - hay nói cách khác là cần hội đủ thiên thời, địa lợi, nhân hòa.

Thiên thời trước tiên là direction của công ty. Sau thời gian dài Chợ Tốt phát triển mạnh mẽ với nhiều sản phẩm được ra mắt để phục vụ người dùng, và bắt kịp sự phát triển của thị trường thì dịch covid đến gây ra nhịp chững lại của kinh tế. Đó cũng là lúc thích hợp để Chợ đi chậm lại và nhìn sâu hơn vào sản phẩm, vào hệ thống để cải thiện những điểm chưa được tối ưu cũng như củng cố những sản phẩm nền tảng. Định hướng này có thể giúp công ty ứng dụng “economy of scale” để đi nhanh, bền vững và hiệu quả hơn trong giai đoạn phát triển sắp tới. Địa lợi là các phần thiết yếu và quan trọng khác về mặt hệ thống của cả công ty đã hoàn thành như Cloud migration, 3-layer architecture. Nhân hòa là tech team đang có những cá nhân đủ giỏi về chuyên môn cũng như đầy nhiệt huyết để sẵn sàng tham gia vào các dự án, và thử thách mới.

Mong đợi ban đầu của management team là hoàn thành dự án này trong 2 quý cuối của năm 2023! Với kinh nghiệm đã từng làm dự án migration tương tự ở công ty cũ, và những thông tin mình đang nắm được về độ phức tạp của các hệ thống hiện tại thì cá nhân mình đánh giá đó là target khó! Với timeline đó sẽ đòi hỏi tất cả các team phải cùng thực hiện và đẩy 100% nguồn lực vào dự án, tuy vậy mọi người đều có các dự án riêng theo product plan của cả công ty để vẫn phải đảm bảo đạt được các KPI về doanh thu, lượng người dùng tăng trưởng... Đặt mục tiêu cao để đẩy mình đi đến giới hạn là một phương pháp tốt dành cho phát triển cá nhân. Nhưng với tổ chức, theo mình thì mục tiêu gần sát thực tế mới có thể giúp lên kế hoạch thực hiện và tự tin để triển khai. Sau khi thuyết phục sếp mình bằng nhiều hình thức khác nhau, và remind liên tục thì team cũng đã được approve để có một deadline ổn thoả nhất là migrate toàn bộ 96 modules trong 3 quý và đồng thời cũng tắt tất cả hệ thống cũ trước Q3/2024!

Mình và anh em trong team đều hiểu rằng để quá trình migration diễn ra mượt mà và hoàn thành đúng thời hạn thì khâu chuẩn bị là yếu tố then chốt, không thể qua loa. Team đã tốn 3 tháng để thực hiện 2 nhiệm vụ. Phía tech sẽ tiến hành build Back-office framework và chuẩn bị tài liệu hướng dẫn cũng như migrate mẫu một vài modules. Phía product sẽ tìm hiểu và nói chuyện với các team để ghi lại thông tin cần thiết cho mỗi modules và cuối cùng có được danh sách những module cần migrate cho mỗi team. Dù vậy cũng khó tránh khỏi có những điểm bị bỏ sót ở giai đoạn discovery, nên trong suốt quá trình migration mình vẫn có những meeting để quay lại giải quyết các điểm conflict này. Góc nhìn của mình ở đây là hãy luôn có một giai đoạn chuẩn bị thật cẩn thận và chi tiết nhất có thể, nhưng cũng hãy dự trù cho những điều mình chưa biết. Và nếu bạn có gặp vấn đề với những thứ chưa biết thì hãy vui vẻ chấp nhận để tìm cách giải quyết nó vì đó là chuyện bình thường. Điều kiện lý tưởng chắc chỉ có thể có trong phòng thí nghiệm mà thôi!

Tiếp theo, mình sẽ chia sẻ về cách quản lý timeline dự án, cách deal/align với các team và cách mình giải quyết những conflicts. Về công cụ, mình dùng Google Sheet để quản lý tiến độ dự án ở mức theo từng modules, còn chi tiết hơn như chia tasks, người thực hiện thì các team sẽ chủ động quản lý trong Jira board theo cách mọi người thường vẫn làm. Với mỗi row module trong file google sheet sẽ có 2 nhóm thông tin bắt buộc. Nhóm đầu tiên là module metadata gồm tên module, tên system, tech PIC (person in charge) và stakeholder - dùng để xác định tech team nào đang phụ trách migration và biz team nào sẽ phụ trách nghiệm thu. Khó khăn lớn nhất ở đây là nhiều module được build từ lâu hoặc được contribute bởi nhiều team, khiến việc xác định tech PIC và stakeholder trở nên phức tạp. Mình và product team đã mất 2 tháng để xác định tech PIC, stakeholder cho từng module và kiểm tra những module nào không còn được sử dụng. Nhóm thông tin thứ hai liên quan đến thời gian và tiến độ bao gồm start date, release date và status. Các team sẽ chủ động điền những đề xuất thông tin này tùy vào planning trong quý. Column status dùng để xác định module đang ở development hay testing phase, giúp việc phối hợp giữa tech team và biz team dễ dàng hơn, đồng thời cũng là một thông tin quan trọng giúp mình có cơ sở đi "dí" các bên liên quan 😉

Sẽ có một sheet tổng để quản lý tiến độ chung với các column cố định của 2 nhóm thông tin kể trên, và các sheet riêng cho từng team (được filter lại từ sheet tổng) để mọi người nắm tiến độ của team mình và thêm những column tùy chọn dựa vào nhu cầu. Các sheet này sẽ được sync với sheet tổng thông qua custom functions. Lý do mình tổ chức file như vậy là để kết hợp được cả các yêu cầu chung của dự án với những phần được tuỳ chỉnh riêng theo team. Điều này giúp các team chủ động hơn và mình cũng mong muốn mọi người sẽ cảm thấy bản thân là owner của project, thay vì chỉ làm với tâm thế là hỗ trợ team khác. Trade-off của việc này là mình cũng tốn kha khá thời gian để setup các custom functions. Cuối sheet tổng có một bảng thống kê nhỏ về tiến độ của các team. Trong các meeting catchup, mình đều remind mọi người xem qua bảng thống kê. Việc này tuy nhỏ và cũng không tốn nhiều thời gian nhưng nó lại giúp tất cả mọi người nắm progress chung và “feel” được rằng con thuyền của dự án đang di chuyển, tất cả chúng ta đều đang cầm một tay chèo. Và biết đâu nó cũng tạo động lực "ganh đua" ngầm giữa các team, thúc đẩy họ hoàn thành dự án sớm hơn 😊.

Mình vừa được công ty sponsor đi học khoá về middle manager và trong đó có một bài giảng nói về 8 chiến lược để thúc đẩy sự thay đổi (hoặc sự thành công). Ngẫm lại mình thấy rằng dù trước đó không biết những lý thuyết này nhưng dường như “vô tình” mình đã vận dụng một vài chiến lược trong dự án. Chiến lược đầu tiên là tạo bối cảnh khẩn cấp cho sự thay đổi. Trong các meeting giao tiếp với các team kể cả tech và biz, mình luôn tìm cách nhấn mạnh tầm quan trọng của dự án, deadline của dự án, và những thiệt hại nếu chúng ta không hoàn thành dự án đúng hạn. Cách này tỏ ra đặc biệt hiệu quả trong giai đoạn giữa và gần cuối dự án. Cá nhân mình quan sát thấy mọi người đều tập trung và “result oriented” hơn. Đội back-office contributors được thành lập với thành viên là engineers đến từ nhiều team khác nhau để đặt nền móng cho hệ thống mới. Và khi “tay đã nhúng chàm” thì anh em contributors cũng tự nguyện trở thành "đại sứ" cho dự án, trực tiếp hỗ trợ kỹ thuật cho các team trong quá trình migration thông qua kênh slack, gặp mặt trực tiếp, meeting. Đây là chiến lược thứ hai, thành lập đội dẫn đường để dẫn dắt sự thay đổi. Chiến lược thứ tư là giao tiếp để thấu hiểu và tạo sự tin tưởng. Với vai trò là tổng quản của dự án thì phải trên 50% thời gian là mình dành cho câu chuyện giao tiếp. Mình chọn cách meeting riêng rẽ với các team để nắm rõ context và expectation của mỗi bên trước khi có các meeting chung. Đối với team biz, mình thường sẽ hỏi về nhu cầu công việc của họ khi sử dụng Back-office ví dụ như công việc của anh sẽ ảnh hưởng thế nào nếu không có tính năng X ? Với team tech, mình sẽ hỏi về khó khăn của team trong quá trình migration, tình hình nguồn lực thế nào và có cần thêm sự hỗ trợ về nhân sự để bắt kịp tiến độ không ? Mình không chắc cách này có tạo được sự thấu hiểu hay tin tưởng với mọi người hay không (vì nó sẽ mang tính chủ quan) nhưng ít nhất những câu hỏi trên cũng giúp mình nắm được mong đợi của các team và giúp những mong đợi đó giao thoa nhiều nhất có thể!

Conflict giữa tech team và biz team đa phần sẽ đến từ việc chưa thống nhất hoặc có nhưng chưa đủ chi tiết về requirement của một tính năng. Và vì là hệ thống legacy nên cũng không có tài liệu để tham chiếu với phiên bản được xây dựng lúc đầu. Cách mình tiếp cận để giải quyết conflict dạng này là sẽ làm rõ minimum expectation của biz team về tính năng đó để đảm bảo các nghiệp vụ quan trọng vẫn được duy trì. Sau đó, mình trao đổi với tech team để giải thích mục đích của mỗi requirements và sắp xếp ưu tiên cho nó. Các minimum expectation sẽ được release trước để đảm bảo timeline dự án, còn các tính năng liên quan đến productivity sẽ đuợc release vào các đợt cải tiến tiếp sau khi migration. Mấu chốt ở đây là biz team sẽ thấy nhu cầu của họ được ghi nhận và sẽ được đáp ứng vào các mốc thời gian cụ thể, còn tech team sẽ thấy được khối lượng công việc là phù hợp với timeline đặt ra.

Sẵn tiện chia sẻ một chút về câu chuyện “thương thuyết” (negotiation), mình có đọc được cuốn "Một đời thương thuyết" của GS. Phan Văn Trường, xin được trích dẫn ở đây một câu của bác cá nhân mình thấy rất thích và đặt nó làm kim chỉ nam cho các cuộc nói chuyện “khó”.

Trong thương thuyết, “Biết người biết ta” là rất quan trọng và để thương thuyết thành công thì không bao giờ được phép quên nguyên tắc “WIN-WIN” đôi bên cùng có lợi.

“WIN-WIN” không mang ý nghĩa là chia đều lợi ích cho đôi bên, mà là khi bước vào một cuộc thương thuyết thì mong đợi và lợi ích của đối phương nên được ghi nhận và thậm chí là bàn đến trước cả mong đợi của bản thân. Cho dù không thể đáp ứng được 100% mong đợi đó, thì chỉ cần việc có thể bày tỏ cho đối phương biết rằng mình hiểu mong đợi của họ như thế nào thôi cũng đủ để tạo nên sự đồng cảm (hay chí ít là thiện cảm). Có nhiều cách để hiểu được mong đợi của người khác, trực tiếp hoặc gián tiếp nhưng theo mình cách đơn giản nhất (nhưng không phải dễ nhất) đó là gặp trực tiếp đối phương, đặt những câu hỏi mở và lắng nghe chủ động chia sẻ của họ. Những từ khoá mình nhắc đến ở trên là kĩ thuật được chia sẻ trong cuốn “Never split the difference” của tác giả Chris Voss. Nếu bạn là người yêu thích tìm hiểu về chủ đề tâm lý con người, hoặc chủ đề về đàm phán thì đây là cuốn sách mà bạn không nên bỏ qua.

Bài viết đã dài, tay cũng đã mỏi :D, mình xin phép khép lại bài viết với kết quả của dự án. Sau 3 tháng chuẩn bị và 9 tháng tiến hành migration, cuối cùng thì con thuyền Back-office centralization cũng đã về đích sớm trước hạn 5 ngày (25/06). Toàn bộ 96 modules đã được vận hành trên hệ thống Back-office mới, đồng thời 6 hệ thống legacy cũng đã được tắt. Tất cả các team cùng làm việc chung trên một hệ thống duy nhất. Và dĩ nhiên kết quả này không thể đến từ một cá nhân, mà chắc chắn phải đến từ một tập thể đã cùng phối hợp vận hành để đưa được con thuyền về đích!

Năm cũ gần qua, năm mới sắp đến, mong cho bạn sẽ luôn vững tâm bền trí trên con thuyền mà bạn đã chọn! Hẹn gặp bạn ở những bài viết trong tương lai, bye my friends!