<![CDATA[lanustudio.bokee.com]]> zh_cn Fri,17 Mar 2006 13:57:07 CST Mon,04 Dec 2006 23:01:49 CST http://www.bokee.com http://reg.bokee.com/account/web/img/logo.gif 博客网 http://www.bokee.com 您好，欢迎访问yunle110.bokee.com <![CDATA[个人应聘简历]]> .html

个人简历

姓名

狄浩

性别

男

 

生日

1985年5月

身高

172cm

籍贯

江苏省溧阳市

民族

汉

政治面貌

预备党员

毕业院校

苏州托普信息学院

学历

大专

专业

计算机游戏程序开发

联系电话

013524474648

电子邮件

landy_di@126.com

邮编

213300

家庭地址

江苏省溧阳市

现在居住地

上海市闵行区畹町路

求职意向

.net开发或者Flash ActionScript,或者计算机其它相关专业

能力速写

1．  .net开发

2．  Flash ActionScript开发

3．  FMS

4．  Flash Remoting

5．  能进行公司网络部署，安装和维护

6．  MSSQLServer2000

教育背景

1．2004年至2007年在苏州托普信息学院读大专

主修课程

1．  游戏开发相关理论课程

2．  Java基础课程

3．  MSSQLServer2000数据库

4．  自学.NET开发

5．  自学Flash ActionScript游戏开发

6．  自学FMS

7．  自学Flash Remoting

自我评论

1．  能吃苦耐劳，刻苦钻研专业知识

2．  自学能力强，能及时更新自己的技术知识

3．  有团队合作能力，能配合团队进行项目开发

4．  环境适应能力强，能时刻严格要求自己

奖励

1．2003年在高中获得计算机应用比赛全校第二名

2．2004年获得学院入学奖学金

3．2005年获得全校三等奖学金

4．2007年获得学院优秀实习生

5．2007年获得学院优秀班干部

社会实践

1．2003年至2004年在学校担任学校机房维护

2．2004年暑假在一家电脑销售公司担任技术员,组装维护电脑

3．2005年暑假，为溧阳多家单位做网络，电脑等部署、安装和维护（代表单位：溧阳市运输管理处共十多个分处）

4．2005年初，为广州一家包装盒加工厂做过一个茶叶盒平面广告

5．2005年初，为吉林一家健身中心制作过一个网站

6．2005年初，在校成立工作室，为学校制作完成学校网站

工作经验

1．2005年9月至2007年2月28日，在杭州******软件公司，在公司主要从事：

1 .net开发

2 Flash ActionScript游戏开发

3 公司网络部署和维护

4 公司网站服务器安全维护

2．2007年3月5日至今，在上海******有限公司做技术部主管，在公司主要从事：.net开发和Flash ActionScript开发

3．2007年回到杭州******软件公司，在公司主要从事.net开发，电信收费接口接入项目，Flash和.net交互式开发

4．2008年5月15日至今,在上海******公司做技术部主管,主要负责网站开发

 

]]> Mon,04 Dec 2006 23:01:49 CST 99 <![CDATA[描述与实现——系统构建的顺序 ]]> .html 1引言

很多人说在做一个系统的时候不知道从何下手，就是有了需求也不知道该怎么做。通常的思路是分析，设计，然后编码。分工也就是你进行数据库的开发，我做GUI，有些人写存储过程。这种方式有一个前提，就是分析和设计必须做的很好，构架很健壮，而且设计做得很细，甚至有些时候要求到代码级。

但是即便如此，项目仍然可能是失败的，原因是因为代码其实也是设计1，会对构架等有反作用，很多分析和设计时期根本想不到的问题，只有到编码的时候才能被发现。

那么，面对一个项目，应该从哪里下手呢？


2永远不够的设计 

设计，当然是设计。没有设计哪儿来的编码？就算是极限编程、TDD4等。其实都是先有设计的。当然，设计的意义随着项目的不同而不同。

越大的项目、其设计工作应该做的越细致一些。这和建筑学很相似5：相信三峡大坝的设计工作一定是做得非常细致，而且是经过了充分的验证以后的。但是如果是我给我们家的狗狗搭个窝，我相信没有必要用AutoCAD去画图。

以上观点又有引起了另一个问题：多少设计才够？我的观点是：没有设计是足够的，做到你做不下去的时候就可以了。

所谓的做不下去了，一种情况是缺乏实践的支持，不知道所做的设计是不是符合要求、能不能实现。这个时候需要进行一些编码工作，搭建一个快速原型进行验证。或者干脆从别的方面下手，把进行不下去的地方先放一放。比如说数据库的设计不知道该做什么，不妨去明确以下业务逻辑，客户业务条理不清晰，就去搞搞GUI，摆摆控件。要知道系统是一个整体，任何一部分对其他部分都是有联系的。对系统其他部分的思考或许会帮你打开思路，攻克难关。但是需要注意的是，搞设计需要有一个主线，不能东一下西一下。大体是要沿着需求—〉业务逻辑—〉GUI设计—〉数据持久化这么个顺序。

还有一种做不下去的情况是人员的心理原因。有个时候程序员更喜欢敲代码、而不是写文档。这也是很正常的。如果说非要程序员去拧着性子讲究敬业精神去写文档而不去写代码，是一种不科学的做法。做软件是脑力劳动，开发人员的活力和激情是很重要的。所以有的时候设计做不下去了，转而去编码，可以缓解很大压力，调动积极性，同时也是对设计的一种检验。可以说是一举两得。


3用代码描述系统——业务逻辑

3.1什么是业务逻辑

很多人说：我知道要做设计，但是我不知道怎么做设计。

做设计没有一个固定的套路，不然也就称不上设计了。编码也是设计，因为编码也没有什么套路，不然算法生成早就淘汰了所有的程序员。

虽然套路没有，但是思路还是有的。构架的设计顺序上面我已经说过了：需求—〉业务逻辑—〉GUI设计—〉数据持久化，这其实也就是先规定想要做什么，然后再考虑怎样去做。

从需求出业务逻辑是最重要，也是最难的一个环节。

什么是业务逻辑？业务逻辑，是对系统行为的定义和描述，即用代码或其它设计性的语言描述系统的行为，规定系统应该做什么。只是这么说太抽象了，我们下面举个例子。

