產品經理對于技術實現層面的考慮有哪些？需要如何考慮呢？
產品經理在設計功能的時候，為了便于功能的實現，有些時候要考慮到技術部門的開發情況，在符合產品定位、用戶體驗的前提下，盡量保證實現難度和周期的可控，比如
新產品設計功能時，可能要考慮技術選型上框架是否支持、前端組件是否適用等。
版本迭代的時候，功能界面的設置與調整是否會影響到技術實現過程中的復雜程度等。
就好像我們在設計過程中要考慮運營便捷度，業務推廣等因素一樣，技術也是要顧及到的一環。
那么，大家往往會在什么時候來考慮技術實現方面的問題？又會從哪些角度去考慮？如果自身對技術并不了解，是否有固定的方式與技術部門保持聯系，使得設計的功能可以最大化的便于開發呢？
新產品設計功能時，可能要考慮技術選型上框架是否支持、前端組件是否適用等。
版本迭代的時候，功能界面的設置與調整是否會影響到技術實現過程中的復雜程度等。
就好像我們在設計過程中要考慮運營便捷度，業務推廣等因素一樣，技術也是要顧及到的一環。
那么，大家往往會在什么時候來考慮技術實現方面的問題？又會從哪些角度去考慮？如果自身對技術并不了解，是否有固定的方式與技術部門保持聯系，使得設計的功能可以最大化的便于開發呢？
沒有找到相關結果
已邀請:
5 個回復
米斯爾 - 改變自己
贊同來自: 金剛心 、草莓奶昔
1、目標。
要讓團隊成員和技術知曉一些重點功能背后的價值和目的。這才能讓整個團隊清楚重要性。團隊成員每個人都可以對產品提建議，有的時候產品人員需要拿出各種方法來說服成員，包括使用客觀的調查數據等；
重要功能輕易不能妥協。
2、梳理業務邏輯
技術在實現上本身就是一個邏輯活。
有的時候產品經理與技術溝通過程當中，很多就是因為邏輯的偏差導致需求無法實現。將自己的業務邏輯梳理給到技術很重要。
3、表示難度太大，搞不定？
原因1：技術不懂且是個不主動的人（態度問題）?！a品人員去谷歌、技術社區、找技術的領導一起討論等，幫他一起找技術方案的資料。
原因2：技術方案可實現但難度大?！偃暨@個功能真的極其重要，一起討論解決方案。短時間內有沒有低成本的變通的方案；難度大的技術方案局限在什么地方；實現技術方案需要耗費多少時間成本和其他成本。
最后說一點，有時候花費大量精力做出來的功能也許真的與你之前的想象完全不同，所以在沒有真正的定論之前，最好用最小成本先上去妥協版的，甚至是個demo，先測試。有數據都好說話。
創世紀 - 的哈桑的hi安徽省大紅花
贊同來自: 草莓奶昔
這個問題要從幾個方面看：
1. 從產品本身來看需要你確定這個需求的價值，可以從KANO模型，ROI投資回報率上來對需求重要性排序，優先做有價值的東西，時間來不來的及
2. 確定了價值，下面就是需求實現的問題，一般來說需求是有多種實現方式的。不僅僅是技術上的，還有其他表現形式上的。打個比方，用戶說要可樂，基本的需求是因為渴了，而你如果提供礦泉水其實一樣能解決問題，這個需要你從本質上理解用戶需求；技術上，實現一個功能，可能寫一個工廠方法就可以簡化很多事情，而開發也可以己腦洞大開過度設計（這種對于入門沒多久又有理想的程序員是比較常見的）。這個在提需求的時候，你提給開發的需求更應該說用戶story，而不是描述解決方案：規定好他應該怎么做。同時盡量找開發領導提前溝通需求，這樣有可能他會給你一種更加好的實現方案
3. 最后就是努力充實自己，面向對象的編程思維可以多了解了解。產品經理的UML工具其實就是面向對象的思考方式，你可以不用管這個方法具體是通過寫了多少行代碼實現的，只需要想通中間的邏輯是怎樣的即可，這樣又可以反過來促進你了解：你的設計中有沒有遺漏什么，下一版功能可以往哪拓展；從整體邏輯的復雜性推算功能的實現時間，對整體開發時間的估算越來越有把握，避免被開發忽悠
金剛心 - 我就是愛拼才會贏他本人！
贊同來自:
如果該功能是核心功能，那么只能招人來實現，如果不行只能說公司在這個問題上對產品規劃過于冒進。?
如果不是，可以先以能實現的缺陷方式先實現，后期向研發反應，由專人研究彌補缺陷。
卓哥 - 天卓社區創始人
贊同來自:
其實很多時候，技術實現困難或者成本高，是對業務理解有偏差所致。
其次，產品經理在構思產品邏輯和功能形態的時候，應該在一定程度上（特別是特定時間范圍內）考慮避開技術瓶?；蛘呒夹g評審后提出技術困難，可以考慮調整產品方案，以達到盡快上線推進業務的目的。
此外，如果技術團隊能力薄弱（主要是小公司，或者技術投入小的情況）產品經理在了解到技術癥結之后，可以去外界尋找一下解決方案（找人、找資料等等），給技術人員一些啟發和思路。
草莓奶昔 - 最靈繁的人也看不見自己的背脊
贊同來自: