主动性
    工作是大家合作的，但是最终需要每个人去完成。想不想做好和能不能做好不是一个概念。除去天赋的因素，能够做好我们的工作，就需要对方向性有所把握，对技术执著不放弃，对我们要做的产品抱有坦诚的责任心。这个方面很难说的明白，但这个点却是区分人和人层次的最重要因素。

基本观念：
    我们研发的这套系统，注意，系统！系统不指cgi，也不指cgi+脚本，也不是内核+文件系统，系统是包括我们的设备和设备应用的网络环境在内的统一整体。任何人都没有能力包揽一切，但是所有的人必须建立这样的观念，那就是：我所做的事情，都是在这个整体环境里产生巨大影响的事情。所以，思考和解决问题的出发点，都是整体性至上！

知识结构：
    计算机体系结构，网络协议栈，linux系统各个方面。还有一些方法上的东西，比如，快速获取有益信息的能力，使用互联网的能力，逻辑思维能力等。迅速定位问题，知识面。

第二部分 我们工作的价值链体现
价值链条，把创造价值的点串起来的金链条。网络设备，几个点而已：

功能：
    给人用的东西。试想，别人做了这么个东西给我用，我非凿死他！如果不觉得脸红，我觉得，要么没有进取心，要么就是目光太短浅。这样的人，太不幸了。功能除了上网之外，包括我们的产品呈现出来的方方面面，包括web界面等等。

安全：
    这是个基础。假如是网关，那我们给人家做的网络上的防盗门，虽然不是专门的防火墙，更何况专门的安全设备？这个基础，对我们各位的要求非常高，小偷总是对大门和周边环境很了解，可是我们造门的人呢，却都躲在门里面。我们防不了多米尼克，但是至少要在某个程度上达到安全性要求。

稳定：
    这是体现产品品质和技术实力的地方。这不是cgi写出来，是靠千百次的调试和不间断的测试累积出来的。稳定性体现在系统的里里外外，稳定的硬件架构，稳定的软件系统，稳定的结合。现阶段，我所理解的稳定性，是依靠代码的优化磨合体现出来的。测试，调优，再测试...这是永恒的主题！

性能：
    这是产品的综合实力的最佳体现点。可惜，我们的水平做不了全部的事情。就好比有的人总想把windows注册表清理得一尘不染一样，对性能的追求，就是要让数据包的转发速率一步步的提高，永不止步，直到极限！不必抱怨我们没有smartbit和ixia，如果你看得懂每一行系统代码，会有人把设备送给你的。仍然是态度，做不做得到另说，想不想做是另外的问题。想做，我们一起来。

产品：
    这个问题不是领导的思路可以决定的，这是行业特点决定的。产品，完备的特性是不可或缺的，产品不是让用户三天两头大电话来抱怨的，不是让技术服务的人天天疲于奔命的。这要求我们真正站在用户的角度，想想他们要得究竟是什么，怎么样做他们才会满意；这还需要我们冲在第一线，亲手调调各种各样的网络设备，交换机、别人的路由器、服务器以及所以我们蒙在屋里永远见不到的东西。没有切身的经验，绝对没有优秀的产品。我们现有的几个人，水平远不及从前那拨人，但是我们的系统却比从前强很多，其中很重要的原因就是我们大多数人都有实践的经验。

第三部分 具体一点
前面很笼统，那我们就明确一下几个方面：

模糊的需求：
    要求做功能，比如vpn，默认的不是能拨上号就行了。到底有能支持多少并发连接，有没有拨号日志，有没有实时查询？产品做完了，怎么样升级？是我们去现场，还是通过网络？还是通过串口？还是不升级？想啊！这里没有人能告诉你我们到底要干什么，只能摸着石头往前走，还不能干不好，很难，但就是这样。
界面设计的合理化：
    写shell似乎是新生的必修课了，希望这别葬送了你们的前程。既然是web，既然要开发web，而且还是交互式的，既然我们要做，我们就要成为web开发某一方面的专家！将来，会有两三个人是web架构的专家，管它是java还是Ajax呢。
内核和系统优化：
    说白了就是netfilter优化和协议栈调优，磁盘优化，安全优化等等，就是优化，不断地优化！
协议分析：
    我们要控制网络，就要控制通讯的规则。三层以上一概包括，掌握了协议，才好意思说是搞网络的吧？
内容管理：
    作了这么多东西，要有条理、高效的组织起来，让所有重复、繁琐的工作自动化。

这是我的同学写的一篇，同学的文笔一直不错，看一下不错，混沌社会中的呐喊，尖锐而又执著,拿过来重重门面

管程序员就象是养蜂人管蜜蜂一样。养蜂人怎么管的呢？养蜂人其实并不能和蜜蜂沟通，谁会说“蜂语”啊。但他们可以把蜜蜂放在一个舒适的蜂房里，这样他们自动就会采蜜了，你顺手就可以拿走蜂蜜。：）
对程序员是类似的，把他们弄到一个舒服的环境里：工资比他们想要的高，以至于不会用了（当然，比你的预算还是要便宜）；这些蜜蜂会嘤嘤嗡嗡自己形成社会，程序员会自己评价自己，就象沉迷在打游戏里的家伙一样，谁的话都听不进去，就只愿意写好的软件 - 这和艺术家和战士一样。
软件公司怎么失控的和完蛋的？通常是来了一个有个性的管理人员，这老兄一看，这帮程序员怎么这么 …… 不顺眼啊？脏兮兮，乱糟糟，不配合，他们看起来是多无趣的一群人啊！最糟糕的是，他们还笑话你！于是对他们进行管理 …… 这下规范了，但是，程序员们被伤害了，他们被要求要参加会议，做计划，写报告，严格按照流程，千万千万不要去动别人的代码！程序员觉得自己就象过起了外星人的生活 …… 于是，最好的程序员走了，有的开始怠工，甚至破坏 …… 蜂房毁了。管理者舒服了，因为好像事情开始受控了，大家开始打领带了；但是 Bug 开始成堆出现，市场丢失，最后，关门大吉。

英文原文：
Software - How Software Companies Die
By Orson Scott Card
The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it.
BEEKEEPING
Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their parents' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Geez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.
OUT OF CONTROL
Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.
SMOKED OUT
The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1152937

2. 在学习的过程中，最好能够了解Java的底层机制，而不仅仅停留在表层，不是抄书上的例子运行出结果就可以。要注意；即便对一个简单的例子也要耐心去琢磨，调试，改动。

3. 在学习的过程中一定要动手做，写代码，而不是抱一本书看看就行了。很多东西和体会必须自己动手才能属于自己，最好能参与一些实际的项目。