依旧是我的FtpSearch搜索引擎。需求我就不说了，就是普通的搜索引擎：抓取、索引、查询等，详细情况可以参考我的另一篇文章http://yuandong.cnblogs.com/archive/2006/06/26/436395.html。本文的重点不是搜索引擎技术，而是系统的实现顺序。先看一下其Solution中Project的层次结构（图一和图二）：

图一：Solution中的Project
单击显示全图，Ctrl 滚轮缩放图片

图二：系统的依赖关系，箭头表示依赖
单击显示全图，Ctrl 滚轮缩放图片

一眼望去，相当复杂，但是我想要描述的不是一个已经实现的系统，而是系统实现的顺序。以上的这些包，是按照什么样的顺序设计和实现的呢？答案是系统各部分的依赖的顺序。


3.2系统各部分的依赖顺序

所谓的依赖说白了就是调用csc编译器时Ref参数后面的东东，在Vs.net中就是Add Reference中添加的DLL。从图中可以很明显的看出项目中包的依赖关系，即：实现依赖于逻辑，UI依赖于系统的其他所有部分。

图三：系统的顶层依赖关系
单击显示全图，Ctrl 滚轮缩放图片

按照依赖的关系，系统可以分为逻辑、实现、表现三大部分。FtpSearch系统中逻辑层包含：Kernel、SearchBusiness、QueryBusiness。表现层包含：SearchApplication（Console控制台程序）、WebSite。实现层包含其它的包。

先说Kernel，这是这个比较特殊的包，它被系统的所有部分依赖。其内容的是系统对现实世界的映射和抽象，非常的简单。如下图：

图四：Kernel包的内容
单击显示全图，Ctrl 滚轮缩放图片

Kernel包中一共有五个类。Server表示的是要被搜索的Ftp服务器。FtpItem是抽象类。表示Server上的一个项目。FtpDir和FtpFile继承于FtpItem，分别表示Server上的目录和文件。FileSize是一个辅助类，用于计算文件大小的便于阅读的表示。

SearchBusiness和QueryBusiness即是对抓取逻辑和查询逻辑的定义，也就是系统的核心逻辑，描述了系统应该实现的两个大模块的功能。其内容如下：

图五：SearchBusiness包的内容
单击显示全图，Ctrl 滚轮缩放图片

图六：QueryBusiness包的内容
单击显示全图，Ctrl 滚轮缩放图片

SearchBusiness包含了四个事件（参数），三个需要被实现的接口，一个枚举，一个具体类。QueryBusiness包含了一个需要备实现的接口，Query类用于封装查询信息，QueryResult和ResultFile类用于封装查询结果。

以上就是业务逻辑，即用代码描述的需求。其中最重要的就是四个接口，他们描述了这个系统的实现部分应该具有的功能。系统的实现部分就是实现这些接口的类。而表现层则根据这些接口调用实现类。另外，单元测试也是根据这些接口构建脚手架的。接口同时具有定义和解耦合两个作用。

以下是两个模块中四个接口的定义。

图七：接口的定义
单击显示全图，Ctrl 滚轮缩放图片

从图上可以看出，接口IRobot定义了抓取机器人的功能，包括启动的方法和可能触发的事件。IQueryServices比较简单，定义的查询服务只要实现Search这个方法就可以了。其它的两个接口则是为他们服务的。可以看出，这四个接口规定了系统的功能。

在设计和构造一个系统的时候，最首要的问题也就使描述系统的逻辑。这些逻辑直接来源于需求和设计者对是系统的认识。这些认识包含系统的规模、构架、要采用的技术、模块间的耦合等。

用代码描述的逻辑，相对于文档、UML等，更具有表现力，也更明确、清晰。一个好的系统设计必有一个好的描述，它起到了整个系统指引方向的作用。

如何用代码描述逻辑是一件需要不断学习和锻炼的事情。很多人，特别是从Asp等系统的开发过来的人，往往不知道该怎么分层，或者一般就是分为两层，表现层调用数据访问层。这种情况下，很多逻辑就散落在系统的很多角落里。这种系统没有一个良好的抽象，没有完整的定义，同时也是紧密耦合、不便于测试的。这种设计不能满足大型项目的需要，同时对维护来说也是一种噩梦。


3.3根据逻辑实现功能

一旦有了明确的逻辑定义，可以说系统的实现就是水到渠成的事情了。

相对于业务逻辑来说，系统的实现是细节，细节依赖于抽象，是理所应当的事情。例如数据持久化、用户界面等，都属于细节。如果我们在改变一个按钮在界面上的位置会导致访问数据的操作进行修改，那显然是很可笑的。同样，修改数据库的同时可能会修改逻辑操作的代码，这也是不对的。对于逻辑来说，它定义并拥有接口，规定了系统的其他部分应该怎样运转。其原因就是业务逻辑是对需求的体现。需求变，则逻辑变，逻辑变则系统皆变。

另外，对于细节，一般推迟实现。比如，做构架的时候不会很具体的考虑到数据库中有多少个表，每个表格包含哪些字段。因为业务逻辑还不明确，更重要的事，系统不因为这些因素而变化。这些细节处于从属地位。

回到我们FtpSearch上来。

实现SearchBusiness的包是SearchEngine、DataAccess、EdtFtpAccess。其中SearchEngine中的Robot类实现了SearchBusiness的IRobot接口，视为系统的核心。同样，SearchEngine中的IFtpAccessor和IFtpAccessorFactory这两个接口定义了它需要的服务，EdtFtpAccess是一个代理模式，它依赖于SearchEngine和第三方的API：EdtFtpNet。EdtFtpAccess通过实现IFtpAccessor和IFtpAccessorFactory接口为SearchEngine提供服务。这是更低一层次的“描述与实现”的关系。

以下是这部分的图示：包含SearchEngine和EdtFtpAccess两个包的内容。

图八：Search功能的实现
单击显示全图，Ctrl 滚轮缩放图片

Query部分就更简单了。只是单单提供了一个查询操作。由于系统的索引采用的是Lucene，所以查询的实现简单的用Proxy模式封装以下就可以了，以至于没有某个包是为了实现QueryBusiness而存在的。数据持久层就全权代理了。


3.4数据持久化与业务逻辑的封装

系统的设计和开发进行的这里，我们才开始真正的着手考虑数据持久层。数据持久层怎样实现？用Access？SqlServer？Lucene？还是自己写？都可以！反正只要能实现业务逻辑规定的接口，从理论上来说，系统就可以运作，不同之处是哪一种实现方式更合适一些。

