作为一枚之前一直从事安防传统行业的产品经理「跨界」到SaaS行业，从团队规模、产品营收策略、开发模式都发生了极大的变化，截取这半年的工作经历的一些片段，希望跟所有打算进入或即将进入采用敏捷开发创业团队的PM们分享一些心得。
#1. 设计需求从写好一个User Story开始
所谓「User Story」，就是从用户的角度描述需求，包含：角色、活动以及商业价值。 一个好的用户故事应该遵循INVEST原则，即：独立性、可协商性、有价值的、可估算的、小的、可测试的。
关于INVEST原则有这样一个小故事。
我在小金写的第一个story是关于「在线考试」这个应用，story是这样写的：作为考试举办者，我希望设置考试流程，以便创办考试。此外，我还在story中详细描述了需要设置哪些考试规则比如试题分数的设置、考试时间的设置等等细节，但当开发看到这个story之后，回复给我的答案是「story太大，无法评估」，并告知像分数设置、时间规则设置之间毫无关联，因此应该将试题分数设置、考试时间设置等等拆成单独的story才能做准确的评估。
这就是INVEST原则中的S,代表Small，每一个story都应该尽可能小而相互独立。
也就是说，以往你提一个需求要写一篇需求文档，到了敏捷开发中，可能就变成了3个、5个甚至更多个story，虽然从完整性上略有不足，但也正由于其足够小且具有价值，而使得项目进度变得更加可控。
#2. 少即是多
确定需求的优先级虽然是每个产品经理的基础功课，但在金数据这半年，由于快速迭代的工作模式，且开发资源极其有限的情况下，优先级的评估更显得尤为重要。
产品规划阶段需要优先级的评估，在小金我设计的第一个产品「在线考试」初期scope共拆为40个story，心理预期完成需一个月，在首次进行开发评估工作量后，我意识了一个严峻的问题是scope太大，要做完一个月根本不可能，显然这是由于我延续了之前的工作习惯导致设计功能力求「尽善尽美」而设计了过多锦上添花的需求导致的。
为了保证产品如期上线，我选择砍需求缩小scope。办法很简单：对规划的每一个功能都问自己一个问题，没有这个功能这个产品是否可用？如果答案是否定的，那么显然它不是我们第一阶段需要开发的功能。这就是MVP原则，这个原则帮助我有效地将40个story缩减为23个story，快速构建出了一个产品的雏形。
#3. 前期风险控制很重要
「在线考试」应用距离规划上线还有一周时，我们仍遗留了许多问题，包括页面样式调整、bug修复以及一些corner case没有覆盖，为了保证如期上线，针对所有的遗留问题我们按照对产品的影响程度重新排序并评估，确立了在产品上线时需要完成的内容，虽然挽回了不少时间但最终还是延迟一周上线。
事后总结，问题的关键在于前期风险控制没做好。如果在每个需求的开发过程中都能及时与开发沟通，了解开发进度及遇到的问题，并与前期预估时间对比推测潜在风险并给予解决方案，那么就能更加有效地控制项目进度，最大可能地避免delay。
#4.多做一点、多说一点
「多做一点」为的是「尽可能避免使用资源」，创业团队最常遇见的问题大概就是资源紧张。开发资源紧张、设计资源紧张、测试资源紧张、市场宣传渠道紧张...在这种情况下如果还想稳步迭代产品，就必须要承担一部分其他角色（比如设计、测试）的职责，保证项目进度不因资源的紧张而block。
而「多说一点」则指当自己无法承担职责时，需要跟其他使用该资源的负责人沟通协调，当多个产品线共用一个设计师，那么就需要PM们提前跟设计师评估出设计稿的工作量，再从多条产品线的需求优先级统筹规划，最终给出一个合理的排期。
在敏捷开发的模式下，写好User story、规划新产品遵循MVP原则、前期风险控制、合理资源调度是我学到的四门功课，未来还要继续修炼，与所有PM共勉。
