Mar 28, 2020

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: viewed 08.02.2020 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ý luôn nhen, 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ó (as it 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 Storíe 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.

BA với trường hợp này dù có là technical BA (mình ko thích tên gọi này nhưng sẽ có bài chia sẻ quan điểm sau thì cũng nên quan tâm và capture thêm các yêu cầu người dùng (user stories) và thông tin chung về business process. Kinh nghiệm này của mình có lẽ tới từ tính cách cá nhân khi tiếp cận mọi vấn đề đều theo hướng top-down

Hik, viết một hồi giờ nhìn lại mới thấy mình viết dài quá, không biết có bạn nào đọc hết không? Các bạn biết thủ thuật skimming & scanning thì áp dụng nhé.

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.

Chia sẻ của chị Annia Trần - Biên tập nội dung bởi BAC

Click để đọc tiếp

Cách viết Prompt ChatGPT mang lại hiệu quả tối đa

Để có thể tận dụng tối đa sức mạnh từ các công cụ AI như ChatGPT, bạn cần học cách viết prompt. Bài viết này, BAC đã tổng hợp những cách viết Prompt ChatGPT hiệu quả mà ngay cả những người mới cũng có thể áp dụng, cùng tìm hiểu ngay nhé
8 Cách áp dụng API SaaS tăng doanh thu cho Business Analyst (Phần 2)

Một API trong mô hình SaaS có thể giúp gia tăng doanh thu bằng cách cung cấp cho khách hàng những tính năng bổ sung với mức giá hấp dẫn mà họ khó có thể từ chối. Trong bài viết này, BAC sẽ giúp các Business Analyst phân tích khái niệm “API được xem như là một sản phẩm độc lập” và chia sẻ một số ví dụ về các loại API trong SaaS có khả năng tạo ra doanh thu.
8 Cách áp dụng API SaaS tăng doanh thu cho Business Analyst (Phần 1)

Một API trong mô hình SaaS có thể giúp gia tăng doanh thu bằng cách cung cấp cho khách hàng những tính năng bổ sung với mức giá hấp dẫn mà họ khó có thể từ chối. Trong bài viết này, BAC sẽ giúp các Business Analyst phân tích khái niệm “API được xem như là một sản phẩm độc lập” và chia sẻ một số ví dụ về các loại API trong SaaS có khả năng tạo ra doanh thu.
Cách thúc đẩy khả năng giữ chân người dùng nhờ vào thiết kế UX SaaS

Thiết kế UX SaaS cho phép các Business Analysts tạo ra trải nghiệm người dùng hấp dẫn cho sản phẩm của mình. Nó giúp bạn giữ chân người dùng và chuyển đổi họ thành khách hàng trung thành. Nhờ đó, mà các BAers có thể giúp doanh nghiệp phát triển hơn trong từng dự án. Hãy cùng BAC tìm hiểu cách tiếp cận thiết kế UX SaaS một cách dễ dàng nhé!

Bình luận

Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +
Phạm Quế

Business Analyst

Khoá học Product Design của BAC đã cung cấp cho tôi nhiều kiến thức và nền tảng vô cùng hữu ích. Giảng viên giảng dạy rất nhiệt tình, truyền cho chúng tôi ngọn lửa đam mê và nhiệt huyết trong ngành. Đồng thời chia sẻ các kiến thức và kỹ năng cần thiết trong bài giảng một cách dễ hiểu hơn. Số lượng học viên không quá nhiều nên chất lượng giảng giạy vô cùng tốt. Giảng viên sửa bài tập 1-1 nên bài giảng sẽ chuyên sâu hơn.
Xem chi tiết +
Nguyễn Văn Long

Chuyên viên về chế độ kế toán & Giải pháp nghiệp vụ Tài chính kế toán trong ứng dụng CNTT - Tập đoàn Điện lực Việt Nam (EVN)

Tôi đã tham gia khóa Phân tích nghiệp vụ phần mềm cơ bản 3.0 tại BAC. Ở đây, tài liệu đào tạo cung cấp nhiều nội dung bổ ích và trình bày dễ hiểu. Giảng viên rất nhiệt tình, ngoài nội dung giảng dạy theo giáo trình còn chia sẻ nhiều kinh nghiệm thực tiễn, các câu hỏi của học viên đều được giải đáp ngay trên lớp và có minh họa từ các dự án trong thực tế. Sau tất cả, tôi cảm ơn BAC và Thầy giáo Thái Sơn.
Xem chi tiết +