第一篇：it產品經理的工作職責
IT業產品經理必備的七項素質
貌似現在一個很常見的IT業新職位就是產品經理，很多大牛都自稱產品經理，不過它確實是一個對個人綜合素質要求非常高的職位，人稱“產品靈魂的設計師”。有志于成為優秀產品經理的朋友來看看下列哪些方面的能力可以幫助你更好地朝自己理想中的狀態邁進。
一、溝通能力
成功的產品經理必須是優秀的溝通者。
從我所認識的優秀產品經理們分析來看，他們所具有的最共同特征是“在工作中具有優秀的口頭及書面溝通技巧”。
為什么溝通很重要?在許多公司，產品經理最為一個決定性角色扮演著溝通樞紐的角色，如下圖所示。
而在不同角色間有效溝通能力，往細了說，就是與不同的個性類型溝通的能力，即在用不同角色溝通的時候講不同的“語言”。對于有效溝通來說，重要的是你使用目標聽眾的“語言”。
例如，大多數工程師傾向于是“內向型”，而大多數銷售/市場專員傾向于“外向型”。這意味著，與工程師溝通相較而言，和市場專員溝通時需要使用“另一種語言”。同樣地，當你和主管溝通時，相對于“樹的級別”而言，你必須把更多的表述重點放在更高層次的“森林級別”，然而許多產品經理卻錯誤的依然跟主管們在談論著這顆樹是多么的美麗。
二、沒有權力的領導
成功的產品經理擁有在沒有正式的權力下也能成為優秀的領導的能力。
多數公司，產品經理被期望在多個領域扮演“領導角色”。這包括領導項目團隊，領導產品策劃和路線圖，領導跨部門溝通等。
然而，在多數這樣的情況下產品經理并沒有統籌這些部門的權利。
沒有權力如何領導別人?我想說，使用聯合影響，談判，關系網和其他類似技巧。
沒有權力是否可能領導?我對此的想法被這個問題總結的很好，我的回答是個反問：甘地和馬丁·路得金有多少權力?
三、學習技巧
這點，用我個人的話來說，就是優秀的產品經理擅長做不擅長的事。
優秀的產品經理必須具備快速學習的能力，市場變化很快，新技術總是拔地而起。“差異化產品”在今天不到6個月內產生，有時甚至更快。
我認為多數公司在雇傭產品經理時會犯的一個錯誤是-他們看重“強悍的專業知識”。
舉個例子，一個做軟件安全的公司，他們尋找一位擁有5年以上軟件安全方面工作經驗的產品經理。我認為這是一個錯誤的方法。相反，51230.com的邵光榮老大哥就說過，他們產品部門招人，反而都是新手優先，因為怕過多的經驗會限制創新能力和個性發揮，這也難怪，人家做的就是充滿個性的婚戀網站。
當然，更好的方法是，尋找一個擁有適當工作經驗的產品經理，并且擁有快速學習的能力。這種方法對我來說實現的很好，我手下那些最好的產品經理在被雇傭以前，都沒有他現在所從事工作的專業知識。
四、商業敏銳度
成功的產品經理對基本的商業原則也有很好的理解。
他們了解如何辨認市場機會，競爭分化的重要性，創造成功產品的策略，定價，促進，合作，分析，聲明，及其他。
這并不意味著他們需要工商管理碩士學位。實際上，我接觸過的多數成功的產品經理并沒有工商管理碩士，但是他們對商業基本原則都有著充分的了解。
五、熱愛產品
成功的產品經理對產品有一種固有的愛。
他們因跟上市場上新產品的步伐而高興，和他們的到手的一樣多。他們注冊了大量的“betas”網站，下載最新版本的軟件并使用，等等。
他們為設計好的產品而高興，即便并不是他們公司制造的。他們討厭設計糟糕的產品，即便是自己公司制造的。
他們熱愛創造偉大的產品，無論它是一個全新的產品，還是改進現有產品。
六、關注細節
任何事務是由細節組成的，關注細節,是創造偉大產品的必要基礎。
SteveJobs曾經說過：
iMac不僅僅是顏色或是半透明或是外殼的形狀。iMac的本質是使每一個元素集中在一起成為最出色的消費電腦。在我們最新的iMac，我堅定我們擺脫了風扇，因為使用一個不會一直嗡嗡作響的電腦工作讓人更愉悅。
扔掉風扇不僅是Steve一個固執的決定那么簡單，他背后需要一個巨大的工程，計算出如何更好的處理電源功耗，以及如何更好的通過機器散熱。這是我們產品出發的核心點，顧客購買我們，就是為了讓我們去解決所有這些細節，所以他們容易和喜歡使用我們的電腦。
成功的產品經理觀注細節不僅僅是提到產品性能，并且在競爭力分析，項目計劃，和幾乎每個他們主要負責的活動。
我的話：同樣，這種細節體現在你所做的報告中、計劃中、任務策劃書中。在內容上，請盡可能的描述到實施細節;在表現上，請盡可能的體現一個產品設計師的UI設計細節。如果一個連報告都不能讓人愉快閱讀的產品經理，怎么指望做出來的產品能有優秀的用戶體驗。
七、常規的產品管理技能
一個產品經理需要這些技巧來完成日常任務。他們包括寫市場分析報告和需求分析報告，執行競品分析，創造產品路線，陳述產品性能和利益，定義用戶界面，等等。
每個公司都需要這樣的技能。這一技能放在最后，是因為我認為擁有上述六點的產品經理很容易學到這些技能。
總結
也許這七項素質還不夠，那就通過學習能力去學習更多吧，無論是專業素養還是個人成長，學習和提升從來都是無止境的。
第二篇：IT產品銷售人員的溝通技巧
作為優秀的銷售人員，僅僅能夠識別、辨認人們的溝通風格還遠遠不夠;要提高溝通效率，提升銷售業績，還必須學會溝通中的一些溝通技巧。盡管不同的銷售人員，對于不同的溝通技巧敏感性不同，但是，掌握一些具有共性的溝通技巧依然十分重要。獨具一格的富有個人魅力的溝通風格往往離不開嫻熟的溝通技巧的錦上添花，從而促成銷售溝通成為一種愉快、輕松與活潑的交流體驗。
個性化的溝通技巧包含語言和非語言方面的溝通技巧。語言方面的溝通技巧包含傾聽、應答、積極交流等;非語言方面的溝通技巧則內容比較豐富，包含副語言、表情、目光、體姿、服飾與發型等。
雖然在銷售溝通過程中，語言溝通常常占到了主導的地位，但是脫離了非語言的配合，僅僅依靠語言媒介的信息傳播，難免會使人感到詞不達意或言過其實，僵硬呆板，缺乏一種幽默、生動或真情流露的情境。不過，非語言行為也很難獨立擔當起信息傳遞與人際溝通的功能，它們往往起著輔助、配合和強化語言的作用。因此，有效的銷售溝通總是語言溝通與非語言溝通的合二為
一、天衣無縫的一種自然融合。 語言溝通
語言溝通是人們借助于口頭語言或書面文字所進行的一種信息交流，它起到一種方向性和規定性的作用?？陬^語言溝通包括交談、報告、演講、談判、電話聯絡等形式;書面文字溝通包括通知、報告、文件、備忘錄、會談紀要、協議等形式。前者溝通形式靈活、生動，反饋迅速;后者溝通形式正式、規范，具有嚴肅性、權威性，能夠保證信息交流的準確性和保存的長期性等優勢?，F實中的銷售溝通，往往是前期口頭溝通居多(討論客戶需要、需求，談判雙方交易條件等)，后期是書面溝通居多(將前期討論、談判確定下來的需要、需求以及交易條件等以書面文字的形式描述出來存檔，以備需要時查驗等。
1.傾聽與應答
優秀的銷售人員一定是一個出色的傾聽者。當客戶提出問題時，他一定是去傾聽而不是去指導，去理解而不是去影響，去順應而不是去控制。不過，事實上大部分的銷售人員都不是優秀的銷售人員，因為他們不是出色的傾聽者，造成這種現象的原因就是心理定勢，即認為傾聽是被動的。他們認為要想銷售成功，就是要想方設法說服客戶，因此，他們認為與客戶溝通就必須努力說、努力講、努力去證明或證實。實踐表明，要在銷售溝通中與客戶建立良好的合作關系，銷售人員首要的是應該學會傾聽，傾聽客戶的需要，傾聽客戶的深層需求;同時向客戶傳遞這樣一種信息：我并不總是贊同你的觀點，但是尊重你表達自己觀點的權力。這就是人員銷售中的“先迎合、再引導”原則。
欲成為一個優秀的銷售人員，就應該經常主動地與客戶進行交流溝通，在集中精力傾聽客戶需要、需求的情況下作出積極的反饋與應答。對客戶的反饋與應答包括表現出注意聽講的身體語言，發出一些表示注意聽講的聲音或順應地提出問題等諸多細節。不過，在作出反饋或應答時，應避免人為產生的一些偏差，比如夸大或低估、過濾或添加、搶先或滯后、分析或重復等。
2.積極交流
掌握并善于使用積極交流的技巧，對于銷售人員來說具有莫大的助益。首先，成功地促使他人改變態度和行為的原則是既要解決問題，又要不傷害雙方的關系或對方的自尊。因此，措辭是否恰當是非常關鍵的，而采用恰當的措辭是積極交流的前提。其次，在積極交流的過程中，要善于使用“換擋”的技巧，即銷售人員和客戶(發送者和接收者)的角色互換，積極鼓勵對方將想說的說出來，當客戶表述的時候，銷售人員
要仔細傾聽;當客戶準備傾聽時，銷售人員又要盡快轉而闡述自己的思想、觀點和情感。“換擋”技巧對于銷售人員的好處在于使客戶愿意聽你講;從客戶的“訴說”中了解與掌握其不滿意和反駁的理由;給客戶提供一個暢所欲言的場所等。最后，積極的交流還要求銷售人員在銷售前主動與客戶接觸，在銷售后主動與客戶保持聯絡。
非語言溝通
非語言溝通是借助于人們的語音、語調、表情、目光、體姿等肢體語言所進行的信息交流。盡管語言溝通起到的是一個方向性和規定性的作用，但是，事實上非語言溝通才準確地表達了傳遞信息的真正內涵。概括地說，非語言行為在信息溝通中不但起到了支持、修飾或否定語言行為的作用，而且在某些情況下，還可以直接替代語言行為，甚至反映出語言行為難以表達的思想情感。
1.副語言
副語言是指說話的語音、語調、語氣等，比如語音低沉、穩健或激昂、高亢等，語調的高低，語氣的輕重，節奏的快慢等，它們伴隨著語言表達信息的真正含義，因而副語言與語言之間的關系非常密切。研究發現，副語言尤其能表現出一個人的情緒狀況和態度，影響到人們對信息的理解以及交流雙方的相互評價。
2.表情
表情是人類在進化過程中不斷豐富和發展起來的一種輔助交流手段。表情不僅能夠傳遞個人的情緒狀態，而且還能夠反映出一個人的喜、怒、哀、樂等內心活動。
3.目光
目光是非語言溝通的一個重要通道，“眉目傳情”就是一種很好的說明。事實上，在人際交流溝通中，有關溝通雙方的許多信息，都是通過眼睛去收集和接收的。目光，作為一種非語言信號，銷售人員使用目光可以向溝通對象傳遞肯定、否定的態度，質疑或認同等情感信息。在人員銷售的溝通中，銷售人員要善于使用目光，如用目光來表示贊賞或強化客戶的語言或行為，用目光來表示困惑等。
4.體姿
所謂體姿，就是指人們在交流溝通過程中所表現出來的身體姿勢。比如前傾、后仰、托腮沉思等狀態或姿勢。研究表明，無論多么老練、深沉的溝通，人們對待他人的態度都很難在體姿上給予掩蓋或隱藏。雖然體姿不能完全表達個人的特定情緒，但它能反映一個人的緊張或放松程度。因此，銷售人員若能準確識別并判斷不同體姿透露出來的不同信息，對于促成銷售，提升銷售業績具有極大的幫助。
5.服飾與發型
個人儀表，尤其是銷售人員的服飾和發型是其溝通風格的延伸與個性的展示。有研究顯示，服飾的重要性，甚至成了銷售人員通向成功之路的決定性因素之一。人們普遍認為，著裝正式不僅是職業化的表現，更是對客戶的尊重。此外，銷售人員還需要關注自己的發型，來自對客戶的抽樣調查認為，銷售人員的發型不宜過于個性化與時髦、前衛，否則會給客戶留下一個過于超前而顯得不太穩重的印象。因此，銷售人員通過其服飾與發型等外表所傳遞的非語言信息應該是積極、進取、熱情、開朗、沉穩、健康的，這樣才容易獲得客戶的認同。
6.肢體語言
對消費行為的深入研究發現，銷售溝通過程中，客戶一般會通過三種肢體語言來傳遞非語言信息，表明對銷售人員的傳遞的信息持反對、猶豫還是接受的態度。這三種肢體語言就是面部表情、身體角度和動作姿勢。表1列舉了客戶持不同態度下的三種肢體語言的表現形式。銷售人員熟知這些肢體語言，對于把握客戶購買心理，審時度勢作出銷售決策至關重要。
需要強調的是，雖然大多數肢體語言的含義明顯且明確。但銷售人員務必需要分清楚的是客戶的肢體語言是其溝通過程中的一個組成部分，且是伴隨著客戶一連串的語言溝通中的一部分非語言暗示，銷售人員切勿斷章取義，但也不能熟視無睹。銷售人員需要隨時捕捉這些微小的非語言信號，并結合整個溝通過程進行正確地“翻譯”或“解碼”。
溝通中的障礙與潤滑劑
1.溝通中的障礙
有效的溝通技巧，需要巧妙地避免溝通中出現的這樣或那樣的溝通障礙。所謂溝通中的障礙，就是指信息在溝通過程中遭遇諸如環境噪音等因素所導致的信息失真(放大、縮小、偏離)或停止(中斷)等現象。引發信息溝通障礙的不僅有信息發送者的因素，也有信息接收者的因素，此外更可能是傳播介質(傳播通道或載體)方面的原因。表
2、表3分別列舉了信息發送者和信息接收者常見的溝通障礙及其表現。銷售人員熟知這些溝通中的信息障礙并努力避免這些障礙有助于提高溝通效率。
2.溝通中的潤滑劑
積極的溝通不僅是有效銷售的前提，而且也是銷售人員將公司的理念與價值觀、產品與服務、公司品牌與形象等向客戶傳遞、傳播和擴散的過程。積極溝通少不了溝通中的潤滑劑。溝通中的潤滑劑不僅能夠幫助調節溝通氛圍，在某種程度上，它還可以促進溝通雙方對溝通問題的理解與認識。表4列舉了銷售過程中常常用到的溝通潤滑劑。銷售人員掌握這些潤滑劑對于提高自身的溝通技能大有裨益。
第三篇：產品經理的主要職責
在《啟示錄》中，主要對產品經理的主要職責進行了二項分類：
1、評估產品機會
產品的需求來源很多，可能是高層的意見，可能是市場用戶的反饋，可能是產品團隊的點子，也有可能是專業人士的分析，而這些點子總是會摻雜部分偽需求和不占大多數的個體需求，需要有人來進行統一的審核和取舍，也就是常說的對產品做減法。 在初期只專注于產品的核心需求，產品經理就是負責這項工作的人，這項工作也是產品經理工作的重中之重，這項工作是在產品的概念化階段完成的,交付產物為《商業需求文檔(BRD)》、《市場需求文檔(MRD)》。
2、定義要開發的產品
當評估產品機會結束以后，如果得出的結論是產品依舊可以開發，那么就要有人來將這個概念化階段的需求功能點，轉換成UI設計師、開發人員、高層能看懂的產品模型。
主要工作是制作產品的線框圖(axure即可完成)和主要復雜功能的流程圖(例如：支付流程圖-visio即可完成)，在完成原型之后，邀請目標用戶，對原型進行可用性測試，驗證自己的想法能得到用戶的積極反饋。
在這一階段，產品團隊的交付產物應該是《產品需求文檔(PRD)》(不一定是word格式，現在提倡的在axure中進行批注是一個不錯的方法)，這一階段完成之后，產品就進入了開發階段，產品團隊要做的保證開發的順利進行和開發出正確的產品。
《啟示錄》這本書中對產品經理的主要職責，進行了以上兩大類，并沒有將產品經理的其他細化職責歸并到大類中，如果就這樣結束，估計很多人會吐槽，因為現實中對產品經理的工作定位，遠遠超過了以上2點，于是網上有一種從產品的生命管理周期來對產品經理職責進行劃分定位的方法，如下圖1-1：
產品的生命管理周期分為： 概念化階段 ------評估產品機會 產品化階段-------定義要開發的產品
開發階段---------協調資源、保證開發進度，確保開發出正確的產品
商業化階段-------與運營和市場團隊合作，制定推廣策略和產品宣傳方案
市場化階段-------與客服部門溝通，了解用戶反饋，升級產品，評估2.0產品機會，循環
進入第一階段
圖 1-1 產品經理職責
從產品生命管理周期來定位產品經理職責的話，可以分為五個階段的職責，如上圖1-1所示，每個階段產品經理的工作職責側重點不同，在開發階段確保開發進度和開發質量，商品化階段和市場化階段，產品經理主要的工作是協調公司資源，推進產品進度，了解產品反饋，制定產品推廣策略，而這幾點都建立在和其他部門的相互配合上，統一可以稱之為推動產品目標的實現。
個人總結：從產品生命管理周期來定義產品經理職責比較明確，如果將開發階段、商品化階段和市場化階段的職責進行抽象化，產品經理的職責也可以在原有《啟示錄》作者觀點上的基礎上抽象為四大類：
1、評估產品機會
2、定義要開發的產品
3、協調資源、推進確保開發出正確的產品
4、協助各部門，推動產品目標的實現
產品需求的4層關系
互聯網產品需求，其實跟以前我們做開發的軟件需求基本是類似的，我也不知道是不是大家從那里搬過來的，暫且不考究這個。今天說下產品需求的4層關系; 首先先說是哪4層： 1. 業務需求 2. 用戶需求 3. 功能需求 4. 系統需求 看官別著急，單獨拉出來一個系統需求是有原因的，如果你不是三五年內的小白產品應該能看懂。
業務需求(business requirement)
什么是業務需求?我覺得是Business Analysis， 就是所謂的
BA吧。不過現在大多數boss或者說創業者不懂這里面具體都是點什么，百度給的定義其實也不是特別的精準，倒是找到一個文庫內容，關于業務分析師的定義
這里介紹的很精準。好吧，簡單的說業務需求是方案范圍，經營范圍，或者項目范圍。業務分析的東西其實就是一種需求的尋找。 舉著栗子說：
業務需求就是寫出來，我們是做什么的，電商?還是社交?還是其他平臺?我們是不是垂直的，線上的還是線下的?我們依賴什么盈利?我們的業務方向怎么發展?
到這里都是業務需求。
業務的需求往往來自boss或者創業的小老板再或者是你們的某個高層領導。專業一些的會有一些大牛給出商業或者業務分析報告給你。更強有力一些。比自己覺
得做哪個好要靠譜很多 。當然我現在講的是互聯網，其實很多東西都是通用的。 用戶需求(user requirement)
用戶需求在互聯網中的表現大多是在各種場景下，用戶想做某件事情所遇到的問題，或所想滿足的欲望。用戶需求前期是對比，后期是體驗。
在軟件中的用戶需求則不是，軟件用的用戶需求是在場景下用戶的目標以及能完成的東西是什么。這里需要大量的用例，跟場景描述。
用戶需求直白的說就是，你的業務規劃，有沒有人鳥你，大家對這個事兒咋看，你能幫他們解決啥問題等等。其實還是為了確認project scope 是不是正確的 ，有木有搞頭。 功能需求(functional requirement)
功能需求是為了滿足業務跟用戶而制定的。也就是說，在你的業務需求出來之后，你要滿足用戶在你這個產品上怎么實現自己的任務。業務需求都包括什么呢?或者說細化到哪一步了呢? 舉個栗子：做電商要有購物車，要有商品發布。好的，那購物車里面的功能具體是什么，怎么展示?你可能要細節的寫出來，購物車可以批量結賬，要有一個 單價疊 加的計算，如果有打折，可能還有其他的運算;
商品發布，參數都有哪些，發圖片、名稱、商品描述、顏色、類型等，如果你是一個很有經驗的產品人，在這一步你能為前端跟猴子省下很多很多時間。 系統需求(system requirement) 為什么把這個單獨拿出來了，是因為在每個需求下都會牽扯到這個系統需求。在軟件中是架構師的責任，在互聯網中可以是項目經理、產品經理、技術總監共同完成 的東西。因為它包含的東西太多了，而且過于繁瑣與復雜。那什么是系統需求 ? 系統需求是數字控制。還是舉栗子說：
在開發過程中，產品時要反復跟各個部門打交道跟交流的，前端、設計、猴子、項目經理、boss。但是有一點，你必須要出的東西其中有一項叫數據字 典，這個 程序員幫不了你。
比如你的用戶名長度，猴子的思維是，我的是string，長度你隨意，前端的世界是，正則判斷下不要亂七八糟的符號就好了，然后不要超過樣式的寬度或者超
過了也沒事兒我給隱藏了。 那請問，用戶名到底要多長? 區間是什么?
這就是系統需求的一部分，因為你要合理的寫出來賬號，介紹，密碼，描述，等等等等之類的一切能鍵入的規則，你以為這樣就完了嗎?
再深化一些，你要跟運營部或者市場部，估算出用戶成長，在什么時候達到一個什么活躍度等相關數據，以便猴子們可以分庫分表或者早點做防備，可能會有人問，
為啥當初不分好呢?
要是當初能分好，阿里巴巴就不用去請oracle的團隊來架構自己的數據庫了，當井噴的時候你根本想不到是什么時間，所以這些必要的措施跟部署也是需要產
品人來參與的，這會直接影響到產品跟用戶的。 如果你做的不合理，你的規劃不好，那用戶的體驗就沒有了。 說案例：
你的社交功能需求跟業務需求寫，客戶瀏覽自己個人中心的時候會加載很多推送，這一頁的數據加載量很多，有可能認識的，可能感興趣的之類的，好的。沒有什么
經驗的猴子可能就直接捅給你數據了，功能實現了沒錯，首頁加載慢的要死。如果你能寫出來，這里會跨表，跨庫，需要一個沉余或者緩存數據表，要不就用分布式
部署來解決。那猴子們會不會能完美的解決東西?
有人說，我是個產品經理，我不懂技術。好吧，你大大小小也是個經理不是么?你的任務就是給公司減少難題解決問題的不是么? 經理也是個管理者不是么?你要操心的問題還有很多，你要涉獵的東西還很多，你的知識面也需要很廣。這樣你才能是一個合格的產品人。 舉報
第四篇：職場培訓 產品經理的職責
產品經理的職責
產品經理類似于一個剛啟動的公司的首席執行官，他將業務計劃呈現給PAC，保護該開發項目的資金。PDT領導對提交的新產品包負完全的責任。通常產品經理在一個或多個功能領域既有管理層又有操作層經驗，并有管理過開發項目的經歷。產品經理可以來自財務、R&D、市場、制造、技術支持或采購的任何功能領域。產品經理組織項目開發團隊，對團隊的結果負領導責任并代表整個團隊的利益簽定提供產品包的計劃合同。產品經理富有項目管理經驗很重要，應有項目經理的任職資格證書。
產品經理管理項目計劃進度、預算、人員配置、資源和報告的制定，他/她負責創建和維護集成的項目文件，評估并管理項目風險，綜合決策點材料包和建議書并呈現給PAC做投資決策和評審。
產品經理的職責包括：
1.
建立、支持和領導PDT核心團隊
2.
將產品開發作為業務管理系統來用，以驅動跨功能部門的產品開發計劃和執行
3.
確保財務、開發、制造、技術支持、采購、市場行銷和銷售計劃是互相耦合的
4.
為所開發產品包制定和管理跨功能部門的計劃
5.
從PAC獲得承諾
6.
確認和管理所開發的產品包及跨功能部門的依賴性
7.
與PAC共同工作確保所需要的資源的到位
8.
制作和綜合項目交付件、預算和時間進度承諾，如項目管理
9.
管理所開發產品包的贏利和虧損
10.
啟動項目和保持項目正常溝通
11.
當無法達成一致時做出決策
12.
對整個項目準備工作分解結構圖
13.
召集PDT核心組針對項目任命和期望值做溝通
14.
將項目職責分配到PDT核心組成員個人
15.
指導項目操作員(POP)建立項目環境、模板、文件等
16.
需要時借調額外的團隊成員
17.
指導PDT核心團隊成員同時制定其相應的功能部門的策略和他們各自的WBSs(Work
Breakdown
Structures)
18.
在概念階段和計劃階段，領導核心組共同合作優化/細化項目WBS到不同的層次
19.
將所要提供的產品包的高層路標圖固定下來
20.
共同合作將各功能部門的策略集成進業務計劃及該項目的建議書的制作中
21.
在概念、計劃和可獲得性決策檢查點做指導
22.
作出各DCP的日程安排及將業務計劃和建議提交和呈現給IPMT的時間表
23.
制定和維護項目計劃，確保根據時間表、預算和規格說明書執行各類活動
24.
保證項目完成及業務目標實現
25.
管理由PDT核心組成員履行的處于關鍵路徑上的活動
26.
收集和以文檔記錄資源、資金需求和承諾
27.
維護集中的集成的項目文件
28.
進行風險評估和制定風險管理計劃
29.
跟蹤問題直到問題解決
30.
管理項目更改控制
31.
保持適當的業務控制
32.
確保合法的有調整的需求被滿足
R&D
PDT
開發代表(研發項目經理)
R&D
PDT
成員關注于所要提供的產品包必需的硬件和軟件開發。根據所要提供的產品包的內容和復雜度不同，可能會有一個或多個硬、軟件人員是PDT成員，代表所有開發部門作出承諾。
R&D
PDT
成員和系統工程師一起工作，將需求轉化為所要提供的產品包的目標，開發產品包的定義、硬件和軟件的組成定義，并且按照這個設計開發出產品包。他/她負責創建和維護產品包信息計劃(包括記錄的保持和保護)、質量計劃、產品遷移/轉換計劃、生命周期結束計劃、升級計劃、硬件測試計劃、軟件測試計劃、全球化支持(NLS)計劃和翻譯驗證計劃。R&D
PDT
成員代表設計者、開發者、測試者、總體、計劃者、認證專員、知識產權分析者等，通過項目計劃管理他們的活動。
R&D
PDT
核心組成員的職責包括：
1.
按照項目計劃保護和管理R&D功能部門的資源
2.
對所要提供的產品包概念進行技術評估
3.
優化/細化業務計劃中的開發部分的工作分解結構
4.
開發所要提供的產品包的定義
5.
評估所要提供的產品包的技術風險
6.
擬制業務計劃中的的R&D部分
7.
擬制為決策評審點準備的R&D相關的建議
8.
擬制所要提供的產品包合同中R&D相關部分
9.
檢查和保護知識產權
10.
如果需要整理出專利檔案
11.
和系統工程師及其他PDT核心組成員合作
12.
決定必需的獲得物或發展業務伙伴
13.
定義所要提供的產品包和/或技術依賴性
14.
制定NLS(本地語言支持)計劃
15.
選擇關鍵器件
16.
規劃資產重用CBB
17.
設計、開發和測試產品使之符合規定的需求
18.
通過項目時間表驅動所要提供的產品包的開發活動
19.
驅動測試計劃和規格
20.
創建產品演示材料
21.
創建分發/發行和支持計劃
22.
第五篇：一線產品經理的工作感想
只是個人的工作心得和所思所想，信馬由韁一通，做產品的人能大致看得懂就行了。 沒啥鋪墊的，直入正題，一塊塊來：先上一張圖
需求文檔看不看
當你辛辛苦苦寫出來一堆需求文檔，跟UED的同學定好交互、視覺、重構;滿以為技術會認真對待，但是你會發現，技術同學基本不會看你準備的一堆東西，基本是按照自己的理解來開發，當開發不下去，第一時間也不是看文檔，而是看測試用例，或者直接跟產品溝通;基本文檔只是QA同學對著寫用例。
剛剛開始工作的時候，對于技術不按照文檔開發，是比較著急上火的，經歷一段時間后，發現重點就好了。產品的本質是保證產品核心功能的質量，保障用戶體驗，用戶端和商戶端的功能不能含糊;運營后臺、客服后臺之類的，保障功能完整和業務流暢的基礎上，可以給技術適當的自由發揮;就算是前臺頁面，多聽聽技術的意見，讓技術同學參與進來;開發過程中，保持溝通，對于技術提出的問題，最快速度的響應。
什么樣的需求要寫文檔?對于功能性、涉及業務流轉，狀態切換，邊界條件灰常多的需求，流程圖、交互、PRD一個都不能少;對于非功能性的需求，提升用戶體驗的部分，文檔可以不準備，準備好原型圖，然后在上面標注出重點，交付的時候講清楚。
todolist與優先級
產品在迭代過程中，不斷有新的需求，不斷有需求被完成，通過list來管理這些需求，整理的過程也是對產品思考的過程，不停問自己，這個需求用戶是誰，解決什么問題，是否必要，以及是否必要現在就做?
list的好處就是，可以盡量多的記錄所有需求，雖然有些天生就是被砍的命，但是list一堆需要完成的事情，對整個項目組都會有緊迫感;一句話講清楚每個需求，標明優先級，負責人，對應的開發，開始時間，完成時間，完成狀態，讓項目組所有人(包括老板)，都知道我們現在有多少事情在做，已完成來多少，接下來做什么。
需求永遠做不完，對于優先級安排，平時工作中最常用的就是四象限法，重要又緊急，重要不緊急，緊急不重要，不緊急也不重要，根據項目實際來做判斷。
需求會議
2014年都是一周一次迭代，每周都會有下次迭代的需求會議，并不是真正意義上的需求評審，產品驅動的公司，基本就是需求講解，交付，以及相關時間點確認
需求準備要充分
在需求會議上，面對技術和QA，甚至老大們的挑戰，這是正常的，他們會問為啥要這么做，為啥不那么做，甚至直接對你的需求提出挑戰：這個東西不靠譜，不可能;拍桌子打板凳的事情也時有發生;唯一避免發生的情況，就是對于需求的準備要充分;不管面對何種挑戰，講清楚數據、用戶需要、和競爭對手怎么做的，基本就能說服;一般只要保持平和的心態，不會有大問題。
真有自己無法立即解答的，快速承認錯誤：不好意思，這個是我沒有準備好，會后我再去做詳細調研和準備，快速跳過這個問題，繼續下面有把握的內容;會后再去完整論證，并把問題描述清楚，郵件給大家;既可以避免沖突，會后大家平和心態來對待，也便于解決。
講好我的故事
這里應該是講好用戶的故事，為啥叫講好我的故事，因為產品需要把自己代入到各個角色中;做過幾次用戶訪談，很多用戶描述這樣一個場景，我快下班了，拿出點評App搜索附近找吃的;運營說這個這個很煩，我需要這么這么做，其實可以這樣就解決了;
客服說，這個信息在這里查，那個信息在另外一個頁面，每條記錄處理的時間增加多少分鐘;
最有意思的是商戶端，商戶那邊有簽合同的、店長、負責人、前臺、收銀，會計，每個人都有可能來用我們的后臺，去商戶端做訪談的時候，觀察他們如何使用點評的產品;
講需求的時候，先描述用戶遇到的困境，繪聲繪色，動人心弦;如何做到，代入自己的角色，不要假裝用過，而是自己真正使用過程中的痛點，放大再放大，感情方式來打動技術。
描述痛點只是第一步，可以清楚描述，如果這個需求做來，運營效率可以提升多少，節約多少成本，最終轉化率預計提高多少，以及ROI(投入產出比)，所有功能點的改進，最后都可以結算為Money，因為錢，會讓所有人興奮，并集中精力來解決問題。
讓更多的人參與需求討論
需求被挑戰，會有點不舒服;但是若所有人都表現出對你的需求漠不關心，那才是最難受的。如何讓技術更多的參與需求討論：首先可以挖掘對業務有興趣的人，多跟他們聊，他們會主動告知他們的想法。一般工作幾年的技術比剛剛工作的童鞋更關心;其次讓技術有存在感，定時告知他們相關的產品數據，月用戶數，月增長量，收入等，根據技術所開發的功能點，細化到此功能帶來的數據，以及同比環比數據;最后在Scrum中，計劃撲克能夠讓所有人都參與到需求當中，因為每個人都要評估task的工作量，目前來看，效果還不錯。
確定好時間點和相關責任人
Scrum確實是一個好的方式，能夠估算出工作量，并且技術自發領取任務，直至每個人工作內容都填充滿整個sprint。
在未開始Scrum之前，每周一次需求會議，只是交付好相關需求，由開發主管來指派任務，并定好工作計劃表，然后QA同學補充相關測試安排，最后敲定上線時間。
其實不管何種方式，最終的結果導向就是，產品盡快上線，且以最有效、風險最小的方式。
適當地砍需求
產品是不需要懂技術，但是如果能根據需求大致預估工作量，排期更簡單;每次我都會提前多準備一些，連交互和重構都準備好，擺出一副不做此需求是誓不罷休的架勢;資源充分時，技術童鞋會主動領取需求的，但是當工作都排的比較滿的時候，就很難了;所以需求評審時，每個需求的優先級都排的高高的，將用戶痛點描述的栩栩如生，如果技術實在抱怨太多，或是總拿51230.com那樣的婚戀網站來舉例，那就象征性地砍掉一部分，前提是保證核心必須完成，其實當時砍掉一部分，不會一直砍下去，而且心里也會有滿足感;其次給技術緊迫感，趕緊完成，后面還有一堆事情呢，即使這次迭代不做，下次迭代也需要完成。
產品開發過程中
保持溝通
在產品開發過程中，技術都是非常有責任心的，會幫你考慮邊界條件，作為產品積極響應技術提出來的各種疑問，是維系技術與產品之間很有效的方式。雖然有一些問題，可能是技術對需求的理解并沒有產品那么深刻，講清楚就好了，沒有必要上綱上線，因為最終大家的目的都是為了產品，另外公司開始實踐的Scrum也對整個團隊保持溝通，既是要求，更要成為一種習慣。
認真對待測試用例
測試用例，又是一個保證產品質量的利器;剛開始工作的時候，認為測試用例只是QA同學的工作，第一版本App上線做UAT的時候，發現對著需求文檔并不能完整驗證完所有需求，但是對著測試用例，所有的主流程，輔助流程，邊界條件，非功能性需求，清晰明了，感覺太有用了。所以每次都提前完成需求文檔交付QA，QA在技術正式進入研發完成用例文檔;在過測試用例時，產品同時參與，避免一些需求理解上的偏差，此外技術同學對著case開發，比需求文檔描述更清晰，另外技術同學可以參與部分自測;UAT的時候，也是產品的參考。
需求變更與delay
需求變更是永恒的話題，Scrum中一般是不接受需求變更，其實不允許變更的本質不是需求定板不動，而是對產品提出了更好的要求，從需求調研、準備、設計、交付每一步都需要考慮周全和清楚;即使在要求嚴格的Scrum中，需求真的不能變更么?如果臨時線上bug造成用戶無法訪問，技術同學是不是要停下手中工作，來排查線上故障呢。作為一個產品，不是神，盡量保證所有的需求都是合理且必要，并且將所有的需求準備工作做到位;如果還不能避免，就要影響甚至說服整個團隊來擁抱變化。
正確處理需求變更
需求變更已經發生，那就趕緊處理吧。如果是產品沒考慮清楚，用戶調研或者數據支持出錯，果斷向團隊承認自己的錯誤，沒有人會責怪一個真心誠意道歉的人;并在第一時間交付變更后的需求文檔、交互、視覺、重構等，并跟技術溝通如何以最小的代價，完成此次實現;若技術的工作在本次迭代已經安排很滿，那考慮需求的緊急程度，適當情況下，可以放到下個迭代去完成。
若是因為行業或者市場變動，產品轉型等原因，直接向團隊傳達變更的原因，以及接下來的產品規劃，讓所有人都看到一個清晰明確的目標，技術會有疑問和挑戰，耐心解答，通過行業數據、競品等角度去闡述;遇到老板變更需求，那比較簡單，因為老板的需求優先級永遠是最高的，但是作為跟技術直接溝通的產品，要認真對待老板變更的部分，若老板頻繁變更需求，煩的是技術，會不會以后合作留下影響呢。
關于產品delay
不管產品還是技術，沒有人愿意看到delay的;面對delay，怎么處理?換個思路：就算delay了，只要用戶還能用，服務照樣跑，地球還照樣轉。如果真的導致用戶不能訪問，整個技術團隊肯定加班加點，不吃不喝也會搞好的。一旦出現delay，整個團隊一起來排查delay原因，是需求變更，還是資源沒到位，還是項目之間的耦合關系，前面小的改動，導致后面項目的延期，做好每次的總結會議，并在下一個迭代中避免此問題。
目前團隊中正慢慢引入Scrum敏捷開發，而本篇總結，大部分是基于小瀑布模式的迭代;需要學習的還有很多，一轉眼又過了兩個月，正式工作已經八個月，需要走的路還有很多，跟隨整個team一起成長。
算是工作總結吧，主要是自己梳理一下，路還長，繼續跟著一班牛人加油唄!