第四章学习总结

课程学习进入到“产品需求文档和原型设计”相关的阶段，群里的同学对这一部分也有了更多讨论。自己虽然有一点点儿工作经验，但通过课程学习，意识到自己之前有好多不足。大致总结如下：

一、文档结构化梳理

产品的第一版需求文档在撰写之前就要考虑好之后文档迭代及延展的问题。当有新人加入团队或有工作交接情况时，具备结构化的需求文档会让人很快“上手”项目或产品。侧面理解，这也是整个团队“大产品”的一部分，当对外输出或展示时，会影响观者对团队的专业程度的印象。结构化梳理之后，也有助于我们回溯产品设计方案，意识到当时到底是“用什么方法解决了谁的什么问题？”

二、适应团队的发展

各个公司规模不一样，团队的配置也不尽相同。我们希望找到一套通用的方法论来满足各个团队的不同发展阶段，这是不现实的。有的是为甲方服务的，在研发之前，产品原型要求做到高保真（包括动效设计）。这样能最大限度地和甲方完成沟通，敲定最终的方案；有的小团队面向 B 端的后台管理系统，为了节约人员投入成本，暂时没有 UI 设计师，工程师用一些开源的代码框架来满足要求；当然一些大公司有了完备的开发流程，按照规则去匹配就好。

三、好工具事半功倍

现在的协作工具层出不穷，大部门免费版本的功能已经能满足很多工作场景。但产品经理在挑选协作工具书时，要考虑到跨平台、演示特性、高保真等问题。不仅要考虑自己书写的便捷性，更要站在设计师、研发工程师的角度上去体验好这款工具。大家好才是真的好！当然，如果有必要的话，可以向公司申请经费，让公司购买企业版本。好的工具真的事半功倍，不要为了省一点儿小钱而耽误开发协作的效率。

四、学海无涯多请教

三人行必有我师，我们要虚心多向别人请教，每个人都有各自的闪光点，多多学习。这次二爷分享了他在工作中的需求文档，真的很简洁、美观、高质。这些让自己这只井底之蛙看到了更广阔的天地，我对自己产品经理的硬技能也提出更高要求。不能总是思考一些形而上的东西，在仰望星空的同时一定要脚踏实地。把每一件小事做好，就是最好的锻炼和成长。