久久久精品午夜免费不卡,国产精品欧美成人,欧美最猛黑人xxxx黑人猛交

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

為什么產(chǎn)品經(jīng)理需要關注開發(fā)模式？

產(chǎn)品大蔥

2020-04-29

2 評論 12587 瀏覽 58 收藏

19 分鐘

本文旨在引導產(chǎn)品從業(yè)人員關注和重視開發(fā)模式問題，隱去了各模式的實施細節(jié)和管理復雜性。文章介紹了常見的5種開發(fā)模式，并對各模式進行了分析，與大家分享。

我一個產(chǎn)品經(jīng)理（本文泛指產(chǎn)品人員）為何要關注開發(fā)模式，開發(fā)的事不是技術的事嗎？那不是技術團隊該關心的事嗎？

一、為什么產(chǎn)品經(jīng)理需要關注開發(fā)模式？

1. 開發(fā)模式即工作模式

首先我們要達成一個共識：產(chǎn)品經(jīng)理除了收集分析需求、拋出草案、定方案、輸出原型、prd、流程圖、架構圖等專業(yè)工作之外，還需要負責協(xié)調(diào)資源、上傳下達等保障整個研發(fā)順利進行的工作。產(chǎn)品經(jīng)理是貫穿始終從頭走到尾并對最終結果負責的人。

互聯(lián)網(wǎng)軟件研發(fā)周期中的各團隊參與情況和當前項目所處的階段，大略劃分的話可以有如下關系：

完成軟件開發(fā)所要進行的工作和各團隊之間大致有如下關系：

為什么有交叉？

設計工作不僅僅是產(chǎn)品經(jīng)理設計產(chǎn)品方案，拿到產(chǎn)品方案后研發(fā)團隊需要構建同樣重要的技術方案。
測試方面，測試團隊肯定是主角，進行項目質(zhì)量的整體驗收。除了這些還有研發(fā)團隊研發(fā)過程中的單元測試，提測前的整體自測，還有產(chǎn)品同學的輔助測試和上線后回歸測試等。
至于部署方面，硬件方面的事情自然運維團隊去處理，但設備選型則是技術方案的一部分。另外有的公司是技術團隊負責發(fā)布代碼，有的是運維同學進行發(fā)布。

各團隊之間看起來相互獨立，各司其職，實則緊密相連，不可分割。無論開發(fā)模式是不是技術團隊該關心的事，它都不可避免地會影響整個研發(fā)過程。各團隊為了消除這種影響，需要調(diào)整工作方式去配合，這樣才能釋放出相應模式的優(yōu)勢力量，達到整體最佳。

2. 熟練掌握開發(fā)模式的好處

第一：加入一個新團隊，能識別出當前團隊正在采用的開發(fā)模式，可以快速適應節(jié)奏展開工作，更順利更少犯錯。試想如果人家在采用敏捷開發(fā)，而你帶著瀑布開發(fā)的思維投入工作并產(chǎn)出，團隊首秀上來就挖坑，想想都覺得可怕。

第二：清楚團隊當前工作模式的優(yōu)勢和局限，在局限性方面就可以提前做好準備，不至于當問題發(fā)生時措手不及，處于被動的局面被牽制住。問題的產(chǎn)生很有可能是團隊工作方式的弊端帶來的而非你個人能力的問題，這個鍋不能背。

第三：以第二點為基礎，清楚局限可以有意識盡所能去優(yōu)化，無論對個人發(fā)展還是公司效率，都是極好的。

二、各開發(fā)模式相互對比

一款產(chǎn)品不是孤立的，它是和自身、公司、競品、行業(yè)、用戶群等相互關聯(lián)的，共同作用下的一個結果，我們研發(fā)一款產(chǎn)品，是基于一定需求痛點，服務于特定人群的。在信息過載、要求快速響應的互聯(lián)網(wǎng)世界里，開發(fā)過程的靈活性和用戶參與程度被越來越多的關注和利用。

當下公司所采用的開發(fā)方式有N多種，每一種都是特定場景下的特定產(chǎn)物，沒有絕對的優(yōu)劣，適合最重要。我們先從操作靈活性、用戶參與度兩個維度對當下流行的開發(fā)模式做一下全局預覽。

