在控制領域，閉環(huán)是我們是系統(tǒng)達到穩(wěn)定的一個有效方案，對于我們的產(chǎn)品研發(fā)，同樣需要類似的反饋系統(tǒng)形成閉環(huán)，這樣我們的研發(fā)體系才能有預期，研發(fā)進度才可控，做到心中有數(shù)，百戰(zhàn)不殆。

智能手表，一個新興的領域，充滿了無限的可能，也許有一天，我們隨處可見，就像當今的智能手機一樣。作為一類新興的產(chǎn)品，市場上缺乏成熟的開發(fā)經(jīng)驗，我們摸著石頭過河，不斷的嘗試，不斷的改進，不斷的提升。

1.困境

作為一家成熟的消費類產(chǎn)品公司，產(chǎn)品僅僅在軟件研發(fā)領域一般包括下圖的各類人員：

簡單的分析上圖中的結構，智能手表的開發(fā)貌似和常規(guī)的互聯(lián)網(wǎng)產(chǎn)品類似，然而它的復雜性卻沒有看上去那么簡單，我們先簡單分析一下上圖：

• 軟件與4類人員有關聯(lián)，兩個強關聯(lián)，兩個弱關聯(lián)。
• 交互與4類人員有關聯(lián)，兩個強關聯(lián)，兩個弱關聯(lián)。
• 其他職能人員關聯(lián)性都相對較少。

這里有一個實踐的經(jīng)驗，強關聯(lián)性的增加導致溝通成本以指數(shù)性的上升，弱關聯(lián)的增加導致溝通成本以簡單+1的形式上升?；诖?，我們假設強關聯(lián)的增加的指數(shù)上升為2的倍數(shù)（該值不一定合理，需要實際研發(fā)數(shù)據(jù)進行匹配調(diào)整），建立對應的溝通成本計算數(shù)學模型：強關聯(lián)（2的n次方） + 弱關聯(lián)數(shù)。使用該數(shù)學模型，我們計算出各個領域在軟件研發(fā)領域的溝通成本：

• 運營：1+1=2
• 視覺：1+1=2
• 測試：2的1次方+1 = 3
• 規(guī)劃：2的1次方+1 = 3
• 交互：2的2次方+2 = 6
• 軟件：2的2次方+2 = 6

備注：部分領域也許還有其他的關聯(lián)度，這里僅僅只考慮產(chǎn)品研發(fā)的主要場景。

基于該數(shù)學模型，我們基本上可以得出，交互和軟件將是整個研發(fā)流程溝通過程中的核心瓶頸，然而這樣計算就正確了嗎？交互和軟件在溝通成本上就只比其他領域多這么一點點嗎？我們再把問題拆解得更細一些。

1.1.領域細分的副作用

軟件技術的不斷革新，促使軟件領域增多，針對智能手表領域，它涉及到的軟件領域包括：智能手表端、服務器端、android應用端、ios應用端、H5網(wǎng)頁端。以下，是它們之間的溝通關系圖：

備注：智能手表并不是所有的功能都涉及到上圖的所有軟件領域，上圖僅僅列舉了最復雜時的情況。

基于上圖，我們需要重新計算一下軟件、交互與測試在最復雜的情況下的溝通復雜度：

• 交互：2的6次方+2 = 66
• 測試：2的5次方+1 = 33
• 軟件（watch）：2的5次方+2 = 34
• 軟件（server）：2的6次方+2 = 66
• 軟件（h5）：2的3次方+4 = 12
• 軟件（android）：2的5次方+3 = 35
• 軟件（ios）：2的5次方+3 = 35

因此，軟件、交互、測試在日常工作過程中，溝通成非常高。如此高的溝通成本，意味著研發(fā)效率的下降，產(chǎn)品復雜度的上升，以及信息不一致情況發(fā)生的概率增高。

1.2.總結

從本章的分析結果得出，僅僅在溝通成本這個層面上，智能手表的復雜度就非常的高。即使與當下常見的互聯(lián)網(wǎng)產(chǎn)品相比，在多引入了一個手表端的情況下，其復雜度指數(shù)性的提升一倍，也是不可估量的。從直觀上看，它僅僅是多了一個手表端，應該和傳統(tǒng)互聯(lián)網(wǎng)產(chǎn)品功能復雜度差不多，但是卻事與愿違。如果《最后期限》一書中所說，我們需要將自身的經(jīng)驗模型化，這樣才能更準確的評估軟件開發(fā)情況。有的事情，還是需要嚴密的理論邏輯分析才能得出正確結論。