4. 在学习到一定阶段后，你开始希望用学过的东西做些什么。这时的你应该开始学习一些更多，更复杂的知识，比如J2EE平台的构建，EJB的开发等。对于这一部分，我建议最好找一本较薄的书先了解一个大概，心里有个总体的认识，和框架，同时提供很多实际的例子来加深对J2EE的了解。

我觉得结果固然重要，但是过程更值得珍惜！

一段感情是为了什么？ ——  为了补上人生的一部分！

人生是为了什么？ —— 为了留下一样东西！——快乐！

快乐的人生，才是美好的人生！快乐的爱情，才是美好的爱情！

未完，待继……

转自：http://www.anyper.com/lihuileyou/archive/2006/01/07/369.aspx

　　随着前一段徐克《七剑》之热播，网上有很多针对世界足坛、NBA、超女的七剑总结帖。
　　我也续上一下，针对我们j2ee的常用工具及framework,当然是open source的.这些工具都是我们开发的利器。

　　莫问：隐为群龙之首，背负前尘往事，是表示内涵和救赎的一把剑。
　　自然非IBM所出的Eclipse是也。

　　天瀑：忽攻忽守，用剑者必须很专一, 一把表示纪律的剑。
　　自然是cvs。当项目源码丢失得无影无踪，或粗心的同事commit发生冲突时我们就会明白协同开发中纪律的重要性。

　　日月：代表调协共存。Ant，项目的构建不能依赖于IDE的特殊格式，ant提供给我们一个融合的方式。此剑为子母剑，ant也有很多的task辅助。

　　青干：防守的极至,奇钝无比,却可抵挡天下最锋利的武器。junit,自动地、密集地单元测试是防守(重构，防止回归错误）的关键法门。

　　竞星：短身，出剑神速，迅雷不可目睹。是一把死亡拼命牺牲的剑。絮尾有铁珠，攻至极至时反打回来，以克制使用者心中的狂性。
　　Hibernate，理由有两个：一个是本人在应用hibernate初3个月也基本上是狂性大发的(以前是用iBatis)不敢听到关于性能的报告，因为不太会搞cache和调优。一直在犹豫是不是能把po传到view上，还有open session in view。关于单元测试策略也比较乱；第二个理由是，Hibernate的作者这个人好象就比较有性格，见不得其他人批评他，"犯强汉者，虽远必诛"，社区里出名的炮仗!

　　舍神：一把开山辟石的大剑，钝重有力。是一把求的剑，代表重生，纯朴，恒心，毅力。
　　在java开源社区，自Spring以降，震动诸界，其作者接连出书，在诛伐EJB的罪与罚过程中出力不小。在流行的开源框架组合中，Spring往往处于中心地位。 我们注意到，韩志邦在续集中将成长为天地会总舵主，这是否隐喻了Spring的将来？（偷笑中...)
   
