Đặc biệt, đối với các hệ thống mà việc phát triển kéo dài, thì việc tổ chức các cuộc họp giải thích v.v trước khi bắt đầu để chia sẻ thông tin sẽ đem đến nhiều lợi ích. Chúng tôi xin phép được giới thiệu những nội dung cần chia sẻ vào giai đoạn này.
Để đảm bảo hệ thống hoàn thành đúng kỳ hạn thì cần phải làm rõ kế hoạch phát triển (bao gồm các milestone). Ngoài ra, cũng cần quyết định hình thức xác nhận tiến độ để theo dõi việc phát triển có đang tiến triển theo dự định hay không.
Tùy doanh nghiệp mà nội dung công việc, sản phẩm v.v của các công đoạn sẽ khác nhau. Nếu khi bắt đầu dự án, làm rõ được nội dung công việc của từng công đoạn thì sẽ có thể phòng tránh trước được những sai lệch trong các công đoạn.
Mục đích của việc này là để tiêu chuẩn hóa quy tắc đặt tên cho các loại tên sử dụng khi phát triển, hiểu rõ quy cách của kết quả của công đoạn phân tích yêu cầu/phân tích hệ thống và tạo ra được các sản phẩm ở các công đoạn sau đó một cách hiệu quả. Việc này rất có ích cho công ty phát triển offshore để đọc hiểu được tài liệu thiết kế được viết bằng những từ ngữ không quen và để tạo tài liệu thiết kế sau đó. Thêm vào đó, việc làm rõ trước quy tắc đặt tên/thuật ngữ đối với phía công ty phát triển offshore cũng nhằm đạt được những mục đích sau.
・Nâng cao mức độ lý giải tài liệu thiết kế mà phía ủy thác cung cấp
・Nâng cao chất lượng của công đoạn tạo tài liệu quy cách của công ty phát triển Offshore
・Sử dụng để kiểm tra khi nghiệm thu Phía ủy thác cũng có thể sử dụng khi lý giải, review tài liệu thiết kế mà có tình trạng dùng sai tiếng Nhật hoặc giải thích không đầy đủ.
Mục đích là để nâng cao chất lượng sản phẩm, nâng cao hiệu suất phát triển. Cụ thể thì phía công ty phát triển offshore thường sẽ có khuynh hướng như bên dưới, nên cần tránh những cách làm này.
・Copy & paste lại sample được cung cấp hay kết quả phát triển đã tạo ban đầu, sau đó chỉnh sửa lại và xem như là sản phẩm hoàn chỉnh.
・Kết quả của việc thiết kế và coding được thực hiện bằng cách copy&paste là sẽ tạo ra nhiều chức năng giống nhau mà lẽ ra có thể làm thành component chung/chức năng chung/module đa năng.
Trường hợp cần giao sản phẩm của phía công ty phát triển offshore cho khách hàng thì cần phải làm rõ mức độ mô tả các tài liệu. Đối với tài liệu thiết kế chi tiết, Q&A, tài liệu kết quả test (cần/không cần evidence, mức độ chi tiết) v.v, thì nếu chỉ định hình thức trước sẽ giảm được sự không đồng nhất, giảm được số giờ. Cả mức độ mong muốn mô tả đối với xử lý exception/xử lý lỗi cũng nên được đưa vào sample một cách thích hợp.
Cùng với việc làm rõ mức độ viết tài liệu, nếu làm rõ được mức độ chi tiết khi test sẽ phòng tránh được nhiều sai sót.
Vì nhiều lý do như kỳ hạn phát triển không đủ v.v, mà cũng có nhiều trường hợp ủy thác cho phía offshore ở trạng thái vẫn còn nhiều phần quy cách phía chưa xác định ở các công đoạn do phía Nhật Bản phụ trách như phân tích yêu cầu ~ phân tích hệ thống ~ thiết kế architect. Đối với phần chưa quyết định quy cách trong sản phẩm thì nếu truyền đạt rõ trước là chưa quyết định thì có thể phòng tránh được sự nhầm lẫn.
Mục đích của việc làm rõ thông tin môi trường phát triển, môi trường test, chẳng hạn như OS, Database, ngôn ngữ lập trình, framework, IDE, tool sử dụng, browser sử dụng, độ phân giải màn hình, thông tin version v.v là nhằm tránh phát sinh sai khác trong môi trường phát triển, môi trường test ở phía công ty phát triển offshore.
Việc sai khác nếu có sẽ dẫn đến thao tác làm lại. Trường hợp phát hiện càng trễ thì chi phí làm lại càng nhiều. Tình huống xấu nhất là không thể hoàn thành hệ thống đúng kỳ hạn.
Do đó, cần phải chia sẻ đầy đủ thông tin và chắc chắn công ty phát triển offshore đã nhận thức đúng.
Nếu có những quy dịnh phát triển như là coding convention v.v thì cũng cần làm rõ với phía công ty phát triển offshore sớm để tránh phát sinh thao tác làm lại.