http://15465259.qzone.qq.com Sun, 29 Nov 2009 18:02:42 GMT Qzone zh-cn Copyright (C), 2005-2008, Tencent Tech. Co., Ltd. Mon, 29 Sep 2008 04:14:43 GMT http://15465259.qzone.qq.com/blog/1222661683 现在，因为学习，工作，生活等等原因。视力问题被显著关注了。戴眼镜的年龄段越来越小，从原来的大学生。到80后的高中。现在，甚至小学就开始有很多人戴上了眼镜。眼睛的功能越来越弱。有些人，离开了眼镜，很难顺利生活。那么，眼睛是否在退化呢？未来的人类。是否会失去我们的眼睛呢？

观点1：人类的眼睛不会退化。
虽然眼镜很大程度上辅助了眼睛的功能。但是没有根本取代眼睛。眼睛仍然在日常生活中，属于常用的器官，因此不可能退化。

观点2：人类眼睛会退化。
随着眼镜，隐形眼镜的经常使用。人类的眼睛实际上是在依赖于工具使用。一旦发现能够替代眼睛的工具出现。例如植入式芯片来控制人工眼球。那么眼睛就会退化。
]]> http://15465259.qzone.qq.com/blog/1222661683#comment 544 Mon, 29 Sep 2008 04:14:43 GMT http://15465259.qzone.qq.com/blog/1222661683 http://15465259.qzone.qq.com/blog/1217574793
大量照片，已经上传到我的图博。
http://shaolei02.photo.pconline.com.cn
欢迎去访问哦。 ]]> http://15465259.qzone.qq.com/blog/1217574793#comment 513 Fri, 01 Aug 2008 07:13:13 GMT http://15465259.qzone.qq.com/blog/1217574793 http://15465259.qzone.qq.com/blog/1214209990
冰洞扶溪涧，
山风撼石林；
青虫鸣幽谷，
太乙笑迎宾。



]]> http://15465259.qzone.qq.com/blog/1214209990#comment 513 Mon, 23 Jun 2008 08:33:10 GMT http://15465259.qzone.qq.com/blog/1214209990 http://15465259.qzone.qq.com/blog/11 “和谐？，谁知道呢？我猜应该不够和谐。”
“算了吧，我可不知道怎么让骨头长肉。困难的事情交给领导去做，这是我的原则。嘿嘿”
“你说没有人会怪茅坑？那我问你，如果现在让你蹲在大马路上拉屎。你能拉出来吗？”
“大马路不是茅坑？那我给你拉个帘吧。‘只要没人瞧，遍地是茅楼’”
“你说什么？这个问题没意义，拉屎是个人的问题？”
“恩。你光拉屎是个人问题。但是你却埋怨茅坑，可就不仅仅是你个人问题了。这里包括茅坑，茅坑里的苍蝇，茅坑里的石头，茅坑里的。。。。。。”
。。。。。。十分钟后。
“呃、抱歉，你吐够了没？吐吧，吐啊吐啊的，习惯就好了。”
“好，让我们直接面对这个问题来分析一下，为什么会产生这种情况。”
“首先，你确实拉不出屎。当然前提是在大马路——好吧，在一个乡下的肮脏的厕所，这里和谐一下。”
“接下来，埋怨茅坑是一种主观行为。是一种思考，而非客观事实。而且，这出自于拉不出屎的你，哦，拉不出屎的某些人。”
“让我们重新先整理一下这个命题，换一种说法。如果我无法出恭，是因为茅坑不适合我。”
“再下来，我们改变其中的一些条件。例如把乡下肮脏的厕所，改为五星级大酒店的高级厕所，有热水龙头的那种。^_^”
“很好，你终于可以解脱一下了。”
“于是你有了结论，拉不出屎，完全是因为茅坑。”
“我们的分析对吗？完全正确，这我敢肯定。但是忽略了一个问题，如果只有这么1个肮脏的厕所呢？好吧，你应该考虑一下大马路了。”
“再继续我们的假设。在这个茅坑你就是拉不出来。然后——”
“先别吐了，听我说完。”
“我想总有一天。你一定能拉出来。至少会有那么一次。”
“于是我们有了另一个结果，拉不出屎赖自己。”
“2种思考方式，换来了不同的结论。也许，可能，该怪自己还是该怪茅坑呢？”
“点背不能怨社会啊！”
标题的这句话是我的家乡东北的一句俚语。大致的意思是有些人在某些情况下没有办法很好的解手，于是便埋怨厕所不好。所表达的含义是，当某些事情的结果不如意的时候，只会一味的埋怨客观环境，却不懂得思考主观问题。和成语“怨天尤人”所表达的意思相似。
其实道理很浅显，似乎每个人都能懂，也知道这么做不对。但是，在遇到问题后，能够不这么想的人却很少。工作中，一个项目组工作失败，最多的不是检讨自己的问题，而是尽可能多的去找出公司的，客户的，或者同事给你所带来的麻烦。于是把这些说成导致失败的一个重要条件。生活中，夫妻间争吵，2个人更多的是发现对方的问题，而不是自己的错误。几乎忘了“一个巴掌拍不响”的道理。于是，人们在工作中，生活中变得越来越自大，越来越骄傲，因为任何错误，都不是自己的问题，而是客观造成的。那些能够清晰的从主观方面分析问题的人，便成了能够不断进步，能够获得成功的人。
换句话说，当我们遇到问题的时候，应该想的是“在这种情况下，我应该怎么做才能成功”，而不是“如果是这种情况，我才能成功”。 ]]> http://15465259.qzone.qq.com/blog/11#comment 512 Mon, 20 Aug 2007 11:24:25 GMT http://15465259.qzone.qq.com/blog/11 http://15465259.qzone.qq.com/blog/10 我把这个过程分为5个阶段，版本控制阶段（开发物控制阶段）、量化阶段、成果物标准化阶段、开发过程标准化阶段、项目管理统计阶段。实际上，每个阶段也都有他的完善程度。但并非第一阶段作的很出色才能进入第二阶段。事实恰好相反，项目管理的提高是需要依赖管理成本增加而存在。如果需要事事完美，可能花费的精力，远大于项目管理带来的好处。而公司更要为此而付出相当大的代价。这和我们的主题“渐进”所相违背。也是公司管理层所不愿看到的。
1、版本控制阶段（开发物控制阶段）。
之所以将后面用括号标注起来的名字为开发物控制阶段。我个人觉得也许叫做开发物控制阶段更贴切一些。因为这个阶段除了控制代码版本，还包括各种文档，甚至开发过程的版本控制。同时还包括权限的分配，开发物的展示，甚至项目开发过程中的教育培训内容等。
这个阶段的完善程度，决定着项目管理以后的进展情况，如果这个阶段的完善程度相对较低，就无法为后面的阶段提供动态，准确的信息，也无法为后面阶段提供便捷的高效的方法和手段。会造成管理成本的提高。但是，后面阶段的深入发展。必然会影响到版本控制阶段的完善。所以公司是先行完善版本控制阶段的管理制度，还是通过后续阶段逐步完善，都是根据公司的情况酌情考虑的。
2、量化阶段。
量化阶段的主要任务，是提出各种可以量化的指标。来减少项目管理过程中的不确定性，提高项目管理过程的计划性、通用性。对于量化指标，包括项目规模量化，设计效率量化，开发效率量化，测试效率量化，工作量量化，风险量化等等。这种量化好处是尽可能减少项目管理中的不确定性，通过数学的手段来提高项目开发过程的风险程度和准确把握项目过程管理的每一步骤。当进行量化的项目数量越多，对于日后的开发助益就越大。
这个阶段的完善程度，最直接的影响阶段就是项目管理统计阶段。同时对成果物标准化和开发过程标准化也有一定影响。量化指标直接决定项目管理统计阶段的统计内容。量化指标不足的时候后，便无法进行项目管理统计。同时，量化指标的制定也决定了成果物的标准化内容。和开发过程标准化的步骤。当然也可以在成果物和开发过程标准化的阶段中提出新的量化指标。但是这种可能性相对较低。反而在项目管理统计阶段提出新的量化指标的可能性还是非常大（而且通常重要的指标确实是在那时提出的）。
3、成果物标准化阶段。
成果物标准化的主要任务，是使项目开发过程中的对公司内部提交的开发成果物进行标准化。这种成果物不包含对公司外部的成果物。之所以这么说。是因为针对公司的客户即项目发起人来说，每个项目的项目发起人都会不同。而对于项目发起人所提交的成果物，是为了满足合同，及发起人的需求而提出的。项目发起人会为自己所提出的成果物支付相关的开发和管理费用。而不一致的项目发起人，会造成成果物的不一致，更遑论成果物的标准化。于是这里所说的成果物标准化仅仅指公司内部提交的开发成果物。
开发成果物的标准化分2个阶段。开发成果物量的标准化和开发成果物质的标准化。所谓开发成果物的量，是指开发成果物的数量。即所包含的内容的个数，例如公司要求每个项目开发必须为公司内部提交源码一份，时序图一组，开发进度表一张，开发计划一份，以及每月一份的项目费用支出表。这些便是项目成果物的量。而量的标准化就是让每一个项目在最后提交的成果物中，都包含相应的相关内容。而所谓开发成果物的质，是指每一个成果物的具体内容，例如源码中的写法，是否包含注释等等。质的标准化也就是让提交的成果物能有统一的格式和规范。便于日后统计和管理。
成果物的标准化阶段，对于开发过程标准化起到了一定的规范作用。在成果物标准化未实行的情况下。去做开发过程的标准化。会受到原有开发过程的阻碍，造成员工的不理解，必然大幅降低了生产效率。还会造成一些不良影响。而成果物的标准化一旦实施效果良好。开发过程的标准化便会水到渠成。以很好的姿态发展下去。
同时，开发成果物的标准化过程又是一个会降低生产效率的过程，在这个过程中所需要消耗的资源远远大于其它过程，因此对于这个过程的发展。切勿操之过急，尽力避免项目管理带来费用增加过剧等副作用。同时开发成果物的制定依赖量化阶段所提供的量化指标和版本控制阶段所完善的好的方法及便捷的工具。这些都能有助于减少标准化制定带来的副作用。在这个阶段，公司尽可能应用好的工具来提高开发效率。
成果物标准化的完善程度，在整个项目管理中起到了基石的作用，它和开发过程标准化决定了项目管理的基础。
4、开发过程标准化
开发过程的标准化的主要任务是将开发的步骤和方法进行标准化，这有些类似通用管理中的科学化管理。开发过程标准化可以在整个项目过程中是一个能够提高开发效率，减少项目开发和管理成本的一步。在这个阶段。公司会大量应用好的工具和方法来完善开发过程的标准化。同时开发过程的标准化能够减小人员的流失带来的损失。这也是国内IT产业普遍关注的问题。
开发过程标准化的完善。需要依赖于开发成果物的标准化的制定。以及版本控制阶段所提供方法。同时开发过程标准化还受量化阶段的影响。开发过程标准化并不是一个静态的标准化过程，而是一个根据项目情况而随时会变化的一个标准化过程。这个标准化的制定，并不仅仅是提出1、2、3、4步骤这样简单。还要根据出现的各种问题，提出如何进行决策，及下一步计划等等。好的开发过程标准化的制定。是一个漫长的长期的过程。
5、项目管理统计阶段。
在这个阶段。主要对项目管理中存在的成果物，量化指标，以及开发过程进行统计整理。得出适合于公司状况的大量统计数据。是项目管理发展的最高阶段。它便于公司在日后的项目管理中能够有大量数据可以查询，做到计划的准确性。上诉4个阶段的完善程度直接影响着项目管理统计阶段。
上面介绍了项目管理发展的5个阶段，那么分别处在这5个阶段的公司情况又是如何？
处在项目管理第一阶段的公司。3年前的维森公司便是如此。尽管公司一直想要提高管理，并制定一些标准化的工作。但是由于基础的控制和管理手段的不充分，造成了几次项目管理的改革失败。于是公司便困在一个以项目做项目的情况，每一个项目都是一个单独的整体。项目之间毫无帮助和可借鉴的内容。或者说无法在其他项目中找到可以帮助本项目的优点。当项目数量增加。项目规模扩大的时候。风险也随之增加。在这个阶段。依赖项目组的所有成员，任何人事变动几乎都会影响到项目最终结果。
处在第二个阶段的公司，康奈克虽不是典型（因为康奈克有些第三阶段的特性），但是以我的观点。康奈克的项目管理还是主要处于此阶段。简单的量化。和相对完善的版本控制，使得每一个项目的过程都能有个大概的项目开发计划和工程进度表。以及相对准确，适应公司的项目成本预算（主要指人力资源安排）。但是由于没有完善或进化到成果物的标准化阶段。每个项目管理的过程差异性相对变大。同类项目的可借鉴和参考的内容较多。非同类项目几乎是没有任何可借鉴的价值（或者说无法发现），对于开发过程的优点也无法深入挖掘。在这个阶段对于PM的依赖相当大。PM的好坏几乎直接影响到项目的成败。
处在第三阶段的公司。项目管理已经初具规模。他们可以准确地判断项目大小，并制定较为详细的项目计划。由于成果物的标准化。使得公司的项目几乎都在以相似的过程进行。对于员工的依赖减小。唯一困扰公司的就是内部成果物的标准化带来的额外的工作量。在这个阶段的公司。管理费用投入会相对其他阶段大很多。并尽可能寻找便捷的工具来减少工作量。这个阶段开始，对于PM的依赖逐渐减小，由于过程化的不标准对于员工的依赖在一定程度上有少量增加。
处在第四阶段的公司。过程标准化带来的优势已经很明显。项目管理的作用开始逐渐变大。并在逐步提高着公司的生产效率。项目管理费的增加用在一定程度上有所减少。项目的风险已经减少到一定程度。对于大型项目的分析和开发过程的把握更加深入。在这个阶段的公司。尽可能的扩大公司的经营范围。而不必担心管理跟不上造成的问题困扰。这个阶段对于员工的依赖性已经降到最低，员工的流失对公司的影响最小。
处在第五个阶段的公司。几乎都是一些国际性大公司。他们能够随时承接大型的项目委托，并通过PMDB(项目管理数据库)来提供需要的数据进行计划和分析。够最大程度降低风险。公司的项目越多，所积累的经验也就越快。自此项目管理形成了一种良性循环。
说了这么多，引回前话。这五个阶段并非完整的按步骤发展。而更多的是在一个阶段发展到一定程度的时候，开始发展下一阶段。并在最后一个阶段发展到一个程度后，又重新回到第一阶段的发展。尤其对于国内的IT企业，这一点尤其重要。公司在发展项目管理的时候。可以把每个阶段划分为ABCDE五个或者更多个等级。使每一个阶段在同等级下发展。当5个阶段的发展过程都达到同一个级别的时候。在重新确认重点目标，进行高级别跃进。这就如同迭代开发中的迭代过程。逐步发展，循序渐进即确保了公司的管理费用增加幅度。又可以在每一个等级下重新审视发展状况，提出新的提案。
最后祝每一个公司都能够找到适应自己的管理发展过程。为我国的IT产业腾飞助力。 ]]> http://15465259.qzone.qq.com/blog/10#comment 512 Tue, 14 Aug 2007 11:19:12 GMT http://15465259.qzone.qq.com/blog/10 http://15465259.qzone.qq.com/blog/9 当时觉得2个女孩很好笑。一点点小事。吵得不可开交，甚至大打出手。可仔细琢磨后，回想自己
的生活历程，这种事情不是也屡屡发生吗？是什么让我们做为旁观者的时候，可以清楚地看清事物
的本质；但是，当身在其中的时候，却有不免无法自控呢？于是这几天也一直在思考着这个问题。
得到了一个不完全，但还算是让我有些安慰的答案，就是“对与错”。
用哲学的话来说，“对”与“错”并不是客观存在的事实。而是事物发展在人的主观映像中的
反映。通俗点说。事物本就没有对错之分。只有对周围其他事物的影响。但是当人们去忽视了影响。
或者仅仅注意到一种影响或很少的影响的时候。于是人们把能够造成自己有利的影响的这种条件，称
之为“对”，而相反的，称之为“错”，也就是人们常说的，做对了，或者做错了。
那么，既然对错是片面认识得到的产物。也就难怪当我们作为旁观者，会笑话别人做的事情。而
作为当事者，却做着同样的事情。而人又是一种感性思维和理性思维共同存在的动物。那么就很难避
免片面性。而我们又应该如何少犯这种错误呢。
放弃对错的观念，也许是解决这个问题的方法之一。这个答案乍听起来让人觉得无法接受。因为
连对错都不分，还算是个“好人”吗？其实这里所说的对错，仅仅是人的一种主观看法。正直的人。
即使不去主观判断“对”和“错”。仍然不会做坏事。而卑劣的人，即使判断了什么是对错，仍然不
一定做好事。就如同人们常说的。“锁君子不锁小人”的道理，是一样的。在事物的判断中。放弃对
错的观念，转而用事物发展对其他事物的影响来看待事物的话。就不会冲动行事，也能避免很多不必
要的麻烦。对于陌路人、同学、朋友、兄弟、夫妻、父子之间的生活共处中，都可以起到很大的帮助。 ]]> http://15465259.qzone.qq.com/blog/9#comment 512 Tue, 02 Jan 2007 00:56:54 GMT http://15465259.qzone.qq.com/blog/9 http://15465259.qzone.qq.com/blog/8 在项目管理的过程中。就是一个使用方法论进行量化，来得到需要的相对数据。
然后再根据这些相对数据。来评审量化的方法。并改进量化的方法。这么一个
不断循环往复过程。
这么说可能太理论化。或者说太模糊。那么就举个例子来说明。
有这么2家软件公司。其中A公司在用项目管理的方式进行管理。他们将
自己做过的项目都完整的纪录历史过程，形成各种统计数据。另一家公司B没有
使用项目过程管理。每一个项目都凭借着自己招聘的出色的项目经理来协助完成，
转眼间3年过去了。A,B两家公司都招聘了好多项目经理，同时也有好多员工离职，
但是因为A公司使用了项目管理的方法。于是在软件项目中，形成了一整套适合
公司使用的管理过程，于是不管人员如何变幻，新来的人。总是能够严格按照公司的项目
管理过程来组织，并进行管理。同时由于有3年来的历史数据作为总结，可以很轻易的根据
公司的当前情况，来准确衡量项目的难易度，复杂度。于是做项目少有不成功的。
再来B公司呢？当初B公司由于没有复杂的管理过程，于是开发中的自由度相对很大。也给了
员工更大的发挥空间，开始的时候。项目做得非常成功。公司发展也很迅速，员工很快就变得
多了，但是当项目规模扩大的时候，就越来越难控制项目的质量。在加上缺乏以往的历史数据作为
依据，很难估计项目的成本和工作量，于是公司的发展变得越来越慢，同时由于人员的流失，更对
公司造成了很多困难。
举这个例子，只是想说一个问题。就是如果公司想要持续发展，想要做大，必须对项目进行
管理，必须进行流程化，量化。不然公司很难脱离创业时期，到达成熟期。
]]> http://15465259.qzone.qq.com/blog/8#comment 512 Mon, 18 Dec 2006 15:20:59 GMT http://15465259.qzone.qq.com/blog/8 http://15465259.qzone.qq.com/blog/7 前车之鉴，后事之师。于是便有了寻找下次成功他“妈”的念头。
首先，从项目的目标说起吧。
半年时间。总结了一下项目的目标。
1、利用新系统杀回原客户。
2、原有系统版权已经不存在，为了部门发展。需要新的系统。
3、扩大现有的市场。
4、使系统能够拥有更大的灵活性，来满足未来需求的快速变化。

