转载 IT项目管理的一些心得

26点 林涛 2482℃ 0评论

开始阶段


项目启动的时候,个人认为最重要的是要弄清楚项目的目标和项目的范围,包括需求范围和时间范围。 
通常,我最怕听到领导说:“把这个工作做一下,需求大概是balabala”,“啥时要?”,“不知道,你先做着,尽快吧。”这种场景经常会出现,由于没有明确的需求和时间约束,有时候就会无法分解工作包,导致无法安排人去做。 
这种情况相信在大多数人身上都有发生,这时候只能根据个人的经验从有限的需求说明中推算出大致的需求,还要估算一个合理的时间,因为虽然领导没指定具体的时间,但不意味着无限期的时间,总是得有个大概的范围。 
关于项目需求的收集,有时候急于心切想一下子获取全部的需求,但是大多数情况下,这是难以做到的。因此我总是确定一些大的需求方向,通过滚动规划,渐进明细的方针,逐步细化这些需求。使得需求的细节尽量在大方向之内。如果时间允许的话,可以先构造一个原型,通过原型能更好的把握项目的需求以及面临的风险。

关于技术框架架构的选择


通常情况,总是选择成熟好用的框架作为首选。事实上,我工作过的公司,都有自己的一套框架,大多项目都遵循这套框架,这些框架都经受了生产环境的考验,因此所面临的风险是最小的。有时候,会觉得这个框架真土,或者太烂,而花太多的时间在修改框架上,但是这在我看来不是最重要的。框架的目的是把程序员拉到流水线上,提高生产力,越复杂的框架对性能的影响也越大,理论上说,不使用框架的代码性能最好,但是可读性差,不易于管理,因此不得不使用一个良好的框架来组织代码。 
举个例子,本人曾经历过的一个项目,觉得是过度设计了框架,有点为设计而设计的味道,框架设计者为了实现解耦,将系统拆分的极度松散,以至于调用某些类库的时候还得依靠反射等方式,而为了完成一个功能业务,常常要在十几个项目中修改许多不同的文件。且不说对系统性能的影响,单单对开发人员的开发体验就很糟糕,疲于在各个工程项中查找要修改的文件。通俗的说,解耦的主要目的之一是实现代码复用,诚然,框架解耦的目的确实达到了,但是又怎样呢?从来没有后期的项目会使用这些解耦的子项目,因为系统业务一旦复杂后,虽然竭尽全力的避免,但是还是会有功能模块相互交织,根本不能独立出来作为一个DLL供给其他项目使用。事实上每到新项目开始的时候,多数情况下还是采用原始的复制代码的方式,而不是直接采用某个dll。解耦的另一个目的是减少系统的关联度,使得修改程序的时候能更简单,这是书上读到的。但是事实上,我觉得跟本不是这么回事,任何更改,如果是简单的代码更改,即使耦合度高的系统,也是很快能改进,而如果出现了较为复杂的业务更改,低耦合度也降低不了改动的规模。当然在此并不是否定解耦不好,只是说明一下,系统设计的时候,要综合考虑,而不是书上说什么就是什么,在我看来,保持KISS原则会让我省心不少。

团队建设


项目经理的主要工作之一就是将任务分解成工作包,然后分配给个人。本人喜欢的方法是开个会,大家一起商量,评估工作时间,认领任务。个人比较喜欢自下而上的方式,即项目成员各自确定各自的任务和时间后,汇总给我,然如有必要,稍做一下微调。自下而上的方式比较民主,大家也乐意接受。相对而言,自上而下的分配工作,有点“闭门造车”的感觉,不清楚团队成员的情况。关于开发模式,本人也经历过多种方式,比如瀑布模式,迭代式等等,个人觉得比较死板,尤其是当年做日本项目的时候,瀑布式开发使得我写了一堆没有实际价值的文档。 
个人喜欢目前流行的方式——敏捷开发。因为其快速响应,随时应对变化,注重实用性而不是文档,选择敏捷开发模式,最好是在团队成员个个都水平较高的时候采用,如果团队成员一堆应届生,一问三不知,那么怎么也敏捷不起来的。因此,对于这种情况下,我通常会采用结对编程的方式。实践出真知,个人感觉结对编程的效率是非常的高,而且可以互相学习技术,互相了解业务,个人非常推荐这种做法。选择怎样的开发模式和管理方法,就会建设出怎样的团队。

风险和变更范围


通常情况下,在做准备工作的时候,尽量的预估一下风险,风险包括技术上可实现性,人力资源的可用性和项目变更的预判。这点是经常会忽略,技术不是万能,面对有些苛刻的场合不一定能实现,这个风险要尽早的发现,考虑生成一份备选方案,最好做出原型来证明方案的可用性。而项目的变更对于开发者来说是家常便饭,但是最好把变更权控制在自己的手中,领导的旨意常常是不能拒绝的,但是也要以理力争,尽量通过邮件,IM聊天记录等确认变更,因为这可以作为变更证据,而不用通过口头叙述,尽量避免范围蔓延和“项目镀金”,不然到时时间来不及背黑锅的就是你了。

 

本文出自 “一只博客” 博客,请务必保留此出处http://cnn237111.blog.51cto.com/2359144/1317922

如需转载请注明: 转载自26点的博客

本文链接地址: 转载 IT项目管理的一些心得

转载请注明:26点的博客 » 转载 IT项目管理的一些心得

喜欢 (0)
发表我的评论
取消评论

表情
(1)个小伙伴在吐槽
  1. 网站做的好棒哦
    陈小予2015-12-25 02:04 回复