項目管理是產品經理的必備技能，但這也是很多新手產品經理的硬傷。本文作者結合自身經驗從需求迭代、敏捷開發、需求收集和項目方案幾個方面分享了新手產品經理管好項目需要注意的幾個要點，希望對你有所幫助。

一、前言

項目管理里，相信很多新手項目經理，部分產品和運營，經常被項目需求折磨的痛不欲生，不知為啥需求一直還需要修改，這是一個嚴肅的事，客戶daddy給我們飯吃給錢賺，不能怪客戶，更多的去想我們是不是哪里還沒有做好呢？

筆者也是剛接手項目管理時長1.5月的練習生產品經理，在這里想和大家交流和分享下自己的學習和思考。

二、需求迭代的方式

1. 常見的客戶需求推進方式方式

坑型溝通方式，項目初期溝通，其實客戶并不清楚自己真正的需求，需求是在后面項目推進中逐漸明確出來的。

所以像圖里一樣，初期溝通非常多，后期溝通也非常的多，初期是需求多，后期是因為需求不符合客戶需求修改的多。最后就變成了大坑。藍線是一般溝通方式，所以到后期就容易改需求，增加了項目周期。

2. 迭代式需求推進方式

項目根據功能需求分為多個階段，在該功能的早期進行項目的需求收集，后期進行需求的確認，這樣即使需求溝通不充分，大概率也不會影響項目的推進工作，因為單個功能上來說，其實該動起來相對簡單。溝通是階段性的，盡可能每一個階段的內容項目干預比較少，這樣可以快速迭代項目快速推進。

二、敏捷開發

在國外，敏捷式開發也早已經被Google、Facebook、LinkedIn等企業應用，目前國內很多企業也在使用，所以，并不是一個新的東西。

該圖來源于互聯網（引用網站已關閉因此沒貼上引用來源）

1. 敏捷開發的起源

2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會，雪鳥會議共同起草了敏捷軟件開發宣言。其中最重要的部分就是對一些與會者一致同意的軟件開發價值觀的表述：

1. 人機交互重于過程和工具；
2. 可以工作的軟件重于求全責備的文檔；
3. 客戶協作重于合同談判；
4. 隨時應對變化重于循規蹈矩；其中位于右邊的內容雖然也有其價值，但是左邊的內容最為重要。

2. 敏捷開發的四條原則

（1）遞增，而不是連續的

敏捷開發里最后交付日期是截止日，除此之外日常交付通過小步快跑快速迭代，意思就是快速制作內容出來和客戶確認一點一點地快速確認，不能等待這階段的任務完成了統一交付。

（2）避免不必要的開銷

溝通必帶方案，討論迅速有目的性，減少阻礙項目執行的難點，會議僅限匯報和快速解決問題；

與其討論要做什么，然后再多個人多次輸出方案，還不如盡快確定基礎標準，在滿足標準的情況盡快去做。在大部分項目里時間：溝通的時間＞＞執行的時間，其實這是很沒有必要的，即使溝通也許需要自己準備好方案，不然討論的時候各種idea浪費的可能是七八個人的時間，1個小時的會浪費的就是7-8個小時。

（3）協作

協作這里必然需要通用的協作工具，一定要用，在管理里這是工作內容有跡可循、高效溝通，在協作軟件里完成自己的任務后，不需要花時間去考慮是否這時候會打擾到別人。這里就不推薦工具了，百度一下一大把。

（4）說真話

這里的說真話并不是說，你說話的主觀意識的真假，而是基于需求、事務判斷的真假，如果你覺得美國人喜歡喝茶，然后就馬上告訴團隊的人，針對這問題展開討論和開發，這就是假。所有討論、需求、執行，必須基于這東西是真實需要的，否則開發出來了也是偽需求，價值不大。

三、收集需求到項目方案的過程

1. 和客戶交流溝通

在項目開始前，一般會和客戶多次溝通，這時候我們需要明確我們的目的——知道客戶想要什么？客戶的客戶是誰？產品是面向哪些人的？這樣交流溝通的時候時刻帶著自己所想達到的目標，在溝通中達成目的；

2. 收集各個方面的信息，挖掘用戶行為后的動機

