大家好，我是連邊，這是我的第48篇原創(chuàng)文章。

今天說一說產(chǎn)品和技術(shù)，以及對應(yīng)的人員組織架構(gòu)。

產(chǎn)品直接決定著項目的成敗，技術(shù)雖沒有直接決定成敗，但是它的架構(gòu)和儲備積累決定了后期的研發(fā)、工作效率。

如果要長期走下去，管理者要產(chǎn)品和技術(shù)同樣的重視與發(fā)展。

產(chǎn)品

產(chǎn)品一般是說最終呈現(xiàn)出來的項目，而在我們平常工作中，它以更零散的名稱存在著，就是我們所說的業(yè)務(wù)。

對零散的業(yè)務(wù)進(jìn)行歸集、整理，最后形成我們的模塊功能，模塊功能組成我們的產(chǎn)品。

業(yè)務(wù)的搜集，大體可以分為兩個方式進(jìn)行收集，主動搜集和被動搜集；

主動收集業(yè)務(wù)，即產(chǎn)品人員去一線觀摩，主動了解業(yè)務(wù)，挖掘需求，解決痛點；

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

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

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

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

所以，真正做得好的團(tuán)隊，應(yīng)該團(tuán)隊內(nèi)形成共識，采取主動搜集的方式，絞盡腦汁的提高主動搜集業(yè)務(wù)的占比。

這樣就能提前做好規(guī)劃，掌握產(chǎn)品規(guī)劃的主動權(quán)，與研發(fā)團(tuán)隊進(jìn)行更高效的協(xié)同工作；減少從業(yè)務(wù)源頭對后續(xù)環(huán)節(jié)產(chǎn)生影響，很多時候被動反饋的業(yè)務(wù)，是急需解決的，首先會打亂研發(fā)團(tuán)隊的研發(fā)節(jié)奏，后續(xù)每個環(huán)節(jié)多少都有影響，久而久之，給產(chǎn)品使用方的感受就是研發(fā)產(chǎn)品團(tuán)隊不專業(yè)。

好的產(chǎn)品應(yīng)該是被定義出來的，思考出來的，而不是靠功能堆積出來的。

技術(shù)

這里說的技術(shù)，是說技術(shù)規(guī)劃與架構(gòu)。

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

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

技術(shù)規(guī)劃是否合理，還有一些技術(shù)架構(gòu)的選型是否合適的判斷依據(jù)，還是來自產(chǎn)品的定義，所以應(yīng)該是先有產(chǎn)品規(guī)劃，然后才有技術(shù)規(guī)劃與技術(shù)架構(gòu)。

比如研發(fā)的產(chǎn)品的呈現(xiàn)形式是B/S架構(gòu)，是做移動App，還是小程序？

是做平臺，還是做產(chǎn)品微服務(wù)，一開始大的方向還是需要定下來的。

定義好大的規(guī)劃之后，也找出技術(shù)積累點進(jìn)行業(yè)務(wù)的積累。

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

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

通過產(chǎn)品對項目的定義，分析清楚項目之間的界限與依賴關(guān)系，決定好項目的層級，然后定好基本的開發(fā)路徑，這個是一開始就要定下來的，而且在很長一段時間內(nèi)也不會去進(jìn)行變更調(diào)整的，后續(xù)根據(jù)該規(guī)劃進(jìn)行相應(yīng)的人員組織架構(gòu)，沉淀相關(guān)的技術(shù)。

人員組織架構(gòu)

前面說了產(chǎn)品和技術(shù)，接下來說一說人員的組織架構(gòu)。人員組織架構(gòu)是與產(chǎn)品規(guī)劃和技術(shù)架構(gòu)相結(jié)合，然后一一對應(yīng)的，需要注意兩點：一個是各司其職，一個是責(zé)任到人。這樣子有利于管理者對項目進(jìn)行跟進(jìn)，不然團(tuán)隊大了，無法協(xié)同工作。

如果項目涉及多個部門，要注意部門內(nèi)部的事情或者需求要把握住從一個口徑來，一般該口徑為項目經(jīng)理，不然團(tuán)隊內(nèi)部事情優(yōu)先級會無法排，整個團(tuán)隊的節(jié)奏就會不穩(wěn)定。

總結(jié)

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

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

但是可以讓技術(shù)工程師在某個整段的時間內(nèi)負(fù)責(zé)某個產(chǎn)品調(diào)研，調(diào)研之后出具PRD文檔。

最后，不管是對產(chǎn)品還是技術(shù)，重要的還是要有產(chǎn)品規(guī)劃和技術(shù)架構(gòu)讓其有使命感、目標(biāo)感、責(zé)任感，然后保護(hù)好他們的整塊研發(fā)時間，相信你就能打造出一支戰(zhàn)斗力和凝聚力非常不錯的團(tuán)隊。