LIFT & SHIFT là gì? Vai trò của BA đối với dự án Lift & Shift?

Trước khi chia sẻ với các bạn về những “đau thương" của BA khi làm một dự án lift & shift gần đây, mình cần phải nói rằng những chia sẻ này xuất phát từ kinh nghiệm cá nhân và các đồng nghiệp mình thường tương tác và thảo luận cùng trong suốt quá trình làm việc. Sẽ thật sự may mắn cho mình cũng như các thành viên khác của nhóm nếu chúng ta có thêm chia sẻ từ các bạn khác nữa. Con đường tới thành công của bất kì nghành nghề nào, vị trí nào, chuyên môn nào cũng không chỉ trải hoa hồng...phải không?

Thế nào là Lift & Shift?

Mình rất xin lỗi là không thể dịch sang tiếng VIệt cụm từ Lift & Shift cho chính xác, các bạn có thể tham khảo diễn giải này từ trang Web TechTarget:

“Lift and shift is a strategy for moving an application or operation from one environment to another without stopping to redesign the app or operations workflow”.

(Nguồn: https://whatis.techtarget.com/definition/lift-and-shift)

Lấy ví dụ đơn giản như sau:

Với một ứng dụng A (application) hay process ABC sẵn có và đã được phát triển và đi vào sử dụng cho một chi nhánh của doanh nghiệp, chủ doanh nghiệp muốn đem ứng dụng hay nền tàng này triển khai cho một chi nhánh khác trong doanh nghiệp, hoặc một môi trường mới.

Nếu có bạn nào làm triển khai ERP với các nền tảng sẵn có như SAP là có thể rất thuộc với khái niệm và dự án như thế này.

Vậy một dự án triển khai đồng hộ hoá hay di chuyển ứng dụng, quy trình hoặc môi trường nền tảng từ nhóm người dùng này sáng nhóm người dùng khác, hay từ đơn vị này sang đơn vị khác của doanh nghiệp,...và tối thiểu hoá thay đổi có thể được “găm" vô chung một dạng này.

BA thì làm gì?

Đối với BA, theo chủ quan của mình, đi đâu, làm dự án nào thì vài trò của họ quan trọng nhất nằm ở việc giao tiếp, kết nối và chuyển đổi thông tin từ mục tiêu doanh nghiệp thành tác vụ cụ thể để đội phát triển có thể thực thi và ước lượng công việc, cũng như hướng ngược lại. Để đảm bảo được giao tiếp (communications) thông suốt thì không thể chỉ nghe người này nói và truyền đạt lại mà phải vận dụng các kĩ thuật phân tích yêu cầu, chuyển đổi và xây dựng roadmap cho các requirements của mình nữa. Và với BA thì một công cụ giao tiếp rất quan trọng đó chính là tài liệu dự án.

Điểm khác nhau ở các dự án là với mỗi dự án, mục tiêu khác nhau, cách triển khai khác nhau, và khả năng kết nối giữa stakeholders và đội phát triển khác nhau thì BA sẽ từ đó mà có định hướng tiếp cận và hoàn thành vai trò cầu nối của mình.

Đau thương đầu tiên: Không có Product Roadmap

Việc làm BA cho một đơn vị thực hiện tư vấn giải pháp khiến mình có thói quen tiếp cận top-down. Tức là với mỗi dự án thì mình đều đặt câu hỏi như: Business Case là gì, mục tiêu dự án/sản phẩm nhằm giải quyết bài toán gì hay nhằm đạt được cơ hội gì, các thành phần liên quan đã và đang tham gia, và quan trọng nhất là có product roadmap không…? Các thông tin này giúp mình nhìn được bức tranh toàn cảnh của dự án hay sản phẩm để từ đó có cách tiếp cận và quản lý yêu cầu từ cao đến thấp và giúp mình map được các requirements vào mục tiêu dự án hay sản phẩm nhằm mục đích đảm bảo delivery yêu cầu đúng và hiệu quả.

Khi không có Product Roadmap thì BA phải tự xây dựng và mất rất nhiều thời gian để tìm kiếm thông tin từ các stakeholders để nắm được cốt lõi vấn đề. Bên cạnh đó, nếu BA kiêm nhiệm nhiều vai trò khác như Scrum Master hay Iteration Manager thì càng khó để có thời gian làm điều này. Dẫn đến requirement phát triển cục bộ và chỉ có thể chạy theo yêu cầu nhận được từ PO/Stakeholders mà không...kịp phân tích thấu đáo. Rủi ro của việc thiếu phân tích là với các thay đổi xảy ra trong quá trình thực hiện chúng ta dễ lơ là việc phân tích ảnh hưởng tới các bên liên quan, kể cả business lẫn technical stakeholders. Rủi ro này lại không nhỏ với các dự án quy mô enterprise intergration khi các bạn BA tham gia phải kết nối nhiều ứng dụng, nhiều môi trường với nhau để đảm bảo thông tin được đồng bộ.

Đau thương tiếp theo: Sử dụng confluences để làm documents nhưng ko có structure / templates

Các bạn có thể phản biện rằng Agile thì không cần hoặc hạn chế viết documents. Nhưng mình lại cho rằng quan điểm này không chính xác. Từ đầu mình có nhắc tới việc BA (nhất là BA Lead) khi tiếp cận dự án mới đều cần nghiên cứu và có hướng tiếp cận hợp lý. Với mảng enterprise integration mình làm thì dùng tools nào viết requirements cũng được, excel cũng vẫn được dùng rất triệt để cho các BA tự quản lý, nhưng quan trọng là có structure/template chung. Ví dụ bạn dùng User Stories để giao tiếp với business side và triển khai Use Case cho technical side. Vì life and shift nên các screenshot của ứng dụng đang có (khảo sát hiện trạng as-is) rất hữu ích và tiết kiệm công sức cho BA trong việc mô tả chi tiết yêu cầu...Vậy nên khi thống nhất cách viết và hướng trình bày thì BA có thể đưa screenshot vào template của mình.

Khi không có structure và template thì mỗi người một kiểu, Architect họ chỉ cần làm sequence diagram, Tech Lead chỉ cần APIs pattern,... BA của nhóm này viết User Stories rồi giải thích thêm (narratives), BA nhóm khác sẽ viết User Storie rồi thêm API payload sample... Dẫn tới việc họp dự án mất rất nhiều thời gian giải thích cho nhau hiểu đồng thời khó kiểm tra được impact của các thay đổi khi xảy ra. Tưởng không nhiều công sức viết tài liệu nhưng khi có thay đổi hay khi cần thay đổi thì công sức bỏ ra để update tài liệu cho đúng và khớp nhau là... không hề nhỏ.

Đau thương lần nữa: Không cần có user stories mà chỉ cần chú ý tới backend tasks khi muốn triển khai ứng dụng cho nhóm người dùng mới.

Điển hình với các dự án lift & shift đôi khi mình gặp đau thương ở khâu ít lường tới nhất là đây. Tức là với nền tảng đã có, ứng dụng chạy băng băng bao năm với chi nhánh X, giờ PO muốn triển khai cho chi nhánh Y để đồng bộ hoá dự liệu và đảm bảo KPI giữa các chi nhánh. Tuy nhiên chi nhánh Y dù chung một doanh nghiệp thì vẫn chịu ảnh hướng nhiều từ thói quen người dùng, phân khúc khách hàng, quy định pháp luật địa phương với domain của doanh nghiệp (ví dụ: Tuy cùng là các chi nhánh của 1 tập đoàn bảo hiểm đa quốc gia, nhưng chính sách bảo hiểm của mỗi quốc gia lại khác nhau…) Nên nếu chỉ tập trung vào các thay đổi cần có của ứng dụng để phù hợp môi trường cơ sở hạ tầng tại chi nhánh mới mà bỏ qua các yếu tố người dùng địa phương thì rất dễ dẫn tới việc người dùng không chấp nhận sản phẩm được shift qua hoặc các thay đổi cần thiết không được phân tích ngay từ đầu. Những trường hợp như thế này thường dễ đẩy dự án vào tình trạng kéo dài, hoặc thay đổi scope trong giai đoạn phát triển.