敏捷项目的一些小记录

新一年、新环境、新挑战，希望构建敏捷的团队，一些想法及拾人牙慧，做下记录，权当笔记。进行中，事情告一段落后再来修改。

敏捷项目的基础

1. 得人少，能有决定导向性问题解决方案的人少，仅一人拍板，或至少在负责的没有太多影响的不同方面有专人拍板，如开发技术选型和产品方向不同人，另外建议产品策划和运营不分家。
2. 靠信任，拍板人要有说服所有人相信自己的魄力，自己已有行业或人脉的积累挖人创业的会有优势，因为人家本来就是被你忽悠过来或者志同道合的。

在大公司内的产品汪相当苦逼，大部分只能靠数据结果证明，会很蛋疼，要顶住上级的乱七八糟想法、完成kpi的压力、合作伙伴的吐槽、大部分情况下无法取得成绩，大家一拍两散，成功者实力+运气均不可少，应了那句你先变成猪也要坐上风口才能飞起来。

敏捷项目的沟通

• 为什么能够效率高，绝大部分是因为人少，沟通不费力。说白了就是人少好说话，嗷一嗓子大家都知道。这是个简单的数学题，两个人一条沟通渠道、三个人就是三条，四个人就是六条......
• 沟通渠道少的的好处就是减少了信息不对称，在拥有共同信息的情况下，沟通成本能够大大减少。
• 在沟通渠道少的情况下，及时沟通就变得容易，开发的劳动成功能够得到快速的反馈，成了能够激励大家，不成的话也能让开发骂一句煞笔，然后产品乖乖去跪键盘反省自己为什么要这样做，投入产出比是否符合预期，少交学费。

敏捷项目的思维方式

• 和大公司最大的不同在于没有足够的资源，因此在大公司的产品可以理直气壮（大部分时候）的考虑，我要做什么，需要哪些资源，小团队的产品汪只能每天都在痛苦的挣扎于我有什么资源，我能做什么，谨慎的向前推进。
• 敏捷的核心思想是MVP（minimum viable product），因此需要在资源/时间确定的情况下，最大限度的挖掘用户价值为导向去衡量项目需要完成的需求以及完成的质量程度。

敏捷项目的管理

• 永远反复思考讨论：为什么要做？项目的可交付结果是什么？质量标准最终定在多少分？大家是否达成共识了？
• 产品需要不断的克制自己对精益求精的欲望，不断随着结果的产出做短期计划及长期路线（这两者是不同的）。
• 研发团队要更加注重轻松&有创造力的氛围营造，无法将过大的压力和机械式开发任务强压，因为一个人的士气降低就可能影响整个团队并且拖累50%以上的进度，不像大公司大部分其实都是流水线。
• 构造灵活的小团队，保证决策的快速响应，团队知识及方法上的不断迭代，不断学习及进化。 重提第一点基础，要对每一部分的负责人有充分的授权和信任，才能更好的培养主人翁意识。

对产品的要求

权当对自己的一些要求，从大公司到小团队的做事方式转变，从利用资源到自己争取并把资源用在刀刃上，从做事到培养人。

1. 想清楚、多尝试，整体节奏把控下单点突进
2. 减少处女座的毛病
3. 用户信息对团队的输出
4. 项目成果对团队的输出
5. 方法论对团队的输出
6. 价值观对团队的输出