这里我们不讨论搜索引擎技术，只是说用Lucene显然更合适。不过不管用什么，都不应该让你的数据持久化的方式入侵到你的业务逻辑。比如说我这里用了Lucene，而且我知道这个著名的开源索引肯定会出新的版本。难道说当它出新的版本的时候，我的整个系统都要跟着它改？当然不行！所以，依赖于它是错误的。我们需要将第三方的组件对系统的影响减少到最小。Proxy模式3是最合适的选择，它将Lucene对整个系统的影响完全局限的在DataAccess一个包中。对于系统的其他部分，他们根本不知道、也没有必要知道数据持久化的细节。查询操作亦是如此。Proxy模式的作用在这里发挥得淋漓尽致。

以下是DataAccess包的内容：

图九：DataAccess包的内容
单击显示全图，Ctrl 滚轮缩放图片

可以看出来，DataAccess中的类完全是为了实现接口而设计的。

除了DataAccess，还有一个包：SearchFacade，故名思义，这个包的作用是封装整个搜索逻辑，对表现层隐藏了大量的细节。这个包的主要内容如下：

图十：SearchFacade包的内容
单击显示全图，Ctrl 滚轮缩放图片

可以看到，这个包中最主要的类就是SearchManager类。表现层需要了解的就是这一个类。这就大大地简化了表现层的复杂度。

以上就所有系统的实现。但是只有实现还是不够的，还需要把他们整合并驱动起来，这也就是表现层的作用。


3.5表现层

表现层最主要的两个作用有两个：整合和驱动。

表现层的方式可以是多种多样的：命令行、窗体、Website……。同样，表现层也应该依赖于业务逻辑，因为表现层的职责是就在用户和业务逻辑之间建立一座桥梁。

回到我们的FtpSearch上来。这个系统的用户有两方面：一是管理员，负责更新数据；二是普通用户，使用系统查询数据。数据的更新显然应该是自动化的，所有采用命令行的方式。而前台采用Web的形式则是必然的。

表现层需要整合整个系统，下面是一段初始化代码，从中可以直观的看到对业务逻辑的初始化：

复制  保存
IFtpAccessorFactory ftpAccessorFactory = new EdtFtpAccessorFactory();

LuceneDataAccess fileServices = new LuceneDataAccess(workPath);

ISearchItemDataServices searchItemServices = new OucSearchItemServices();

SearchManager searchManager = new SearchManager(ftpAccessorFactory, fileServices, searchItemServices);

if (!isSilence)
    searchManager.RobotNewFileFound  = new EventHandler<NewFileFindEventArgs>(searchManager_RobotNewFileFound);

searchManager.FileSaved  = new EventHandler<FtpSearch.SearchFacade.Event.FileSaveEventArgs>(searchManager_FileSaved);


以上代码可以总结为：使用满足业务逻辑定义的接口的类，给业务逻辑进行构造。也就是对整个系统的整合。

所谓的驱动，就是根据用户的请求，调用初始化了的业务逻辑。用户的请求可能是Web Request，命令行参数、鼠标的点击、时钟事件等等。表现层应将其转化为业务逻辑的消息，并在此过程检查输入输出是否合法。同时，表现层需将业务逻辑给出的结果反馈给用户。


3.6依赖的方向

系统实现的顺序就是系统依赖的顺序，先描述后实现的顺序体现了从已知到未知的探索过程，同时也是不稳定依赖于稳定的过程。

系统依赖的方向应该是不稳定的部分依赖于稳定的部分，稳定的部分先于不稳定的部分被设计和实现，不受不稳定部分的影响。这样的系统才是健壮的、灵活的。

在一个系统中，什么是稳定的？逻辑，因为逻辑直接来源于需求；什么是不稳定的？数据库设计、用户界面等，因为左右他们的因素会有很多。

系统某一部分的稳定程度反映在它的抽象程度上。接口、抽象类的抽象程度高于具体的实现类。业务逻辑包含的大部分是接口和抽象类，而具体的类大都位于实现部分。

在FtpSearch系统中。业务逻辑是指Kernel、SearchBusiness、QueryBusiness。这三个包，其中SearchBusiness和QueryBusiness显然是以接口为主的，抽象程度较高，稳定性强。Kernel包比较特殊，全部是具体类。但是Kernel是对现实世界对象的映射，现实世界是不容易改变的，所以这个包虽然抽象程度不高，但是稳定性却比较高。所以依赖于这三个包，即依赖于业务逻辑，是向稳定的方向依赖，是正确的。


4耦合

4.1单元测试

在前面我已经提到过，接口同时起到了定义和解耦合两个作用，这个进行单元测试时尤为重要。因为对于某个类的测试，我们必须为其构造一个环境，将这个类分离出来。如果这个类直接调用系统的其他部分，那么系统就是紧耦合的。这种浑然一体的系统是无法一一攻破的。我们继续用FtpSearch的例子进行分析。

比如我们要对核心类Robot进行测试，这个类依赖于接口IFtpAccessorFactory。我们可以用一个实现该接口的模拟类对Robot进行测试。UML图如下：

图十一：Robot的单元测试
单击显示全图，Ctrl 滚轮缩放图片

图中，RobotTest调用MockAccessorFactory对Robot进行构造，然后执行Robot的方法进行测试。MockAccessorFactory类会模拟各种访问服务器的行为，甚至是模拟一些异常情况，比如服务器超时、访问的目录不存在、数据非法等。这样的好处是可以很容易实现测试的状况覆盖，而不用真的使用服务器引发某个错误。

TDD的一个好处就是，如果你先写Robot的测试RobotTest。那么你自然而然的就会得到上面的结构。

这个接口是便于测试的，请注意图中描述与实现的关系，IFtpAccessorFactory是描述，而MockAccessorFactory和EdtFtpAccessorFactory都是实现，而且还可以有其他的实现。不同的实现满足不同的需求，这样系统具有很大的灵活性，是松耦合的。

反过来看，Robot是高层次的，它定义了IFtpAccessorFactory接口，描述了所需要的逻辑，但是它不需要了实现的细节。MockAccessorFactory和EdtFtpAccessorFactory通过实现IFtpAccessorFactory接口满足不同的要求，视为不同的实现方式。


4.2第三方API

第三方的组件是不断更新、不可靠，同时也是不可控制的。可以说是系统中最不稳定的部分。从防御性编成6的思想来看，要把不可靠的因素隔离起来。从描述和实现的角度来看，第三方组件服务于实现，是细节，应该依赖于抽象，为实现服务。所以在采用第三方组件的时候，一半将其影响限定在一个类或一个包中。这个时候，Proxy模式和Fa&ccedil;ade3模式都是很有用处的。

