|
对定制型软件来说，客户需求调研、分析阶段的工作事实上是极其难以把握的。需求分析太深入，时间耽误太多影响后面工作，而且分析的结果还未必能用上，后期客户需求的改变会令对前期分析工作自信满满的系统分析员吐血。需求分析太浅薄，自然后期工作捉襟见肘，不说人们也知道有多少坏处。 项目管理论坛 我对需求分析阶段的最终成果的定义是完成类似于SAP实施的业务蓝图，统一图例。而此业务蓝图是在三天的小组成果报告会议中接受全体项目组成员质询，讨论通过。而此份业务蓝图经过修饰，格式规范，简洁明了，转呈营运总监签字时获得好评。最令大家得意的是，营运总监在大区会议上要求各大区经理规范业务时，就是拿着我们的业务蓝图在做演示。 blog.mypm.net 事实上，需求分析的真正成果是大家都成为某方面的“业务专家”，成为项目中活跃的一份子，能够积极从客户的角度参与后来的项目沟通。 项目管理者联盟 领导 转自项目管理者联盟 项目管理者必须完成领导的职责，我对此的理解是：1决策；2保证决策意图的顺利执行。 项目经理博客 性能和成本永远是一对矛盾，项目经理因此常常陷入两难的境地，这种状况下常常能体现出项目经理出色的对大小、轻重、缓急判断的均衡感。决策能力来源于项目经理的实践经验，是管理者厚积薄发的功力体现。 项目管理者联盟 对于第二项，人们最常说的是“领导是一门艺术”。艺术是发散的，与严谨的二进制逻辑是格格不入的，这常常构成了程序员向管理方向发展的恐慌。虽然作为EC项目的主管对我来说是硬着头皮上，但我始终是抱着学习的态度去面对困难，我一直的心态是“让暴风雨来得更猛烈些吧！”。 项目管理论坛 以我的经验来看，作为项目经理，一个半年的项目下来不吵个20、30架是不称职的，说明项目的沟通存在极大的问题。我没有天生的领导魅力，依靠的只是自己琢磨的两件法宝：1坦诚对待工作上的沟通；2任务本位，区别于官本位。 项目管理者联盟 坦诚就是管理过程中坦率指出别人错误，同时也准备让别人指出自己的错误。这是解决问题变得简单，在项目组中一旦形成传统，大大有益于项目的进行。 www.mypm.net 我始终没有试过威势压人、软硬兼施的领导手段，对其效果难以提出中肯的意见。我觉得交流的目的只是解决一个具体的问题时，交流就会变得简单，当然，经过开始阶段的磨合，我认识到立刻要求别人和自己的思路合拍是不现实的，作为管理者应当宽容。 项目管理者联盟 控制 项目管理者联盟 软件开发项目的管理在我看来是一个比较复杂的领域，它的控制包含了定性和定量的成份，同时项目进程中特有的、大幅度的迭代构成了软件项目复杂性的另一个因素，即所谓的需求变化导致设计、代码变化。 项目管理者联盟 如何能按期、按计划完成EC项目，一直是我考虑的重点。宏观地看，我在项目管理中自觉地用了两级控制。 www.mypm.net 一、总体控制 项目管理者联盟 如前“计划”中所述，项目进程安排两次迭代，而每次迭代过程又包括需求分析、系统设计、代码实现、系统测试四个阶段。 项目管理者联盟 总体控制的目标基本是大目标，采取定性控制的方法。但要说明的是，虽然需要达到的目标是定性的，但阶段成果的体现是具体的、明确的。 比如需求分析阶段，完成的阶段性成果业务蓝图所描述的业务范围、业务深度是很难量化要求的，但业务蓝图本身的表达规范、“人人都是业务专家”的要求又是具体的。 项目管理者联盟 二、具体控制 项目管理者联盟 软件作为一种可以实际感受的产品，最终拿给用户的必须是经过量化控制的。 项目管理者联盟 就目前我们所能采用的手段来看，设计阶段以前的定量控制是难以做到的，比如如何能定量考核设计是否契合需求？所以软件的具体控制是从设计开始的，以设计为核心。 项目管理者联盟 -设计文档必须详尽，并且及时更新。 转自项目管理者联盟 -根据设计文档发放工作单，确定完成时间。 www.mypm.net -页面功能测试和组件测试是依据完全最新的设计文档要求。根据设计文档对软件的测试显然是可以做到定量的。
|
