經(jīng)歷過4個從零開始到上線的項目，關于項目管理，有一些自己的想法，發(fā)現(xiàn)在項目開發(fā)時，如果有些問題沒有記錄清楚，那么以后就真真的有坑。

1. 項目需求

在項目立項時，一定要多去問，為什么要做？做的原因有哪些？誰是我們的客戶？我們要解決他們什么問題？有沒有時間要求等。這些都是這個項目立項的支撐點，如果沒有這些支撐點，做出來的東西就不夠穩(wěn)定，經(jīng)不起推敲的。

如果你是甲方，那么想要產(chǎn)品早早的上線，請一定一定不要相信乙方的項目經(jīng)理所說的任何保證，除非這家公司你是真知道他的能力。在任何情況下，一定要把你們在會議溝通的任何需求和任何想法記錄清楚，形成一份清晰的紀要文檔，每次會議一定要有討論結果和解決方案，切記：一定要有解決方案，問題誰都會找，管件是解決方案。

如果你是乙方，那么想要產(chǎn)品早早的交付，請一定一定不要相信甲方所說的每一句話，甚至是標點符號。甲方每一個人都是患有階段性失憶癥的，而且每一個甲方都是最牛的創(chuàng)意大師。他們的每個想法請不要盲目的答應，一定要考慮考慮再考慮，最好是當場能畫流程圖，草圖，確定一切正常時，再確定是否能開發(fā)，并記錄成紀要文檔，并郵件告知項目關聯(lián)的每個人，尤其是甲乙雙發(fā)的商務人員和項目干系人員。

2. 項目時間

有很多項目時間就是固定死的，需要把項目反推開發(fā)進度，但是也有很多是沒有時間要求的，大部分是總監(jiān)或老板，也有可能是商務直接嘴上說說。這時候的開發(fā)就看項目經(jīng)理的能力了，是否能有效的把控項目的開發(fā)進度。

項目時間的評估一般是技術經(jīng)理，我遇到的技術，在做周期評估時候，大部分的評估內(nèi)容都是超時的。當然，作為項目管理人員，這個時候就是純經(jīng)驗了，專業(yè)的PMP管理人員，并不適用互聯(lián)網(wǎng)公司那種機動性較強的開發(fā)項目（可能我遇到的PMP管理人員是假的，不展開討論）大部分互聯(lián)網(wǎng)項目中，不會有那么多的時間去做評估、記錄、方法論。大部分的項目都要求快速上線，時間較為緊張的項目中，一開始就知道了時間的局限性，那么合理安排開發(fā)順序就非常重要了，這個下面再說。

3. 項目開發(fā)安排

比較排斥分功能點開發(fā)。大項目的開發(fā)，大部分是幾十個功能一起開發(fā)，開發(fā)時，盡量一個功能模塊由一個人（團隊）來做，這時候，一定要經(jīng)常開會討論，把各功能模塊之間的關聯(lián)關系說明白，寫明白，畫明白。不然開發(fā)時一定會出現(xiàn)，做出來的東西垮功能時的不適用（也就是Bug多）甚至會出現(xiàn)底層架構設計的錯誤；

看過一篇文章，里面說過，技術在開發(fā)功能時，如果是一個功能比較多的項目，一定要按照嚴格意義上的功能模塊進行分配，何為嚴格意義上的功能模塊，看完之后以我的理解，白話的解釋就是一個功能，由某個工程師開發(fā)時，他要知道這個功能中包含的東西，就算不是他做的接口，也必須知道里面的業(yè)務邏輯。這樣，在開發(fā)的時候，他可以把整個功能模塊的業(yè)務全部理清楚，交付給測試后的Bug就會相對比較少，如果出現(xiàn)問題，一個人就可以解決Bug（我相信產(chǎn)品經(jīng)理一定遇到過一個Bug找不到是哪個技術負責的修改的情況）

4. 項目功能優(yōu)先級

功能開發(fā)時，一定有優(yōu)先級順序，工期越緊越要搞清楚優(yōu)先級順序，在開發(fā)時，一定把遵循，業(yè)務級第一，功能級第二，統(tǒng)計級第三，頁面（顯示，UI）級最后的原則，項目的使用是滿足業(yè)務的，業(yè)務能跑通，項目才是正確的，其次是讓使用人員用的開心，就屬于功能級的事情，減少使用人員的使用次數(shù)就是好的功能，越簡單越好；

