Nhớ lại những năm đầu làm nghề, mình rất hay bối rối giữa những quy trình học được qua khoá học, qua các blog khác với quy trình thực tế trong công việc. Gần đây khi trải nghiệm qua đủ nhiều cũng như có được lượng kiến thức nhiều hơn mình mới bắt đầu phân biệt được process & workflow >> lí giải được tại sao quy trình thực tế có khi lại khác với những gì mình biết, mình học.

Process : hãy bắt đầu với process trước, vì đây là thứ quen thuộc nhất với chúng ta, ví dụ design thinking process, double diamond process. Process được sinh ra để tập hợp tất cả các hoạt động cần có để đạt được một mục tiêu cụ thể, nó bao gồm những quy tắc, guideline để đảm bảo hiệu quả công việc, thường thì nó có tính lặp lại & bao quát.

Workflow : cũng hao hao như process (nên mới dẫn đến việc thấy rối rối), cũng bao gồm các bước cần mình follow, nhưng điểm khác việc lớn ở đây là nó được mô tả dưới các công việc nhỏ & cụ thể, phải mô tả trách nhiệm và sự tham gia của các bên tham gia trong quá trình thực hiện. Ví dụ:

Workflow phê duyệt thiết kế:

Process là lý thuyết, là bức tranh lớn, là chuỗi mục tiêu cần có & workflow là các chi tiết cụ thể trong từng bước của process, nó tập trung vào cách hiện thực hoá mục tiêu của từng bước có trong process.

Ví dụ design thinking process bao gồm các bước: empathize > define > ideate > prototype > test. Tuy nhiên từng giai đoạn đó có nhiều bên involve vào, không nhất thiết designer phải làm hết, ví dụ: empathize sẽ cần team UXR handle chính, define sẽ gồm UXR, PO/PM, UXD cùng thảo luận và frame vấn đề, ideate sẽ do UXD & PO cùng brainstorm,…

Cụ thể hơn workflow cho mục đích empathize thì ta cần những activities như interview, collect user feedback, data analysis, chiến lược của công ty… ai sẽ làm hoạt động nào, cần trình bày và document đó ở đâu,…

Workflow có tính linh hoạt cao hơn, nó là cách tổ chức/ phòng ban định hình cách làm việc với nhau, workflow của một công ty 100 người sẽ khác hẳn với công ty start-up 10 người.

Cả mặt process, workflow nếu nhìn tổng quan đều được định hình bởi scope & trách nhiệm công việc của các nhân sự. Những đầu công việc này bị ảnh hưởng rất lớn bởi UX maturity (nói cách khác là mức độ quan tâm & đề cao giá trị UX trong doanh nghiệp đó), mức độ quan tâm càng lớn thì đầu việc càng nhiều & càng có impact.

Nên nếu bạn thấy những gì mình đọc, mình học, nó đang khác xa với process thực tế trong công ty bạn, nó có thể đến từng việc công ty đang hiểu và quan tâm đến UX ở level nào, nếu công ty càng đầu tư, thì process mới gần với các thứ mình được học.

Cách công ty tổ chức phòng ban, thiết kế đội ngũ sẽ tác động đến workflow của bạn.

Ví dụ:

Công ty A chia team theo dạng cụm phòng ban: PO riêng, designer riêng, dev riêng. PO sẽ chịu trách nhiệm hoạch định chiến lược sau đó lên kế hoạch, soạn brief cho team designer, dev để thực thi solution ấy. Có thể thấy cách chia này nhầm để các bên phối hợp với nhau theo dạng ghép nối các công việc chuyên môn theo từng project. Mảnh ghép ở đây là những phần việc chuyên môn của từng phòng ban.

Công ty B chia team theo dạng theo module, product / outcome-oriented , mảnh ghép ở đây là các module của một product.

Ví dụ: mỗi squad gồm PO, designer, dev, QC. Squad X lo về khía cạnh loyalty ; Squad Y lo về module “thanh toán”; Squad Z lo về “gamification”... Cách chia này khiến từng module, từng feature theme, và squad hoạt động như một công ty nhỏ, nên từng thành viên sẽ có cơ hội tham gia được các hoạt động trong process nhiều hơn >> tính ownership các thành viên rất cao, họ được hoạt động độc lập, họ sống & làm để tối ưu cho một mục tiêu cụ thể. Điều này giúp họ chuyên hoá cho một outcome nhất định. (Bạn có thể tìm hiểu thêm qua keyword: squad, Spotify model).

Tất nhiên mỗi cách đều có ưu nhược riêng.

Vậy nó tác động đến mình như thế nào?

Xem workflow nào hợp gu bạn hơn hoặc phục vụ cho hướng phát triển của bạn.