这是个简单的MIS项目，核心算法很少，超多的报表和数据维护页面。我是这个项目的PM，在项目开发过程中测试出来的问题归总下来，我认为这些是可以项目开始之前进行规范的。

1.             有的同事把一些数据的ID hard code在程序中，重新导入数据时ID发生变化，如果找不到ID，程序就会运行错误；

2.              有些初始化的值考虑得不全，结果在一些页面因为匹配不到数据而运行出错；如，年的下拉框数据；

3.              报表中出现比较多的就是排序问题，一开始就没有规定每张报表的排序要求，所以很多报表都忽略了排序，而这些往往都直接给用户带来不专业的感觉；

4.              报表的边框粗细不均匀等问题也有存在；

5.              一些综合统计的报表，比较明显存在大家业务经验不足等问题；如果有相关的一批数据，如果其中之一在统计条件中没有发生业务数据，其他的也显示不出来，或者出来多条记录；

6.              最初还有报表字段取错，运行出来的数据错误；

7.              报表的所见并不能完全的打印；如日期打印不全等；

8.              有的同事在开发过程中，选用了控件的最大长度来控制用户输入的长度，而在新建的页面采用复制的旧的页面造成控制长度出现问题；

9.              在报表方面，一般用户的查询条件是从当前年的1月1日到当前日期；而在记录维护页面，需要显示的是当前月的1日到当前日期；

10.           开发文档的作者很难追溯到；数据库对象视图没有作者，很多页面都没有作者；

 

从XXX的第一轮需求调研结束后，和同事一起总结了需求开发的中的难点，我的同事觉得需求开发得难点就是对获取的需求进行正确有效的分析。举个例子我们在需求过程中经常会问“你们现在对订单资料是怎么进行管理的，具体步骤是什么？具体存在哪些问题？这些问题是否都希望由系统来帮助解决？”，然后通过获取到的资料进行整理，画出原型与客户进行确认。

原型是经过初步需求分析的产物，意味着通过给客户看我们的解决方案来一起确认并达成双方的共识，以降低项目开发阶段给双方带来的风险。
从我的工作经验来说，以前从事的是内部服务系统业务，谈需求的时候就是和自己的同事‘聊天’，形式不受拘束，大家可以谈得很开，比如我可以问很细节的问题，包括挖掘对方部门的业务根源，弄到最后有些部门的leader觉得我好像在抢他们的饭碗，但是我觉得只有这样我们才能给出理想的解决方案。
但是在正式需求的场合就显得很不一样了，你必须准备充足的需求问题列表，同时要保障沟通顺畅。在需求过程中要记录尽可能多的需求内容，整理需求的时候还要能够体现业务完整性。

半夜感觉有大风在刮,放在窗台上小花瓶摔碎的声音让我有了确定的感觉,台风来了.因为上次深圳紧张准备应对的"珍珠"台风,结果从深圳擦肩而过,所以我还想着:"台风要来了而已"!还在床上做着美梦,好像在等着电话响,要是这时候有人打电话过来说因为台风来临今天不用上班该多好.上次因为强降水,路面积水不好穿行,所以休假在家,结果了解到同事们都按时到办公室上班,有一种很无地自容的感觉.但是电话还是没有来电响声,没多久闹钟响了,看来今天得准备去上班,哪怕半路中收到不需要上班的消息.起床了,切身感觉到"派比安"台风来了,花园有摔碎得小花瓶,还有一些枯叶,还有一张座椅翻了,幸亏两个盆栽还好好的,看来和"派比安"对抗也没有问题,心里在偷着乐呢.搭乘公车来到办公室,还好是No3,说的过去,不一会儿阿姨来清洁办公室,今天运气不是很好,阿姨使用吸尘器把我耳机带的一边卷进去乐,怎么也弄不起来,那只好大方点喽,同阿姨说剪掉算了,看真那办只耳朵,唉没有办法啦,只好先将就喽.

打工族一般都知道有出勤奖，我们每个月有100元的全勤奖,但是只要迟到2次就没有了.所以一般很讨厌月底了还要迟到,因为坚持不容易.呵呵。其实我很反感迟到，以前6、7年的工作在记忆中只迟到过1、2次,现在换工作要乘车，30分钟的正常车程,有时可能要塞上1小时甚至更多,所以很容易迟到,就算自己有那种厌恶迟到的感觉又能如何摆脱呢.今天早上深惠路上的车就塞个死死的,半个小时才晃了晃,外面还下着雨,车上人挤人,雨伞的水不是蹭上了也挨上滴上了。上班的时候大家又都比较讲究着装,看来又要泡汤了。别提了,我早上还摔了一跤,倒霉吧,大厅一楼经过雨伞的滴水后变得好滑,一走急了就半跌,尴尬不说,幸亏不是浅色的长裤,否则又要郁闷一天.

