針對這些年旁觀和經(jīng)歷過的技術(shù)產(chǎn)品場景，做一些個人的總結(jié)和判定，盡量不涉及爭議性話題，比如對一個互聯(lián)網(wǎng)公司而言，技術(shù)重要還是產(chǎn)品重要之類的，這種話題一扯開，各有道理，誰也別指望說服誰。

    此外，加一個前綴，主要針對非技術(shù)領(lǐng)導(dǎo)者所面臨的技術(shù)管理困境，在很多從傳統(tǒng)企業(yè)轉(zhuǎn)型或個人站轉(zhuǎn)型的互聯(lián)網(wǎng)企業(yè)里，這個問題較為突出。

    以下一些產(chǎn)品經(jīng)理 or Boss 面臨的場景，不知道讀者是否熟悉。

    這么簡單的需求？為什么開發(fā)告訴我要做那么久？

    同行 or 競爭對手都做出來了，為什么我的開發(fā)說這個無法實(shí)現(xiàn)？

    我明明說清楚了，開發(fā)也確認(rèn)了，給我的產(chǎn)品怎么是這么奇怪的一坨？和我想要的完全不是一回事。

    線下測試都o(jì)k，一上線就各種崩潰，詭異現(xiàn)象，弄得我們什么運(yùn)營活動都搞不了.

    請了個大公司出來的，工資巨高的，結(jié)果也沒看出比便宜程序員好在哪里？

    天哪，又給我說要重構(gòu)！又是好幾個月啥需求都做不了！ 

    看上去，有沒有同感？且慢，程序員也有話說。

    你需求三天一改，兩天一變，你以為我代碼會72變，我多少工作打水漂了你知道不？

    你說這個簡單，你前面系統(tǒng)數(shù)據(jù)結(jié)構(gòu)各種不支持，我不大改我根本支撐不了這需求，我跟你說數(shù)據(jù)結(jié)構(gòu)你聽么你？

    你告訴我做A,B,C,D,E，我都按你說的做了，做完了你說不是你要的，鬼知道你要什么。

    你就給我這點(diǎn)開發(fā)時間，我已經(jīng)加班給你把事干了，我反正實(shí)現(xiàn)了，測試也通過了，線上出問題，你業(yè)務(wù)場景各種詭異，我哪里知道，又沒早跟我說。

     天天有事沒事就拉我開會，你知道我思路多難集中么？完全沒效率，你尊重過我的時間么？你以為寫代碼隨時抽五分鐘就能寫一坨么？

     這代碼補(bǔ)丁打得，找一個小問題要一個下午，不重構(gòu)你后續(xù)功能沒一個可以順利快速搞起來的，我替你考慮，你還埋怨我？

     哎哎哎，上面的那位童鞋不要亂講，我設(shè)計架構(gòu)的時候，也沒想到現(xiàn)在業(yè)務(wù)這么變態(tài)啊，當(dāng)時我可是按照標(biāo)準(zhǔn)的流行業(yè)務(wù)模式設(shè)計的。你沒理解我架構(gòu)精髓，就知道重構(gòu)，你有問題哦你。

     好了，打住打住，架構(gòu)這話題太大，程序員自己都會pk起來，不和諧。

下面說一下我的理解和相應(yīng)的對策。

問題1：信息不對稱

       產(chǎn)品人員往往認(rèn)為，描述了功能需求，甚至簡單的給一個競爭對手的范例，工程師就能完美的實(shí)現(xiàn)所有業(yè)務(wù)需求；但是，工程師對業(yè)務(wù)的理解往往是欠缺的，因此在產(chǎn)品的塑造上，很可能因?yàn)閭€人理解偏差，帶來極大的隨意性；即便是產(chǎn)品經(jīng)理具有超強(qiáng)的控制力和投入，保證技術(shù)在功能實(shí)現(xiàn)上與使用場景吻合，但往往因忽略了業(yè)務(wù)的性能訴求，導(dǎo)致線下ok的東西，線上各種問題。

個人認(rèn)為，讓技術(shù)充分了解業(yè)務(wù)訴求，并參與業(yè)務(wù)討論，是有必要的，只有這樣，才能深刻理解產(chǎn)品的設(shè)計目標(biāo)和設(shè)計要點(diǎn)，這樣才能減少產(chǎn)品跑偏，與需求不符的現(xiàn)象。

