项目杂谈

       首先在项目开发前期(往往是项目立项的时候),应该对项目可能使用到的关键性技术展开讨论和评审。一般在一个项目里面会有一个技术负责人+一个业务负责人,两人分别在项目过程中对整体的业务和功能需求,技术方案和设计负责,他们的作用就是把零散的技术开发和测试活动关联起来,识别产品的需求和设计风险,及时采取措施。否则项目真正在开发期间会出现,项目人员往往各干各事,零零散散的状况。但是对于技术负责人和业务负责人两人的能力要求是非常高的。这是从人力资源和项目中的职责上解决上述问题。项目经理在项目中主要是合理安排好人员和工作任务,保证项目整体的进度及其监控。

     但是如果项目中缺乏业务专家和技术专家的情况下,往往这部分的工作就落到了项目经理或者开发经理的身上。这个要把技术负责人+业务负责人的工作都放在项目经理或开发经理的身上时,前提是项目经理或开发经理对产品的需求、设计、开发技术都非常熟悉,且有组织实施项目的成功经验,沟通协调能力比较出色。如果这种前提不成立,就需要从项目过程和管理方法本身着手解决问题。

解决的问题:大家是否对项目的目标、范围、进度、质量这类约束性要求达成一致?

缺乏目标和不能达成一致的情况下,就是项目经理安排做什么就做什么,做完自己的事情就完了,至于自己是否有上游、下游、平级关联的工作那不是自己考虑的事情,那是项目经理去解决的问题。

当项目经理没有多余的精力解决这些事情时,产品完成情况差,达不到交付的质量。项目开发人员会困惑自己到底要开发完成哪些功能,因为项目任务分配时并没有详细的工作说明书去指导自己要去完成具体的任务。这种情况一方面是开发人员的质量意识没有建立起来,工作没有精益求精或者认为没有时间去做这些附属工作,所以工作比较被动;另一方面,可能开发人员有想把工作完善的意识,因为测试不通过的情况下,又要重新进行功能开发,本身自己是不愿意的,问题就在于确实没有一个标准说明他的开发工作怎么样才算是做完了,做好了,测试人员能够认同,同项目开发人员能够认同,项目经理能够认同。

标准的来源有几个方面:

1.客户的要求和期望。

2.产品的规格和设计。

3.产品验证和确认的具体要求。

4.项目组成员达成一致后的结果。

5.项目本身对进度、成本的约束。

另外项目中经常遇到的问题包括:

  • 1.开发人员不具备全局思维方式,缺乏设计能力。
  • 2.关联需求逻辑结合(以下情况比较普片)
  • 3.需求编写、设计遗漏,目前没有澄清过程,讨论记录,以致于没有项目测试依据

      让本身只具备中级程序员水平的开发人员去做架构师和系统分析师做的工作,本身对开发人员自己的能力和素质提出了挑战。有没有合适的开发人员能够担任构架师和系统分析师的角色,也就是技术负责人和业务负责人这个角色的领导者和管理者呢?有的话,可以从项目职责的管理角度去定义项目成员的责任。没有的话,第一个是项目组寻求外部力量的支援,第二个是项目过程中有意识地重点培养这方面的人才(为将来的项目储备人才),第三个是项目经理需要在项目组内开展好内部业务、技术类的交流和沟通工作,比如每隔两天开发人员、测试人员定期进行工作交流;开展进度轮查和统计工作,及时发现项目过程中的问题,尤其是检查项目组成员的工作是否缺乏目标。缺乏一个共同的目标,就会出现各干各的,自己干完自己的工作就行了,自己对自己的工程认可,对其他人的工作不认可。如果所有人认为开发完成的标准是,需求是清晰无歧义的,设计是完整的,测试的方法是可验证的,开发的模块测试通过后才能发布的,那么标准的制定一定是一个大家沟通协商后达成一致的过程。那么工作最后就是围绕如何大家都达成一致展开。

   一、需求的撰写者一定是考虑后续开发和测试人员的工作而展开,需求的描述肯定是清晰无歧义的,否者就不能与开发和测试人员达成一致。

   二、开发人员会自己主动做系统设计,并做说明会议,否者无法和项目经理、测试人员达成一致。

   三、测试人员会主动提供以往类似系统的功能和性能测试用例提供给项目经理、开发人员。

四、项目经理会召开项目沟通会议帮助大家消除分歧,项目中协调各人员的工作,保证项目的顺利进行。

关于目标的落实,从ISO9001质量管理的角度来需要制定质量方针,对项目目标进行分解。

举例如下:

项目目标分解项

评定方式

数据来源

管理目标

本次项目的管理方式采用部门制定的项目管理制度。

项目管理计划

本次项目的迭代需建立至少三个开发版本基线,至少两个测试基线。

迭代计划

项目重点文档提交100%

QA检查表

质量目标

开展的需求、设计、测试用例等评审会议次数不少于10次。

项目周期评审

产品应通过交付测试。

测试报告

 

 

4.项目进度十分缓慢,迭代一计划无法完成,按目前进度无法评估完成时间;

       迭代一的计划是否将项目风险考虑进去了,项目进度可能存在滞后的保留时间是否充分估算过?

      早期的项目团队的合作需要时间进行磨合。尤其是分工合作的情况下,大家之间没有一定的默契和项目磨合是很难按照预期的计划完成任务。在这种情况下,项目经理必须要积极指导和加强任务分配的管理,包括沟通的人员和方式也要在任务说明书中写明。

 

5.目前开发模式,并非测试并行介入(目前无法介入用例设计),后续短时间内测试工作量较大;

测试介入的时间点在哪里?项目计划中是否考虑到这个问题,测试介入了到底具体要做哪些事情,和谁进行沟通后,能够将工作量置前。测试工作由于是一个验证和确认的工作过程,没有确定的结论性的成果,是没有办法展开工作的。测试人员只能在项目的早期过程中,参与评审工作,当然评审分为正式评审和非正式评审,如果非正式评审话费的时间多,正式评审花费的时间就比较少,可以在这个方面多做些工作,测试人员需要跟踪一下项目的进度,项目经理也要按照项目管理制度的规定定期发邮件通知项目进度给测试人员,因为测试工作也需要安排人员,做测试方案和计划,测试人员理解需求和设计也需要一定的时间。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

黄鹤的故乡

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值