Waterfall và Agile dưới góc độ thiết kế
Mô hình truyền thống ‘Waterfall’ – tức là giống thác nước chẩy từ nguồn đổ xuống dưới, 1 sản phẩm được phát triển xong xuôi thì chuyển sang xây dựng. Với Waterfall dân thiết kế chúng ta được thỏa sức đề xuất một phương án thiết kế. Nếu mọi thứ ổn thì giai đoạn xây dựng rất nhanh vì mọi thứ đã hoàn chỉnh. Những công ty làm xong xuôi thiết kế, xong gọi thầu đến đấu giá và trao gói xây dựng cho một đơn vị bên ngoài thực hiện là thuộc nhóm này. Người thiết kế cứ thiết kế, người xây cứ xây, xây xong có khi lại bàn giao cho một người khác quản lý.
Tuy vậy, lắm khi tới giai đoạn ‘xây nhà’, ý tưởng lại không khả thi, hoặc quá tốn phí. Cuối cùng đúng kiểu vẽ con hổ mà sản phẩm cuối thành ra con mèo rừng. Chưa kể là sản phẩm tới tay người dùng có khi lại đã trở nên lạc hậu vì thường tốc độ của Waterfall khá chậm.
“Làm cho xong tốt hơn là làm sao cho hoàn hảo” (“Done is better than Perfect’)
Agile là mô hình linh hoạt hơn, với sản phẩm tiến hóa dần cùng phương châm nằm lòng “Làm cho xong tốt hơn là làm sao cho hoàn hảo” (“Done is better than Perfect’). Vừa làm vừa sửa. Các nhóm tự bàn tự quyết, tự đưa ra mục tiêu thay vì nhận lệnh từ trên xuống. Với vị trí thiết kế, để làm tốt mảng thiết kế trong mô hình agile, thường bạn phải bao quát được các vòng phát triển và tổng thể của 1 tính năng. Ví dụ bạn thiết kế tính năng trả tiền. Hiện tại chỉ có 2 phương pháp thanh toán: khách hàng có thể trả bằng thẻ tín dụng, hoặc trả sau tại quầy. Nhưng trong tương lai khi những phương pháp tính tiền khác được kết hợp, ví dụ Paypal, Wechat, thiết lập trả tự động Direct debit thì giải pháp sẽ được thiết kế ra sao để khách hàng có thêm lựa chọn, mà giao diện người dùng đã quen không phải đập đi vẽ lại, đồng thời anh em coding không phải code lại từ đầu?
Khả năng có thể nhân rộng (scalability), và tính ’tiến hóa’ (incremental) là hai đặc điểm cơ bản của agile, và thật ra nó rất hợp với UX. Vì UX cũng vậy, trải nghiệm của khách hàng liên tục tăng dần đều. Mấy bạn thử mở web năm 2000 ra xem xem có ai còn thấy hài lòng không mặc dù hồi đó Microsoft cũng là đỉnh của chop :-))
Spotify model và câu chuyện Xây cầu
Nhắc đến Agile thì phải nhắc tới ‘Spotify model’ vì nhiều công ty tiến lên Agile học theo mô hình này.
Thoạt tiên, để mình kể chuyện xây cầu. Nếu giao cho các nhóm thiết kế và xây dựng 1 cây cầu thì nhóm nào sẽ dựng được cây cầu tốt nhất nhanh nhất?
Nhóm 1 toàn các anh chị làm Hành chính, các anh chị đương nhiên thiết kế ra 1 cây cầu chưa kịp đứng thì đã đổ. Nhóm thứ 2 gồm toàn các anh chị làm thợ xây, xây cực giỏi nhưng các anh lại cần có thiết kế mới xây được. Nhóm thứ 3 gồm toàn kiến trúc sư đỉnh của chóp, các anh cãi nhau tung tóe không ai đồng ý với thiết kế của ai nên chưa xong đoạn thiết kế thì đã vỡ tổ. Nhóm thứ 4 gồm toàn các anh CEOs hét ra lửa. Có điều không ai chịu làm lính thì lấy đâu ra sếp. Nhóm cuối cùng may sao lại có 1 cô CEO, 1 anh làm hành chính quản gia, 1 anh thiết kế và một cô kiến trúc sư. Nhóm cuối này thống nhất với nhau rất nhanh phương án thiết kế, cũng như yêu cầu kỹ thuật, chỗ nào cần quyết định thì cô CEO chốt, còn mọi việc hành chính dọn đường thì đã có anh quản gia chu đáo tin cậy lo.
Mô hình Spotify nổi tiếng nhờ nó chia vai trò và kỹ năng của thành viên thành các nhóm như nhóm xây cầu số 5 ở trên. Nhờ vậy các nhóm tự quyết và làm việc cùng nhau rất linh hoạt, hiệu quả (hàng dọc trong hình). Bên cạnh đó các bạn Hành chính, Kiến trúc sư, hay thiết kế…. sẽ nằm trong câu lạc bộ Hành chính riêng của họ (hàng ngang trong hình).
Chú thích: Mô hình Spotify rất hiệu quả nhờ tính linh hoạt và tự quản hàng dọc theo nhóm (squad, mỗi nhóm có đủ các kỹ năng cần) và sự quản lý kỹ năng theo chiều ngang – theo Chapter. (Nếu bạn không hiểu chapter thì đừng lo. Ít người hiểu lắm, mà cũng không quan trọng lắm ;-))
Đây là mô hình trong 5 năm vừa qua mình chứng kiến rất nhiều công ty ở Melbourne rùng mình thay đổi để hóa thân vào. Ào ào các nơi thành lập squad, chapter, tuyển scrum master… Quá trình tiến lên Agile ở các tập đoàn lớn thường mất vài năm. Có những tập đoàn ở Úc đây đã quá độ đi lên Agile hơn 2 năm rồi mà vẫn chưa ‘tiến hóa’ xong. Mà hành trình này lại không đi giật lùi được, đã tiến là chỉ có tiến lên thôi anh em ạ.
Lý thuyết thì nhiều, search phát ra cả đống nhưng nói chung Waterfall hay Agile kiểu Spotify đều đang tồn tại, và có cả những công ty nửa nọ nửa kia. Chưa kể còn có rất nhiều công ty tự nhận là agile nhưng lại làm việc theo kiểu chỉ đâu đánh đó, trên bảo dưới phải nghe của waterfall.
Chốt bài
Sự thông hiểu và kiến thức tổng hợp chỉ đạt được khi cùng làm việc với nhau.
Có một lần mình thiết kế useflow cho một hành trình fall out. Đây là hành trình xẩy ra khi người dùng gửi hồ sơ đăng ký dịch vụ. Nếu nhập sai một thông tin họ sẽ bị ‘fall out’ và không đăng ký được. Hiện tại gặp trường hợp như thế này nhân viên tổng đài phải gọi điện thoại cho từng khách hàng. Phần thiết kế UX mới nhằm giúp cho người dùng biết tình hình, thử lại, đồng thời họ có thể chủ động gọi cho tổng đài. Bạn backend đã cho mình một gợi ý tuyệt vời giúp cho khách hàng không cần phải điền lại toàn bộ thông tin mà chỉ cần điền duy nhất thông tin họ đã điền sai. Hệ thống sẽ tự tạo ra một bản copy và viết đè lên hồ sơ cũ. Nếu không nói chuyện với bạn ấy mình sẽ không biết là hệ thống có thể làm được điều đó. Và bạn đó cũng sẽ không biết để mà gợi ý.
Mình thích làm việc trong một nhóm Agile bởi vì mình có thể kiểm tra ngay lập tức tính khả quan của thiết kế; đồng thời mô hình agile giúp việc thông tin chia sẻ trong nhóm với nhau vô cùng hiệu quả. Thử hình dung, nếu theo waterfall, bạn tỉa tót bản thiết kế sửa nhà cho thật nét, xong đến lúc đưa cho thợ xây, họ mới bảo Cái này bọn anh chưa làm được em ơi. Hoặc để làm đúng như nầy thì mất 2 năm cơ. Trong khi đó với Agile, cả nhóm cùng ngồi bàn phương án với nhau. Chúng ta có thể quay sang anh thợ xây ngồi ngay bàn bên cạnh trình bầy ý tưởng xong hỏi anh ý luôn.
Với dân thiết kế những kiến thức toàn diện rất đáng quý. Có những giải pháp đến từ backend, và cũng có những giải pháp mà kỹ thuật thì tịt, nhưng lại có thể ‘xử lý’ thuận tình hợp lý nếu có content write viết ra nội dung thông minh, hợp lý. Làm việc cùng nhau khiến các bên hiểu được chuyên môn của nhau, học được từ nhau nhiều hơn. Điều này chúng ta làm việc cùng nhau nhịp nhàng ăn ý hơn nhiều:-)