企业要提高自身的核心竞争力,那么本身的信息化程度是一个重要标志.信息化可以理解为对管理思想的关注程度,成熟理念的接纳能力.可能要给企业推荐一些应用软件,注入一些管理理念或是体现了自身的一些管理思想,这对企业的发展是很有益的.如果企业因为自身的管理理念比较成熟,可以达到流程化自动化的程度,那企业就会考虑引进软件或定制软件来提高生产力;可是如果是要把一些现成的软件推荐给企业,为企业注入一些管理理念来提升生产力或规范流程作业,往往就比较困难.借我的同事的口头禅套路:有困难并不可怕,可怕的是没有困难.困难往往也是另一种价值的体现.我现在在研究客户关系管理CRM,从CRM的发展过程来看,比较仓促上阵,由于强大的市场需求,CRM迅速进入到各行各业.CRM源于销售自动化,后来逐步进入客户服务、市场营销和信息技术部门，现在又在金融服务、制造、后勤和采购等领域出现，最终会进入到经理决策领域。都只描述了客户关系管理的发展过程，没有说明客户关系管理到底是什么。CRM是什么?

第三章 "硅谷"
整个开发团队一起搬到了弗罗泽克盆地,这个地方被命名为硅谷.在这里阐述的是一个项目团队需要怎样的环境和外部支持.汤普金斯提出"还有良好的网络支持。也就是说，每个人的办公桌上都要有最新的计算机工作站，都必须用以太网或更快的网络连接起来。我还要全职的网络维护人员，以及全套的集线器、路由器、T1或ISDN出口。”硅谷成为世界上第一个项目管理实验室.

第4章 CD ROM工厂

要成为世界最大的软件出口国,必须需要建筑 CD ROM工厂 .但是 CD ROM工厂 的建设进度和设计都存在问题.CD ROM工厂的厂址在雨季的时候卡车驶过会造成大泥塘.但是设计和进度都是元首定的,如果要变更那简直是不可能的呀.这种情况在项目中也是经常见到的.但是汤普金斯心中主意已定,并给元首发去资料.
汤普金斯认为变化是让人们觉得更安全的要素,而逃避风险是致命,因为只有积极降低风险才有机会获得利益.

安全和变化

除非感到安全，否则人们就不能去迎接变化。

在所有成功的工程中(以及在绝大多数其他有价值的工作中)，变化都是基本的要素之一。

安全感的缺乏会让人们反对变化。

逃避风险是致命的，因为这会让你也得不到与风险同在的利益。

人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。

第5章 元首
头儿的地位会给你带来管理上的优势？
负面效应:威胁不是提高业绩最好的方法。如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成。更糟糕的是，如果目标没有实现，你就必须兑现你的威胁。

第一章：新的机会
汤普金斯的管理思想：
1、管理中最困难的是人，让正确的人去做正确的事。这就是优秀的管理者和平庸的管理者之间的区别；
2、寻找合适的人选。然后，不管你之后做错了什么，这个人都会拯救你。这就是管理所有的艺术；
尽管汤普金斯这样优秀的人最终还是成为ReSOE（离开，到别处去寻找机会）。但是没过多久汤普金斯就获得新的机会，被绑架到摩罗维亚去管理一个计划成为世界级软件的工厂。

第二章 对抗卡布福斯
汤普金斯在他的梦中：汤普金斯 pk 卡布福斯，是管理软科学和管理硬科学的对抗。
一个没有管理过任何人、任何事的卡布福斯来给项目管理经验丰富汤普金斯上项目管理的课程。卡布福斯的课程内容为“将制订出甘特图以及波特图、状态报告、与人力资源部门之间的交流规范、每周会议的计划、电子邮件的使用规定、时间卡、进度跟踪记录、项目里程碑报告，还有制订一个质量管理程序”汤普金斯把卡布福斯上的项目管理的课程称为文案工作，因为卡布福斯的项目管理的课程中没有谈到对人的管理，而只是一些枯燥的文档，不再有管理的作用。而汤普金斯认为项目管理的四要素是：人员的选择、任务的分配、激励和团队建设。

战争终于爆发了,有点郁闷.纯粹技术的人员都不太喜欢和其他人沟通,都很认同自己的技术,并想很好的保护起来.如果一个团队有两个这样的人物,或者是两个实力都很强的的技术高手就比较麻烦.任何一方沟通封闭都会激怒对方.有什么办法可以化解呢?原则上是天外有天,强中自有强中手,难道不沟通不交流就能永处上游吗?所以任何事情还是要平心静气才好,至少给自己留条后路.从另一个侧面来看争吵又是好的........

