博友一根弦留言，說講講《產品經理應該具備的開發知識》瞭解開發人員的工作流程，溝通、協調起來會更加順暢，這回就定制一下這個話題。一般當工程師接到產品開發需求的時候，最直接想知道的幾個問題是：
這個是一款什麼產品?
產品是怎麼樣的一個產品，這個產品的背景的由來是什麼。什麼時候確定下來的?誰確定下來的?我們為什麼要做這做個產品，做與不做對目前有什麼區別。這個產品在整個體系中扮演的角色是?-這個直接讓工程師知道要做的對象是什麼，進而才會有很清晰的概念存在。
這個產品的意義是什麼?
產品的意義在於哪裡，通過開放這個產品能產生什麼?又改變什麼?幫助用戶方面做什麼樣的提升?幫助我們商業層面又有多少的幫助?這個直接決定瞭工程師是不是認可做這個事情的價值，能不能讓他們很興奮、全身心的投入進來做這件事情。
這個產品到底要做哪些事情?
這個產品到底要做哪些事情，幾個關鍵的應用場景、關鍵的應用業務是什麼?哪些事情是最主要預先要解決的?哪些事情是相對不重要的?–這個直接決定瞭工程師是否覺得業務是不是很具體，是不是可以很好從系統的角度去抽象業務，進行系統設計。
這個產品具體的實現邏輯是什麼?
具體實現的邏輯，就是在開發產品的時候，把關鍵業務、主場景、關鍵業務邏輯梳理出來，希望通過什麼樣的方式去實現。這個直接決定瞭工程師可以初步的評估你這個產品方案的可行性，現有框架的對實現邏輯是不是支持，也決定瞭要支撐這個邏輯的實現成本。
這個產品的產品經理是誰?
這個產品經理是誰也是很重要的，產品經理是不是OK?是不是可以好配合?好溝通?產品技術的專業技能怎麼樣?是不是有激情?–這個直接決定瞭工程師是不是喜歡和你打交道，是不是認可你，認可你的產品的一個重要因子。
這個產品需要我們多長時間做出來?
資源總是有限的、大產品分項目做，小產品一個項目開發周期搞定。但是多少時間要做出來，還是非常客觀的一個評估條件。這個直接決定瞭工程師在評估完開發成本後決定是不是缺人要加人進來，是不是需要非常規，敏捷開發等等。
以上這些問題，都是你在給工程師提交需求之前一定要想明白的。第一：如果你自己都想不明白，描述清楚這個產品到底是什麼樣的產品，要做什麼不做什麼，意義在哪裡，具體怎麼做?那勢必給別人的感覺是你沒有想明白，那別人怎麼會相信你，信服你。繼而開足馬力的支持你配合你。
第二、這些問題也是你換位思考的一個方式。產品經理如果一直站在產品經理的視角看問題，那肯定會忽視瞭很多事情的細節、很簡單的工程師也是一群需要尊重需要肯定，喜歡做有挑戰事情的人，你如果都不重視工程師對項目開發的感受，人傢憑什麼要重視你對產品的感受，一樣的道理。
第三、大傢的目標都是要完成目標、有成就感，那麼產品經理就得要多走一步，因為整個事情是圍繞你始終的，你要讓你自己興奮起來，全身心的投入帶動所有工程師全身心的投入。大傢使命一致，這也是很重要的一個方面，絕對不能忽視。
曾經在《產品經理怎麼樣和工程師打交道》一文中有寫過一些相關的跟工程師的理解，大傢有興趣的再回顧一下。接下來步入正題，講一講產品開發人員的相關知識。
產品開發流程，實質上大公司也好、小公司也好大同小異，但是在具體的人員角色的分工上不一樣。一般一個產品需求對接過去瞭，技術部會評估分析需求和工程師的情況，以及項目需要交付的情況，首先會得出需求開發方式、項目參與人員角色。
1、這個產品需求開發量很小，是不是走小需求流程就可以瞭?
2、這個產品需求開發量很大，是不是得走項目流程才可以?
在項目流程角色裡面：還會根據你項目實現的復雜度、困難度的情況，評估需要不需要：
項目經理
需求分析師
構架師
如果不需要，不需要重構，不需要改變環境，隻需要做一些應用的開發、調整，那可能就需要幾個開發的工程師就可以瞭。
其次，工程師隊列確定下來以後，就開始評估項目的目標和范圍，看一下是不是需要把產品需求按照優先級拆分成幾個項目來做。
很簡單的道理，從無到有的產品，一般的開發量都不小，如果一下子上，大傢累死累活搞個半年，還不如3個月一個周期上個雛形，然後1個月1個月慢慢迭代，這也是小步快活的一種靈活策略，也可以允許中途有些需求的變更和調整。
最後評估所需要的測試資源，需要多少測試人員進行測試。
如果說流程的話：需求提交–>需求評估–>項目立項–>項目的kickoff–>項目開發–>測試–>上線。這些具體的去蘇傑的書《人人都是產品經理》去看好瞭，不具體圍繞展開瞭。反正有一點就是說一說敏捷開發。開發有2種模式一種是非並行的開發模式，就是說：A環節好瞭，然後給B進入下一個環節，B好瞭然後又給C，然後C好瞭又進入下一個環節給D
這種模式是流程式開發的模式，反正工程師永遠會說：產品的需求還沒有全部完善，老子死活沒法往下做。然後測試的又說，前面的你們都沒定呢，我們怎麼可能跑到你們前面去。
這樣的開發模式，你想嘛，想快就快不瞭瞭，大傢扯皮的時候比較多。
那另外一種就是並行的開發模式，就是說ABCD不是站在1根軌道上，站在4根軌道上，大傢充分通好氣以後，隻要有一方把一部分東西明確下來以後，下面的人就可以按照這種預定線性往下瞭。這樣的方式非常靈活高效，特別是需要非常著急的去完成一個項目開發的時候。我畫瞭一下流程示意圖，大傢可以和上面的比對一下時間(橫軸為時間)。
不得不說並行開發的模式，現在很多人都喜歡口口聲聲叫他敏捷開發，敏捷開發確實是一個好東西，但是現在大多數情況絕對成瞭被逼出來的產物瞭。時間就這麼多，人就這麼幾個，東西一定要出來。所以大傢沒辦法瞭，不能按照流程出牌瞭，都往前走多瞭一步，於是有瞭協同。
大公司和小公司從本質上沒有啥區別，但是有一點，組織結構不太健全的公司是 產品經理就當策劃、又當UED、又當測試。程序員又當項目經理、又當需求分析師、又當構架師、又當測試。所以項目風險很大的程度上取決於核心程序員的個人修為，反正測試也沒有太多的性能測試，大傢都是使用一下，點撥點撥給你功能使用沒問題就行瞭。因為請求比較少很多時候靠服務器增量還是扛得住。
最後@一根弦：
跟開發溝通、協調的一點我個人的建議是：
1、怎麼讓很多想不明白的問題，讓開發幫你想，幫你得到答案，我覺得是需要考慮一下的。
2、還是要多溝通–女產品經理溝通起來，一般都OK的，工程師怕磨，這一點我是身有體會。
3、溝通、協調的最本質的是：要站在對方的角度考慮問題，流程都是死的，人是活的。
4、隻有知道對方在想什麼?想做什麼?不想做什麼?大傢對待這件事情上到底想要什麼?不要什麼?你的操作空間才會更大。
–以上僅僅是站在執行層面的一點個人觀點，也歡迎大傢更正補充。大傢想瞭解什麼，我也可以根據大傢的需求定制哈哈，貌似很偉大。裝瞭%￥#。
作者：費傑_苦力強狒狒
文章來源：kuliqiang.com