- Khi lập trình viên nói No, cách phản hồi lại có thể giúp bạn, với vai trò quản lý sản phẩm, khẳng định quyền hạn và đạt được mục tiêu
- Khi họ nói rằng không thể triển khai một tính năng trong khung thời gian đã đề ra vì lý do kỹ thuật, những câu hỏi phù hợp có thể giúp tháo gỡ tình huống
1. Có giải pháp kỹ thuật nào khác để xây dựng tính năng này không?
- Có nhiều cách để xây dựng một tính năng, và cách được thử đầu tiên không phải lúc nào cũng là tối ưu nhất
- Lập trình viên thường muốn dùng công nghệ mới nhất để xây dựng các tính năng ấn tượng, nhưng điều này có thể dẫn đến over-engineering thay vì tối ưu cho sự đơn giản
- Những lập trình viên có một bộ kỹ năng kỹ thuật nhất định có thể không nhận ra những giải pháp đơn giản hơn nằm ngoài phạm vi kiến thức của họ
- Vì vậy, nên khuyến khích kỹ sư suy nghĩ sáng tạo hơn về giải pháp kỹ thuật
- Một số quản lý sản phẩm giỏi nhất mà tôi từng làm việc cùng có đủ hiểu biết và góc nhìn kỹ thuật về bối cảnh công nghệ để đặt ra những câu hỏi sâu sắc, giúp kỹ sư suy nghĩ vượt ra ngoài khuôn khổ
2. Nếu phải đưa ra giải pháp trong các ràng buộc này, bạn sẽ làm thế nào?
- Nếu lập trình viên nêu vấn đề với giải pháp bạn đề xuất, hãy thử yêu cầu họ đưa ra giải pháp của riêng mình
- Lập trình viên là kho tàng của sự sáng tạo và đổi mới, và bằng cách hỏi xem có phiên bản đơn giản hơn của tính năng hay không, bạn tạo cho họ cơ hội để tư duy sáng tạo
- Khi hiểu được cốt lõi của vấn đề, lập trình viên sẽ suy nghĩ sáng tạo và tìm ra giải pháp hoạt động trong các ràng buộc của dự án
3. Chúng ta có thể cân nhắc cách tiếp cận theo từng giai đoạn cho tính năng này không?
- Khi họ nói rằng không thể triển khai tính năng vì độ phức tạp kỹ thuật, hãy hỏi xem có thể chia dự án thành nhiều giai đoạn với các ngày phát hành khác nhau hay không
- Dù rất dễ bị cuốn vào việc muốn đưa ra một tầm nhìn hoành tráng ngay từ đầu, cách tiếp cận theo từng giai đoạn mang tính lặp hơn và cung cấp kết quả cụ thể nhanh hơn
- Ưu tiên có thể thay đổi, và cách tiếp cận theo từng giai đoạn cho phép bạn phối hợp với lập trình viên về những gì nên bổ sung tiếp theo
4. Chúng ta có thể loại bỏ hoặc giải quyết những trở ngại nào để công việc trở nên khả thi?
- Đây là câu hỏi dành cho các phản đối liên quan đến nguồn lực; khi lập trình viên viện dẫn nguồn lực hạn chế (ví dụ: thời gian hoặc số lượng lập trình viên sẵn có), hãy chủ động loại bỏ công việc để giải phóng thời gian cho họ
- Các cách có thể gồm: loại bỏ hẳn công việc, tự đảm nhận những việc không cần lập trình viên, phụ trách giao tiếp với đội khác và/hoặc bên thứ ba, hoặc giúp công việc dễ hơn bằng cách làm chủ quy trình và loại bỏ các tính năng legacy
Kết luận
- Việc “đẩy tiếp” khi lập trình viên nói “không thể” có thể khiến bạn thấy không thoải mái, nhưng điều đó cũng có thể giúp bạn nhận được nhiều sự tôn trọng hơn
- Bạn cần đào sâu thêm một chút để hiểu vì sao kỹ sư phản đối, rồi lần lượt gỡ bỏ từng lý do phản đối đó
- Tất cả những câu hỏi này đều là câu hỏi hay vì chúng thừa nhận những khó khăn và ràng buộc riêng mà kỹ sư có thể gặp phải khi triển khai một tính năng cụ thể
- Đồng thời, chúng cũng thể hiện rõ rằng bạn sẵn sàng tự mình xắn tay vào hỗ trợ nhóm và dự án, làm những việc khó nhọc hoặc điều chỉnh để phù hợp với yêu cầu và lịch trình
8 bình luận
Rốt cuộc vẫn là vấn đề điều phối như thế nào
Cảm ơn vì nội dung rất hay
Nếu hỏi theo những ý ở trên thì kiểu nói "No" chỉ vì thật ra đơn giản là không muốn làm chắc sẽ bị nhận ra rất nhanh
Với vai trò PM/PO, tôi có 2 phương pháp từng giúp ích khi làm nhiệm vụ điều phối giữa bộ phận nghiệp vụ của dự án và bộ phận IT.
Tất nhiên, tiền đề là cả bộ phận nghiệp vụ lẫn bộ phận IT đều là những bên "biết nghe và hiểu".
Thứ nhất là tiến hành theo từng giai đoạn.
Thứ hai là thu nhỏ quy mô.
Chỉ có vậy thôi.
Khó khăn lớn nhất khi bộ phận nghiệp vụ hoặc bộ phận IT triển khai dự án chính là "thời gian".
Thời hạn thì đã cố định, còn khối lượng thì thường là không thể làm hết trong khoảng thời gian đó.
Lúc này hãy làm theo kiểu "từng giai đoạn". Chia thành lịch tuần tự như phase 1, 2, 3... Chức năng quan trọng nhất đưa vào phase 1, ít quan trọng hơn thì để phase 2... đại loại như vậy.
Nhưng với những dự án không thể làm theo từng giai đoạn, tức là phải mở cùng lúc trong một lần,
thì phải giảm quy mô cho phù hợp với "thời gian". Trong những gì dự kiến cho phase 1, 2, 3, ngoài các chức năng "thực sự cần thiết" thì phải cắt bỏ hết.
Với hai phương pháp này, nếu là bộ phận nghiệp vụ/IT "biết nghe và hiểu" thì phần lớn đều đồng ý.
Vì như vậy vẫn tốt hơn là dự án vỡ trận rồi mỗi người lại bị sếp của mình mắng.
Chậc.
Mọi người cố lên nhé^^
PS:
Còn một gia vị cuối nữa.
Ngay cả khi dùng 2 cách trên, nhiều khi các developer vẫn tỏ ra ngần ngại.
Những lúc đó, nếu nói
"Khoảng giữa tiến độ dự án chúng ta hãy kiểm tra lại một lần. Nếu thấy cần thêm thời gian, tôi sẽ chịu trách nhiệm gia hạn tiến độ"
thì thường gương mặt của các developer sẽ giãn ra hẳn.
Và khi kiểm tra vào khoảng giữa chừng, có đến 95% trường hợp là hóa ra không cần thêm thời gian.
Ngoài ra, một khi developer đã bắt đầu vào code thì nhiều trường hợp lại làm rất nhanh.
Là người làm ở vị trí cần phối hợp với lập trình viên, tôi mong được làm việc với những lập trình viên có thể đối thoại như thế này. Trước giờ tôi chỉ gặp những lập trình viên vừa đầu tiên đã nói là không làm được nên thấy khá buồn. Mà hễ tôi cố thuyết phục và hỏi han kiểu này kiểu kia thì đa số lại là trường hợp chính họ trước đó không biết rằng vẫn có cách để làm..
kkkkkkkk, đau lòng thật..
Những câu hỏi mà kỹ sư nên tự đặt ra cho mình trước khi nói "KHÔNG".
Tôi cũng thấy đây là những câu hỏi rất hay để tự đặt ra cho chính mình.
Trước khi là kỹ sư thì họ cũng là con người. Tôi cũng đồng ý rằng việc theo thói quen cứ nói No với tư cách kỹ sư là có vấn đề, nhưng nếu phía PM/PO mang theo những câu hỏi như vậy thì có lẽ sẽ là một sự hỗ trợ rất lớn.