財務應該及早進入產品開發流程，貫穿到企業愿景，使命，產品規劃，產品開發及產品生命周期管理全過程

 

IPD成本控制主要針對兩個目標：

1、  降低開發成本

2、  降低產品本身的結構成本

 

研發人員常犯的成本錯誤：

1、  只關注物料成本，不關注設計成本和維護成本，出現物料成本雖然降低，但是帶來的設計難度、設計成本增加

2、  不采購外來成熟組件，自行開發，導致產品不穩定帶來的維護成本增加

3、  對公司內部成本高的優選器件不采用，忽略量產后帶來的采購成本下降

 

控制綜合成本的手段：

1、  通過需求與規劃，區分基本需求、競爭需求、可有可無的需求，避免過度開發

2、  通過產品化共享，減少低水平重復開發

3、  通過技術分類，識別核心技術、關鍵技術、通用技術和一般技術，核心技術和關鍵技術自主開發，通用技術和一般技術外包，以降低開發成本

4、  在設計中控制成本：確定目標成本，設計中采用多方案選擇，減少新模塊，控制質量成本，加強可靠性設計，由高手負責設計

5、  在開發與制造中進行成本過程控制：保證資源

 

產品經理必須掌握的財務成本知識：

1、  了解財務基本專業知識，定期看部門財務報表，分析部門的內部核算表

2、  理解核算原則，學會用比例定崗

3、  了解公司和部門的固定成本變動，學會控制成本

4、  知識計算部門內部的盈虧平衡點

5、  知道怎么做預算，并親自做預算和審核下級預算及費用

6、  關注項目回款，明白影響現金流的原因

7、  熟悉公司財務制度，并提出改進措施，使其簡潔有效

新產品開發的前三單客戶也是產品開發的一部分，必須由公司高級別的人員完成，而不是一味地交給客戶經理去銷售

 

產品命名及商標管理：

1、  產品命令應將技術語言轉換為了市場語言

2、  命名突出賣點

3、  命名保持統一品牌形象

4、  命名不要使用方言，俚語

 

產品宴會的FFAB策略：

Feature：技術賣點

Function：功能賣點

Advantage：產品的優點

Benefits：對客戶的好處

1、  如果客戶熟悉技術，突出介紹Function、Feature；不熟悉技術，突出介紹Advantage、Benefits

2、  客戶經理（銷售）應該掌握，Benefits、Advantage、Function

3、  市場經理應該掌握，Benefits、Advantage、Function、Feature

4、  技術經理應熟悉技術實現路徑

5、  嚴格區別Advantage、Benefits

 

產品定價：

1、  要利潤，定高價

2、  要規模，定低價

3、  阻攔對手，定更低價

4、  把價格隱藏在服務中

 

產品定價步驟：

1、  明確競爭對手產品

2、  分析競爭對手產品定價

3、  進行比較定價分析$APPEALS

4、  對產品進行成本分析，根據配置不同進行成本分析

5、  根據戰略價值及KPI定價

6、  細化并驗證定價策略

 

按價格承受力把客戶分類：

1、  戰略客戶：樣板用戶，帶動其他客戶消費

2、  利潤客戶：接受的價格給公司帶來的利潤大于機會利潤

3、  非利潤客戶：接受的價格給公司帶來的利潤小于機會利潤

4、  大客戶：訂單較多

5、  價值客戶：戰略+利潤+大客戶

 

定價避免以下情況：

1、  避免大客戶是非利潤客戶

2、  避免非利潤的戰略客戶太多

3、  避免將戰略客戶等同于價值客戶

 

客戶滿意度聚焦利潤客戶，價值客戶的滿意度必須達到100%，非戰略非利潤客戶的滿意度不要超過50%

 

新產品推廣：

一個資料庫六個子庫：案例庫，問題庫，產品資料庫，市場資料庫，需求庫，競爭對手資料庫

銷售工具包：內部銷售工具包，給客戶資料包

五種手段：公司展廳，展覽會，樣板點，研討交流會，廣告/網站/軟性文章

 

公司高層，產品經理，市場經理，客戶經理都要進行客戶關系的維護和開拓

產品經理和系統級工程師更要對技術型的客戶進行維護和開拓

 

產品銷售工具：產品一紙禪、售前膠片、案例分析、銷售指導書

通過規范的資料培訓銷售人員，營造產品大量進入市場的條件

常見的質量管理問題原因：

1、  QA沒有在設計時介入

2、  QA工作不獨立，影響測試結果

3、  做評審沒有評審要素，評審人沒有績效考核，走過場

4、  新手做設計，高手救火

5、  未建立公共模塊共享開發的研發模式

6、  引入不成熟的技術

7、  在設計時，未進行多方案預備

 

構建質量體系六個要素：

1、  一套流程：將質量管理體系融入研發流程

2、  兩個原則：業務決策評審與技術質量評審分離、建立產品貨架

3、  三個職位：系統級工程師，主審人，PQA

4、  四個分離：規劃與系統設計分離，設計與實現分離，實現與測試分離，測試與驗證分離

5、  五種手段：規劃與CBB共享、評審、測試和驗證、任職資格與活動匹配、缺陷歸零管理

6、  六個評審點

 

技術評審：關注技術評估

決策評審：關注財務、資源投入、計劃

技術分類：核心技術，關鍵技術，一般技術，通用技術

 

核心技術：需要進行發展規劃，進行立體開發，知識產權保護

技術外包進行嚴格評審，避免核心技術，關鍵技術外包

核心技術，關鍵技術：縱向發展人員

一般技術，通用技術：橫向發展人員，可以外包

 

核心技術特點：獨有性，競爭性，可攔截性，不可替代性，可管理可保護，產生價值

 

