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