許多產品經理可能會經常面臨這樣的問題：公司現有技術資源不足以支持自己的產品設計和迭代周期，導致不得不妥協。而Boss或客戶還不斷要求采用『小步快跑，快速迭代』的方式看到產品成果，這時作為產品負責人的你該怎么辦呢？

讓我們設想這樣一個背景，并以此展開討論：

抱怨解決不了問題，以項目周期為時間段，在項目執行前、執行中從容應對，通過合理的控制和管理盡可能的達到目的。

項目前期

明確狀態，獲取理解和支持

在評估完時間，資源和可行性后，PM需要做好充足的心里準備，分別列出最壞，適中和最好三個結果。這其中又以『最壞』為重中之重，因為這很可能就是真實的結果。PM應當明確告知領導可能出現的后果，打好預防針。如涉及到對外合作項目，還要在內部達成一致如何對客戶進行告知。不要隱瞞后果期待奇跡發生，更不要企圖自己承擔后果。P.S.有職責較為明確的公司，該工作會由項目經理承擔。

做最后努力，爭取（額外）資源

有給力的研發負責人帶隊，一方面可以對團隊把控，也可以讓年輕人發揮主觀能動性快速成長，也許他們未來都是公司的財富。如果團隊中不具備這樣的人，發揮人脈關系哪怕借一個來，都是非常有必要的。還是不行？不如放棄敏捷開發模式或重新衡量項目可行性，以免拖垮團隊毀掉聲譽。

制定可行的迭代周期

迭代周期不要過短（團隊HOLD不住，時間都會浪費在代碼分支合并，沖突檢測，發版上），也不要太長（否則失去了敏捷開發的意義），每次發版時間在可以在標準值基礎上+30~50%時間，給不成熟的團隊留出充分的容錯時間，所以需要具體情況具體分析。這時作為產品經理的你，需要和研發負責人探討每個里程碑實現程度。請考慮以下兩方面：1.是否會影響你的產品設計節奏；2.在每次交付時能否滿足領導或客戶的預期。

明確開發背景，不走回頭路

包括開發框架，網站架構，語言數據庫服務器部署要求等等（尤其設計到客戶，一定要確定清楚，必要時有合同，郵件為證）。不要進行到一半發現完全跑偏，團隊接收不了這樣的驚喜。在此環節，產品經理的參與主要體現在明確表述在與需求方的接觸過程中，對方有何『硬性』要求都要提出，以供整個團隊做設計背景。

項目執行階段
部門間彼此配合，適當的對結果打『折扣』

由于資源局限性，部門間更需要彼此理解和對目標認可。根據現實情況，在產品設計上做一些妥協，給功能列表減負，優先級低或者『令人尖叫』的功能先砍掉。舉個極端的例子，注冊驗證碼都搞不定的的人，就干脆去掉驗證這步吧。如果是對已有產品進行大的版本更新，就要考慮更多的兄弟部門和聯動意義，比如去掉某功能是否會影響該部門開展業務活動，作為PM不可能令誰都滿意，只能考驗自己的平衡和交流能力了。

會議的重要性

這點所有敏捷開發都會強調，包括通過站會匯報各自進度情況。能力不足更要保持信息暢通，不要讓成員自鉆牛角尖再給項目雪上加霜。產品經理在項目執行過程中，始終會保持與需求方的溝通。如果出現產品變更或需求變化，也要在會議上及時提出，如此反復修正復合當前情況的開發計劃，并保證可行性。

適當的說不

在項目執行過程中，團隊難免會受到各種各樣的干擾和額外的工作要求，比如客戶會要求你幫助部署服務器，測試線路等等。如果合同中有對應要求，可以協調兄弟部門作支持。但原本就超負荷的研發團隊，最好合理的拒絕，避免再牽扯更多精力。

巧妙的進行匯報

雖然定期匯報項目情況是項目經理的工作，但產品經理需要通過在方案中植入相對感性化的描述，來彌補項目不足和客戶的體驗。舉例來說，在重要又枯燥的數字（完成度，開發率等）之后，適當的可視化工作狀態，比如放一些成員加班的照片，攻克問題的數字及內容和對下階段的產品設想。核心思路是體現項目進度雖有一些延后和不盡如人意，但整體仍未失控。

額外：感情安撫

能力不足往往是團隊年輕，但年輕人充滿活力，加班到凌晨不眨眼，雖然解決的問題看似都『不值一提』。但長期如此消耗勢必對團隊成員的心里產生巨大的折磨和影響。端茶倒水零食飲料不能少，如果有『程序員安撫師』……想多了，有這預算不如在招個經驗豐富的人。這期間大部分人的能力都在突飛猛進，沒準也可以顯露大牛天賦。

總結
萬事俱備只差一位產品經理來發號施令的理想狀態，過去，現在和將來都未必會有。在這種狀態下，產品經理更需要有一顆強大的內心，沉著冷靜有條不紊的把資源利用到極致，對事情終局的判斷，可以倒逼過程中的每個決策，這是你作為一名PM可以掌控的。隨著研發能力的提高和彼此配合的加強，一切終究會慢慢走上正軌，而你和程序猿們在『戰斗』中培養出來的堅定友誼，也會讓身為產品經理的你在未來獲益良多。