前期在一个项目会议上经过大家一起讨论，按照BossJ的建议，将整个升级大致分成了3个部分：准备升级程序、准备数据、综合测试。看起来这个是一个不错的升级步骤。我大致做了个Project的，绝对粗粒度滴。

接下来的事情就是按着Project按部就班滴开始干活，由自己负责总控各个部分的进度。

第一阶段程序部分升级：80%的程序是使用原系统的一个新版本，在新版本上增加原来针对该客户定制的部分功能，及已有功能中业务上的小调整；剩下的20%是一个新系统中压根就没有的功能，需要从老版本上加到新版本上，而在老版本中这个功能模板跟其他模块还有很高的耦合。在我跌跌撞撞滴摸索+加班下，终于按时掐着Project上时间按时完成了。 这一部分的工作全是自己一个人来完成，很累！

第二个阶段数据部分升级：数据可以大致分成基础数据和业务数据。原系统中数据跟新系统的数据的组织方式整个不一样，整个数据库都重新设计过。基础数据还好办，在经过简单的加工后能很好的升级到现有的系统；业务数据就头大了，一开始我使用Excel修修补补的来进行迁移，后来发现Oracle的跨用户的操作，就改成了视图更新方式。这个过程中由于公司对Project上的时间要求比较严格，自己稍微有些压力，犯了一些错误，差点把数据跟新错误，一个很难发现的错误，最后还是在Debug下找到了源头，将数据更新回来。

客户提出需要修改一部分业务数据，期望这次更新能够一起给他们装进去。在Project里面对这部分的工作也是分成两快滴，能升级滴由我负责在数据层面操作，客户新增的信息我分配给了一个负责编写新版本业务代码的工程师A。首先我将客户提交的数据标准化，并就这些标准化后的结果更客户沟通，达成了一致，交给你该工程师。该工程师将这些标准化的数据录入系统中。这一阶段还算比较轻松，也是按照Project的时间安排来走滴。

第三个阶段整体测试：这里不是说前两个阶段没有进行测试，而是指的在整个程序和数据都准备完成后对系统进行一个测试。主要目的是测试业务数据的装入是否正确、客户定制要求是否满足。

在Project里面我安排了两名工程师G和A来协助我完成，分别给他们细分了下测试的内容。考虑到客户定制的模块功能相对简单，我安排了新进入团队的G来完成，给了IPMSG上发了一些简单的说明如何测试的文字。A就是前文提及的添加业务数据的工程师，他负责由我升级的数据。不过这个任务比较重，我只给他分配了测试业务部分的数据，而基础部分的数据是为业务部分服务的在数据升级阶段我也做过一些测试，基本上问题不大。而我负责测试有A完成的新的业务数据和负责调配资源修改程序的BUG。

说到测试，前期写过一片叫 我的测试观 的文字。

所有的问题都在第三个阶段爆发出来了，G发现了一些问题，并记录反馈给我了，得到这些记录（我们没有bug管理系统）后，我开始跟G进行沟通，确定了问题的所在，于是我放下手里的测试开始修改这些Bug。

A也发现了新版本程序的一些Bug，发现测试无法往下进行，在给我进行反馈后，他开始修改这些Bug，前文提及了A就是负责写这些业务的工程师（我们没有专门的测试）。

G现在在干吗？空闲？资源不能空闲，他被其他的工作占据了，并且暂时无法释放出来供我使用。好吧我要Review我的Project，把G这天的时间排除出去。

我继续改我的Bug，发现问题不少（一开始的时候我只是从原来的系统中将这部分功能拿过来，并植入到相关耦合模块中），怎么办？好吧！重写ing。

问题来了A又需要去一个优先级别更高的项目中工作2天。好吧，那我继续Review我的Project，A也派出去了。

终于我的Bug改完了，我还需要一些资源来帮我进行测试，在周一的项目会上，BossJ给我分配了L，对系统的熟悉了解都很深，这下好了我有了更好的资源了。我给他安排了一些新的测试，避开了A已经发现的问题，可是L一会就发现了更致命的Bug，而不巧的是这个部分是A负责的？A所在项目的优先级比我高，怎么办，自己上咯。TroubleShooting可是我的强项，不出5分钟，原来A把业务逻辑编写错了。我一直比较坚持谁的Bug谁自己改（主要是认为这样时间成本会低很多），找到了错误，我通知了顶头上司S“我需要A来修改一个Bug，估计可能需要1个小时，不修改这个Bug我的测试无法进行。”S只好现将A的优先级别降降，给了我。

A开始修改他的Bug，修改完后，我取到了最新的code，building，pubulish，deployer，继续测试。