FtpSearch系统中采用了两个第三方的开源组件，分别是EdtFtpNet和Lucene。都使用了Proxy模式进行封装隔离。

以上就是系统构建的顺序。

系统构建的顺序就是系统各部分的依赖顺序。系统逻辑、实现、表现三部分的依赖关系是：实现依赖于逻辑、表现依赖于逻辑和实现。其中业务逻辑是整个系统的核心，业务逻辑即使用代码描述的系统行为，它从需求出发，规定了系统各部分的协作关系和运行方式。良好的业务逻辑抽象是系统健壮、灵活的保证。 


参考文献

1．《源代码就是设计》 Jack Reecves
2．《敏捷软件开发 》Robert C. Martin
3．《设计模式》，4GOF
4．《测试驱动开发》，Kent Beck
5．《代码大全2》，Steve McConnell
6．《程序员修炼之道》，Andrew Hunt等

]]> Thu,08 May 2008 14:37:29 CST 0 <![CDATA[一个项目经理的一些个人体会]]> .html 本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。

项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的；

3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；

4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；

5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。

6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。

7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。 

对于这种需求天天变的客户，你就一定要事先做好规矩：

一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；

二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：

*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；

*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；

*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；

8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。

9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做干特图的形式表现出来。你做完这个表以后会惊奇地发现，干特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。

好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：“(*&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。

另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。

接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：

1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；

2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？

3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。

系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：

一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正确是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。

验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，这些在前面已经有所提及，这里就不再多说。

我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了XP还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。

]]> Thu,08 May 2008 14:36:31 CST 0 <![CDATA[项目计划书的内容]]> .html 1.引言 
1.1计划的目的 
1.2项目的范围和目标 
1.2.1范围描述 
1.2.2主要功能 
1.2.3性能 
1.2.4管理和技术约束 

2.项目估算 
2.1使用的历史数据 
2.2使用的评估技术 
2.3工作量、成本、时间估算 
3.风险管理战略 

3.1风险识别
3.2有关风险的讨论 
3.3风险管理计划 
3.3.1风险计划 
3.3.2风险监视 
3.3.3风险管理 

4.日程
4.1项目工作分解结构 
4.2时限图(甘特图) 
4.3资源表 

5.项目资源
5.1人员 
5.2硬件和软件 
5.3特别资源 

6.人员组织 
6.1组织结构 
6.2管理报告 

7.跟踪和控制机制 
7.1质量保证和控制 
7.2变化管理和控制 

8.附录

]]> Thu,08 May 2008 14:35:56 CST 0 <![CDATA[日常管理随笔二]]> .html 继续谈一些日常的总结和感悟，仍然是一些工作上的点点滴滴而已


1.开会四件事

我在每周例会会让大家谈4件事：

（1）上周的工作情况
（2）本周的工作计划，
（3）觉得目前现状，或项目，或公司及任何方面有什么问题

（4）觉得目前现状，或项目，或公司及任何方面有什么可以改善的地方，有什么好的发展建议。

没有别的目的，了解现状，规划将来，让优秀者发展，让落后者淘汰，让团队进步。


2.授权。任务分配明细，责任明确，具体到人

搞开发的都知道，系统架构如果要应付大数据量的并发，需要做分布式处理，管理的道理亦然，如果要管理大的团队，应付更多人员管理，也需要“分布式”，所谓分布式，不过就是项目管理中的WBS，所以，要把适当的人用到适当的模块，根据他的特长和兴趣，充分的授权，同时，具体量化到每个模块-责任人的关系，这样出了问题，可以有的放矢。同时，部门协调也比较容易找对人。任务的分解让整个团队变得平衡，让每个成员动起来，同时，责任到人，保证了项目的质量，也提高了工作的效率。


3.随时反馈，及时沟通。

很多开发人员不太愿意沟通和反馈，甚至觉得不屑，也许他始终没有明白这里面的意义。这是人在职场很重要的习惯，我每次开会都教他们要记得随时反馈，及时沟通，不要做闷葫芦，这是一个非常好的习惯，不仅仅可以提高团队工作效率，也真的可以影响你的职业人生。


4.默认淘汰制。

一个在舒逸的环境待久了，就会变得颓废，没有危机的机体是没有生命力的，所以，对一些不能跟上前进步伐的，为了保证大部队的目标和前进速度，只能淘汰，因为不能为了极少一部分人，而连累的整个团队。特别是创业团队，尤为重要。创业型企业需要激情，效率和执行力，创业团队需要的是有责任心，做事积极主动，有激情，有热情，有积极进取和奋斗精神的。要有非常好的团队氛围，团队的风气不能坏，如有发现，一律清除，因为这东西就像一个肿瘤，如果不及时切除，会造成整个团队腐烂。


5.交叉测试。

程序员总是有这个自信，自己做的东西没有问题，即使自己测试往往也是按自己的业务逻辑去重复，所以，有的时候很难发现真正的问题。而人总有一个“优点”就是，看别人做的东西就是很烂，所以让不同的人去测试不是自己写的代码，往往能找到很多问题。 这不为是一种好的测试方法。


6.适当的提拔有潜力的人。

对一些有潜力的人，适当给一些锻炼的机会，也帮助他的成长，同时也可以帮我分担一部分压力，让我有时间从琐碎的事务中跳出来想一些更重要的事情或产品规划。水涨船高，只有员工整体水平都提升了，都进步了，做为管理者自然就跟着提升了，团队才具有更强的战斗力，作为公司才能更好的发展。人要向上走，不是靠爬，而是靠顶，没有接班人，这个空缺只能你来做，建好团队，培养好接班人，你会很轻松。同时，不但帮助你的下属成长，也去帮助你的上级成长，因为只有他提高了，你才会提高。


7.要不要和员工交朋友。

我个人觉得：可以，但不是在工作中。对待工作就应该公事公办，该怎么办怎么办,不应该参杂太多的感情。公司是个做事的地方，不是来比谁的"爱"最多。做事就不要做人，做人就不要做事。当然,有的时候，一个管理者要做到这两者的平衡，真的比较难！


8.培养开发人员的市场和产品思想

