Một tình huống rất hay gặp: doanh nghiệp có một phần mềm đang chạy hằng ngày (website bán hàng, phần mềm quản lý đơn, công cụ nội bộ) do một lập trình viên hoặc một đội bên ngoài làm ra. Rồi người đó nghỉ việc, đội đó ngừng hợp tác. Phần mềm vẫn chạy, cho tới ngày cần sửa một lỗi, thêm một báo cáo, hay gia hạn máy chủ, thì mới phát hiện không còn ai hiểu nó, và không ai biết mật khẩu nằm ở đâu.
Thuê một đội mới để tiếp quản là lựa chọn hợp lý. Nhưng tiếp quản một phần mềm có sẵn khác với làm mới từ đầu: đội mới phải hiểu những gì người khác đã làm, thường là không có tài liệu, trong khi phần mềm vẫn phải phục vụ khách hàng mỗi ngày. Làm đúng thứ tự thì việc chuyển giao diễn ra êm; làm vội thì dễ rơi vào cảnh sửa một chỗ hỏng ba chỗ.
Việc đầu tiên: thu về những thứ đang nằm trong tay người cũ
Trước khi tìm đội mới, hãy kiểm tra doanh nghiệp đang thật sự nắm những gì. Rất nhiều trường hợp, tài khoản quan trọng được đăng ký bằng email cá nhân của lập trình viên cũ, và chỉ người đó vào được.
Danh sách nên thu về, càng sớm càng tốt, khi người cũ còn liên lạc được:
- Mã nguồn, bản mới nhất, đúng với bản đang chạy thật. Tốt nhất là cả kho mã (repository) kèm lịch sử thay đổi, không chỉ một file nén.
- Máy chủ và hosting: tài khoản quản trị, nơi thanh toán, ngày gia hạn.
- Tên miền: tài khoản tại nhà đăng ký và nơi quản lý cấu hình tên miền.
- Cơ sở dữ liệu và bản sao lưu: sao lưu có đang chạy không, lưu ở đâu, đã ai thử khôi phục chưa.
- Tài khoản dịch vụ bên ngoài mà phần mềm dùng: gửi email, cổng thanh toán, tin nhắn, bản đồ, cửa hàng ứng dụng…
- Tài liệu và mật khẩu quản trị: cách cài đặt, cách đưa bản mới lên chạy, những lưu ý người cũ biết mà chưa ghi ra.
Với mỗi tài khoản, mục tiêu là chuyển sang đứng tên doanh nghiệp, rồi mới cấp quyền cho người làm kỹ thuật. Việc này chỉ cần người quản lý làm, không cần biết lập trình. Nếu người cũ không còn liên lạc được, hãy liệt kê những gì đang thiếu; đội mới sẽ cần biết điều đó ngay từ buổi trao đổi đầu tiên.
Tiếp quản theo bốn bước, đừng sửa ngay
Áp lực thường là "có lỗi đang cần sửa gấp". Nhưng một đội vừa nhận phần mềm mà lao vào sửa ngay trên bản đang chạy thật là cách nhanh nhất để gây thêm sự cố.
1. Thu quyền truy cập. Như phần trên. Đội mới nhận quyền từ tài khoản của doanh nghiệp, không nhận lại tài khoản cá nhân của người cũ.
2. Dựng lại được một bản chạy thử. Đây là phép thử quan trọng nhất: từ mã nguồn bạn đang giữ, đội mới có dựng lại được một bản phần mềm chạy giống bản thật hay không, trên môi trường riêng, không đụng vào dữ liệu khách hàng. Nếu không dựng lại được, nghĩa là mã nguồn bạn có chưa phải bản đang chạy, hoặc còn thiếu một mảnh nào đó. Biết điều này sớm tốt hơn nhiều so với phát hiện ra khi đang sửa lỗi gấp.
3. Đánh giá và lập danh sách rủi ro. Đội mới đọc mã, xem phần mềm dùng công nghệ gì, phiên bản nào đã cũ, chỗ nào dễ vỡ, chỗ nào thiếu sao lưu. Kết quả bạn nên nhận là một danh sách viết bằng ngôn ngữ dễ hiểu: vấn đề gì, ảnh hưởng gì tới việc kinh doanh, nên xử lý trước hay sau.
4. Bắt đầu bằng việc nhỏ. Việc đầu tiên giao cho đội mới nên là một thay đổi nhỏ, ít rủi ro: sửa một lỗi hiển thị, thêm một cột vào báo cáo. Mục đích là để đội đi trọn một vòng (sửa, thử, đưa lên bản thật) và để bạn thấy cách đội làm việc trước khi giao những phần quan trọng.
Câu hỏi nên hỏi đội tiếp quản
Khi trao đổi với đội thuê ngoài, ngoài giá và thời gian, hãy hỏi thêm:
- Đội đã làm việc với công nghệ của phần mềm này chưa, ở mức nào? Phần mềm cũ có thể viết bằng công nghệ đội mới ít dùng. Một đội nghiêm túc sẽ nói thẳng mức kinh nghiệm thực tế, thay vì nhận hết.
- Trước khi sửa, đội cần bao lâu để tìm hiểu, và kết quả của giai đoạn đó là gì? Bạn muốn nhận được danh sách rủi ro và xác nhận đã dựng lại được bản chạy thử, không chỉ một lời "đã nắm được".
- Đội ghi lại những gì mình tìm hiểu được ở đâu? Tài liệu đội mới viết ra trong lúc tiếp quản là thứ bạn nên giữ, để lần sau đổi người không phải bắt đầu lại.
- Mã nguồn sẽ nằm ở đâu trong lúc làm? Câu trả lời tốt nhất là trên kho mã đứng tên doanh nghiệp.
Sửa dần hay viết lại từ đầu?
Đội mới nhìn mã cũ thường thấy nhiều chỗ chưa ưng, và đề xuất viết lại là chuyện dễ hiểu. Nhưng viết lại một phần mềm đang chạy là quyết định lớn: phần mềm cũ, dù rối, đang chứa rất nhiều quy tắc nghiệp vụ mà không ai ghi ra, và bản viết lại phải làm đúng tất cả những quy tắc đó trước khi thay được bản cũ.
Một cách nghĩ thực tế:
- Nên sửa dần khi phần mềm vẫn đáp ứng công việc hằng ngày, vấn đề chủ yếu là thiếu tài liệu, mã khó đọc, vài lỗi lặt vặt. Mỗi lần sửa, đội dọn lại khu vực mình đụng vào.
- Mới nên tính chuyện viết lại khi danh sách rủi ro cho thấy vấn đề nằm ở nền móng: công nghệ đã ngừng được hỗ trợ và có lỗ hổng bảo mật, hoặc cách tổ chức dữ liệu không còn đáp ứng được cách doanh nghiệp đang làm việc. Ngay cả khi đó, thay từng phần một thường an toàn hơn thay toàn bộ trong một lần.
Quyết định này nên dựa trên danh sách rủi ro ở bước 3, không dựa trên cảm giác "mã cũ xấu quá".
Để lần sau không rơi lại vào tình huống này
Khi đã tiếp quản xong, hãy giữ vài nguyên tắc để lần sau đổi người hay đổi đội không phải bắt đầu lại:
- Mọi tài khoản kỹ thuật đứng tên doanh nghiệp, người làm kỹ thuật chỉ được cấp quyền.
- Mã nguồn nằm trên kho của doanh nghiệp, cập nhật liên tục, không chỉ bàn giao vào ngày cuối.
- Có tài liệu tối thiểu: cách dựng bản chạy thử, cách đưa bản mới lên chạy, sao lưu nằm ở đâu.
- Thỉnh thoảng thử khôi phục từ bản sao lưu, để chắc rằng nó dùng được khi cần.
Cách HD Web Services làm
Khi nhận outsourcing, đội của chúng tôi chủ yếu làm với React/Next.js, Vue/Nuxt.js, .NET, Flutter, NestJS, GraphQL và PostgreSQL, triển khai bằng Docker, dùng Cloudflare. Với công nghệ khác, chúng tôi nói rõ mức kinh nghiệm thực tế trước khi nhận việc. Đội làm việc trực tiếp trên kho mã của bạn, hoặc bàn giao định kỳ nếu dùng kho của chúng tôi; làm theo sprint, demo cuối mỗi sprint và gửi báo cáo hằng tuần gồm việc đã xong, việc đang làm và rủi ro cần bạn quyết định. Thoả thuận bảo mật (NDA) được ký trước khi trao đổi chi tiết dự án.
Nếu bạn đang có một phần mềm cần người tiếp quản, đọc thêm bài kiểm soát chất lượng khi thuê ngoài lập trình, hoặc kể cho chúng tôi nghe phần mềm đó đang chạy ra sao và bạn đang nắm được những gì.