問題2：尊重技術(shù)人員的時間觀

        工程師什么時候開發(fā)效率最高？我相信不止我一個人會有這樣的感覺，凌晨1點(diǎn)-2點(diǎn)這段是時間，夜深人靜，無人打擾，開發(fā)效率最高。應(yīng)盡可能營造無打擾，無中斷的開發(fā)環(huán)境；從設(shè)計代碼到編程到測試，開發(fā)需要整段的時間來思考和實(shí)現(xiàn)，比如下午4點(diǎn)有個會，哪怕只有10分鐘，等于一個下午沒有效率。至少以我個人而言，是做不到可以隨時中斷，隨時繼續(xù)的開發(fā)水準(zhǔn)。我?guī)啄昵氨容^多的編程都是在半夜完成的。

所以，產(chǎn)品人員應(yīng)當(dāng)與技術(shù)人員勤溝通不錯，但是請盡量將完整時間給工程師，比如早上上班后開溝通會，保證后續(xù)的完整性，下午午飯后立即開溝通會，或者用午餐會的形式，留給完整的下午時間給工程師，都是值得建議的方案。

問題3：理想主義情緒

       開發(fā)人員往往有理想主義情節(jié)，希望所設(shè)計的架構(gòu)可以支撐更廣泛更持續(xù)的應(yīng)用訴求；有時候產(chǎn)品人員也會有這樣的想法，過于追求遠(yuǎn)大的宏偉目標(biāo)；理想主義往往導(dǎo)致投入太多的無用功到無謂的兼容性設(shè)計上，而實(shí)際上，隨著業(yè)務(wù)的發(fā)展和市場的變換，往往大部分提前準(zhǔn)備的或者按照高端目標(biāo)準(zhǔn)備的設(shè)計，都是浪費(fèi)的；其實(shí)，最重要的是把握當(dāng)下的市場，互聯(lián)網(wǎng)產(chǎn)品淘汰更新頻率太快，未來是怎樣，很多不確定的因素。

一個典型的架構(gòu)悖論是，為了支撐更多更復(fù)雜的業(yè)務(wù)訴求，而設(shè)計了一個非常宏偉龐大的架構(gòu)，但是新的訴求出現(xiàn)的時候，很抱歉，互聯(lián)網(wǎng)發(fā)展太快，新的訴求超出了最初的預(yù)期，然后，因?yàn)榧軜?gòu)太復(fù)雜太龐大，所以無法實(shí)現(xiàn)。

這事在著名的互聯(lián)網(wǎng)上市公司是經(jīng)常出現(xiàn)的。

輕架構(gòu)，著重當(dāng)下，代碼做好低耦合就可以了，不用把架構(gòu)弄得太復(fù)雜，而且，個人認(rèn)為，最好的設(shè)計是，讓后續(xù)的程序員（中等水平），不讀文檔，只看代碼就能接手。

問題4：80%的無用功

       這事可以說是問題3的升級版；也可以說是問題1的升級版；程序員往往因?yàn)閷I(yè)務(wù)訴求不清晰；或者為了追求完美，將80%的精力投入到并不存在的業(yè)務(wù)訴求上，這我也遇到過，而且，當(dāng)事人，無論是產(chǎn)品負(fù)責(zé)人，還是技術(shù)人員，在我點(diǎn)明之前，都茫然不知，以為只是技術(shù)不夠成熟才導(dǎo)致周期過長。

舉個簡單例子，在統(tǒng)計系統(tǒng)，查看來訪的refer統(tǒng)計，如果一個網(wǎng)站有幾萬個refer來路，請問哪個站長會去看超過1000名以后的來路？這個業(yè)務(wù)訴求是不存在的，但是工程師卻努力的為此糾結(jié)，‘我的存儲壓力太大了啊，每天要存儲多少這類信息啊。’ 你需要存這么多么？

類似的很多數(shù)據(jù)統(tǒng)計和分析系統(tǒng)里，匯總數(shù)據(jù)是不能丟的，這是必須的，但是各種排行數(shù)據(jù)，總有一些長尾是業(yè)務(wù)上永遠(yuǎn)不會去看的，這些數(shù)據(jù)占據(jù)了80%甚至90%的存儲資源，帶來各種負(fù)載和查詢壓力，而實(shí)際上，卻不存在這樣的業(yè)務(wù)訴求。

簡單說，很多業(yè)務(wù)系統(tǒng)，都存在這樣的現(xiàn)象，有超過90%的數(shù)據(jù)為了滿足不到1%的需求，怎么處理？

小公司，建議直接砍掉；大公司，留在另冊保存，單獨(dú)查詢接口，不占用主體業(yè)務(wù)資源。

