- 浏览: 162568 次
- 性别:
- 来自: 华东
文章分类
最新评论
-
chen_miao:
我是初学者,请问,我在flex设计好了带有按钮和下拉框的界面, ...
ruby+flex实现天气预报 -
barrytyh:
很多技术人员都有想法,但忘了一个根本性的问题,谁在给你MONE ...
互联网创业与软件开发 -
fireflyman:
囧......
关于并发和并行 -
fireflyman:
你老再次出现了
谈谈互联网新产品如何起步 -
qhh394141930:
写得很详细,受教了。谢谢!
从瀑布模型、极限编程到敏捷开发
在上篇文章里,我简要谈了项目管理中的需求开发和管理,那么在这篇文章里就和各位以闲话家常的方式讨论下项目规划和项目监控。项目规划、项目监控其实也是项目管理中比较核心的工作,也是很多开发人员最敏感的话题,因为这两个东西与公司的领导和员工关系都非常的密切。
先从我以前的学校说起,以前我们学校有片荒地,当时的领导觉得学校应该搞绿化,于是组织在荒地上植树,不到一年换了一个校长,这位校长觉得学校应该抓体育运动,决定再造一个足球场,于是把树移走,造了一个足球场,再后来北京奥运会来了,学习为了迎合绿色奥运的理念又开始植树,这就是没有规划和监控的典型例子,结果是劳民又伤财。当然对于学校来说,有国家财政的支持,有资本这么折腾,可是对于小公司做项目来说,这么折腾几下估计很快就要牺牲了。
事实求是的说大多数小公司在这两个方面做得很少有令人的满意的,小公司的老板其实也会意识到公司在项目规划和监控方面做得不咋地,但很少能做到有效的改进,其实这个也是有很多方面的原因的,以我自作多情的猜测主要有以下两个原因,对于小公司,尽管盈利不是很多,但基本还是可以撑下去的,老板会觉得管他乱不乱,公司总之每个月还是有盈利的,少就少点吧,多干几年自己的下半辈子基本有别墅有车了,所以比较保守,要是改革吧,万一鸡飞蛋打怎么办?还是本分点好,小心使得万年船。其实是对项目规划和监控其实需要大量的成本,老板觉得钱应该花在刀刃上,搞这些东西就是在务虚。再者更恶劣的老板有病就乱烧香,就有想想借助CMMI这个洋玩意治病的,其实很多老板都蛮喜欢CMMI的,CMMI就是假定人就是一个机器的部件,可以替换可以不停的运转,总之管机器总比管人省心吧,结果是万分的矛盾,银子撒了一大把,收效却甚微,甚至比以前更乱,大家做的都不开心。与其听咨询师们拿什么高深的方法论来瞎掰,不如我们谈点实际的,想就以下议题来和各位消遣。
1 工作量估算
对于工作量估算很多项目经理(老板)喜欢用数学公式来计算,可能数学公式更加的客观和科学,ok,,看看市面流行的计算方法吧,最常见的是基于代码行的数学模型,那么这里存在不少问题,工作量估算主要是为了在项目进行中进行有效的项目监控,那么软件开发尚未结束,谁知道最后的代码行有多大?代码经常会被修改,那么修改的代码算不算?如果算,那么代码修改越多难道能说明工作量越大?代码效率的区别也是很大的,假如一个10行代码可以实现的东西被写成50行,难道能客观的反映工作量?还有2种比较高级点的方法是基于功能点和COCOMO的方法,那么我想问的是它们的公式中的系数该怎么定?那么不少咨询师忽悠我说,根据自己的实际情况来定呗,那么我想问的是,算命是迷信,电脑意味着科学,那么用电脑算命算不算迷信?所以我是主张这里还是要靠人的经验来估算,大家可以在项目周会上对工作量进行充分的估算,在估算时要同时考虑到项目执行的难度,根据经验给出合理的评估。
2 任务分配
大多数的做法是将整个项目划分成一个个可以独立执行的原子任务,这些任务要划分优先级和难度,至少心理有个数,并且每项任务要制定负责人。那么问题就出在这个任务分配上了,软件开发是一项智力创造的活动,如果按CMMI假设的那样,在分配任务时忽略人的因素是万万不可取的,我就有血的教训,不久之前做一个ruby的项目,然后开始在公司内部随便抓了几个有点ruby基础的人,也没太顾忌别人的想法。做着做着,觉得他们有点心在曹营心在汉,平时还是抱着本thinking in java看,做ruby也是在敷衍了事,结果是代码质量不行,需要大规模的修改。当然按理说员工应该服从公司的安排,做一样就要做好一样,但员工也有员工的规划,你去叫他做他压根就不喜欢的事只能说明管理有问题。
另外还有一个普遍性的问题是能者多劳,有个朋友刚进公司动手能力很强,也非常的积极,每次做项目都分给他最难最累的任务,做着做着也就厌倦了,这时老板会忽悠你说,你能力强,要挑起公司的大梁,以后公司壮大了给你个什么职位,我觉得这就是在扯淡,这就是我经常见到的忽悠式的管理,很多管理手段完全靠人情,很多人都是在这种环境中被忽悠长大,到最后怎么样?被忽悠了几年还不是另谋高就了,所以指望人情化管理的公司很难长大。我觉得该讲原则的地方就要讲原则,在任务分配上给能力强的分配少而精的任务,而且要考虑到员工自己的想法,有些人想做java架构师,你叫他做oracle dba就不合适,有些对ui设计感兴趣,你叫他做系统分析员也不合适,有些人就喜欢搞技术,你硬要叫他做管理也是不合适。
3 进度管理
在做进度之前,一项最重要的任务是识别关键任务,很多进度表进行任务安排时将各项任务平均分的特点为觉得极不合适,有些任务比较难处理,而且许多后续任务依赖于该项任务,那么这项任务就应该配备更精良的人手和充裕的时间,依我的经验80%的时间都是在处理这些20%的关键任务上。这里还有个比较重要的问题是时间安排,我听很多项目经理说时间安排要尽可能的紧,也就是比预计要靠前,这样员工才有紧迫感。我觉得这是不可取的,首先即使你按原计划进行,八成也是要要延期的,那么这就会导致项目严重延期,长此以往,项目延期成了家常便饭,不延期反而不正常,于是大家都成了老油条,那么进度表不就是废纸一张,毫无约束力而言吗!我觉得根据实际情况指定个合理的进度表是比较重要的,或许你会说项目还是在延期,那我觉得是你项目估算没有做好,项目延期在10%左右比较正常,否则就可以调查是什么原因导致进度滞后,如果是客观原因,以后完全可以延长项目时间,总之一个合理的进度表比较重要。
4 项目奖金
这里牵扯到一个钱的问题,据我了解国内大多小公司很少有项目奖金这么一说,年底给点路费就不错了!国内的大多数项目经理更像是一个技术负责人,根本没有用钱的权利,我就曾像公司申请项目奖金,结果计划全盘泡汤,给的理由很荒唐,说项目奖金不好分配,给张三多一点吧,李四不爽,反之亦然。我心理暗自想:“你丫不想给就直说呗!”,这里会导致一个问题,就是“项目经理”凭什么约束成员,大锅饭的道理我也不想再解释了,总之结果就是3个月的项目就得做个5个月,其实老板的小算盘看似很精明,其实未见得,虽然项目奖金能省就省了,那么工作效率的下降所带来的成本的提高,孰轻孰重?长远一点说,产品质量的下滑导致的项目维护的成本你计算过吗?依我的经验,3个月的有效工作时间其实也就是1个月,这已经不错了。不过项目奖金的分配确实是个难问题,但有没有项目奖金和分配合理与否是2码子事吧?由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题,只得望梅止渴,看看人家华为了,员工根据能力分等级,加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋,这个问题需要更深入的讨论。
先写那么多,有时间继续……
评论
这里牵扯到一个钱的问题,据我了解国内大多小公司很少有项目奖金这么一说,年底给点路费就不错了!国内的大多数项目经理更像是一个技术负责人,根本没有用钱的权利,我就曾像公司申请项目奖金,结果计划全盘泡汤,给的理由很荒唐,说项目奖金不好分配,给张三多一点吧,李四不爽,反之亦然。我心理暗自想:“你丫不想给就直说呗!”,这里会导致一个问题,就是“项目经理”凭什么约束成员,大锅饭的道理我也不想再解释了,总之结果就是3个月的项目就得做个5个月,其实老板的小算盘看似很精明,其实未见得,虽然项目奖金能省就省了,那么工作效率的下降所带来的成本的提高,孰轻孰重?长远一点说,产品质量的下滑导致的项目维护的成本你计算过吗?依我的经验,3个月的有效工作时间其实也就是1个月,这已经不错了。不过项目奖金的分配确实是个难问题,但有没有项目奖金和分配合理与否是2码子事吧?由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题,只得望梅止渴,看看人家华为了,员工根据能力分等级,加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋,这个问题需要更深入的讨论。
先写那么多,有时间继续……
我以前也这样想。现在倒过来考虑,给你奖金了,你照样5个月干完怎么办?
所以我们公司的奖金只是逃税的一个手段。平均奖金,大家也就不把他当奖金了。老板也没考虑把它单奖金。-----后来公司改革,抽取了其中10%的奖金做活动奖金,但是其实质只是不给刚毕业的了,给带他的人。其他人照样拿平均奖金 。
分配奖金是高技术活,我们公司改革来改革去,那个领导来搞,年终奖最后还是工资的系数关系。
那让干活的人做估算是最保险的事情,如果是8个人左右的team,那就一块估算加讨论,这样的结果是最真实的,能反映出团队的平均水平。
如果是由某个人来做这件事,未免会比较片面。
温伯格的“中文版”的书中,用的词是“常识”。
大致意思是,推导式的分析很快会在现实问题面前变得不堪重负,
而造成分析瘫痪。这需要通过“常识”来大大降低问题的复杂度。
这种情况大家可以想想如何来下围棋。
o6z的句子,如果改写一下是这样:
O6Z所说的拍脑袋是建立在人类常识基础上,并可以通过其他手段进行辅助,但是中心是人类常识。
我觉得还是直觉比较好。
因为常识里面包括了直觉和一些已经从直觉固化为知识的东西,从而容易叫某些别有用心的人夸大知识的作用,而隐藏直觉的作用。其实任何一种专业化强的职业,直觉方面的作用都是关键性的,比如医生和法律工作者,其关键要求并不是你知识是不是已经具备(具备是必要条件),而是否在经验和直觉方面具备才是充要条件。这也就是为什么这两个职业的入门要求是必须要有数年的从业经验的缘故。
而美国的两个所谓的权威机构,为了自身的经济利益在这两个方面做得事情,恰恰说明了人类意识中卑鄙和龌龊的一面(一个是IEEE,一个是SEI)。
温伯格的“中文版”的书中,用的词是“常识”。
大致意思是,推导式的分析很快会在现实问题面前变得不堪重负,
而造成分析瘫痪。这需要通过“常识”来大大降低问题的复杂度。
这种情况大家可以想想如何来下围棋。
o6z的句子,如果改写一下是这样:
O6Z所说的拍脑袋是建立在人类常识基础上,并可以通过其他手段进行辅助,但是中心是人类常识。
其实拍脑袋并非我自己独创,实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情,只不过要看你如何拍。
如果你去研究psp的过程,会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾,以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程,是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人,大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了,其中还是有很大的欠缺,特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的,是值得我们仔细认真虚心的学习领会的。
在后期确实很多精确性的估算方法,但是,在很多固定期限的合同中,是在需求不是很明确下的情况下估计的。但是这些估计也很必要,因为要确定报价。这个阶段是很难进行估计的,但不估计,纯粹拍脑袋更不合适。拍脑袋可能误差200%,正式的估算方法可能把误差缩小到60%-70%。
我没有看到过所谓正规的估算方法不是基于拍脑袋的(不是拍脑袋就算不上是估算了),这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的,只要在一定限度之内就可以了。而拍脑袋的能力高下,决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确,不存在(不仅仅是实际上不存在,而且是理论上不存在,并且是经过数学严密计算证明过的)一种方法可以不依靠人的这种拍脑袋能力,对未发生的事情进行合理的预期,更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题,没有什么商量的余地。
看来我们对拍挠脑袋的理解不一样,呵呵。我所说的拍脑袋是未使用任何的预先定义的估算方法。当然最终都是人在做决定,什么都可以说是拍脑袋,但讨论这个就没有意义了。
我所说的拍脑袋是建立在人类直觉基础上,并可以通过其他手段进行辅助,但是中心是人类直觉。
实际上人类直觉的可靠和高预测能力,特别是面对高复杂和多头绪的场景是大大高于现有其他方式的。这一点你可以去学习学习实验心理学。而人类的这个直觉能力,还可以通过不断的总结和回顾进行加强,这也就是我多次强调psp的那个方式价值的原因。
而采用预先定义的估算方法的根本问题,在于数学的理论证明未来不可预测,从而证明这样的方法理论上站不住脚。第二,由于这种预测涉及的要素太多,那么这个预定义的方式所耗费的代价也必然会十分巨大;而同时如果这个耗费不大,也恰恰可能说明,你考虑的要素太少。
第三,由于预定义形式往往给人造成是基于客观的错觉(而其推演方式和最初的书籍启动点往往又是直觉的),从而造成其预测的观点对最终结果的影响力国强,也就是为了证明其预测的正确往往会为了预测结果而结果的后果。当然基于直觉的方式也存在这个问题,但是由于直觉的随意性比较强,而且使用直觉的时候往往是集体直觉而不是单体直觉,从而冗余性会抑制这种对结果的自我校正。
其实拍脑袋并非我自己独创,实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情,只不过要看你如何拍。
如果你去研究psp的过程,会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾,以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程,是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人,大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了,其中还是有很大的欠缺,特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的,是值得我们仔细认真虚心的学习领会的。
在后期确实很多精确性的估算方法,但是,在很多固定期限的合同中,是在需求不是很明确下的情况下估计的。但是这些估计也很必要,因为要确定报价。这个阶段是很难进行估计的,但不估计,纯粹拍脑袋更不合适。拍脑袋可能误差200%,正式的估算方法可能把误差缩小到60%-70%。
我没有看到过所谓正规的估算方法不是基于拍脑袋的(不是拍脑袋就算不上是估算了),这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的,只要在一定限度之内就可以了。而拍脑袋的能力高下,决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确,不存在(不仅仅是实际上不存在,而且是理论上不存在,并且是经过数学严密计算证明过的)一种方法可以不依靠人的这种拍脑袋能力,对未发生的事情进行合理的预期,更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题,没有什么商量的余地。
看来我们对拍挠脑袋的理解不一样,呵呵。我所说的拍脑袋是未使用任何的预先定义的估算方法。当然最终都是人在做决定,什么都可以说是拍脑袋,但讨论这个就没有意义了。
其实拍脑袋并非我自己独创,实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情,只不过要看你如何拍。
如果你去研究psp的过程,会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾,以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程,是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人,大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了,其中还是有很大的欠缺,特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的,是值得我们仔细认真虚心的学习领会的。
在后期确实很多精确性的估算方法,但是,在很多固定期限的合同中,是在需求不是很明确下的情况下估计的。但是这些估计也很必要,因为要确定报价。这个阶段是很难进行估计的,但不估计,纯粹拍脑袋更不合适。拍脑袋可能误差200%,正式的估算方法可能把误差缩小到60%-70%。
我没有看到过所谓正规的估算方法不是基于拍脑袋的(不是拍脑袋就算不上是估算了),这一点不需要争论了。同时确定报价也并非是必须准确的知道项目规模的,只要在一定限度之内就可以了。而拍脑袋的能力高下,决定于经验积累的能力。这也就是为什么我比较欣赏psp在这个方面努力的最根本理由。
但是我们必须要明确,不存在(不仅仅是实际上不存在,而且是理论上不存在,并且是经过数学严密计算证明过的)一种方法可以不依靠人的这种拍脑袋能力,对未发生的事情进行合理的预期,更加谈不上什么能够把它的误差同另外一个什么东西对比了。这个是一个科学的问题,没有什么商量的余地。
其实拍脑袋并非我自己独创,实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情,只不过要看你如何拍。
如果你去研究psp的过程,会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾,以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程,是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人,大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了,其中还是有很大的欠缺,特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的,是值得我们仔细认真虚心的学习领会的。
在后期确实很多精确性的估算方法,但是,在很多固定期限的合同中,是在需求不是很明确下的情况下估计的。但是这些估计也很必要,因为要确定报价。这个阶段是很难进行估计的,但不估计,纯粹拍脑袋更不合适。拍脑袋可能误差200%,正式的估算方法可能把误差缩小到60%-70%。
其实拍脑袋并非我自己独创,实际上cmmi的官方方法psp/tsp就是建立在拍脑袋的估算基础上的。当然我这里强调的是拍脑袋并不是啥坏事情,只不过要看你如何拍。
如果你去研究psp的过程,会发现其预估是建立在一个对于开发过程的数据和流量进行记录和回顾,以及对产出进行统计和对比的基础上的。这其实是一个强力的经验养成和积累的过程,是一种提供快速提高拍脑袋结果的准确性的好方法。可以说任何想提高拍脑袋水平的人,大概的路子也都是这个。当然我并不是说psp的做法在实施层面就很好了,其中还是有很大的欠缺,特别是公式和统计方法和统计数据选择方面还有很多问题。但是这个方法的框架和组成形式是好的,是值得我们仔细认真虚心的学习领会的。
哼,小公司尤其需要干劲,但经常是干着干着就没劲了,靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲,使之细水长流……
小公司的干劲是靠市场和金钱来刺激的,不是靠条条框框的规章制度,小公司的管理完全靠人,靠领导的人格魅力,干的没劲是觉得没有希望,如果有希望 ,会继续充满激情的。
不同意唯金钱论,金钱激励很重要,但不是全部,小公司经常公用许多新人,相比之下融入感,成长机会,相互尊重等有时候比金钱更有激励作用!小日本这方面就有独到的地方!不是发钱就能解决所有问题,不是所有公司都有那么多钱
我曾在一个公司干了三年,多次被项目经理气的要辞职,体会到了“逼走员工的是中层管理者”的看法。还有架构师,CTO,甚至人际资源经历和销售部人员的关系都非常重要。如果割裂的把管理仅仅考虑成极其理性的事情我认为还是有些表面化,不够适合中国国情和人性
再声明一下,我非常讨厌代码行数这个东西,虽然有时候不得不统计这个东西,不同的人代码行数差异太大了。喜欢copy的人代码行数非常大,技术好的行数小。我印象中一个家伙写个登陆,这么简单的页面就用了3000行代码,你说说项目都这样做,那规模好大呀,一个人一天都能完成几千行的代码。呵呵,吓死人。
缺乏代码评审
项目管理的核心是找的合适的人做合适的事情,其他一切都不能称之为核心。你可以称其他要素为关键的,重要的,但是绝对不能说是核心的。计划和计划实施过程的监控自然是重要的,但是绝对是最重要的。
估算和计划,我在这个论坛已经说过很多次了。基本上说,最靠谱的估算就是基于经验的拍脑袋的做法。当然培养这个估算的能力,是有一个过程的,并且我推荐可以将PSP的做法加以改进,以加强自己的复习工作,从而可以很快的提高自己的估算的能力。当然这个地方有很多的策略和各种策略的优缺点,以后专门讨论的时候再展开。
至于任务的分配和进度的确定,这个方面我以前也说过很多了。这里我需要强调的是,任务和需求的粒度化其实才是解决这些问题的核心基础实践,没有这个基础,基本上这些事情仅仅就是一种纸上谈兵。
至于说绩效考核以及分配,这个话题太大,而且专业性太强,我建议大家不要着急讨论。
总的来说,我觉得楼主可能看PMP之类的东西太多了,中毒了。
可能我还停留在见山是山,见水是水的境界,我觉得:
觉得拍脑袋是最好的方法,本来就是一种悲观的做法,我不知道你是不是试过所有方法,认真思考过才这么说的。
首先要有一个估算的意识,任何工作都可以用科学的眼光来看待它。就像以前很多迷信现象都被现在的科学验证了,可以说是从现象看本质的过程。
只能说估算这门学科还停留在不成熟的阶段,我比较相信功能点和代码行。至于调整因子,我觉得不要用的太多。
至于代码行,在同一种技术框架下,代码行还是非常准的。
拍脑袋(delphi法)适用于售前,功能点适用于需求规格说明书完成,代码行适用于代码稳定之后。后两种可以用于实际的生产率度量。每个企业都应该定义自己的估算方法和模型,基于自己的历史数据。
另外,一般拍脑袋都是人天,人月,规模是很难拍脑袋拍出来的,是客观的。像你自己说的,和时间打上关系就不准确,不客观了。
总之,拍脑袋过于依赖个人经验,无客观的度量基准,无法利用统计过程方法进行分析,无法利用行业数据。
当然,有时候也是很准的,因为这是“人工智能”。
哼,小公司尤其需要干劲,但经常是干着干着就没劲了,靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲,使之细水长流……
小公司的干劲是靠市场和金钱来刺激的,不是靠条条框框的规章制度,小公司的管理完全靠人,靠领导的人格魅力,干的没劲是觉得没有希望,如果有希望 ,会继续充满激情的。
管理是什么?指条条框框的规章制度?
哼,小公司尤其需要干劲,但经常是干着干着就没劲了,靠一时的激情和干劲撑的住一年我就佩服你的毅力。
所以需要管理这种干劲,使之细水长流……
发表评论
-
谈谈互联网新产品如何起步
2011-02-16 17:56 1270很多时候, 我们刚做完一个互联网产品,由于产品很粗糙, 功 ... -
育娃网---探索国内育儿社区的新思路
2009-12-22 19:55 310个人认为,这个市场是一个充满前景的垂直行业,到底应该从哪 ... -
关于社交网络的一点思考
2009-09-23 12:16 1717只要是给人设计的 ... -
对产品和运营的几点思索
2009-09-07 22:04 20941、做一个产品需要首先考虑,是卖内容还是卖功能, 切不可都做 ... -
命运掌握在自己手中
2009-09-07 13:57 747李彦宏独家撰文:命运 ... -
强者必学的定律
2009-07-06 10:03 7901、蓝斯登原则:在你往 ... -
如何快速通过CMMI评估
2008-12-15 11:39 1398终于访谈结束 ... -
对WebGame行业的一点看法
2008-09-22 10:20 1373之前不怎么上 ... -
如何进行项目跟踪
2008-09-08 19:52 1837项目跟踪主要针对计划,是为了了解项目的实际进展情 ... -
CMMI 名词辨析:检查点 里程碑 基线
2008-09-06 10:02 2573我实施CMMI的过 ... -
互联网创业与软件开发
2008-09-04 22:57 2136最近与一位创业公司的朋友私下交流了一些项目管理和软 ... -
创业公司如何用人(转CSDN老紫竹的一篇颇有见地的文章)
2008-08-29 14:32 4170创业不是用钱就能堆 ... -
新手到底新在什么地方
2008-08-22 21:29 2142接触项目管理也有一段时间了,给我感触比较深的还是 ... -
从瀑布模型、极限编程到敏捷开发
2008-08-18 21:11 2871软件开发是一种对人 ... -
QA真的能保证质量吗?
2008-08-15 21:20 4295我最早接触QA是去年在一家大型制造型企业实习的时候,在这种企业 ... -
我们不是在做技术决策,我们在玩
2008-07-31 12:58 3346在这里我不想一 ... -
小公司如何做项目管理(上)
2008-07-21 08:09 2328我所在的公司和大多数国内IT公司一样,十几到几十人的规模,每 ... -
如何编制软件测试用例
2008-06-20 12:52 1982如何设计编制软件测试 ... -
阿里要走102年 阿里的工程师能走多远?
2008-03-19 20:30 1225转载自 http://java.csdn.net/index. ... -
如何快速通过CMMI评估
2008-03-14 22:12 1252终于访谈结束 ...
相关推荐
信息技术有限公司的项目管理手册是企业规范项目操作、提高效率、保证质量的重要文档。这份手册详细阐述了项目管理的各个环节,涵盖了从项目启动到结束的全过程,包括职责分配、项目整体管理、项目范围管理、项目进度...
小项目管理不仅适合于软件开发也适合于日常的IT项目管理。
项目管理在公司管理中的重要地位体现在以下几个方面:公司业务项目化管理的方向、应用项目管理的公司实例、项目管理的能力和水平将构成新经济时代的个人和组织的核心竞争力。 创新管理与项目管理 创新管理与项目...
【公司项目管理流程、规范、制度和考核办法】 项目管理制度是企业管理的核心组成部分,它旨在确保公司的投资项目得以高效、有序地进行。本制度旨在强化和规范公司对内投资的技术改造和基本建设项目,通过明确责任...
IT项目管理管理办法介绍 IT项目管理管理办法是确保IT项目的成功实施和交付的关键步骤。该办法涵盖了项目管理的整个生命周期,从项目准备和计划到项目实施、项目交付和项目关闭。该办法旨在确保项目的质量、进度和...
### 敏捷项目管理概述及最佳实践 #### 敏捷项目管理的概念 敏捷项目管理是一种以用户需求进化为核心、采用迭代、循序渐进的方法进行项目管理的方式。它强调在整个项目周期内持续地评估和调整策略,以确保最终产品的...
【项目管理在小公司的实践与挑战】 在小公司中,项目管理往往面临一系列独特的挑战。由于资源有限,人员配置相对较少,公司的管理层,尤其是老板,往往身兼项目经理的角色。这样的情况使得决策流程变得集中,而缺乏...
在本项目中,合同的名称是“图书管理系统项目管理”,委托单位是Bit金融商务大学,承担单位是中国软件有限责任公司。合同的签订日期是2016年3月21日,项目的起止日期是2016年3月至2016年6月。 二、生存期 生存期是...
项目管理知识小贴士全集
《项目管理概论》是项目管理领域的一门基础课程,主要涵盖了项目管理的各个核心环节。这份"项目管理概论网课习题答案.zip"压缩文件,针对的是南开大学提供的网课学习资源,其中包含了课程的期末习题解答,为学习者...
在IT行业中,项目管理是一项至关重要的任务,它涵盖了项目的整个生命周期,从启动到收尾,确保每一阶段都得以顺利进行并达成预设目标。"项目管理表格模板"为IT项目经理提供了一套完整的工具,帮助他们有效地组织和...
《项目管理案例.zip》是一个包含了41个具体项目管理案例的压缩文件,这些案例以MPP格式呈现,是Microsoft Project的文件类型,专门用于规划、组织和管理各种类型的项目。通过对这些案例的学习和分析,我们可以深入...
对于项目管理中的工作分解结构(WBS),它是将项目分解为更小的可管理部分的过程。这些部分通常指工作包或活动,每个部分都有可交付的成果。在WBS中,最底层的可交付成果或项目工作称为工作包。而项目管理过程中的...
智慧美容小程序源码+项目说明(支持全国连锁美容机构线上客户管理、门店管理、商品管理、项目管理,支持在线预约,在线下单,特色项目展示等功能).zip 智慧美容小程序源码+项目说明(支持全国连锁美容机构线上客户...
6. 从文件中提到的“2019年下半年信息系统项目管理师下午真题及答案”这一知识点可以了解到,小任老师对于历年真题的收集和解析工作相当重视,能够提供清晰、准确的真题资料和答案。考生通过研习这些资料,能够对...
一页纸项目管理,就像一只麻雀,虽小但五脏俱全,完全可用于人数较少的团队,既可以很好地做计划,又可以很好地向上司报告,真是一举两得。 既然如此,那就从概念撸起,看看这一页纸项目管理到底怎么回事,如此好的...
WBS 是一种用于项目管理的工具,用于将项目分解为更小的任务,以便更好地管理和控制项目。WBS 可以帮助组织工作、防止遗漏工作、为项目估算提供依据等。 需求分析 需求分析是指对项目的需求进行分析和确定的过程,...