1704227079
团队架构要与项目的种类相适应
1704227080
1704227081
团队可以小到几个人，大到数百人。美国的公司大多数运用跨部门团队，让每个成员在项目中代表最大的利益相关方。不同的团队架构（见图8-2）适用于不同的项目。直线延伸或简单产品可以运用直接透明的矩阵结构，其中，产品经理通过不同职能部门引领项目开发。在这类架构中，职能部门团队成员可能在特定的项目中花费的时间不到25%。产品经理很可能地位较低或处于中层。随着复杂性的增加，组织架构的重量级也会增加，产品/项目经理会与把全部时间（临时）投入新产品工作中的职能部门专家合作共事。对于某些突破性产品，自发团队（偶尔会在同一地点办公）比较合适。在这种架构中，报告关系从单独的职能部门转向项目单元。最后这种架构是最不常见的。（小公司也许无法奢望用不同的矩阵架构，因为每个人可能都会参与到所有项目之中。）不管组织架构如何，产品经理必须构建一个尽可能完善的最佳团队。
1704227082
1704227083
1704227084
1704227085
1704227086
图8-2 新产品矩阵结构
1704227087
1704227088
不同部门的视角至关重要，但你可能还需要考虑组织期限、文化层次、人员性别与个性的多样性。这可能导致协调起来更加困难，但也可能因为不同视角的互动而产生新的想法和解决问题的思路。更高程度共享心智模式的团队，可能容易受团体迷失的影响。因此，让团队成员在不同项目之间进行轮换很有价值，但这可能导致低效。为了降低这种风险，产品经理应该尽量掌握跨团队的知识体系。有几种工具可以帮助他实现这个目标：（1）在新组建的团队中安排过去在成功团队里工作过的成员；（2）在参与新项目团队工作之前，让新团队成员参加成功团队的会议，向他们学习；（3）指派成功团队的成员作为导师；（4）确保整个团队的所有成员不会同时被更换。[6]
1704227089
1704227090
建立团队基本准则
1704227091
1704227092
产品经理作为产品开发团队的主管，负责指导团队的活动，保持团队的目标协调一致，并且与高级管理团队保持有效沟通。首先就要确立团队的宗旨。尽管团队明显是为开发新产品而存在的，但也必须明确每个人对其职能、时间安排以及产品开发的目标都要有一致的认识。团队宗旨应该高于团队的一切会议日程和会议记录。确立了团队宗旨的承诺之后，为团队会议制定共同接受的基本原则，可包括的条款有“参加会议前必须做好充分的准备”“所有会议都必须按时召开或结束”“开会时不得使用手机或其他干扰会议进程的设备”“团队成员轮流承担做会议记录的责任”。确保所有团队成员认识到自己对每次阶段性检查工作的贡献。
1704227093
1704227094
运用工作分解结构和活动图表
1704227095
1704227096
项目团队组建的同时，项目的进程也要同步制定。首先搞清楚完成特定新产品项目所需要的主要活动。每项主要活动都应进一步细分成具体的任务和分任务，创建工作分解结构（WBS）。用WBS中的信息来预估项目开展的时间和各种资源要求。工作任务必须细分到足以允许各种可接受的预估为止。如果没有WBS，任何对时间和资源的估计都只能是个大概，可能会与真实要求产生巨大出入。下面是一次产品召回的WBS范例。尽管不是新产品开发项目，但它仍然给我们呈现了一个完整流程的简单案例。
1704227097
1704227098
1000开展全面的安全分析
1704227099
1704227100
1001根据产业/政府标准进行风险分类
1704227101
1704227102
1002参观工厂
1704227103
1704227104
1003员工访谈
1704227105
1704227106
1004产品与设备测试
1704227107
1704227108
1005确定召回的速度
1704227109
1704227110
2000通知员工
1704227111
1704227112
2001给全体员工发电子邮件
1704227113
1704227114
2002在内部网创建相关登录页面
1704227115
1704227116
2003对在现场处理本次召回的销售人员开展培训
1704227117
1704227118
3000通知中间商和顾客
1704227119
1704227120
3001发送第一等级或优先级电子邮件
1704227121
1704227122
3002电话直接联系关键客户群体
1704227123
1704227124
3003为回答各类问题建立免费热线电话
1704227125
1704227126
3004在网站上建立专门的登录页面
1704227127
1704227128
3005在相关媒体上发布新闻