2022.05.18 LUVINA'S MIND

Quản lý cấp trung - Quản lý bài toán

Trong bài viết “Vận hành team bằng Mục đích – Bài toán – Hành động” ở kì trước đã liệt kê 3 kĩ thuật chính để vận hành dự án gồm Kỹ thuật họp, Kỹ thuật quản lý Bài toán, Kỹ thuật quản lý hành động.

Ở bài viết này chúng tôi sẽ viết nhiều hơn về kĩ thuật quản lý bài toán.

Ý nghĩa tích cực của bài toán

  • Bài toán là những thứ phải giải quyết để đạt mục đích. Nó  khác với Vấn đề là từ chỉ những rắc rối, hư hỏng đã xảy ra.
  • Ví dụ về bài toán: 
    • (1) Phát triển phương pháp mới để tăng tốc độ
    • (2) Phương pháp chăm sóc tâm lý để tăng động cơ làm việc cho member.
  • Giải được những bài toán này thì tăng được giá trị cung cấp cho khách hàng (1) hoặc làm cho tình hình của Team, Project tốt hơn (2).
  • Bài toán không nằm sẵn ở đó để nhặt lên giải quyết như vấn đề, mà ta phải tích cực đi tìm nó, phát hiện ra nó để giải quyết.

Nội dung Phiếu quản lý bài toán

No

Phân loại

Tiêu đề

Nội dung

Ngày ghi vào

Tình trạng

Độ ưu tiên

Kết quả/Kết luận

Phân loại thế nào?

Notyet

Doing

Done

Chỉnh lý các bài toán “giả hiệu”

  • Thường sau một thời gian thì các bài toán sẽ đầy ắp file quản lý vì phải hơn một nửa là các bài toán “giả hiệu”.
  • Các bài toán “giả hiệu” này có đặc điểm là mô tả khó hiểu, hoặc khó biến thành hành động cụ thể và tồn tại vĩnh viễn.
  • Việc tồn tại các bài toán “giả hiệu” này làm chúng ta mất tập trung, và có thể bỏ rơi bài toán thực sự.

Check point để tìm bài toán “giả hiệu”

Check point

Ví dụ

Nhầm lẫn giữa vấn đề và bài toán.

Tính năng kém, phản ứng mất 30s.

Việc đối ứng bị phụ thuộc vào

người khác.

REQ chức năng login chưa được quyết định,

phải bắt khách hàng quyết thôi.

Yếu tố mặc nhiên quá cao.

Nâng cao chất lượng.

Không rõ mục đích.

Phải làm lại module truyền tin.

Độ ưu tiên không rõ ràng.

Bài toán nào cũng bị đánh dấu “quan trọng”.

Phân loại không rõ ràng.

Sử dụng nhiều phân loại chưa tồn tại.

Khi thấy các dấu hiệu trên thì phải làm 4 hành động sau:

1. Biến vấn đề thành bài toán.

2. Viết lại bài toán ở mức có thể nhìn thấy Action tiếp theo là gì.

3. Ưu tiên các bài toán kết nối trực tiếp với mục đích của dự án.

4. Đơn giản hóa việc phân loại.

Biến vấn đề thành bài toán

  • Vấn đề là các chướng ngại vật, ví dụ như “Tính năng kém, phản ứng mất 30s” hay “member hay đi làm trễ”. Khi có vấn đề thì phải làm gì đó để giải quyết. Việc “làm gì đó” chính là bài toán phải giải.
  • Ví dụ như “REQ chức năng login chưa được quyết định, phải bắt khách hàng quyết”: Team phải làm gì đó, đề xuất cái gì đó và bắt khách hàng quyết. Tức là mình phải tham gia, đóng vai trò quyết định, chứ không phải là người khác.

Viết lại bài toán ở mức có thể nhìn thấy Action tiếp theo là gì

  • Bài toán cần phải được phân tách nhỏ đến mức có thể nhìn thấy ngay được Action phải làm là gì.
  • Chẳng hạn bài toán “Nâng cao chất lượng” phải được phân tách nhỏ ra, ví dụ thành “Cải tiến tốc độ response” nếu như tính năng kém, hoặc “thực hiện test lại” nếu như bug nhiều.

Ưu tiên các bài toán kết nối trực tiếp với mục đích của dự án

  • Phát hiện ra bài toán mà không ghi thì phí, ghi hết vào nhiều quá rồi cũng không làm hết.

quan-ly-bai-toan

Đơn giản hóa sự phân loại

  • Phần lớn mọi người hay lao vào phân loại chi tiết quá và không làm gì nữa.
  • Phải từ quan điểm phân loại để làm gì?
  • Quan điểm của tác giả: Phân loại để biết phải làm việc với ai về bài toán này.
Bàn bạc Nhờ vả Xửnội bộ

Là bài toán phải hỏi ý kiến chuyên gia ngoài dự án hoặc hỏi khách hàng

Là bài toán nhờ ai đó, khách hàng giải quyết trọn gói

Là bài toán trong team nghĩ kỹ thì làm được

Tóm tắt

  • Bài toán khác với vấn đề, nó mang ý nghĩa tích cực hướng đến việc hoàn tất dự án.
  • Cái khó của quản lý bài toán là: Viết gì trong đó.
  • Các bài toán “giả hiệu” hay lẫn lộn với bài toán thật nên phải phát hiện bài toán “giả hiệu” bằng cách nhìn vào tiêu đề, độ ưu tiên, phân loại.
  • Chỉnh lý bài toán “giả hiệu” bằng cách:
    • Biến vấn đề thành bài toán
    • Phân tách nhỏ đủ để thấy được hành động tiếp theo
    • Ưu tiên những bài toán kết nối trực tiếp với mục đích dự án
    • Phân loại đơn giản.

Thực hành

1. Các member của Team mình có nhầm lẫn giữa vấn đề và bài toán không?

2. Xem lại file quản lý bài toán của Team mình, có vấn đề nhầm lẫn trong đó không?

back to top