项目启动阶段
团队组建
这种情况主要发生在职能划分的研发团队，各个研发成员按照资源池的形式划分。虽然需求来时，各个职能的tl都会答应，但实际人员到位情况以及支持力度远远不够，很可能导致最后延期。
措施： 拉各个职能的一把手开会，当场确定好支持的人员以及到位时间；如果其不能当场确认，也要下班前给出回复。并且，在每个时间节点开始和结束的节点亲自进行确认。
备注： 在有些灵活的创业团队，需求的负责人和开发团队的组织也是比较灵活的，因此也需要掌握这点常识。
自我授权
很多时候，领导喜欢给我们工作，却又不明确授权，而我们去跟各个方面接洽沟通的时候，又不得不解释，自己不能顺利、完全发挥自己的能力和工作内容。
措施： 把领导以及相关人叫齐，正式声明自己的工作职责、工作内容，大家要全力配合。其中不要过于担心自我授权后，某些工作做不好，这毕竟是一个过程，没有谁开始就能做好。
备注：另外，要区分好，自我授权与给title的区别。不可否认有些工作是必须某些岗位或者等级才能做的，但领导可能觉得你等级还不够，想让你锻炼下，合格了再给title。也可以理解，但那只是个title，自我授权还是必要的。如果不去主动正式声明自己的工作内容和工作职责，就会名不正言不顺。
需求可视化
这个主要出现在过程的弱管理上，没有敏捷的场景。因为开发总是预估一个模糊时间点，项目经理于是只有节点去问，完成了倒还好，没完成的情况和原因有很多，导致项目不可控。而如果中间去问，开发人员又给不出准确的进度情况。
措施：需求可视化，把一件事提上日程，每天计划做什么，每天过进度，今天应该完成的进度是什么，今天做了什么，明天做什么，最好白板的方式公示。这样明确以后，谁比较忙，谁比较空，哪个需求提前，哪个需求延后了非常清楚，这就是可视化，小颗粒度的项目过程控制。当然了解的人可能会说这不就是敏捷么？对敏捷的特点之一就是需求可控可视，当你的团队不能完整的实现敏捷的时候，在需求控制上实现可视化也是可行方案。这比要求大家发日报、周报来的有效的多，当然如果你的领导想知道项目进度，可以由项目经理进行整理相关节点和进度进行上报，没有必要每个人都去写。
固定沟通渠道
在项目的需求讨论以及研发过程中，大家都是倾向于不回答、不讨论的，尤其人很多或者回答也没有意义的时候。这种在研发团队司空见惯，待久了，大家都会觉得这个团队没有发展空间，没有成长和沟通的土壤。
措施：一定要主动的去问，去了解，最好一对一的去问每个人的看法和建议，去征求大多数人喜欢沟通的方式，建立有效的周期性讨论。如果有一天别人回答的你很少，那么有两种可能：1 根本不想和你沟通，因为不能互相理解或者因为即使沟通有了观点也没有下文 ；2 在自己的认知和能力内，已经对当前的团队和产品没有什么大的建议了。当然大多数情况下，其实属于第一种。
备注：其实固定沟通渠道，只不过为团队打开反馈的窗口，至于是否真的要执行周期性讨论，取决于团队真实意愿和需求。有一点不得不提的是，真正重要的是团队的氛围，要珍惜并重用每个人的看法和能力，让他们有机会说，有机会做，甚至有机会主导。这样，这个措施的目的才是真正的达到。
产品初创阶段
项目如何走向正轨
如何保证需求赶上工期
备注：特别说明关键路径法，也是项目管理中的重要常识，就是找出影响项目主要进度的主要需求，进行需求的拆解、资源调配，来减少工期。
沟通方式
| 沟通方式 | 说明 | 效果 |
|---|---|---|
| 树型 | 从上到下，层级的沟通 | 链路最长，效果不好 |
| 拓扑 | 同级负责人沟通，再向下沟通 | 链路取中，比较依赖负责人的状态 |
| 动态拓扑 | 不同职能指定特定负责人，再向下沟通 | 链路取中，比较灵活 |
| 网状拓扑 | 任何职能，任何等级的都可以互相沟通 | 链路最短，效果最差，最灵活，只有在部门小或者某些小事情上可以如此 |
总结：公司级别的决策以及下发都建议树型沟通；日常公司的运行建议普通拓扑；一些具体项目的推进实施，可以动态拓扑；细节的琐事，反馈机制，可以考虑网状拓扑。
敏捷教练类型
编写中。。。
