轉載【我了解的産品經理】

博友一根弦留言，說講講《産品經理應該具備的開發知識》了解開發人員的工作流程，溝通、協調起來會更加順暢，這回就定制一下這個話題。一般當工程師接到産品開發需求的時候，最直接想知道的幾個問題是：

這個是一款什麼産品？

産品是怎麼樣的一個産品，這個産品的背景的由來是什麼。什麼時候确定下來的？誰确定下來的？我們為什麼要做這做個産品，做與不做對目前有什麼差別。這個産品在整個體系中扮演的角色是？—-這個直接讓工程師知道要做的對象是什麼，進而才會有很清晰的概念存在。

這個産品的意義是什麼？

産品的意義在于哪裡，通過開放這個産品能産生什麼？又改變什麼？幫助使用者方面做什麼樣的提升？幫助我們商業層面又有多少的幫助?—這個直接決定了工程師是不是認可做這個事情的價值，能不能讓他們很興奮、全身心的投入進來做這件事情。

這個産品到底要做哪些事情？

這個産品到底要做哪些事情，幾個關鍵的應用場景、關鍵的應用業務是什麼？哪些事情是最主要預先要解決的？哪些事情是相對不重要的？–這個直接決定了工程師是否覺得業務是不是很具體，是不是可以很好從系統的角度去抽象業務，進行系統設計。

這個産品具體的實作邏輯是什麼？

具體實作的邏輯，就是在開發産品的時候，把關鍵業務、主場景、關鍵業務邏輯梳理出來，希望通過什麼樣的方式去實作。—這個直接決定了工程師可以初步的評估你這個産品方案的可行性，現有架構的對實作邏輯是不是支援，也決定了要支撐這個邏輯的實作成本。

這個産品的産品經理是誰？

這個産品經理是誰也是很重要的，産品經理是不是OK？是不是可以好配合？好溝通？産品技術的專業技能怎麼樣？是不是有激情？–這個直接決定了工程師是不是喜歡和你打交道，是不是認可你，認可你的産品的一個重要因子。

這個産品需要我們多長時間做出來?

資源總是有限的、大産品分項目做，小産品一個項目開發周期搞定。但是多少時間要做出來，還是非常客觀的一個評估條件。—這個直接決定了工程師在評估完開發成本後決定是不是缺人要加人進來，是不是需要非正常，靈活開發等等。

以上這些問題，都是你在給工程師送出需求之前一定要想明白的。第一：如果你自己都想不明白，描述清楚這個産品到底是什麼樣的産品，要做什麼不做什麼，意義在哪裡，具體怎麼做？那勢必給别人的感覺是你沒有想明白，那别人怎麼會相信你，信服你。繼而開足馬力的支援你配合你。

第二、這些問題也是你換位思考的一個方式。産品經理如果一直站在産品經理的視角看問題，那肯定會忽視了很多事情的細節、很簡單的工程師也是一群需要尊重需要肯定，喜歡做有挑戰事情的人，你如果都不重視工程師對項目開發的感受，人家憑什麼要重視你對産品的感受，一樣的道理。

第三、大家的目标都是要完成目标、有成就感，那麼産品經理就得要多走一步，因為整個事情是圍繞你始終的，你要讓你自己興奮起來，全身心的投入帶動所有工程師全身心的投入。大家使命一緻，這也是很重要的一個方面，絕對不能忽視。

曾經在《産品經理怎麼樣和工程師打交道》一文中有寫過一些相關的跟工程師的了解，大家有興趣的再回顧一下。接下來步入正題，講一講産品開發人員的相關知識。

産品開發流程，實質上大公司也好、小公司也好大同小異，但是在具體的人員角色的分工上不一樣。一般一個産品需求對接過去了，技術部會評估分析需求和工程師的情況，以及項目需要傳遞的情況，首先會得出需求開發方式、項目參與人員角色。

