Người quản lý sản phẩm có nên biết cách viết mã?

(Loại) câu trả lời ngắn

Đây là một trong những câu hỏi mà nó bắt đầu xuất hiện khá thường xuyên và gần đây, với tư cách là một PM nền tảng phi kỹ thuật (ít nhất là về mặt giáo dục chính quy), tôi đã đặt ra một suy nghĩ khá quan trọng về nó. Tôi đoán đây là trường hợp với hầu hết các nhà quản lý sản phẩm không có nền tảng công nghệ, những người đang làm việc trên các sản phẩm kỹ thuật.

Câu trả lời ngắn gọn cho tôi là không có. Công việc chính của một PM và nơi anh ấy hoặc cô ấy nên đặt phần lớn năng lượng và trí tuệ là lắng nghe và thấu hiểu thị trường, xác định chiến lược và tầm nhìn sản phẩm và truyền đạt các yêu cầu rõ ràng về sản phẩm cho nhóm sản phẩm. Có thể viết mã hoặc tạo kiến ​​trúc phần mềm hoặc bất kỳ kỹ năng tương tự nào khác chỉ là một lợi thế, nhưng chắc chắn không phải là công việc quản lý sản phẩm.

Tôi tin rằng các kỹ năng mã hóa hoàn toàn cần thiết mà một PM nên có, nên là những kỹ năng cần thiết để lấy và xử lý dữ liệu liên quan đến việc sử dụng sản phẩm, chấp nhận người dùng, hành vi của khách hàng, để anh ta có thể hiểu biết và đưa ra quyết định dựa trên dữ liệu về tương lai của sản phẩm. Ví dụ, có thể sử dụng SQL một cách hiệu quả, để kéo dữ liệu hoặc bất kỳ ngôn ngữ lập trình nào để thao tác chúng là những kỹ năng siêu quý giá và như tôi đã nói là cần thiết.

Tại sao một PM không cần phải biết cách viết mã

Điều đó đang được nói, sự hiểu biết sâu sắc nhất bạn có thể có về mặt kỹ thuật về sản phẩm và công nghệ, càng tốt cho bạn. Nhưng điều này không đòi hỏi phải có một nền tảng kỹ thuật phần mềm. Bạn có thể có được sự hiểu biết đó bằng cách liên tục tò mò về các chi tiết nhỏ, đọc về công nghệ, khung, ưu và nhược điểm của chúng và rõ ràng, bằng cách làm việc trên các sản phẩm kỹ thuật và giao tiếp có ý nghĩa nhất có thể với các kỹ sư đang xây dựng sản phẩm .

Theo kinh nghiệm của tôi, các kỹ sư luôn sẵn sàng giải thích và chia sẻ những hiểu biết cho những người phi kỹ thuật về những gì họ đang xây dựng, cách họ xây dựng nó và tại sao họ đưa ra những lựa chọn nhất định về mặt công nghệ. Lúc đầu, tôi miễn cưỡng thực hiện thêm một dặm nữa và bắt đầu chụp với những câu hỏi như vậy, vì tôi đã không muốn trở thành người đàn ông sẽ là một kẻ mất tập trung liên tục. Mặc dù vậy, điều tôi nhận ra là phần lớn các đồng nghiệp của tôi không chỉ ở đó để trả lời câu hỏi của tôi, mà họ còn đi xa hơn để cung cấp cho tôi nhiều chi tiết hơn tôi đã hỏi, chia sẻ tài liệu hữu ích có thể giúp tôi hiểu sâu hơn về những câu hỏi của tôi. Như tôi đã nói, bạn không nên miễn cưỡng hỏi, tuy nhiên, bạn phải thận trọng để không vượt qua giới hạn. Trước khi bạn tiếp tục chụp một câu hỏi, hãy chắc chắn rằng bạn đã thực hiện nghiên cứu của riêng mình trước. Nếu bạn không thể tìm thấy một câu trả lời thỏa mãn hoặc nếu bạn cần một số hiểu biết sâu sắc hơn, thì hãy tiếp tục và hỏi.

