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