1、這個産品需求開發量很小，是不是走小需求流程就可以了？

2、這個産品需求開發量很大，是不是得走項目流程才可以？

在項目流程角色裡面：還會根據你項目實作的複雜度、困難度的情況，評估需要不需要：

項目經理

需求分析師

構架師

如果不需要，不需要重構，不需要改變環境，隻需要做一些應用的開發、調整，那可能就需要幾個開發的工程師就可以了。

其次，工程師隊列确定下來以後，就開始評估項目的目标和範圍，看一下是不是需要把産品需求按照優先級拆分成幾個項目來做。

很簡單的道理，從無到有的産品，一般的開發量都不小，如果一下子上，大家累死累活搞個半年，還不如3個月一個周期上個雛形，然後1個月1個月慢慢疊代，這也是小步快活的一種靈活政策，也可以允許中途有些需求的變更和調整。

最後評估所需要的測試資源，需要多少測試人員進行測試。

如果說流程的話：需求送出–>需求評估–>項目立項–>項目的kickoff–>項目開發–>測試–>上線。這些具體的去蘇傑的書《人人都是産品經理》去看好了，不具體圍繞展開了。反正有一點就是說一說靈活開發。開發有2種模式一種是非并行的開發模式，就是說：A環節好了，然後給B進入下一個環節，B好了然後又給C，然後C好了又進入下一個環節給D……

這種模式是流程式開發的模式，反正工程師永遠會說：“産品的需求還沒有全部完善，老子死活沒法往下做。“然後測試的又說，前面的你們都沒定呢，我們怎麼可能跑到你們前面去。

這樣的開發模式，你想嘛，想快就快不了了，大家扯皮的時候比較多。

那另外一種就是并行的開發模式，就是說ABCD不是站在1根軌道上，站在4根軌道上，大家充分通好氣以後，隻要有一方把一部分東西明确下來以後，下面的人就可以按照這種預定線性往下了。這樣的方式非常靈活高效，特别是需要非常着急的去完成一個項目開發的時候。我畫了一下流程示意圖，大家可以和上面的比對一下時間（橫軸為時間）。

不得不說并行開發的模式，現在很多人都喜歡口口聲聲叫他靈活開發，靈活開發确實是一個好東西，但是現在大多數情況絕對成了被逼出來的産物了。時間就這麼多，人就這麼幾個，東西一定要出來。是以大家沒辦法了，不能按照流程出牌了，都往前走多了一步，于是有了協同。

大公司和小公司從本質上沒有啥差別，但是有一點，組織結構不太健全的公司是 産品經理就當策劃、又當UED、又當測試。程式員又當項目經理、又當需求分析師、又當構架師、又當測試。是以項目風險很大的程度上取決于核心程式員的個人修為，反正測試也沒有太多的性能測試，大家都是使用一下，點撥點撥給你功能使用沒問題就行了。因為請求比較少很多時候靠伺服器增量還是扛得住。

最後@一根弦：

跟開發溝通、協調的一點我個人的建議是：

1、怎麼讓很多想不明白的問題，讓開發幫你想，幫你得到答案，我覺得是需要考慮一下的。

2、還是要多溝通–女産品經理溝通起來，一般都OK的，工程師怕磨，這一點我是身有體會。

3、溝通、協調的最本質的是：要站在對方的角度考慮問題，流程都是死的，人是活的。

4、隻有知道對方在想什麼？想做什麼？不想做什麼？大家對待這件事情上到底想要什麼？不要什麼？你的操作空間才會更大。

–以上僅僅是站在執行層面的一點個人觀點，也歡迎大家更正&補充。大家想了解什麼，我也可以根據大家的需求定制哈哈，貌似很偉大。裝了%￥#。

本文作者: 費傑　

發表日期: 2010-07-18

文章連結: 産品經理應該具備的開發知識

關 鍵 詞 : 産品經理, 處世之道, 職業素養