#《人人都是产品经理》读书体会 陆陆续续看完《人人都是产品经理》，系统的体会谈不上，倒是有一些零散的认识、总结、想法、感悟，纯粹从我个人的主观态度总结，受个人知识体系以及能力不同，难免偏颇，权当交流吧。
首先，扉页看到作者的工作经历，从06年毕业一直到现在，一直从事产品经理或者类似的工作，确实挺难得的。我个人坚信只有积累才能创造优秀的产品，才能让产品越来越好。反过来，如果我们总是今天做这个，明天做那个，是不可能把事情做精做细的。有时候，我们容易陷入一种误区，感觉只要我们天天念着我们是在做产品，我们要做好产品，我们不是在做项目，仿佛这样就能真把产品做好。其实不然，我个人对产品的看法就是：即使我们现在做的是项目，只要我们一直在做，那么渐渐的，这个项目自然而然就是产品了；就算我们天天说要做产品，而每当做到第一个版本的时候，就停止或搁置了，那这个产品也只能说是一个项目。尤其是软件类产品，大部分的软件类产品的生命周期止步于开发测试完成。当然，这种情况一定程度上与软件产品定位，以及瞬息万变的市场环境有一定的关系。总的来说，我认为，只有我们持续的去做，持续的去完善、改进一件事情，一个产品，是肯定能成功的。而这个持续期会根据我们做的事情的大小相关，可能是半年、一年，甚至是几年。淘宝网最初也是花了很多时间去研究，打磨细节，到现在一直有那么多人在持续完善，改进它。这使得淘宝网自然而然成了行业标杆。
这本书关于需求的描述，提到一个观点，个人比较赞同。那就是：需求有很多，但是活下来，能真正有意义的是少数。我看到我们在分析梳理产品功能需求的时候，那么多功能，但是仅仅只是看到功能，我更想知道我们是关注客户（作者指出客户和用户的区别：客户是为产品付钱的人；用户是真正用产品的人）还是关注用户？用户真的会很喜欢用我们提供的那么多功能吗？我可能会认为，一些我认为不太符合实际的功能之所以存在，或许是因为它的存在意义单纯只是商业上的噱头，或者说是商业策略，比如：竞争对手已经有这个功能，我们也一定要有，不管这个功能合不合理，用户有没有真正愿意去使用。最近看到一篇博客文章说的是：一个朋友问购买了某款比较出名的软件系统的另一个朋友，说你为什么要买它啊？那个朋友回答说,我们买来基本不会去使用，而是会对别人宣传：你看，我们的公司是采用XXX的国际化先进软件管理系统，显示我们的专业度有多高。因此，如果是真的为用户着想，我认为一定要搞清楚用户本质的，潜在的需求，在分析出一些功能的时候，是不是要再多想想，用户真的会用这个功能吗？这个功能真的有实际使用场景吗？通过这种方式，每个产品，每次需求的搜集，到最后，站得住脚的都是少数。
而本书的第三章《项目的坎坷一生》，内容上个人没什么体会，感觉也没超出我太多的认识，中规中矩。唯有章节名称，到是有些同感。我做了几年的项目（我一直认为我是在做项目），回顾起来，都挺坎坷的。从项目立项，到最后落地投入使用，真是一路磕磕碰碰。商业上，定位上的因素，技术管理的因素，等等。我的看法是，要想让项目成功，可控制，第一就得先有全局的计划。软件类项目和其他类似上班类行政类工作有不一样的特点。软件类有不确定的因素（新技术的使用，新思路，新架构的使用），一切不可控的因素如果前期不分解成可控的因素，那么到项目真正开始运行的时候，就算加再多的人进来也无济于事。
我比较赞同《人月神话》里提到的项目团队的运作方式，那就是所谓的外科手术团队。做一个外科手术当作一个项目，那么需要有一个外科医生，和一到n个助手，以及多个护士。这些对应到软件团队里，外科医生就是所谓的软件架构师，模块设计师，他们负责把工作规划成可以分解成多个明确的子任务。然后把这些任务分配给助手（软件工程师），软件工程师负责按照架构师的设计实现框架，软件工程师还可以再在架构师可控制的范围内，细化模块内部的任务，分到护士(助理工程师），负责完成更细小更明确的任务。所有这一切，都需要软件架构师有很好的设计，关键点就是要保证任务能被分解，可验收。经过这样的设计过程，整个项目的可控性大大增强，应对需求变更也得心应手，起码能回答哪个需求能做，哪个需求能不能实现，需求需要多少时间，改动的模块等问题。这样就把一个软件性的技术问题转化为了人力人工问题，如果上级要求提前完工，那么适当增加人手或者增加工作时间即可。
《人人都是产品经理》作者提出的那些项目过程，个人认为还是比较形式化，虽然说形式化很重要，但是更重要的是项目实际的可控性。反过来，如果形式化真的能保证项目的可控性，那就应该形式化。就像作者说的：要想开会不流于形式，就要做更多形式化的工作，比如：会前准备，签到，会后会议纪要等。他说这句话，我理解的是：作者不知道有更好的办法让开会不形式化，所以只有用形式化的方式保证开会不形式化。
以下还有一些零零散散的体会，罗列如下：
- 本书内容感觉不太流畅，可能是很多都是博客汇总而来（部分内容之前我也在网上看过），后期虽然做了一些梳理，但我还是感觉，不够流畅；
- 本书的配图画的都不错，体现了作者的文档编写功力，说明他有特意去学习和钻研过，这从他书里推荐的一些其他书籍能看得出来。比如：附录里推荐的一些有用的信息；
- 作者看的书也挺多的，体现了他提的产品经理的自我修养。有些书我看过，有些书我没看过。 以上个人体会，如有不认同的，可以提出，一起交流。