让他们每个人都把自己当作产品经理或项目经理（来考虑问题）学会分析需求，分析问题，过滤伪需求，学会和市场人员沟通，学会协调，学会把细节作好，而不是只完成自己那点功能就完事。注意用户体验。遇到问题，不要先讲不可能，先思考，再决定，不要认死理，不要主观的自己认为怎样怎样。我尽自己所能帮大家提高，无论是技术的，还是做人做事的思维方式。我想这种提高，会大大减少沟通的成本和返工的成本，也可以大大提高项目的质量。也许有的人还不理解为什么要这样做（有的人会有“好像这不是我份内的事”的想法），我想几年后，他会明白这其中的益处。


9.制定日常工作规范。 

小公司发展靠哥们义气，普通公司靠规范制度，大公司靠企业文化。没什么可讲的了，没有规矩，不成方圆。规范是企业或产品长期发展效率和质量的保证。


10.寻找比自己优秀的人。

我个人觉得团队应该寻找比自己更优秀的人，因为只有这样才能做出更优秀的产品，而不会让自己成为产品的技术瓶颈。如果按80%理论，越往下面越差，估计不会做出什么好的东西，而管理者再牛也不可能完成所有的工作，也不可能精通所有的技术,也不可能事事亲为，还需要大批优秀的人和专业团队来共同创造。我在团队里倡导，除非你某方面比我强,成为某一方面的专家，否则，我觉得你是不称职的。

我所做的就是包容，激励，协调，让团队团结一致的超某个方向前进。

我做的不是最好，但我在努力做到最好！

从做管理到今天，我忽然发现，我自己变的宽容了许多，胸怀里可以装的东西更多，变得更大!

]]> Thu,08 May 2008 14:35:31 CST 0 <![CDATA[日常管理随笔一]]> .html 作为管理，时间不短也不长，所感所悟略有所思，不敢讲做经验或什么理论，只作为日常随笔一记，算做茶余饭后偶谈一资且记于此。


1.帮助员工成长。

个人觉得一个管理者，从管理员工的角度讲，不仅仅是分配任务，授权或者汇报等等这些，最重要是帮助一个员工去提高，去实现自己人生目标，大家都提高了，企业也会提高，同时，由于员工在这里得到了自我价值的提升和实现，自然愿意留下来一起成长。


2.培养好员工的自理能力。

好的管理者，应该培养好自己的员工，当管理者不在的时候，工作会照样井然有序的进行，而不是无所适从或者乱糟糟，甚至懒散怠工。（当然，好的员工会主动做好安排好自己的事情。）但并不是所有的人都能够做到这样，管理者不可能做好所有的工作，还需要靠团队的力量来完成一个又一个的项目，我有时候也是希望员工能快速的成长，我也尽量为他们创造这样的环境，作为一个管理者，能让团队快速有效的工作，尤为重要。有时候告诉他们正确做事的方法和做人的态度比让他懂一个技术点重要的多。

告诉他们好的做事习惯和态度也是他们以后个人人生成长道路上一笔不错的财富。管理者不可能样样精通，术业有专攻，做好一件事需要团队的力量,而不能靠管理者本人去做。如果管理者本人每天累的吐血，而下面的人每天都唱着“明天会更好！”，肯定是失败的管理。如果有做事积极主动，干净利落，又能及时沟通反馈工作的最近进展的下属，我想这该是非常幸福的管理者。

其实，员工也是可以"调教"的，特别是对于许多刚步入社会的新人，尚未完全掌握一些与人相处的道理，做事的方法，尚未了解与人为善，社交礼仪方面的重要性，常常以自己为中心，心高气傲。所以还需要岁月的历练，个人的感悟。给他们一定的时间和锻炼的机会，他们会慢慢成熟起来。


2.“哥们”情节

管理学上虽然有在公司做管理不要和员工讲“哥们”的说法，但我还是希望和员工打成一片，只是在工作上班时我还是对他们要求很严格，项目计划，项目进度，文档规范等等一个都不能马虎。下班之余我依然会和他们一起吃饭，开玩笑，一起瞎扯。我认为这完全是两码事，感情归感情，工作归工作，公私分明，要做就把事情做好。管理者也是人，工作中只是分工不同，既然工作就要各负其责，把自己该做的份内的事情做好，如果把工作和私下感情搞浑，很容易导致团队的执行力非常差。当然，也有的员工有时不理解，但我想随着年龄的增大，阅历的增多，也许会慢慢理解。

在中国的环境，中国人的情节还是“情”“义”当头，自古至今，很多时候，都以此作为为人处世的原则，我想中国式管理确实有所不同，既要考虑到中国人情感的感受，又要严格管理的规范。


3.作为管理者，个人认为：

小管理者靠的是能力，中管理者靠的是魅力，那么大管理者则靠的是胸怀。

并不是所有的员工都会像自己那样做事，处事.任何一个企业或环境里都会有各种各样的人，性格各异，同时，也不可能要求所有人像自己一样的方式做事或处理问题。记得天下无贼里面说过一句话，"只有心里容的下弟兄，才能作大哥"。作为管理者，有海纳百川的胸怀是很重要的。管理要懂得知人善用，“知人”是指领导者应当非常了解他的团队成员，包括知识技能和性格爱好等等；“善用”是指让团队各成员扬长避短，使团队战斗力达到最强。就是说：不仅用最合适的人正确做他擅长的事，而且还要激励他做得更好。


4 .管理的最高境界不是完美 

在管理实践中，常能听到员工抱怨公司管理不规范、运作混乱、组织架构不清晰，其实有的时侯，混乱自有混乱的好处，作为一个团队，由于个体差异，参差不齐，一味地追求完美的统一，却可能抹杀了个体的个性而导致整个组织解体和僵死。俗话说得好：水至清则无鱼、人至察则无徒。鱼缸里的水虽然清澈见底，但生长在其中的鱼长不大，活不长。江海的水虽然混浊，却能够容纳更多更大的鱼。管理的重心有效地进行资源调配，包容多样化的差异性，并将其揉合成一种向心力,使的团队优势互补，形成强有力的凝聚力和战斗力，团队需要优秀的人才，但并不是优秀人才越多越好。从自然规律来看，不同的音符，才有乐章的美妙；不同的落差，才有起伏的壮观；不同的性格，才有生动的和谐；不同的所有，才有无尽的追求。

管理的最高境界不是完美，而是残缺中的和谐！


5. 初出茅庐，相信自己就一定能可以。

