Đã bao giờ doanh nghiệp bạn gặp một vấn đề nhưng không biết bắt đầu thế nào để có thể giải quyết nó? Làm thế nào để các doanh nghiệp tìm ra và hóa giải các vấn đề mình gặp phải? Cách thức chính là G Process - một khái niệm không thể thiếu trong từ điển của Got It - công ty đã sáng tạo ra quy trình này.
G Process là gì?
G viết tắt cho Gating hoặc “Getting It Done” - hoàn thành công việc. G Process là quy trình gồm 10 bước từ G1 đến G10 giúp mọi người có thể hoàn thành công việc của mình một cách nhanh gọn, hiệu quả nhất.
G Process dựa trên phương pháp nào?
Đây là quy trình được đúc kết, chỉnh sửa từ chính kinh nghiệm của Got It trong suốt quá trình phát triển sản phẩm và vận hành các hoạt động kinh doanh. Phương pháp “made by Got It” này kết hợp với DNA của công ty là Data-Driven giúp giải quyết vấn đề bằng cách chứng minh:
- Vấn đề được đưa ra là quan trọng và cần được giải quyết (hay còn gọi là chọn “right problem to solve”)
- Giải pháp cho vấn đề đó được lựa chọn phát triển một cách hiệu quả (effectively developed)
- Đo lường được ảnh hưởng của vấn đề tới các hoạt động kinh doanh của công ty (measurable)
Hãy cùng xem 10 bước đó là gì, và quy trình này hoạt động như thế nào nhé!
10 bước tìm kiếm câu trả lời với G Process
G1: Problem Identification — Lựa chọn đúng vấn đề cần giải quyết
Đối với các công ty startup công nghệ còn non trẻ có thể nói là đụng đâu cũng thấy có vấn đề. Trong số đó, việc lựa chọn và giải quyết đúng vấn đề nhằm mang lại tác dụng tích cực cho công ty là một việc vô cùng quan trọng. Nếu không, công ty sẽ để lãng phí tài nguyên khi đâm đầu vào những vấn đề không quan trọng hoặc ít tác động tới các hoạt động kinh doanh.
Vậy lựa chọn đúng vấn đề bằng cách nào? Bạn có thể tham khảo một hoặc một nhóm các yếu tố trong G Process 1 sau:
- Từ KPI Goal của công ty. Ví dụ, nếu KPI của quý này là tăng trưởng việc sử dụng sản phẩm thì tất cả những vấn đề liên quan tới tăng trưởng sẽ có độ ưu tiên cao hơn.
- Từ kết quả đo lường được ở version trước. Ví dụ, bạn là PM của một website và quan sát thấy landing page có lượt bounce quá cao, cứ 10 người truy cập thì có đến 8 người thoát ra ngay lập tức. Vậy thì con số 80% này chính là dữ liệu cho thấy version trước đó có vấn đề và cần phải sửa chữa ngay. Chúng ta có ngay G1 là “lượt bounce của landing page quá cao (80%)”.
- Từ kết quả của khảo sát người dùng thông qua online survey hoặc là interview với người dùng.
- Từ một giả thiết về hành vi người dùng hay phản ánh của thị trường về sản phẩm hay dịch vụ của công ty mà chưa thể chắc chắn do không có đủ dữ liệu.
Xem thêm: Chu trình PDCA là gì? Cách ứng dụng chu trình PDCA cải tiến doanh nghiệp
G2: Ideation - Đề xuất và lựa chọn Giải pháp tốt nhất
Khi vấn đề đã được lựa chọn để giải quyết, ta đến bước thứ hai: Tìm kiếm giải pháp phù hợp nhất. Vấn đề sẽ được đưa ra toàn công ty để ai cũng có thể đề xuất cách giải quyết, sau đó một “hội nghị bàn tròn” sẽ được tổ chức gồm 3 bên:
- Business Owner (Product/Product Manager — PM hoặc phụ trách dự án): người đưa ra G Process 1, chịu trách nhiệm chung và đưa ra tổng quan về yêu cầu công việc, thời gian hoàn thành dự án
- Project driver (Technical Product Manager — TPM hoặc phụ trách dự án): người chịu trách nhiệm triển khai dự án ở bước tiếp theo (G Process 3a), phụ trách quản lí các tài nguyên cần thiết (số người tham gia, thời gian dự kiến…)
- Feedback and Approvals (Cross functional leads): leader của các team đóng góp ý kiến, nhận xét, và chấp thuận các chi tiết sẽ được thực hiện trong dự án.
Trong cuộc họp này, mọi phương án sẽ được đưa ra thảo luận, mổ xẻ, phân tích. Nhưng không phải ai cãi to là thắng đâu nhé!
Mỗi phương án được đưa ra cần phải dựa trên những persona cụ thể của khách hàng:
- Họ là ai?
- Họ gặp vấn đề gì?
- Vấn đề đó ảnh hưởng đến trải nghiệm ra sao?
- Khách hàng tìm kiếm trải nghiệm như thế nào và vì sao?
- Từ đó, mọi người sẽ cùng xem mỗi phương án có ưu điểm, nhược điểm gì, để rồi chọn ra cái tối ưu nhất.
Trong thời điểm hiện tại, giải pháp được ưu tiên nhất thường là giải pháp có thời gian thực hiện ngắn nhất để có thể đưa sản phẩm tới tay người dùng và đo lường các metrics ngay.
G3: Product Vision, Specs and Design
G3 là bước cụ thể hoá phương án được chọn ở G2. Từ khoảng cuối năm 2017, Got It đã quyết định “bẻ nhỏ” G3 thành G3a, G3b, và thậm chí là G3c (nếu cần thiết). Việc này nhằm đảm bảo giải pháp được xem xét một cách kỹ lưỡng hơn, cũng như tránh thay đổi nhiều trong quá trình thực hiện.
G3a - Product vision
Để một chức năng thực sự thành công và mang lại giá trị cho người dùng cũng như công ty, chức năng đó có thể phải qua hàng loạt version khác nhau. Ở bước này mô hình tổng quan hay “big picture” sẽ được đưa ra như:
- Các UX flow sẽ như thế nào?
- Kiến trúc tổng thể có thể tích hợp với hệ thống hiện tại, cũng như khả năng thay đổi trong các phiên bản tiếp theo hay không?
- Các hệ thống khác có thể bị ảnh hưởng như thế nào?
- Những công nghệ hay dịch vụ bên ngoài nào sẽ được tận dụng?
- Các personas sẽ bị tác động tích cực hay tiêu cực thế nào?
- Các business KPIs sẽ bị tác động ra sao?
- Ngoài product thì có những bộ phận nào trong công ty cần tham gia và chịu ảnh hưởng?
Ở bước này, các bên sẽ bàn bạc với nhau để quyết định các yêu cầu tổng quan cho MVP như UX design, các đặc điểm (specifications) và tác động (business impact/metrics affected). Các hệ thống sẽ chịu ảnh hưởng, các bên tham gia dự án, test plan và các metrics cần đạt được ở cuối quá trình thực hiện (G10) cũng sẽ được bàn bạc và chốt lại ở G3a.
G3b - Product specs and design
G3b là bước cụ thể hoá tới từng chi tiết của G3a. Tất cả những việc cần làm sẽ được mô tả một cách chi tiết.
Kết quả của G Process 3b là một kế hoạch vô cùng chi tiết cho tất cả các team có liên quan để sau đó, các team có thể tiến hành làm việc một cách độc lập và song song với nhau.
G4: Estimation - Ước tính
Đến bước thứ tư, khi đã rõ phải làm những gì, bạn sẽ cần bắt đầu ước tính thời gian cần thực hiện cho từng đầu việc cụ thể.
Mỗi người sẽ được tự estimate thời gian hoàn thành công việc. Điều này không chỉ tăng tính chủ động cho mọi người trong team, mà còn giúp mỗi người rèn luyện kỹ năng quản lý bản thân, hay cao hơn là quản lý công việc, quản lý dự án. Nhờ đó mà chỉ sau một thời gian làm việc, hầu như mọi nhân viên đều có tính chủ động rất cao. Bạn chính là CEO cho sản phẩm của mình, và các đồng nghiệp sẽ đóng vai trò cố vấn để cho lời khuyên, feedback và góp ý để hoàn thiện sản phẩm ấy.
G5: Execution - Thực hiện
Tính toán xong thì bắt tay vào làm thôi! Có lẽ không phải nói nhiều về bước thứ năm nữa, vì mọi người vào bước này ai cũng tập trung cao độ để hoàn thành công việc. Ai mà lỡ estimate hơi “ngáo” thì bây giờ chính là lúc chạy deadline hùng hục đây!
Do G3b đã được tính toán rất kỹ nên lúc này nhiều team cùng có thể hoạt động song song, để đến đúng ngày đúng giờ là ghép kết quả, tạo thành sản phẩm cuối cùng. Các bạn engineer thì code, các bạn QA thì viết test cases và chuẩn bị test plan, các bạn Ops thì làm tài liệu training chuyên gia, các bạn growth thì chuẩn bị các campaign quảng bá cho sản phẩm. Tất cả hoạt động nhịp nhàng như một cỗ máy được bôi trơn, chờ ngày chạy thử.
G6: QA — Kiểm thử
Ở bước này thì đầu ra của tất cả các team đều đã “ra tấm ra món”, nhưng chưa chắc đã đúng như với yêu cầu nên cần phải test để đảm bảo những gì làm ra đạt chất lượng cao nhất. Tất cả các team đều phải làm QA.
Ví dụ tại Got It, biết viết test automation là yêu cầu bắt buộc đối với mọi engineer. Trong 2 tháng training, sẽ có hẳn 2 tuần bạn phải “nằm vùng” ở team QA để học làm test. Việc này sẽ giúp bạn có một tư duy tốt hơn trong quá trình code, biết “thương mình thương người” để viết code sạch hơn, đồng thời tăng mối giao lưu tình cảm giữa hai team QA và engineer.
Ngoài ra trong quá trình viết code, tất cả engineers đều phải có đầy đủ unit test cho những gì mình code. Tương tự các team khác như Ops, Growth, etc. cũng đều phải cùng nhau check chéo để đảm bảo rằng đầu ra của mình có chất lượng cao nhất.
G7: Internal Alpha Testing — End-to-end Test
Khi xây dựng một sản phẩm hay tính năng mới, thì sản phẩm hay tính năng đó phải thuyết phục được “người trong nhà” trước, rồi mới tính đến chuyện thuyết phục người dùng. Vì vậy chính các nhân viên sẽ đóng vai người dùng bình thường để thử tất cả các sản phẩm, tính năng trước tiên.
G8: Public Beta Testing (Optional)
Thường quá trình test sẽ hoàn thành ở G Process 7. Tuy nhiên, nếu có yêu cầu cụ thể, G8 sẽ được đề xuất để đảm bảo giảm thiểu rủi ro nếu sản phẩm không đáp ứng được yêu cầu của người dùng hoặc ảnh hưởng tới những thành phần đang có sẵn. Ở bước beta testing (hay còn gọi là external testing), sản phẩm sẽ được đưa ra cho một lượng nhỏ người dùng để thu thập feedback trước khi phát hành chính thức.
Đối với mobile app thì đây chính là bước để submit phiên bản mới lên App Store để chờ được approve bởi Apple hay Google.
G9: Release — Go Live!
Sau quá trình “sứt đầu mẻ trán” thì đây chính là lúc thành quả được tung ra. Có một điều thú vị là ngay sau release thì team QA phải thực hiện post production test để đảm bảo phiên bản mới hoạt động tốt ở trong môi trường production (vốn phức tạp hơn nhiều so với môi trường dev hay staging).
Ở bước này, PM còn phải tự tay test một số flow trọng yếu của sản phẩm (gọi là business impact flow) để đảm bảo rằng hoạt động kinh doanh của công ty không bị ảnh hưởng. Bất kỳ lỗi gì xảy ra khi test business impact flow, bằng bất cứ giá nào, phải được fix ngay tức thì. Các lãnh đạo của công ty cũng liên tục test business impact flow như là một thói quen Để giảm rủi ro như có lỗi mà không kịp huy động người sửa thì bạn nên tránh release sản phẩm mới vào ngày cuối tuần.
G10: Results — Postmortem
Bạn còn nhớ ở G3 chúng ta đã set KPIs cho sản phẩm chứ? Vậy thì G10 chính là lúc phân tích các dữ liệu, con số để xem liệu lần phát hành này có đạt được các KPIs đó không, cũng như sản phẩm ảnh hưởng như thế nào tới trải nghiệm và hành vi của người dùng v.v..
Thường quá trình thu thập dữ liệu sẽ mất khoảng 2 tuần và trong thời gian đó, có rất nhiều thí nghiệm sẽ được thực hiện. G10 chính là lúc nhìn lại những gì mình đã làm được và chia sẻ bài học với cả team.
Sau đó, chính những số liệu, kết quả phân tích ở G10 sẽ là cơ sở cho một G1 tiếp theo. Câu chuyện đi tìm data-driven solution sẽ lại được khởi động, các vấn đề sẽ không ngừng được đưa ra và giải quyết theo một chu trình logic. Đó chính là điều khác biệt khi làm product: không phải làm xong là xong, mà bạn sẽ luôn phải nhìn vào G10 để tìm ra những G1 tiếp theo.
Ai sẽ là người chịu trách nhiệm trong từng bước của G Process?
Hãy coi việc xây dựng và vận hành sản phẩm cũng như thực hiện các hoạt động kinh doanh giống như một chuyến du hành qua rất nhiều địa hình khác nhau. Với mỗi địa hình, ai là người thạo nhất ở địa hình đó sẽ là người cầm lái. Tất cả những người còn lại sẽ hỗ trợ mà không phân biệt vị trí của người đó là sếp hay là nhân viên. Đối với các bước của G Process cũng vậy, mỗi bước sẽ có một những người chịu trách nhiệm cuối cùng.
Quá trình đi từ G1 tới G10 nhìn có vẻ dài và máy móc tuy nhiên có những bước rất ngắn ví dụ G1, G2, G3b, G4, G7, G8, G9. Mỗi tuần bạn nên dành thời gian riêng cho Gating để chuyển một project từ bước này sang bước kia. Mỗi khi một project được gate để pass sang bước tiếp theo thì sẽ có một số người phải tham gia bắt buộc còn lại là optional để mọi người không phải meeting nhiều.
Trên đây là những nội dung cơ bản nhất về G Process - quy trình làm việc cốt lõi của Got It. Bạn hoàn toàn có thể áp dụng phương pháp này trong bất cứ vấn đề nào mình gặp phải.
Team Content SlimCRM.vn
Nguồn: Got it Viet Nam
