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