项目管理简单模型

项目管理简模型杜维君在产品的开发过程中，或多或少存在着问题，有技术问题，管理问题，需求问题等。本人集合自己的认知及工作经验项管理过程中问题简单梳理总为一个简单的项目管理过程原型。该原型适合项目管理流程尚未建立管理规范发员工作经验不是很丰富的组织对日常工作极易疏忽的问题提出文只阐述相关过程关键内容不涉及具体操作方案该模型包含以下几个步骤统标目计划作量量化及过程改进这四个过程中，本人认为第一“系统目标和后一过程改进为重要具原因下面将详细阐述。系目：事开头难，只有第一步做好，才能保证后续工作的正确进行。该步骤并非传统意义上的系统定义的整理工作以将该步骤抽象的描述为义项目成功的标准体容是：在项目的开始，不管是合同类定制项目还是产品类自研项目，我们都可以，也必须要做这样一件事。就是保证各方对“判断项目成功与否”的统一认识。通常这些我们只定义了进度和质量是当遇到进度问题，我们又放弃了质量。但是这里我想提出的是度和质量不是唯一标准们还有应该有其他更加明确的标准先行占有市场（如：技术领先销售额（如：细分市场用户满意度（如：模仿超越级统提高工作效率如：系统优化）等等。在我们项目开发的前期们往对这个步骤做得不够细多我们只是在可行报告中提及相关内容，而且没有量化，具体化，明确化。工量化在这个工作过程，可以很程度上考验一个公司真正的CMMI的水平。软件项目本身就是很难量化的工作“计件些标准化工作流程那样容易统计量化所以软件项目的量工作在们公司还处于一个摸索的阶段且种量化过程必须建立在特定的工作规范，质量标准，考核体系之上的，否则量化无从谈起。该过程包含我们通常所做“项目计划编编写计划的工作应该是按照项目本身的进度来编写而不是按日历表来写而写计划绝不是个简单日程表要涉及很多对项目本身内容的思考，沟通，权衡以及实施过程中可能遇到的问题分析解决时间。其次我很多时候是一次性把作计划写好个过程一个子项的写完然后直接将任务分配给项目组每个人很精准的安排了每个人的时间实情况是我们自以为很详细的工作计划后是有很多没虑到的问题里需要我们思考该如何把任务分解的更加合理。这里说的是更合理而不是更细认为分解程度，取决与对工作量的考核标准。本

人不建议考核到小时，也很难达到那么细的粒度。最后，关于时间安排，不要把项目组成员上班的时间都计划投入到项目中，最好不超过80%工作时间，因为人不时机器，任何一个工作任务变换都需要时间4个小时完成任务，理论上一周可以完成，事实一周可以完成3个经很好。实：实施的过程中我会遇见各种问题，同时也考验项目经理能力的时候。下面就几个容易出问题的地方做简单阐述。、沟在与相关人员沟通时们能无意中承诺别人不可能的事情是们不要做一个明知不可能的承诺坦的和别人沟通利自己的优势说服她们即使不能，也比欺骗的结局要好。对于目标不明确的人，尽量不要完成他的信口开河的要求，一定整理出文档，整理文档的过程，其实也是一个思考确认的过程。、控制管理过程中控制的内容很多，软件项目主要的提及的是“进度”和“质量”控制简说一下我们的误区我常认为项目计划做好要严格按照计划执行好不要变更而实施情况是我在每次的质量控制活动后发有缺陷或者可以提高的地方。可以想象，发现了这些问题后，还是按原计划进行的结果会是什么。、学、培训在每个项目中或或少的总有要去尝试或学习新的过程工具，技术。在这个过程中必须考虑到工作效率的降低为了团队的进度代时值得的。、意缓冲所谓计划赶不上变化情会照我们计划那样一帆风顺的进行下去非我们有上帝一样权力和执行力糟糕的是的客户或领导可能认为这些意外是你的借口当然我们也可以在一始就告知我们经验中曾遇到一些不愉快这样还可以说明我们的深谋远虑。过改：程改进是一个主动提高的过程要队有所进步就必须花些时间去做“过程改进这所说过改进是项目组小范围，并未指CMMI中说的那么浩大工程，而是指类似代码重构之类事项。如果所有的时间都忙于编码，测试等工作中，怎么会有时间去思考，学习，改进，所以这个时间应该制定项目计划时就考虑到。

版本规划该工作属于第一步程中工作内容所以单独列出是因为我们对该项工作太不够重视了。这里所说版本规划并非指源代码的版本控制，而是指产品的版本规划。版本规划好比一个软件产品的蓝图有一定的特定性长远性需要考虑产品的战略定位，市场定位，目标客户的定位，功能定位。如果像申报软件是一个产品族要划各个产品之间的市场细分个品之间定位应该相互补充，不应大而全定位相互重叠。像打印