另外，我也想对刚入行的和即将进入社会的朋友们说一句，当你发现别人比自己懂得多，技术强，不要灰心和气馁，比你懂的多，了解的多，未必就是他比你聪明多少。而只是比你看的多，学的多，练的多，历经的多一点而已，没有什么，只要你努力，勤奋，你一样可以做的更好，每个人不是一生下来就什么都懂的。给自己信心，给自己更多的机会，去实践，去锻炼，去学习，去感悟，让自己去承担的更多未必是坏事，因为责任往往和价值是成正比的，偷懒的你其实也许丢失了很多可以进步或成功的机会，还是那句话，踏踏实实去做事，去迎接给你的每一个挑战，你觉得自己行，肯定就可以行的。


6.除了技术，其实还有很多!

不要犯文人相轻的毛病，任何一个人都有别人学习的地方，一个人只要能成功自有他成功的道理，学习别人的长处，克服自己的短处，也不要一味地耍大牌，其实，这个世界离了谁都照样转，强中更有强中手，别太拿自己那点技术太当会事。谦虚会让你学到更多，协作会让你有更多的朋友。人成功不仅仅靠的是技术，还有很多很多的东西，沟通能力，协调能力，社交能力，为人处事，待人接物，社会资源，有时候这些要比技术带给你的远远多的多。
以上言论仅代表个人观点，随便谈谈，欢迎切磋。(李天平)

]]> Thu,08 May 2008 14:35:06 CST 0 <![CDATA[项目经理应如何调动员工的积极性 ]]> .html 欲造物，先造人！”一个项目的成功或失败，其首要关键因素是人。项目成员是否能够步调一致，是否能够积极主动的朝着同一目标前进便成为项目顺利开展直至最终完成的基本前提。 

通常员工表现不佳，有来自员工内在思想的原因，也有来自其它多方面外在环境的原因。其中后者有更多的因素，影响面更大。这就要求项目经理必须努力帮助员工创造更好的环境，包括工作场地、设施工具甚至生活条件等硬件环境，同时也包括项目总目标、项目制度以及工作氛围等软件环境。这其中，硬件环境条件由于项目自身的性质难以进行本质性改善。因此项目经理应该把软件环境的改善作为调动员工积极性的重点。 


1、建立共同的目标

项目总目标是项目经理与项目组织成员共同建立起来的，融项目目标与个人目标于一体的，项目组织成员们努力要追求的目标。有了这样一个目标，项目团队就可以对团队成员产生强大的吸引力，从而增强团队的凝聚力。只有项目组织成员在思想意识上高度统一没有分歧，才能确保项目的措施从上之下具体贯彻落实，保证项目内部个体力量与目标方向相同，避免“内耗”现象，大大提高生产效率。 


2、让员工说该怎么办

首先，安排工作时让员工了解事情的背景和原因。我们通常认为由于高一级的管理者更加广泛的接触以及其所处的职位高而相应承担的责任、考虑的问题都更为重要。所以上级对下级布置任务时，上级只需说明要求，而下级一般必须遵照执行。但如果员工不了解事情的背景和原因，他只能完全按照项目经理的表面意图去工作，不敢也不愿越雷池一步。执行过程中遇到的任何特例问题，他都要向项目经理汇报，因为他不知道怎样处理以及如何处理是正确的。 

在任务执行过程中，遇到意外情况，让员工提出解决方案。管理级别高并不意味全能。在专业问题上，专业技术员工可能提出更加合理化的方案。不同的管理级别只能代表不同范围团体的利益，不同的思考角度。因此，让员工提方案而由项目经理审批绝不意味他领导项目经理。相反，是用他的专业角度弥补项目经理的不足。 

让员工了解事情的背景和原因，并且在特例情况下让员工说怎么办不仅能够提高工作效率，使决策更加合理化。更重要的是培养员工的思考习惯，激发他们的主观能动性，增强员工在团队中的主人翁精神。 


3、布置任务时明确要求

项目管理者经常会向项目组织成员下达工作安排。在安排时，尽量明确任务的详细要求、责任人、完成时间。如果一项工作涉及多人，还需明确各人的分工或者主要的负责人。 

明确的要求可以避免员工之间的责任推委，极大的淡化了可能出现的管理矛盾。并且在目标考核中，明确的要求是考核的前提条件。 


4、“Push精神”

任何“目标管理”都不会自动实现。在项目实施的过程中，我们通常将项目目标在时间坐标上量化成诸多子项目或是任务。但无论这种量化分割多么详细、多么具体。目标都不会自动实现。把划分好的任务扔给员工，只知道等待结果的“耍手掌柜式”的管理是项目经理要极力避免的管理方式。 

任务下发后，要经常询问员工的执行情况，进度情况。一方面，根据执行具体问题及时调整原任务中不合理的要求；另一方面，对于员工已经完成的部分要给予肯定，并鼓励他们继续努力完成后续工作。对于员工在工作遇到的问题和困难给予有力的帮助。要让员工时刻感受到自己正在紧张为之付出努力的工作在上一级管理者心目中很重要。从而进一步激发员工的工作热情。 


5、肯定、赞扬你的员工 

有的管理者认为作为领导在下属面前一定要威严，这样说话才有威摄力。而下属有问题也不敢或不愿向领导反应。如果项目经理和员工之间形成这样的对峙关系，工作的开展将会变得事倍功半。长此以往，员工还可能对项目经理下发的任务产生抵触情绪，严重的可能会直接影响到项目的实施。 

其实肯定和赞扬作为一种低成本、有效的激励形式早已被多数的管理者广泛使用。经常的与员工沟通，对他们做出的成绩、取得的成果提出肯定和表扬，不仅会激发员工的工作热情，更能提高项目经理和员工的沟通指数。管理学中著名的“三明治技巧”正是充分运用了肯定赞扬的效力来达到批评指正的目的。 

项目经理不仅是项目的管理者，同时也应是项目组织成员的“啦啦队”，为他们鼓气加油。 


6、为员工创造学习氛围，提供学习机会 

学习、培训在当代社会中越来越频繁的出现在企业招聘中关于福利报酬的说明中。这足以证明学习的机会在多数员工心目中的重要程度。培训机会的创造可能更多得需要依靠企业的支持。但学习氛围的创造则是项目经理义不容辞的责任。 

建立日常学习机制，提供员工相互交流的机会，搭建技术、经验共享的平台，以致在项目组织成员中创造出学习的良好氛围都是项目经理应该做的。通过这些方式，可以极大提高员工工作的自主性和热情。让员工在工作中学习，又在学习中增强工作的热情。 


