本人一年多產(chǎn)品經(jīng)驗菜鳥咬腋，這篇文章主要是對自己的工作進行復(fù)盤之余斋否，也希望能夠為一些剛剛工作的或者正想入坑的產(chǎn)品新人一些理解和思考。
ps：本篇文章只是對工作流程的基礎(chǔ)總結(jié)赋铝，每個工作節(jié)點不會特別細致的進行展開旋奢，沒講到位的地方大家互相交流泳挥，如有不合理處請指導(dǎo)，勿噴勿噴哈哈哈哈～～～
一至朗、產(chǎn)品經(jīng)理&項目經(jīng)理職責(zé)邊界
1屉符、介紹
本菜鳥就職于一家致力于為B端做企業(yè)信息化服務(wù)解決方案的中小型公司，所以產(chǎn)品的輸出形式基本上都是以項目的形式來進行和交付锹引。在日常的工作中矗钟，我們產(chǎn)品經(jīng)理不僅要做好職責(zé)之內(nèi)的工作，同時我們也會有涉及到項目經(jīng)理的一些工作嫌变。因此我們的工作職責(zé)相較于打造自研產(chǎn)品的互聯(lián)網(wǎng)公司來說吨艇，可能更加瑣碎，橫向的學(xué)習(xí)和發(fā)展會更多一些腾啥，但是對于垂直行業(yè)的經(jīng)驗積淀來說东涡，就比較少了冯吓。
2、產(chǎn)品經(jīng)理職責(zé)
（1）機會評估
工作內(nèi)容：整理產(chǎn)品方案软啼、評估需求成本
主要節(jié)點：項目預(yù)研階段
主要參與：項目經(jīng)理（整理整體方案）桑谍、產(chǎn)品經(jīng)理（整理產(chǎn)品方案）延柠、技術(shù)經(jīng)理（整理技術(shù)方案祸挪，評估技術(shù)可行性）、商務(wù)經(jīng)理（配合對需求把關(guān)）
（2）需求收集
工作內(nèi)容：包括但不限于以下幾種方法：用戶訪談贞间、頭腦風(fēng)暴贿条、卡片分類、問卷調(diào)查等等
主要節(jié)點：項目預(yù)研階段
主要參與：整個項目組
（3）需求管理
工作內(nèi)容：PRD需求文檔增热、需求管理文檔
主要節(jié)點：項目計劃階段
主要參與：產(chǎn)品經(jīng)理
（4）需求設(shè)計
工作內(nèi)容：產(chǎn)品架構(gòu)圖整以、功能結(jié)構(gòu)圖、業(yè)務(wù)流程圖（UML）峻仇、UE原型
主要節(jié)點：項目實施階段
主要參與：產(chǎn)品經(jīng)理
（5）需求評審
工作內(nèi)容：項目組成員評估需求可行性和工作量
主要節(jié)點：項目實施階段
主要參與：整個項目組
（6）需求實施
工作內(nèi)容：各崗位成員按照需求進行設(shè)計公黑，并及時溝通需求細節(jié)
主要節(jié)點：項目監(jiān)控階段
主要參與：整個項目組
（7）產(chǎn)品驗收
工作內(nèi)容：根據(jù)需求和用例進行驗收
主要節(jié)點：項目交付階段
主要參與：產(chǎn)品經(jīng)理
3、項目經(jīng)理職責(zé)
項目經(jīng)理的工作流程大致可以分為項目預(yù)研摄咆、項目啟動凡蚜、項目計劃、項目實施吭从、項目監(jiān)控朝蜘、項目交付幾個階段。
（1）項目預(yù)研：
項目組前期預(yù)備階段涩金，此時不一定會對該項目進行正式立項谱醇，僅僅作為售前支撐需要成立的臨時項目組
工作內(nèi)容：整理項目建設(shè)方案
主要參與：項目經(jīng)理（整理整體方案）、產(chǎn)品經(jīng)理（整理產(chǎn)品方案）步做、技術(shù)經(jīng)理（整理技術(shù)方案副渴，評估技術(shù)可行性）、商務(wù)經(jīng)理（配合對需求把關(guān)）
（2）項目啟動：
在此階段我們首先應(yīng)該成立項目組進行立項全度，正確的識別干系人佳晶，并將各崗位的人員確定下來，方便后續(xù)的工作正常進行讼载。
工作內(nèi)容：確定項目組成員轿秧、明確項目干系人的期望、明確項目目標(biāo)咨堤、明確項目需求菇篡、項目計劃排期
主要參與：整個項目組
（3）項目計劃：
在此階段主要是對需求進行拆解成任務(wù)進行分配，并由各崗位負責(zé)人對任務(wù)進行工期估算一喘，進行排期
工作內(nèi)容：任務(wù)分配驱还、工期估算嗜暴、時間進度安排（甘特、燃盡圖）议蟆、風(fēng)險控制闷沥、版本管理
主要參與：整個項目組
（4）項目實施：
在此階段各崗位工作進入設(shè)計，并進行評審咐容。
工作內(nèi)容：需求設(shè)計&評審舆逃、UI設(shè)計&評審、代碼設(shè)計&評審戳粒、測試用例&評審
主要參與：整個項目組
（5）項目監(jiān)控：
在此階段主要對項目進度進行跟進路狮，及時更新任務(wù)狀態(tài)，提前對風(fēng)險進行預(yù)警
工作內(nèi)容：每日例會蔚约、每日日報奄妨、每日任務(wù)更新、人員表現(xiàn)苹祟、風(fēng)險預(yù)警
主要參與：項目經(jīng)理
（6）項目交付：
在此階段對項目進行內(nèi)部驗收砸抛，并整理需要交付的文檔
工作內(nèi)容：驗收報告、上線報告树枫、需求文檔直焙、數(shù)據(jù)庫設(shè)計文檔、接口文檔
主要參與：項目經(jīng)理
二团赏、項目型產(chǎn)品經(jīng)理工作流程
1箕般、項目預(yù)研
項目預(yù)研階段（各公司可能叫法不同），如字面意思就是項目在前期進行預(yù)先調(diào)研舔清，研究丝里。在此階段會先成立一個臨時項目組，甚至于可能就只有一個人去進行前期調(diào)研体谒，按照以往相似的案例或者網(wǎng)上的案例整理出來項目的可行性方案和建設(shè)方案杯聚。以下圖1為我們常用的建設(shè)方案文檔結(jié)構(gòu)目錄。
大家可以發(fā)現(xiàn)幌绍，對于我們產(chǎn)品經(jīng)理的工作而言，在第二部分（項目需求分析）和第四部分（平臺功能介紹）是我們主要的工作內(nèi)容故响。所以可能在項目之初傀广，我們就要配合進行需求調(diào)研，輸出一些初期的文檔彩届，如產(chǎn)品需求文檔（以下節(jié)點再展開說明）伪冰、產(chǎn)品的架構(gòu)圖、產(chǎn)品功能結(jié)構(gòu)圖樟蠕，根據(jù)客戶需要甚至于會輸出部分原型圖贮聂。如下圖2為我司預(yù)研的項目架構(gòu)圖靠柑，圖3產(chǎn)品功能結(jié)構(gòu)圖
2歼冰、項目啟動
在此階段我們首先應(yīng)該成立項目組進行立項（一般會組織開一次項目啟動會議），正確的識別干系人耻警，并將各崗位的人員確定下來隔嫡，方便后續(xù)的工作正常進行。
工作內(nèi)容如下：
（1）確定項目組成員
一個項目的啟動榕栏，一般來說第一步是需要確定項目組的成員畔勤，然后必須明確項目經(jīng)理即項目負責(zé)人蕾各。我們公司一般是在項目啟動時扒磁，先自己大致評估需要的人員配置，然后和各部門的負責(zé)人評估和確定項目組成員式曲。如下圖4所示：
（2）明確項目干系人的期望
在《軟件需求工程第3版》-KarlWiegers的書籍中有說到項目干系人應(yīng)該包括所有和項目有關(guān)的人，包括商務(wù)和客戶吝羞。所以在此處兰伤，項目經(jīng)理或者產(chǎn)品經(jīng)理需要闡述來自客戶對該項目的期望，通俗的講即為客戶需求钧排。同時可能還有包括來自項目干系人各方面的期望敦腔，比如小公司的老板可能也會直接參與項目，希望將該項目的某些文檔恨溜，代碼標(biāo)準(zhǔn)化下來作為案例能夠?qū)ν膺M行銷售符衔。又比如說商務(wù)期望開發(fā)周期盡量縮短，先給客戶交付一個基礎(chǔ)產(chǎn)品糟袁，能夠盡快回款判族。總之我們需要在啟動會議將干系人的期望共同進行探討项戴，并達成項目組的共識形帮。一般來說此處不一定會生成專門的文檔，通常都是會議紀(jì)要同步郵件周叮。
（3）明確項目目標(biāo)
項目管理中辩撑，不論是瀑布開發(fā)還是敏捷開發(fā)模型，都必須會要確定項目目標(biāo)仿耽。比如確定項目計劃合冀，確定里程碑，確定項目章程氓仲。還有包括交付時的流程水慨，需要哪些文檔得糜，有什么交付標(biāo)準(zhǔn)（注意此處在很多小公司都很隨意，但是我們公司是真實吃過虧的）我們有以前開發(fā)的一個項目當(dāng)中晰洒，在項目前期由于客戶對工期的要求比較緊急朝抖，而且項目初步預(yù)測是比較簡單的，所以在商務(wù)階段就過早將項目啟動谍珊，然而交付的流程和交付標(biāo)準(zhǔn)都沒有確定（因為一開始覺得客戶還是很好說話的治宣，所以大家都很配合）。結(jié)果天天加班趕著交付時間進行交付之后砌滞，由于沒有明確的交付標(biāo)準(zhǔn)侮邀，所以客戶反復(fù)提出更多一些想法，對體驗的優(yōu)化等等（當(dāng)然我很理解客戶希望能夠收到一個心滿意足的擁有極致體驗的產(chǎn)品贝润，但是用戶的需求隨著不同的階段绊茧，使用的增加會有更多的需求，不然何來的敏捷開發(fā)呢哈哈）打掘，但是客觀上來說华畏，我們項目組預(yù)計本應(yīng)該釋放的資源缺遲遲抽不出來，幾乎往后的很長一段時間都保持著極高頻率的迭代優(yōu)化期尊蚁。
（4）明確項目需求
這一部分主要是對需求進行評審（由于在預(yù)研階段產(chǎn)品經(jīng)理基本都會對需求整理一份初步的文檔）亡笑，項目組成員對需求進行評審，除了砍掉不合理需求之外横朋，也要對合理的需求按照優(yōu)先級進行大致的排期仑乌。當(dāng)成員達成共識后，由各崗位的負責(zé)人評估工作周期琴锭。
（5）項目計劃排期
最后就是對項目計劃進行排期晰甚，首先這個項目完全交付，分成幾個階段祠够，每個階段的時間安排周期压汪，在這個階段內(nèi)，各崗位成員做什么古瓤，時間周期多久止剖。都應(yīng)該列出來一份文檔，或者利用項目管理工具進行管理落君，此處可以用到甘特圖進行管理穿香，或者一些項目管理工具，如禪道绎速、TAPD皮获、Teambition等等，如下圖5纹冤。（此時項目計劃排期顆粒度還比較大洒宝，主要是明確每個崗位的工作節(jié)點）
3、需求收集
對于項目型產(chǎn)品來說雁歌，直接用戶是相對較少的宏浩，而且我們的每一個客戶基本都屬于我們的特征客戶（不然他們不會花錢來使用），所以客戶來源相對容易靠瞎，但是我認為需求收集還是至少要分成兩種情況來確定收集方式比庄。
情況一：項目還未交付
對于需求收集來說，從0到1階段其實是比較難的乏盐。首先你的大部分需求是直接來自于你的客戶佳窑，但是客戶提出的需求很多是不合理的，并且可能并不是來自于他的真實訴求父能，可能說只是覺得同類型的產(chǎn)品有神凑，那么就要。這個時候就比較考驗產(chǎn)品經(jīng)理的需求分析能力了法竞，客戶直接提出的必然是顯性需求耙厚，那么你是否能夠透過現(xiàn)象看到本質(zhì)强挫，挖掘出客戶的隱形需求岔霸，并提出解決方案去給客戶選擇（此處《軟件需求工程》有專門講解顯性需求和隱形需求）。
主要收集方式：
用戶訪談：此方法是我在該情況下常用的方式俯渤，大佬們都說過讓用戶定義產(chǎn)品嘛呆细。主要是通過和客戶進行當(dāng)面的溝通，通過一些事先準(zhǔn)備的問題引導(dǎo)客戶說出他們的需求八匠。但是往往不專業(yè)的客戶在沒有看到實物的時候并不知道自己需要什么絮爷，想法和需求都來源于目前線下傳統(tǒng)的流程之中。如果單純按照客戶的業(yè)務(wù)需求直接搬到線上來梨树，其實是不一定會真正讓客戶獲得優(yōu)質(zhì)的體驗坑夯，甚至可能加大用戶的使用門檻（畢竟很多傳統(tǒng)行業(yè)的領(lǐng)導(dǎo)連智能手機和電腦都用不習(xí)慣，還只局限于通訊需求）
頭腦風(fēng)暴：此方法其實在行業(yè)內(nèi)比較常見抡四，主要就是讓項目組成員能夠針對該項目柜蜈，提出自己的想法，設(shè)想可能存在的需求指巡。因為從0到1階段淑履，客戶是沒有概念，他們甚至說不清楚他們要什么藻雪，所以我們可能會提前先通過網(wǎng)上找案例等方式先項目組討論秘噪，確定一個我們都認為可以的需求，然后再去找客戶去講解勉耀，在這個過程中就經(jīng)常能夠引導(dǎo)出來用戶的需求指煎，客戶經(jīng)常會提出蹋偏，這個地方我們可能不是這樣做的，我們可能不需要至壤。
卡片分類（項目組）：卡片分類也是行業(yè)內(nèi)很常見的需求收集方式暖侨，主要是通過列出所有的需求，讓每位成員按照自己的理解去對需求進行分類崇渗，劃分結(jié)構(gòu)層級字逗。我在此方法后面加了個小括號（項目組），還是因為客戶對需求沒有概念宅广，他可能都不知道這個功能有什么用葫掉，實現(xiàn)出來什么樣子，怎么交互的跟狱。如果讓客戶在這個階段參與這個過程會對分類造成很大的誤差俭厚。所以我們暫且是靠項目組各位成員的經(jīng)驗來進行的。
客戶需求評審：這一個階段就是將整理好的需求驶臊，或者設(shè)計的原型給客戶進行講解挪挤、演示。在這樣的情況下关翎，客戶大概能知道這個產(chǎn)品的雛形是什么樣子扛门，自然而然的就會提出一些他的需求（這個其實是效率比較高的方式）
情況二：至少已經(jīng)有同類型交付的產(chǎn)品（或迭代期間）
在這樣的情況下一般是客戶已經(jīng)比較了解同類型產(chǎn)品或者是已經(jīng)在使用我們的產(chǎn)品。那么客戶往往會提出各種各樣的問題纵寝，這個時候主要的工作并不是需求來源论寨，而是對需求的合理性進行把控，即便合理的需求也有可能很多（因為往往從0到1的產(chǎn)品功能比較基礎(chǔ)爽茴，一般以滿足客戶的必備需求為主葬凳，所以還有很大的優(yōu)化空間），這個時候你要將收集來的需求進行簡化、并合理的進行排期。
主要收集方式：
客戶建議反饋：在這種情況下最主要的需求來源必然是在使用我們產(chǎn)品客戶光酣，所以直接問客戶就好了任斋，當(dāng)然你不問他他也會找你提出來的，具體把控下節(jié)“需求管理”再展開。（表示我現(xiàn)在被幾個負責(zé)項目的客戶窮追不舍）
測試反饋：如果你們公司有個好的測試真的會很幸運，一個好的測試能為產(chǎn)品經(jīng)理減少很多麻煩。測試最主要的輸出文檔之一就是測試用例江场，測試用例理應(yīng)覆蓋整個產(chǎn)品的方方面面，那么在測試整理測試用例的時候窖逗，或者日常進行測試的時候址否。很有可能就會發(fā)現(xiàn)在評審之初沒有發(fā)現(xiàn)的需求不合理之處，尤其是對于用戶體驗的問題測試經(jīng)常能夠發(fā)現(xiàn)。
4佑附、需求管理
在此階段至少需要兩個文檔：需求管理文檔樊诺、PRD需求文檔。
（1）需求管理文檔：在上述需求收集中說過音同，客戶可能會提出非常多的需求词爬，并且中間包含很多不合理的需求。這個時候即便是經(jīng)驗很豐富的產(chǎn)品經(jīng)理权均，也應(yīng)該將所有的需求收集起來顿膨。一是因為你可能一時之間無法很清晰的作出決定來判斷這個需求是否合理；二是因為客戶經(jīng)常提出的需求只是隨口一說叽赊，說完就忘記了恋沃。當(dāng)他下次再提出的時候，可能規(guī)則就改了必指，即便兩種實現(xiàn)方式都是合理的囊咏，但如果你沒有記錄會導(dǎo)致項目組又會重新進行返工。所以我們需要一個需求管理文檔來記錄收集來的用戶需求塔橡，如圖6所示：
然后每過一段時間（具體按公司業(yè)務(wù)規(guī)范而定）項目組開會進行一次需求評審。一般來說影響業(yè)務(wù)流程的需求是優(yōu)先級比較高的葛家，客戶的必備需求也是優(yōu)先級比較高的户辞，至于客戶的期望需求，界面友好性的需求相對來說優(yōu)先級會低一些惦银。當(dāng)然這是在開發(fā)資源有限的情況下不得不劃分優(yōu)先級咆课。然后將評審?fù)ㄟ^的需求按照優(yōu)先級進行排期，并將同期的需求建立一個文件夾扯俱，存放該期相關(guān)的資料。如下圖7喇澡、圖8所示：
（2）需求文檔：
對于需求文檔晴玖，網(wǎng)上已經(jīng)有很多成熟的模版了读存，不一一展開細說。但是我們往往能看到大廠的需求文檔非常全面呕屎，細致到無可挑剔让簿，但是當(dāng)我們做項目趕工期的時候，你可能連整理需求文檔的時間都沒有秀睛，更不用說做到那么細致了（其實這樣在軟件開發(fā)當(dāng)中是很不規(guī)范的尔当，因為沒有想清楚的需求到后期再返工可能帶來的工作量會非常大，但是出于現(xiàn)實客觀情況蹂安，小公司為了業(yè)務(wù)會在極短的開發(fā)周期內(nèi)交付椭迎，但是人員配置卻不會增多）锐帜。這個時候可能要引用一句敏捷宣言即：工作的軟件 高于 詳盡的文檔。當(dāng)你來不及整理詳盡的文檔的時候畜号，你就要善于利用工作的軟件了缴阎，我將在第六節(jié)“需求設(shè)計”中展開說明（但是之后一定要要將需求文檔補上，不然項目交接或者有新同事加入的時候可能會漏掉很多細節(jié)）简软。
5蛮拔、項目計劃
在此階段主要是對需求進行拆解成任務(wù)進行分配，并由各崗位負責(zé)人對任務(wù)進行工期估算痹升，進行排期语泽。
在需求管理中已經(jīng)說過要將需求進行評審的時候進行工期評估，將需求排期视卢，那此處為何又要做一遍呢踱卵？這個我要解釋一下：其實在很多大型軟件項目開發(fā)中，可能是由很多個團隊共同開發(fā)的据过，甚至可能細致到一個功能模塊都有一個單獨的團隊進行開發(fā)惋砂。而進行一個需求實施時，測試要寫用例绳锅，保證需求是可以測試西饵，可以量化，是合理的鳞芙。而前端開發(fā)又需要對開發(fā)的框架進行搭建眷柔、對頁面進行布局、做接口聯(lián)調(diào)幾個流程原朝，后端開發(fā)同樣要搭建框架驯嘱、部署服務(wù)器數(shù)據(jù)庫、理解需求建立數(shù)據(jù)庫表喳坠、再進行接口設(shè)計鞠评、以及配合前端進行接口聯(lián)調(diào)等幾個流程。所以一個需求要完整的實現(xiàn)壕鹉，中間可能包括了項目組成員的很多個任務(wù)剃幌，這時就需要項目經(jīng)理來對任務(wù)進行拆分，評估任務(wù)工期晾浴，來保證項目的可控负乡。在此階段我們公司使用的項目管理工具是禪道，所以我用禪道進行演示：
（1）任務(wù)分配：具體按公司的開發(fā)流程來拆解脊凰，如下圖9所示：
（2）工期估算：這個因為每個人的工作效率不一樣抖棘，肯定是不能由項目經(jīng)理直接定的，一般是由各任務(wù)人員自己評估工期，再由項目經(jīng)理檢查钉答，如下圖10所示：
（3）時間進度安排：此處的進度安排是聚焦到每一個任務(wù)的安排始末時間础芍，一般的項目管理軟件都有這個功能，如下圖11所示：
（4）風(fēng)險控制：當(dāng)你把以上事項做完之后数尿，你就能夠統(tǒng)計出來項目完成需要多久的時間仑性，哪些任務(wù)容易完成，哪些任務(wù)不容易完成右蹦。如果時間超出了項目交付時間诊杆，你就不得不像負責(zé)人要人了，至少有數(shù)據(jù)支撐你也有底氣一些對吧何陆。在這部分主要確定整體完成時間晨汹，是否會延期、一些不容易完成的任務(wù)如何解決贷盲、部分任務(wù)需要提前準(zhǔn)備其他條件（如部署小程序需要先申請注冊小程序并微信認證之類的）淘这，當(dāng)你收集好這些問題之后你作為負責(zé)人你就需要將這些問題進行反饋和跟進了。
（5）版本管理：你是否有遇過這樣的情況巩剖，當(dāng)你的V1.0版本還存在迭代的時候铝穷，V2.0的大版本就進行開發(fā)了，這是很常見的佳魔，那么此時你就需要安排好每個版本哪個項目組做什么任務(wù)曙聂。我們根據(jù)公司的開發(fā)現(xiàn)狀定了一個版本管理的規(guī)范：
【生產(chǎn)環(huán)境】作為線上穩(wěn)定正式版本，供所有用戶開放使用鞠鲜。
【測試環(huán)境】作為上個版本號（即當(dāng)前線上版本）bug維護宁脊，和交付給甲方測試驗收使用。
【開發(fā)環(huán)境】對當(dāng)前迭代版本進行開發(fā)贤姆、測試使用榆苞。
【版本示例V2.0.2.0513】各數(shù)字從左至右分別代表大版本號、迭代版本號庐氮、bug修訂號语稠、迭代版本開始時間
6、需求設(shè)計
工作內(nèi)容：產(chǎn)品架構(gòu)圖弄砍、功能結(jié)構(gòu)圖、業(yè)務(wù)流程圖（UML）输涕、UE原型
需求設(shè)計階段一般要整理產(chǎn)品架構(gòu)圖音婶、功能結(jié)構(gòu)圖、如上圖2莱坎、圖3衣式。但是如果要進行開發(fā)，最為重要的必然是流程圖和原型了。
首先我們來說說流程圖碴卧，目前比較規(guī)范的就是UML建模了弱卡。我們至少要從業(yè)務(wù)層面分析出來客戶的業(yè)務(wù)流程，并整理或者優(yōu)化為業(yè)務(wù)流程圖同步給開發(fā)住册，比如活動圖婶博、時序圖就是我平常用的比較多的（具體看開發(fā)和公司要求使用何種模型，有的公司可能還需要產(chǎn)品經(jīng)理設(shè)計類圖的）荧飞，流程圖對于開發(fā)來說尤為重要凡人，比如業(yè)務(wù)流轉(zhuǎn)，狀態(tài)變更你自己可能很清楚叹阔，但是開發(fā)可能真的是一臉懵逼的挠轴。網(wǎng)上有很多成熟的規(guī)范我就不展開說了，上圖：
接下來要說的就是產(chǎn)品經(jīng)理最基礎(chǔ)但是工作量最大的工作了岸晦，原型設(shè)計。我仍然會在此分為兩種情況進行說明
情況一：用戶預(yù)研階段（或者用戶評審）
在此情況下你要明確你的原型是給你的客戶看的睛藻，目的是為了給他匯報你的方案启上，并挖掘客戶的需求。所以在此階段修档，原型只設(shè)計主要的頁面即可碧绞，但是一定要盡量保真，這樣才能讓客戶有真實的體驗感吱窝，并反饋真實的想法讥邻。同樣地，在原型上所有的說明標(biāo)注都不應(yīng)該有院峡，因為在此階段你把原型做到足夠保真后兴使，你完全可以借機拿客戶做可用性測試，如果在沒有說明幫助的情況下照激，客戶仍然可以知道這些功能就是他們想要的发魄，仍然可以走完整個流程，證明你的設(shè)計是基本符合客戶需求的俩垃。如下圖13所示：
圖13：高保真原型
情況二：項目實施開發(fā)階段
在此情況下你就要明確這份原型是給項目組成員看的励幼，為的是能夠以這份原型為開發(fā)的標(biāo)準(zhǔn)。所以每個頁面都必須設(shè)計的非常詳細口柳，以上“需求管理”章節(jié)說了我們要善于利用工具整理需求苹粟，無論是架構(gòu)圖、產(chǎn)品功能結(jié)構(gòu)圖跃闹、流程圖嵌削、需求說明還是交互都屬于需求的每個部分毛好，我們可以以Axure這樣的原型工具作為需求文檔的載體，在原型設(shè)計中加入每個功能點的說明苛秕、規(guī)則肌访、流程、狀態(tài)等等艇劫，這樣開發(fā)也能夠不用打開各種各樣的文檔增加負擔(dān)吼驶。（其實開發(fā)看著你那幾十上百頁的需求文檔根本都懶得看，換做是你港准，你會看得多認真哈哈～）旨剥，還是上圖：
7、需求評審
在此階段浅缸，基本是需求已經(jīng)全部設(shè)計完成之后轨帜，項目組開會一起來進行最后的需（吹）求（毛）評（求）審（疵）。評審要非常細致衩椒，不要怕大家懟需求或者開會時間過長蚌父，因為你在這個節(jié)點所有沒有想清楚的需求最終你還是要背鍋的，而且如果后期如果在開發(fā)過程中毛萌，卻發(fā)現(xiàn)這個需求不可行苟弛，導(dǎo)致開發(fā)返工，開發(fā)生不生氣是一回事阁将，最重要的是這會導(dǎo)致整個項目組延期膏秫，這樣的后果是非常嚴(yán)重的。
雖然是需求評審做盅，但是一定要讓項目組的每個成員都引起重視缤削，需求一旦返工導(dǎo)致的是每個崗位的同時可能工作都要受到影響。而不能只是說產(chǎn)品一個人講吹榴，其他人都模棱兩可的聽聽就過了亭敢，那這樣的評審毫無意義。（這個階段我好像沒有發(fā)現(xiàn)什么高效的技巧图筹，還望大家給予建議）帅刀。
8、需求實施&項目實施
在此階段各崗位工作進入設(shè)計远剩，并進行評審扣溺。如需求設(shè)計&評審、UI設(shè)計&評審瓜晤、代碼設(shè)計&評審娇妓、測試用例&評審。作為項目經(jīng)理兼產(chǎn)品經(jīng)理你需要組織會議活鹰，來跟進各崗位輸出的工作是否滿足需求哈恰，是否有偏離預(yù)期的想法。我們一般會將大家的任務(wù)給量化志群，具體到工時每天進行跟蹤着绷，如圖15、16:
9锌云、項目監(jiān)控
在此階段主要對項目進度進行跟進荠医，及時更新任務(wù)狀態(tài)，提前對風(fēng)險進行預(yù)警桑涎。此階段算是項目經(jīng)理非常核心的工作職責(zé)了彬向，你要時刻跟進項目組成員的進度，工作完成度是不是有按照預(yù)定的計劃進行攻冷。一般會有以下幾種方式：
（1）每日例會：我記得在每本敏捷開發(fā)的書里都會提到這個15分鐘每日例會娃胆，來跟進我們當(dāng)前的進度，今天要完成的任務(wù)等曼，以及有什么問題里烦。當(dāng)然我個人認為還是要看公司業(yè)務(wù)而定，規(guī)矩是死的人是活的禁谦，如果一個很簡單的項目胁黑，項目組成員又不是很多，在可控的情況下通過日報和工作群的溝通就能發(fā)現(xiàn)問題州泊，沒有必要說一定要把大家召集起來開個例會丧蘸。（因為組織大家可能會打斷同事的工作狀態(tài)，如果日報大家都沒什么問題的話就沒必要每天這么高頻了）
（2）每日日報：這個應(yīng)該算是各行各業(yè)的工作規(guī)范了遥皂，每天應(yīng)該把今日完成的任務(wù)和明日計劃完成的任務(wù)列出來力喷，并在項目組內(nèi)給其他成員同步。這樣也好讓大家互相了解整體的項目進度渴肉。（而且日報也是自己提前預(yù)警的一種方式冗懦，你可以在備注中將風(fēng)險和情況如實匯報出來，如果領(lǐng)導(dǎo)認為這個任務(wù)不可控了仇祭，就會介入進來披蕉，即便未來發(fā)生了問題，至少提前做了匯報乌奇，總比一聲不吭的要好）
（3）每日任務(wù)更新：不論是用軟件工具還是通過文檔等各種方式没讲，對任務(wù)狀態(tài)進行及時更新都是必要的一個環(huán)節(jié)，作為項目組各崗位的成員應(yīng)該做到及時將自己完成的任務(wù)進行狀態(tài)更新礁苗，方便項目經(jīng)理同步進度爬凑。（當(dāng)然在現(xiàn)實情況下就是你不催，大家必然不動试伙，敵不動嘁信，我不動）
（4）人員表現(xiàn)：人員表現(xiàn)乃項目正常運行的基礎(chǔ)（像什么喊口號或者人員積極性啥的這種主觀的我就不再介紹了）于样，這里我想說的是，任務(wù)需要量化才能夠最直觀的監(jiān)控到每個人的表現(xiàn)潘靖，眼見不一定為實穿剖，數(shù)據(jù)更加直接。像大公司什么KPI卦溢，OKR等一些制度都非常完善了糊余，也有很多開放的方法可供大家學(xué)習(xí)，小弟就不再展開介紹了单寂。但是通過剛來公司大家的任務(wù)情況都靠口頭匯報贬芥，和目前使用管理工具看到實時數(shù)據(jù)一對比，就會發(fā)現(xiàn)量化任務(wù)后大家的積極性和工作效率都相應(yīng)的會有一定提升宣决。我分析有如下可能：
項目組同事之間發(fā)現(xiàn)別人做的更快更多蘸劈，自己相應(yīng)的也會帶動積極性，怕被比下去（比如以前我作為新人剛來公司的時候疲扎，和其他產(chǎn)品經(jīng)理做一個項目昵时，對方就會時刻關(guān)注我的工作，進度椒丧，和學(xué)習(xí)的一些小技巧）
管理軟件的數(shù)據(jù)會對管理層開放壹甥，每個人都擔(dān)心領(lǐng)導(dǎo)和決策層看到自己的表現(xiàn)（對于小公司來說領(lǐng)導(dǎo)和老板基本認識每一位同事）
管理工具會統(tǒng)計人員各方面維度的數(shù)據(jù)，如工時壶熏，任務(wù)數(shù)句柠，出現(xiàn)bug數(shù)等等，綜合起來大家不僅能看到自己哪方面問題比較多棒假，同時也能針對性的去注意溯职，倒逼成員在其它崗位的工作和評審中更加集中注意力
（5）風(fēng)險預(yù)警：風(fēng)險預(yù)警經(jīng)常會來自于項目進度、交付質(zhì)量帽哑、需求變更等等谜酒。首先對于項目進度來說，本身就難以控制妻枕，對需求和任務(wù)提前預(yù)測本身就是主觀并且不準(zhǔn)確的僻族，尤其是我們做項目經(jīng)常對行業(yè)并不是很熟悉，有可能對工作量的預(yù)判會有較大偏差屡谐。再來交付質(zhì)量來說述么，由于交付時間明確，工期相對緊張愕掏，留給測試的時間自然會不夠充裕度秘。最后對于需求變更這種，可以說是最讓人頭疼的問題饵撑，對于軟件產(chǎn)品來說剑梳，需求變更是非常常見的事情唆貌。而且時間一趕，就有可能出現(xiàn)許多需求細節(jié)想不清楚的地方阻荒，然而在進入一個項目從0到1開發(fā)時挠锥，由于項目組都沒什么經(jīng)驗，評審的時候自然也就不夠細致侨赡，從而在開發(fā)的過程中會有很多問題，這就有可能導(dǎo)致需求細節(jié)變更粱侣。而且對于我們做項目來說羊壹，我們的客戶還會源源不斷的提出各種想法（雖然按照規(guī)范流程來說，項目開發(fā)中是不再收集變更的需求齐婴。但是真正面臨甲方的時候油猫，你這個需求達不到甲方的意思，甲方根本就不驗收柠偶，自然你的項目尾款就收不到情妖。這個也是很頭疼的問題，也導(dǎo)致我們公司目前交付通常都會拖一段時間诱担，望各位建言獻策）
10毡证、交付驗收
交付驗收一般來說是一個項目期最后的一部分工作，自從進入公司以來看到公司所有的產(chǎn)品幾乎都有一個情況蔫仙，就是交付期一旦用戶試用料睛，必將會反饋各種各樣的優(yōu)化意見。所以在這里我們遵循一個敏捷概念叫“增量交付”（來自ACP敏捷項目管理應(yīng)試指南）摇邦，即：
使得工作產(chǎn)品更早地交付到客戶手里恤煞，更快地交付價值
允許客戶在項目未完成前先用系統(tǒng)，以便給需求變更留出時間施籍，同時影響最小
不試圖預(yù)先規(guī)劃所有細節(jié)居扒。相反，團隊可以先規(guī)劃一部分丑慎，交付一部分價值喜喂，得到有價值的反饋后再重復(fù)這個循環(huán)
優(yōu)先處理最有價值的功能部分，以便把這最有價值的部分盡快交付到客戶手里
同時立哑，還有一些注意的地方夜惭。就是很多小公司在交付的時候經(jīng)常是客戶提出來交付什么文檔就配合去整理，客戶不提出來就不給了铛绰。這樣是會減少一定的工作量诈茧，但是這也是對自己公司專業(yè)性的不負責(zé)任。交付文檔是對這個項目的總結(jié)捂掰，不僅可以對當(dāng)前系統(tǒng)設(shè)計規(guī)則做記錄敢会，也能夠督促客戶驗收曾沈。以前我們就對一個已經(jīng)開發(fā)完成的系統(tǒng)整合其它功能做開發(fā)，由于對方交付文檔缺少鸥昏，在數(shù)據(jù)割接這一塊沒有數(shù)據(jù)庫的設(shè)計資料塞俱，導(dǎo)致開發(fā)很多數(shù)據(jù)遷移都有可能對不上的字段±艨澹總之一個項目期時間說短不短障涯，說長不長，花點時間把交付文檔整理完備做好最后的收尾是非常必要的膳汪。
三唯蝶、總結(jié)
1、敏捷開發(fā)的一些思考
最近公司一直在學(xué)習(xí)并希望實踐敏捷開發(fā)于公司的軟件開發(fā)工作流程當(dāng)中遗嗽。然而效果往往不盡人意粘我，我們可以先看看敏捷宣言（在《PMI-ACP敏捷項目管理》這本書中講過遵循敏捷宣言代表了敏捷從業(yè)者的最高指導(dǎo)性原則）
個體和互動 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶合作 高于 合同談判
響應(yīng)變化 高于 遵循計劃
那么我依照敏捷宣言的原則來映射到我們的公司業(yè)務(wù)中去，就會發(fā)現(xiàn)一些問題
（1）首先人與人之間的口頭交互雖然在短期內(nèi)提高了溝通效率痹换，然后從長遠來看征字，需求的不斷完善、豐富娇豫、細節(jié)的修改匙姜，以及項目組成員的頻繁調(diào)動，許多細節(jié)都可能被遺漏锤躁，甚至新接手的項目組成員根本無法快速上手到項目組的運行之中搁料；并且在真實的開發(fā)當(dāng)中，如果不嚴(yán)格遵循于流程規(guī)范系羞，很有可能造成本可以提前阻止的小問題到了后期越滾越大郭计。
比如按照流程來說，需求同步應(yīng)該開會進行椒振，但是有幾次我為了提高效率昭伸，將一些細節(jié)只和對應(yīng)的開發(fā)說了，導(dǎo)致項目組有幾個同事都不知道這個細節(jié)澎迎，以致于大家測試的時候根本沒有發(fā)現(xiàn)問題庐杨。還好沒有導(dǎo)致嚴(yán)重的錯誤，但是這其實是不應(yīng)該發(fā)生的（我理解此原則想表達的是個體互動的效率高于嚴(yán)格遵循流程流轉(zhuǎn)的效率夹供，然而在真實的開發(fā)場景中灵份，如果當(dāng)我們習(xí)慣于使用口頭互動，那么你試問自己你真的會將每次口頭表達的細節(jié)都詳細的記錄在文檔上嗎哮洽？至少在我們公司是沒有做到的）
（2）第二就是適應(yīng)變化填渠，響應(yīng)變化就會讓我們的工期受到影響，強交付是做項目的基礎(chǔ)標(biāo)準(zhǔn)，我們每一個項目都會在簽署合同之前氛什，對需求進行大致評估莺葫，雖然工期不一定特別精準(zhǔn)，但是基本差不多枪眉。在開發(fā)并整理計劃之初捺檬，我們就會將任務(wù)拆分出來將項目組成員的工作量安排飽滿。如果在開發(fā)過程中進行需求變更贸铜，工期必然延后堡纬，就有可能導(dǎo)致我們原本簽署的周期之內(nèi)無法按時進行交付，違約對于公司來說會導(dǎo)致更為嚴(yán)重的后果萨脑。當(dāng)然我有聽過有同行建議過隐轩，在特殊的情況如果來不及交付就臨時增添開發(fā)人員，但是在現(xiàn)實中經(jīng)常是不適用的渤早，對于大項目或者自研產(chǎn)品來說還好一點，一個是周期相對長瘫俊，二是基本每一個人不論是不是產(chǎn)品崗位鹊杖，都對需求有基礎(chǔ)的認識，你要臨時救火的確能快速上手扛芽；但是對于一些周期較短的小項目來說骂蓖，除了項目組的這幾個人，可能其他同事只聽過這個項目的名字川尖，需求完全不了解登下，尤其是對于開發(fā)來說，每個規(guī)則都要非常清楚叮喳，理解需求就要幾天時間被芳，可能很多細節(jié)還不知道（即便你整理一份再細致的需求文檔，對于一個從0到1的項目來說有多少規(guī)則馍悟，多少功能畔濒，這會讓開發(fā)在短時間內(nèi)很難上手幫忙）。
最后我個人認為锣咒，無論是基于何種開發(fā)模型侵状，規(guī)則是死的，人是活的毅整，沒有必要認為什么比較流行就去使用趣兄，適合自己公司的才是最好的。
2悼嫉、自我思考
從大學(xué)畢業(yè)就直接進入了產(chǎn)品實習(xí)生的工作中艇潭，一眨眼就一年多過去了。公司也非常信任我的工作能力，很短的時間內(nèi)就讓我獨立承擔(dān)產(chǎn)品經(jīng)理的工作做一些簡單的產(chǎn)品暴区。為了完善自己的工作規(guī)范和方法闯团，我看過很多工作相關(guān)的書籍、論壇仙粱、帖子房交，但是絕大部分的思想和方法都很難應(yīng)用于當(dāng)前的公司業(yè)務(wù)當(dāng)中，這是讓我有點失落的（本來想著今年拿下PMP和NPDP兩大項目管理認證的伐割，奈何工資收入不允許候味，一直存不下來錢，只能先自己看書學(xué)習(xí)了）隔心“兹海總感覺自己設(shè)計出來的產(chǎn)品就像自己的小孩，剛剛長大一點就要交給別人硬霍，看不到他以后會是什么樣帜慢，是會成為我期望他成為的樣子還是變成我完全不認識的樣子。大家幸幸苦苦一起將他孵化出來唯卖，我是希望它能真正的為我們的客戶帶來很大價值的粱玲，而不是流于形式。不知道自己未來會在哪個行業(yè)深耕下去拜轨，但是我認為這個職業(yè)一定會為我的生活帶來些獨特的體驗抽减。