　　由龙：七剑中代表进攻,最高攻击武器。
　　面对struts，我们的心情很复杂，它曾经是开启了我们MVC模式的导师，它曾经是那么锋利，现在仍稳居国内期望学习java框架排行榜首位(csdn统计)，各大java培训机构之必备良方。可惜其架构(性格）被证明存在缺撼，连其作者都投奔JSF去了，正如游龙剑的主人渐坠入暗黑一样，它会在沉沦前绽放出怎样的光芒？让我们拭目以待。
 

　　本文的目的是为应聘项目经理提供帮助。项目管理是升迁的途径，需要运用你过去的开发经验，而且薪水通常高于程序员。应聘项目经理的准备工作包括：复习一些常用的概念、术语，问自己一些在面试中经常问到的问题。

学会运用一个或多个项目管理计划编制工具。通过以上的准备，将为你应聘这个职位增加信心。

　　想好你要说的内容并准备回答涉及面广泛的问题是成功应聘的重要方面。与应聘技术职位不同的是，项目管理问题的答案往往是主观的。要牢记技术项目的项目经理的职责是组织项目成员通过完成技术任务而达到某种商业目标。该技术任务应该是可应用或维护的，都必须满足客户/用户的要求和期望。

　　本文的目标并不是教授如何进行项目管理。这方面有许多很好的书、杂志和研讨班。本文或本文的参考书目中将列出一些。本文将介绍如何回答有关应聘问题的方法和思路。你可以根据自己的经验，观察其他项目经理，应聘职位的岗位描述对答案进行组织。无论被问到什么问题，无论你如何回答，记住运用一个项目经理最有用、最重要的特性…….常识。
　　一、什么是真正的项目管理

　　任何成功的项目都不可能是某一个人的功劳。一个成功的项目是多个部门的众多人员共同努力的结果。这些人，组成一个项目团队，具有不同技术水平，才能，工作风格和知识。

　　项目团队需要有一个共同目标，共同的前景，并且清楚的知道他们要做的工作。该团队，无论采取何种报告结构，必须能够很好地工作和激励以达到商业目标。

　　项目经理是项目团队的领导。他/她的职责是激励团队以积极的方式完成任务。该职位需要具有技术和人际技能，需要每天关注的内容（顺序如下）如下：

　　业务
　　公司
　　项目
　　团队
　　个人

　　技术和方法的变更

　　项目经理的技能应包括技术技能和管理技能，坚实的技术基础能够在技术方面对团队起指导作用，管理技能有助于沟通和解决问题。管理技能不仅限于技术方面，还包括解决问题的能力，估算能力，编制计划的能力，人际和
沟通能力。

　　你可能已经意识到自己忽视或缺乏某些领域的知识。因此，本文的读者为：

    *
      　　没做过项目经理的人
    *
      　　已经是项目经理，但认为自己的技能已经过时的人

　　二、项目经理是什么

　　项目经理角色

　　项目管理是估算、计划编制、重组、整合、评估和修正等过程的不断重复，其中包括管理人员，用户参与和解决问题，直至达到项目的商业目的。

　　管理层需要什么样的人

　　每个经理都在找有能力完成某一商业目标的人。最困难的是要了解他们懂什么和能做是么。比较困难的是，不知道需要多少人。因此，你必须使招聘人员认为你是真诚可靠的。这不仅限于项目范围内，还包括与管理层和客户
保持联系。

　　管理是指无论在有利或不利的环境中都能应对自如。在问题没有被详细表述或没有可选的解决方案时，你必须表现出你的管理才能。如果你让管理层来解决所有的问题，那要你还有什么用，管理层正在做你做的工作呢。

　　人员管理技能

　　了解人们的心理和他们的工作方式是项目经理必需的素质之一。每个人都不同。通过了解你的和别人的工作方式，可以缓解压力，便于沟通。

　　IBM多年来的口号是“尊重每一个人”。这具体表现为了解你日常工作中接触的人。要做到这点，你必须了解你自己并且知道你是如何激励别人或对别人施加压力的。

　　阅读迈尔斯-布里格斯（Myers-Briggs）人格类型分析方面的书籍是一个很好的开端。Katherine Briggs和她女儿Isabel Briggs-Myers制作的问卷（MBTI迈尔斯-布
里格斯人格类型定向）用于帮助人们发现他们的个人风格及对团队产生的影响。该问卷是在Carl Jung的“心理类型”基础上发展而来的。此类书在书店有关自我提升和心理学的分类中均能找到。

　　你应该理解个人工作风格，并且牢记这些实践经验。以下所列的项目应该成为与人相处的第二种本能。也是每个想成功的项目经理必备的常识：

　　尊重每一个雇员（供应商）
　　虚心倾听
　　做出见识广博的决策
　　不要当众批评别人
　　了解自己的实力和做事的先后顺序
　　真诚地听取团队成员的意见和建议
　　对目标和交付产品有清楚的了解
　　在IT团队中提倡合作和信息共享
　　了解每个人的做事风格及他们的优缺点
　　表扬应以团队成员喜欢的方式，真诚地表达
　　将负面影响视为成长的机会
　　以积极的方式提供指导

　　你不能管理你无法控制的东西

　　如前所述，项目管理是执行一系列可重复的任务以完成某个商业目标。为了完成任务，你必须建立控制体系。因此，应对下列方面的问题有所准备：

　　度量方法：度量方法如果没有管理好或运用好，会产生负面影响。度量方法可以作为计划编制的“输入”，可以在项目进展过程中和结束时进行统计，为下一个项目或项目的下一个阶段提供参考。用度量方法来评估员工的绩效是不恰当的。

　　项目计划：通过制定项目计划能够得到正在执行的任务的关键检查点。这些检查点是达到商业目标的路标。要记住项目计划不仅只对新的开发项目有用。他们在支持和维护中同样重要。许多项目经理都犯同样的错误，他们编制一个十分出色的计划，但从不付诸实施。事实上，他们很少按计划进行工作。

　　预算：估算和编制计划的同时要做预算。许多项目经理要制作和管理他们自己的预算。如果你能使实际工作进展和计划一致，那么你的工作就会变得比较简单。大多项目管理工具都具有使费用（按小时，天，或年计）与某个资源相关。许多公司的财务部门认为的资源费用包括企业一般管理费用。另外一些公司可能根据项目名称或用户，管理方式，员工和顾问分别计算。（对于顾问，还要考虑他们的加班费）设备费用也要单独考虑。记住还要考虑运行项目应用所需的软件工具和硬件。（例如销售部门的彩色打印机）

　　员工工作计划：人是任何项目中有价值的。一个人可以促进项目成功或项目进展顺利，也可能对项目产生破坏。员工工作计划能对员工的成长起到建设性和实际作用。大多组织有自己的格式。但无论形式如何，下列事项必须包括：职责明确；客观地评价员工的优缺点；为员工提供参与制定其发展方向和对其进行评估的机会。

项目管理的奖励/压力

　　项目经理的角色是一柄双刃剑。这个职位要承担一定的压力，也会得到相应的奖励。一旦你成为项目经理，就必须对这两方面做好准备。

　　成功地完成一个系统，每个人都会得到奖励。能够帮助员工开发他们的潜能是项目经理特有的回报。在任何任务中，人都是最重要的元素。通过运用自己的管理技能造就了一个充满活力的团队，是一件值得骄傲的事。

　　人员同样是最大的压力。人毕竟会受到那些不受你控制的事物的影响。团队成员的家庭困难，彼此间的个性冲突都需要项目经理来处理。

　　任何有关应用或团队成员的事情首先要找的就是项目经理。上层领导和用户认为你是对项目拖延、需求遗漏、系统中的bug和不正确等唯一的负责人。

　　三、准备面试的方法

　　书、杂志、组织和研讨会

　　本文的参考目录中列出了许多能得到有效的管理实践信息的地方。去寻找管理方面的书籍，包括技术管理和商业管理两个方面。阅读管理大师，例如：Peter Drucker，C. A. Gallagher和A.Maslow写的书和文章。他们提供了在任何领域都使用的管理知识。信息管理大师例如：Tom DeMarco, M. Page-Jones, Ed Yourdon, L. L. Constantine等等提供了许多条理清楚的、经过实践检验的方法。

　　如果你要同用户一起工作，要阅读一本有关领域的专业书籍。了解业务比了解技术环境更重要。事实上，让用户参加面试过程越来越流行。要准备得更充分，可以买一本《哈佛商业评论》（Harvard Business Review）这是一本很好的杂志，适用于商业读者同样也适用于IT管理。许多IT杂志例如《CIO杂志》及在参考书目中列出的书目中都有有关项目管理和人员管理方面的文章。这些杂志中还包括概括或详细的技术性文章。

　　可以和美国管理协会（AMA）和其他商业组织取得联系，获取管理信息。值得一提的是，卡奈基梅隆大学的软件工程研究所（SEI）在90年代提出的管理软件过程，最新标准版本为SEI9000。

　　许多技术研讨会，例如数字咨询和技术转换研究所（Digital Consulting and Technology Transfer Institute）有许多不同领域的项目管理和技术研讨会。另一种
途径是通过你所在的组织。他们也许会提供有关授权、谈判和倾听技巧等的课程，所有这些都有助于你准备项目管理。

　　你应该了解的软件

　　掌握一种项目管理工具。例如微软的Project和Applied Business Technology/Project Workbench。所有这些工具都有许多有效的项目管理方法和术语字典。

　　除了上述提到的工具外，还有一个越来越流行的工具可以针对不同技术环境中的项目在计划编制、费用估算和管理方法上提供帮助。这个工具就是LBMS/Process Engineer，具有CASE界面的工具。

　　如果你使用过此类工具，把这些内容列在你的简历中。当然，不仅要掌握工具，你还必须具有坚实的基础知识和项目管理方法。

　　一个项目经理必须足智多谋。通过email进行通信已经取代了电话和邮寄备忘录。许多公司有自己的系统，还有许多公司使用Lotus Notes。无论是用何种产品，必须具有如下性能：

    *
      　　能够与处于不同地理位置的人取得联系
    *
      　　能够有效地通知团队（包括供应商）范围，进度的变更
    *
      　　能很快地解决小问题
    *
      　　要记住人们工作方式的差别，性格内向的人更愿意通过email沟通。这样他们可以有时间思考问题的答案而不是在会议上立刻做出答案。

　　作为一个项目经理，你可能会作报告（report）和介绍(presentation)。因此，需要掌握字处理软件和图形软件。这些软件在市场上都可以买到。在你的简历上列出你会使用的此类软件。

　　寻找思想

　　任何行业都有好的项目经理和差的项目经理。你可以从两种项目经理身上得到启示（什么是应该做的而什么是应该避免的）。如有可能，问一些优秀的项目经理他们是如何做的。如果你对你的职业发展道路还不太清楚，你可以拿一篇刚刚读过的有关文章，问问这些项目经理对此文的观点。

　　一个成功的项目经理的标志有拥有一支气氛融洽的积极的团队，上层领导的信任和用户的尊重。一致的行动是另一个标志，它是衡量领导能力的基础。优秀的项目经理应该了解每个雇员的长处和短处。他们认为失败并不是缺点，而是一次学习机会。

　　项目经理必须建立一套专业标准。但按照一套完美的例子来进行管理却是一个失败的项目经理。这虽然说明他们的多才多艺，但更体现了他们在授权和沟通方面的能力不足。使原来想积极工作的员工变得消极的做法可以毁了项目经理。你在技术方面的能力应该用于指导和培训员工。如果你参与编程或设计，你不是在开发你的团队，也不是在做项目经理。

　　项目计划技术

　　以下是在面试中通常会提到的有关项目计划编制的术语和图表。大多项目计划编制工具都会使用到一些或全部术语和功能。你应该复习一下有用的一个或多个项目管理工具，这有助于你进一步熟悉常用的技术和功能。

　　图表类型：

　　甘特图：用图形，特别是条形图，描述项目进度的图表。每一个条形符号代表不同的意义。例如：关键任务的条形符号及/或颜色可能与非关键任务的不同。概要任务（活动或阶段）的符号可能于其他任务不同。

　　Pert图：用流程图来表示所有任务的现行依赖关系。PERT的意思是计划评价与审查技术，是一种网络图。

　　任务列表：文本/纵向地列出项目计划。通常至少应包括以下栏目：任务编号，任务名称，开始日期，结束日期，持续时间和工作效率。

　　工作分解结构：项目任务和/或活动的结构图。

　　关键路径：是贯穿整个项目的一条路径，表明在限定的时间成功完成项目涉及的各任务间的依赖关系。调整关键路径上任务的时间进度将会影响整个项目的交付时间。关键路径方法（CRM）图是一种网络图，用于项目的进
度控制和协调项目的活动和事件。

　　可交付成果：证明一个或多个任务完成的有形事物。例如：逻辑数据模型。

　　依赖关系：任务间的联系会影响一个或多个任务的开始时间。例如：在没有弄清需求前，不能开始编程。

　　JAD/简化方法：联合应用程序设计(简化方法是90年代的术语)。一套面向结果的,大脑风暴式的,有一个共同的商业目的信息集合/分享会议。该方法是 IBM公司在1970年开发的，由固定的，结构化的过程组成，并在一个有经验的实施者的领导下进行。简化方法去掉了一些结构,然而,仍要求所有各方都必须参加所有的会议和一个有建模技术的记录员作记录。参加者们包括项目团队,管理(与用户)和行政官员。为会议的成功，每个人必须理解和同意目的并且尽快解决他们的任务。

　　延迟：是任务的结束时间和与其相关的任务的开始时间之间的延迟时间。这允许任务结束时间和开始时间的重叠和拉长。

　　方法论：一种明确的、有组织的、可重复的、结构化的方法/技术，以完成一个通用的目的。这些技术或指南定义步骤，任务，角色，目的和可交付成果，这些是任何系统的成功的实现所必须的。

　　衡量标准：一个一致并且可重复的测量一个项目的大小和复杂性的方法。标准准备在整个项目生命期中使用许多方法中的一个。今天公司使用的流行方法是：

　　a) 功能点（Allan Abrecht）
　　b) 重要事件 (Tom DeMarco)
　　c) 加权平均
　　d) 代码行

