產品經理如何在設計產品時避免給開發挖坑?
前段時間有個特別火的問題是說如何向外行解釋，產品經理經常改動需求，導致開發工作量增加。那麼問題來了，產品經理設計產品時如何兼顧未來的可擴展性呢？
從精益創業的角度講，很多時候都是設計簡單的功能和場景，以後再逐步完善，那如何避免後續增加修改功能導致開發工作量很大呢？經常聽開發筒子們這個是寫死的，要改成可配置的就是比較麻煩。之前設計的時候只考慮了一種情況，現在又說要根據用戶不同的選擇應用不同的邏輯。真心想知道如何才能解決這個問題啊！舉個栗子，比如設計一個充值卡的功能，現在的設計是充值卡只允許充入賬戶後供某一人使用。以後可能會支持多人共用（就是你可以綁定幾個人，大家都可以用你賬戶里的錢），商家後台選擇支持單獨使用還是共用。我的理解是以後要加這個功能就是加一個條件判斷，然後再做一套多人共用的邏輯，以後再詳細思考設計相關功能就行。但是老闆說要把未來可能擴展的情況都想清楚，否則未來改起來很麻煩。哪位大神能具體解釋一下原因嗎？
1. 搞明白基本的一些技術背景和技術概念
產品經理需不需要懂技術是老生常談的問題，我的回答是肯定要懂，關鍵在於，懂的技術是怎麼樣的技術。
懂技術並不是就要能自己成為架構師、自己成為工程師，又可以規劃技術架構又能實現產品功能。懂技術是要明白技術實現的邏輯。
比如，我們在做的配送業務，需要有配送員、訂單、商家多種信息，每種信息是存放在各自的數據結構里的，它們之間又通過邏輯關係串聯起來。這些產品上都未必體現得出來，但在很多產品設計的時候要考慮到，要做某個新業務時，發現商家要分截然不同的兩類，那中間的邏輯怎麼樣成本最低，是同一張表用屬性區分、還是新造一張表，都是要跟技術一起討論研究的。
平時，也建議多看些技術相關的文章和科普。注意，千萬不要買什麼《七天掌握安卓系統》之類的書，看一些跟產品息息相關的比較好。
還有個公眾號，叫做「給產品經理講技術」，寫得很接地氣，推薦。
2. 學會梳理產品邏輯
這個邏輯不是 APP 上有幾個 tab 頁，也不是功能之間簡單的關係，說的是背後的幾個邏輯：數據結構、信息流程和其它的邏輯關係。
很建議大家看看 @蘇傑 老師的《淘寶十年產品事》，裡面提到的淘寶產品經理，都是對數據和流程的梳理非常熟練的。
然而我見到的很多產品經理，並不太把這個當回事。「只要給我實現就行了，我不關心怎麼實現。」
數據結構其實是第一重要的東西，可以讓產品經理非常深入地理解技術實現的邏輯。
信息流程則是在有一個信息通路、存在一些狀態轉化邏輯的情況下，需要考慮的。比如常見的訂單從生成到支付到結束的環節，如果也只是零散地提出功能需求，那很可能出現紕漏，技術實現上也不明晰。
比如，這是嘟嘟美甲最初交互草稿里，我們梳理的訂單狀態轉化圖。
還有很多其他的邏輯，也需要梳理清楚。
比如，我們前段時間在設計取消訂單機制的時候，發現有很多種情況，每種情況的文案也不應該一樣，這時候就要梳理出每種具體的提示，不能讓技術去幫你完善。
對於應該梳理什麼、怎樣梳理比較好，可以多問問程序員哥哥們的意見。如果他們看到你的文檔，立刻就能想到該怎麼實現，那就證明起到作用了。如果每次都要花費大量的時間拆解和討論，那就是梳理得還不夠。
3. 出現坑的時候，多復盤
不同的產品差異很大，即使再有經驗的產品經理，也不一定就永遠不會埋坑。
坑出現了之後，除了儘快填起來，還要去復盤，多想想，怎麼避免下次再進坑。
如果是文檔寫得不周全，那就盡量寫得周全些；如果是缺乏溝通，那就在協作時多設立溝通會；如果是需求總會變動，那就研究需求變動的根本原因，把它大事化小小事化了。
關於產品技術協作，在我們公司，是設置了一套復盤機制的。每次出現大的問題，都會在解決之後，召集一次大會，所有相關人員加產品和技術的總負責人都在場的情況下，把事情說清楚，搞明白原委，並且會上要制定解決方案。
經過一兩個月的嘗試，我們發現，大多數的坑都是同樣的原因，我們就重點攻克這個難點，慢慢讓坑變少，原來的大坑也變小了。
希望能幫到你。說實話，這個要求挺高的。
要做到這一點，首先產品經理要有架構師的能力，這樣才能最大程度的考慮到重用、擴展性和靈活性。
其次產品經理還需要有很強的市場前瞻性，所以可以預知未來會發生什麼樣的變化，事先做好準備。
然後產品經理還應該有財務總監的能力，就能計算出投入產出比，找到最優的投資方案。
那這樣的產品經理薪水需要多少呢？多少也不行，有這些能力人家早就自己去創業了。
以上，大部分時候產品經理都是在替老闆背鍋而已，很多公司里，真正的產品經理的權力，其實在老闆手上。
轉一篇十幾年經驗產品經理的文章—《醒醒吧，信息安全的產品經理們》http://mp.weixin.qq.com/s?__biz=MzIzMTAzNzUxMQ==mid=2652873615idx=1sn=dd993d9ef7e461d213acec297f07cae1scene=0#wechat_redirect就事論事，你老闆說的是對的。
類似這種事，首先從資料庫結構來說，就應該按多人共用的邏輯來設計。簡單說，資料庫層面卡id和會員id得是兩個東西。前端代碼和交互、ui上都按一人用來走。至於後端代碼，就看情況了。事實上，不挖坑是不可能的。
上面說的那個處理方式，如果你真每次都這麼乾的話，就會出現過度設計，這樣對技術來說也是坑。
是不是坑，取決於老闆，老闆說不是，就不是。有時候老闆會站在程序員那邊，說先簡單弄一下，這樣其實等於挖坑讓你跳，但是產品經理的作用就是填坑背鍋，給錢你就是讓你干這個的。當然，你說的判斷一下，這是錯誤的，這是因為你完全不懂技術，技術是要學習的，當然，我不是叫你去學c系列，不是讓你為了學技術而學技術，而是讓你掌握基本的工程思維。上面那個事，一張卡多人解決了，一張卡一人也不是問題，根本不需要判斷，沒啥判斷的。謝邀，這個問題簡單談下吧。
產品經理需要的是產品規劃和總體設計，對整體業務建模的能力，然後才是各個需求點的需求分析和開發能力。產品經理不是簡單隨便的畫幾個流程圖，做點DEMO就完事的，當前大部分產品經理都達不到要求，或者說連一個合格的業務和軟體需求分析師能力都不具備。
產品經理不是說要你做過開發，而是要懂軟體工程，懂一個產品從需求提出到最終設計實現和上線整個過程是如何的，主流的開發方式是如何的，否則你如何和開發銜接？
回答正題，產品經理如何避免給開發挖坑上？產品經理要考慮的是需求本身的可擴展性，整個能力在業務場景分析和業務建模上，而不是去考慮技術實現的可擴展性，技術實現可擴展是架構人員該去考慮的問題，而不是產品經理，當然產品經理具備多年開發經驗能考慮到這點當然更強。
需求的可擴展性就是真正想清楚未來業務場景和流程可能出現的變化，可能會出現的新增，具體出現這些變化可能的原因是如何的？而架構要做的事情就是要在整體設計上考慮到這些可變因素。我們強調的並不是需求變化了開發啥都不需要改，而是盡量能以可擴展的方式改，這個在設計模式裡面會談的比較多，而我比較詫異的是當前互聯網主流開發談這塊的很少，大家都忙著去追求主流的技術研究，你嘴裡冒不出點redis，memcached，kafka，rabbitMQ這些東西好像都不會意思說是做互聯網開發的。但真正我們的開發人員在設計上考慮擴展性的時候確越來越少，這個不是產品經理的問題而是設計開發的問題。
需求可擴展性提出後，設計開發必須就要考慮設計上的可擴展性，你沒有提出開發自然不會考慮，簡單來說一個需求變更過來如果涉及到資料庫表結構模型要大改動（不是簡單擴展欄位就能解決），或者說一個需求變更涉及到大量的java文件要修改，這些變動隨便哪個開發都不想去做。即需求變化不要影響到架構，否則代價很大，就如裝修一樣，埋在地下的管線隱蔽工程要動基本就翻天覆地，你說只是牆面重新粉刷或者加裝個裝飾畫那就再簡單不過。因此在這點上對產品經理的要求還是真正想清楚業務架構模型和需求可擴展性，而不是去考慮技術實現或架構上本身如何可擴展。架構人員要考慮的是如何在需求變化時候盡量不碰觸到底層架構模型，能夠在擴展資料庫表或欄位，能夠增加新的介面實現類來解決問題。
再回來，產品經理更重要的能力是對需求可擴展的權衡，而不是一味的追求需求可擴展，所有地方都要動態靈活，都要可配置，這本身也是給開發挖坑。產品上線1，2年你都在發現你原來設計的可擴展性需求場景壓根就沒有出現，反而是整體技術實現越來越複雜並難以維護。在適當的時候，用最適當的架構做最適當的事情並保留一定擴展性才是最重要的。這種權衡不僅僅是架構權衡，也是產品經理在需求可擴展上的權衡，否則一個功能本來1，2天能搞好了，考慮了太多不切實際的擴展1，2周都做不出來，在當前互聯網敏捷迭代下往往是不合適的。任何可擴展性的引入都會增加架構整體的複雜性，也會影響到系統的性能，需求和架構在這方面都要慎重。
簡單將產品經理的埋坑及填坑分為幾種情況。前端產品經理。盡量把用戶的擴展需求想清楚，否則可能因為一個看似簡單的需求擴展，引起架構的大變化。以及盡量不要提那些看似簡單卻難以實現的需求（比如：有哪些產品經理認為很簡單，實則開發很難的技術？ - 前端開發），如果有，請準確地預估時間。比如FaceU有許多炫酷的圖像處理及人臉方面的標定和處理技術，如果一開始產品經理沒有估計清楚難度，不在技術研究或者SDK購買上早做布局，直接讓程序員上手做，這就是要搞死人的。後端產品經理。盡量把業務流程、數據元信息及各類數據結構、所需的各類支撐和運營系統思考清楚併合理規劃開發節奏、順序和所需時間。如同 @劉飛的回答中所提到的酒店系統，房間就是數據元信息，裡面涵蓋是否有WiFi、早餐及酒水等多重核心信息，以及怎麼與各個價格和庫存等子系統交互。如果元信息疏漏了重要數據或者劃分不清楚，整個系統都有可能面臨大重構。數據產品經理。盡量把需要採集的數據以及埋點需求想清楚，不要隨時打補丁收集新的數據，以及拖累技術開發不斷進行數據清理等工作。這篇回答里（數據產品經理是做什麼的？ - 何明科的回答）其實對數據產品經理，提出過一些標準。總結起來，找到靠譜的產品經理很難，而找到靠譜的後端產品經理，真是難上加難，對邏輯思維等綜合素質要求高很多，還要耐得住寂寞，畢竟大部分你負責的系統都無法直接呈現消費者面前。
======更多回答請看何明科的主頁
產品設計是一個迭代的過程，改動需求，是不可避免的。
所謂的坑，並不是指改動需求，而是指那些本可以避免的需求改動。需求， 本質是一種決策。
方案A：需要團隊10天。
風險：需求迭代可能會轉變為方案B，可能還需要20天，甚至30天，甚至根本變不了。
優點：快速上線驗證，可能會演變出新方案C、也可能放棄這個方向。方案B：需要團隊20天。
風險：這個方向就是錯的、無價值的。優點：如果此方案是對的，為後續節約了很多時間。做決策，需要掌握充足的信息。
包括業務上的、產品上的、技術上的、市場上的、團隊上的各類信息。理想的決策方式是在掌握充足信息的情況下，權衡利弊得出最有利的判斷。
但是，這對於一個人來說是很難做到的。因此，次理想的方式就是各項均有人有專長。
大家互通想法，然後有人吸收各方意見做出自己的判斷。產品在這種模式下，往往有幾個比較合適的角色。
業務專家、決策者、執行者。業務專家，你比工程師更了解業務，更知道什麼樣的東西是有價值的。
決策者，你能很好的吸收各方意見，比團隊中的任何人更可能做出正確的判斷。執行者，聽明白最後的決策，並把它很好的執行。成為某一類專家，往往可以做出更正確的判斷。
比如電影業務專家、產品專家、技術專家等。古語有云，成功的人學習他人的經驗，而一般人只學習自己的經驗。很多問題，都會有較成熟的解決方案。
也許對應的方案，沒辦法很好的解決你的問題。但也可以吸取裡面有價值的部分，來輔助自己判斷。附一些標準的系統。如何提升產品架構能力？ - huiter 的回答======避免給開發埋坑，並不是說要做出100%正確的決定，只走直線不走彎路。只要你做的足夠的專業，同時邏輯清晰，決策獲得團隊支持。這樣即使走錯了，他們也不會認為這是坑，至少不會認為這是你造成的坑。初級產品經理簡單講講。
1.了解系統架構，至少知道每一個需求點的改動位置，大致了解系統的實現機制和局限性。多和開發討論實現方式等，會對系統的了解大有裨益。2.新需求評估的時候，「復用性」往往是建立在「可配置」的基礎上的，這樣投入和產出核算就會出現問題，尤其是業務逼著PD「下周上」的時候，許多情況是無法滿足的。這個時候，評估的重點應該不是「未來的拓展」，而是「實現手法的局限性」，換句話說，就是「這樣做需求，哪些事情就做不了」，然後明確告訴業務方，這幾個場景的需求短期內無法實現。以免給開發後期挖大坑。
3.最後，遇到坑了，買好水果咖啡。。。。陪著兄弟們加班好了~~~555555
當然，有坑不可怕，可怕的是挖了坑tmd業務不靠譜，沒結果產出，這個才是最坑爹的~~~有結果的坑都值得一跳。。。無論產品還是開發（對，我說的就是PAPI醬這樣27天上線的項目）
//公眾賬號：qinhan_wang坑是永遠不可能避免的。我聽我的開發朋友們抱怨的最多的，絕對不是「PM又給我挖坑了」，而是「我靠這代碼誰寫的，到處都是坑！」然後說點正經的。PM只要對業務理解到位、有基本的數據邏輯思維、能夠產出詳細的規範的需求文檔、原型，那麼就足夠了。業務上的需求總是千變萬化的，不坑是不可能的。更需要重視的是版本的優化迭代。所以現在敏捷開發大行其道，原因就是：1）我們要正視需求的多變性；2）我們要正視技術的局限性；3）我們要正視人的力量是有限的；現在的時代，你非要把八字都沒一撇的業務場景考慮進去，完全是拖慢項目進度，增加開發成本，最終導致產品錯過市場時機。
我看成了如何給開發埋坑，心想，這個我拿手啊，興沖沖的就跑過來了。然後仔細一看，這個真心不擅長了
產品經理：要XX功能,#高級答案開始#以後可能出現xxx變化，以後不可能出現yyy變化#高級答案結束#架構師：A：完整方案，可靈活擴展，要XXX人天B：迭代方案，不可靈活擴展，但為擴展留足了空間，要YYY天C：寫完之後代碼送給你方案，以後別跟我提該需求，要ZZZ天產品經理：#初級答案開始# 不要選C #初級答案結束#
解決這個問題，有且只有一個辦法，學點技術，最起碼也得懂技術實現原理。
這根本就不是你應該考慮的問題啊，產品經理要考慮的是產品的需求，功能的完整性及操作邏輯的完整性，而不是考慮開發需要多少成本。你的設計是否符合程序現有框架根本是不重要的，你面向的是業務，這也是你這個職位存在的價值，你還能比開發更了解程序么？只要你的設計是正確的，合乎邏輯的，以及有價值的，就要堅定的執行下去。少挖坑，就是設計產品前多思考，避免無謂反覆的需求變更。你的問題就是業務場景及其帶來的業務價值根本沒考慮清楚，這還能不挖坑嗎？
說下產品初期的注意事項吧，找好定位，打好基礎，坑不可避免，只能盡量減少到最小！首先對 @劉飛 大大的觀點表示下強烈認同，產品經理需要懂技術，不需要精，最少要知道各個開發語言的作用，實現環境，優勢和劣勢都是什麼，起碼做到和技術有的聊，別做懵逼狀就好。
產品初期（投入研發之前）如何打造產品初期框架，要不要做用戶調研，很多公司都會面臨這方面的問題或爭議。而作為產品經理必須要從多方面考慮，公司是否找准了商業定位？產品定位是否能支撐公司的商業定位？初期版本哪些功能可以上？哪些需要用戶反饋後迭代？可以上的功能和產品形態是否具有高容錯性、復用性？主要是開發會不會做無用功。
用戶調研需不需要做？什麼時間做？用戶調研和產品研發會不會有衝突？在沒有用戶場景的情況下，用戶參與感強不強？調研結果準確度高不高？......
等等這些問題都是需要投入大量精力去思考和衡量，不同行業背景有可能做法也會不一樣。下面梳理下自己在遇到這些問題時的一些想法做法，背景是興趣實踐社交。
問題梳理
（基本都是真實發生的一些問題討論）
產品定位是什麼？
這是在產品初期必須要做的事情，在這之前還有另一個必須要做的事情就是公司的商業定位，這兩個定位一定要明確化。
為什麼未做用戶調研，就開始研發設計？
試想一下即使在公司內部溝通，沒有線框圖效果圖的情況下溝通成本高不高，更何況是對用戶。用戶調研肯定會做，可以和產品研發並行，也可以等到產品上線之後。縱觀互聯網to c的產品，沒幾個說是在做了用戶調研之後才開始開發的，包括微信、滴滴、餓了么、美團等大廠公司。用戶調研，尤其是產品功能可行性方面，總得先搭一個場景出來，或是demo或是滿足用戶基本功能的產品，主要目的就是把用戶更快的代入場景。
為什麼會定100000的KPI？
KPI,算是結果導向的一種表現形式，定KPI的主要目的,在我看來不一定要你非得完成此指標，而是在有指標的前提下，給自己的目標明確化，有壓力，有動力，激發潛能，爭取能實現一個超預期。
這屬於產品階段問題，迭代方案會出，但沒有辦法非常明確，這個階段稱之為應急預案比較貼切。產品從0到1階段，也就是迭代上線階段。在上線之後有了用戶數據、用戶反饋之後才會給出比較明確的迭代方案，不然一切都是空談。產品迭代方案的核心不夠明確。
首先不是完整的產品架構，只算是基礎架構，基礎框架基於產品定位完全可以給出的。其次現有架構設計是綜合各方面考量的結果:1設計研發人員不能閑置，2產品功能上面容錯性、復用性高，不會做無用開發，3節奏感的把控，時間管理的考量。與用戶的接觸很少，為什麼在極短的時間內做出了完整的產品的框架？
還是那句話，用戶調研不是不做，但現在的優先順序不是很高，或者可以說現在所做的事情就是在為用戶調研作準備，進行場景搭建。
------------------舉例-----------------------
初期版本長什麼樣子，不是很方便展示給大家，就拿知乎做案例做下分析。
可以先想一想知乎的定位是什麼？
知乎- 與世界分享你的知識、經驗和見解
單獨按照官方給出slogan來講好像不是很精準，因為百度知道，其他的bbs論壇都可以這樣說。
回憶一下初期知乎的運營策略是什麼，稱之為「裙帶效應」應該算是貼切。
知乎的初期用戶主要以互聯網精英為主，起初施行的是邀請註冊機制，推廣（小推）形式說起來也簡單，通過各大社區、論壇、博客尋找有優質產出的用戶，向其發放邀請碼，後續也引入了李開復、雷軍為首的高知名度業界大咖陣容。經歷兩年多的時間沉澱優質內容，定性嚴謹的言論格調，直到2013年3月，才開始面向公眾開放註冊，如果以此時間節點作為分割線，知乎3年前用戶40萬而3年後是3000萬！對「厚積薄發」做了完美的詮釋！
回過頭來說下精準定位，嘗試做了總結，在官方的slogan後面加一句「打造圈子內的意見領袖」是不是感覺和其他的社區、bbs論壇就有了區分。
在基於這個產品的定位下，是不是能夠搭建出產品的基礎框架了？先回憶，還記得早期的知乎長啥樣不？（圖不是最早期的，因為我也沒有存檔）
首頁
菜單頁
這種產品形態就屬於知乎的基礎架構，主要頁面就兩個，一個首頁、一個抽屜菜單，評論回答，收藏，點贊都在子頁面，那時還沒有寫文章功能。基於產品定位，這樣的產品架構，能不能投入研發，當然能了，會不會成為技術的坑，當然不會，都是基礎功能，即使後續產品形態有變動，產品功能也不會被cut。
所以產品初期設計的基本思路就是，找准商業定位、產品定位，構建高復用性的基礎功能版本框架，快速迭代上線，獲取用戶反饋驗、後續功能驗證迭代。
------end---------
產品經理要懂開發，這樣在設計產品的時候才不會給開發埋坑；產品經理要懂營銷，這樣在設計產品的時候才不會給市場埋坑；產品經理要懂運營，這樣在設計產品的時候才不會給運營埋坑；…
把產品需求深度挖掘，很多改需是因為產品自身沒有把產品的需求想太深，沒有好好的列出playA,playB,playC，也沒有集思廣益好好和大家詳談，最重要的，就是沒有負責，在得到需求時，產品最先要做的就是和需求的提出人討論，你為什麼提出這個需求，你的需求是為了解決你產品的什麼問題？
不負責任的產品聽了，哦，好的，然後接著文檔一寫原型一做，呵呵就當起了老大爺，如果你敢討論，敢挖掘，你就會發現也許這個需求有更好的實現辦法，甚至能連接到其他未完成，或者已完成的功能，把復用率提高，減少開發成本和時間預算
開發的時間是產品省下來的，你有多能，開發就有多爽，產品你不一定要懂技術上的很多東西，什麼BUG對沖什麼兼容性，但是你至少你要做到你本職的工作，你不是應聲蟲，而是努力成為能照顧一個團隊的輔助型carryMark住來寫。
你想多了，自己挖的坑，從來都是自己跳的。想要開發幫你填？做夢把。。。
1. 這事情要具體事情具體分析，單純抽象的講道理講方法幫助很有限，極有可能說話這人就沒整明白產品經理該幹什麼在胡扯耍流氓；或者這個人的產品觀已經融入到骨子裡是個大神。當然，後者我還沒見到過活的(⊙o⊙)…2. 既然題目提的是產品經理，以下所有的內容都建立在這個PM不是二逼的前提下，如果這人是個滿嘴跑火車，根本搞不清楚業務場景，功能需求，工作流程，就是為了改變世界才跳入PM火坑的人，那不用往下看了，早燒死他程序猿早解脫，基本是無藥可救狀態。3. 一個產品從0到1的過程中，需求變動是不可避免的。越扁平化的公司越是如此，關鍵看怎麼改。4. 改分為兩種情況，把原需求改掉，或者在整個業務鏈閉環中加。前者多為細節更改，這裡就是大家常說的又改需求了。後者其實很多時候對程序猿的要求比較高，你的程序模塊間耦合度是不是夠低，代碼是不是可拓展。並不單純是產品經理的鍋。5. 其次，外部條件也很重要。客觀的產品開發限制，如時間等；主觀的不同的人提出的不同意見或者同一個人在不同的時間裡提出的不同意見等。6.產品的工期多長？如果時間很緊張，一定程度意味著代碼質量降低，後期（如果有的話）需要重構。這種項目一般是為了搶奪市場或者實驗性投放，一旦出問題就快速調整。所以所有主線需求流程務必落到紙上，而紙上的東西最低標準確保能跑通，然後儘可能達到自己滿意。接下來產品經理的主要任務是確保進度以及保證進度的正確性，除非需求完全就是錯的，不然謹慎或者別修改。如果時間不緊張，這個時候修改需求是否會造成麻煩反而很多時候看程序猿的水平。耦合度多高，配置的靈活性多高，hardcode有多少等等，這種項目一般投放出去因為開發周期長而沒有時間修改或者受眾面大而沒有機會修改。需求說明書要寫詳細，不一定要特別規範，因為可能還會來回改。但這種情況就要有一點必須把握好，後面可能哪裡會改要有個範圍，做之前就跟程序猿達成共識，程序層面上提前預留調整空間。7. 大家對這個產品的定位或者期待是怎樣的。8. 這裡需要控制預期和戰略眼光，講一種情況說明下，如果是具有戰略意義的項目，很有可能你的上級會頻頻過問，然後經常給出自己的意見或需求。外行思考必然是發散的，需要PM去收斂，取捨歸併做加減法。控制好別人對產品的預期。做好這件事情的前提是你對產品的戰略眼光，如果你思考的產品場景滿足了核心需求，他們提出來的問題你就不需要過分擔心輕鬆處理掉，反之你自己會一團亂麻，程序猿還會被需求變更搞死。至於如何控制預期具備戰略眼光是另外一個問題了，這裡不展開。9. 後續有需要再補充。
首先，你要有一個好老大。一個足夠理性，一個不會說出"我不管，我就要這樣"的傻逼老大。
我一直覺得產品經理一定要前端後端ios安卓都精通！因為這樣才能不會提出不合理的需求！因為這樣產品經理就知道怎麼提高代碼的復用率！節省開發時間！因為這樣程序猿哥哥們才能不用加班不用熬夜早早回家碎覺覺！因為這樣產品經理在技術說無法實現時，傲嬌的站出來，說用xxxx就好了！當場打臉！因為這樣，程序猿哥哥就能不煩產品經理！嗯，對，就這樣！我不會告訴你我是一個當過程序媛當過運營狗當過pr 當過測試的產品狗！
推薦閱讀：
※前端開發js函數式編程真實用途體現在哪裡？
※怎麼評價Vue.js2.5以後要大力加強對TypeScript和VSCode的支持？
※font-weight和fontWeight的區別？
※onclick = xxx這種賦值寫法綁定事件的原理是什麼？
※有哪些常用軟體是用WEB前端技術寫的?底層使用瀏覽器殼?