Posts Tagged “管理”
标题这个帽子可能有点大，放着唬人吧。 公司是做管理类软件来，自己也有幸连着参与了公司几个项目的从需求、开发、部署、交付、维护整个流程，算是过了几遍整个项目的”生命周期”了。发现在项目过程中沟通真的很重要，这个沟通包括对外的与客户的沟通，对内与项目小组成员，于boss的沟通，也来简单分享下对于这些沟通的理解吧。 你给任何一个公司打电话一般都是前台接线，或者是自动给你转到分机，或者是前台帮你转接过去吧，想想为什么是这样呢？约定俗成，对就是约定！为了建立起良好的沟通的约定，来完成项目过程中的沟通工作，有这么多工作需要做，按照标准的中式思维，我们需要成立一项目小组，这个小组的成员至少应包括软件提供商的项目经理、客户的主管部门负责人（如果是全公司参与的项目，至少需要一个副总及以上级别的人员），为什么需要这么一个有分量的儿人物，很简单，首先，小兵说话没威信，配合起来效率低，很多的事宜是需要领导拍板才能定论的；其次，管理类项目，如果上层没下决心提高管理水平，上再多的软件、系统都是白搭。需要软件提供商及客户各指派一人来充当前台接线，各种资料、数据的转发，各种问题的汇总等。 需求分析阶段 如果把整个项目中的沟通按重要性从高到低依次画出个1、2、3、4…来的话，需求分析阶段的沟通工作无疑是最重要的，也就是1级重要，这一阶段需要反复的跟客户沟通，确认。而这一块的工作又是最不容易的，管理大师们早就总结出来了“管理无定式”，只要有利于提高本组织的管理，能更好的为产出（可能是产品、也可能是服务、甚至还可能是咨询等等）服务，就是一个好的管理方案。而一般的管理类软件提供商（专业的外包公司除外），都会有一个自己的平台（框架），软件提供商会去根据客户的提出新的需求结合市场要求不断的完善这一平台。这样就极有可能出现极具“个性化”的管理方案，不巧的是这个管理方案中客户要求的某些功能对软件提供商原来的平台冲击很大，当然你客户可能认为这是软件提供商的技术不够好。应该说凡是需要在原来平台下定制的项目（产品实施除外）都会遇到方案给平台带来的冲击问题，只是在管理类项目里这个表现的比较突出而已。
最近一段给客户一个系统做升级，姑且把它定位成一个项目 前期在一个项目会议上经过大家一起讨论，按照BossJ的建议，将整个升级大致分成了3个部分：准备升级程序、准备数据、综合测试。看起来这个是一个不错的升级步骤。我大致做了个Project的，绝对粗粒度滴。 接下来的事情就是按着Project按部就班滴开始干活，由自己负责总控各个部分的进度。 第一阶段程序部分升级：80%的程序是使用原系统的一个新版本，在新版本上增加原来针对该客户定制的部分功能，及已有功能中业务上的小调整；剩下的20%是一个新系统中压根就没有的功能，需要从老版本上加到新版本上，而在老版本中这个功能模板跟其他模块还有很高的耦合。在我跌跌撞撞滴摸索+加班下，终于按时掐着Project上时间按时完成了。 这一部分的工作全是自己一个人来完成，很累！