技術并不是越多越好，而是核心技術和關鍵技術越多越好

 

技術開發五個階段：立項，開發，驗證，發布，成果貨架化管理

 

對技術管理考核：結果要寬松，過程要嚴格

 

共用基礎模塊CBB：在不同產品、系統之間共用的零部件，模塊，技術，設計成果

貨架：將不同層次的產品統一管理

貨架產品：成熟度達到一定程度的CBB

平臺：一系列貨架產品在層級上的集合

 

平臺形成的兩條路：

1、  根據需求形成平臺規劃：平臺很難規劃

2、  總結與沉淀：做3個定制項目進行一次CBB分析

 

技術預研和平臺開發人員級別要高，需要高手開發

預研團隊和技術開發，產品開發團隊應該合理流動，以實現技術成果的產品化

 

鼓勵和激勵平臺開發措施：

1、  通過任職資格牽引

2、  平臺進行內部定價

3、  可以對非競爭的客戶進行外部銷售

4、  對平臺開發給予戰略補貼和特別激勵

項目分級：

A級項目：公司級重點關注和管理項目

B級項目：產品線重點關注和管理的項目

C級項目：產品經理或項目經理自己管理的項目

 

項目排序要素：市場吸引力、競爭地位、財務評估

 

單項目主體：項目經理

多項目主體：項目管理部

 

項目開發四個階段：階段，步驟，任務，活動

三個計劃：

1、  一級計劃：解決全流程、全要素協同

2、  二級計劃：全流程協同下的各部門協同

3、  三級計劃：指導更小模塊或個人具體執行任務計劃

 

提高計劃準備度和完成率三要素：需求管理，關鍵資源及時到位，項目經理的能力

 

計劃制訂需要分階段，分級進行，避免追求一次成型

研發工作四類流程：

 

1、  技術開發流程：預研、應用技術開發V版本

2、  平臺開發流程：共享模塊開發V版本

3、  產品開發流程：每向細分市場R版本

4、  定制項目開發流程：在產品和平臺基礎上針對某一客戶的定制M版本

 

產品開發活動四個步驟：階段，步驟，任務，活動

 

概念階段：驗證市場需求，確立產品是否可以立項

計劃階段：確立總體方案，資源投入，確保工藝、結構方案、設計方案同步，避免重復開發

發布階段：尋找樣板客戶，準備商標、命令、市場指導書、產品實驗局、初步定價策略；銷售工具包、售前膠片、銷售指導書、產品的配置、商業械設計、產品的成功安全分析，銷售培訓，發布計劃

 

產品開發流程六個階段：概念、計劃、產品開發、驗證、生命周期管理

四個決策評審點：概念決策、計劃決策、發布決策、生命周期決策

六個技術評審點：產品包需求評審、系統規格評審、概要設計評審、詳細設計評審、樣機評審、小批量評審

 

財務角色：

概念階段：產品的定價分析和成本分析

計劃階段：核算綜合成本

開發階段：監控成本

發布階段：明確價格策略

生命周期階段：進行價格的核準和調整價格

 

生產、維護、服務人員：在方案設計階段參與進來，提出可維護、可安裝、可測試、可生產需求，使方案設計一步到位。

 

采購角色：

概念階段：參與供應商認證

計劃階段：完成元器件認證，明確提前采購的風險

產品生命周期階段：關注器件的產能情況，提前預警

 

企業執行產品開發流程失敗原因分析：

1、  為流程而流程，只有研發參與

2、  沒有建立市場管理流程，沒有好的市場經理，產品開發沒有良好的輸入，推行產品開發流程困難

3、  沒有培養起來系統級工程師或團隊進行總體方案設計，沒有打通設計時的所有環節，流程流于形式

4、  評審過于關注技術，在市場和財務成功方面考慮較少

5、  過多關注流程執行的完整性，沒有結合自身情況，分步推進

6、  配套支撐流程和體系建設跟不上，如項目管理流程、績效管理流程、任職資格體系建設，落地的支撐人員配套跟不上

7、  沒有固化或形成時，過早進行IT化，僵化了流程

研發與銷售矛盾重重：需要建立市場體系，銷售與市場分離

市場體系：分析客戶需求，進行產品規劃，培訓渠道及客戶經理，立足核心產品設計

 

市場體系：讓產品好賣，營

銷售體系：將產品賣好，銷

 

需求管理四個步驟：需求收集，需求分析與分類，需求分發，需求實現及驗證

需求管理體系目的：讓每個人在日常活動中，將需求進行收集并通過分析和分發，以確保非金屬人員面向市場進行開發

需求管理體系原則：落后了，找對手；平行了，建市場；領先了，做標準。

要建立好的市場體系，必須建立鼓勵研發人員進入營銷體系的機制。

為了保證快速地反映市場，規劃必須每三個月更新一次。

 

需求分類：

A類：新產品開發需求

B類：產品設計規格更改需求

C類：詳細設計路徑更改需求

D類：生產訂單需求

E類：CBB和平臺開發需求

F類：技術開發需求

G類：市場調研，需要繼續求證

 

進入一個客戶群三要素：

1、  市場吸引力：市場規模，市場成長性，戰略價值

2、  競爭地位：是否有能力進入，市場份額、產品優勢、成本優勢、渠道能力

3、  財務回報：收入增長率，現金流貢獻、研發投入產出比

 

確定新產品的需求的方法：

1、  重新進行新產品開發

2、  對老產品進行改進

 

外部需求：客戶的要求、功能需求、規格需求、可靠性需求

內部需求：產品化需求（可生產、可安裝、可維護、可測試、可驗證），技術需求

 

需求完成包括四類人員：客戶經理、市場經理、產品經理、技術經理