三、5種常見開發(fā)模式介紹

我們選取了4種典型的開發(fā)模式進行說明，這4種模式有的是默認選擇的，可能你在用但是你自己沒意識到；有的是當下熱議的；有的是用于增加項目透明度可以隨時引入新的變更需求的；有的是應對老板一聲令下要求即刻上線的。

1. 瀑布式開發(fā)

各個階段從上到下，一步一步地走，是不是很像瀑布，水從上流淌而下。

瀑布模型式是最典型的預見性的方法，是開發(fā)方法論的老大哥，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。只能一個階段一個階段的執(zhí)行，不可回溯。每個階段都需要獨立評估，準確無誤的輸出，完整的文檔。上一個階段結束前，下一個階段不能開始。直到最后部署交付，期間都拿不到切實可應用的項目。

這是大多數(shù)團隊默認采用的一種模式，甚至常用到自己在用它，但是都不知道它就是瀑布式開發(fā)。采用瀑布開發(fā)方式的用戶常見于新負責的項目經(jīng)理因為這種方式對項目的估計非常方便。項目開發(fā)中涉及到的幾乎一切都預先計劃，從而便于確定預期的開發(fā)成本和開發(fā)時間，非常方便地把整個項目置于自己的掌握之下。

缺點也很明顯，任何人都不能預知未來，做出來的方案也都不是完美無瑕，計劃趕不上變化，每個階段環(huán)環(huán)相扣，任何一個階段出問題，都可能導致延期甚至項目失敗。另外對于開發(fā)人員而言就可能顯得太嚴酷了。因為測試過程在開發(fā)階段之后實施，子系統(tǒng)測試所暴露的問題可能需要立即修改代碼，而開發(fā)人員一般在同一階段也會從事其他的開發(fā)任務，而所需要的軟件修改可能會降低開發(fā)人員的生產(chǎn)率和工作質(zhì)量，這樣就顯著增加了計劃架構的成本。

2. 增量和迭代開發(fā)

增量和迭代其實是兩種開發(fā)方式。

增量開發(fā)是把項目切割成N個相對獨立的模塊。像堆積木一樣，每次迭代會增加新的軟件模塊，而在先前添加的模塊中幾乎沒有變化。開發(fā)過程可以順序進行，也可以并行進行，并行開發(fā)提高了交付速度。

這就要求產(chǎn)品經(jīng)理在分析設計階段，要充分考慮研發(fā)資源問題。如果研發(fā)資源有限，我們把項目切分成塊后勢必要按緊急、重要程度進行排序，業(yè)務人員會牽扯進來。如果研發(fā)資源充足，分析設計階段產(chǎn)品經(jīng)理會很忙，我們要在設計階段過后輸出的是供好幾個研發(fā)組并行開發(fā)的子模塊原型、PRD、流程圖等，當然如果你是個產(chǎn)品leader的話，就可以授權下面人去分頭行動了。

迭代開發(fā)和增量開發(fā)類似，也是把一個大任務切分成N個子任務。與增量模式各模塊間相對獨立不同，迭代開發(fā)的每次迭代任務都是以上一次迭代為基礎進行的。由于軟件是分部分交付的，因此從項目開始就不需要完整的規(guī)范，并且在開發(fā)過程中可能會對需求進行少量更改。但是，需求不能根本改變，必須在開始時就定義主要需求。

這就要求產(chǎn)品經(jīng)理每次迭代都要留下足夠清晰的文檔，供后來人能接著繼續(xù)迭代開發(fā)，后來人可能是公司其他產(chǎn)品經(jīng)理，也可能是新來的產(chǎn)品經(jīng)理。如果你是一個產(chǎn)品leader，如果你們公司項目采用的是迭代開發(fā)模式，如果你不想因為某個人的離職導致開發(fā)組陷入一團糟的話，就提前要有這方面的要求和準備。

如果把增量開發(fā)看作是橫向開發(fā)的話，那迭代模式就是縱向開發(fā)。增量迭代模式的優(yōu)點是如果失敗，影響的只是一部分而非整個項目，降低了損失。軟件更容易成功，通過先前的上線版本收集用戶反饋，結合反饋作出下一次迭代方案，小步快跑更容易成事。缺點是因為增量開發(fā)是拆開成塊，如果開發(fā)過程中沒有溝通好，或者文檔不清晰，會導致后期合在一起的時候出問題。

