[打卡宝宝]：李静
[打卡日期]：2019/04/22
[学习内容]：人人都是产品经理
准备出发：把需求打个包
上战场之前，就像战士要把自己的物品打包一样，需求也要打包。我们现在来解决这个包有多大的问题，即某个将来的潜在项目里，到底应该包括多少需求的问题。这里不得不提前谈一点项目管理的内容了。做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。
但又要马儿跑又想马儿不吃草的事情是没有的，所以我们通常是在上述4个要求中做平衡。我经历的互联网、软件项目，比较推崇敏捷方法，所以有比较固定的项目时间，专业点叫“迭代周期”，一般是2～4周。然后有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的只能是量——项目范围。
继续，我们有了项目时间长短，也就意味着可以按经验的比例估计出留给开发的时间有几天，然后团队里有多少开发工程师也是知道的，所以我们可以直接算出有多少“可用工作量”，同样以“人天”为单位。还记得我们把产品需求列表按照“性价比”从大到小排序过了么？从上往下看，每一行后面都还对应着一个“工作量”，现在我们只要做一个简单的加法，一行又一行地从上到下依次纳入项目，能做多少，一目了然，我们把这个动作叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。
当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随意地超出“可用工作量”。
这个过程完全定量地回答了“做多少”的问题。但，真实情况哪会这么简单明了，就像课本里总是给出一个简单到不真实的例子，然后再告诉你还有很多特例，而到了实际操作中，你会发现又要复杂很多，没办法，大家都尽力吧，让每个项目的大小相对靠谱，下面说几个需要注意的地方。
第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求合集”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解。
第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。
第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。
[坚持习惯]：
读书192＋减重减脂48
[今日感悟]:敏捷方法这个词第一次听说，百度了一下，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。
本书中主要说明为：
1.有计划，更要“拥抱变化”。
2.迭代周期内尽量不加任务。
3.集中工作，小步快跑。
4.持续细化需求，强调测试。
5.不断发布，尽早交付。
恢复写读书笔记，无比开心，有一个最安静的时间用来思考。
希望你每天逗都比上一天进步，八小时之内求生存，八小时之外谋发展。