需求產出的四份文檔：

1、  客戶需求規格說明書

2、  產品包需求說明書

3、  需求的分解分配

4、  技術規格說明書

 

將產品規格轉變為技術需求：FFAB

Benefits：對客戶的好處

Advantage：產品的優點

Function：功能模塊的賣點

Feature：實現功能模塊的技術特性

 

業界常用的$APPEALS模型：$價格、A可獲得性、P包裝、P功能性能、E易用、A保證、L生命周期成本、S社會接受程度

 

 

 

 

企業戰略規劃制定：一個從公司愿景，到經營計劃，到各產品線的愿景，及業務計劃，再到產品平臺以及核心技術需求，并落實到資源規劃以及各種激勵機制的配套保證的總體流程

 

戰略規劃分三個層次：

1、  頂層設計，戰略研究層

2、  業務層，產品線戰略規劃層

3、  支撐層，資源配置管理改進層

 

產品戰略的W型八個步驟

 

技術型企業組織績效指標：

1、  生存類能力指標：財務指標，交付指標，

2、  可持續發展能力指標：新業務占收入的比重，核心技術和平臺帶來的收入占比

3、  核心競爭能力指標：公共模塊共享率，人員結構合理性及任職資料提升率，引導客戶需求與規劃能力

 

產品線的核心考核指標是組織績效：對市場成功和財務成功負責

個人績效：只能產品線有利潤，組織績效成功，才有意義

 

企業增加利潤的路徑：

1、  進入新市場

2、  開發新業務

3、  改變商業模式

4、  降低成本：研發的首要目的是提高老產品的利潤，其次是開發新產品，新技術

5、  提高價格

 

企業新業務分類：

1、  聚焦發展，70%

2、  必須突破的業務，20%

3、  布局式業務，10%

 

筆記原書：

 

 

研發的六種產出模式：

1、  基礎研究，發明和標準

2、  應用開發，將非成熟的應用技術變成成熟的技術

3、  項目開發，一次性的定制

4、  產品開發，內部共享模塊與產品，外部銷售的產品，可批量，可重復，可復制生產

5、  解決方案，以產品為核心，為客戶做的跨產品或跨領域集成方案

6、  服務和運營，服務、運營、維護獲取收益

 

產品開發貨架層次：器件、組件、部件、單機、整機、子系統、系統

產品分類：

1、  內部共享產品：器件、組件、部件

2、  面向細分客戶群的產品：部件、單機、整機、子系統（能力強的公司）

3、  解決方案級產品：子系統、系統

 

技術型企業的商業模式：經營技術、經營產品、經營解決方案、經營客戶和服務

 

技術型企業的商業模式發展和演變五個階段：

1、  勞動密集型加工

2、  項目生存型

3、  產品擴展型

4、  運營客戶型

5、  集成產業鏈型

 

產品開發方式：

1、  先開發技術，然后做通用產品，再銷售

技術開發->產品開發->形成產品->銷售渠道->通用客戶需求

缺點：容易被細分市場產品替代，技術一旦落后沒有后續產出

2、  客戶需求，尋找技術，完成定制

客戶需求->營銷渠道->確定交付->投入開發->技術突破

缺點：技術開發有風險；一個個項目做，企業很難做大；質量不易保證；人員沒有專業發展通道，容易流失；項目越多，管理越難

 

集成產品開發：

1、  產品開發與技術開發、平臺開發分離；

2、  技術和平臺開發先行，解決技術突破；

3、  產品開發按細分客戶群需求

 

集成產品開發和技術開發特點：

1、  產品開發：強調基于市場需求和共享平臺，對市場和財務的成功負責

2、  技術開發：自己掌握業界成熟的技術，做成貨架，供產品開發時共享，以縮短產品開發周期

 

集成產品開發三種產品形態：

1、  產品大版本V：平臺版本

2、  細分客戶群版本R：交付給用客戶產品，四要素：客戶及競爭需求、功能與技術需求、時間、成本

3、  客戶定制版本M：在R版本的基礎上針對具體客戶的個性化版本

 

產品開發四個范疇：技術開發、市場開發、生產和服務開發、資料包開發

產品開發的步驟：

1、  先進行市場開發，細分客戶群，尋找賣點和商業模式，尋找市場和財務成功的要素；

2、  根據產品需求進行分解與分配，進行技術開發

3、  根據技術要求進行產品的可生產性，可安裝性，可測試性，可驗證性，可服務性開發

4、  根據產品大量進入市場，進行技術資料包，服務資料包和銷售工具的開發

 

企業研發管理發展的五個階段：

1、  單項目單產品階段：以項目為核心

2、  多產品、共享產品和貨架平臺階段：以產品為核心

3、  以共享為核心面向客戶需求階段：以客戶為核心

4、  以產業鏈為核心的關注利潤階段：以利潤為核心

5、  持續改進階段

 

集成產品開發管理思想：

1、  產品開發是一項投資

2、  必須強調基于市場的創新

3、  執行技術開發與產品開發分離

4、  對技術進行分類管理，強調核心技術，關鍵技術的自主開發

5、  跨部分的協同開發，實現全流程全要素（市場、研發、生產、采購、財務協同）的管理

6、  強調CBB和平臺建設，強調技術共享

7、  執行異步開發

8、  根據產品的不同層次和技術開發執行不同的結構化開發流程

9、  強調市場和財務成功、核心競爭力的提升是研發績效考核的重要因素

 

要實現IPD要以產品線（產品）為核心進行四大重組：財務重組、市場重組、產品重組、組織與流程重組

筆記原書：

 