直覺總是告訴我們下面一根線被上面那根短一些，可以它們卻實實在在是一樣長。

2.個體效率與團隊效率的糾纏

直覺告訴我們個體效率提高，團隊效率就會提高。人員的增多，團隊效率也會提高。但是在沒有背景前提下，這樣的結論沒有任何意義，如果我們所做的事情可以拆分成多個基本互不關聯(lián)的事情，那么，這個結論基本成立。

例如：我們都聽說過和尚挑水喝的故事，1個和尚挑水喝，2個和尚抬水喝，3個和尚沒水喝，改為3個和尚都分別自己挑水。那么相對于1個和尚，效率提高三倍，如果單個和尚每天挑水的效率提高1.5倍，那么3個和尚相對于最開始的一個和尚效率提高3*1.5=4.5倍，是不是很激動人心。

理想很豐滿的，現(xiàn)實很骨感，軟件行業(yè)可不能用和尚挑水來簡單類比。這樣的直覺錯誤，我們卻經(jīng)常再犯。原因在于我們在分析任何事情時，都是先由系統(tǒng)1（簡單理解為直覺系統(tǒng)）處理，在系統(tǒng)1無法給出合理的解釋時，系統(tǒng)2（簡單理解為思維系統(tǒng)，可是它很懶）才會介入。軟件行業(yè)的著作《人月神話》全面的闡釋了軟件不能簡單增加開發(fā)人員來解決問題。因此，針對智能手表的研發(fā)，取得個體效率與團隊效率的平衡至關重要。

產(chǎn)品研發(fā)就像種果樹，必須經(jīng)歷播種、施肥、灌溉等一天天逐漸的長大，不要企圖通過多施肥等手段提前收獲果實。種一個棵樹最好的時間是十年前，其次才是現(xiàn)在，所以想要新品早點上市，那么就需要將需求整理提前，而不是過多的希望研發(fā)后端流程能更有效率。

2.1.如何提高個體效率

• 盡量減少被打擾的次數(shù)。
• 讓個體身處于所在專業(yè)領域的團隊中。
• 持續(xù)進行某個特定領域的研究。
• 同領域人員集中地點辦公。

2.2.如何提高團隊效率

• 加強團隊成員溝通。
• 項目組成員集中成一個團隊。
• 團隊成員為多領域復合型人才。
• 同項目組成員集中地點辦公。

2.3.矛盾與取舍

雖然大方向來說，需求提前才是促使新品上市的主要方式。但是，實際研發(fā)過程中，尤其是在迭代開發(fā)中，需求已經(jīng)做到了提前，后端迭代速度偏慢，就成了一個比較凸顯的問題。多少人能做多少事，增加人員能否提高生產(chǎn)力，迭代速度是否存在極限，這些問題都有待研究和解決。

就像愛因斯坦的相對論，人類無法突破光速有一個制約的因素，就是速度越快，質(zhì)量越大，接近光速時，質(zhì)量趨于無窮大，也就是說速度越快，加速的成本就越高。一個軟件開發(fā)的速度也許也受到其固有的軟件復雜度等因素影響，存在一個迭代速度極限值，例如：一個功能點由一個人變?yōu)閮蓚€人來做，那么多一個人就多了溝通成本，那么隨著人數(shù)的激增，超過某個臨界值時，增加人數(shù)反而會降低研發(fā)速度。

2.3.1. 個體效率與團隊的矛盾點

• 團隊的溝通與減少打擾互相矛盾。
• 專業(yè)團隊與敏捷團隊矛盾。
• 持續(xù)研究某個領域與多領域復合矛盾。
• 專業(yè)團隊集中辦公與敏捷團隊集中辦公矛盾。

以上矛盾簡直是要逼死“處女座”，本人就是“處女座”。所以，現(xiàn)階段根本就不存在個人效率與團隊效率雙贏的方案，必須有所取所，取長補短。剛開始接觸敏捷開發(fā)，要做的事情就是熟悉敏捷開發(fā)中的各個流程，以及如何操作，解決我們現(xiàn)有的問題?，F(xiàn)在回過頭來分析，敏捷開發(fā)中設立的每個環(huán)節(jié)，在解決以上矛盾問題上都提出了相應的方案。

2.3.2. 團隊的溝通與減少打擾互相矛盾

