今天一个地市级系统管理员在跟我埋怨一个功能中时间点没有做限制处理。表面看是很简单。其实是个比较复杂的问题。我的答复是可以把这问题反映给你们省公司负责这块问题搜集的人员，然后综合各家地市负责人的意见，最终进行评审看是否需要进行程序完善，如果需要完善那么我们还得考虑各种因素做出设计，最终还需要你们的专家团队评审，通过之后我们才能进行程序修改，经过测试、验证后才能进行部署更新。

 他听完后，说了一句：“我晕，这个是程序是否完善的基本条件吧，还要提需求才弄，我无语了”。

  后来经过我的耐心分析解释，他同意了我的说法。

我是这样告诉他的：我们也知道那个功能简单，就是一个限制问题，但是这个是一个严谨的问题，不说是说修改就修改，涉及到的算法和牵连的问题很多。现在系统中出现一些小问题，也不能说是某一方的问题，在贵公司这边就没有人跟踪这些问题，应该有一套完善的机制来处理，比方说各局发现有些不合理的地方，应该怎么上报，报给谁，然后由谁组织大家进行讨论，是否能进行修改，最终怎么处理，这些都没有人来做。

问题出现了。就是这个机制在这么大的项目管理中为什么没有呢？据了解之前是存在的，并且由专人负责搜集问题，然后和我们厂家和用户之间进行沟通协调进行解决。随着项目进入了维护阶段，这些机制就被丢了。再加上客户方负责人变更，我方现在项目经理没有及时进行沟通导致。

  从上面问题我们可以得出两个问题：

第一是沟通问题。我想到的是沟通应该是一个持续的问题，不应该随着项目进入运维阶段就不再进行，一套完整的机制应该是一直要存在，并且不断完善的。如果有这些完善的沟通机制，不但能增加与客户之间的信息传递，说不定还能带来新的项目机会。

  第二个问题需求管理的问题，客户认为这个问题是很简单的，你给我处理就是了，为什么还要那么麻烦的进行上报、评审这些。我暂且不讨论需求的管理。我想说的是这个问题在我看来也可以算是第一个问题“沟通问题”，之前如果有好的沟通方式，有好的问题收集、问题评审，有好的交流方式，那么第二个问题就迎刃而解了。

以上是我的个人看法，对项目管理中的一点理解。