Nhưng nếu tôi là một PM có nền tảng kỹ thuật thì sao?

Mặt khác, có nhiều người đang chuyển từ phía kỹ thuật phần mềm thực hành sang phía quản lý sản phẩm. Không có nghi ngờ gì về sự hiểu biết kỹ thuật của họ là một lợi ích đáng kinh ngạc. Tuy nhiên, bạn vẫn phải ghi nhớ, mục tiêu chính của bạn là người quản lý sản phẩm là gì. Tôi hiểu rồi, một khi bạn đang xây dựng một sản phẩm đầy thách thức, nó rất hấp dẫn khi muốn tham gia vào khả năng kỹ thuật hoặc lựa chọn công nghệ và bạn nên (ngay cả khi bạn không có nền tảng kỹ thuật phần mềm).

Phải nói rằng, ngay cả khi tôi ở vị trí đó, tôi sẽ không đưa ra quyết định cuối cùng về cách kiến ​​trúc kỹ thuật của sản phẩm, hoặc công nghệ nào sẽ được sử dụng. Và điều này là bởi vì, bạn không phải là người sẽ thực sự xây dựng sản phẩm. Các kỹ sư của nhóm của bạn là những người sẽ làm điều đó và từ cuối cùng về những lựa chọn đó là của họ. Chuyên môn của họ có thể khác với bạn, các công nghệ họ biết sử dụng tốt không nhất thiết phải giống với bạn. Và chắc chắn đó không chỉ có một cách đúng để xây dựng một cái gì đó. Chắc chắn, bạn có thể và nên đóng góp trong các cuộc thảo luận đó, nhưng đừng để cho cái tôi kỹ thuật của bạn vượt lên trước bạn.

Nếu tôi muốn học cách viết mã?

Quay trở lại với các nhà quản lý sản phẩm không có nền tảng kỹ thuật phần mềm, học cách viết mã rõ ràng có thể không chỉ hữu ích. Đối với cá nhân tôi, nó không chỉ hữu ích; nó là thứ tôi thích Đầu tiên, tôi đang học một cái gì đó mới, nó rất thú vị. Mặc dù, phần tuyệt vời nhất của nó, không chỉ là học một khuôn khổ mới hoặc các nguyên tắc kỹ thuật phần mềm. Nó ảnh hưởng đến các nguyên tắc công nghệ phần mềm, theo cách bạn đang nghĩ, cách bạn xử lý vấn đề, cách bạn phân tích nó và cách bạn cấu trúc suy nghĩ của mình.

Như một phần thưởng, bạn luôn có thể bắt đầu dự án X riêng của mình, đó có thể chỉ là một khái niệm bạn muốn thử nghiệm và cuối cùng đã xây dựng một MVP về tính năng lớn tiếp theo của sản phẩm. Đó là một cái gì đó khá.

Tóm tắt

Cho dù kỹ thuật phần mềm có thể giải trí và hữu ích đến mức nào, với tư cách là người quản lý sản phẩm, bạn phải luôn luôn ghi nhớ trách nhiệm chính của mình là gì. Và những người không tự xây dựng sản phẩm. Nó định nghĩa sản phẩm. Vâng, một số kiến ​​thức mã hóa chắc chắn có lợi. Nhưng đưa ra quyết định đúng đắn về những gì sản phẩm nên và trong những gì sản phẩm nên phát triển là bản chất của công việc quản lý sản phẩm. Bạn có đội ngũ kỹ sư phần mềm để lo phần còn lại. Tôi thừa nhận rằng trong một số trường hợp nhất định, người quản lý sản phẩm phải có kiến ​​thức kỹ thuật cao, nhưng tôi tin rằng trong phần lớn các trường hợp, đây chỉ là điểm cộng và không bắt buộc.