作為產(chǎn)品，如何有理有據(jù)地撕程序猿呢？如何把程序猿撕的無話可說，且直接認(rèn)慫呢？答案就是——了解程序研發(fā)流程中的點點滴滴，多用程序猿的視角與程序猿溝通問題，提高產(chǎn)品研發(fā)效率，盡可能減少撕的環(huán)節(jié)。

產(chǎn)品原型制作完成了，下一步的工作就是將原型及相關(guān)文檔交付給開發(fā)團(tuán)隊進(jìn)入到產(chǎn)品開發(fā)環(huán)節(jié)。這時，作為產(chǎn)品經(jīng)理的你，終于可以稍微松一口氣了。但是，并不是這以后的事情和自己沒關(guān)系了！

作為一個產(chǎn)品，你應(yīng)該是無所不能的，從產(chǎn)品、交互設(shè)計、開發(fā)到運營，所有的知識不能說精通但是都要略懂。這樣一來，無論在創(chuàng)業(yè)公司需要一人兼多職還是在大公司與其他同事有良好的溝通、寫作都是可以勝任的。

說到軟件開發(fā)流程與管理，有很多堪稱經(jīng)典的書講解得要深刻的多。在這里，筆者只是對常用的軟件開發(fā)流程進(jìn)行大致的介紹，但具體到各個公司不同的開發(fā)團(tuán)隊?wèi)?yīng)用的具體方法還會有所不同。在此，希望各位通過對基本的了解，在進(jìn)入公司后才能夠盡快與開發(fā)團(tuán)隊達(dá)成默契。

瀑布模型

瀑布模型是1970年由溫斯頓·羅伊斯提出的軟件開發(fā)模型，直到80年代早期還在軟件開發(fā)界被人們所沿用。

瀑布模型的核心思想是按照工序?qū)栴}分階段化簡，將功能的實現(xiàn)與設(shè)計分開，采用結(jié)構(gòu)化的分析與設(shè)計方法將邏輯實現(xiàn)與物理實現(xiàn)相分離。它將軟件的生命周期分為：制定計劃、需求分析、軟件設(shè)計、程序編寫、軟件測試和運行維護(hù)六個階段，并規(guī)定了它們自上而下的固定順序，如同瀑布一樣落下。

瀑布模型的優(yōu)點：

• 明確了不同階段的任務(wù)目標(biāo)
• 可以分階段檢驗階段進(jìn)度
• 當(dāng)前一階段任務(wù)完成后，只需關(guān)注后續(xù)階段任務(wù)（這同時也是一個缺點）

瀑布模型的缺點：

• 在階段間極少有反饋
• 只有在項目最后階段才能看到項目效果
• 無法適應(yīng)需求的變化，因為需求階段一旦完成就不會再又變動

通過瀑布模型的缺點可以發(fā)現(xiàn)，這和互聯(lián)網(wǎng)時代的產(chǎn)品設(shè)計理念有很大的沖突。因為瀑布模型后一個階段必須在前一個階段完成后才會開始，這讓需求的變動變成了不可能。但是在互聯(lián)網(wǎng)時代用戶的需求變化速度是很快的，產(chǎn)品從開發(fā)到最終發(fā)布的過程中要面對需求頻繁變化的可能性。為了適應(yīng)用戶不斷變化的需求以及產(chǎn)品的快速開發(fā)發(fā)布，誕生了敏捷開發(fā)模型。

敏捷開發(fā)模型

敏捷開發(fā)是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)模型。敏捷開發(fā)強調(diào)程序員團(tuán)隊與業(yè)務(wù)專家之間的緊密協(xié)作、面對面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊組織方法，也更注重做為軟件開發(fā)中人的作用。

不同的公司或不同的開發(fā)團(tuán)隊所遵循的敏捷開發(fā)方式可能會有所差異，但是它的本質(zhì)都是為了增加人與人間的溝通以及頻繁交付軟件版本，不斷的開發(fā)與更新符合用戶需求的軟件。

敏捷開發(fā)是一種軟件開發(fā)模型，根據(jù)這種思維方式衍生出了很多種具體的敏捷開發(fā)實現(xiàn)方法，這其中極限編程XP和Scrum是實際開發(fā)過程當(dāng)中經(jīng)常使用的兩種實現(xiàn)方法。這里只介紹其中的一種：Scrum。

Scrum

Scrum一詞來自英式橄欖球運動，本質(zhì)含義就是一群人你推我搡地去搶球和控球。用球賽來類比確實是一個形象又合適的比喻，在賽場上盡管隊員們努力按照既定計 劃推進(jìn)，但是場上瞬息萬變，不可能實時按照教練或者隊長的指令亦步亦趨的去行事，只能靠平時訓(xùn)練中形成的素養(yǎng)見機(jī)行事，達(dá)成目標(biāo)。

Scrum的核心思想是首先承認(rèn)我們的用戶并不清楚自己的需求，并且人類的需求會不斷變化的，所以我們默認(rèn)需求是變化的需求，并且制定一套策略對小功能快速開發(fā)，通過后續(xù)不斷迭代完善產(chǎn)品。

Scrum三大角色

1. 產(chǎn)品經(jīng)理：產(chǎn)品功能和需求的確定者，明確產(chǎn)品不同版本需要實現(xiàn)的功能。
2. 流程管理員：負(fù)責(zé)整個Scrum流程的順利實施，項目經(jīng)理的角色。
3. 開發(fā)團(tuán)隊：負(fù)責(zé)產(chǎn)品的開發(fā)工作，不同的開發(fā)成員負(fù)責(zé)不同的模塊或功能，通過協(xié)作完成整體任務(wù)的完成。

Scrum開發(fā)模型

1. 產(chǎn)品經(jīng)理根據(jù)用戶需求以及產(chǎn)品設(shè)計制定產(chǎn)品需求列表
2. 開發(fā)團(tuán)隊對需求進(jìn)行工作量和時間評估，并和產(chǎn)品經(jīng)理共同制定一個迭代周期內(nèi)需要實現(xiàn)的需求列表。
3. 開發(fā)團(tuán)隊進(jìn)入開發(fā)迭代周期（根據(jù)實際情況設(shè)定周期在1-4周）進(jìn)行產(chǎn)品開發(fā)，在開發(fā)過程中會有每日站立會成員間對開發(fā)中遇到的問題進(jìn)行討論，開發(fā)成員對各自負(fù)責(zé)需求進(jìn)度進(jìn)行更新，共享整體工作信息。
4. 每一個迭代周期結(jié)束時都要保證輸出一個可發(fā)布版本，所有團(tuán)隊成員進(jìn)行回顧會議，對迭代周期中遇到的所有狀況進(jìn)行回顧，吸取經(jīng)驗教訓(xùn)，為下一個迭代周期的工作做準(zhǔn)備。

總結(jié)

產(chǎn)品初期設(shè)計完成后，從研發(fā)階段到后續(xù)版本頻繁迭代升級，每一次的變動都少不了和研發(fā)團(tuán)隊打交道的機(jī)會。通過產(chǎn)品的視角去看待產(chǎn)品敏捷開發(fā)全流程，在與研發(fā)團(tuán)隊溝通過程中可以更好地站在對方角度思考問題，減少“撕”的幾率，提高產(chǎn)品研發(fā)、迭代效率，打造更好的產(chǎn)品。

作者：記小憶，陷入產(chǎn)品無法自拔的偽碼農(nóng)！微信公眾號：“PM龍門陣”，大擺龍門陣，產(chǎn)品有鴻儒！

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