这期间L在干吗，对了他也发现了自己负责的一个Bug，改吧。

这回我总算明白了：原来我是在给新系统做测试来着。。。

本科学地是计算机科学与技术，没怎么系统地接触过这些概念，今天下班回来查找了一下项目经理的职责

1.确保项目目标实现，保证业主满意 这一项基本职责是检查和衡量项目经理管理成败、水平高低的基本标志。
2.制定项目阶段性目标和项目总体控制计划 项目总目标一经确定，项目经理的职责之一就是将总目标分解，划分出主要工作内容和工作量，确定项目阶段性目标的实现标志如形象进度控制点等。
3.组织精干的项目管理班子 这是项目经理管好项目的基本条件，也是项目成功的组织保证。
4.及时决策 项目经理需亲自决策的问题包括实施方案、人事任免奖惩、重大技术措施、设备采购方案、资源调配、进度计划安排、合同及设计变更、索赔等。
5.履行合同义务，监督合同执行，处理合同变更 项目经理以合同当事人的身份，运用合同的法律约束手段，把项目各方统一到项目目标和合同条款上来。

基本上任何项目都适用，很宽泛，太宽泛的东西作为Abstract Class还行，具体到某个行业还是需要的具体的Class，又找了找具体到软件行业职责

1. 制定项目计划，并根据各种变化修改项目计划
2. 实施 项目的管理、开发、质量保证过程，确保客户的成本、进度、绩效和质量目标.
3. 制定有效的项目决策过程
4. 确保在项目生命周期中遵循是实施公司的管理和质量政策
5. 选择一个能够精确衡量项目成本、进度、质量、绩效的项目距阵
6. 风险管理
7. 招聘和培训必须的项目成员
8. 确定项目的人员组织结构.
9. 定期举行项目评估(review)会议
10.为项目所有成员提供足够的设备、有效的工具和项目开发过程
11.有效管理项目资源

网络上出现的多的就是这11条，我就在想什么样的人，或者说是该具备什么样的素质的人才能担任这一角色呢？我现在是否真的能胜任该角色呢？又找到了如下的国际软件项目经理的七大素质

1、在一个或多个应用领域内使用整合了道德、法律和经济问题的工程方法来设计合适的解决方案。
2、 懂得确定客户需求并将其转换成软件需求的过程。
3、 履行项目经理的职责，善于处理技术和管理方面的事务。
4、 懂得并使用有用的项目管理工具。
5、调谐互相冲突的目标，在成本、时间、知识、现有系统以及组织的限制下找出可接受的折衷办法。
6、在一个典型的软件开发环境中谈判、有效地工作、在必要时进行领导，并与有关负责人（包含外方）进行良好沟通。
7、 从最初创建建议书一直到项目签收结束都应用国际标准。

这里啰嗦几句，跟主题无关。最近老看到一些什么“大公司做人，小公司做事”的论调，相当不以为然，调整好自己的
心态无论做事还是做人，真最重要。虽然自己没能做到”像随时要离开一样做好准备，像永远要留下一样用心。”但是
还是尽量认真做事，认真做人吧。

好了言归正传。同事L曾戏说，我们真正把客户当做我们团队的一部分，由他们负责来测试。我想这个是由于欠缺规
划，或者是协调的不合理的原因。时间紧固然是一个因素，但是我也从来没见过暴雪因为时间紧就让玩家来测试的，
他们宁愿担着跳票带来的风险也要践行“暴雪出品，必属精品”。

没了解过专门的测试团队是如何工作的，但是个人觉得这个不光光是测试本身的问题。
为什么需要测试？提高软件质量，给客户提供优质服务。软件质量是由软件整个开发生命周期决定的，从需求分析，
到概要设计，到编码，到单元测试，到集成测试。每一环都会影响到软件质量。
如何测试？现在很流行的TDD，敏捷等都提倡将测试提前，尽早发现问题。这里要提一句关于敏捷中常用的”拥抱变化
“的是一个很好的理念，将测试提前才能很好的发现问题，发现需求上的不足，正”真拥抱变化”,还记得Bob大叔的
MarkIV型咖啡机就是这么产生的。那么涉及到测试时的具体操作该如何处理呢？如单元测试的时候，可能需要设计一
个简单的测试环境，一些尽可能多的覆盖实际应用的测试用例，对测试结果有一个预期，能很好的发现问题。这里提
到的测试环境和用例的设计，需要对实际的业务有一些了解，符合8/2原则，设计的用例至少要覆盖实际应用中的80%
场景，对另外的不场景的20%应该单独测试。到了系统整体测试的时候，在场景选择，用例设计的就需要考虑跟多的
因素了。比如对软硬件环境（可能这个应该算作压力测试吧）的要求，用例选取需要覆盖到系统中各个模块中等。
反观现在我们的开发过程，需求跟设计是放在一起做的，甚至有一些设计来限制需求的感觉（当然这个没有任何问题，软件本身就是为了来简化人工操作，提高效率的），设计出来经过一些简单的推演，大家就开始动手code，过程中会发现一些问题，再次讨论，修改设计（个人开始很喜欢这个过程了，有些类似于敏捷的迭代，拥抱变化）。自己做一些测试数据测试完成后，交付模块整体测试。

