⑴ 工作中如何做好技術積累
古人雲：「活到老，學到老。」互聯網算是最辛苦的行業之一，「加班」對工程師來說已是「家常便飯」，同時互聯網技術又日新月異，很多工程師都疲於應付，叫苦不堪。以至於長期以來流傳一個很廣的誤解：35歲是程序員工作的終點。
如何在繁忙的工作中做好技術積累，構建個人核心競爭力，相信是很多工程師同行都在思考的問題。本文是我自己的一些總結，試圖從三個方面來解答：
第一部分闡述了一些學習的原則。任何時候，遵循一些經過檢驗的原則，都是影響效率的重要因素，正確的方法是成功的秘訣。
提升工作和學習效率的另一個重要因素是釋惑和良好心態。第二部分分析了我在工作中碰到和看到的一些典型困惑。
成為優秀的架構師是大部分初中級工程師的階段性目標。第三部分剖析架構師的能力模型，讓大家對目標所需能力有一個比較清晰的認知。
如何學習
在繁忙的工作中，持之以恆、不斷學習和進步是一件艱巨的任務，需要堅強的毅力和堅定的決心。如果方法不得當，更是事倍功半。幸好我們的古人和現在哲人已經總結了很多優秀的學習方法論，這里匯總了一些重要原則。遵循這些方法必會對大家的工作學習大有裨益。
貴在堅持
有報道指出，過去幾十年的知識量超過之前人類幾千年的知識量總和。而計算機領域絕對是當代知識更新最快的領域之一，因此，工程師必須要接受這樣一個現實，現在所掌握的深厚知識體系很快就會被淘汰。要想在計算機領域持續做優秀架構師，就必須不停的學習，掌握最新技術。總之，學不可以已。
所謂「冰凍三尺，非一日之寒，水滴石穿，非一日之功」，通往架構師的道路漫長而又艱巨，輕易放棄，則所有付出瞬間付之東流。要想成為優秀的架構師，貴在堅持！
雖然知識更新很快，但是基礎理論的變化卻非常緩慢。這就是「道」和「象」關系，縱是世間萬象，道卻萬變不離其宗。對於那些非常基礎的理論知識，我們需要經常復習，也就是「學而時習之」。
重視實踐
古人雲：「紙上得來終覺淺，絕知此事要躬行。」 學習領域有所謂721模型：個人的成長70%來自於崗位實踐，20%來自向他人學習，10%來自於培訓。雖然這種理論存在爭議，但對於工程師們來說，按照實踐、學習和培訓的方式進行重要性排序，大致是不錯的。所以重視實踐，在實踐中成長是最重要的學習原則。
人類的認知有兩種：感性認知和理性認知。這兩種認知互相不可替代性。實踐很大程度來自於感性學習，看書更像是理性學習。以學開汽車做例子，很難想像什麼人能夠僅僅通過學習書本知識就會開汽車。
書本知識主要是傳道——講述抽象原型，而對其具體應用場景的講述往往含糊其辭，對抽象原型之間的關系也是淺嘗輒止。採用同樣精確的語言去描述應用場景和關聯關系將會失去重點，讓人摸不著頭腦。所以，僅僅通過看書來獲得成長就像是用一條腿走路。
重視實踐，充分運用感性認知潛能，在項目中磨煉自己，才是正確的學習之道。在實踐中，在某些關鍵動作上刻意練習，也會取得事半功倍的效果。
重視交流
牛頓說：「如果說我看得比別人遠一些，那是因為我站在巨人的肩膀上。」我們需要從別人身上學習。從老師、領導、同事、下屬甚至對手身上學習，是快速成長的重要手段。
向老師和領導學習已經是人們生活習慣的一部分了。但是從同事甚至對手那裡學習也很重要，因為這些人和我們自身更相似。所以要多多觀察，取其所長，棄其所短。對於團隊的小兄弟和下屬，也要「不恥下問」。
此外，在項目中積極參與具體方案討論也非常重要。參與者先驗感知了相關背景，並且討論的觀點和建議也是綜合了發言者多種知識和技能。所以，討論讓參與者能夠非常全面，立體地理解書本知識。同時，和高手討論，他們的觀點就會像修剪機剪樹枝一樣，快速的剪掉自己知識領域裡面的疑惑點。
重視總結和輸出
工程師在實踐中會掌握大量細節，但是，即使掌握了所有細節，卻沒有深刻的總結和思考，也會陷入到「學而不思則罔」的境地。成長的「量變」來自於對細節的逐漸深入地把控，而真正的「質變」來自於對「道」的更深層次的理解。
將經驗輸出，接受別人的檢驗是高層次的總結。這種輸出不僅幫助了別人，對自身更是大有裨益。總結的方式有很多，包括組織分享，撰寫技術文章等等。當然「日三省吾身」也是不錯的總結方式。總之，多多總結，多多分享，善莫大焉！
解答別人的問題也是個人成長的重要手段。有時候，某個問題自己本來不太懂，但是在給別人講解的時候卻豁然開朗。所以，「誨人不倦」利人惠己。
重視規劃
凡事預則立，不預則廢。對於漫長的學習生涯而言，好的計劃是成功的一半。
長期規劃
長期規劃的實施需要毅力和決心，但是做正確的長期規劃還需要高瞻遠矚的眼界、超級敏感的神經和中大獎的運氣。對於大部分人來說，長期規劃定主要是「定方向」。但遵循如下原則能夠減少犯方向性錯誤的概率：
遠離日暮西山的行業。
做自己感興趣的事情。
做有積累的事情。
一邊走一邊看，切勿一條道走到黑。
短期規劃
良好的短期規劃應該在生活、成長、績效和晉升之間取得平衡。大部分公司都會制定一個考核周期——少則一個月，多則一年。所以不妨以考核周期作為短期學習規劃周期。本質上，規劃是一個多目標優化問題，它有一系列的理論方案，這里不一一細說。基於相關理論，我給出一個簡單易行的方案：
確定目標優先順序。比如：成長、生活、績效。
確定每個目標的下限。從優化理論的角度來看，這被稱為約束。比如績效必須在一般以上，之前已經規劃好的旅行不能更改，必須讀完《Effective Java》等等。
優先為下限目標分配足夠的資源。比如，事先規劃好的旅行需要10天，這10天就必須預算出去。
按照各主目標的順序依次分配資源。比如，最終分配給學習的時間是10天。
在給定的學習預算下，制定學習目標，要激進。然後給出執行方案。比如，學習目標是掌握基本的統計學知識，並成為Java專家。具體方案為：完成《Effective Java》、《Java Performance》、《Design Pattern》、《Head First Statistics》四本書的閱讀。
對規劃中的各學習任務按目標優先順序進行排序，並最先啟動優先順序最高的任務。比如，最高優先順序是掌握統計理論，那麼就要先看《Head First Statistics》。
對於該方案，要注意以下幾點：
最低目標必須能夠輕松達成的目標，否則，從優化理論的角度來講，該命題無解。比如，類似「半年內完成晉級兩次、績效全部S、從菜鳥成為Java專家」就不太合適作為最低目標。總之，要區分理想和夢想。
主要目標規劃必須具備一定的挑戰性，需要規劃出不可能完成的目標。過度規劃本質上是一種貪婪演算法，目的是目標價值最大化。因為一切皆有變數，如果其他目標能夠提前完成，就不妨利用這些時間去完成更多的學習目標。總之，前途必須光明，道路必須坎坷。
各目標之間不一定共享資源，規劃不一定互有沖突。
此外，短期規劃還可以從如下幾個方面進行優化：
學習計劃最好能結合工作計劃，理論聯系實際結合，快速學以致用。比如，本季度規劃去做一些數據分析工作，那麼不妨把學習目標設置為學習統計知識。
要靈活對待規劃的目標和具體執行步驟，需要避免「鄭人買履」式的笑話。面臨新的挑戰和變化，規劃需要不斷地調整。
那些令人糾結的困惑
人生是一場馬拉松，在漫長的征途中，難免有很多困惑。困惑就像枷鎖，使我們步履蹣跚，困惑就像死鎖，讓我們停滯不前。
接下來我將總結自己在工作中碰到和看到的一些典型困惑。這些困惑或者長期困擾作者本人，或者困擾我身邊的同事和朋友。當這些困惑被釋然之後，大家都感覺如重獲釋，為下一階段的征程提供滿滿的正能量。人生就像一場旅途，不必在乎目的地，在乎的，應該是沿途的風景，以及看風景的心情。良好的心態是技術之旅最好的伴侶。期望通過這個解惑之旅，讓大家擁有一個愉快的心情去感受漫長的學習旅途。
學無止境嗎
必須要承認一個殘酷的現實：人的生命是有限的，知識卻是無限的。用有限的生命去學習無限的知識是不可能完成的任務。一想到此，有些工程師不免產生一些悲觀情緒。如果方法得當並且足夠勤奮，悲傷大可不必。
雖然，人類的整體知識體系一直在擴張。但是就很多重要的工程細分領域，基礎理論並不高深。計算機的很多重要領域，工程師有能力在有限時間內抓住核心要害。
比如，密碼學被認為是門非常高深的學科，但是一大類密碼技術的基礎是數論中一個非常簡單的理論——素因數分解：給出兩個素數，很容易算出它們的積，然而反過來給定兩個素數的積，分解的計算量卻非常驚人。
「一致性」算得上是計算機領域裡面最經典的難題，它是所有分布式系統的基礎，從多核多CPU到多線程，從跨機器到跨機房，無所不在，幾乎所有的計算機從業人員都在解決這個問題，但是Paxos給出了一個很優雅的解決方案。
許可權管理是很多工程師的噩夢，但如果你能搞定「Attribute Based Access Control(ABAC)」和「Role-Based Access Control(RBAC)」，也能達到相當高度。
另外，技術學習是一場對抗賽，雖然學無止境，超越大部分對手就是一種勝利。所以，以正確的學習方式，長時間投入就會形成核心競爭力。
沒有絕對高明的技術，只有真正的高手
致力於在技術上有所成就的工程師，都夢想有朝一日成為技術高手。但技術高手的標准卻存在很大的爭議。這是一個有著悠久歷史的誤解：以某種技術的掌握作為技術高手的評判標准。我經常碰到這樣一些情景：因為掌握了某些技術，比如Spring、Kafka、Elasticsearch等，一些工程師就自封為高手。有些工程師非常仰慕別的團隊，原因竟是那個團隊使用了某種技術。
這種誤解的產生有幾個原因：首先，技多不壓身，技術自然是掌握的越多越好，掌握很多技術的人自然不是菜鳥。其次，在互聯網時代來臨之前，信息獲取是非常昂貴的事情。這就導致一項技能的掌握可以給個人甚至整個公司帶來優勢地位。互聯網時代，各種框架的出現以及開源的普及快速淘汰或者降低了很多技能的價值，同時降低了很多技術的學習門檻。所以，在當前，掌握某項技能知識只能是一個短期目標。懷揣某些技能就沾沾自喜的人需要記住：驕傲使人退步。
所謂麻雀雖小，五臟俱全。如果讓你來做造物主，設計麻雀和設計大象的復雜度並沒有明顯區別。一個看起來很小的業務需求，為了達到極致，所需要的技術和能力是非常綜合和高深的。真正的高手不是拿著所掌握的技術去卡客戶需求，而是傾聽客戶的需求，給出精益求精的方案。完成客戶的需求是一場擂台賽，真正的高手，是會見招拆招的。
不做項目就無法成長嗎
在項目中學習是最快的成長方式之一，很多工程師非常享受這個過程。但是一年到頭都做項目，你可能是在一家外包公司。對於一個做產品的公司，如果年頭到年尾都在做項目，要不然就是在初步創業階段，要不然就是做了大量失敗的項目，總之不算是特別理想的狀態。正常情況，在項目之間都會有一些非項目時間。在這段時間，有些同學會產生迷茫，成長很慢。
項目真的是越多越好嗎？答案顯然是否定的。重復的項目不會給工程師們帶來新的成長。不停的做項目，從而缺乏學習新知識的時間，會導致「做而不學則殆」。真正讓工程師出類拔萃的是項目的深度，而不是不停地做項目。所以，在項目之間的空檔期，工程師們應該珍惜難得的喘息之機，深入思考，把項目做深，做精。
如何提高項目的深度呢？一般而言，任何項目都有一個目標，當項目完成後，目標就算基本達成了。但是，客戶真的滿意了嗎？系統的可用性、可靠性、可擴展性、可維護性已經做到極致了嗎？這幾個問題的答案永遠是否定的。所以，任何一個有價值的項目，都可以一直深挖。深挖項目，深度思考還可以鍛煉工程師的創造力。期望不停地做項目的人，就像一個致力於訓練更多千里馬的人是發明不出汽車的。鍛煉創造力也不是一蹴而就的事情，需要長時間地思考。總之，工程師們應該總是覺得時間不夠用，畢竟時間是最寶貴的資源。
職責真的很小嗎
很多時候，一個工程師所負責系統的數量和團隊規模與其「江湖地位」正相關。但是，江湖地位與技術成長沒有必然關聯。提升技術能力的關鍵是項目深度以及客戶的挑剔程度。項目越多，在單個項目中投入的時間就越少，容易陷入膚淺。特別需要避免的是「 在其位不謀其政」的情況。團隊越大，在管理方面需要投入的精力就越多。在管理技巧不成熟，技術眼界不夠高的前提強行負責大團隊，可能會導致個人疲於應付，團隊毫無建樹。最終「 一將無能，累死三軍」，效果可能適得其反。
從技術發展的角度來說，技術管理者應該關注自己所能把控的活躍項目的數量，並致力於提高活躍項目的影響力和技術深度。團隊人數要與個人管理能力、規劃能力和需求把控能力相適應。一份工作讓多個人來干，每個人的成長都受限。每個人都做簡單重復的工作，對技術成長沒有任何好處。團隊管理和項目管理需要循序漸進，忌「拔苗助長」。
一定要當老大嗎
有一些工程師的人生理想是做團隊里的技術老大，這當然是一個值得稱贊的理想。可是，如果整個團隊技術能力一般，發展潛力一般，而你是技術最強者，這與其說是幸運，不如說是悲哀。這種場景被稱之為「武大郎開店」。 團隊里的技術頂尖高手不是不能做，但為了能夠持續成長，需要滿足如下幾個條件：
首先你得是行業裡面的頂尖專家了——實在很難找到比你更強的人了！
其次，你經常需要承擔對你自己的能力有挑戰的任務，但同時你擁有一批聰明能乾的隊友。雖然你的技術能力最高，但是在你不熟悉的領域，你的隊友能夠進行探索並擴展整個團隊的知識。
最後，你必須要敏而好學，不恥下問。
否則，加入更強的技術團隊或許是更好的選擇，最少不是什麼值得驕傲的事情。
平台化的傳說
平台化算得上是「高大上」的代名詞了，很多工程師擠破頭就為了和「平台化」沾點邊。然而和其他業務需求相比，平台化需求並沒有本質上的區別。無論是平台化需求還是普通業務需求，它的價值都來自於客戶價值。不同點如下：
很多平台化需求的客戶來自於技術團隊，普通需求的客戶來自於業務方。
產品經理不同。普通業務需求來自於產品經理，平台化需求的產品經理可能就是工程師自己。長期被產品經理「壓迫」的工程師們，在平台化上終於找到「翻身農奴把歌唱」的感覺。
很多平台化的關注點是接入能力和可擴展性，而普通業務的關注點更多。
歸根結底，平台化就是一種普通需求。在實施平台化之前，一定要避免下面兩個誤區：
平台化絕對不是諸如「統一」、「全面」之類形容詞的堆砌。是否需要平台化，應該綜合考慮：客戶數量，為客戶解決的問題，以及客戶價值是否值得平台化的投入。
平台化不是你做平台，讓客戶來服務你。一些平台化設計者的規劃設計裡面，把大量的平台接入工作、臟活累活交給了客戶，然後自己專注於所謂「最高大上」的功能。恰恰相反，平台化應該是客戶什麼都不做，所有的臟活累活都由平台方來做。本質上講，平台化的價值來自於技術深度。真正體現技術深度的恰恰是設計者能夠很輕松的把所有的臟活累活搞定。
所以平台化的最佳實踐是：投入最少的資源，解決最多的問題。平台解決一切，客戶坐享其成。
搞基礎技術就一定很牛嗎
經常聽到同學們表達對基礎技術部同學的敬仰之情，而對搞業務技術的同學表現出很輕視，認為存儲、消息隊列、服務治理框架（比如美團點評內部使用的OCTO）、Hadoop等才能被稱為真正的技術。事實並非如此，更基礎的並不一定更高深。
比如下面這個流傳很久的段子：越高級的語言就越沒有技術含量。但真是這樣嗎，就拿Java和C來說，這是完全不同的兩種語言，所需要的技能完全不同。C或許跟操作系統更加接近一點，和CPU、內存打交道的機會更多一點。但是為了用好Java，程序員在面向對象、設計模式、框架技術方面必須要非常精通。Java工程師轉到C方向確實不容易，但作者也見過很多轉到Java語言的C工程師水土不服。
基礎技術和業務應用技術必然會有不同的關注點，沒有高低之分。之所以產生這種誤解，有兩個原因：
基礎技術相對成熟，有比較完整的體系，這給人一個高大上的感覺。業務應用技術相對來說，由於每個團隊使用的不一樣，所以成熟度參差不齊，影響力沒有那麼大。
基礎技術的門檻相對來說高一點，考慮到影響面，對可靠性、可用性等有比較高的最低要求。但是門檻高不代表技術含量高，另外成熟技術相對來說在創新方面會受到很大的約束。但是最先進的技術都來自活躍的創新。
對比下來，業務技術和基礎技術各有千秋。但真正的高手關注的是解決問題，所有的技術都是技能而已。
可行性調研的那些坑
工作中開展可行性調研時有發生。做可行性調研要避免如下情況：
把可行性調研做成不可行性調研。這真的非常糟糕。不可行性的結論往往是：因為這樣或者那樣的原因，所以不可行。
避免「老鼠給貓掛鈴鐺」式的高風險可行性方案。「天下大事必作於細」，可行性調研一定要細致入微，避免粗枝大葉。
避免調研時間過長。如果發現調研進展進入到指數級復雜度，也就是每前進一步需要之前兩倍的時間投入，就應該果斷的停止調研。
可行性調研的結論應該是收益與成本的折衷，格式一般如下：
首先明確預期的結果，並按照高中低收益進行分級。
闡述達成每種預期結果需要採取的措施和方案。
給出實施各方案需要付出的成本。
工程師天生不善溝通嗎
實際工作中，溝通所導致的問題層出不窮。工程師有不少是比較內向的，總是被貼上「不善溝通」的標簽。實際上，溝通能力是工程師最重要的能力之一，良好的溝通是高效工作學習的基礎，也是通過學習可以掌握的。下面我按工程師的語言說說溝通方面的經驗。
第一類常見的問題是溝通的可靠性。從可靠性的角度來講，溝通分為TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式當然比較可靠，不過成本比較高，UDP模式成本低，但是不可靠。在溝通可靠性方面，常見錯誤有如下兩種：
經常聽到的這樣的爭論。一方說：「我已經告訴他了」，另一方說：「我不知道這個事情呀」。把UDP模式被當作TCP模式來使用容易產生扯皮。
過度溝通。有些同學對溝通的可靠性產生了過度焦慮，不斷的重復討論已有結論問題。把TCP模式當成UDP來使用，效率會比較低。
第二類溝通問題是時效性問題。從時效性講，溝通分為：同步模式和非同步模式。同步溝通形象地說就是：你現在給我聽好了。非同步溝通的形象表述是：記得給我做好了。在溝通時效性方面，有如下兩種常見錯誤：
已經出現線上事故，緊急萬分。大家你一言，我一語，感覺事故可能和某幾個人有關，但是也不能完全確定，所以沒有通知相關人員。最終，一個普通的事故變成了嚴重事故。對於緊急的事情，必須要同步溝通。
半夜三點你正在熟睡，或者周末正在逛街，接到一個電話：「現在有個需求，能否立刻幫忙做完。」這會非常令人郁悶，因為那並不是緊急的事情。不是所有的需求都需要立刻解決。
有效溝通的一個重要原則是提前溝通。溝通本質是信息交流和處理，可以把被溝通對象形象地比喻成串列信息處理的CPU。提前溝通，意味著將處理請求盡早放入處理隊列裡面。下面的例子讓很多工程師深惡痛絕：一個需求策劃了1個月，產品設計了2周。當開發工程是第一次聽說該需求的時候，發現開發的時間是2天。工程師據理力爭，加班加點1周搞定。最後的結論是工程師非常不給力，不配合。就像工程師討厭類似需求一樣。要協調一個大項目，希望獲得別人的配合，也需要盡早溝通。
有效溝通的另外一個重點是「不要跑題」。很多看起來很接近的問題，本質上是完全不同的問題。比如：一個會議的主題是「如何實施一個方案」，有人卻可能提出「是否應該實施該方案」。 「如何實施」和「是否應該實施」是完全不同的兩個問題，很多看起來相關的問題實際上跑題很遠。「跑題」是導致無效溝通的重要原因。
良好溝通的奧秘在於能掌握TCP模式和UDP模式精髓，正確判斷問題的緊急性，盡量提前溝通，避免跑題。
帶人之道
有些初為導師的工程師由於擔心畢業生的能力太弱，安排任務時候諄諄教誨，最後感覺還是有所顧慮，乾脆自己寫代碼。同樣的事情發生在很多剛剛管理小團隊的工程師身上。最終的結果他們：寫完所有的代碼，讓下屬無代碼可寫。「 事必躬親」當然非常糟糕，最終的往往是團隊的整體績效不高，團隊成員的成長很慢，而自己卻很累。
古人說：「用人不疑，疑人不用。」這句話並非「放之四海而皆準」。在古代，受限於通信技術，反饋延遲顯著，而且信息在傳遞過程中有大量噪音，變形嚴重。在這種情況下，如果根據短期內收集的少量變形的信息做快速決斷，容易陷於草率。在公司里，這句話用於選人環節更為恰當，應該改為：錄用不疑，疑人不錄。
考慮到招聘成本，就算是在錄用層面，有時候也無法做到。作為一個小團隊的管理者，能夠快速准確的獲取團隊成員的各種反饋信息，完全不需要「用人不疑，疑人不用」。用人的真正理論基礎來自於「探索和利用」(Exploration and Exploitation )。不能因為下屬能做什麼就只讓他做什麼，更不能因為下屬一次失敗就不給機會。
根據經典的「探索和利用」(Exploration and Exploitation )理論，良好的用人方式應該如下：
首選選擇相信，在面臨失敗後，收縮信任度。
查找失敗的原因，提供改進意見，提升下屬的能力。
總是給下屬機會，在恰當地時機給下屬更高的挑戰。 總之，蒼天大樹來自一顆小種子，要相信成長的力量。
效率、效率、效率
經常看到有些同學給自己的績效評分是100分——滿分，原因是在過去一段時間太辛苦了，但最終的績效卻一般般。天道酬勤不錯，但是天道更酬巧。工程師們都學過數據結構，不同演算法的時間復雜度的差距，僅僅通過更長的工作時間是難以彌補的。為了提升工作學習效率，我們需要注意以下幾點：
主要關注效率提升。很多時候，與效率提升所帶來的收益相比，延長時間所帶來的成果往往不值得一提。
要有清晰的結果導向思維。功勞和苦勞不是一回事。
做正確的事情，而不僅僅正確地做事情。這是一個被不斷提起的話題，但是錯誤每天都上演。為了在規定的時間內完成一個大項目，總是要有所取捨。如果沒有重點，均勻發力，容易事倍功半。如果「南轅北轍」，更是可悲可嘆。
架構師能力模型
前面我們已經講完了原則和一些困惑，那麼工程師到底應該怎麼提升自己呢？
成為優秀的架構師是大部分初中級工程師的階段性目標。優秀的架構師往往具備七種核心能力：編程能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、在線運維能力、項目管理能力和規劃能力。
這幾種能力之間的關系大概如下圖。編程能力、調試能力和編譯部署能力屬於最基礎的能力。不能精通掌握這三種能力，很難在性能優化能力和業務架構能力方面有所成就。具備了一定的性能優化能力和業務架構能力之後，才能在線運維能力和項目管理能力方面表現優越。團隊管理能力是最高能力，它對項目管理能力的依賴度更大。
⑵ 製造業如何搭建數據運營體系
比如永洪幫我們搭建了迪聯商用數據雲的建設，隨著技術的發展，我們IT人員就是要運用行業的先進經驗和先進技術手段，幫助公司內部構建技術平台，比如說永洪就是個很好的數據平台，他們把我們內部的情況作了全面了解之後，幫助我們構建了數據模型、數據平台。永洪幫助我們從業務場景角度做了規劃，大致分為三個階段：產品數據、企業經營管理數據、生態數據。
⑶ 淺析企業如何建立技術知識管理體系
建立技術知識管理體系 俗話說，條條道路通羅馬，企業進行技術知識管理也是一樣的道理，企業可以通過不同的方式進行技術知識管理，但終究哪種方式最為經濟，又能達到實際效果，企業還得根據自身狀況，參考其他企業的經驗來進行體系規劃和流程選擇，以便建立有效的技術知識管理體系。 1 規劃企業技術知識管理體系 企業必須結合發展戰略及企業管理模式進行技術知識管理體系（以下簡稱體系）規劃，規劃包括建立合理的組織機構和分工明確的責任機制，鎖定體系管理的核心業務流程和核心技術，選擇構建體系的管理流程及各流程的實現途徑。 2 建立技術知識管理機制 同大多數企業一樣，筆者所闡述的管理結構也採用最高管理者居於上端，中間管理層居於中間，為數眾多的技術人才居於底層的「金字塔」型。這種管理結構的特點在於管理職能從宏觀到微觀，更有助於體系的基礎建設。無論是承擔宏觀控制職能的最高管理者，還是承擔中層指導職能的中層知識管理者，以及承擔微觀操作職能的知識工程師，這些角色構成了企業知識管理的中間力量，也是企業實施知識管理成敗的關鍵，他們的職能必須明確。 3 選擇技術知識管理流程 3.1 技術知識定義 鑒於不同部門、不同流程、不同員工對同一技術知識的認識會存在很大差異，所以需要對技術知識加以明確的定義。 根據核心業務流程選定技術知識項目，項目選定可從以下來源著手：①企業業務流程；②企業各部門職能規劃；③各崗位職責；④企業員工能力素質水平；⑤企業內部產品組合；⑥企業外部客戶資源。 在此基礎上，對每個項目進行細化，對這些技術知識項目進行統一定義。在此，採用列舉的方式進行定義，比如，「裝配知識」可以定義為：按規定的技術要求將零件或部件組配和連接成半成品或成品的相關知識。包括：①裝配要求；②裝配工藝流程；③裝配成本控制；④裝配質量控制；⑤工藝設備管理。