2011年我開始接觸一些IPD的培訓課程，今年10.1長假期間我又參加了兩次有關IPD的外訓課程，對IPD有了一些大概的了解，10.1過后我買了一些有關IPD的書籍開始閱讀，了解了更多的IPD的知識后使我感到十分震驚，原來產品的開發是應該這樣搞的，困惑了很久的一些產品管理問題一下子找到了答案（雖然還不是全部）。

在中國涉及到產品開發的公司有很多，各行各業的都有，做的好做的一般都存在，從我的工作經歷看，先在小型軟件公司工作，后到中小型軟件公司工作，之后又在一家世界有名的超大公司做軟件開發，大中小型的公司我都干過了，但依然找不到軟件開發在管理方面的門徑。傳統管理，營銷管理，人力資源管理都很少涉及產品開發管理，這說明這是一門很“偏”學問。產品管理既涉及到開發人員的管理，又涉及到技術管理，還有流程建立行者等等，在我的工作經歷中經常遇到最多的問題包含：

1、中小公司無法吸引開發高手，長期發展甚至會感覺整個小行業人才凋零，沒有前景
2、開發過程混亂，開發團隊的工作效率主要取決于leader的個人水平及工作積極性
3、質量管理較差，需求來源模糊，設計稀里糊涂，到了測試階段基本上已經無法控制、測試人員對項目影響力較小
4、文檔管理幾乎空白，屬于自覺自發的行為結果
5、人員培養困難
6、新手做設計，高手救火
。。。很多很多

這些問題，或大或小，或輕或重，在我閱讀完從華為走出來做IPD咨詢這些高手寫的書之后，慢慢找到了答案。

IPD集成產品開發管理思想強調：

1、  產品開發是一項投資

2、  必須強調基于市場的創新

3、  執行技術開發與產品開發分離

4、  對技術進行分類管理，強調核心技術，關鍵技術的自主開發

5、  跨部分的協同開發，實現全流程全要素（市場、研發、生產、采購、財務協同）的管理

6、  強調CBB和平臺建設，強調技術共享

7、  執行異步開發

8、  根據產品的不同層次和技術開發執行不同的結構化開發流程

9、  強調市場和財務成功、核心競爭力的提升是研發績效考核的重要因素

除了IPD的流程之外，華為人結合了華為實踐IPD過程的經驗與教訓，及一些成功的管理實踐，做了完整的總結與升華，閱讀之后感覺茅塞頓開。
介紹兩本書：

 

總結網上訂票系統常見的問題如下：

 

1、 高峰時段無法登陸，提示在線用戶過多

2、 訂單提交成功之后，支付環節出了問題，瀏覽器意外退出，后再登陸，發現登陸不上，無法在規定時間內完成支付，購票失敗

3、 訂單提交反饋時間過長，熱門線路需要等待20分鐘甚至更長時間，才能得到反饋

4、 驗證碼輸入總是錯誤，無法完成驗證碼驗證環節，無法登陸

5、 逢用戶高峰，網站反應速度較慢

6、 對多瀏覽器支持不好，沒有IOS，Android應用入口

 

以上問題多數都是用戶體驗的問題，用戶體驗的問題即有票源稀少的原因，更多的是對訂票系統使用過程中系統登陸困難，反應遲鈍，訂單結果反饋太慢，意外退出等問題難以忍受。

 

本人并非訂票系統設計人員，但是通用對訂票系統外在的表現大膽猜測一下訂票系統的設計。

 

常見問題原因分析：

 

問題1，高峰時段無法登陸，提示在線用戶過多；

問題4，驗證碼輸入總是錯誤，無法完成驗證碼驗證環節，無法登陸

 

無法登陸的問題，其原因顯然是前端用于處理WEB連接服務器太少或網絡帶寬不足所至，為了不讓更多的用戶一起連接服務器導致服務器較慢，只好拒絕一些用戶的登陸請求。使同時在線人數保持在一個上限以內。

驗證碼輸入總是錯誤的問題，原因也是用于處理WEB連接服務器太少所至，為了防止一些客戶端使用“惡意”軟件，不斷自動登陸的情況，驗證碼需求由客戶端向服務器提交一個驗證請求，可以由于服務器響應實在太慢，以至于整個響應速度居然超過了驗證碼的有效時間。

 

常見問題：

問題2：訂單提交成功之后，支付環節出了問題，瀏覽器意外退出，后再登陸，發現登陸不上，無法在規定時間內完成支付，購票失敗

問題3：訂單提交反饋時間過長，熱門線路需要等待20分鐘甚至更長時間，才能得到反饋

問題5：逢用戶高峰，網站反應速度較慢

 

問題2是一個系統的BUG，但是可以通過一些設計來解決這個問題。

 

問題3，問題5，可能是由于WEB服務器與邏輯處理服務器在同一臺機器上，而導致服務器CPU分配了過多的時間與資源在處理用戶請求，在執行邏輯時執行緩慢。

 

如果數據庫也在同一臺服務器上，那問題可能更加嚴重。當然我相信，不在一臺服務器上的可能性比較大。

 

總結以上問題，其解決方案建議如下：

 

1、 準備更多前端WEB服務器，解決WEB前端的問題沒有別的辦法，只能加服務器，或者每個省市放一群單獨的服務器，根據用戶量進行增加，直到響應流暢為止。

2、 可以考慮把邏輯服務器單獨分離出來，與WEB服務器分開，WEB服務器只處理WEB請求，邏輯服務器單獨運行

3、 把數據庫服務器單獨分離，并且把火車票票量數據庫與用戶訂票信息數據庫放到不同的機器上，由于大量的訂票請求會訪問火車票票量數據庫，并且會有大量訂票數據添加到用戶訂票信息數據庫中，在處理添加的邏輯占用了大量的數據庫資源，會導致整個系統變慢。如果放到同一臺機器上，必然導致響應變慢。把不同性質的數據，放到不同機器、不同的數據系統中，可以合理的分流系統訪問量，使系統響應加快，橫向擴展更具有彈性。