那么针对目标。我们需要的是一个什么样的系统呢？
1、充分兼容原有系统，主要表现在数据结构的完整性上。
2、一个新的。可以注册版权的，无争议的新系统。
3、增加现有的功能、并保证能够解决最新的用户需求，和潜在的用户需求。
4、系统底层拥有合理的系统架构、完善的开发平台。

既然提出了我们系统要实现的内容。那么再来看看我们需要什么才能完成这样的系统呢？
1、拥有充分熟悉。并了解原有客户的领域专家。必须能完整分析、整理原有客户的业务管理模式。
2、拥有一个基层开发团队，能够进行进行新的系统的开发。
3、我们的领域专家不仅仅拥有分析原客户的能力，还必须有市场眼光，并了解相关行业的业务管理模式。
4、拥有一个或多个系统架构师，要求能够和领域专家们进行沟通，并将领域的业务模式。转成新系统的架构。同时还要求能够熟悉相关的开发工具。来搭建公司的新产品的开发平台。

了解了项目的必要充分条件后。看看我们具备了哪些，又缺少了什么？
第一，缺少相应的领域专家。
我们没有多个或者1个领域专家。于是在业务领域的分析，是依靠遗留下来的源代码进行的分析。这种分析的缺点是。总结了很多系统相关的分析（此处包括业务规则甚至用表和存储过程表示）。却无法清晰的分解出真正的业务模型。甚至在某些细节方面，表示出不理解和不清晰。
第二，我们拥有了一个基层的开发团队。这是我们所具备的。但是开发团队的组成并不理想。正常的开发团队要拥有
1个项目经理 （负责团队的协调，制定并监督执行开发计划，对资源的合理安排以及开发中对问题的决策）
1个架构师 （负责和领域专家进行沟通。并将业务模型分析，并整理出可供使用的系统模型，负责系统架构的设计和开发，负责开发平台的架构和制定部署计划。）
1个技术专家 （负责深层次技术的指导，技术难点的攻关，负责指出并协助架构师实现系统架构和开发平台。）
1个项目组长 （负责项目组的技术细节问题的解决，能够传达开发计划、开发思想和指导相应开发人员顺利进行开发）
N个开发人员 （负责具体的开发编码工作，要求开发人员能够在一定程度上正常使用开发平台和开发工具进行开发）
N个测试人员 （对提交产品进行严格测试，保证产品质量）。
这是我所理解的正常的开发团队。当然，在必要的情况下。有可能存在1人身兼多职的可能性。
而我们当前的开发团队是怎么个情况呢？