不管是敏捷團隊還是專業(yè)領域團隊，溝通都不可避免，因為產(chǎn)品是由整個團隊開發(fā)出來的，即使是某個交互方案、軟件組件、策劃方案往往都由多人參與。然而，頻繁的溝通必然影響個人的開發(fā)效率，因此在敏捷的團隊里，每日有固定的晨會、每周有固定的迭代計劃與總結會等。是的，這就是敏捷開發(fā)在個人效率與溝通的矛盾上的取舍。

同樣的，在專業(yè)領域團隊中，我們嘗試每周做固定的交流會，以軟件為例：每周固定代碼交流會，以某位軟件同事的作品為主線，引導專業(yè)領域團隊內(nèi)成員交流。這是一個很好的取舍，讓整個團隊有自己固定的節(jié)奏。

收益

這樣的方式，極大的改善了團隊內(nèi)信息不對稱的問題，在專業(yè)領域團隊有效的改善設計方案，規(guī)章制度的實際執(zhí)行，同時提高了整個團隊的能力等。在敏捷團隊中，有效的避免因信息不一致導致前端設計與后端實現(xiàn)不一致，測試理解偏差等問題。

損失

每天都有會議，對于工作有一定的打斷影響，部分人員參與會議時，會議參與度低，實際收益甚微，會議的整體節(jié)奏需要成員逐步適應，弱一個人同時處于多個敏捷團隊中，會議數(shù)量會嚴重影響該成員的工作（這種情況需要盡量避免）。

2.3.3. 專業(yè)團隊與敏捷團隊矛盾

在這個問題上，個人比較趨向選擇專業(yè)團隊為主，敏捷團隊為輔的方式，不一定正確，也不一定適用于各類場景，這個決定是站在我現(xiàn)在所處的環(huán)境得出來的，理由如下：

• 敏捷團隊已經(jīng)有足夠多的會議，足以達到信息對稱的效果。
• 敏捷團隊為主，會導致各個人員專業(yè)領域薄弱，專業(yè)上缺乏積累，重復開發(fā)的風險增大。
• 敏捷團隊為主，會導致人員復用性降低，調(diào)配難度增大，資源獨占。
• 專業(yè)團隊為主，能有效的積累專業(yè)領域知識，設計整體方案，提高生產(chǎn)率。
• 專業(yè)團隊為主，對于技術方案的評估會更加全面和準確。

但是，這樣的選擇也有它存在的問題：

• 專業(yè)團隊為主，敏捷團隊缺乏足夠的獨立性，人員變動可能性增大。
• 專業(yè)團隊為主，敏捷團隊缺乏明確的目標，難以在迭代過程中找到成就感。
• 專業(yè)團隊為主相比于敏捷團隊為主，在產(chǎn)品開發(fā)期間溝通效率偏低。

2.3.4. 持續(xù)研究某個領域與多領域復合矛盾

如今，各類技術紛繁復雜，各類想法如雨后春筍般冒出，要跟上市場的節(jié)奏，要求我們必須有足夠的反應速度和研究深度。在產(chǎn)品初期，我們往往需要的是快速實現(xiàn)基本功能，產(chǎn)品的上市后，我們需要不斷的優(yōu)化用戶體驗，這個時候需要我們在需求、交互、軟件方案進行深入研究改善。因此，從需求出發(fā)，兩者都不能少。

• 識別獨立的核心領域，專人跟進研究，不參與敏捷迭代。
• 豐富領域內(nèi)文檔沉淀，提高新手上手速度，避免踩同樣的坑。
• 團隊內(nèi)在迭代開發(fā)過程中，根據(jù)人員特點，重點培養(yǎng)其核心領域，促使團隊在整體上各項領域均研究深入。
• 逐步識別細分領域，將各項細分領域?qū)I(yè)化，系統(tǒng)化，模塊化。

2.3.5. 專業(yè)團隊集中辦公與敏捷團隊集中辦公矛盾

這個問題其實與“專業(yè)團隊與敏捷團隊矛盾”類似，這里的意見和之前的一致。

2.4.總結

在個人效率與團隊效率上，沒有絕對正確的方案，在智能手表這個產(chǎn)品領域，我們現(xiàn)在采用本章描述的方式進行取舍。它還有很多問題，并且存在一定的改善空間，但是這些問題，不能簡單的根據(jù)我們的經(jīng)驗得出結論，需要相關的數(shù)據(jù)支持以及對應的方案實施驗證。因此，需要不斷的思考和嘗試，也需要下一章節(jié)的研發(fā)閉環(huán)來有效的衡量和評估方案的有效性和其帶來的實際效益。

