需要一个邮件群,邮件群比qq群好(qq群就有邮件群)
关于开会的周期,一天最少一次,早中个一次
上午效率低,
开会讨论三点: 做了什么，要做什么，有什么问题
关于MileStone
PM就是汇总做了什么
汇总成项目进度，检查MileStone是否达到
汇总要做什么，做出下一阶段的计划
汇总大家遇到的问题，及早解决潜在的风险
PM就是打杂的，为Dev和Test提供任何便利，保证他们的高效工作
包括提水，买饭
因为PM的工作不一定要在电脑前完成
设计一个系统,从表层的feature开始
逐级细化，算是需求
把功能做成没有歧义的
button上的字是"确认" 点了之后弹出"Hello" 都是要定死的
甚至Hello 弹出坐标为 50，50 也是要确认的
Word Excel就够饿
Feature 做成这个样子是为了可以衡量一个功能是否已经完成了
Feature做完了，就要设计系统，用我们学的东西UML 把那些东西画出来，
然后大家Review
review 完了改
在review 再改
再Review 再改
直到大家都清楚这个东西的逻辑和实现方法(70%的把握)
一个人在上面念，一堆人下面挑错
像对付仇人一样挑他的毛病
大家挑不出毛病也就差不多了
分工按功能点分(登录，注册),
能分到半天 或者一天的粒度上
头几个任务每人自己定时间，然后看他们谁做的比较快
头几个任务建议你在每个人的任务里加一个Buf
一般来说，人都是过于乐观的
习惯了Delay任务可就不好了
开始每个人自己挑,如果那些信誉比较好的Dev能够准时快速的完成任务，以后就继续让他自己挑,
如果有人总是没法估计自己的工作量，那就是你分配,不过更倾向于分配,
不过考虑一下每个人的心理
所以兼顾民主，有个度
没有激情先从PM身上找原因吧,不要拿一条尺子量人，尤其不要拿自己的尺子量人,有耐心一些
第一个任务Double，估计
不过不排除一个Dev自己已经Double过了，这时候就看情况来定了
低于一天的全部Double,一天的Buf半天
不要在项目进程里出现不可衡量的问题
"可以""应该" 不确定的东西会让项目变的不确定,尤其是进度
记住，PM不要去写代码，只需要读别人做的东西就OK了，我深有体会
实在没有事情干（虽然这种事情不太可能发生），读一些书