剛入產(chǎn)品經(jīng)理行業(yè)時，跟不不知道到底什么是優(yōu)先級，做的越久越發(fā)現(xiàn)，這個問題是真心的不好回答，比如我管理的最早的產(chǎn)品，是一款對C的產(chǎn)品，我們的運營經(jīng)理三天兩頭的來找我，要求把某個顯示，某個顏色，某個彈框，某個提示語改改，甚至每次開會，提的最多的也是這類問題，這類產(chǎn)品我當時在評估時，第一要任是滿足功能（某些盈利功能，某些產(chǎn)品代表性功能）其次是交互，好用好玩好看。最后才是用戶可能無感的東西做優(yōu)化。而我現(xiàn)在管理的對B的產(chǎn)品，老板說某客戶要加個功能，你看一下。商務說我現(xiàn)在收集發(fā)票信息太痛苦了，你給我做個發(fā)票管理系統(tǒng)。運營說，我下個月可能要做一波活動，需要一個營銷工具，你來看看怎么實現(xiàn)比較合適。你收到此類信息后，發(fā)現(xiàn)每個都是比較緊要的事情，怎么破？？唯一的評估要求就是，那個功能不做你損失最大。那個功能做了，對公司貢獻最大。

5. 關于測試

測試一定要寫測試用例，一定要懂項目的業(yè)務需要和這個功能的使用場景，測試時盡量能做到角色扮演（把自己當成用戶）

曾經(jīng)看過一篇文章，說張小龍談論騰訊里面的最厲害的測試，張小龍自己說他要把自己變成一個小白用戶需要醞釀很久，而馬總（馬化騰）只要一個呼吸間就可以把自己變成小白用戶。我在要求我的測試的時候，第一要務是必須理解里面的業(yè)務邏輯，我會把產(chǎn)品設計的想法，場景，用戶的要求全部講出來，告知測試設計的原因，把每個功能點上可能涉及到的東西都會提出來，而測試偶爾提出的問題，我也會在會議中盡心討論，隨時修改或記錄。我一直相信產(chǎn)品只是一個人，沒有辦法把一個邏輯中可以涉及到的方方面面都考慮到，這個時候測試就是產(chǎn)品的一個補漏和補全的作用。測試用例-第一版中重要的邊界值一定要考慮進去，而為什么說第一版只考慮重要的邊界值問題呢，因為很多互聯(lián)網(wǎng)項目中上線都是第一位。優(yōu)化迭代時才需要去考慮各種邊界值，容錯問題的事項。

6. 人員管理

項目開發(fā)過程中，一定存在溝通上的各種問題，小問題，人員自己溝通，大問題，整理成文檔，每周做一次總結會議，把所有問題會議上攤開講，就算是和其他人員沒有關系，讓其他人員了解一下，有助于對整個系統(tǒng)的了解；

人員才是項目中最大的問題，任何一個團隊中，只要是人在的地方，就一定會有糾紛和爭吵。尤其是在一個項目設計大量的開發(fā)人員，需要開發(fā)人員之間進行協(xié)調(diào)時，作為項目管理人員，一定要關注溝通的問題。能由項目牽頭溝通的，盡量有一個可以中和的人來去引導整個溝通的過程。如果所溝通問題設計的人員比較多時，建議進行小范圍會議來進行頭腦風暴形式討論，并形成會議紀要形式，記錄解決方案和討論內(nèi)容（解決方案已定要有）很多工程師在解決Bug問題時都會出現(xiàn)抵觸情緒，而測試在提出解決方案時的解決一定存在消極怠工的情況。這個時候，項目管理人員在項目后期一定要定期開Bug評審會，評估每一個Bug的優(yōu)先級，解決方案備注，解決人員的說明，解決時間的去頂?shù)?，以Excel的形式在會議結束后郵件發(fā)給每一個相關人員。很多時候問題說開了，人與人之間就會很好相處了。項目管理人員切記有團體情況。

7. 需求變更

需求一定是經(jīng)常變更的，需求變更的事情，大多不是業(yè)務層面的，大多是功能層面和使用層面的事情，這類需求變更，成文件形式記錄，通報給技術總監(jiān)和相關技術人員。業(yè)務層面變更就要組織相關領導開會確認，之后把變更后的內(nèi)容告知所有技術人員；

需求變更一般是由甲方提出，甲方包括付錢的，發(fā)工資的，商務，業(yè)務，運營等。所以這個又老生常談的問題–需求評估，當然沒有誰能一次性把所有的問題想明白。需求變更的產(chǎn)生在產(chǎn)品的生命周期中一定是經(jīng)常存在的。那么如何避免需求的變更就兩個解決方案，一是在需求確立時多搞清楚情況，之前說過就不說了。二是需求管理—任何需求的產(chǎn)品都要文檔形式記錄，每次需求的結果都要郵件形式告知每一個相關人員，讓需求變更人員不要意思提變更，再不濟也讓他們在提變更時想清楚再提。項目人員在接到需求變更時，又回到第四點說的，優(yōu)先級，這個需求到底需要需要現(xiàn)在就去改，現(xiàn)在就做，評估清楚再做。

以上7點是入行幾年來，經(jīng)歷了4個從0開始的項目后的一些總結。只是自己所接觸的小公司的情況，沒在大公司呆過可能不知道情況，希望大公司的大牛不要噴我。

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

題圖來自 Unsplash，基于 CC0 協(xié)議