对团队内项目管理的看法

公司内部，基本是一个部门负责一个项目，项目结束了，部门也就要重组了。一个项目的周期长，并且需要多个部门的人员协同配合完成，比如开发分为应用开发和平台开发，测试也分为平台测试和应用测试，实施的是工程人员，多个部门的人协同完成一个项目。平台是多个项目可以复用的，应用的东西可以部分复用，工程数据基本不能复用。我身处平台开发，对这种众口难调的项目实在是体会颇深。加上目前3个项目同时使用平台，更是让人头大。

从平台开发的角度看，管理真是问题多多。

每个小团队都有一个对外的接口人，还有一个负责跟进进度的人。每次前端出现问题，都由接口人传话给进度跟进人，然后再传给开发人员。开发人员还得返回去再找测试、找工程确认问题到底怎么回事，由于平台开发不了解前端应用，测试和工程说不清具体问题，还得找到应用开发才能解释清楚，一个问题想要弄清楚，真是不易，沟通的缓解太多了。

记录问题的工具太原始了---excel，你能想象到一个excel，列出无数个问题，每周或者隔断时间大家一起过问题的场景的吗？基本上一天就白费了，确认问题需要谁解决，搞不好还要分析分析原因，让人很是挫败。过很长时间以后，可能问题已经解决了，你会在TFS中再次看见这些问题的身影，让你填原因.......时隔多日，谁还会记得当时查出的原因是什么？甚至恍惚觉得这可能是个新问题。

不知道从什么时候开始，项目组里干活的人越来越少了，都变成了接口人。都开始负责传话。以前开发干的不好的人，都变成了接口人，给干活的指派工作。真是会干的不如会说的。太多人给我当保姆，都能感觉到团队成员的自觉性下降了，出现问题的时候不会像以前那样积极主动了，除非保姆找到某个人，才出动查问题。

出现问题的时候，都开始互相推脱，都说不是自己的问题，作为前端的我很是痛苦，基本上所有的问题我都要参与查，查到最后可能发现80%都不是我的问题。

如果我有机会作为一个项目的管理者，我希望能避免以上的各种问题。

1、扁平化管理。

一个小组一个管理人就够了，负责对外接口和进度跟进。不传话。

2、用统一的工具管理问题、需求

让每个人明确自己的问题、需求项。管理者可以明确看到问题和需求的进度。

3、不留冗余岗位，不留保姆

多重管理导致团队积极性下降。技术接口人一定要是懂技术的，否则既没有工作能力，也没有让众人信服的能力。