Bản đồ năng lực Yeowubie Software Labs: web, mobile và phần mềm nội bộ
Khi một doanh nghiệp tìm đội phát triển bên ngoài, câu hỏi thật sự không phải là "công ty này giỏi không". Câu hỏi đúng hơn là "việc của tôi rơi vào vùng họ làm tốt, hay rơi ra ngoài rìa". Bài viết này vẽ lại bản đồ năng lực của Software Labs thuộc Yeowubie theo đúng cách đó: ba mảng công việc, mỗi mảng nói rõ làm được đến đâu, và quan trọng không kém, dừng ở đâu. Software Labs là tên gọi nội bộ cho mảng phát triển phần mềm chuyên nghiệp của công ty, không phải một thương hiệu riêng.
Ba mảng công việc trong một đội nhóm
Software Labs làm ba nhóm việc: website cho doanh nghiệp, ứng dụng mobile, và phần mềm dùng trong nội bộ công ty. Ba mảng này chia sẻ chung một lõi kỹ thuật, nên một dự án có thể bắt đầu ở mảng này rồi mở sang mảng khác mà không phải đổi đội. Đó là ý nghĩa của chữ full-stack ở đây: không phải "biết mọi thứ", mà là một đội có thể đi từ giao diện đến dữ liệu trong cùng một dòng công việc.
Cách hữu ích để hình dung là đặt ba mảng lên cùng một trục. Trục đó là khoảng cách từ người dùng cuối đến hệ thống bên trong. Website đứng gần khách hàng bên ngoài nhất: ai cũng nhìn thấy, nên hình thức và tốc độ tải quan trọng. Ứng dụng mobile đi sâu hơn một bước, gắn với thiết bị và thói quen dùng hằng ngày. Phần mềm nội bộ nằm ở đầu kia, ít người thấy nhưng chạm trực tiếp vào quy trình làm việc của nhân viên.
Điểm mạnh của việc gom ba mảng vào một đội nằm ở phần nối. Một cửa hàng có website bán hàng, một app cho khách quen, và một công cụ quản lý đơn nội bộ thường phải nói chuyện với nhau qua cùng một kho dữ liệu. Khi cùng một đội phụ trách, phần nối đó không rơi vào khoảng trống giữa hai nhà thầu. Đây là lý do nhiều doanh nghiệp vừa và nhỏ chọn một đầu mối thay vì chia nhỏ.
Tất nhiên gom lại không có nghĩa là mọi việc đều phù hợp. Một dự án rất lớn, nhiều chục người làm song song trong nhiều năm, không phải sân chơi của một đội nhỏ. Bản đồ này vẽ ra để bạn đặt đúng việc vào đúng chỗ.
Phát triển web: giao đến đâu là hợp lý
Mảng web nhận trọn vẹn từ trang giới thiệu doanh nghiệp, landing page chiến dịch, đến hệ thống có quản trị nội dung và tài khoản người dùng. Nói gọn: nếu đó là một website hoặc ứng dụng web mà một doanh nghiệp vừa và nhỏ thực sự cần để vận hành, phần lớn rơi vào vùng làm được. Giới hạn thật nằm ở quy mô cực lớn và yêu cầu hạ tầng đặc thù, chứ không nằm ở loại trang.
Trong thực tế, các dự án web thường chia thành vài lớp. Lớp đầu là trang trình bày: giới thiệu công ty, sản phẩm, tin tức. Lớp này nhanh và rõ ràng, giá trị chính nằm ở thiết kế sạch và tốc độ. Lớp thứ hai là trang có nội dung động: blog, danh mục sản phẩm, trang đa ngôn ngữ. Ở đây bắt đầu cần một hệ quản trị nội dung để người không biết kỹ thuật vẫn tự cập nhật được. Lớp thứ ba là ứng dụng web có đăng nhập, có vai trò người dùng, có dữ liệu lưu lại theo thời gian, ví dụ trang đặt lịch, cổng khách hàng, hay bảng điều khiển quản trị.
Việc giao web cho một đội bên ngoài hợp lý nhất khi yêu cầu được mô tả bằng kết quả mong muốn, không phải bằng công nghệ cụ thể. "Tôi cần khách điền form và đội bán hàng nhận thông báo ngay" là một yêu cầu tốt. "Tôi cần dùng đúng framework X" thường là quyết định nên để cho đội kỹ thuật đề xuất, trừ khi bạn có ràng buộc thật từ hệ thống cũ.
Có một vùng cần nói thẳng. Hiệu năng cho lượng truy cập rất lớn, ví dụ một sàn thương mại điện tử quy mô quốc gia với hàng triệu lượt mỗi ngày, là bài toán hạ tầng riêng, đòi hỏi cam kết vận hành dài hạn và đội trực hệ thống. Một đội phát triển vừa làm được phần dựng và phần đầu của quy mô đó, nhưng vận hành ở đỉnh tải cao nhất là câu chuyện cần thảo luận từ đầu.
Ứng dụng mobile: ranh giới giữa tự làm và phát hành qua bản địa
Mảng mobile dựng được ứng dụng cho cả hai hệ điều hành phổ biến, từ thiết kế màn hình đến kết nối dữ liệu phía sau. Ranh giới cần phân biệt không nằm ở việc viết app, mà nằm ở việc đưa app ra thị trường và thu tiền. Ở Việt Nam, một số mô hình thu phí trực tiếp qua cửa hàng ứng dụng có rào cản pháp lý và thanh toán riêng, nên phần phát hành đôi khi đi qua một đối tác bản địa.
Phần xây dựng app khá thẳng. Một ứng dụng thường gồm các màn hình, một lớp đăng nhập, kết nối tới máy chủ để lấy và lưu dữ liệu, và đôi khi tính năng như thông báo đẩy hay bản đồ. Nếu app của bạn nằm trong nhóm này, nó là việc dựng được trong một chu kỳ rõ ràng. Việc khó hơn không phải mã nguồn, mà là quyết định phạm vi: một app cố làm mọi thứ trong phiên bản đầu thường trễ và đắt. Bắt đầu hẹp rồi mở rộng là cách an toàn hơn nhiều.
Điểm cần hiểu rõ là khâu vận hành thương mại. Khi một ứng dụng cần tính phí người dùng đều đặn, hoặc xử lý dòng tiền trong nước, chủ thể đứng tên thu tiền và chịu trách nhiệm pháp lý thường không phải đội phát triển. Mô hình thực tế hay dùng là đội phát triển phụ trách phần kỹ thuật, còn một đơn vị bản địa hoặc một cá nhân kinh doanh đứng ra làm chủ thể thu phí và chia sẻ doanh thu. Đây không phải hạn chế năng lực kỹ thuật, mà là cấu trúc kinh doanh để tuân thủ quy định địa phương.
Vì vậy, khi cân nhắc giao một app, câu hỏi nên hỏi sớm là: ai sẽ đứng tên trên cửa hàng ứng dụng, ai thu tiền, và dòng tiền chảy qua đâu. Trả lời ba câu này từ đầu giúp tránh tình huống app đã xong về kỹ thuật nhưng chưa thể phát hành vì vướng mô hình thu phí. Phần kỹ thuật và phần phát hành nên được lên kế hoạch song song.
Phần mềm nội bộ: công cụ chạy bên trong công ty
Mảng phần mềm nội bộ làm những công cụ mà nhân viên dùng để vận hành, không phải khách hàng bên ngoài thấy: hệ thống quản lý đơn hàng, bảng theo dõi công việc, công cụ tính toán nội bộ, cổng nhập liệu. Đây thường là mảng bị xem nhẹ nhưng mang lại lợi ích rõ nhất, vì nó thay thế những bảng tính thủ công và các bước làm bằng tay đang ngốn thời gian mỗi ngày.
Đặc điểm của phần mềm nội bộ là nó phải khớp với cách công ty thực sự làm việc, không phải cách một mẫu chung giả định. Một công cụ quản lý đơn cho tiệm bánh khác với công cụ cho xưởng cơ khí, dù cả hai đều gọi là "quản lý đơn". Vì thế phần quan trọng nhất của loại dự án này không phải lập trình, mà là giai đoạn đầu ngồi xuống ghi lại quy trình hiện tại: bước nào đang làm thủ công, chỗ nào hay sai sót, ai chịu trách nhiệm khâu nào.
Lợi ích của việc dùng cùng một đội cho cả ba mảng hiện rõ nhất ở đây. Khi công cụ nội bộ cần lấy dữ liệu từ website bán hàng, hoặc đẩy thông tin sang app cho khách, phần kết nối đã nằm trong tầm tay của đội. Doanh nghiệp không phải làm trung gian giải thích giữa hai nhà thầu không quen hệ thống của nhau. Đây là phần tiết kiệm âm thầm nhưng đáng kể về thời gian quản lý.
Giới hạn cần nói thật cũng nằm ở đây. Một số phần mềm nội bộ thuộc loại đặc thù ngành sâu, ví dụ hệ thống kế toán đầy đủ tuân thủ chuẩn báo cáo, hay phần mềm có yêu cầu chứng nhận riêng theo lĩnh vực. Với những trường hợp đó, dùng một sản phẩm sẵn có đã được kiểm chứng thường hợp lý hơn là tự dựng từ đầu. Một đội phát triển tốt sẽ nói cho bạn biết khi nào nên mua thay vì xây, chứ không nhận mọi việc chỉ để có việc.
Trước khi giao việc: vài giới hạn và điều kiện hợp tác
Trước khi giao bất kỳ dự án nào, ba điều đáng làm rõ là: phạm vi thực tế của phiên bản đầu, ai là người ra quyết định bên phía bạn, và việc bảo trì sau khi bàn giao diễn ra thế nào. Một đội nhỏ làm tốt khi phạm vi rõ và người quyết định ổn định; nó gặp khó khi yêu cầu thay đổi liên tục hoặc khi không ai bên phía khách chốt được quyết định.
Giới hạn đầu tiên là quy mô đội. Một đội phát triển tinh gọn không phải một công ty vài trăm người. Điều đó có nghĩa là không thể chạy mười dự án lớn cùng lúc, và những dự án đòi hỏi đội trực hệ thống suốt ngày đêm cần được bàn riêng về điều kiện vận hành. Đổi lại, đội nhỏ giao tiếp trực tiếp hơn, ít tầng trung gian, và người làm thật sự là người bạn nói chuyện. Với phần lớn dự án doanh nghiệp vừa và nhỏ, đây là sự đánh đổi có lợi.
Giới hạn thứ hai là về dữ liệu và sở hữu. Cần thống nhất từ đầu ai sở hữu mã nguồn sau khi bàn giao, dữ liệu được lưu ở đâu, và bạn có thể tự vận hành tiếp hay phụ thuộc vào đội phát triển. Một hợp tác lành mạnh là hợp tác mà bạn không bị khóa chặt: bạn nên có quyền lấy lại mã và dữ liệu của mình. Hãy hỏi thẳng điều này trước khi ký, không phải sau khi xong.
Điều kiện hợp tác cuối cùng là nhịp làm việc. Phát triển phần mềm tốt cần phản hồi đều đặn từ phía khách, không phải giao đề bài rồi biến mất ba tháng. Những dự án thành công thường có một người bên phía khách dành thời gian xem bản thử, trả lời câu hỏi, và quyết định nhanh khi cần. Nếu bạn chuẩn bị được vai trò này, phần lớn rủi ro của một dự án thuê ngoài đã được giải quyết trước khi viết dòng mã đầu tiên. Bản đồ năng lực chỉ cho biết việc gì làm được; còn việc đó có chạy tốt hay không phụ thuộc nhiều vào sự rõ ràng giữa hai bên.
