#week6#立项与组队读后感

本周的主题是立项与组队，主要是在产品的策划阶段完成之后，开始组建团队来推进后续的设计、开发、测试、上线、运营等工作，是后续一系列工作的起点。

这部分的工作，更多的是跟不同的团队、不同的人打交道，在没有管理权力的情况下，影响项目相关成员，以实现产品在保质、保量、按时、成本可控的条件下完成。这些工作都是管理的工作，我想这也是产品经理之所以叫产品经理，而不叫产品策划或需求分析师的原因。

说到了组建项目团队，就必不可少的提到另一个职位：项目经理。项目经理负责的工作是推动项目按时保质的完成，其关注的点为：项目范围、质量、进度、成本。这四项要素互相影响，一项变动，另外三项中至少有一项要跟着变动。项目经理的职责是把事情做正确，强调的是执行力。

而产品经理，最重要的职责是定义产品：做正确的事情，强调解决用户问题。这样就产生了一个矛盾：
项目经理要把事情按时完成，所以不希望在项目进行中有太多的需求变化，最好没有变化，这样项目就会可控；
产品经理要做正确的事情，而如何定义正确的事情？随着时间的推移、内外部环境的变化，对“事情是否正确”的认知也会发生变化，所以产品经理就希望能快速的响应这种变化，对需求进行变更。

矛盾如何解决呢？

控制项目的大小，一个项目中发生了变化的事情，在下一个项目中体现，而不在当前项目中进行变更，也就是敏捷项目管理，把每一个迭代都当成一个项目来管理，这样基本可以平衡不太大的变化了。但是如果是从根本上发生变化，那么整个项目也许就可以停下来，然后再来确实是否需要重新开始了。

当产品经理同时担任了项目经理角色时，如何平衡做正确的事情和把事情做正确呢？

有句话说：在错误的方向上前进，执行力越强，错得就越离谱。既然如此，那么是否应该一发生变化，就修改产品需求，并且立即实施呢？

我理解不是。原因如下：
1、变化快速的发生，我们提出的解决方案是否可以解决变化带来的问题？这需要我们去深入思考，不能草率的拍脑袋决定；
2、习惯了随时改需求，那么对需求的思考也就不会深入，对用户需求的把控就不强，就会带来更多的变动，形成恶性循环；
3、需求变动会给ue、开发等团队带来大量工作，频繁变动会导致周边团队怨声载道，影响产品经理的威信，后续你在提需求，周边团队都会持怀疑的态度，等等。

所以，在下一个迭代中来体现这些变化，给我们自己深入思考的时间，也不会轻易的干扰周边团队的工作节奏，这样才是一个良性的循环，这样也给迭代提出了一个要求：周期不能太长，如果以3个月为一个迭代周期，那么按照上面的做法，也许就黄花菜都凉了。