SM的價值或者脫離敏捷來講，項目經理的價值是什麼？編碼實現的理解不如程序員，業務的理解不如產品經理。我的理解是“SM的工作就是在PO與團隊之間的架橋”，要對整個軟件項目負責。
既然是架橋，首先就得理解架橋的必要性，瞭解這座“橋”的作用，然後才知道這橋架成什麼樣子。
人最終是受限於自身的經驗與知識體系的。
正因爲分工不同，PO往往在業務知識、用戶價值方面思考較多，對軟件的實現方面思考甚少。結果就是PO在表達自己的產品設計時，或因爲畏懼技術的不可達而設計得過於小氣，發揮不出技術的最大潛能。或者就是天馬行空般表達，完全脫離實際技術能力而導致項目流產。除以之外，PO在表述產品設計時容易出現想當然，認爲只要把想法簡單的說出來即可，對編碼實現需要考慮非常具體邏輯判斷的認識不到。PO大量細節考慮不周，程序員在實現時就會在細節的確認上花費大量的時間，最終結果就是實際花掉的時間遠遠超過當初認爲“應該花掉”的時間。SM識別出這些潛在的問題，從需求的源頭提升質量，就能提升實現的質量與速度。
從程序員的角度看，實現功能很容易成爲目標甚至唯一目標，而可用性就是對最終產出的“評判”標準。功能實現出來就像廚師把飯菜做出來一樣，只是最基礎的要求，如何把軟件產品這個“飯菜”做的色香味俱全，纔是一個優秀IT工程師的所應該追求的。軟件產品是否優秀的指標，有擴展性、維護性、可移植、安全性、健壯等等，每一項指標的提升都需要程序員去思考很多東西，不是一個簡單隻知道碼代碼的人能夠深刻理解的。以功能實現爲目標容易產出維護成本很高的軟件產品，比如規範做的極爛、架構基本沒有、模塊高耦合等等。另外，有一些東西僅僅從技術的角度進行分析是遠遠不夠的，比如擴展性以及設計模式的選用，很多就是基於業務場景想象來進行選型的，我們預見未來可能會有這些功能的擴展，在編碼中就應該提前規劃。而這些東西PO是無法從需求中提煉出來的，他僅僅知道未來要擴展，但不知道我們現在其實可以提前準備。這些點就是SM的價值，提前識別出來，引導好PO在澄清需求時講出來，好讓編碼職員提前作好規劃，提升整個項目的編碼水平。
其次就是需要知道如何架橋，有一些常用的架橋手段。
這個架橋的手段就不僅僅指專業知識了，更多的涉及到人際溝通方面的東西，用一個時髦的詞來說就是情商要高。當我們意識到某個方法有利於工作質量的時候，別人不一定認同或者明顯是對的但是不願意改變自己的工作方式，人對於改變往往是下意識抗拒的，這個時候我們就需要運用一切資源來推動這個東西了，比如從公司層面形成制度、利用自己的人格魅力施加影響、動之以情曉之以理等。那這些工作有沒有規律可循呢，其實還真沒有，需要因人而異，對症下藥。不同的人有不同的思路，有權力的人可以強推，有權威的人就簡單了，大家相信他，那他只需要表達出來，大家首先就信任了他三分。方法是沒有定型的，資源也是有限的。戰爭是解決爭端的最後手段，所以利用好現在的因素尤其是專家和公司層面制度等大家會信服的東西來“水到渠成”是最好的結果。
最終目的其實很好理解，就是要把想要做的軟件產品做出來，但是這個架橋的理解卻不是每個人都能夠理解得透的。
其實，優秀的SM或者項目經理的工作不只是架橋這一個工作，於技術團隊而言需要指導技術架構、設計模式等東西以提高軟件架構的擴展性、維護性等。於PO來說，需要引導其確保設計層面考慮了易用性、在技術上是否可行、是否把握住了產品的核心價值等全局性、根本性的東西。