針對這些年旁觀和經歷過的技術產品場景，做一些個人的總結和判定，盡量不涉及爭議性話題，比如對一個互聯網公司而言，技術重要還是產品重要之類的，這種話題一扯開，各有道理，誰也別指望說服誰。
此外，加一個前綴，主要針對非技術領導者所面臨的技術管理困境，在很多從傳統企業轉型或個人站轉型的互聯網企業里，這個問題較為突出。
以下一些產品經理 or Boss 面臨的場景，不知道讀者是否熟悉。
這么簡單的需求？為什么開發告訴我要做那么久？
同行 or 競爭對手都做出來了，為什么我的開發說這個無法實現？
我明明說清楚了，開發也確認了，給我的產品怎么是這么奇怪的一坨？和我想要的完全不是一回事。
線下測試都ok，一上線就各種崩潰，詭異現象，弄得我們什么運營活動都搞不了.
請了個大公司出來的，工資巨高的，結果也沒看出比便宜程序員好在哪里？
天哪，又給我說要重構！又是好幾個月啥需求都做不了！
看上去，有沒有同感？且慢，程序員也有話說。
你需求三天一改，兩天一變，你以為我代碼會72變，我多少工作打水漂了你知道不？
你說這個簡單，你前面系統數據結構各種不支持，我不大改我根本支撐不了這需求，我跟你說數據結構你聽么你？
你告訴我做A,B,C,D,E，我都按你說的做了，做完了你說不是你要的，鬼知道你要什么。
你就給我這點開發時間，我已經加班給你把事干了，我反正實現了，測試也通過了，線上出問題，你業務場景各種詭異，我哪里知道，又沒早跟我說。
天天有事沒事就拉我開會，你知道我思路多難集中么？完全沒效率，你尊重過我的時間么？你以為寫代碼隨時抽五分鐘就能寫一坨么？
這代碼補丁打得，找一個小問題要一個下午，不重構你后續功能沒一個可以順利快速搞起來的，我替你考慮，你還埋怨我？
哎哎哎，上面的那位童鞋不要亂講，我設計架構的時候，也沒想到現在業務這么變態啊，當時我可是按照標準的流行業務模式設計的。你沒理解我架構精髓，就知道重構，你有問題哦你。
好了，打住打住，架構這話題太大，程序員自己都會pk起來，不和諧。
下面說一下我的理解和相應的對策。
問題1：信息不對稱
產品人員往往認為，描述了功能需求，甚至簡單的給一個競爭對手的范例，工程師就能完美的實現所有業務需求；但是，工程師對業務的理解往往是欠缺的，因此在產品的塑造上，很可能因為個人理解偏差，帶來極大的隨意性；即便是產品經理具有超強的控制力和投入，保證技術在功能實現上與使用場景吻合，但往往因忽略了業務的性能訴求，導致線下ok的東西，線上各種問題。
個人認為，讓技術充分了解業務訴求，并參與業務討論，是有必要的，只有這樣，才能深刻理解產品的設計目標和設計要點，這樣才能減少產品跑偏，與需求不符的現象。
問題2：尊重技術人員的時間觀
工程師什么時候開發效率最高？我相信不止我一個人會有這樣的感覺，凌晨1點-2點這段是時間，夜深人靜，無人打擾，開發效率最高。應盡可能營造無打擾，無中斷的開發環境；從設計代碼到編程到測試，開發需要整段的時間來思考和實現，比如下午4點有個會，哪怕只有10分鐘，等于一個下午沒有效率。至少以我個人而言，是做不到可以隨時中斷，隨時繼續的開發水準。我幾年前比較多的編程都是在半夜完成的。
所以，產品人員應當與技術人員勤溝通不錯，但是請盡量將完整時間給工程師，比如早上上班后開溝通會，保證后續的完整性，下午午飯后立即開溝通會，或者用午餐會的形式，留給完整的下午時間給工程師，都是值得建議的方案。
問題3：理想主義情緒
開發人員往往有理想主義情節，希望所設計的架構可以支撐更廣泛更持續的應用訴求；有時候產品人員也會有這樣的想法，過于追求遠大的宏偉目標；理想主義往往導致投入太多的無用功到無謂的兼容性設計上，而實際上，隨著業務的發展和市場的變換，往往大部分提前準備的或者按照高端目標準備的設計，都是浪費的；其實，最重要的是把握當下的市場，互聯網產品淘汰更新頻率太快，未來是怎樣，很多不確定的因素。
一個典型的架構悖論是，為了支撐更多更復雜的業務訴求，而設計了一個非常宏偉龐大的架構，但是新的訴求出現的時候，很抱歉，互聯網發展太快，新的訴求超出了最初的預期，然后，因為架構太復雜太龐大，所以無法實現。
這事在著名的互聯網上市公司是經常出現的。
輕架構，著重當下，代碼做好低耦合就可以了，不用把架構弄得太復雜，而且，個人認為，最好的設計是，讓后續的程序員（中等水平），不讀文檔，只看代碼就能接手。
問題4：80%的無用功
這事可以說是問題3的升級版；也可以說是問題1的升級版；程序員往往因為對業務訴求不清晰；或者為了追求完美，將80%的精力投入到并不存在的業務訴求上，這我也遇到過，而且，當事人，無論是產品負責人，還是技術人員，在我點明之前，都茫然不知，以為只是技術不夠成熟才導致周期過長。
舉個簡單例子，在統計系統，查看來訪的refer統計，如果一個網站有幾萬個refer來路，請問哪個站長會去看超過1000名以后的來路？這個業務訴求是不存在的，但是工程師卻努力的為此糾結，‘我的存儲壓力太大了啊，每天要存儲多少這類信息啊?！?你需要存這么多么？
類似的很多數據統計和分析系統里，匯總數據是不能丟的，這是必須的，但是各種排行數據，總有一些長尾是業務上永遠不會去看的，這些數據占據了80%甚至90%的存儲資源，帶來各種負載和查詢壓力，而實際上，卻不存在這樣的業務訴求。
簡單說，很多業務系統，都存在這樣的現象，有超過90%的數據為了滿足不到1%的需求，怎么處理？
小公司，建議直接砍掉；大公司，留在另冊保存，單獨查詢接口，不占用主體業務資源。
這樣下去，技術壓力就會減輕很多，考慮的復雜度就會降低很多。
問題5：考核機制
抱歉又要說這個經典案例了，明明可以很簡單完成的事情，工程師會說”我要評高級工程師，我需要有技術價值體現啊，我不能這么簡單的做啊！“ 這事在大公司常見，所以簡單問題復雜化，管理考核體制首當其沖。
順便說一句，大公司創新乏力，很大程度是被這個原則拖累的，程序員想的不是把產品做多牛，是自己技術炫出來先，好上一個層級；產品人員只好苦捱技術炫技的過程，錯失市場良機。
問題6：沒有足夠的思考和設計時間，以及學習研究的時間
好吧，前面說了，不要追求完美，不要設計復雜的架構，但是即便是輕架構，即便是簡單的代碼，也需要足夠設計和思考的時間；
小公司、非技術管理者，往往簡單的認為，實現開發就是編碼、編碼、編碼。
其實，設計到位，編碼就會如拉稀一般一瀉千里；設計不到位，就如便秘一般，寸行難行。
按個人的經驗，自己以前設計統計系統的時候，會想幾周，做一些簡單代碼，測試一些想法和原型；等一切思路上的疑惑解決后，編程就是很簡單很容易的事情了。
看程序員的工作效果，請給予更寬松的時間和績效考量，不要看一個程序員發呆，或者聽音樂，就下結論說他不干活；別真把程序員當碼農。
當然，必須指出，好的程序員，在思考清楚后，實現效率是快的驚人的，也請部分開發工程師別為自己的偷懶和無作為推脫。
簡單的評判標準是，如果給一個優秀的程序員足夠的思考和空閑時間，應該有一個代碼爆發期；他的成果應該能夠在短時間內得到集中的體現。如果是思考一段時間后寫代碼依然便秘的，那么，這個人的水平大概也就清楚了。
問題7：資深與多面
大公司的技術人員，如果不是特別頂級的，往往能力局限在某個領域，當然深度足夠，但是廣度基本都很欠缺；特別是一畢業就進入大公司的，最悲慘的是在某個特定架構下寫程序的，寫了五年后出來一看，尼瑪原來自己只會寫一種架構下的代碼。（當然，必須指出，在大公司還是早期小公司的時候進入的技術人員，往往更全面一些。） 而小公司往往需要多面手，最好服務端也會，客戶端也會，樣式表也會，反正老板是分不出寫程序和寫程序還是有區別的。但是深度要求，恐怕就沒大公司那么深了。
所以問題來了，從大公司挖一個專家來，結果發現這個不會，那個也不會，還不如自己3000塊錢招的野路子程序員；這就是需求不匹配，目標不清楚；如果小公司遇到了非常嚴重的技術瓶頸，一旦突破業務會爆發性增長；而恰好某個大公司有這個領域的技術專家，那么這種定向的動作是會有很好的效果；但是如果只是覺得技術差點事，或者只是對技術不滿意，希望通過來一個大公司的解決問題，這事能如愿的不多；
當然，還是那句話，從小公司開始就進入大公司的元老核心技術，見證一個公司從小到大歷程的，經歷過公司幾次技術升級的，是非常難得的極品人才，問題是，這樣的人，市場上是很難遇到的。而且，就算遇到了，往往也不是小公司請的起的。
七扯八扯，勉強湊成一篇，最近人退化的厲害，寫不動博客了，湊活看吧。
不認同的，有意見的，您隨意吧。
轉自：http://blog.csdn.net/hguisu/article/details/11721659
原創文章，作者：s19930811，如若轉載，請注明出處：http://www.www58058.com/2628
