對於同一個產品，程式設計師和產品經理的分工不同。產品經理主要關注產品的功能、使用者的體驗、產品的設計等方面；而對於程式設計師，主要考慮的是功能的邏輯實現、專案的部署、產品的可維護性等。對於產品經理提出的一個功能，程式設計師可能有多種實現方式，要考慮多種技術細節；而產品經理僅僅把控功能的整體實現，是否有bug。

程式設計師與產品經理思維的不同，主要還是分工不同，考慮問題的出發點不同。

產生這種疑問的根本原因是溝通問題，更大程度上是產品經理的原因，所以要解決這個問題，要先從產品的本質說起。

產品論到極處，就三條：

1，誰是你的使用者？

2，你幫助Ta解決了什麼問題？

3，Ta為什麼要使用你的產品？

所以請記住，產品是使用者用的，他購買你只是為了更好的完善自己，而不是你的產品。

使用者不會為功能買單。人們購買的是解決方案。

你的工作不是更快的開發更多的功能，而是使那些投入精力開發的功能在成果和影響上可以最大化。

因此就有那麼一個理論工具專門來說這個，這個理論有本書叫《使用者故事地圖》。

這本書呼籲團隊把溝通作為高效團隊的核心價值。故事，是程式設計師和其他角色溝通的必備要求，故事地圖將這些要素組織為結構化，以此來強化軟體開發中最關鍵的部分 — 溝通。

這本書的觀點和敏捷開發方法在某些方面不謀而合，比如：人和互動勝過過程和工具以及可以工作的軟體勝過面面俱到的文件。

所以你可以配合敏捷開發方法使用。總之，這種方法可以替代乾巴巴的需求來達到產品和研發溝通的目的。

使用它可以考慮三種場景：開始前、進行中、結束後。

開始前，我們通常需要梳理出使用者畫像和使用者故事板。尋找到使用者的痛點和動機，他在什麼場景下遇到什麼問題？我們的解決方案是什麼？這就是使用者畫像和使用者故事板。

進行中，哪些故事已經被完成了？還有哪些正準備完成？這些故事是否需要被更改？怎麼講故事更容易被使用者接受？

結束後，做為一種文件用來備忘。就像你度假時拍的照片。滿滿都是回憶。

需要注意的是，沒有必要一開始就完成故事的全部，你應該是增量的、迭代的去完成你的產品。

同樣是迭代，在早期的目的更多是為了試錯。在後期的目的更多是微調。

你在團隊裡可以考慮使用這個工具，看是否能解決問題。

產品經理，它主要是制定的是一個產品的互動以及產品的運營，程式設計師他主要負責的是對這款產品進行底層的研發，以及對這個產品進行後期的維護，因為如果說這個產品開發完之後，這個產品需要後期再增加功能的話，那他就需要有產品經理去提這個功能，然後程式設計師再對產品提的需求進行開發，增加一些功能模組

這就是產品經理程式設計師鎖需要區分的工作職責內容