看起来很美的一个过程，实际操作的时候，发现很多问题，其中有一些觉得就是缺乏很好的测试。

需求跟设计是否真的能分开，没必要争论，有很多需求确实是泡沫，在设计过程中跟客户沟通、交流，发现原来他们要的那个需求根本就不是原来他们提出来的，有了一个简单的设计再跟他们沟通，他们反而自己提出剪掉那些泡面。
问题就在我们的沟通机制做的还不够好，还需要规范、高效一些，记得项目过程中好几次开会的时候，零时被叫道会议室，还没明白过来是怎么回事，就开始了argument，最后发现大家要表达的是一个意思。当然这个argument也带来了大家对这个设计理解更加深刻，但是否只有argument这一种方法来理解设计？是否可以在讨论之前，设计者自己出具些能覆盖整个项目的测试用例，先分发给大家参考一下，或许大家能从中发现一些不足，一些亮点，下次设计的时候借鉴”团队不是一群码农”。这个是关于设计阶段的，到了code阶段，还会对设计有一些改动，这个时候更需要有一些好的用例了，因为往往需要修改的设计会牵连到很多的模块，而修改的提出来之一个模块的负责人，这个是需要该木刻的负责人出具一些用例，来表明前面的设计不能满足，而后面的设计能很好的实现，将这些用例分发相关模块负责人，共同探讨一下是否会对其他木刻有冲击。

以上文字写于某个等待某个测试数据的中午。

前段时间（前2个礼拜），忙着给一个基于Web的绩效管理项目作Close，这个项目其实是一套管理类的软件，而Close的工作实际上就是给做那个项目的二期。在项目现有的代码上增加一些功能，比如很简单的一个例子，以前有一个月度的考核，现在需要一个年度的考核，年度的考核基本上跟月度考核一致，如果熟悉面向对象开发的或者了解设计模式，一定会很自然的想到一个叫“模板”的概念，通过抽象来重用、重构软件。问题来了，年度的成绩有很大一部分来自月度考核的结果，好吧，再抽象出一个成绩的接口，由这个接口去负责取考核结果，想法很好，可是你行不通（当然这些更应该在设计之初就考虑的问题）。

这个项目是构建在一个自定义的框架上，为了提高开发效率，框架作了很多工作，开发者只需要调用指定的方法就能完成诸如控件绑定、数据库访问等一些内容，为了进一步减少工作量，有一个小的工具软件专门负责生成数据库访问相关代码，当然有的必有所失，这框架最大的不足就是对类、接口等有很多的限制。实际开发过程中，只需很简单的写一些业务逻辑上的代码，看似一个很完美的构想，如果开发一套系统只需简单的设计一些业务逻辑，真是太美妙了，（微软就是这样设计的MOSS的，微软每次Release产品几乎都会展示一些拖拖拽拽的动作来完成很多功能的Demo，捎带提一下博客园的一篇文章http://www.cnblogs.com/JeffreyZhao/archive/2008/12/10/i-cannot-bear-any-more.html）工业化代码将由此产生。可如果真的细想一下，发现会有很多问题，由于框架对类、接口上的限制比较多，像前面举例说到的项目的二期，几乎似乎无法通过现有代码重构来实现的。在实际操作中我是沿用了分与合 里提及的 CV大法，而这中方法的弊端显而易见，如果需求稍有变动，Nightmare is comming。

从维护这个角度看，并不见得会提高开发速度；从参与开发的人员特别是没参与业务逻辑设计的开发人员角度看，涉及到的业务逻辑本身相对简单，几乎是全部的面向过程编成的思想在做Code，每天陷入一些很无聊的重复逻辑调试中，对开发者本身很不利（并不是说面向过程有多么的不好，可大家都海还面临着衣食住行的问题，开发者本身的身价肯定跟自己的技能挂钩的）；从公司角度来看这个问题就更严重了，公司的产品本身有“质量隐患”，容易把市场做烂，参与制作产品的员工又有“后顾之忧”，担心在这里做了一段后，相对业内其他人员毫无竞争力，有些人财两空的感觉。