3. 看板開發(fā)

大家經(jīng)常聽到敏捷開發(fā)，其實敏捷開發(fā)不是一個模式，而是一組模式的統(tǒng)稱。本節(jié)講的看板開發(fā)和下節(jié)的極限編程都屬于敏捷開發(fā)，除此之外還有Scrum。

如果說瀑布模式是一種自上而下的驅(qū)動方式，那么看板模式就是一種自下而上的驅(qū)動方式。后道工序在需要時，通過看板向前道工序發(fā)出信號，請給我需要數(shù)量的輸入。前道工序只有得到相應看板后，才啟動任務。用戶需求為其中的原始驅(qū)動力。

看板模式?jīng)]有明顯的迭代過程，沒有單獨的計劃階段，可以隨時引入新的變更需求。看板上的內(nèi)容堅持“即來即增加”和“即變即更新”的原則，團隊中的每個人都可以根據(jù)實際情況增加或者流動自己負責的任務。可以清晰地看到所有項目活動，任務數(shù)量，負責人和進度。這種增加的透明度有助于更準確地估計最緊要的任務，項目組也更加趨向于自動化。

站立會是看板開發(fā)方式的一個顯著特征，每天開發(fā)組主要成員，一人一兩分鐘，交代下自己當前已完成的任務，正在進行的任務，有沒有遇到問題。之所以采用站立的形式，是因為不要在會上討論復雜的問題，產(chǎn)品經(jīng)理需要把控好站立會的時間。

復雜問題如需討論，單約專項會議進行。開發(fā)是環(huán)環(huán)相扣的，站立會會把問題提前拋出來，避免之前流程環(huán)節(jié)上的浪費。能帶來一種類似“Stop and Fix”的氛圍，出現(xiàn)問題時，能立刻暫停，分析根本原因，并加以解決，防止問題的再次發(fā)生。

但是這種方式，容易讓大家的注意力集中到某個點上而忽略其他點，不利于思維的發(fā)散。

4. 極限編程（XP）

極限編程和傳統(tǒng)開發(fā)模式的本質(zhì)不同在于它更強調(diào)可適應性以及面臨的困難，去掉了條條框框，更強調(diào)專注問題，快速解決。也可以理解為這是一種更“隨意”的開發(fā)方式，但是設計、編碼、測試環(huán)節(jié)依然存在，只是不拘泥于形式和流程。所以除了團隊成員之間需要相互熟悉、默契之外，在團隊文化方面也是有一定要求的，它的基礎和價值觀是交流、樸素、反饋、勇氣和尊重。適用于經(jīng)常發(fā)生變化的項目、緊急上線任務和封閉開發(fā)等。項目組人數(shù)也要進行控制，建議在2～10人之間。

在極限編程式開發(fā)中，經(jīng)常見到結對編程，即代碼由兩個人坐在一臺電腦前一起完成。一個程序員寫代碼關注編碼細節(jié)，另外一個人主要關注整體結構性的東西，不斷地對第一個程序員寫的代碼進行評審。團隊成員能夠長期維持努力工作的狀態(tài)，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。

代碼權限集體所有，每個人都可以更改代碼的任意部分，每個人都對所有的代碼負責。在XP中，沒有那種傳統(tǒng)開發(fā)模式中一次性的、針對所有需求的總體設計，設計過程幾乎一直貫穿著整個項目開發(fā)，而且實現(xiàn)方式簡單，能滿足需求、通過測試即可。

不推諉不扯皮，有話直說，對事不對人，勇于承擔任務，不逃避責任。這個“極限”就體現(xiàn)在把交流、反饋、勇氣、尊重這些最樸素的東西發(fā)揮到了極致。這種模式的弊端除了挑團隊之外，由于不拘泥形式，后期在文檔完整性上也會有所欠缺。

如果項目組成員有流動也會給開發(fā)帶來很大問題。因強調(diào)的是簡單設計簡單開發(fā)，更關注當下的需求滿足情況，所以后期重構的幾率會更大。但是這種模式所帶來的效率提升，結果導向性，在某些場景下是其他模式所不能取代的。