　　里程碑：在项目生命期的一个重要的事件的结束。通常一个里程碑是在关键的路径上的一项活动。它不必是一个有形的可交付产品例如一个逻辑数据模型，但可以是用户对工作成果的肯定。

　　阶段/活动/摘要标题：概要级的概念。不是所有的项目管理工具都强调特定的阶段和摘要一级的格式，然而许多标准的开发方法用这些术语进行工作分解。

　　RAD：快速的应用开发(如果不正确地使用会有破坏作用)。通过应用程序生成器，建模和快速原型工具的使用加快开发工作的一条途径。最大的改进是在整个开发生命周期中加入快速原型。这在编码前了解清楚用户需求提供优秀的工具。

　　资源限制：一个基于可得到的资源的数量，每个资源的技巧的水平，资源工作时间表而开发的计划和时间表。

　　范围变更：对原先设计要求的功能增加而没有对人员，时间或费用的影响进行评估。范围变更可能是一个商业用户或一个热心的程序员提出的。两者影响系统的交付并且不能被估计，分析，或记录。

面试中的表达的要点(就算问题没被问)

　　如果你没有管理经验

　　对于那些从未正式管理过一个项目的，可能是非正式地管理过的人。在那些情况中，当强调他们的技术背景优势的同时需要明确说明他们没认识到他们已掌握的那些技巧。你可以提及你是怎么不得不在没有授权的情况下领导一个大型的开发团队进行工作的。需要强调的是没有一个稳固的技术的基础,你的工程任务和估计的决定可能被过分简单化。当你是项目的领导人，你需要提供技术的连贯避免团队超负荷工作。

　　如果你的技术技巧在未来的技术的环境中是落伍或不同的

　　你不需要理解技术环境的内部是如何工作的，但是你应该理解一般的概念和特征决定环境的能力和弱点。许多项目管理技巧是超出技术范围的。因此,如果你的技术技巧是落伍的，你仍然能强调你在技术上能负独立责任。提
及你管理的应用类型和及其商业作用。提及团队是如何有效地完成目标的。强调你的管理哲学。提到上级，与你地位同等的人，你的用户和部下是如何评价你的管理能力的，记住提起任何你掌握的商务领域知识。在面试时应该将
你对你的技能落后的恐惧抛在一旁。一旦你拥有这个工作，你将能向公司内的专家询问。在所有组织中都有各方面专家的非正式的机构。你可以到处打听一下，把他们找出来。
　　问面试官的问题：

　　即使你通过面试，得到了这个职位，你还需要信息进行估价，这时是你的好机会。如果这将是项目经理的第一个工作任务，这尤其是关键。你需要明白你的工作环境。因此，你可以问下列问题：