很块要去蛇口做项目了,公司租了三室房,由我和另外两位同事居住.前天就两位同事就已经先搬过去,我过段时间也要搬过去.重新体验集体生后,内心有不错的期待哦,最主要我依赖这次现场客户来提升自己的实力.是不是在打小算盘呢?谁知道呢.我的主要职位是业务分析,但是具体负责测试和实施,看起来有点怪吧,其实
我还是比较清楚,自己该做什么.这可不是旁观者清哦.
想说项目的成员很少会是固定角色,很多时候一人担当多个角色,项目的工作使得女人工作起来象男人,男人
工作起来象机器,在看世界杯的时候就在讨论那些球员象机器或者非人的种类,哈哈.

1.               引言

    《需求启动会议》作为需求过程所涉及文档的一部分提出。文档内容主要是一些具备可操作性的方式方法，并且给出实施依据。目的是在具体的软件项目过程可以借鉴其中的内容并且高效地进行应用。

2.               会议背景

    项目的甲乙双方签定合作合约后，就进入项目的启动阶段。项目启动阶段的核心工作是完成需求，其中项目甲方是指客户方，项目乙方为开发方。

　　

3.               常见问题

    项目甲方的积极参与对构造需求是非常关键的。实际操作中要做到这点存在着一些问题：甲方自身的提供需求的能力以及他们是否愿意积极地参与进来。我们可能会说，“有时要找出这些人有一定困难”，“要让他们参与进来不是很好办”。如果项目甲方不能或不愿意参与，这就意味着项目失去了内部支持这条成功的条件。

 

4.               会议内容

事实上，提供需求、解释需求、指定需求和排列需求优先级是项目甲方的职责所在。此外，项目甲方有权利要求开发队伍投入时间去辨别和理解这些需求。项目甲方负责提供需求，开发组负责理解和实施。召开需求启动大会，旨在动员涉众人员关注需求，积极地参与到需求的过程中来。使得对需求的重要性有足够的认识，同时也为项目甲乙双方在以后相互协作过程中有一个好的沟通平台奠定好基础。

 

    会议主要内容是：

1、  开发方简要阐明需求的重要性。开发方必须使用通俗易懂的语言说明需求是项目分析、设计和实施的依据，用户只有把需求描述清楚，而且开发人员真正了解了需求，项目成功才有保证等内容。以下列举项目成败与需求的相关数据依据（可以根据实际情况更新）：

ü       失败

Ø       缺乏用户输入(13%)；

Ø       不完整的需求(12%);

Ø       不断变化的需求(12%);

ü       成功

Ø       用户介入(16%) ；

Ø       有效的管理(14%) ；

Ø       清晰完整的需求(12%) ；

 

2、  开发方简要阐明完成需求的一般过程。主要是描述在需求过程中需求的的各个阶段以及开发方一般采取什么样的需求手段、方法。具体内容请参照其他相关文档。

ü       需求收集

Ø       报表，表单

Ø       面谈，会议

Ø       现场业务参观

ü       需求分析

Ø       发现问题背后的问题：深耕法

 

ü       需求定义

ü       需求确认

ü       需求规格

ü       需求变更控制

 

3、  阐述《软件客户需求权利书&软件客户需求义务书》的内容，建议以签约的形式完成。

ü       客户有如下权利：

Ø        要求分析人员使用符合客户语言习惯的表达。

Ø        要求分析人员了解客户系统的业务及目标。

Ø        要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。

Ø        要求开发人员对需求过程中所产生的工作结果进行解释说明。

Ø        要求开发人员在整个交流过程中保持和维护一种合作的职业态度。

Ø        要求开发人员对系统的实现及需求都要提供建议，拿出主意。

Ø       描述产品使其具有易用、好用的特性。

Ø       可以调整需求，允许重用已有的软件组件。

Ø       当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。

Ø       获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

ü       客户有下列义务：

Ø       给分析人员讲解业务及说明业务方面的术语等专业问题。

Ø       抽出时间清楚地说明需求并不断完善。

Ø       当说明系统需求时，力求准确详细。

Ø       需要时要及时对需求做出决策。

Ø       要尊重开发人员的成本估算和对需求的可行性分析。

Ø       对单项需求、系统特性或使用实例划分优先级。

Ø       评审需求文档和原型。

Ø       一旦知道要对项目需求进行变更，要马上与开发人员联系。

Ø       在要求需求变更时，应遵照开发组织确定的工作过程来处理。

Ø       尊重需求工程中开发人员采用的流程（过程）。

4、  明确需求过程中可能涉及的场地和沟通方式等问题

 

5.               会议特点

1、  正式的会议：一般有项目甲乙双方的高层、甲方核心业务人员和乙方项目经理需求人员等；

2、  参加的人员多：一般要求涉众人员都要参加；

3、  可以是正式会议的议题之一。也可以单独进行。

 

6.               会议目标

1、  达成对需求重要性的一致理解；

2、  了解甲乙双方在软件需求过程中各自拥有的权利和应尽义务；

3、  促进甲乙双方的涉众人员相互了解、认识；

4、  确定主要的沟通方式；

 

7.               会议成果

1、  签定了《软件客户需求权利书&软件客户需求义务书》；