大家好，我是連邊，這是我的第48篇原創文章。

今天說一說產品和技術，以及對應的人員組織架構。

產品直接決定著項目的成敗，技術雖沒有直接決定成敗，但是它的架構和儲備積累決定了后期的研發、工作效率。

如果要長期走下去，管理者要產品和技術同樣的重視與發展。

產品

產品一般是說最終呈現出來的項目，而在我們平常工作中，它以更零散的名稱存在著，就是我們所說的業務。

對零散的業務進行歸集、整理，最后形成我們的模塊功能，模塊功能組成我們的產品。

業務的搜集，大體可以分為兩個方式進行收集，主動搜集和被動搜集；

主動收集業務，即產品人員去一線觀摩，主動了解業務，挖掘需求，解決痛點；

被動收集業務，即一線人員有明確的反饋渠道，可以是工作群、電子表格任何形式的反饋都算。

一般的團隊是兩種方式都存在，只是兩種方式占比的多與少。

主動搜集方式占比高的團隊，會帶來諸多好處，對我們產品有著主動權，有著優先定義產品的權利，能夠從這些主動信息里面去思考、抽象出自己的產品，而不是變成業務堆積出來的產品；

被動搜集方式占比高的團隊，會帶來諸多壞處，比如一線人員覺得我們不專業，有時候被動搜集上來的業務很少，更多的時候，是反饋急需解決的問題，沒有足夠的時間去思考、調研業務、挖掘需求、解決問題，最后上線的產品的業務質量、技術質量都可想而知。

所以，真正做得好的團隊，應該團隊內形成共識，采取主動搜集的方式，絞盡腦汁的提高主動搜集業務的占比。

這樣就能提前做好規劃，掌握產品規劃的主動權，與研發團隊進行更高效的協同工作；減少從業務源頭對后續環節產生影響，很多時候被動反饋的業務，是急需解決的，首先會打亂研發團隊的研發節奏，后續每個環節多少都有影響，久而久之，給產品使用方的感受就是研發產品團隊不專業。

好的產品應該是被定義出來的，思考出來的，而不是靠功能堆積出來的。

技術

這里說的技術，是說技術規劃與架構。

技術和其他的事物一樣，要聚齊一群人，就要讓其有目標感，每天徒勞的搬磚沒啥很大的意思。

選擇一門合適的編程語言，挑選一款合適的中間件，使用一種合適的服務框架，合理的規劃項目層級，等等都可以歸為技術架構。

技術規劃是否合理，還有一些技術架構的選型是否合適的判斷依據，還是來自產品的定義，所以應該是先有產品規劃，然后才有技術規劃與技術架構。

比如研發的產品的呈現形式是B/S架構，是做移動App，還是小程序？

是做平臺，還是做產品微服務，一開始大的方向還是需要定下來的。

定義好大的規劃之后，也找出技術積累點進行業務的積累。

像做工業控制軟件，上位機與設備打交道就非常頻繁，我們是不是要抽取一層驅動層，來專門沉淀解決與設備打交道的系列問題，不要每個上位機都為了設備打交道而折騰得死去活來；而涉及到大數據儲存，我們就要整理出一套成熟的大數據儲存方案，真有大數據使用的情況，就有開箱即用的方案。

還有服務之間相互依賴調度，是不是一開始就定義為整體項目是微服務體系架構，而不是通過各種curl滿天飛？

通過產品對項目的定義，分析清楚項目之間的界限與依賴關系，決定好項目的層級，然后定好基本的開發路徑，這個是一開始就要定下來的，而且在很長一段時間內也不會去進行變更調整的，后續根據該規劃進行相應的人員組織架構，沉淀相關的技術。

人員組織架構

前面說了產品和技術，接下來說一說人員的組織架構。人員組織架構是與產品規劃和技術架構相結合，然后一一對應的，需要注意兩點：一個是各司其職，一個是責任到人。這樣子有利于管理者對項目進行跟進，不然團隊大了，無法協同工作。

如果項目涉及多個部門，要注意部門內部的事情或者需求要把握住從一個口徑來，一般該口徑為項目經理，不然團隊內部事情優先級會無法排，整個團隊的節奏就會不穩定。

總結

最后總結一下，還有一個注意點，不要讓做技術的去同步做產品，一個是人都有惰性，二是技術人員不能從整體出發，很多時候只了解自己模塊的業務，對整個項目的業務沒有一個全局的認識；

還有就是產品業務不是一蹴而就的，是在技術工程師的實現的過程中會有變化的，其中就涉及到各種交涉問題，而普遍的技術人員在溝通上有明顯的不足，而且容易打斷技術工程師有整塊的開發時間，從而導致降低工作效率。

但是可以讓技術工程師在某個整段的時間內負責某個產品調研，調研之后出具PRD文檔。

最后，不管是對產品還是技術，重要的還是要有產品規劃和技術架構讓其有使命感、目標感、責任感，然后保護好他們的整塊研發時間，相信你就能打造出一支戰斗力和凝聚力非常不錯的團隊。