项目经理修炼之道(1) -- 给软件开发建模 .

简介: <p>#成为项目经理是需要积累的,如果你想快,但不想付出,那求神拜佛比较好。</p> <p>#这系列文章是写给想成为项目经理,但又愿意努力的人的。</p> <p><br></p> <p>当我们开发软件的时候,很多人知道要为目标软件建模,好开发需求。</p> <p>而成为项目经理自身也是一种需求,为进一步开发其关键点,事实上也需要建模---为软件开发自身建模。</p> <p><br

#成为项目经理是需要积累的,如果你想快,但不想付出,那求神拜佛比较好。

#这系列文章是写给想成为项目经理,但又愿意努力的人的。


当我们开发软件的时候,很多人知道要为目标软件建模,好开发需求。

而成为项目经理自身也是一种需求,为进一步开发其关键点,事实上也需要建模---为软件开发自身建模。


项目经理更类似帅才,单项未必是最优的,但在开发软件时必须统筹全局。

而统筹全局的前提则是对软件开发自身形成了自己的想法,自己的道,这里的“道”,即是属于你自己的软件开发模型。


让我们从最简单的开始。


软件项目的基本输入是:人,需求和工具。

其中人是团队成员,需求是原始需求,工具则是Visual Studio这样的东西。

这三者不是不可改变,但在限定时空背景下,选择有限,因此认为他们是一种输入。


与软件构建相关联的主要手段有:管理,流程,估算,开发模型(瀑布,迭代),需求开发,设计编码,测试


软件项目的输出是:软件产品,软件产品可以用功能和非功能两个质量维度进行度量。


而从输入转向输出的过程中则受三个维度的因数影响:

商业因素,项目政治因素,技术因素。

商业因素是指和赚钱相关的事。比如:一个需求可能做的很好,但最终被取消了,因为准备在下一个版本中放出来。

项目政治是指和人情有关的东西。比如:A和B就可能有点个人恩怨,没法合作,但偏偏项目有同时需要这两个人。

技术因素则是指各个环节的内在合理性。比如:设计就应该符合高内聚,低耦合的原则。


单纯的任何一个维度都不足以保证项目的成功,都只是一种筹码。

你手里的筹码越多,天平越向胜利这一端倾斜。倾斜到一定程度后,结局出现,或赢或输。


上面的各个因素还可以进一步细分,比如管理又可以分为:管人,管事,管物。

其中管人最重要,所以所谓管理项目,首先是管人,人管不好,别的是扯淡。

假如队伍中没一个人有基本的责任感,那么即使把PMBOK,CMMI倒背如流,项目该失败,还是失败。

这是后话,这次不提。


如果想成为项目经理,首先要形成一个属于自己的,覆盖软件开发各个领域的模型。

并给出一个属于自己的,对模型中每个角色的定位。

相信项目经理每天只要喝喝咖啡,不需要懂什么就可以了,就和相信赵括同学能打好仗一样,是危险的。


上面的模型远不完善,但故事已经很长,因此说修炼这事需要点耐心和积累。


眼下似乎没有把软件开发关联要素作为一个整体进行考察,帮助每个人形成自己的“道”的书。

更多的书,强调的是某个单独的维度:面向对象,编程语言,设计模式,敏捷,种种开发平台等等。

事实上在项目面前,所有这些都只是筹码,在不违反法律和社会道义的前提下,做项目本就应该“不择手段”。

但只有形成了自己的道,才能很好的驾驭这些手段,一旦反过来被这些东西所驾驭,那就容易偏狭

相关文章
|
项目管理
产研项目管理-实用经验
项目管理方法是一门通用技能。当你正在管理一个项目时,如果没有系统的方法,那么只能事倍功半。项目管理用结构化的方法告诉我们:如何就目标达成共识,如何与相关方协作,如何拆分工作,如何控制项目工期,如何达成项目目标,从而为公司收益做出贡献。
655 0
|
架构师 项目管理
项目管理修炼之道札记:创造出色团队
项目管理修炼之道札记:创造出色团队
121 0
|
Java 项目管理
艾伟也谈项目管理,软件架构引言之项目管理的问题
  软件架构引言之项目管理的问题     很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?     不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是“进度拖延”。
1112 0
|
项目管理 测试技术 数据库