中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在控制領域，閉環是我們是系統達到穩定的一個有效方案，對于我們的產品研發，同樣需要類似的反饋系統形成閉環，這樣我們的研發體系才能有預期，研發進度才可控，做到心中有數，百戰不殆。

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

1.困境

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

簡單的分析上圖中的結構，智能手表的開發貌似和常規的互聯網產品類似，然而它的復雜性卻沒有看上去那么簡單，我們先簡單分析一下上圖：

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

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

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

備注：部分領域也許還有其他的關聯度，這里僅僅只考慮產品研發的主要場景。

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

1.1.領域細分的副作用

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

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

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

• 交互：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

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

1.2.總結

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

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

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

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

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

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

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

2.1.如何提高個體效率

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

2.2.如何提高團隊效率

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

2.3.矛盾與取舍

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

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

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

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

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

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

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

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

收益

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

損失

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

2.3.3. 專業團隊與敏捷團隊矛盾

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

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

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

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

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

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

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

2.3.5. 專業團隊集中辦公與敏捷團隊集中辦公矛盾

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

2.4.總結

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

3.研發閉環

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

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

3.1.瓶頸識別

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

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

那么如何識別瓶頸？在產品研發領域主要包括以下流程：

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

3.2. 研發效率量化

在3.1中，我們記錄了每個功能在每個環節上完成的時間，基于該數據，我們可以做以下這些事情：

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

3.3. 定位問題點，針對性總結優化

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

3.4. 總結

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

本文由 @空穴來風 原創發布于人人都是產品經理。未經許可，禁止轉載。