logo头像

从测试感悟到的项目管理

  一个项目从孕育到生产的这个完整的流程,需要各个部门密切顺滑的配合才能够像齿轮一样的环环扣紧不脱轨。在这中间,所有的技术人员都像一颗螺丝钉,如果自己的任务钉对了位置,方能愉快的做好自己的事情,如果中间的沟通协作等流程出现了问题,各个螺丝钉都会感觉不自在以致痛苦。人肉的项目管理流程毕竟不能够带来严谨的工作态度,测试作为生产线上的最后一个环节,如果前面的生产环节出了一点小问题,堆积到测试这里就会绕城一大坨大问题。

  经历多了坑的流程,我一直对流程化、自动化的东西很是在意,常常思考作为测试怎样在没有完善流程的项目中,贡献自己的力量。

  项目不仅应该根据定好的时间点,完整的分割每天的任务量,且有责任监督文档的完整性,可读性,可测性,了解从研发到UI到测试的工作流程与提高工作效率的方法,来调整文档的规范性。

  从研发内部的协作自动化,部门直接的协作也很有兴趣,核心就在于换位思考,了解各个职位的详细工作流程,以及在各个岗位最希望应用的工作模式。

利其器

  个人认为不管是多大的团队,都应该善于使用各种管理工具,有的认为团队小高效率就应该任何事情口头立马沟通交流,但是长久以往,所有的信息没有载体记录,流程会因为节点的不清晰而变得混乱,后期总结归纳起来也特别不方便。不管团队大小,总有适合当前场景的管理工具,重量级到轻量级的工具,找到适合自己的就好。

版本管理:SVN,Git

项目管理工具:

  1. Excel
  2. Microsoft Project
  3. dotProject
  4. redmine: bug 需求也可以管理
  5. Jira
  6. Teambition
  7. Worktile
  8. trello

不仅要用项目管理工具提升效率,还有很多其它常用工具能大大提高平时的工作效率,参见:it常用工具思维导图

风险评估

  测试需要评估bug的风险,对公司的受益影响,对用户的使用体验影响,对版本开发迭代的影响。项目同样也需要评估风险,对需求的改动,版本的更新,资源的调动使用都是需要对相互的影响作出评估。

沟通

  测试需要针对功能问题,流程,效率,和各个部门进行沟通,项目需要对资源等进行沟通调配。

需求

  需求的产生,并不是随意的有一个idea,或是抄抄别人家的产品画个图就可以了。从测试角度,版本每次测的兼容性,如果产品阶段考虑的好,向前的兼容性就能很好,功能性兼容,接口层面的兼容都应该考虑到,而不是每次强制用户升级造成用户体验极差。

  从用户角度实用性,易用性也同样需要兼顾,所以需求的考虑是一个复杂的过程,具有前瞻性,多往后考虑1到3个版本,不是就当前版本简单的列个功能性列表,开头没开好,整个团队会为了填需求的大坑疲倦不堪。而这些坑,往往从每一个环节堆积,到最后的测试环节就会凸显的特别明显,作为测试对这种坑真的太深恶痛绝。

  所以想要团队效率高,轻松过渡,需求环节太重要了。设计者的技术知识实在不可缺,但有的公司并不在意这个点,浪费了时间和金钱,导致资金链断裂,公司岌岌可危还以为是市场没有做好。

任务分割

  任务分割及其的重要,将任务分割到每小时,每天,这样任务的可控性也会大大提高。对于项目的管理,风险的预期都是很有益处的。测试对于细节要求会很高,希望控制到每个细节,这样会比较有安全感。对于项目管理来说,也有相同的效果,对细小的东西掌控的很好,在合起来的时候,才能做到心理有底。对后续开展工作能得心应手。

项目规划点

  • error code:考虑到兼容性,从立项开始前端特定的error code按照规定的提示,没有规定的error code,按照服务端返回的error message提示。
  • 版本记录:每个版本应该记录除了需求意外的变化,比如APP具体修改的功能细节,服务端接口的变化,如果有特殊的接口还应该详细记录,包括其兼容性的影响。

大而谈之,不如切分为每日任务,踏实做之.