3.研發(fā)閉環(huán)

談到閉環(huán)，我們往往會想到大數(shù)據(jù)，因為現(xiàn)在人人都談大數(shù)據(jù)。不談它，感覺自己都不是做產(chǎn)品的人一樣。說得好，不如做得到，相比于產(chǎn)品級的大數(shù)據(jù)研究，在整個研發(fā)流程中，記錄好各個節(jié)點的情況，識別出研發(fā)過程中的各項瓶頸和問題，做到可追溯，可分析，也顯得十分的重要。

但是在開始記錄數(shù)據(jù)之前，我需要著重聲明一下：我們一定要避免什么數(shù)據(jù)都記錄，因為我們總感覺每一項數(shù)據(jù)都有它的意義。讓數(shù)據(jù)產(chǎn)生它應有的價值才更重要，數(shù)據(jù)驅(qū)動改善研發(fā)流程，需要以迭代的思想逐步優(yōu)化，不能一蹴而就。

3.1.瓶頸識別

每個專業(yè)領域都有它固有的研發(fā)效率，產(chǎn)品研發(fā)就像多條并行生產(chǎn)的流水線，需要經(jīng)歷一個又一個的環(huán)節(jié)，如果每個環(huán)節(jié)都保持著忙碌，那么效率最低的環(huán)節(jié)決定了整個研發(fā)團隊效率。尤其是上下銜接的兩個環(huán)節(jié)，如果的生產(chǎn)與消費不匹配，就是導致資源不足或者資源浪費問題。

生產(chǎn)和消費必然不可能完全匹配，因此在軟件領域有隊列，在迭代領域有需求池，這些措施能解決一定的沖突。但是如果嚴重不匹配，例如生產(chǎn)者太強，那么最后任務就得不到及時的響應，尤其是產(chǎn)品研發(fā)領域，時機有時候很重要。如果消費者太強，又導致一定的資源浪費。因此，我們想要什么？快速，還是省資源？這決定了在整個團隊組建過程中人員的配比情況。

那么如何識別瓶頸？在產(chǎn)品研發(fā)領域主要包括以下流程：

識別瓶頸的核心思想在于評估相互連接著的兩個環(huán)節(jié)的匹配度和處理能力，因此我們需要任何一個功能在每個節(jié)點上的完成時間，當我們想識別在整個項目周期，各個領域的瓶頸問題時，我們只需要選取按照一周為一個節(jié)點進行計算分析，就能得出對應的上下兩個環(huán)節(jié)生產(chǎn)與消費是否匹配，從而識別瓶頸領域。

3.2. 研發(fā)效率量化

在3.1中，我們記錄了每個功能在每個環(huán)節(jié)上完成的時間，基于該數(shù)據(jù)，我們可以做以下這些事情：

• 尋找生產(chǎn)大于消費的時間區(qū)間，計算此時消費者的效率，該效率基本能代表該專業(yè)領域的實際研發(fā)效率。
• 基于得出來的實際研發(fā)效率，對比每月的實際生產(chǎn)率，分析當前是否存在人員閑置，或者利用不足。
• 對比多月的實際研發(fā)效率，用于評估在領域優(yōu)化，或者敏捷流程優(yōu)化等方面的方案嘗試中，是否取得實際效果。

3.3. 定位問題點，針對性總結優(yōu)化

根據(jù)各個節(jié)點的數(shù)據(jù)，識別出在項目過程中開發(fā)進度不合理的功能，并進行階段性的總結分析，針對遇到的問題，制定對應的改善方案，持續(xù)優(yōu)化項目研發(fā)流程，在流程優(yōu)化過程中做到有理可依，有數(shù)據(jù)可以證明。

3.4. 總結

在控制領域，閉環(huán)是我們是系統(tǒng)達到穩(wěn)定的一個有效方案，例如在自動化原理里面提到的PID控制，它根據(jù)當前實際值與期望值的誤差計算，利用比例、積分、微分三個方面的反饋控制，使系統(tǒng)最終在期望值上下浮動，趨于相對穩(wěn)定。對于我們的產(chǎn)品研發(fā)，同樣需要類似的反饋系統(tǒng)形成閉環(huán)，這樣我們的研發(fā)體系才能有預期，研發(fā)進度才可控，做到心中有數(shù)，百戰(zhàn)不殆。

本文由 @空穴來風 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。