　　1. 公司优先权是什么？
　　2. 本项目的执行资助者是谁？
　　3. 公司使用的开发原理体系是什么？
　　4. 本项目最后期限是什么？
　　5. 有量度项目成功的方法吗？
　　6. 你的新经理将怎样保持项目信息灵通？
　　7. 你的新经理管理哲学和风格是什么？
　　8. 项目上的人们的技能水平是什么？
　　9. 你将管理的项目的范围被充分地定义吗？
　　10. 技术环境已经选好了吗？
　　面试中通常会问到的问题

　　以下是典型的项目管理面试中通常会问到的问题（期望的回答）：很多的问题的答案是主观的，面试官想知道你的观点是否和他们的及公司一致。问题的构成如下：
　　1. 项目管理软件工具知识，
　　2. 编制项目计划的技术，
　　3. 人员管理技能
　　4. 沟通技能
　　5. 原理体系知识（标准开发生命周期和项目管理）。

　　项目管理软件工具知识

　　问题1：工期和工作量之间的差异是什么？
　　答案1：工期是商业/日历上的天数，与人数和工作量无关。工作量是与日历天数无关的人的工作。例如：
　　一天的工作量对于一个一只花50%在时间在上面的人来说，他的工期就是两天。如果两个人全职工作，工期是1天，而工作量是两个工作日。
　　问题2：怎样和为什么要在编制项目计划时考虑依赖关系？
　　答案2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型
必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测试没有影响。
　　项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。
　　问题3：你怎样将人的工作步调与计划结合？
　　答案3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。
　　问题4：你怎样将培训，假日和个人教育时间表结合起来？
　　答案4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。
　　问题5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？
　　答案5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。
　　问题6：实况报告对计划的作用以及实况与最初预计的比较有何价值？
　　答案6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径的变化或时间表的调整。这些报告对已实现工作评价和作为
在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项目的影响记录下来。

　　做项目计划的技能

　　问题7：你为什么制定项目计划？
　　答案7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的“一览表”协助对任
何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。
　　问题8：你将怎样着手做项目的计划？
　　答案8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解
。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对
项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。
　　问题9：你将怎样着手制定项目计划？
　　答案9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。把资源角色或资源名字加到每个任务上。应用度量结果确定
事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。
　　问题10：怎样确定人员需求？
　　答案10：不考虑资源限制进行计划开发。在任务旁边加上诸如数据模型制作者，业务分析员和用户等角色。再加上能将任务重叠起来的补充性的资源。在计划中要考虑开发团队包括支持团队和用户代表失去一个或多个资源
的情况，要在每个任务上增加15%的余量。要使项目小组的组成容易理解，要有角色所必备的技术水平的说明。
　　问题11：给项目加上测量标准有什么价值？
　　答案11：如果使用得当，测量标准是一个有价值的工具。它们提供测定开发系统的复杂性和工作量的方法。度量结果为制定项目计划提供了信息输入资源，并且是确定发展方向的有价值的历史信息。软件测量标准将有助于
开发更好的软件。不过，最好有3年的历史资料。
　　问题12：你怎样在计划中运用新技术？
　　答案12：在增加培训任务的同时要扩大工作量，缩小每个工作单元。在评价新技术在开发中的影响的过程中加上额外的原型和检查点（里程碑）。

?

人员管理技能

