You need compile boost and add libs path in project or makefile.

Compile boost run:

轉自：http://blog.chinaunix.net/uid-23766031-id-2386460.html

死鎖：一種情形，此時執行程序中兩個或多個線程發生永久堵塞（等待），每個線程都在等待被   VC控制臺使用CSocket要點：

1、在Stdafx.h中加入#include "afxsock.h"
2、在CPP中加入
最使用VC編寫base64的程序，找了半天發現ATL本身就提供此功能，以下幾個函數就可以滿足常見需要：

設計高效算法往往需要使用Hash表，O(1)級的查找速度是任何別的算法無法比擬的。
所謂Hash，一般是一個整數，通過某種算法，可以把一個字符串"pack"成一個整數，這個數稱為Hash，當然，一個整數是無法對應一個字符串的。
所以Hash函數是Hash表最核心的部分，對于一個Hash函數，評價其優劣的標準應為隨機性或離散性，即對任意一組標本，進入Hash表每一個單元（cell）之概率的平均程度，因為這個概率越平均，兩個字符串計算出的Hash值相等hash collision的可能越小，數據在表中的分布就越平均，表的空間利用率就越高。

Hash表的構造和沖突的不同實現方法對執行效率也有一定的影響.

DJBHash是一種非常流行的算法，俗稱"Times33"算法。Times33的算法很簡單，就是不斷的乘33，原型如下

hash(i) = hash(i-1) * 33 + str[i]

Time33在效率和隨機性兩方面上俱佳。

其它常用字符串哈希函數有：
BKDRHash，APHash，JSHash，RSHash，SDBMHash，PJWHash，ELFHash等。BKDRHash和APHash也是比較優秀的算法。當然要根據具體應用選擇合適的Hash算法，比如字符集的考慮。

APHash作者Arash Partow有一個頁面很有參考價值，包括了各種Hash的介紹及代碼。

http://www.partow.net/programming/hashfunctions/#RSHashFunction

Blizzard使用的算法比較精妙，被稱為"One-Way Hash"，并且在Hash表中使用了三個哈希值(一個用來確定位置，另外兩個用來校驗)。

MD5等加密算法也屬于hash，不過已被中國學者找到碰撞檢測的破解算法 http://blog.sina.com.cn/s/blog_a2498b5b01014bsg.html

題目描述：

     一個循環有序數組（如：3,4,5,6,7,8,9,0,1,2），不知道其最小值的位置，要查找任一數值的位置。要求算法時間復雜度為log2(n)。

問題分析：

    我們可以把循環有序數組分為左右兩部分（以mid = （low+high）/ 2為界），由循環有序數組的特點知，左右兩部分必有一部分是有序的，我們可以找出有序的這部分，然后看所查找元素是否在有序部分，若在，則直接對有序部分二分查找，若不在，對無序部分遞歸調用查找函數。

代碼如下：

    #include <iostream>

    using namespace std;

    int binarySearch(int a[],int low,int high,int value)  //二分查找
    {
        if(low>high)
            return -1;

        int mid=(low+high)/2;

        if(value==a[mid])
            return mid;
        else if(value>a[mid])
            return binarySearch(a,mid+1,high,value);
        else
            return binarySearch(a,low,mid-1,value);
    }

    int Search(int a[],int low,int high,int value)     //循環有序查找函數
    {
        int mid=(low+high)/2;

        if(a[mid]>a[low])       //左有序
        {
            if(a[low]<=value && value<=a[mid] )        //說明value在左邊，直接二分查找
            {
                return binarySearch(a,low,mid,value);
            }

            else                                       //value在右邊
            {
                return Search(a,mid+1,high,value);
            }
        }
        else                    //右有序
        {
            if(a[mid]<=value && value<=a[high])
            {
                return binarySearch(a,mid,high,value);
            }
            else
            {
                return Search(a,low,mid-1,value);
            }
        }
    }

    int main()
    {
        int a[]={3,4,5,6,7,8,9,0,1,2};

        cout<<Search(a,0,9,0)<<endl;

        return 0;
    }

大小端問題

 

By unanao

<sunjianjiao@gmail.com>

 

一、什么是大小端問題

