从研发管理系统看项目管理

 

文章来源：IT工程技术网 http://www.systhinker.com/html/02/n-11602.html

之前发表的一篇  [从研发管理系统看项目管理]，得到了大家的关注

非常感谢大家的支持

 

我对于项目管理，现在还未出师，所以继续学习吧

对于上篇中提及的不妥之处，在这里做个反省。

==============================

1、项目管理知识：
现在对项目管理，我刚开始。只是出于了解一些理论知识的层面，对于一些过程的实际情况、实例、措辞有很大偏差。这点要注意:)

虽然自己看了一些关于项目管理的资料，只是在理论的表面上了解的片面，现在还未深入，主要原因在于没有实践。

2、需求分析、需求管理、需求跟踪：
1）对于需求：我现在理解是，项目的开发周期中，需求、设计出于项目前期，应用较长的时间去获取需求、分析需求、验证需求、设计。
2）在需求分析之后的阶段里，是对需求的“验证”和“检验”。此时通过设计或实现来验证这条需求是不是行得通。
3）需求的变更。这个是项目里比较关键的地方。
A、小的变更可能不会太影响项目的开展。
B、但是对于大的变更，很可能会造成项目工期的延长，或者直接将项目改头换面直接做。不过，造成这种情况发生，在开发的同时，是不是也应该检讨一下，当时的需求是怎么做的，是不是某个环节被忽视了。

3、成本管理：
公司一般会提倡资源共享；建立公司的资源库之类之类的。这个时候配置管理或者QA就会绞尽脑汁去寻找一些配置管理的工具，或者提交共享资源的资产库之类的。日常工作中要适时更新其中的资源，控制人员访问权限，审核是不是相关人已经及时提交某个工作文件。
所以，我想，从一开始就规范人员的使用工具，大家都在一个统一的环境里开发、设计等等，可以避免很多不兼容的情况，节约沟通时间。至于资源共享，这个一般公司高层比较喜欢，不多说了。

4、技术评审：
1）主要设立在某个项目的某个研发阶段，比如需求分析结束后，要做需求评审。组织一群人对这个项目的需求进行讨论和确定，审批后，才能开始分析设计的阶段。因为需求是看做项目开发的基础的，一般评审通过以后会建立一个需求“基线”，之后的分析设计和测试用例会按照这个“需求基线”的内容进行。（这里讲了一些配置管理的术语）
2）为什么加入“评审”这个过程：一般出于对某个研发阶段工作成果的检验。评估是不是能够符合当时要做这个项目的初衷，是不是能反映当时客户或者用户提出的“需求”。判断我们的开发能力是不是能够实现这些“需求”，还会考虑我们的资金、人力、时间等。
3）一般会成立“评审小组”：可能决策者是公司的高层领导。

5、工作模板：
这里，我个人认为不用做得很复杂，用长篇大论去说第一步、第二部、第三步……的确，中小企业对于此要求不是很高，甚至认为是拖延工期的事情，推广一般都不顺畅。所以，我想着，是不是能用简单的一张表格，将某一个流程里的第一步、第二步、第三步做成简单的“填写框”，相关的人只要拿着这张表，在项目过程里，依次填写内容、审批、确认等等，一个流程其实就走完了。
因为我接触的开发人员较多，让他们去记流程基本上是不可能的事情，他们的头脑里大多都是一个想法：怎样实现功能，而不注重形式。所以，我觉得，给他们一张表格，按照上边的内容填写就可以了。
不知道这样的想法是否可行，目前正在实践中，已经开始用了几个过程的“工作模板”了，大家还没有提出什么意见来，继续观望和完善吧。

6、个人习惯：纯属个人想法。我是非常注重高效率工作，不喜欢拖拖拉拉。当然沟通是比较重要的手段，有时候，沟通顺畅，可以让你的工作进展很快，这样效率也高。

     因为总是独处，所以起初是用看书来打发时间的，没想到现在能够养成一个让我现在有些小得意的习惯。

 

文章来源：IT工程技术网 http://www.systhinker.com/html/02/n-11602.html