-
编辑 删除
项目（FBMS）总结－管理篇(1)
本文可以任意转载或分发,但请注明作者和出处。 面临的困难很多，如何能够在两个月时间内完成这么一个项目？我们还是一步一步的来看看把。 项目组在项目启动之日（2005年7月4日）成立，...
-
编辑 删除
项目（FBMS）总结－简介篇
本文写于2005年12月，由于某些原因未能公开，现在一晃过去2年又多，早已是物是人非，回头看看这篇文章，当时的情景还是历历在目，让人感概良多，用一句时髦话总结：“很傻很天真”。不敢独藏，与各位同行...
-
编辑 删除
绩效管理之KPI设定_程序员
参考了一些文档，暂且定义如下：岗位职责：1完成项目经理安排的开发任务；2按照详细设计文档编码； 3对所负责的开发模块进行单元测试并通过； 4修改测试部门反馈的缺陷；5对使用公司或部门产品/框架提出反馈意见...
-
编辑 删除
绩效管理之KPI设定
今年准备实施绩效管理，在设定研发岗位KPI时一时感觉还是比较的迷惘，那些需要定量考核，那些需要定性考核？定量考核的以什么指标量化？定性考核的如何说得清楚明白？问题很多.........
-
编辑 删除
不要让客户牵着鼻子走
跟客户高层开例会,关于项目终验,首先由信息技术科介绍目前系统没有完成的功能,说了一大通之后,让开发方根据这些未完成功能提出意见.这其实是走进了一个圈套:因为客户反馈到信息技术科未完成的范围是不定,有变化的,结...
-
编辑 删除
项目终验
项目进入收尾临门一脚阶段，由于平时关注于客户更关心和紧迫的需求变更和新增需求，反而忽略了原始需求未完成的模块。范围管理没有做好，结果在项目收尾的时候发现遗漏了部分需求：血的教训啊！...
-
编辑 删除
测试漫谈：需要由SA去做测试吗？
SA:系统分析员。如果测试人员熟悉需求或者测试用例经过SA和QA Manager的严格评审，可以说，是不需要SA去做测试的。这样做的代价是在测试人员需要非常详细测试文档，包括测试用例以及用于检验数据正确性的SQL。这些工...
-
编辑 删除
测试漫谈:QA与涉众的关系
QA的涉众:1.PM2.系统分析员(SA)3.开发人员4.QA Manager简单来说:QA应根据PM的开发计划制定相应的测试计划.QA根据SA书写的需求文档制定相关的测试用例,并由QA Manager和SA复审测试用例.QA根据开发组发布的版...
-
编辑 删除
测试漫谈之：测试人员需要懂技术吗？
回答是：懂就最好不过，测试方面可以做得很“敏捷”。不懂，需要系统分析员&开发人员协助测试人员：1.构造测试用例，获取测试数据。2.提供必要的文档支持。比如，前台不能直接看到最终结果的，需提供后台查询脚...
-
编辑 删除
测试漫谈：你认为不出错，它就是正确的吗？
今天比较的郁闷，在一些认为不会出错的地方，程序偏偏就出错了。这些地方往往就是测试人员认为不会出现错误的地方，所以测试时候根本就没有注意到，又或者先前测试过多遍都没有问题，后台出现变更，再次回归的时候就...
-
编辑 删除
沟通，还是沟通
如何了解客户的真正想法，推动项目尽快验收？一般来说，项目组会设立客户经理，通常是销售，不需要专职在某个项目，可同时对多个项目服务，主要是要有目的了解客户想法，达到有效沟通，事半功倍。利用好客户经理这个...
-
编辑 删除
目标
当听到客户说：“需求中提到的没有完成的功能必须全部完成后才能终验”，我又意识到自己犯了个错误：过于关注客户的需求，忙于处理客户优先级较高的需求变更而忽略了公司的目标：终验。下一步，调整计划，与各最终用...
-
编辑 删除
项目管理需要懂业务吗?
针对行业软件的开发项目.前几天跟一个同事交流,他说很郁闷,因为他负责那些开发工作,自己不懂业务,很难跟进,感觉就是力不从心,希望其他熟悉业务的人可以分担那部分工作.这里就引入了一个问题:项目管理需要熟悉业务吗?...
-
编辑 删除
制度化的发布流程
由于系统上线后程序修改十分频繁,经常出现上午修改,下午就要发布的程序,往往需要发布的程序没有经过测试就直接发布到生产环境了,但由于一直没有出现什么问题,就习以为常...
-
编辑 删除
星期一现象
何为星期一现象?周五版本发布后,在星期一往往会出现某个功能或某个模块用不了的情况,我们把这个现象称为星期一现象.为什么会出现星期一现象?开发人员发布版本后,没有认真测试和没有经过QA测试,直接发布到生产环境...
-
编辑 删除
沟通与交流
昨天晚上安排一位技术骨干与每一个开发人员访谈，主要是收集一下他们对目前开发的看法，到了晚上11点还没有动静，于是跟他交流了一下，他认为这些技术交流没有必要，因为在平时已经收集到这些信息，不需要再耗时与每...
-
编辑 删除
改变，那么易，那么难
比如每周填写timesheet（项目成员周报），耗时不过5分钟，只是，从开始到现在几个月时间，能坚持下来的人，为数甚少。更多的人，只要上级不提醒，不要求，总有各种各样的原因不填写。看来，还是通过刚性制度＋柔性辅...
-
编辑 删除
从细节中解脱
目前项目管理中，经常出现的问题是Team Leader往往是Team中的技术骨干，如果涉及到细节问题，负责具体的技术工作，需要耗费大量的时间和精力去完成，迷失于细节之中，反而让管理者无暇顾及或者不能站在更高的层次上...
-
编辑 删除
Action
项目管理里面,有一个Action->反馈->Action的过程,当你看着某些事情失去控制或者变坏的时候,你就该Action了.前段时间出现不少问题,弄得客户满意度很差,希望通过人员的调整,资源的重新分派和整合,可以在3月底给出一份...
-
编辑 删除
持续改进之技术篇#1
改进不一定有效果，但，持续改进一定会有效果。改进，很难，因为难，才好玩。 由于目前的技术框架不足以支持快速开发和实施，为提高效率节省成本，不做技术改进基本上可以肯定要给人淘汰了。持续改进#1：1...