(From《Computer Systems,A Programer's Perspective》)在幾乎所有的機器上，多字節對象被存儲為連續的字節序列，對象的地址為所使用字節序列中最低字節地址。

小端：某些機器選擇在存儲器中按照從最低有效字節到最高有效字節的順序存儲對象，這種最低有效字節在最前面的表示方式被稱為小端法(little endian) 。這樣的存儲模式有點兒類似于把數據當作字符串順序處理：地址由小向大增加，而數據從高位往低位放；

       大端：某些機器則按照從最高有效字節到最低有效字節的順序儲存，這種最高有效字節在最前面的方式被稱為大端法(big endian) 。這種存儲模式將地址的高低和數據位權有效地結合起來，高地址部分權值高，低地址部分權值低，和我們的邏輯方法一致。

 

 舉個例子來說名大小端:  比如一個int x, 地址為0x100, 它的值為0x1234567. 則它所占據的0x100, 0x101, 0x102, 0x103地址組織如下圖:

二、為什么會有大小端模式之分呢？

這是因為在計算機系統中，我們是以字節為單位的，每個地址單元都對應著一個字節，一個字節為 8bit。但是在C語言中除了8bit的char之外，還有16bit的short型，32bit的long型（要看具體的編譯器），另外，對于位數大于 8位的處理器，例如16位或者32位的處理器，由于寄存器寬度大于一個字節，那么必然存在著一個如果將多個字節安排的問題。因此就導致了大端存儲模式和小端存儲模式。例如一個16bit的short型x，在內存中的地址為0x0010，x的值為0x1122，那么0x11為高字節，0x22為低字節。對于 大端模式，就將0x11放在低地址中，即0x0010中，0x22放在高地址中，即0x0011中。小端模式，剛好相反。我們常用的X86結構是小端模 式，而KEIL C51則為大端模式。很多的ARM，DSP都為小端模式。有些ARM處理器還可以由硬件來選擇是大端模式還是小端模式。

 

三、如何區分大小端問題：

方法1：

#include <stdio.h>

 

int main(void)

{

       int i = 1;

       unsigned char *pointer;

 

       pointer = (unsigned char *)&i;

       if(*pointer)

       {

              printf("litttle_endian");

       }

       else

       {

              printf("big endian\n");

       }

 

       return 0;

}

       C中的數據類型都是從內存的低地址向高地址擴展，取址運算"&"都是取低地址。小端方式中（i占至少兩個字節的長度）則i所分配的內存最小地址那個字節中就存著1，其他字節是0。大端的話則1在i的最高地址字節處存放，char是一個字節，所以強制將char型量p指向i，則p指向的一定是i的最低地址，那么就可以判斷p中的值是不是1來確定是不是小端。

 

方法2：

#include <stdio.h>

 

int main(void)

{

       union {

              short a;

              char ch;

       } u;

       u.a = 1;

 

       if (u.ch == 1)

       {

              printf("Littel endian\n");

       }

       else

       {

              printf("Big endian\n");

       }

}

       利用聯合體的特點，數據成員共享內存空間，union中元素的起始地址都是相同的——位于聯合的開始。 用char來截取感興趣的字節。

 

四、需要考慮大小端（字節順序）的情況

1、所寫的程序需要向不同的硬件平臺遷移，說不定哪一個平臺是大端還是小端，為了保證可移植性，一定提前考慮好。

2. 在不同類型的機器之間通過網絡傳送二進制數據時。 一個常見的問題是當小端法機器產生的數據被發送到大端法機器或者反之時，接受程序會發現，字(word)里的字節(byte)成了反序的。為了避免這類問 題，網絡應用程序的代碼編寫必須遵守已建立的關于字節順序的規則，以確保發送方機器將它的內部表示轉換成網絡標準，而接受方機器則將網絡標準轉換為它的內部標準。

3. 當閱讀表示整數的字節序列時。這通常發生在檢查機器級程序時，e.g.：反匯編得到的一條指令：
80483bd: 01 05 64 94 04 08        add %eax, 0x8049464

3. 當編寫強轉的類型系統的程序時。如寫入的數據為u32型，但是讀取的時候卻是char型的。如：0x1234, 大端讀取為12時，小端獨到的是34。

六、提高程序的可移植性

使用宏編譯

#ifdef LITTLE_ENDIAN

//小端的代碼

#else

//大端的代碼

#endif

 

七、大、小端之間的轉換

1、小端轉換為大端

#include <stdio.h>

 

void show_byte(char *addr, int len)

{

       int i;

 

       for (i = 0; i < len; i++)

       {

              printf("%.2x \t", addr[i]);

       }

       printf("\n");

}

 

int endian_convert(int t)

{

       int result;

       int i;

 

       result = 0;

       for (i = 0; i < sizeof(t); i++)

       {

              result <<= 8;

              result |= (t & 0xFF);

              t >>= 8;

       }

 

       return result;

}

 

int main(void)

{

       int i;

       int ret;

 

       i = 0x1234567;

 

       show_byte((char *)&i, sizeof(int));

       ret = endian_convert(i);

       show_byte((char *)&ret, sizeof(int));

 

       return 0;

}

 

轉自：http://www.fredosaurus.com/notes-cpp/misc/random-shuffle.html

// File        : misc/random/deal.cpp - Randomly shuffle deck of cards.

// Illustrates : Shuffle algorithm, srand, rand.

// Improvements: Use classes for Card and Deck.

// Author      : Fred Swartz 2003-08-24, shuffle correction 2007-01-18

//               Placed in the public domain.

 

#include <iostream>

#include <cstdlib>   // for srand and rand

#include <ctime>     // for time

using namespace std;

 

int main() {

    int card[52];    // array of cards;

    int n;           // number of cards to deal

    srand(time(0));  // initialize seed "randomly"

    

    for (int i=0; i<52; i++) {

        card[i] = i;  // fill the array in order

    }

   

    while (cin >> n) {   

        //--- Shuffle elements by randomly exchanging each with one other.

        for (int i=0; i<(52-1); i++) {

            int r = i + (rand() % (52-i)); // Random remaining position.

            int temp = card[i]; card[i] = card[r]; card[r] = temp;

        }

       

        //--- Print first n cards as ints.

        for (int c=0; c<n; c++) {

            cout << card[c] << " ";  // Just print number

        }

        cout << endl;

    }

  

   return 0;

}

轉自：http://blog.csdn.net/fuyangchang/article/details/5637464
wiki地址http://en.wikipedia.org/wiki/Hamming_distance

在信息領域，兩個長度相等的字符串的海明距離是在相同位置上不同的字符的個數，也就是將一個字符串替換成另一個字符串需要的替換的次數。

例如：

• "toned" and "roses" is 3.
• 1011101 and 1001001 is 2.
• 2173896 and 2233796 is 3.

對于二進制來說，海明距離的結果相當于 a XOR b 結果中1的個數。

python代碼如下

 

def hamming_distance(s1, s2):

    assert len(s1) == len(s2)

    return sum(ch1 != ch2 for ch1, ch2 in zip(s1, s2))

 

print (hamming_distance("gdad","glas"))

結果是2

 

C語言代碼如下

 

unsigned hamdist(unsigned x, unsigned y)

{

  unsigned dist = 0, val = x ^ y;

 

  // Count the number of set bits

  while(val)

  {

    ++dist;

    val &= val - 1;

  }

 

  return dist;

}

 

int main()

{

         unsigned x="abcdcc";

         unsigned y="abccdd";

         unsigned z=hamdist(x,y);

         printf("%d",z);

}

     摘要: 轉自：http://www.codinglabs.org/html/theory-of-mysql-index.htmlMySQL索引背后的數據結構及算法原理摘要本文以MySQL數據庫為研究對象，討論與數據庫索引相關的一些話題。特別需要說明的是，MySQL支持諸多存儲引擎，而各種存儲引擎對索引的支持也各不相同，因此MySQL數據庫支持多種索引類型，如BTree索引，哈希索引，全文索引等等。為了避免...  閱讀全文

轉自：http://www.infoq.com/cn/articles/cyw-evaluate-seachengine-result-quality

前言

搜索質量評估是搜索技術研究的基礎性工作，也是核心工作之一。評價（Metrics）在搜索技術研發中扮演著重要角色，以至于任何一種新方法與他們的評價方式是融為一體的。

Cranfield評價體系

A Cranfield-like approach這個名稱來源于英國Cranfield University，因為在二十世紀五十年代該大學首先提出了這樣一套評價系統：由查詢樣例集、正確答案集、評測指標構成的完整評測方案，并從此確立了“評價”在信息檢索研究中的核心地位。

Cranfield評價體系由三個環節組成：

1. 抽取代表性的查詢詞，組成一個規模適當的集合
2. 針對查詢樣例集合，從檢索系統的語料庫中尋找對應的結果，進行標注（通常人工進行）
3. 將查詢詞和帶有標注信息的語料庫輸入檢索系統，對系統反饋的檢索結果，使用預定義好的評價計算公式，用數值化的方法來評價檢索系統結果和標注的理想結果的接近程度

查詢詞集合的選取

Cranfield評價系統在各大搜索引擎公司內有廣泛的應用。具體應用時，首先需要解決的問題是構造一個測試用查詢詞集合。

按照Andrei Broder（曾在AltaVista/IBM/Yahoo任職）的研究，查詢詞可分為3類：尋址類查詢（Navigational）、信息類查詢(Informational)、事務類查詢(Transactional)。對應的比例分別為

Navigational ： 12.3%  Informational ： 62.0%  Transactional ： 25.7% 

為了使得評估符合線上實際情況，通常查詢詞集合也會按比例進行選取。通常從線上用戶的Query Log文件中自動抽取。

另外查詢集合的構造時，除了上述查詢類型外，還可以考慮Query的頻次，對熱門query（高頻查詢）、長尾query（中低頻）分別占特定的比例。

另外，在抽取Query時，往往Query的長短也是一個待考慮的因素。因為短query（單term的查詢）和長Query（多Term的查詢）排序算法往往會有一些不同。

構成查詢集合后，使用這些查詢詞，在不同系統（例如對比百度和Google）或不同技術間（新舊兩套Ranking算法的環境）進行搜索，并對結果進行評分，以決定優劣。

附圖：對同一Query：“社會保險法”，各大搜索引擎的結果示意圖。下面具體談談評分的方法。

Precision-recall（準確率-召回率方法）

計算方法

信息檢索領域最廣為人知的評價指標為Precision-Recall（準確率-召回率）方法。該方法從提出至今已經歷半個世紀，至今在很多搜索引擎公司的效果評估中使用。

顧名思義，這個方法由準確率和召回率這兩個相互關聯的統計量構成：召回率（Recall）衡量一個查詢搜索到所有相關文檔的能力，而準確率（Precision）衡量搜索系統排除不相關文檔的能力。（通俗的解釋一下：準確率就是算一算你查詢得到的結果中有多少是靠譜的；而召回率表示所有靠譜的結果中，有多少被你給找回來了）。這兩項是評價搜索效果的最基礎指標，其具體的計算方法如下。

Precision-recall方法假定對一個給定的查詢，對應一個被檢索的文檔集合和一個不相關的文檔集合。這里相關性被假設為二元的，用數學形式化方法來描述，則是：

A表示相關文檔集合

A表示不相關集合

B表示被檢索到的文檔集合

B表示未被檢索到的文檔集合

則單次查詢的準確率和召回率可以用下述公式來表達：

（運算符∩ 表示兩個集合的交集。|x|符號表示集合x中的元素數量）

從上面的定義不難看出，召回率和準確率的取值范圍均在[0,1]之間。那么不難想象，如果這個系統找回的相關越多，那么召回率越高，如果相關結果全部都給召回了，那么recall此時就等于1.0。

	相關的	不相關
被檢索到	A∩ B	A∩ B
未被檢索到	A∩B	A∩B

Precision-Recall曲線

召回率和準確率分別反映了檢索系統的兩個最重要的側面，而這兩個側面又相互制約。因為大規模數據集合中，如果期望檢索到更多相關的文檔，必然需要“放寬”檢索標準，因此會導致一些不相關結果混進來，從而使準確率受到影響。類似的，期望提高準確率，將不相關文檔盡量去除時，務必要執行更“嚴格”的檢索策略，這樣也會使一些相關的文檔被排除在外，使召回率下降。

所以為了更清晰的描述兩者間的關系，通常我們將Precison-Recall用曲線的方式繪制出來，可以簡稱為P-R diagram。常見的形式如下圖所示。（通常曲線是一個逐步向下的走勢，即隨著Recall的提高，Precision逐步降低）

P-R的其它形態

一些特定搜索應用，會更關注搜索結果中錯誤的結果。例如，搜索引擎的反作弊系統（Anti-Spam System）會更關注檢索結果中混入了多少條作弊結果。學術界把這些錯誤結果稱作假陽性（False Positive）結果，對這些應用，通常選擇用虛報率（Fallout）來統計：

Fallout和Presion本質是完全相同的。只是分別從正反兩方面來計算。實際上是P-R的一個變種。

再回到上圖，Presion-Recall是一個曲線，用來比較兩個方法的效果往往不夠直觀，能不能對兩者進行綜合，直接反映到一個數值上呢？為此IR學術界提出了F值度量（F -Measure）的方法。F-Measure通過Presion和Recall的調和平均數來計算，公式為：

其中參數λε(0,1)調節系統對Precision和Recall的平衡程度。（通常取λ=0.5，此時 ）

這里使用調和平均數而不是通常的幾何平均或算術平均，原因是調和平均數強調較小數值的重要性，能敏感的反映小數字的變化，因此更適合用來反映檢索效果。

使用F Measure的好處是只需要一個單一的數字就可以總結系統的檢索效果，便于比較不同搜索系統的整體效果。

P@N方法

點擊因素

傳統的Precision-Recall并不完全適用對搜索引擎的評估，原因是搜索引擎用戶的點擊方式有其特殊性，包括：

A 60-65%的查詢點擊了名列搜索結果前10條的網頁；  B 20-25%的人會考慮點擊名列11到20的網頁；  C 僅有3-4%的會點擊名列搜索結果中列第21到第30名的網頁 

也就是說，絕大部分用戶是不愿意翻頁去看搜索引擎給出的后面的結果。

而即使在搜索結果的首頁（通常列出的是前10條結果），用戶的點擊行為也很有意思，我們通過下面的Google點擊熱圖（Heat Map）來觀察（這個熱圖在二維搜索結果頁上通過光譜來形象的表達不同位置用戶的點擊熱度。顏色約靠近紅色表示點擊強度越高）：

從圖中可以看出，搜索結果的前3條吸引了大量的點擊，屬于熱度最高的部分。也就是說，對搜蘇引擎來說，最前的幾條結果是最關鍵的，決定了用戶的滿意程度。

康乃爾大學的研究人員通過eye tracking實驗獲得了更為精確的Google搜索結果的用戶行為分析圖。從這張圖中可以看出，第一條結果獲得了56.38%的搜索流量，第二條和第三條結果的排名依次降低，但遠低于排名第一的結果。前三條結果的點擊比例大約為11:3:2 。而前三條結果的總點擊幾乎分流了搜索流量的80%。

另外的一些有趣的結論是，點擊量并不是按照順序依次遞減的。排名第七位獲得的點擊是最少的，原因可能在于用戶在瀏覽過程中下拉頁面到底部，這時候就只顯示最后三位排名網站，第七名便容易被忽略。而首屏最后一個結果獲得的注意力（2.55）是大于倒數第二位的(1.45)，原因是用戶在翻頁前，對最后一條結果印象相對較深。搜索結果頁面第二頁排名第一的網頁（即總排名11位的結果）所獲得的點擊只有首頁排名第十網站的40%，與首頁的第一條結果相比，更是只有其1/60至1/100的點擊量。

因此在量化評估搜索引擎的效果時，往往需要根據以上搜索用戶的行為特點，進行針對性的設計。

P@N的計算方法

P@N本身是Precision@N的簡稱，指的是對特定的查詢，考慮位置因素，檢測前N條結果的準確率。例如對單次搜索的結果中前5篇，如果有4篇為相關文檔，則P@5 = 4/5 = 0.8 。

測試通常會使用一個查詢集合（按照前文所述方法構造），包含若干條不同的查詢詞，在實際使用P@N進行評估時，通常使用所有查詢的P@N數據，計算算術平均值，用來評判該系統的整體搜索結果質量。

N的選取

對用戶來說，通常只關注搜索結果最前若干條結果，因此通常搜索引擎的效果評估只關注前5、或者前3結果，所以我們常用的N取值為P@3或P@5等。

對一些特定類型的查詢應用，如尋址類的查詢（Navigational Search），由于目標結果極為明確，因此在評估時，會選擇N=1（即使用P@1）。舉個例子來說，搜索“新浪網”、或“新浪首頁”，如果首條結果不是 新浪網（url：www.sina.com.cn），則直接判該次查詢精度不滿足需求，即P@1=0

MRR

上述的P@N方法，易于計算和理解。但細心的讀者一定會發現問題，就是在前N結果中，排序第1位和第N位的結果，對準確率的影響是一樣的。但實際情況是，搜索引擎的評價是和排序位置極為相關的。即排第一的結果錯誤，和第10位的結果錯誤，其嚴重程度有天壤之別。因此在評價系統中，需要引入位置這個因素。

MRR是平均排序倒數（Mean Reciprocal Rank）的簡稱，MRR方法主要用于尋址類檢索（Navigational Search）或問答類檢索（Question Answering），這些檢索方法只需要一個相關文檔，對召回率不敏感，而是更關注搜索引擎檢索到的相關文檔是否排在結果列表的前面。MRR方法首先計算每一個查詢的第一個相關文檔位置的倒數，然后將所有倒數值求平均。例如一個包含三個查詢詞的測試集，前5結果分別為：

查詢一結果：1.AN 2.AR 3.AN 4.AN 5.AR  查詢二結果：1.AN 2.AR 3.AR 4.AR 5.AN  查詢三結果：1.AR 2.AN 3.AN 4.AN 5.AR  

其中AN表示不相關結果，AR表示相關結果。那么第一個查詢的排序倒數（Reciprocal Rank）RR₁ = 1/2=0.5 ；第二個結果RR₂ = 1/2 = 0.5 ； 注意倒數的值不變，即使查詢二獲得的相關結果更多。同理，RR₃= 1/1 = 1。 對于這個測試集合，最終MRR=（RR₁+RR₂+RR₃）/ 3 = 0.67

然而對大部分檢索應用來說，只有一條結果無法滿足需求，對這種情況，需要更合適的方法來計算效果，其中最常用的是下述MAP方法。

MAP

MAP方法是Mean Average Precison，即平均準確率法的簡稱。其定義是求每個相關文檔檢索出后的準確率的平均值（即Average Precision）的算術平均值（Mean）。這里對準確率求了兩次平均，因此稱為Mean Average Precision。（注：沒叫Average Average Precision一是因為難聽，二是因為無法區分兩次平均的意義）

MAP 是反映系統在全部相關文檔上性能的單值指標。系統檢索出來的相關文檔越靠前(rank 越高)，MAP就應該越高。如果系統沒有返回相關文檔，則準確率默認為0。

例如：假設有兩個主題：

主題1有4個相關網頁，主題2有5個相關網頁。

某系統對于主題1檢索出4個相關網頁，其rank分別為1, 2, 4, 7；

對于主題2檢索出3個相關網頁，其rank分別為1,3,5。

對于主題1，平均準確率MAP計算公式為：

(1/1+2/2+3/4+4/7)/4=0.83。 

對于主題2，平均準確率MAP計算公式為：

(1/1+2/3+3/5+0+0)/5=0.45。 

則MAP= (0.83+0.45)/2=0.64。”

DCG方法

DCG是英文Discounted cumulative gain的簡稱，中文可翻譯為“折扣增益值”。DCG方法的基本思想是：

1. 每條結果的相關性分等級來衡量
2. 考慮結果所在的位置，位置越靠前的則重要程度越高
3. 等級高（即好結果）的結果位置越靠前則值應該越高，否則給予懲罰

我們首先來看第一條：相關性分級。這里比計算Precision時簡單統計“準確”或“不準確”要更為精細。我們可以將結果細分為多個等級。比如常用的3級：Good（好）、Fair（一般）、Bad（差）。對應的分值rel為：Good:3 / Fair:2 / Bad:1 。一些更為細致的評估使用5級分類法：Very Good（明顯好）、Good（好）、Fair（一般）、Bad（差）、Very Bad（明顯差），可以將對應分值rel設置為：Very Good:2 / Good:1 / Fair:0 / Bad:-1 / Very Bad: -2

評判結果的標準可以根據具體的應用來確定，Very Good通常是指結果的主題完全相關，并且網頁內容豐富、質量很高。而具體到每條

DCG的計算公式并不唯一，理論上只要求對數折扣因子的平滑性。我個人認為下面的DCG公式更合理，強調了相關性，第1、2條結果的折扣系數也更合理：

此時DCG前4個位置上結果的折扣因子（Discount factor）數值為：

i	log2 (i+1)	1/log2 (i+1)
1	1	1
2	1.59	0.63
3	2	0.5
4	2.32	0.43

取以2為底的log值也來自于經驗公式，并不存在理論上的依據。實際上，Log的基數可以根據平滑的需求進行修改，當加大數值時（例如使用log₅ 代替log₂），折扣因子降低更為迅速，此時強調了前面結果的權重。

為了便于不同類型的query結果之間橫向比較，以DCG為基礎，一些評價系統還對DCG進行了歸一，這些方法統稱為nDCG（即 normalize DCG）。最常用的計算方法是通過除以每一個查詢的理想值iDCG（ideal DCG）來進行歸一，公式為：

求nDCG需要標定出理想情況的iDCG，實際操作的時候是異常困難的，因為每個人對“最好的結果”理解往往各不相同，從海量數據里選出最優結果是很困難的任務，但是比較兩組結果哪個更好通常更容易，所以實踐應用中，通常選擇結果對比的方法進行評估。

怎樣實現自動化的評估？

以上所介紹的搜索引擎量化評估指標，在Cranfield評估框架（Cranfield Evaluation Framework）中被廣泛使用。業界知名的TREC（文本信息檢索會議）就一直基于此類方法組織信息檢索評測和技術交流。除了TREC外，一些針對不同應用設計的Cranfield評測論壇也在進行進行（如 NTCIR、IREX等）。

但Cranfield評估框架存在的問題是查詢樣例集合的標注上。利用手工標注答案的方式進行網絡信息檢索的評價是一個既耗費人力、又耗費時間的過程，只有少數大公司能夠使用。并且由于搜索引擎算法改進、運營維護的需要，檢索效果評價反饋的時間需要盡量縮短，因此自動化的評測方法對提高評估效率十分重要。最常用的自動評估方法是A/B testing系統。

A/B Testing

A/B Testing系統

A/B testing系統在用戶搜索時，由系統來自動決定用戶的分組號（Bucket id），通過自動抽取流量導入不同分支，使得相應分組的用戶看到的是不同產品版本（或不同搜索引擎）提供的結果。用戶在不同版本產品下的行為將被記錄下來，這些行為數據通過數據分析形成一系列指標，而通過這些指標的比較，最后就形成了各版本之間孰優孰劣的結論。

在指標計算時，又可細分為兩種方法，一種是基于專家評分的方法；一種是基于點擊統計的方法。

專家評分的方法通常由搜索核心技術研發和產品人員來進行，根據預先設定的標準對A、B兩套環境的結果給予評分，獲取每個Query的結果對比，并根據nDCG等方法計算整體質量。

點擊評分有更高的自動化程度，這里使用了一個假設：同樣的排序位置，點擊數量多的結果質量優于點擊數量少的結果。（即A2表示A測試環境第2條結果，如果A2 > B2，則表示A2質量更好）。通俗的說，相信群眾（因為群眾的眼睛是雪亮的）。在這個假設前提下，我們可以將A/B環境前N條結果的點擊率自動映射為評分，通過統計大量的Query點擊結果，可以獲得可靠的評分對比。

Interleaving Testing

另外2003年由Thorsten Joachims 等人提出的Interleaving testing方法也被廣泛使用。該方法設計了一個元搜索引擎，用戶輸入查詢詞后，將查詢詞在幾個著名搜索引擎中的查詢結果隨機混合反饋給用戶，并收集隨后用戶的結果點擊行為信息．根據用戶不同的點擊傾向性，就可以判斷搜索引擎返回結果的優劣，

如下圖所示，將算法A和B的結果交叉放置，并分流量進行測試，記錄用戶點擊信息。根據點擊分布來判斷A和B環境的優劣。

Interleaving Testing評估方法

Joachims同時證明了Interleaving Testing評價方法與傳統Cranfield評價方法的結果具有較高的相關性。由于記錄用戶選擇檢索結果的行為是一個不耗費人力的過程，因此可以便捷的實現自動化的搜索效果評估。

總結

沒有評估就沒有進步——對搜索效果的量化評測，目的是準確的找出現有搜索系統的不足（沒有哪個搜索系統是完美的），進而一步一個腳印對算法、系統進行改進。本文為大家總結了常用的評價框架和評價指標。這些技術像一把把尺子，度量著搜索技術每一次前進的距離。

---

感謝張凱峰對 本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家加入到InfoQ中文站用戶討論組中與我們的編輯和其他讀者 朋友交流。

轉自：http://www.itivy.com/ivy/archive/2011/11/24/something-that-architecture-must-be-aware-of.html

對于大多數架構師而言，“可擴展性”在軟件架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴展性正是如今軟件設計領域最值得優先考慮的要素。然 而，計算機科學家們還無法了解一套單獨的架構如何才能擴展至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴展性架構，往往以業界較為通用 的已知可擴展模式及個人偏好為標準。簡單來講，打造一套具備可擴展性的系統已經變得更像是一門藝術而不單單是技術。

我們常常會通過觀摩杰作體會并學習藝術的精髓，而可擴展性也應該遵循同樣的路線！

在這篇文章中，我將列出數款為大家所耳熟能詳的可擴展性架構。通常情況下，架構師們完全可以借鑒已知的可擴展架構模式，進而創造出新的可擴展架構。

1. LB (負載平衡器) + 無共享單位 - 該模型中包含一系列單元，各單元彼此間不共享任何內容，且一致指向一個將輸入文訊按一定條件發往單元處的負載平衡器（這構成一個循 環，以負載等情況為基礎）。每個單元可以是一個單獨的節點或是緊密耦合的節點所構成的集群。用戶可以使用DNS循環、硬件負載平衡器或者軟件負載平衡器達 成負載平衡效果。創建一套負載均衡的層次結構，并在其中結合前面提到的各種負載平衡器也是可行的。在由Michael Stonebraker撰寫的《 無共享體系架構實例 》一文中，專門討論了此類架構。
    
2. LB + 無狀態節點 + 可擴展存儲 - 傳統的 三層式Web架構 使用的就是這種模型。該模型包括數個與可擴展存儲交互的無狀態節點以及一個分布于節點間負載中的負載平衡器。在這一模型中，存儲通常作為限制因素存在，但NoSQL存儲則可以利用這套模型創建出具備相當可擴展性的系統。
    
3. 點對點架構 (分布式Hash列表 (簡稱DHT)以及內容尋址網絡(簡稱CAN)) -這套模型提供了一些傳統的 可擴展算法，這些算法的各個方面幾乎全部按對數進行了等比例增加。舉例來說，像Chord、Pastry（特指免費版）以及CAN都屬于此類。而以 Cassandra為代表的、基于P2P架構的幾款NoSQL系統也是其中的成員?！?nbsp;展望P2P系統中的數據 》一文就深入探討了這類模型的各種細節。
    
4. 分布式隊列 – 這種模型以將隊列實施（即先進先出交付機制）作為網絡服務處理為基礎。該模型通過JMS隊列而廣泛得到采用。一般會遵循這種做法的有任務隊列以及通過保持隊列分級體系實現擴展性的任務隊列版本，后者在負載無法及時處理時，任務會由低級層面向高級層面傳遞。
    
5. 發布/訂閱模式 - 一般用于通過網絡向彼此發布訂閱訊息。《 發布與訂閱的多面性 》這一經典論文中詳細的介紹這一模型，該模型方面最典型的例子即 NaradaBroker與 EventJava 。
    
6. 小道消息與自然靈感式模型 - 這種模型源自日常生活中小道消息的傳播途徑，也就是每個節點將隨機選擇后續節點以交 換信息。正如現實生活中的實際反饋，這種八卦型算法在信息傳播方面出奇地迅速。該模型的另一大分支則是受到生物學影響的啟發式算法。自然世界中存在著大量 協調及擴展方面極為卓越的固有算法。舉例來說，螞蟻、人類以及蜜蜂等等，都能夠以最簡潔的交流方式協調好擴展性方面的需要。模型中的算法正是借鑒了這些實 際存在的現象。在論文《 從流行病的蔓延到分布式計算 》中對這種模型有著詳盡的敘述。
    
7. 地圖縮小/數據流 - 這一概念首先由谷歌公司提出，地圖縮小為工作的描述及執行提供了一套可擴展的模式。雖然內容 簡單，但它仍然成為聯機分析處理方面的首要處理模式。數據流則是一種更先進的方式，用來表達執行信息；而像Dryad及Pig這樣的項目為數據流的執行提 供了可擴展的框架。論文《 地圖縮?。捍笮图荷系暮喕瘮祿幚?nbsp;》中設置了專門的主題，詳細討論這一內容。Apache的Hadoop就是這種模型的代表性產品。
    
8. 責任樹形圖 - 這種模型打破了遞歸問題的束縛，將整個流程以樹狀形式加以處理；每個父節點將工作下放至子節點。這種模型擴展性強，并已經被應用于數款可擴展性架構當中。
    
9. 流處理 - 這種模型被用于處理源源不斷的數據流及數據。這種處理方式通過網絡中的處理節點獲得支持（例如Aurora、Twitter Strom以及Apache S4等）。
    
10. 可擴展存儲 – 該模型的應用范圍從數據庫、NoSQL存儲、服務注冊到文件系統都有體現。 鏈接中的這篇文章 以可擴展性為切入點對其進行了深入討論。

綜上所述，可擴展性的實現只有三種方式，即：分布、緩存及異步處理。前文所提到的各種架構事實上都是把這三種方式進行不同組合并加以實施。而另一方 面，不利于可擴展性的因素，除了糟糕的編碼本身，全局性協調也起到了重要的影響。簡單來說，任何一種全局性協調都會限制系統的可擴展性。本文中所提到的各 種架構也只是在做好了本地性協調，而非全局性協調。

然而，將它們有機地結合起來以創建一套極具可擴展性的架構可不像說起來那么容易，除非我們能找到一種全新的擴展模式。不過經驗告訴我們，比起搞一套全新的架構，采用為我們所熟知且更易駕馭的可擴展性解決方案永遠是更好的選擇。

技術型企業即要關注財務指標和交付指標：產出

也要關注貨架建設：技術積累，員工能力的提升和任職資格

 

保證產出的同時，保證技術積累和員工任職資格能力的提升是技術型企業必須解決的難題

 

技術型企業的組織建設的原則：

1、  有利于按產出線和專業分工

    基于產出進行核算

    突出資源線、專業線進行組織設計

 在專業技術領域不增加的情況下，增加項目不增加部門，產出規模的擴展不會帶來組織規模的擴張

2、  有利于建立員工按專業的職業生涯設計，建立個人專業發展方向

3、  有利于對產出按項目 方式進行管理和控制

4、  有利于按產出建立跨部門的團隊，全流程、全要素地進行項目和產品開發

5、  有利于建立委員會對項目進行評審

6、  保證產品經理，市場經理，客戶經理，項目經理在一線，能調動公司所有資源，為產品線能夠快速響應客戶負責

 

組織建設不一定一步到位，但活動必須到位，關鍵人才必須培養

 

技術型企業的活動分類：

 

一、規劃類活動

系統部：產品規劃

系統部：技術規劃

市場部：市場規劃

市場部：客戶群規劃

公司高層：產業鏈管理的規劃

公司高層：資本動作的規劃

公司高層：高層人才的引進計劃和規劃

公司高層：風險管理的評審機制

 

二、產出開發類活動

預研、產品開發、定制項目開發、解決方案

技術開發支撐產品開發

產品開發支撐解決方案開發

三、資源線的管理活動

支撐管理：財務管理，項目管理，質量管理，人力資源管理

支持產出管理：營銷部，產品線管理，市場部

 

典型技術型企業組織結構：

1、  委員會：規劃、評審、決策負責

2、  產出線：對產出負責，按照項目的方式動作

3、  資源線：對人的培養，成長，知識積累和職業通道負責

 

六大分離：

1、  技術開發和產品開發分離

技術體系的核心業務：

(1)    構建技術平臺，形成技術儲備，發現新的技術增長點

(2)    建立技術標準和技術規劃，形成核心技術以主動引導客戶，在技術上領先競爭對手，同步培養優秀的技術人員

產品體系的核心業務：

(1)    以成熟的技術和平臺快速、低成本地滿足客戶要求

(2)    在周期，成本和可靠性及可生產性，可保障性上領先對手，在市場和財務指標上構建核心競爭力

預研體系的核心業務：

(1)    對未來的技術和產品進行探索和研究，形成企業的技術儲備

(2)    提高企業技術領域的影響力

2、  市場體系和銷售體系分離

引導研發和高水平的客戶經理轉入市場部進行市場需求和產品規劃

3、  產出線與資源線分離

4、  決策與職能體系管理及職能體系執行分離

5、  系統設計與實現相對分離

鼓勵公司高手參與規劃和設計，保證研發質量，低水平研發人員從實現積累經驗，逐步上升到系統級工程師，參與設計。避免低手做設計，高手救火的情況發生。

6、  開發與測試和驗證分離

設立獨立的測試部門和驗證部門可以有效的保證產品的質量

 

完整的產出線要素：

1、  面向客戶提供有外部收入或內部轉換收入的項目或產品

2、  從需求到交付統一全程管理

3、  有一個項目總的責任人全程負責

4、  涉及產出的所有元素，研發，銷售，市場，采購，生產及中試測試，以矩陣方式參與并為產出統一服務，由產出線進行統一績效管理

 

產出線五種表現形態：

1、  產品開發項目

2、  預研項目

3、  技術平臺開發項目

4、  定制項目

5、  管理項目：管理體系建設也可以立項，通過項目管理的方式來推進和完成

 

產出線的組織層次分為四層：

決策層：IRB，對項目資源策略負責

管理層：IPMT，對產品的市場成功和財務成功負責

執行層：PDT，對項目從立項到發布負責

維護服務層：LMT，對產品生命周期管理及更改負責

 

產品經理與項目經理的區別

1、  產品經理是一個固定的職位，項目經理是一個臨時性的職位

2、  產品經理管理所有的產品版本，V版本，R版本，M版本，項目經理管理目前的R版本

3、  在新產品開發時，產品經理兼任項目經理

4、  產品經理對產品的全生命周期的管理負責，是例行職位，項目經理對產品開發全過程負責，是一個項目職位

5、  產品規模小時，產品經理兼任項目經理；規模大時，產品經理主要負責老產品推廣，項目經理負責新產品開發，項目經理向產品經理匯報

 

資源經理與項目經理區別：

1、  項目經理對產出負責，資源經理對資源負責，對人的任職資格通道負責

2、  項目經理是臨時職位，負責項目開發，對交付負責；資源經理是固定職位，負責人的培養，專業發展

3、  資源經理是一個資源池的管理者，項目經理從資源經理處承接資源，或委托資源經理承接開發任務

4、  資源經理管理人員的固定績效，項目經理管理人員的變動績效

 

實施矩陣管理必須具備的條件：

1、  企業要具備承諾文化

2、  產品線與資源線劃分合理

3、  單項目管理和多項目管理分離，項目經理管單項目，項目管理部管理多項目

4、  三級計劃體系結構清晰，層次合理

5、  項目流程清晰，大項目可以劃分成多個小項目，實現資源分階段投入和評審

6、  需求管理流程初步實現，保證一段時間內項目需求規劃的準確性

 

矩陣管理三種模式：

強矩陣：參加項目的人直接由項目經理管理

弱矩陣：一個人同時參加兩個以上的項目，匯報給資源經理，抄送給項目經理

混合矩陣：一部分參與強矩陣團隊，一部分參與弱矩陣團隊

 

不是所有的企業都要實施矩陣管理，實施矩陣管理必須完成一些基礎建設

企業典型的考核辦法	缺少的配套措施	導致的結果
平衡記分卡、嚴格的KPI制度	沒有考慮研發過程的難度與風險評估，尤其是技術攻關和技術探索	高手做高風險項目不如低手做低風險項目收益大，無法鼓勵優秀的研發人員創新
實行矩陣管理，對項目進行考核，項目周期長，一個人長期承擔多個項目開發	沒有按階段把大項目規劃成小項目	績效管理工作量巨大，績效管理變成了簡單應付
對研發人員進行強制分布	沒有任職資格建設，沒有規定行為準則，不先對項目進考核	業績好的團隊和業績差的團隊區別不大，影響了業績好的團隊的績效管理
	不進行財務成本考核	研發人員沒有組織績效，只注重個人能力的提升，鉆研新技術，最終企業研發人員能力提升了，但是企業組織績效沒有提高

 

研發績效需要區分以下誤區：

1、  區分組織績效和個人績效，組織績效主要是市場和財務的成功，個人績效必須在組織績效上進行分解

2、  組織績效的首要任務是在老產品改進上的毛利率提升，其次才是新產品、新技術的開發

3、  將預研，產品開發和需求及規劃人員的績效考核進行區分，產品開發人員必須與當年所支撐的產品收入掛鉤，預研人員可以與三年內預研成果轉化成產品成果所帶來的收入掛鉤

4、  研發人員的能力，過程和結果及項目的關鍵點分別以不同的績效手段管理和考核

5、  盡量將項目劃分成一個個階段，減少每個階段的時間，使得一個人在一段時間內盡量承接的項目少，實現精力聚集的同時，減少績效考核的工作量

6、  將產品維護工作與產品開發的工作分開，產品維護的項目按任務數進行考核，產品開發的項目按計劃進度及質量要素考核

7、  建立任職資格，將不同層級的研發人員的考核模式與薪酬結構分開，低層次人員主要考核基本行為規范，中，高級人員的考核應該結合過程考核結果，高層次人員主要考核結果

8、  創新性的預研工作主要考核領軍人物的任職資格

 

績效管理的五種手段：

1、  任職資格：對員工的能力進行評價

2、  行為準則：每一個職位必做的相關工作職位要求活動的基本要求，PI(Performance Indicator)；

3、  PCB：(Personal Business Commitments)主要對員工的過程進行評價，來自年度，季度計劃，必須完成的一些工作

4、  KPI：(Key Performance Indicator)關鍵績效指標，通常對組織進行考核，來自企業的發展戰略財務指標、市場指標及必須要解決的問題，更多的是強調組織績效，強調實現戰略目標的挑戰性指標

5、  KCP：（Key Control Point）對項目關鍵路徑上的關鍵資源的活動進行績效管理，以區分項目成功的貢獻和風險

 

不同層級、不同類別的研發人員的考核手段：

1、  高層管理人員：KPI，KPC和任職資格

2、  預研人員：任職資格、KCP、PBC

3、  產品開發的高級別人員：KPI、任職資格、PBC

4、  產品開發的低級別人員：行為準則、任職資格、PBC

5、  研發體系的職能部門：最好不要考核KPI，主要考核其任職資格和行為準則及PBC

 

薪酬包：

1、  基本工資：任職資格

2、  扣款：行為準則

3、  月度/季度績效資金：PBC

4、  年度績效獎金：KPI

5、  項目特別獎勵：KCP

 

組織績效考核工具是KPI，承接單位為營銷體系，研發體系。

KPI是組織考核工具，個人KPI必須建立在組織KPI的基礎之上。

 

公司級KPI指標通常包括五類指標：

1、  銷售收入及增長率

2、  新業務在銷售中所占的比例

3、  人均創造利潤空間及增長率

4、  核心技術平臺上收入所占比重

5、  核心競爭力提升的四大指標：

(1)    產品收入、利潤收入、區域收入及客戶群收入結構的合理性

(2)    商業模式及產業鏈競爭能力的合理性

(3)    組織層次合理性及人員結構的合理性

(4)    高質量的快速的產品交付能力

 

任職資格管理：某公司的研發人員分級

一、基本條件：經歷，學歷，現職狀況

二、參考項：績效情況，品行

三、資格標準：業務活動，基本素質，知識技能

 

七級
六級	完整的系統方案設計和需求分析的過程
五級	原型設計到工程設計到小批量設計到產品轉產的過程經歷
四級	市場的經歷
三級	技術支持和售后服務的經歷
二級	有測試的經歷
一級

 

KCP管理要點：

1、  是否在關鍵項目的關鍵路徑上

2、  是否要付出個人額外的努力

3、  是否有獨特貢獻

4、  是否是關鍵資源

5、  是否冒一定的風險

6、  是否代表一定的價值導向

 

績效管理結果分布：

工資、職位：對現在的肯定

資金：對過去的肯定

福利、補貼、帶薪休假：公共福利

期權、股票、分紅、培訓、出國考察、導師制、崗位輪換：對未來肯定

技術型企業即要關注財務指標和交付指標：產出

也要關注貨架建設：技術積累，員工能力的提升和任職資格

 

保證產出的同時，保證技術積累和員工任職資格能力的提升是技術型企業必須解決的難題

 

技術型企業的組織建設的原則：

1、  有利于按產出線和專業分工

    基于產出進行核算

    突出資源線、專業線進行組織設計

 在專業技術領域不增加的情況下，增加項目不增加部門，產出規模的擴展不會帶來組織規模的擴張

2、  有利于建立員工按專業的職業生涯設計，建立個人專業發展方向

3、  有利于對產出按項目 方式進行管理和控制

4、  有利于按產出建立跨部門的團隊，全流程、全要素地進行項目和產品開發

5、  有利于建立委員會對項目進行評審

6、  保證產品經理，市場經理，客戶經理，項目經理在一線，能調動公司所有資源，為產品線能夠快速響應客戶負責

 

組織建設不一定一步到位，但活動必須到位，關鍵人才必須培養

 

技術型企業的活動分類：

 

一、規劃類活動

系統部：產品規劃

系統部：技術規劃

市場部：市場規劃

市場部：客戶群規劃

公司高層：產業鏈管理的規劃

公司高層：資本動作的規劃

公司高層：高層人才的引進計劃和規劃

公司高層：風險管理的評審機制

 

二、產出開發類活動

預研、產品開發、定制項目開發、解決方案

技術開發支撐產品開發

產品開發支撐解決方案開發

三、資源線的管理活動

支撐管理：財務管理，項目管理，質量管理，人力資源管理

支持產出管理：營銷部，產品線管理，市場部

 

典型技術型企業組織結構：

1、  委員會：規劃、評審、決策負責

2、  產出線：對產出負責，按照項目的方式動作

3、  資源線：對人的培養，成長，知識積累和職業通道負責

 

六大分離：

1、  技術開發和產品開發分離

技術體系的核心業務：

(1)    構建技術平臺，形成技術儲備，發現新的技術增長點

(2)    建立技術標準和技術規劃，形成核心技術以主動引導客戶，在技術上領先競爭對手，同步培養優秀的技術人員

產品體系的核心業務：

(1)    以成熟的技術和平臺快速、低成本地滿足客戶要求

(2)    在周期，成本和可靠性及可生產性，可保障性上領先對手，在市場和財務指標上構建核心競爭力

預研體系的核心業務：

(1)    對未來的技術和產品進行探索和研究，形成企業的技術儲備

(2)    提高企業技術領域的影響力

2、  市場體系和銷售體系分離

引導研發和高水平的客戶經理轉入市場部進行市場需求和產品規劃

3、  產出線與資源線分離

4、  決策與職能體系管理及職能體系執行分離

5、  系統設計與實現相對分離

鼓勵公司高手參與規劃和設計，保證研發質量，低水平研發人員從實現積累經驗，逐步上升到系統級工程師，參與設計。避免低手做設計，高手救火的情況發生。

6、  開發與測試和驗證分離

設立獨立的測試部門和驗證部門可以有效的保證產品的質量

 

完整的產出線要素：

1、  面向客戶提供有外部收入或內部轉換收入的項目或產品

2、  從需求到交付統一全程管理

3、  有一個項目總的責任人全程負責

4、  涉及產出的所有元素，研發，銷售，市場，采購，生產及中試測試，以矩陣方式參與并為產出統一服務，由產出線進行統一績效管理

 

產出線五種表現形態：

1、  產品開發項目

2、  預研項目

3、  技術平臺開發項目

4、  定制項目

5、  管理項目：管理體系建設也可以立項，通過項目管理的方式來推進和完成

 

產出線的組織層次分為四層：

決策層：IRB，對項目資源策略負責

管理層：IPMT，對產品的市場成功和財務成功負責

執行層：PDT，對項目從立項到發布負責

維護服務層：LMT，對產品生命周期管理及更改負責

 

產品經理與項目經理的區別

1、  產品經理是一個固定的職位，項目經理是一個臨時性的職位

2、  產品經理管理所有的產品版本，V版本，R版本，M版本，項目經理管理目前的R版本

3、  在新產品開發時，產品經理兼任項目經理

4、  產品經理對產品的全生命周期的管理負責，是例行職位，項目經理對產品開發全過程負責，是一個項目職位

5、  產品規模小時，產品經理兼任項目經理；規模大時，產品經理主要負責老產品推廣，項目經理負責新產品開發，項目經理向產品經理匯報

 

資源經理與項目經理區別：

1、  項目經理對產出負責，資源經理對資源負責，對人的任職資格通道負責

2、  項目經理是臨時職位，負責項目開發，對交付負責；資源經理是固定職位，負責人的培養，專業發展

3、  資源經理是一個資源池的管理者，項目經理從資源經理處承接資源，或委托資源經理承接開發任務

4、  資源經理管理人員的固定績效，項目經理管理人員的變動績效

 

實施矩陣管理必須具備的條件：

1、  企業要具備承諾文化

2、  產品線與資源線劃分合理

3、  單項目管理和多項目管理分離，項目經理管單項目，項目管理部管理多項目

4、  三級計劃體系結構清晰，層次合理

5、  項目流程清晰，大項目可以劃分成多個小項目，實現資源分階段投入和評審

6、  需求管理流程初步實現，保證一段時間內項目需求規劃的準確性

 

矩陣管理三種模式：

強矩陣：參加項目的人直接由項目經理管理

弱矩陣：一個人同時參加兩個以上的項目，匯報給資源經理，抄送給項目經理

混合矩陣：一部分參與強矩陣團隊，一部分參與弱矩陣團隊

 

不是所有的企業都要實施矩陣管理，實施矩陣管理必須完成一些基礎建設