需要申明的是，这里没有任何对这个框架的不满的意思，更不是发牢骚，只是明明已经发现这个问题，该好好想想如何改进现有的框架，还是跟其他一些公司一样，沿用一些开源的框架。

公司开始以系统集成商的角色广泛接触相关领域从业人员，一方面通过合作伙伴（姑且这么叫）DC联系移动视频
监控、移动报表的相关软硬件厂商，另一方面专门抽调人手（员工F）学习客户现有的Exchange平台，了解市面
上的短信平台等，并委派其为移动方案经理。

历时一个月先后接触了移动视频领域2两、移动报表一家、短信平台3家、Exchange的相关软件代理商3家。跟一家移动视频领域的企业StarV建立了合作关系，也搭建了一个简易的Exchange的演示平台。针对客户的四点需求提交了一份简单的方案，主要包括一些大的框架性的东西，主要讲解了每点需求该如何实现，并起了一个很好的名字叫移动商务管理。将方案提交给客户后，客户总体上很满意，但是觉得方案整体不够细。

历时半个月开始细化方案，但是一涉及到具体的技术细节，像 Exchange环境的Front-End架构、像ISA的防火墙
功能、像移动报表如何与现有业务系统结合、像短信平台的技术指标对联通移动的支持、像数字视频信号如何转
换成模拟信号、像手机端如何点播视频文件等等，没实际操作过相关产品的F显得很无助，但是还是在Boss J的
压力跟大力支持下提交了第二版方案，第二版版方案中直接将公司一开始要推的Nokia的 PusMail 换成了Exchange自带的PushMail，F也搭建了基于Exchange的PushMail演示环境。

这一次客户相关部门的负责人来到公司（可能有来公司考察的意味），在公司的会议室Boss J给他们讲解了第二套方案。客户明显对提出来的邮件整合、短信平台、移动报表三块没多大兴趣，倒是对那个移动视频兴致勃勃。Boss J明显已经觉察到了这一点，但是一贯的积极坚定（一个很好的习惯）促使他继续朝着很好的方向努力。客户回去后，不久就来Email告知移动报表这个老总暂时又没这个需求了，而短信平台集团将会搭建，届时将会利用集团的平台。

Boss J带领F继续照理于完善Exchange的邮件整合和移动视频，过程中了解到客户直接找到了已经建立合作伙伴关系的StarV，StarV的经营模式是不做最终客户。当公司递交完第三版方案后没几天，客户相关负责人电话练习Boss J,“很遗憾，邮件整合这块您的方案不够细，我们已经将这部分的工作交由一家专门做这个的公司来负责；倒是咱们的移动视频这块，希望能看到演示效果。”Boss J还是试图挽回这个局面。事后BossJ和F才发现提交的关于邮件整合的部分，确实明显的很不专业，虽然F的演示环境就是按照提交的方案来做的。

客户随即提交了几个文件过来期望看看在手机端的效果，F联系Starv的负责人员，解决了客户手机端观看设置等相关问题。之后Markting的就一直咬着移动视频这块跟客户周旋，期望能早日签单，不幸的消息再次传来，客户希望通过投标来找到合适的方案来升级现有的监控系统到移动视频监控。

更不幸的是Starv告知，前期提供的解决方案中用一个设备，而该设备的提供商H也将参与竞标，在StarV的联系下Boss J 跟H、Starv的相关负责人进行了一次会晤，觉得我们基本退出竞标，但是处于客户关系维护等考虑，公司将继续参与投标，并与H合作帮其挤掉其他竞标对手，标书上技术方案由H方提供。Boss J将这个情况告知F，让其将工作重心转移到其他工作。

事情到这里原本该结束才对，谁知H半路摆公司一道，技术方案明显晚于约定时间提供，给过来的技术方案完全违背公司最初给客户的推荐，而且方案本身十分简陋，基本就是一个根本拿不出手的东西，F只好将以前的方案拿过来，撇开手上其他工作，全力以赴制作标书。

唱标现场，H又给公司下了一个套：客户要求唱标内一个礼拜搭建一演示环境，而H相关负责人说是提供给公司的方案中涉及到的设备最短的采购周期需要一个礼拜。客户的口气明显很不客气，缺乏临场经验的F面对这一突发情况有些紧张，将原本准备好的讲标中一些出彩点给遗漏了，甚至还有明显的前后矛盾之处，好在公司是第一个上去讲标的，在场的几位客户负责人还没能反映过来。

而很不幸的是我就是那个专门被抽调过来的F，而万幸的是我在这一过程中学到了不少东西。描述过程中尽量采用了第三人称的视角，但是还是有些个人感情色彩。

关于过程中学到的东西，下篇博文将会做个小小的总结。
To Be continued……