项目经理 （空缺）
直接导致在项目的开发计划无法及时地进行调整，团队成员沟通少。开发问题的决策往往要长时间商讨，即使这样。也很难得到一个明确的结果。

架构师 （我）
项目中的表现并不称职，
在系统建模中，没有将相关的业务模型完整地转化成系统模型。
在其系统架构上面表现得还算满意，组件的搭建方式，工厂模式的使用是的结构表现趋于合理。但仍有不完美的地方。例如接口表现方式不明确，服务器端组件的效率有待提高。各部分的偶合性还需要减小等。
客户端开发平台的搭建工作，只能说是完成，但并不让人满意。开发平台的易用性，通用性，稳定性还有待提高。

1/2技术专家（我）
这里解释一下为什么是 1/2技术专家。原因在于我对开发工具，三层技术掌握比较深刻。可是对于选择的数据库 DB2 掌握实在是有限的很，无法担当重任。另外对于 DOS 下的POS开发。也无法起到指导作用。
左右1/2的技术专家，自我感觉表现满意。解决了工厂模式细粒度组件架构上的技术问题。解决了组件调用的事务处理问题。

1/2技术专家（1-2人，不署名）（这里补充说明，此人并非任命技术专家。而是无奈之举中，挑选出的相应人员，因此对于工作成绩，是应该给于很大的肯定。）
针对DB2、POS开发的技术专家。DB2技术中表现得差强人意。（因为也不曾有过DB2的开发经验，摸着石头过河）。POS开发中，尚且看不出来表现，因为新系统中，并不打算改造原有POS，而旧有的改造，仅需要解决相应的DB2问题。

