之前发表的一篇 [从研发管理系统看项目管理],得到了大家的关注
非常感谢大家的支持
我对于项目管理,现在还未出师,所以继续学习吧
对于上篇中提及的不妥之处,在这里做个反省。
==============================
1、项目管理知识:
现在对项目管理,我刚开始。只是出于了解一些理论知识的层面,对于一些过程的实际情况、实例、措辞有很大偏差。这点要注意:)
虽然自己看了一些关于项目管理的资料,只是在理论的表面上了解的片面,现在还未深入,主要原因在于没有实践。
2、需求分析、需求管理、需求跟踪:
1)对于需求:我现在理解是,项目的开发周期中,需求、设计出于项目前期,应用较长的时间去获取需求、分析需求、验证需求、设计。
2)在需求分析之后的阶段里,是对需求的“验证”和“检验”。此时通过设计或实现来验证这条需求是不是行得通。
3)需求的变更。这个是项目里比较关键的地方。
A、小的变更可能不会太影响项目的开展。
B、但是对于大的变更,很可能会造成项目工期的延长,或者直接将项目改头换面直接做。不过,造成这种情况发生,在开发的同时,是不是也应该检讨一下,当时的需求是怎么做的,是不是某个环节被忽视了。
3、成本管理:
公司一般会提倡资源共享;建立公司的资源库之类之类的。这个时候配置管理或者QA就会绞尽脑汁去寻找一些配置管理的工具,或者提交共享资源的资产库之类的。日常工作中要适时更新其中的资源,控制人员访问权限,审核是不是相关人已经及时提交某个工作文件。
所以,我想,从一开始就规范人员的使用工具,大家都在一个统一的环境里开发、设计等等,可以避免很多不兼容的情况,节约沟通时间。至于资源共享,这个一般公司高层比较喜欢,不多说了。
4、技术评审:
1)主要设立在某个项目的某个研发阶段,比如需求分析结束后,要做需求评审。组织一群人对这个项目的需求进行讨论和确定,审批后,才能开始分析设计的阶段。因为需求是看做项目开发的基础的,一般评审通过以后会建立一个需求“基线”,之后的分析设计和测试用例会按照这个“需求基线”的内容进行。(这里讲了一些配置管理的术语)
2)为什么加入“评审”这个过程:一般出于对某个研发阶段工作成果的检验。评估是不是能够符合当时要做这个项目的初衷,是不是能反映当时客户或者用户提出的“需求”。判断我们的开发能力是不是能够实现这些“需求”,还会考虑我们的资金、人力、时间等。
3)一般会成立“评审小组”:可能决策者是公司的高层领导。
5、工作模板:
这里,我个人认为不用做得很复杂,用长篇大论去说第一步、第二部、第三步……的确,中小企业对于此要求不是很高,甚至认为是拖延工期的事情,推广一般都不顺畅。所以,我想着,是不是能用简单的一张表格,将某一个流程里的第一步、第二步、第三步做成简单的“填写框”,相关的人只要拿着这张表,在项目过程里,依次填写内容、审批、确认等等,一个流程其实就走完了。
因为我接触的开发人员较多,让他们去记流程基本上是不可能的事情,他们的头脑里大多都是一个想法:怎样实现功能,而不注重形式。所以,我觉得,给他们一张表格,按照上边的内容填写就可以了。
不知道这样的想法是否可行,目前正在实践中,已经开始用了几个过程的“工作模板”了,大家还没有提出什么意见来,继续观望和完善吧。
6、个人习惯:纯属个人想法。我是非常注重高效率工作,不喜欢拖拖拉拉。当然沟通是比较重要的手段,有时候,沟通顺畅,可以让你的工作进展很快,这样效率也高。
因为总是独处,所以起初是用看书来打发时间的,没想到现在能够养成一个让我现在有些小得意的习惯。
谢谢大家的支持,共同进步吧~共勉