　　问题13：你作为项目经理要做的第一件事情是什么？
　　答案13：除了注意公司的发展方向并从中发现自己的发展道路外，在头脑中要建立项目经理所关注事物（商务，公司，项目，团队，个人，技术和方法论的变化）的优先顺序。因此，和部门经理开会确定优先顺序，安排用
户和职员会议，得到全部成员的状态报告和评价。重要的是能尽快处理业务，项目和个人有关的事情。
　　问题14：当你的职员减少了30 %你将怎样着手完成公司的项目？
　　答案14：首先，确定和区分项目的优先次序，哪些项目是必须在今后的18个月内完成的。把绝对的最小的总人数与每个项目联系起来。向管理者和用户说明对进度表的影响。因为两者都也许不愿意接受进度表的变化，因
此或许可以给你一些例外。
　　减掉顾问比去掉一个雇员要好。每个项目的顾问也许可以用雇员代替。坚持运用学习曲线理论并逐步减少顾问人数。可以把一些顾问的工作从一周降低到一星期中的2或3天以应付人员削减。
　　如果公司有提前退休的一览子法案，赶紧寻找一些有资历的、适用的雇员。牢牢记住失去“老资格的人”你也许就失去了有价值的知识。尽可能将一个快退休的人和新手组合在一起。
　　以满足业务目标为前提，确定剩下员工的重要性以及他们在每个项目中的重要性。使新手和经验丰富人员的比例适当。两者都是确保项目和公司不断成功的财富。
　　问题15：你的团队主要是由新手组成的，并且进度已经落后。你将做什么？
　　答案15：需要记住一个项目很少因为在截止时间内没有完成而被取消的。项目被取消，主要是诸如缺少资金，用户支持或不能满足的业务目标。
　　因此，要做的第一件事是培训，无论在室内还是室外，在课堂或通过录像带。另一种附加方法就是让资深的雇员或高级顾问充当教师。
　　举办针对个人评估和辅导的会议。帮助每个员工准确评价他们各自的优点和缺点。同时明确任务，将所有必须遵守的标准或准则阐述清楚。为每个员工提供从成功项目中得到的模板作为指南，还要允许他们发挥自己的才能。
如果需要，和他们一起工作。对任何问题或完成的任务做出迅速的反馈。
　　对于较大的任务，看看他们的计划，有助于确定他们是否了解任务的范围和目标，以便了解他们是否能完成任务。倾听员工的观点，也许他们会有完成任务的正确的方法和途径。然而也要防止雇员陷入挫折和士气低落的困境
中。
　　问题16：你将怎样和与你竞争相同职位的员工相处？
　　答案16：这是经常发生的不愉快情况。雇员总是认为他们能胜任某个职位而管理层还没有意识到这一点。因此，要进行如下调查：
　　发现员工的管理能力
　　阅读评估和状态报告
　　当雇员变得不合作时试图发现一些变通的方法并且针对这种状况进行一些个人谈话，谈话内容包括：
　　弄清楚状况；与员工一起分析他/她具有的能使他/她得到提升的资历；强调在初期协作的必要性和管理层是如何高度重视合作关系的。
　　问题17：在决策和工作风格方面你会给你手下多大的自由？
　　答案17：自由的大小取决于每个人的技能和专业水平。一个好的经理是“面向结果的”并且能创造一个能使团队广泛交流的环境。无论如何，每个员工每周需提交项目和商业目标有关的状态报告并且经理要进行审查。这有
利于加强组织建设并使每个员工致力于他们自己应完成的工作。
　　问题18：如何对待即将退休的员工？
　　答案18：即将退休的员工能提供大量的信息。一个人在把所有业务知识和关系网拒之门外时必须三思而后行。因此，要利用这些人的能力：他们在某些特殊技能方面可以作为新手的老师。明确主要的工作利益，要使项目能
充分利用这些技能，可以利用他们从非正规途径得到的必要支持（不用通过正规的，官僚的途径完成工作）
　　问题19：对一个一贯迟到的员工你会怎么办？
　　答案19：好的经理是通过结果与所花时间来评价一个员工的。然而，还需要了解迟到会在公司和团队中造成什么影响。一个人经常迟到人们会感到领导在徇私并且会影响团队的士气。这个人也许可以按期完成自己的任务但
可能会影响到别人的进度。职业特性包括可靠性。如果别人的工作进度取决于他们的工作进度，那么，他们的进度对于整个团队就很重要。
　　首先判断这些员工的模式。换句话说，是偶尔还是一贯如此。其次，明确公司有关考勤方面的政策，确定迟到及其相关处理方法。要了解该员工的工作是否与进度相符并了解与他一起工作的人对他迟到的反应。最后，必须与
他们进行客观的谈话，谈话的主题包括：
　　公司的规章制度
　　对团队的影响
　　对个人评价的影响
　　强调时间进度
　　达成谅解
　　问题20：在费用削减的情况下，你将怎样鼓舞士气？
　　答案20：钱不是仅有的激励因素。人们需要了解他们是否对项目有积极的贡献。因此，要强调拥有的自豪感并且举行业务会议，在会上让用户谈谈他们对项目组的良好印象。同时，让用户对他们的功能和业务提出一个概括
。培训是一个激励因素。因此，状况会议可以作为一个非正式的培训课程。不定期地举办有关新技术的内部研讨会。如果培训课程费用太昂贵，可以租赁技术录像带。订阅杂志，有许多技术杂志是免费的。必须记住的是，忽视培
训将使团队的精神低落。这样会影响产品的质量和数量。
　　问题21：你如何雇人？
　　答案21：首先做一个工作所需技能的描述。如果你不了解现在的需求就很难雇到合适的人。接下来要了解团队成员的个性。列出团队现在缺乏的技能或工作风格。与人力资源部门讨论所有这些情况，包括调动现有员工。当
候选人到来，针对现有工作进行面试，同时还要了解他是否具有新岗位所需的技能。
　　问题22：你将如何解决团队中的个人冲突？
　　答案22：辨别出人的不同个性。分别向员工表述每种风格的价值。当与冲突双方讨论试图分析申诉或冲突的原因时应持有客观的态度。
　　问题23：你将如何监控/管理顾问？
　　答案23：顾问也是人，也需要得到尊重。他们还需要明确的目标和任务。坚持做工作周报，将工作时间和工作完成情况联系起来。
　　问题24：你将如何管理外援？
　　答案24：和管理顾问的方法相同。不过，他们可能有一个经理来负责外包合作。首先要和这个经理一起组织日常会议。坚持做工作周报和可交付产品的拷贝。
　　问题25：你将如何同一个似乎总是不能按时完成工作的员工一起工作？
　　答案25：直到找到问题的原因时，问题才能解决。原因不一定是分析问题或解决问题的能力差。可能是一个管理方面的问题。该员工可能没有得到适当的培训，他的工作可能超出了他的能力范围。另外一种可能是这个人有
太多的事情要做而且这些事情都是最重要的或者他不清楚交付日期。如果不是上述原因，要注意观察，找出原因所在。例如当所有人遇到问题时，都会找这个人。那么，这个人的工作经常会被无数次地打断。

检查:
　　典型活动：交付后的三到六个月对目标成本，开发工作，可见/不可见收益进行检查。
　　典型交付：实施总结报告。
　　问题34：制作原型应该在项目生命周期的那个阶段？
　　答案34：贯穿整个项目。眼见为实。因为它是验证功能，业务规则，用户需求数据和测试的一个好工具。值得注意的是，原型不会成为粗制滥造的产品。原型需要较好地维护。原型应能在过程和数据不完全的情况下，显示
各个窗口和窗口间的导航关系。
　　问题35：在项目生命周期中，基于客户端/服务器端开发与基于大型机开发的区别是什么？
　　答案35：基于客户端/服务器端开发的项目需要额外的任务编制各部分的计划。各部分计划中必须包括对事件，数据和网络位置的检查。必须根据用户的要求决定服务器/客户端的分布。在服务器/客户端环境中，要运用
外观建模技术和制作图形界面的原型相结合和方法。
　　问题36：在一个维护项目中如何管理和保证质量？
　　答案36：维护本身就含有负面意义。许多公司认为维护工作是不好的，第二位的。费钱的，并且是对现有应用的不断修改。必须懂得维护也有它的生命周期。因此，应建立一个围绕维护活动的控制和质量工作的计划。新的
开发计划包括交付产品和每个任务分配的时间。项目计划应考虑到需求变更的情况。这样可以使项目经理和用户看到变更对项目进度的影响。
　　维护阶段/活动有：
　　变更的确定（是否会造成产品问题，是否增加了新的功能，或技术平台的变更）
　　正式记录变更，
　　变更确认并初步估计变更的大小，
　　对现有变更进行优先级排序，
　　变更分析，
　　对变更进行编程，
　　对变更和变更对系统产生的影响进行系统/回归测试，
　　用户确认变更，
　　产品递交，
　　生产。
　　问题37：面向对象的开发与传统的开发方法在管理技术上有什么不同？
　　答案37：面向对象的项目团队人员较少，团队成员不需要有太多创意。重要的是技术和个人的角色。每个成员需在项目的不同阶段承担不同的角色。因此，每个成员必须了解他们自己的优缺点。围绕一个或多个人员的角色
有：
　　设计师（系统的整体结构）
　　抽象工程师（类和类族）
　　应用工程师（完成和组装类和类之间的消息）
　　由于传统的开发方法，个人角色是不能互换的。软件开发是个人的努力的结果。即使是由最优秀的，最聪明的人组成的团队，如果他们不能为共同的目标而工作，那么就是最简单的项目也不能成功完成。
　　问题38：你如何在处理雇员关系，项目管理，文本工作之间分配时间？
　　答案38：人是最宝贵的财富，因此需要花费最多的时间。然而，项目经理必须关注事物的次序应该是：
　　商业目标，
　　公司的目标，
　　项目，
　　团队，
　　个人，
　　技术和方法的变化
　　问题39：什么是PM-CMM?
　　答案39：人员管理能力成熟度模型。PM-CMM和CMM都是卡内基.梅隆大学的软件工程研究所开发的概念模型。PM提供了人力资源管理的组织方法。五个层次是：
　　随意的：人员管理没有连贯性，
　　可重复的：组织在人员管理方面有一些政策方针，
　　明确的：将人员管理与业务特点相结合，
　　可度量的：对人员管理可进行目标量化，
　　优化：有组织地致力于不断地提高人员管理水平。

