Giới thiệu

Phương pháp IRAC (đọc là eye-rack hoặc ai rách haha) là một cái sườn giúp bạn có thể sắp xếp câu trả lời cho một vấn đề nào đó một cách chi tiết và rõ ràng. Thực ra phương pháp này bắt đầu được đưa ra và áp dụng bởi các công ty luật ở Mỹ.

Cấu trúc của một câu trả lời chuẩn IRAC bao gồm các thành phần cơ bản: Issue – Vấn đề, Rule – Quy phạm, Analysis – Phân tích và Conclusion – Kết luận.

Mình là lập trình viên, nên sẽ cố gắng giải thích một cách đơn giản và non-legal hết sức có thể ^_^

  • Issue: các vấn đề mà khách hàng đưa ra cho chúng ta mà chúng ta cần giải quyết và tư vấn cho họ.
  • Rule: các quy tắc và những thứ common sense cần tuân thủ trong quá trình thực hiện yêu cầu. Các quy tắc ở đây có thể là một vài tiêu chuẩn chung hoặc những quy định cụ thể từ phía khách hàng.
  • Analysis: phân tích, làm rõ ràng các yêu cầu của khách hàng. Dựa vào các Rule mà chúng ta liệt kê ra các solutions hợp lý để giải quyết Issue.
  • Conclusion: từ kết quả Analysis ở trên, chúng ta tổng kết lại các phương pháp tốt nhất hoặc phù hợp nhất để khách hàng có thể áp dụng.

Trong một số trường hợp, chúng ta có thể gộp chung phần Analysis và Conclusion lại với nhau mà không cần phải tách biệt chúng.

  Code convention là gì? Một số quy tắc chung khi viết code lập trình

  Quy tắc viết code dễ đọc, tối ưu và dễ bảo trì nhất

Ví dụ áp dụng

Issue

Khách hàng Trung Nghĩa đã có một website bán hàng online. Trung Nghĩa liên hệ và yêu cầu Duy PT phát triển thêm tính năng sản phẩm đa phiên bản.

Rule

  • Không ảnh hưởng tới dữ liệu hiện có do website đã có lượng traffic cao cùng với lượng khách truy cập đông đảo (common sense).
  • Tốc độ tải trang nhanh chóng, ít nhất là như trang hiện tại.
  • Validate dữ liệu đầy đủ phía backend (common sense).
  • …

Analysis

Yêu cầu của khách hàng khá mơ hồ nên cần làm rõ ràng, chi tiết hơn:

  • Các phiên bản sản phẩm có khả dụng trong việc tìm kiếm hay không?
  • Các thuộc tính của mỗi phiên bản sản phẩm có giới hạn hay không?
  • Khi một sản phẩm có số lượng thuộc tính quá lớn thì xử lý như thế nào?
  • Việc cập nhật thông tin phiên bản sản phẩm có ảnh hưởng tới những đơn hàng trước đó không? Nếu có thì cách xử lý là gì?
  • Cách thức để tạo một sản phẩm có nhiều phiên bản là như thế nào?
  • Cách chọn phiên bản sản phẩm ở phía người dùng cuối như thế nào? Có thể đưa ra một số cách thức mà Shopee, Lazada hoặc các trang TMĐT khác đã làm sẵn.
  • …

Xem thêm các việc làm PHP lương cao trên TopDev

Thông thường đây là quá trình tốn nhiều thời gian nhất trong quá trình lấy yêu cầu. Chúng ta cần phải tưởng tượng ra một big picture về chức năng khách hàng mong muốn, sau đó dần xoáy sâu vào phần details.

Trong quá trình này, để tiết kiệm thời gian cũng như giúp khách hàng dễ nắm bắt ý kiến của mình, chúng ta có thể đưa ra một số bản mockup mô tả chức năng. Dựa vào các bản mockup này, khách hàng sẽ có thể giúp bạn thay đổi, hiệu chỉnh một số thứ cho phù hợp. Khách hàng khá thích làm việc với những người làm việc rõ ràng như vậy, nên các dev nào có ý muốn chuyển sang hướng manager hãy chú ý nhé ^_^.

Hãy cố gắng đặt càng nhiều câu hỏi càng tốt, khách hàng sẽ không thấy phiền lòng đâu. Bạn càng đặt nhiều câu hỏi thì điều đó càng chứng tỏ bạn đang hiểu rõ hơn về thứ mà khách hàng mong muốn. Tuy nhiên, hãy tránh hỏi những câu hỏi ngu ngốc.

Đừng quên keep track tất cả những thông tin mà bạn nhận được. Bạn sẽ cần nó để viết documents lại sau này. Mình khuyên bạn nên keep track mọi thứ qua email nếu có thể.

Conclusion

Sau quá trình phân tích thông tin và clear requirements với khách hàng, lúc này bạn cần viết một bản tổng kết nội dung, kèm theo FSD (Functional Specification Document) rồi gửi cho khách hàng. Có thể sẽ có một vài chỉnh sửa nho nhỏ nào đó.

Việc tiếp theo là ngồi rung đùi chờ khách hàng sign-off rồi bắt tay vào làm thôi. Với một số công ty nhỏ và quy trình không quá strictly thì bạn cũng có thể làm luôn được rồi.

Bài viết của mình đến đây là hết, cám ơn các bạn đã theo dõi nhé 😀

Bài viết gốc được đăng tải tại duypt.dev

Xem thêm:

Cập nhật tin tuyển dụng IT lương cao tại TopDev