《网易一千零一夜》项目管理之高度延伸

这种情况主要发生在职能划分的研发团队，各个研发成员按照资源池的形式划分。虽然需求来时，各个职能的tl都会答应，但实际人员到位情况以及支持力度远远不够，很可能导致最后延期。

措施：拉各个职能的一把手开会，当场确定好支持的人员以及到位时间；如果其不能当场确认，也要下班前给出回复。并且，在每个时间节点开始和结束的节点亲自进行确认。

备注：在有些灵活的创业团队，需求的负责人和开发团队的组织也是比较灵活的，因此也需要掌握这点常识。

自我授权

很多时候，领导喜欢给我们工作，却又不明确授权，而我们去跟各个方面接洽沟通的时候，又不得不解释，自己不能顺利、完全发挥自己的能力和工作内容。

措施：把领导以及相关人叫齐，正式声明自己的工作职责、工作内容，大家要全力配合。其中不要过于担心自我授权后，某些工作做不好，这毕竟是一个过程，没有谁开始就能做好。

备注：另外，要区分好，自我授权与给title的区别。不可否认有些工作是必须某些岗位或者等级才能做的，但领导可能觉得你等级还不够，想让你锻炼下，合格了再给title。也可以理解，但那只是个title，自我授权还是必要的。如果不去主动正式声明自己的工作内容和工作职责，就会名不正言不顺。

需求可视化

这个主要出现在过程的弱管理上，没有敏捷的场景。因为开发总是预估一个模糊时间点，项目经理于是只有节点去问，完成了倒还好，没完成的情况和原因有很多，导致项目不可控。而如果中间去问，开发人员又给不出准确的进度情况。

措施：需求可视化，把一件事提上日程，每天计划做什么，每天过进度，今天应该完成的进度是什么，今天做了什么，明天做什么，最好白板的方式公示。这样明确以后，谁比较忙，谁比较空，哪个需求提前，哪个需求延后了非常清楚，这就是可视化，小颗粒度的项目过程控制。当然了解的人可能会说这不就是敏捷么？对敏捷的特点之一就是需求可控可视，当你的团队不能完整的实现敏捷的时候，在需求控制上实现可视化也是可行方案。这比要求大家发日报、周报来的有效的多，当然如果你的领导想知道项目进度，可以由项目经理进行整理相关节点和进度进行上报，没有必要每个人都去写。

固定沟通渠道

在项目的需求讨论以及研发过程中，大家都是倾向于不回答、不讨论的，尤其人很多或者回答也没有意义的时候。这种在研发团队司空见惯，待久了，大家都会觉得这个团队没有发展空间，没有成长和沟通的土壤。

措施：一定要主动的去问，去了解，最好一对一的去问每个人的看法和建议，去征求大多数人喜欢沟通的方式，建立有效的周期性讨论。如果有一天别人回答的你很少，那么有两种可能：1 根本不想和你沟通，因为不能互相理解或者因为即使沟通有了观点也没有下文 ；2 在自己的认知和能力内，已经对当前的团队和产品没有什么大的建议了。当然大多数情况下，其实属于第一种。

备注：其实固定沟通渠道，只不过为团队打开反馈的窗口，至于是否真的要执行周期性讨论，取决于团队真实意愿和需求。有一点不得不提的是，真正重要的是团队的氛围，要珍惜并重用每个人的看法和能力，让他们有机会说，有机会做，甚至有机会主导。这样，这个措施的目的才是真正的达到。

产品初创阶段

项目如何走向正轨

如何保证需求赶上工期

备注：特别说明关键路径法，也是项目管理中的重要常识，就是找出影响项目主要进度的主要需求，进行需求的拆解、资源调配，来减少工期。