這樣下去，技術(shù)壓力就會減輕很多，考慮的復(fù)雜度就會降低很多。

問題5：考核機(jī)制

       抱歉又要說這個經(jīng)典案例了，明明可以很簡單完成的事情，工程師會說”我要評高級工程師，我需要有技術(shù)價值體現(xiàn)啊，我不能這么簡單的做啊！“ 這事在大公司常見，所以簡單問題復(fù)雜化，管理考核體制首當(dāng)其沖。

順便說一句，大公司創(chuàng)新乏力，很大程度是被這個原則拖累的，程序員想的不是把產(chǎn)品做多牛，是自己技術(shù)炫出來先，好上一個層級；產(chǎn)品人員只好苦捱技術(shù)炫技的過程，錯失市場良機(jī)。

問題6：沒有足夠的思考和設(shè)計時間，以及學(xué)習(xí)研究的時間

       好吧，前面說了，不要追求完美，不要設(shè)計復(fù)雜的架構(gòu)，但是即便是輕架構(gòu)，即便是簡單的代碼，也需要足夠設(shè)計和思考的時間；

小公司、非技術(shù)管理者，往往簡單的認(rèn)為，實(shí)現(xiàn)開發(fā)就是編碼、編碼、編碼。

其實(shí)，設(shè)計到位，編碼就會如拉稀一般一瀉千里；設(shè)計不到位，就如便秘一般，寸行難行。

按個人的經(jīng)驗(yàn)，自己以前設(shè)計統(tǒng)計系統(tǒng)的時候，會想幾周，做一些簡單代碼，測試一些想法和原型；等一切思路上的疑惑解決后，編程就是很簡單很容易的事情了。

看程序員的工作效果，請給予更寬松的時間和績效考量，不要看一個程序員發(fā)呆，或者聽音樂，就下結(jié)論說他不干活；別真把程序員當(dāng)碼農(nóng)。

當(dāng)然，必須指出，好的程序員，在思考清楚后，實(shí)現(xiàn)效率是快的驚人的，也請部分開發(fā)工程師別為自己的偷懶和無作為推脫。

簡單的評判標(biāo)準(zhǔn)是，如果給一個優(yōu)秀的程序員足夠的思考和空閑時間，應(yīng)該有一個代碼爆發(fā)期；他的成果應(yīng)該能夠在短時間內(nèi)得到集中的體現(xiàn)。如果是思考一段時間后寫代碼依然便秘的，那么，這個人的水平大概也就清楚了。

問題7：資深與多面

       大公司的技術(shù)人員，如果不是特別頂級的，往往能力局限在某個領(lǐng)域，當(dāng)然深度足夠，但是廣度基本都很欠缺；特別是一畢業(yè)就進(jìn)入大公司的，最悲慘的是在某個特定架構(gòu)下寫程序的，寫了五年后出來一看，尼瑪原來自己只會寫一種架構(gòu)下的代碼。（當(dāng)然，必須指出，在大公司還是早期小公司的時候進(jìn)入的技術(shù)人員，往往更全面一些。） 而小公司往往需要多面手，最好服務(wù)端也會，客戶端也會，樣式表也會，反正老板是分不出寫程序和寫程序還是有區(qū)別的。但是深度要求，恐怕就沒大公司那么深了。

所以問題來了，從大公司挖一個專家來，結(jié)果發(fā)現(xiàn)這個不會，那個也不會，還不如自己3000塊錢招的野路子程序員；這就是需求不匹配，目標(biāo)不清楚；如果小公司遇到了非常嚴(yán)重的技術(shù)瓶頸，一旦突破業(yè)務(wù)會爆發(fā)性增長；而恰好某個大公司有這個領(lǐng)域的技術(shù)專家，那么這種定向的動作是會有很好的效果；但是如果只是覺得技術(shù)差點(diǎn)事，或者只是對技術(shù)不滿意，希望通過來一個大公司的解決問題，這事能如愿的不多；

當(dāng)然，還是那句話，從小公司開始就進(jìn)入大公司的元老核心技術(shù)，見證一個公司從小到大歷程的，經(jīng)歷過公司幾次技術(shù)升級的，是非常難得的極品人才，問題是，這樣的人，市場上是很難遇到的。而且，就算遇到了，往往也不是小公司請的起的。

七扯八扯，勉強(qiáng)湊成一篇，最近人退化的厲害，寫不動博客了，湊活看吧。

不認(rèn)同的，有意見的，您隨意吧。

轉(zhuǎn)自：http://blog.csdn.net/hguisu/article/details/11721659