7、注意你的手下，虚心听取员工的抱怨

项目经理在项目组织中究竟扮演什么样的角色？通俗的可以称做领导（leader），时髦的可以说是经理人（manager），但是更为恰当的应该是协调人（coordinator）。一个协调项目组织中各项人力资源、物力和财力在规定的时间达到预期目标的人。 

因此，项目经理应该经常注意员工是否有不良表现。这不仅仅影响到目标和任务能否达成，而且不良的思想、行为、情绪具有的传染力，很容易形成团队的不良风气，沉淀为团队的不良价值取向，积重难返。看到有不良表现的员工，应主动与其交流，注重事实。而不是听取他人的评论，轻易断言，妄下结论。对于遇到需要帮助的员工，应帮助员工解决困难；对于思想偏激的员工，应帮助员工了解事实真相，使其尽早恢复工作的热情。 


8、展现人格魅力

员工服从项目经理的命令是因为项目经理的权力。那么项目经理的权力基础又是什么呢？权力显然来自更高组织裁定的合法权，但保证这一权力更重要的应是专家权和典范权。要想使员工心悦诚服地听从命令，项目经理除了必须拥有广泛的专业知识，还必须拥有值得员工尊敬的人格魅力。 

自信负责的工作态度，高尚的道德操守，牺牲奉献的工作精神才是一个项目经理的权力基础。也只有拥有这样的人格魅力，员工才会积极采取项目经理所建议的行动步骤，才更有可能提升项目经理的激励目的。

]]> Thu,08 May 2008 14:34:03 CST 0 <![CDATA[项目开发过程管理(草稿)]]> .html 本人刚接触项目管理不久，为公司写了一篇《项目开发过程管理》的文章，文章中有很多内容来自网络，并加上自己的理解及文字，于是就产生了这篇文章。文章肯定有很多不合理的地方，或者不合标准的地方，希望各位前辈批评指正。以下附原文：

项目开发过程管理

1、项目立项

项目立项过程：

1） 项目经理将确定的《需求说明书》及《立项单》交给相关部门的负责人签字确认。
2） 立项通过后，项目经理将《需求说明书》交给开发负责人，并由开发负责人进入需求分析流程。

2、需求分析

需求分析就是分析软件用户的需要的是什么，就是要让开发人员全面地理解用户的各项要求,并准确地表达所接受的用户需求。


需求分析的过程：

1) 需求获得：由项目经理把《需求说明书》交给开发负责人

2) 讨论需求：需求讨论的目的是让开发人员准确的知道这个项目要做的是什么，开发负责人组织开发人员讨论《需求说明书》，明确需求的组成内容，逐步细化需求提到的所有功能，并分析他们是否满足需求，综合成系统的解决方案

3) 需求修订：需求修订应该是一个不断重复的过程，这个过程有可能出现在需求分析中，也有可能出现在系统设计或者是编码开发过程中，越在项目开发流程靠前的阶段发现问题，对项目开发的影响也就越小，有些问题只有在设计或者编码阶段才会被发现，或者是在设计和编码阶段产生了需求变更，每次需求修订产生的《需求说明书修订稿》都要由项目经理、需求提出者以及开发负责人3方签字确认。

3、项目计划

项目计划的目标是为项目负责人提供一个框架使之能合理地估算软件项目开发所需的资源 、经费和开发进度，并控制软件项目开发过程按此计划进行。项目经理及开发负责人需要在公司建立的项目管理平台上对项目资源及进度进行计划和控制。

项目计划过程

1) 资源确定：项目经理确定项目资源，包括：人员、硬件、软件以及其他的相关资源
2) 进度安排：项目经理确定项目里程碑任务安排，里程碑任务以界面操作可见性为标准；开发负责人根据项目里程碑任务，细化成开发任务，每个开发任务最长周期不能超过一天
这个过程中产生的文档有：项目计划说明书.doc 

4、系统设计

在需求明确之后、准备开始编码之前，要做系统设计，系统设计对后面的开发、测试、实施、维护工作起到关键性的影响。系统设计的主要目的是：将软件系统需求转换为未来系统的设计，明确系统构架，使软件适合于实施环境。系统设计分为两部分：概要设计和详细设计。

系统设计流程：

1) 规范制定：由开发负责人制定本项目的开发规范，包括：代码体系、接口规约、命名规则。 
2) 概要设计：开发负责人和相关开发人员共同完成业务流程设计、模块数据处理流程设计及用户界面设计。
3) 详细设计：开发负责人和相关开发人员共同完成接口设计和数据库设计。
在这个过程中产生的文档包括：业务及数据流程图、接口设计文档、美工界面、数据库设计文档。

5、开发编码

开发编码是软件开发的最终实现阶段，受项目计划及系统设计的约束。

开发编码流程：

1） 开发人员根据需求及系统设计完成编码任务
2） 开发人员在开发过程中，需要对每个模块、类、方法、字段做详细说明注释以及修改注释
3） 开发负责人及时明确开发人员在开发过程中遇到的疑问，对开发的关键点进行代码跟踪审核，确保实现方式的正确性
4） 开发负责人根据详细的开发计划跟踪项目进度，向项目经理汇报每天的开发情况。


6、测试

软件产品的质量是软件市场竞争中获得成功的关键，软件测试是保证软件质量的手段，它是需求分析，设计和编码的最后复审。

a) 单元测试

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

单元测试的流程：

3） 开发人员编写测试用例
4） 开发人员编写测试代码
5） 根据测试用例运行测试程序，根据结果写测试报告。
这个过程中涉及的文档有：测试用例、测试报告。


b) 集成测试

集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

集成测试的流程

1） 设计集成测试用例和测试过程
2） 编写测试程序或者测试脚本
3） 执行测试并记录测试结果


c) 确认测试

确认测试是验证软件的功能和性能及其它特性是否与用户的要求一致。对商品化软件的品质从功能、性能、可靠性、易用性等方面作全面的质量检测，帮助软件企业找出产品存在的问题，出具相应的产品质量报告。

确认测试的流程

1) α测试：α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。

2) β测试：β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

3) 配置复审：确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

]]> Thu,08 May 2008 14:33:38 CST 0 <![CDATA[网站项目流程图]]> .html 单击显示全图，Ctrl 滚轮缩放图片 

]]> Thu,08 May 2008 14:32:53 CST 0 <![CDATA[影响项目的因素及经验总结]]> .html 我们都要学会从项目失败中吸取教训，只要我们能够能有宽大的胸怀去面对它，那么犯错也不见是一件坏事。