并非抱著目的，我們就可以做好交流的，因此當我們思緒不夠清晰，或者對客戶了解不深和對項目信息獲取不夠時，我們就無法在交流的時候達到我們手機信息的目的。所以，在拜訪客戶之前，準備好想要提問的大綱，并且以此作為收集問題及信息的來源，

常規的流程，這是屬于一般的工作或者演講、訪談、調查的一般流程；

1. 制定訪談和想知道的內容大綱，并依此設計提問；
2. 根據問題的情況，并針對可能回答的內容，進一步提問內容；預想各類方案；
3. 到達場景時，預設一個符合主題的開場，然后切入正題；
4. 正常提問，并針對或者根據客戶想法、客戶的目標客戶來進行溝通；
5. 最終獲取相關信息，并應用在實際產品設計規劃中；

3. 觀察客戶的基礎信息和習慣

觀察客戶是什么性格的人，不同性格的人決策或者思考傾向是不一致的，可以輔助我們出方案，或者有利于我們溝通時針對性獲取關鍵信息，比如偏保守的人，對界面和UI等設計需求偏向保守；

理解客戶所在公司的風格，知道客戶所處崗位，能夠更清楚項目最終決策人對項目需求的訴求，市場和運營大部分的訴求基于基礎功能之外能夠對營收帶來明顯幫助。

4. 理解客戶

項目里理解客戶，和作為產品經理去理解用戶其實很像，因為項目里的客戶其實就是做產品的時候，很像公司里的領導，你的產品需求挖掘和設計，很大一部分取決于領導思考。

理解了客戶，就會更容易去在項目里做出適合客戶的產品，需求挖掘更充分，同理心去代入客戶思考路徑里。

比如，客戶是一家汽車銷售公司，想做VR的項目，方便客戶看車…基本訴求就是，能夠在網上看車，那就是VR看車，但是我們需要深入思考的是，這樣做合適嗎？在市場VR設備這么少的情況下，那這時候如果我們想要拿下這個項目那方案和建議就是：

1. 這樣的體驗一定很好，客戶可以看到自己想要的汽車關鍵信息，未來一定是非常好的；
2. 但是，目前考慮到市面上VR硬件設備相對較少，做VR看車體驗的應用，主要適合在展館上結合附帶硬件讓客戶體驗；
3. 使用Web GL和Open GL技術可以實現裸眼AR效果，并且VR制作的模型是可以復用成本整體更低了；可以在微信小程序、瀏覽器上觀看，也可以代入帶客戶公司常用的APP里，也可以在電腦上網站打開觀看，這樣用戶受眾群體就會非常多；

那其實到最后，很可能在VR項目拿下的情況下，還可以多一個AR效果實現或者手機看車的項目，增加了收入，并且即使最終不行，從客戶角度去思考，項目帶來的好處，并且為客戶的客戶去思考，某些角度上會讓客戶覺得我們下了功課，能增加信任感。

5. 出項目方案

1. 定位問題；
2. 明確用戶（用戶畫像）；
3. 識別需求（同理心地圖、思維導圖、客戶目標用戶的體驗）；
4. 描述問題&需求（解決問題下的功能型需求、設計需求、呈現效果需求等）；
5. 方案構思；
6. 得出多套方案，出多套原型設計，投票（可行性和潛在影響力四象限分析）；

四、后記

今早6:00被貓吵醒了，睡不著，突然靈感迸發，也想起來了剛有個概念的這篇文章，就干脆寫寫自己的一些思考，生活中就是這么枯燥和隨意。

希望對自己工作有幫助，對自己的成長有比較大的幫助，與其說是長篇大論的說寫，還不如說是為了自己總結和提升的一個過程，學習-吸收-轉化的一個過程，也希望這個理念對大家有幫助。

五、免責說明

本報告僅代表個人觀點，數據來源于互聯網公開信息，分析結果屬于筆者對這個領域的研究，如果有引用在文中會說明，期待和各位交流。

如需私下交流或侵權等問題，請發郵箱：aigbert.li@qq.com，或加微信Aigbert-Aquarius，歡迎各位指正和交流。

作者：LS邋遢道人，資深運營和產品，連續創業者，現任某公司產品負責人，微信公眾號：LS邋遢道人

本文由 @LS邋遢道人 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議