项目组长 （我）
表现还算满意。在开发的细节问题上，可以进行指导，并协助解决细节问题。并可以对相应的开发人员进行培训。

开发人员 （5人）
总体来说，在工作的完成质量上。还是很好的。但由于信心、开发积极性等主客观因素，使得开发的效率表现的不是很高。

第三、关于领域专家对于其他相关业务的分析，市场的预测等。在这里我们约等于0。之所以说约等于，是因为市场销售人员，有时候会获取部分零散的客户需求，但对于业务的整理，却为空。这部分工作。是由开发人员直接进行的。

第四、关于业务模型转化系统模型，因没有相应的领域专家。使得系统建模工作进展相当困难。大部分模型的搭建。放到了具体的实现中。

以下便是我分析的项目失败的原因。希望能从中找到解决的方法。 ]]> http://15465259.qzone.qq.com/blog/7#comment 512 Sun, 10 Dec 2006 05:34:42 GMT http://15465259.qzone.qq.com/blog/7 http://15465259.qzone.qq.com/blog/6 主要表现：
1、无项目经理，对项目进度无法进行跟踪和决策问题。
2、开发中表现各执己见，相对沟通较少，开发中问题很难或无法统一。
3、前期的可行性分析不充分。对于工具的选择有些疏忽。
4、无法提高开发人员的信心、积极性，使得开发效率低。