其实影响我们项目失败的因素主要分为　　


技术失败：

1、领先技术的诱惑
2、不完善的技术设计
3、为非技术问题提供了技术解决方案
4、依赖软件包来满足需求
5、在开发生命周期过程中没有充分利用工具
6、以技术为导向进行开发　　


人为失败：

1、缺少行政人员的支持
2、缺少领导
3、没有敬业精神的项目团队　　
4、功能不全的项目团队
5、管理第三方失败　　
6、缺少一个项目精英
7、缺少项目所有权
8、相关人员冲突
9、拒绝变更
10、敌对的组织文化
11、经验不足的项目经理
12、缺少商业理由
13、不清晰或模棱两可的商业优先级
14、缺少用户培训
15、相关人员动机不一致　　


过程失败：

1、缺少项目管理方法体系
2、缺少系统开发方法体系
3、缺少收益管理方法体系　　
4、缺少质量管理方法体系
5、未能确定和转移项目风险　　 
6、未能管理需求
7、过长的项目时间表
8、测试不足
9、计算机化的”爆炸“方法 


从项目失败中吸取教训是不断改进过程的重要组成部分，现在罗列一下一些主要的经验教训

1、管理用户预期。

即是我们的项目人员要从一开始就明白需要交付什么以及不要交付什么。要在项目中确定用户的需求和建立尽可能清晰的商业所有权。即使在最好的情况下，用户以前收到的信息也是有限的。通常情况下，我们很难确定能够提供反馈信息的合适用户。

在项目一开始就需要确定主要的用户需求，并且为主要用户提供时间，以便他们确定所在部门的需求，同时他们也有责任提供和验证信息并投入相应的资源。


2、项目规格说明书中必须考虑商业要求和用户需求。

首先要理清两个概念。

第一，项目是因为可确定且可测量的商业要求而产生并发展的。在软件项目初期确定的清晰目标将随着项目的进展而逐渐变得模糊，这是拥有过长的交付期限的项目所共有的特点。因此在项目开始之前，需要确定最终用户，以便在软件项目的设计和开发过程中充分考虑到他们的需求，同时用户也有责任而且需要采取相应的行动来帮助项目获得成功，这一点非常重要。用户需求构成了项目的分析和设计阶段中一个至关重要的环节。需求确定后，就要为这些需求确定基线，并将它们引入到配置管理系统中，同时使用变更控制对其进行管理。如果这些需求出现了变更或添加了新需求，则需要对项目进行影响分析，并对项目计划进行相应的修正。而像我们一些采用增量式和迭代方法开发软件的组织而言，还需要冻结每个软件版本的需求，并建立相应的机制（在确定的时间点和功能点进行版本控制，详细如项目的版本控制可以专门建一个文件夹用于版本控制，然后专人每天以该文件夹的更新文件搜索出来，以WINRAR保存完整路径进行打包，再解压便得完整路径下的每天更新的文件），以便向开发基线添加新的具有更高优先级的需求（用户需求反馈中确定优先级）。

第二，项目规格说明书必须关注商业需求而不是技术解决方案。因此，即使从技术上讲已经存在明确的解决方案，但在进行项目评审时仍需将重点放在与商业相关的方面。


3、在批准资源以前测量和评估项目的规模和复杂度（重视实现性）。

技术力量的发展带来了一个不幸的后果，就是让我们相信，许多以前不可能实现的目标如今不但可以实现了，而且可以轻而易举地实现。有时候这种思想在项目的早期阶段通常表现为对项目的潜在收益过分夸大、过于庞大的项目范围定义以及过分乐观

却相当危险且不够详细的项目规划。因此我们需要明确确定的是：

a、提议的项目进度表是否现实可行；
b、项目的商业案例是否可行；
c、解决方案在技术上是否可行；
软件项目的规模和复杂度是项目成功与否的一个决定性因素。


4、软件项目的引入必然会为组织带来广泛的变化。

新技术对使用新技术人员的角色和责任带来的不少的影响，容易导致有关程序角色和责任的不明确。因此在项目计划中纳入培训成本和时间进度以确保员工知道如何使用和维护系统是至关重要的。没有合理的培训就是永远不可能实现软件投资的全部潜在收益。更重要的是，缺少培训可能会为项目带来商业风险和运作风险，这些风险可能会最终威胁项目的长期可用性。


5、清晰可见的项目管理结构对项目至关重要。

在管理结构中必须存在定义清楚的角色、责任和义务。在项目的开始阶段就应该确定正式的报告结构以及与高级管理层交流的途径，同时在项目的整个过程中予以保持。

6、首先处理好人员问题

永远不要忘记，人才是项目成功的唯一最重要因素。人员开发计划必须与组织中的项目管理框架同步进行，从而提供培训、业绩评估、分派工作和职位晋升相关的机制。（哈哈，谁都希望项目团队里都是高度主动性和熟练技能的员工）


7、接受风险，但要严格管理风险

IT系统的成功实现需要有效风险管理所支持的创造性思维。风险处理和变革是提高竞争优势的重要力量，但很大程度上还是取决于组织文化对这些方面工作的鼓励和支持阿。当然项目也要及时对一些影响项目进度的功能模块进行调查并重新审视风险分析工作（以及后续的风险管理工作），从而对基线进行重新评估并相应的调整计划。


8、始终评审项目的可行性

项目开始之后，时刻对项目成功的依赖条件进行监督是至关重要的。变更的影响可能导致最初的投资评估毫无意义。因此，商业案例应作为项目过程中一个持续使用的参考。如果认为投资的项目无法实现预期收益，就应当毫不犹豫的终止该项目。一旦作出终止项目的决策，就不要将这个过程变成一个冗长而麻烦的过程。放弃项目并继续前进，确保我们可以从这个过程中学到有用的经验。导致失败项目耗费高额成本的一个关键因素往往是由于终止项目本身这一过程过于冗长。


9、管理外部供应商

应当对供应商的质量管理系统予以足够的关注，以确保这些系统有效并可在现有质量系统中进行评估。过多地依赖承包商对系统交付能力的保证，或者在项目遇到问题时忽略承包商的参与都会带来巨大的风险。最重要的经验是必须与供应商建立亲密的关系，但不要过于依赖他们。无论何时，客户都必须保留他们对项目及其进程的所有权。也就是说，我们必须评审外部供应商的能力和财政立场，将其视为获取和履行