4、 把支付訂票費用放到一個單獨的網站進行，訂單提交成功后鎖票，之后根據訂單號可以在另外一個單獨的網站上進行單獨支付，支付時只要提供訂票號就可以，這樣做有很多好處：1. 避免了由于支付失敗而導致退出瀏覽器，卻由于在線人數過多無法登陸導致訂票失敗的情況，2. 電話訂票也可以在此支付，在火車站機自動售票機器上取票，這樣支付方便，也解決了異地付款取票的問題 3. 單獨支付會在一定程度上給訂票網站減輕訪問與處理壓力

5、 提供快遞火車票服務進行創收，支付成功的火車票可以進行快遞，這樣即方便訂票人也可以給鐵道部創收

6、 網站可以根據用戶訂票信息做一些有針對性網站廣告，如旅游、酒店廣告等進行創收

7、 開發出更多的手機終端軟件，擴大訂票系統使用的覆蓋面

8、 支持更多的瀏覽器，而不僅僅是IE

由于本人水平有限，歡迎各個高手批評指正，希望這篇文章能夠拋磚引玉，大家一起討論。
網上的其他類似文章：

http://cloud.it168.com/a2012/0130/1304/000001304533.shtml 

轉自：http://book.douban.com/annotation/19461092/


       半個月前在豆瓣上看到了一本新書《數學之美》，評價很高。而因為在半年前看了《什么是數學》就對數學產生濃厚興趣，但苦于水平不足的我便立馬買了一本，希望能對數學多一些了解，并認真閱讀起來。
       令我意外并欣喜的是，這本書里邊的數學內容并不晦澀難懂，而且作者為了講述數學之美而搭配的一些工程實例都是和我學習并感興趣的模式識別，目標分類相關算法相關聯的。這讓我覺得撿到了意外的寶藏。
        書中每一個章節都或多或少是作者親身經歷過的，比如世界級教授的小故事，或者Google的搜索引擎原理，又或者是Google的云計算等。作者用其行云流水般的語言將各個知識點像講故事一樣有趣的敘述出來。
        這本書著實讓我印象深刻，所以我把筆記分享出來，希望更多和我學習研究領域一樣的人會喜歡并親自閱讀這本書，并能支持作者。畢竟國內這種書實在是太少了，也希望能有更多領域內的大牛能再寫出一些這種書籍來讓我們共同提高。
