周二
和大家配合的工作有
1、站会上再次观察问题。站会别弄成形式，确保大家在站会上说的话对项目有好处，是PM的本职工作。每当发现问题的时候，不要占用会上的时间马上纠正，不妨再观察一天（这也就是周一、周二两天都观察的原因）；
2、和客户确认明天周例会的参加人和时间是否有变动。我的项目一般会把跟客户的例会安排在周三下午。一来，周一、二一般都会很忙，你拉着客户开会，他人在心不在，更难受；二来，别等到后半周开，如果客户有变动，项目组还有1到2天的时间修改。前四次例会，都要提前和客户确认，没养成习惯之前要培养他。
我记得有一个PM跟我讨论：“例会的时候不要提前跟客户说，到时候一开，打他个措手不及，这样稀里糊涂就开完例会了。要是提前提醒，他们万一变更个计划，这周任务就增加了”。我当时抽了一下，回答他：“你四不四撒？这又不是暗杀？措手啥不及？过两天他得出空来想变更了，给你打电话你能不接吗？到时候傻的还是你啊？”
别跟这个PM似的，别给客户弄“措手不及”。
3、预约TL的时间，讲一下项目架构。跟他说：“不用准备，粗略说一下，就10分钟。”不过，如果这个TL到时候真的10分钟以内就说完了，那你悬了：绝对不是他技术不过硬，而是他没看上你这个PM。这个后面会说。
话说回来，即使只是10分钟的会，也要提前说，绝不给你的队员突然袭击。
自己做的工作有：
1、准备周例会的内容。尤其头几次例会，一定要给客户好印象，让客户觉得在会上的确有东西讨论，而不是形式会议。而这，都得策划。
你得相信：“这世间所有的自然而然都是有人背后辛苦策划的结果”。
如果需要BA、TL的帮助，中午以前跟他们说。当然尽量能不麻烦他们的就不麻烦。
2、继续制定项目计划。制定项目计划绝对不是个拍脑袋的事，需要花时间想清楚，现在你用手自己拍脑袋，将来客户会换成板砖拍你脑袋。
3、继续观察开发人员的负荷。
4、确定各个环境是否可用。比如CI、Git。上周你应该拿到了这些系统的登录方式，登上去看看，这点儿破事别追着TL问，太烦人。而且，自己看才最保险。
周三
和大家配合的工作有
1、站会。连续观察了两天了，如果还是有问题，PM要在今天的站会开始前，再次强调站会规则，说问题。另外，站会结束的时候，提醒一下：1、下午和客户的第一次例会；2、通知大家明天晚上聚餐。
2、客户例会。例会PM主持（除非你的BA抢着主持），如果需要，BA可以参加，不过最好自己搞定。对于参与人数，有一个例外情况：如果不是远程例会，是在客户现场，客户那边4，5个人，而且都是“部门领导”级别的，最好PM也带着BA和UX，显得重视。这是唯一的理由，虽然比较扯淡，但是也比客户下一次也一个人参加你的例会强。
3、预约BA和TL的时间，讨论项目迭代计划。三天了啊，项目计划应该差不多了，如果还没完，今天晚上自己加个班也得弄完。
关于项目计划，有一个真理：PM的计划，如果BA或者TL觉得扯淡，那就真的是扯淡。
4、还记得昨天约过TL么？今天听他讲，相信我，一个纯种的TL说起来技术架构，如果他想说，10分钟绝对说不完。
如果你是一个不懂技术的PM，唉。。。。
如果你懂点儿，那就把你的“提醒”提出来，注意，不是“建议”是“提醒”。什么叫“提醒”？就是你觉得肯定会出问题的地方。
自己做的工作有：
1、给BA减压加工作。项目的前几周BA的工作的确非常忙和重要，他们的压力会比较大，你要给他们减压。
同时，由于事情多，肯定有一些落下的，你要给BA加上去，这就是“减压加工作”。
听着是不是有点儿矛盾？解释一下啊，减压指的是精神层面的；加工作是物理层面的。人是可以“压力小的做很多事情的”，对么？
用什么办法减压加工作呢？自己找方法吧。老Twer如果还记得“大姐”、“叔儿”是怎么干的，可以给新人讲讲。
2、例会完了以后紧急调整本周工作。如果自己没想好，先自己想，有主意了再和BA、TL讨论，然后修改本周计划。
未完，待续。。。
