）項目背景
項目背景主要通過以下五個維度去詳細展開說明，這樣可以更為清晰的介紹項目，記為5W法：
who 目標用戶
what 什么需求
where 何種場景下
why 為什么做/為什么讓我們做
when 什么時候要
舉例說明：
who：內(nèi)部BU+外部合作伙伴
what：想要有一個服務展示平臺
where：當需要調(diào)用服務接口，卻找不對應的負責人時
why：因為市面上還沒有這種開放類的平臺，而我們底層有這些api接口，且數(shù)據(jù)量龐大、搜索精準
when：9月中之前要
（2）產(chǎn)品規(guī)劃
所謂產(chǎn)品規(guī)劃，可以用“仰望星空腳踏實地”來形容：
一是未來產(chǎn)品的終極目標（星空）
二是我們現(xiàn)在需要如何拆解并一步步實現(xiàn)（實地）
（3）商業(yè)價值
我們需要站在商業(yè)層面，通過業(yè)務模式的剖析去轉(zhuǎn)化為商業(yè)價值。商業(yè)模式在大多數(shù)情況下是為盈利模式做鋪墊的，縱觀互聯(lián)網(wǎng)時代，任何一家公司都不是無償付出的
換句話說，我個人認為不以掙錢為目的的公司都不是好公司。當然這句話很有爭議，但我覺得如果公司不能自負盈虧，那么就無法養(yǎng)活為它付出工作的人，對員工來講就是不負責的
（4）功能/非功能需求
在這部分，我們主要是對產(chǎn)品的功能模塊以及整體框架作概要說明。功能性需求比如：商城功能、社交功能等，非功能需求就像：交互效果、首頁固定位置等
我們只負責宏觀模塊化認知的建立，而不用講述具體實現(xiàn)的效果以及一些細節(jié)的功能點。因為那些內(nèi)容是PRD所要展開說明的，我們在這里只需點到為止，明確功能框架而已
需求評審
另一個重要的會議就是需求評審，與立項會議不同的是，需求評審是所有產(chǎn)品迭代都不可避免的一個過程。就像針對一些小型的項目或者比較著急的功能迭代，那么基本是不會有立項會議的。而需求評審是將用戶的需求轉(zhuǎn)化為功能，并交由項目團隊實現(xiàn)，可想而知，它的重要程度無可替代
需求評審的與會人員也和立項會議有所不同，參與評審的基本上都是開發(fā)、測試、市場等負責人所挑選的具體實施人員。所以，他們才是我們真正意義上為這個項目添磚加瓦的團隊成員
一般會有ios、Android開發(fā)人員+前端H5+后端開發(fā)+測試+運營+市場，主體上是由這部分人所組成的，一些大型的項目也會有客服、運維、設計人員的加入
需求評審的相關內(nèi)容也在之前所提及的文章中有過詳細介紹，具體內(nèi)容見上述鏈接
2、團隊模式
每個公司因為工作模式、業(yè)務架構等不同因素，導致各部門的人員構成也不盡相同?？v觀當今互聯(lián)網(wǎng)公司的人員組成架構，基本上都會根據(jù)公司規(guī)模進行區(qū)分，較為普遍的分為以下三種：
大型公司 職能+項目
中型公司 項目
小型公司 職能
大型公司
規(guī)模較大的公司，比如上市公司或者員工數(shù)在100人以上的公司，大多數(shù)會以職能+項目的人員架構方式展開工作。而這一點從座位的分布位置就可以看出來，各部門比如開發(fā)、測試、產(chǎn)品等都按各自職能聚在一堆。這種模式可以促進同行們的信息交流，有利于成員間的學習，營造互相幫助的氛圍
這種人員架構會出現(xiàn)雙領導的情況，即產(chǎn)品經(jīng)理為項目迭代的領導，而各部門負責人則為人事的領導。比如一個開發(fā)人員既需要在項目中按照產(chǎn)品的設計去開發(fā)，同時還要聽從開發(fā)負責人的工作安排
每次組建團隊開展項目基本都會有新的面孔，當然大多數(shù)隊員都是已經(jīng)共過事的，也不乏新鮮血液的融入。而具體人員名單的確定，則是由各部門直屬領導所分配的
優(yōu)點
可以讓團隊成員保持新鮮感，通過和不同風格的人員工作交流，會學習到更多知識，同時結交更多朋友
缺點
需要不斷重復磨合的過程，由于每次項目都是不一樣的成員，剛開始也不了解各位的水平如何，導致總要先適應一段時間才能正常工作
中型公司
市面上也有許多公司發(fā)展狀況較好，員工數(shù)基本都是在50~100人之間，這種公司規(guī)模會以項目組作為人員的組織架構
這和大公司的區(qū)別就在于，中型公司是按照業(yè)務種類或者功能模塊等屬性進行劃分的。每個項目組都是負責各自所屬領域的工作，人員相對固定，項目組之間是并行獨立存在的
比如滴滴打車里面，可能會按照不同的業(yè)務劃分具體負責的項目組，所