1.    因為需要傳播信息量的增加，不同的聲音并不能完全表達信息，語言便產生了。
2.    當文字增加到沒有人能完全記住所有文字時，聚類和歸類就開始了。例如日代表太陽或者代表一天。
3.    聚類會帶來歧義性，但上下文可以消除歧義。信息冗余是信息安全的保障。例如羅塞塔石碑上同一信息重復三次。
4.    最短編碼原理即常用信息短編碼，生僻信息長編碼。
5.    因為文字只是信息的載體而非信息本身，所以翻譯是可以實現的。
6.    2012，其實是瑪雅文明采用二十進制，即四百年是一個太陽紀，而2012年恰巧是當前太陽紀的最后一年，2013年是新的太陽紀的開始，故被誤傳為世界末日。
7.    字母可以看為是一維編碼，而漢字可以看為二維編碼。
8.    基于統計的自然語言處理方法，在數學模型上和通信是相通的，甚至是相同的。
9.    讓計算機處理自然語言的基本問題就是為自然語言這種上下文相關的特性建立數學模型，即統計語言模型（Statistical Language Modal）。
10.    根據大數定理（Law of Large Numbers），只要統計量足夠，相對頻度就等于概率。
11.    二元模型。對于p(w1,w2,…,wn)=p(w1)p(w2|w1)p(w3|w1,w2)…p(wn|w1,w2,…,wn-1)的展開問題，因為p(w3|w1,w2)難計算，p(wn|w1,w2,…,wn-1)更難計算，馬爾科夫給出了一個偷懶但是頗為有效的方法，也就是每當遇到這種情況時，就假設任意wi出現的概率只與它前面的wi-1有關，即p(s)=p(w1)p(w2|w1)p(w3|w2)…p(wi|wi-1)…p(wn|wn-1)。現在這個概率就變的簡單了。對應的語言模型為2元模型（Bigram Model）。
12.    *N元模型。wi只與前一個wi-1有關近似的過頭了，所以N-1階馬爾科夫假設為p(wi|w1,w2,…,wi-1)=p(wi|wi-N+1,wi-N+2,…,wi-1)，對應的語言模型成為N元模型（N-Gram Model）。一元模型就是上下文無關模型，實際應用中更多實用的是三元模型。Google的羅塞塔翻譯系統和語言搜索系統實用的是四元模型，存儲于500臺以上的Google服務器中。
13.    *卡茲退避法（Katz backoff），對于頻率超過一定閾值的詞，它們的概率估計就是它們在語料庫中的相對頻度，對于頻率小于這個閾值的詞，它們的概率估計就小于他們的相對頻度，出現次數越少，頻率下調越多。對于未看見的詞，也給予一個比較小的概率（即下調得到的頻率總和），這樣所有詞的概率估計都平滑了。這就是卡茲退避法（Katz backoff）。
14.    訓練數據通常是越多越好，通過平滑過渡的方法可以解決零概率和很小概率的問題，畢竟在數據量多的時候概率模型的參數可以估計的比較準確。
15.    利用統計語言模型進行分詞，即最好的分詞方法應該保證分完詞后這個句子出現的概率最大。根據不同應用，漢語分詞的顆粒度大小應該不同。
16.    符合馬爾科夫假設（各個狀態st的概率分布只與它前一個狀態st-1有關）的隨即過程即成為馬爾科夫過程，也稱為馬爾科夫鏈。
17.    隱含馬爾科夫模型是馬爾科夫鏈的擴展，任意時刻t的狀態st是不可見的，所以觀察者沒法通過觀察到一個狀態序列s1,s2,s3,…,sT來推測轉移概率等參數。但是隱馬爾科夫模型在每個時刻t會輸出一個符號ot，而且ot和st相關且僅和ot相關。這個被稱為獨立輸出假設。其中隱含的狀態s1,s2,s3,…是一個典型的馬爾科夫鏈。
18.    隱含馬爾科夫模型是機器學習主要工具之一，和幾乎所有機器學習的模型工具一樣，它需要一個訓練算法（鮑姆-韋爾奇算法）和使用時的解碼算法（維特比算法）。掌握了這兩類算法，就基本上可以使用隱含馬爾科夫模型這個工具了。
19.    鮑姆-韋爾奇算法（Baum-Welch Algorithm），首先找到一組能夠產生輸出序列O的模型參數，這個初始模型成為Mtheta0，需要在此基礎上找到一個更好的模型，假定不但可以算出這個模型產生O的概率P(O|Mtheta0)，而且能夠找到這個模型產生O的所有可能的路徑以及這些路徑的概率。并算出一組新的模型參數theta1，從Mtheta0到Mtheta1的過程稱為一次迭代。接下來從Mtheta1出發尋找更好的模型Mtheta2，并一直找下去，直到模型的質量沒有明顯提高為止。這樣一直估計（Expectation）新的模型參數，使得輸出的概率達到最大化（Maximization）的過程被稱為期望值最大化（Expectation-Maximization）簡稱EM過程。EM過程能保證一定能收斂到一個局部最優點，但不能保證找到全局最優點。因此，在一些自然語言處理的應用中，這種無監督的鮑姆-韋爾奇算法訓練處的模型比有監督的訓練得到的模型效果略差。
20.    熵，信息熵的定義為H(X)=-SumP(x)logP(x)，變量的不確定性越大，熵也越大。
21.    一個事物內部會存在隨機性，也就是不確定性，假定為U，而從外部消除這個不確定性唯一的辦法是引入信息I，而需要引入的信息量取決于這個不確定性的大小，即I>U才行。當I<U時，這些信息可以消除一部分不確定性，U'=U-I。反之，如果沒有信息，任何公示或者數字的游戲都無法排除不確定性。
22.    信息的作用在于消除不確定性。
23.    互信息，對兩個隨機事件相關性的量化度量，即隨機事件X的不確定性或者說熵H(X)，在知道隨機事件Y條件下的不確定性，或者說條件熵H(X|Y)之間的差異，即I(X;Y)=H(X)-H(X|Y)。所謂兩個事件相關性的量化度量，即在了解了其中一個Y的前提下，對消除另一個X不確定性所提供的信息量。
24.    相對熵（Kullback-Leibler Divergence）也叫交叉熵，對兩個完全相同的函數，他們的相對熵為零；相對熵越大，兩個函數差異越大，反之，相對熵越小，兩個函數差異越小；對于概率分布或者概率密度函數，如果取值均大于零，相對熵可以度量兩個隨機分布的差異性。
25.    弗里德里克·賈里尼克（Frederek Jelinek）是自然語言處理真諦的先驅者。
26.    技術分為術和道兩種，具體的做事方法是術，做事的原理和原則是道。術會從獨門絕技到普及再到落伍，追求術的人會很辛苦，只有掌握了道的本質和精髓才能永遠游刃有余。
27.    真理在形式上從來是簡單的，而不是復雜和含混的。
28.    搜索引擎不過是一張大表，表的每一行對應一個關鍵字，而每一個關鍵字后面跟著一組數字，是包含該關鍵詞的文獻序號。但當索引變的非常大的時候，這些索引需要通過分布式的方式存儲到不同的服務器上。
29.    網絡爬蟲（Web Crawlers），圖論的遍歷算法和搜索引擎的關系。互聯網雖然復雜，但是說穿了其實就是一張大圖……可以把每一個網頁當做一個節點，把那些超鏈接當做連接網頁的弧。有了超鏈接，可以從任何一個網頁出發，用圖的遍歷算法，自動訪問到每一個網頁并且把他們存儲起來。完成這個功能的程序叫網絡爬蟲。
30.    哥尼斯堡七橋，如果一個圖能從一個頂點出發，每條邊不重復的遍歷一遍回到這個頂點，那么每一個頂點的度必須為偶數。
31.    構建網絡爬蟲的工程要點：1.用BFS（廣度優先搜索）還是DFS（深度優先搜索），一般是先下載完一個網站，再進入下一個網站，即BFS的成分多一些。2.頁面的分析和URL的提取，如果有些網頁明明存在，但搜索引擎并沒有收錄，可能的原因之一是網絡爬蟲中的解析程序沒能成功解析網頁中不規范的腳本程序。3.記錄哪些網頁已經下載過的URL表，可以用哈希表。最終，好的方法一般都采用了這樣兩個技術：首先明確每臺下載服務器的分工，也就是在調度時，一看到某個URL就知道要交給哪臺服務器去下載，這樣就避免了很多服務器對同一個URL做出是否需要下載的判斷。然后，在明確分工的基礎上，判斷URL是否下載就可以批處理了，比如每次向哈希表（一組獨立的服務器）發送一大批詢問，或者每次更新一大批哈希表的內容，這樣通信的次數就大大減少了。
32.    PageRank衡量網頁質量的核心思想，在互聯網上，如果一個網頁被很多其他網頁所鏈接，說明它受到普遍的承認和信賴，那么它的排名就高。同時，對于來自不同網頁的鏈接區別對待，因為網頁排名高的那些網頁的鏈接更可靠，于是要給這些鏈接比較大的權重。
33.    TF-IDF(Term Frequency / Inverse Document Frequency) ，關鍵詞頻率-逆文本頻率值，其中，TF為某個網頁上出現關鍵詞的頻率，IDF為假定一個關鍵詞w在Dw個網頁中出現過，那么Dw越大，w的權重越小，反之亦然，公式為log(D/Dw)。1.一個詞預測主題的能力越強，權重越大，反之，權重越小。2.停止詞的權重為零。
34.    動態規劃（Dynamic Programming）的原理，將一個尋找全程最優的問題分解成一個個尋找局部最優的小問題。
35.    一個好的算法應該像輕武器中最有名的AK-47沖鋒槍那樣：簡單、有效、可靠性好而且容易讀懂（易操作）而不應該故弄玄虛。選擇簡單方案可以容易解釋每個步驟和方法背后的道理，這樣不僅便于出問題時的查錯，也容易找到今后改進的目標。
36.    在實際的分類中，可以先進行奇異值分解（得到分類結果略顯粗糙但能較快得到結果），在粗分類結果的基礎上，利用計算向量余弦的方法（對范圍內的分類做兩兩計算），在粗分類結果的基礎上，進行幾次迭代，得到比較精確的結果。
37.    奇異值分解（Singular Value Decomposition），在需要用一個大矩陣A來描述成千上萬文章和幾十上百萬詞的關聯性時，計算量非常大，可以將A奇異值分解為X、B和Y三個矩陣，Amn=Xmm*Bmn*Ynn，X表示詞和詞類的相關性，Y表示文本和主題的相關性，B表示詞類和主題的相關性，其中B對角線上的元素很多值相對其他的非常小，或者為零，可以省略。對關聯矩陣A進行一次奇異值分解，就可以同時完成近義詞分類和文章的分類，同時能得到每個主題和每個詞義類之間的相關性，這個結果非常漂亮。
38.    信息指紋。如果能夠找到一種函數，將5000億網址隨即地映射到128位二進制，也就是16字節的整數空間，就稱這16字節的隨機數做該網址的信息指紋。信息指紋可以理解為將一段信息映射到一個多維二進制空間中的一個點，只要這個隨即函數做的好，那么不同信息對應的點不會重合，因此這個二進制的數字就變成了原來信息所具有的獨一無二的指紋。
39.    判斷兩個集合是否相同，最笨的方法是這個集合中的元素一一比較，復雜度O(squareN)，稍好的是將元素排序后順序比較，復雜度O(NlogN)，最完美的方法是計算這兩個集合的指紋，然后直接進行比較，計算復雜度O(N)。
40.    偽隨機數產生器算法（Pseudo-Random Number Generator，PRNG），這是產生信息指紋的關鍵算法，通過他可以將任意長的整數轉換成特定長度的偽隨機數。最早的PRNG是將一個數的平方掐頭去尾取中間，當然這種方法不是很隨即，現在常用的是梅森旋轉算法（Mersenne Twister）。
41.    在互聯網上加密要使用基于加密的偽隨機數產生器（Cryptography Secure Pseudo-Random Number Generator，CSPRNG），常用的算法有MD5或者SHA-1等標準，可以將不定長的信息變成定長的128位或者160位二進制隨機數。
42.    最大熵模型（Maximum Entropy）的原理就是保留全部的不確定性，將風險降到最小。最大熵原理指出，需要對一個隨機事件的概率分布進行預測時，我們的預測應當滿足全部已知的條件，而對未知的情況不要做任何主觀假設。在這種情況下，概率分布最均勻，預測的風險最小。I.Csiszar證明，對任何一組不自相矛盾的信息，這個最大熵模型不僅存在，而且是唯一的，此外，他們都有同一個非常簡單的形式-指數函數。
43.    通用迭代算法（Generalized Iterative Scaling，GIS）是最原始的最大熵模型的訓練方法。1.假定第零次迭代的初始模型為等概率的均勻分布。2.用第N次迭代的模型來估算每種信息特征在訓練數據中的分布。如果超過了實際的，就把相應的模型參數變小，反之變大。3.重復步驟2直至收斂。這是一種典型的期望值最大化（Expectation Maximization，EM）算法。IIS(Improved Iterative Scaling)比GIS縮短了一到兩個數量級。
44.    布隆過濾器實際上是一個很長的二進制向量和一系列隨機映射的函數。
45.    貝葉斯網絡從數學的層面講是一個加權的有向圖，是馬爾科夫鏈的擴展，而從知識論的層面看，貝葉斯網絡克服了馬爾科夫那種機械的線性的約束，它可以把任何有關聯的事件統一到它的框架下面。在網絡中，假定馬爾科夫假設成立，即每一個狀態只與和它直接相連的狀態有關，而和他間接相連的狀態沒有直接關系，那么它就是貝葉斯網絡。在網絡中每個節點概率的計算，都可以用貝葉斯公式來進行，貝葉斯網絡也因此得名。由于網絡的每個弧都有一個可信度，貝葉斯網絡也被稱作信念網絡（Belief Networks）。
46.    條件隨機場是計算聯合概率分布的有效模型。在一個隱含馬爾科夫模型中，以x1,x2,...,xn表示觀測值序列，以y1,y2,...,yn表示隱含的狀態序列，那么xi只取決于產生它們的狀態yi,和前后的狀態yi-1和yi+1都無關。顯然很多應用里觀察值xi可能和前后的狀態都有關，如果把xi和yi-1,yi,yi+1都考慮進來，這樣的模型就是條件隨機場。它是一種特殊的概率圖模型（Probablistic Graph Model），它的特殊性在于，變量之間要遵守馬爾科夫假設，即每個狀態的轉移概率只取決于相鄰的狀態，這一點和另一種概率圖模型貝葉斯網絡相同，它們的不同之處在于條件隨機場是無向圖，而貝葉斯網絡是有向圖。
47.    維特比算法（Viterbi Algoritm）是一個特殊但應用最廣的動態規劃算法，利用動態規劃，可以解決任何一個圖中的最短路徑問題。它之所以重要，是因為凡是使用隱含馬爾科夫模型描述的問題都可以用它來解碼。1.從點S出發，對于第一個狀態x1的各個節點，不妨假定有n1個，計算出S到他們的距離d(S,x1i)，其中x1i代表任意狀態1的節點。因為只有一步，所以這些距離都是S到他們各自的最短距離。2.對于第二個狀態x2的所有節點，要計算出從S到他們的最短距離。d(S,x2i)=min_I=1,n1_d(S,x1j)+d(x1j,x2i)，由于j有n1種可能性，需要一一計算，然后找到最小值。這樣對于第二個狀態的每個節點，需要n1次乘法計算。假定這個狀態有n2個節點，把S這些節點的距離都算一遍，就有O(n1*n2)次運算。3.按照上述方法從第二個狀態走到第三個狀態一直走到最后一個狀態，這樣就得到整個網絡從頭到尾的最短路徑。
48.    擴頻傳輸（Spread-Spectrum Transmission）和固定頻率的傳輸相比，有三點明顯的好處：1.抗干擾能力強。2.信號能量非常低，很難獲取。3.擴頻傳輸利用帶寬更充分。
49.    Google針對云計算給出的解決工具是MapReduce，其根本原理就是計算機算法上常見的分治算法（Divide-and-Conquer）。將一個大任務拆分成小的子任務，并完成子任務的計算，這個過程叫Map，將中間結果合并成最終結果，這個過程叫Reduce。
50.    邏輯回歸模型（Logistic Regression）是將一個事件出現的概率適應到一條邏輯曲線（Logistic Curve）上。典型的邏輯回歸函數：f(z)=e`z/e`z+1=1/1+e`-z。邏輯曲線是一條S型曲線，其特點是開始變化快，逐漸減慢，最后飽和。邏輯自回歸的好處是它的變量范圍從負無窮到正無窮，而值域范圍限制在0-1之間。因為值域的范圍在0-1之間，這樣邏輯回歸函數就可以和一個概率分別聯系起來了。因為自變量范圍在負無窮到正無窮之間，它就可以把信號組合起來，不論組合成多大或者多小的值，最后依然能得到一個概率分布。
51.    期望最大化算法（Expectation Maximization Algorithm），根據現有的模型，計算各個觀測數據輸入到模型中的計算結果，這個過程稱為期望值計算過程（Expectation），或E過程；接下來，重新計算模型參數，以最大化期望值，這個過程稱為最大化的過程（Maximization），或M過程。這一類算法都稱為EM算法，比如隱含馬爾科夫模型的訓練方法Baum-Welch算法，以及最大熵模型的訓練方法GIS算法。

http://ipseeker.cn/tools/pywb.php 

在Windows平臺做開發肯定會接觸到UI程序的編寫，以MFC的UI開發為例，可以開發單文檔，多文檔，對話框等形式的應用。寫一個UI程序容易，寫好卻不是一件簡單的事情。在整個代碼結構的清晰性與可維護性方面需要多加注意。寫好UI程序需求注意以下幾點：

 

1、圍繞數據編程與不是圍繞UI編程

 

當我們拿到需求最先接觸到的就是UI的設計，也許是美工畫的，也許是設計草圖。工程師在具體設計的時候容易受UI的影響，或者干脆從UI開始編程。

 

這是一個錯誤的編程習慣，無論UI如何展現與交互，最終都應該圍繞數據編程。拿到需求后，應該先思考和推敲數據的設計與流轉，UI不過就是數據的一種展現形式而已。

 

2、做好UI與邏輯的解耦

 

UI的編程會涉及到許多控件的操作，消息的處理，不知不覺，一個UI類的代碼會越寫越大，以至于一段時間以后，瀏覽和梳理都會變得不太方便。

 

在UI類里，除了與UI本身的操作有關的代碼以外，任何邏輯代碼都應該與此解耦，并根據具體情況進行封裝調用。如果一個控件關聯了太多數據操作，應該把這些操作封裝到控件的繼承類中，把一類代碼進行集中管理和維護。

 

上述問題，在程序寫作的初期還不太明顯，隨著代碼逐漸膨脹，會越會越讓人難以忍受。

 

3、數據單向依賴，單向更新

 

UI圍繞的數據進行展現與更新，在這個過程中，所以對數據的操作應該進行封裝，而不是散落在UI程序在各個角落，數據的更新、獲取和UI傳遞消息時，應該單向操作，如果出現循環處理的情況，在以后維護調試的BUG的過程中會變得比較困難，導致維護效率下降。

 

 

新建一個DEF文件（右鍵Project->Add->New Item->.def）

加入


參考鏈接：      摘要: 轉自：http://www.cnblogs.com/k-eckel/articles/188489.html深入分析MFC文檔視圖結構（項目實踐）        k_eckel：http://www.mscenter.edu.cn/blog/k_eckel 文檔視圖結構（Document/View Architecture）是MFC的精髓...  閱讀全文