2、缺少技术
主要表现：
1、开发中部分技术细节问题无法得到及时的解决。
2、开发中关于DB2的问题处于摸索状态。没有技术专家进行指导。
3、开发工具的不熟悉。开发人员仅仅按照开发平台模版进行机械式的开发。
4、开发平台的不完善，使得部分开发人员在遇到特殊问题的时候无法独立解决。
5、组件技术、三层平台的不理解，造成组件开发的进度缓慢，培训时间相应变长。
]]> http://15465259.qzone.qq.com/blog/6#comment 512 Sun, 10 Dec 2006 05:33:49 GMT http://15465259.qzone.qq.com/blog/6 http://15465259.qzone.qq.com/blog/5 1、项目初期未能对整个开发团队情况进行了解。导致搭建的系统架构无法被开发团队完全理解，以至于影响了后期的开发进度情况。
2、组件平台搭建过程中没有充分考虑到同客户端的一体化。造成客户端开发平台无法高效的，稳定地进行开发工作。
3、前期对于业务掌握不够深入。导致平台的通用性，灵活性不够。
4、针对当前开发团队对于项目的难度估计不够、产生了轻敌的心理，导致项目时间一拖再拖。同时给开发增加了心理负担。
5、开发中。存在了不自信和免责任的心理。使自己在推动开发团队前进的过程中效力减小。部分工作完成不尽如人意。
6、和领导沟通不够。没有充分把自己的想法告诉领导。导致领导处于迷茫的、无计划性的项目管理中。
7、过分在技术上下力气，而忽略了项目中的管理部分。使得项目进展缓慢。 ]]> http://15465259.qzone.qq.com/blog/5#comment 512 Sun, 10 Dec 2006 05:33:02 GMT http://15465259.qzone.qq.com/blog/5