本次阅读了《构建之法》的第九、十章
在具体做项目的时候才会意识到PM项目经理这个角色的不可或缺性，每次站立会议的时间、每次要完成的内容、需要修改的地方等等基本都需要这么一个角色来协调组内关系和安排组内任务并对组内成员任务完成进度予以评价
典型的用户场景如果不能设计得合适用户，那么自己设计的软件就不能达到预期，到头来知识做了一些无用功
我们团队有PM这么一个角色，用户的场景设计可可行性与否还有待考证，在第一次团队冲刺过程中基本没有遇到什么大的问题（除了技术上的）
书中对于我们在校生的PM指标做了一些描述，给我们指明了一条路：
你是否觉得你的长处不在于写代码和debug，而是协调、沟通，让一个团队或组织有效运转起来？你是否喜欢表达，善于和各种专业背景的人沟通？你是否经常思考如何改进生活中点点滴滴的小问题？你会思考这样的问题么：新浪微博、豆瓣、qq、微信都可以社交，它们的定位、产品特性、用户群、解决的需求，有什么不同？你是否对以下领域感兴趣，甚至自己找过相关的书来看：心理学、社会学、组织行为学、统计学、商业模式？
如果你的答案是yes，那么我看好你的PM潜质。
在校学生可以通过下面的方式锻炼自己的 PM 能力：
- 参加多种社团并组织一些活动，最好是草根的活动，而不是由上而下规定的活动；
- 选修各种相关学科的课程
今后我们会增加交流的次数，并且多多练习写一些文档来锻炼自己
- 争取在实际的企业中实习
- 和小伙伴一起，搞点小生意，小创业
场景分析章节里旅馆老板的小例子既有内涵又明显移动，让我们明确的了解了，同时也写明了文档的重要性
是否要文档
有人说，我们敏捷的团队，就喜欢直接的面对面的交流，不喜欢搞文档什么的，多好！
其实大多数情况下，留下文字说明是很有好处的，相对于后来的浪费和返工，当初花的时间真的是太值了。看下面的例子:
自习课时，教务主任匆匆走进来，告诉班长“帮我找两个人，我要班花”，同时两手在胸前做了一个抱花的动作，就走了。班长就组织全班投票评选起班花来，闹了一节课，搞了一些大数据，终于统一了意见，选出了班里最漂亮的两个MM。于是俩MM很羞涩的去找主任，主任说：“怎么是你们？男生都哪儿去了？好吧，跟我去后勤，我要搬花……”
可见，面对面直接的交流当然很敏捷, 但是还是要留下文档, 以明确用户的需求。