　　小结

　　一个成功的团队是指由不同技能、才华、工作风格和知识的成员组成的士气高涨的团队。项目经理的职责就是将这些人组成团队并激励他们。本文通过复习一般性的概念、术语和面试中经常会问到的问题，为面试做准备。你
可以根据你有关如何成为一个好的项目经理的知识和经验，对答案进行整理。不管怎么回答，尽量给你所应聘的组织留下印象。应以一种积极的态度面对。应侧重于人员管理，同时还有一个良好的技术背景。应具备应有的常识、
自信、倾听和作决定的能力。

?
沟通技巧

　　问题26：你将怎样使用户参与和了解项目的每个阶段？
　　答案26：贯穿整个项目的原型是得到用户肯定的方法。让用户对有形和无形的利益进行研究，以做出成本效益分析。和用户一起开发测试数据，测试大纲和验收标准。e-mail里程碑状态报告和更新/修改的项目计划
。在项目进行阶段性检查时的同时对可交付产品进行检查。
　　问题27：你将如何发现和解决内部和外部问题？
　　答案27：从所有可能的资源获取实情并客观地记录下来。然后在相关方参与下，尽量自己解决问题。如果这种方法无效，按照组织的管理结构提出问题并参照可能的解决方法。
　　问题28：你将如何得到供应商的一贯支持？
　　答案28：虽然供应商是在管理范围之外的，但也可以将他们包含进来，如果他们：得到尊重；了解业务目标；预先购买；将供应作为计划的输入，这样会对他们产生影响；参与设计，因此，在项目的早期阶段就应该考虑供
应商的管理。确保他们了解业务目标和工作的利益。
　　问题29：如何处理“是否能破除一些规矩”现象？
　　答案29：单纯为了技术而采用某种技术是不能说服用户或领导的。任何人都可能抵制那些会改变现状的变化。然而，如果将技术与商业利润联系起来，用户会支持你的建议。
　　问题30：你如何应对不同的商业用户，如果他：
　　a) 拒绝确认需求
　　b) 经常改变主意
　　c) 不肯花时间
　　d) 坚持不现实的截止日期
　　答案30：无论客户有多难应付，都应该记住正因为他们我们才有工作做。他们是客户。必须以高度的职业精神，完全尊重他们。
　　因为他们不能了解我们的工作正如我们不能完全了解他们的那样，沟通变得比较复杂。因此，我们要花时间作规划并解释其中包含的内容。用户需要感到他们没有浪费时间，正在取得成果，并且他们的意图被很好地理解。制
作原型是一个有用的工具。它提供了一幅用户能理解的、灵活的图画。
　　另外，对工作风格的理解也很重要。拒绝承认或不断地改变想法可能源于对问题缺乏理解，或是对未来的担心。
　　用户往往不愿意花时间与IT人员交谈并认为这样做是浪费时间，因为IT人员过分关注他们自己的任务。应该对过去交付产品的历史进行检查。如果用户来了多次但并未发看到有价值的输出，他们将拒绝花更多的时间。在
这种情况下，你应该做你擅长的商业领域的项目以期得到用户的尊重。
　　召开一个历时一小时（并且要限定在该时间范围内）的需求讨论会来讨论特殊的问题。会议结束时应让用户知道下一步该怎么做（并要取得共识）。用户的观点被记录在“会谈纪要”上。这些会让用户感到他们的意见已被听
取并且允许他们更改错误。
　　一个项目被取消往往是由于没有经济合理地达到用户的业务要求。如果在项目的整个过程中，一直保持与用户的有效沟通，他们将看到他们的要求正在逐步达到。项目很少因为延期而被取消。要注意范围变更。在原有的截止
日期上增加额外的任务，将会产生不现实的截止日期。
　　问题31：在一个不编程，就认为你没在工作的环境中，你如何开展工作？
　　答案31：如果用户认为你了解了他们的业务目标，他们就希望早些开始编程。以一种他们能够理解的形式制作需求文档，提供一种开放的沟通方式，并让他们知道你了解什么，你正在做什么。通过项目计划，状态报告和原
型同样能够表明项目的进展。通过让用户审查需求，原型和状态报告的形式，让用户参与项目。

　　方法论知识

　　问题32：生命周期是什么，它的作用是什么？
　　答案32：一个开发或维护生命周期是描述一个特定项目的开始，中间环节和完成的方法。一个生命周期包含了完成特定目标的所有步骤，任务和/或活动。每个活动可能有一种特定的方法。例如,制作数据模型可能会按照
James Martins建模方法。对象建模可能会采用Ivan Jacobson方法。生命周期通过运用所有方法来完成业务目标。
　　问题33：描述你的项目计划中应包括的阶段、活动和可交付产品。
　　答案33：项目计划中应包括如下阶段（不是以瀑布/线性次序）：
　　项目管理：
　　典型活动：很多人忘记加入诸如开发和维护项目计划，状态会议和报告，评估的资料收集和汇报，制作演示资料和向上级和用户进行演示等诸如此类需要花时间的，内部的项目管理活动。
　　典型交付：项目计划，状态报告，评估报告（例如：有多少个功能点）
　　需求分析：
　　典型活动：范围定义，成本利润初步分析，建议。
　　典型交付：范围文档，物理和逻辑分析，实体关系图，成本利润分析，商业规则申明，任务定义和概要说明。
　　设计：
　　典型活动：建立开发和测试环境，制作逻辑模型，技术系统设计，执行计划。
　　典型交付：逻辑数据模型，事件模型，对象模型，网络模型，物理设计，适合开发环境的规格说明，经过修改的规格说明书，测试计划，流程图。
　　开发：
　　典型活动：编码，单元测试和制作用户文档。
　　典型交付：测试说明书，过程手册，程序。
　　测试：
　　典型活动：软、硬件测试，线性测试，系统测试，集成测试，回归测试和平行测试。
　　典型交付：测试结果，问题报告和跟踪纪录。
　　实施和支持：
　　典型活动：第一阶段成果打包；培训。
　　典型交付：问题报告过程。

    一、谋定而后动，不做半路出家的和尚：

    想创业就要考虑风险，怎样有效的规避创业初期的风险问题呢？中国商界有句俗语：“做熟不做生”，创业者对于自己熟悉行业的运营过程早已深谙不惑，行业风险的巧妙规避应该游刃有余，反之，这创业的第一步没等迈出，就被风险绊倒了。

    二、你有丰富的资源吗？

    资源是一个企业成功的基本因素，其中最重要的几个资源分别为人力资源、资金和公共关系。

    人力资源：人乃万物之灵，只要有企业，有商业活动，就必然有人的存在。人力资源是企业发展壮大的决定性因素，优秀的人（主要的核心人物）完成优秀的工作，一个企业在创业初期，需要优秀的人（更多指的是优秀的管理者）来“指点江山”，而企业在度过创业期之后，从优秀到卓越更需要有优秀的人（管理者）来完成。

    资金：雄厚的资金实力是企业创业、发展、壮大的坚实后盾，其作用如同水、粮食之于人体一样，毋庸质疑，没有资金（自有、融资等），还是不要冲动的好。

    公共关系：中国现有的政治、经济体系决定了大多数企业如果没有良好的公共关系就别想把企业做好（极个别除外），只要你办企业，哪怕开个小商店，工商税务等各种政府职能部门盯着你不放，什么时候“喝”够了你的油水，什么时候算你有好日子过（喝得够吗？）。还有市场竞争不公平、新闻媒体的失实报道等，就是得罪了街头上的小混混你也别想好。中国的公共关系啊，只能用两个字表达--复杂。

    三、创业者，你行吗？

    首先，创业者具备应有的基本商业素质吗？懂得经营管理吗？能有效利用好已有的各种资源吗？

    素质在于教育，只要肯学习，每个人都会有很大的提高。而经营管理则是一门“艺术”，这门“艺术”中，重要的是经营者是否能玩转各种资源，当然，重要的是人力资源。优秀的人可以帮助经营者管理企业、制定商业计划，甚至可以搞融资，可以搞公共关系，经营者只要听报告、做决策就可以“运筹帷幄之中，决胜千里之外”了。比如三国时期的刘备，文有诸葛亮出谋划策，武有关羽、张飞、赵云等攻城略地，岂能不独霸一方？再看今日的阿里巴巴创始人、首席执行官马云，其不懂得技术，但尊重专家和技术人员的意见，所以有今日之成就。

    四、给创业者的几点建议（切忌）：

    1、对员工（特别是初期的追随者）过多不切实际的承诺，将来兑现不了，可能导致严重的人事危机，更甚者可能威胁到企业的生存。

    2、事必亲躬，企业没做起来，人先倒下了。

    3、盲目投资，没有对市场进行详细的研究分析，与赌钱没什么区别（有谁想跟钱过不去可以找笔者）。

    4、不要过于“嚣张”（骄傲），有很多创业者在取得一点成绩之后，便开始“享受”，或者是性情的完全转变，特别是在对待员工的态度问题上，总是摆出一副土皇帝的面孔，对员工是呼之即来，挥之即去，最后的结果--哭都找不到北。


创业不容易啊，但是创业是我们体现自己价值的最短路径，估计也是唯一路径，祝愿
创业者：乘势而上，抓住机遇；站在新起点上，创造新发展;

常来我的博客座座？创业就成功了一半！

经理人要获得更好的职业机会，在职业发展上持续前进，除了需要不断学习来提高相关的知识和技能之外，还需要培养以下七个习惯：

一、充分地认识自我

一个人能否取得事业上的成功，关键在于是否能准确识别并充分发挥自身的优势。

　　同是管理工作，不同领域的管理工作对人有不同的要求。一些管理职位需要有更强的人际影响力，否则将不能带动团队完成目标；而有一些管理工作的性质则对经理人的深度思考和分析能力有着更高的要求，因为他需要更多地充当顾问的角色。因此，要认清自己的才干和优势，在此基础上选择职业方向。

二、树立清晰的职业发展目标

清晰了自身的优势，就要树立明确的职业发展目标。职业发展首先是个人的事，公司只能给予一定的支持和机会。然而，很多中国雇员的习惯是等待公司为其做职业规划，或随机地进行职业选择，这样会使自己走一些弯路或减慢职业发展的速度。

　　在任何一个公司里，管理职位都是有限的，只有有明确职业目标并为此不断努力的人，公司才更愿给予他机会，因为这不仅意味这会有好的工作表现，同时也反映了一个人的事业心和追求成功的态度。

三、主动寻求更大的职责

大部分公司在正式给员工晋升之前会对其能力进行全面的考察，而其中的一个考察方式就是在不变动该员工现有的职位和薪酬的前提下给予其与新职位相关的更多的工作职责。

　　有的人在这种时候过于急躁，向公司提出各种待遇和职位上的要求，这样做的结果是让公司将他排除在人选之外。因此，在职业发展方面切忌过于急躁，必须有充足的耐心，关注工作职责所能够带来的职业发展机会，而非眼前利益。根据自己所确定的职业发展目标主动寻求更大、更多的工作职责，将无疑为自己的职业发展争取到更好的机会。

四、停止抱怨，承担责任

经理人经常抱怨、指责、推卸责任不但使自己失去改进自身的机会，同时也让周边的人，无论是上司还是其他的同事感到失望从而不愿与其合作。这种态度对下属的影响尤其可怕--团队成员会效仿上司相互抱怨指责，而不是去考虑自己怎样改善相关的工作。

　　很显然，一个人在抱怨一个公司的环境和文化氛围阻碍了其发展时，并不意味着他换一家公司就能够获得他所期望的发展--一切取决于他是否能够调整自己的心态和做法。当一个人对周围的人和事横加指责时，他的注意力集中在过去。如果他承担了责任，眼光才会投向未来，才能专注做好计划来达到目标。

五、不可忽略执行力

执行公司战略，带领团队成员达成目标的能力，是公司评估经理人表现的一个主要方面。然而，一些经理人认为执行是低层面的事，他们喜欢提出很多想法却不愿意付诸行动，讲起来头头是道，而行动力不足，到头来没有结果，仍然无法获得公司的认可。如果本职工作都做不好，何谈进一步的职业发展机会？

　　因此，执行力是经理人进一步发展的一个核心能力。目标一旦确定，经理人需要迅速规划并组织有效资源，找出切实可行的方法将计划付诸实施，监控过程，及时发现和解决问题，确保结果的达成。

六、关注并帮助下属成长

经理的主要工作除了带领团