每个组织都是由各种不同的职位、等级或阶层的排列所组成，每个人都隶属于其中的某个等级。彼得原理是美国学者劳伦斯·彼得在对组织中人员晋升的相关现象研究后，得出一个结论：在各种组织中,雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为向上爬的原理。这种现象在现实生活中无处不在：一名称职的教授被提升为大学校长后，却无法胜任；一个优秀的运动员被提升为主管体育的官员，而无所作为。对一个组织而言，一旦相当部分人员被推到其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。因此，这就要求改变单纯的根据贡献决定晋升的企业员工晋升机制，不能因某人在某个岗位上干得很出色，就推断此人一定能够胜任更高一级的职务。将一名职工晋升到一个无法很好发挥才能的岗位，不仅不是对本人的奖励，反而使其无法很好发挥才能，也给企业带来损失。

2、酒与污水定律

酒与污水定律是指把一匙酒倒进一桶污水，得到的是一桶污水；如果把一匙污水倒进一桶酒，得到的还是一桶污水。在任何组织里，几乎都存在几个难弄的人物，他们存在的目的似乎就是为了把事情搞糟。最糟糕的是，他们像果箱里的烂苹果，如果不及时处理，它会迅速传染，把果箱里其他苹果也弄烂。烂苹果的可怕之处，在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没，而一个无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的，是建立在相互理解、妥协和容忍的基础上的，很容易被侵害、被毒化。破坏者能力非凡的另一个重要原因在于，破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器，一头驴子一秒钟就能毁坏掉。如果一个组织里有这样的一头驴子，即使拥有再多的能工巧匠，也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子，你应该马上把它清除掉，如果你无力这样做，就应该把它拴起来。

3、木桶定律

水桶定律是讲一只水桶能装多少水，这完全取决于它最短的那块木板。这就是说任何一个组织，可能面临的一个共同问题，即构成组织的各个部分往往是优劣不齐的，而劣势部分往往决定整个组织的水平。水桶定律与酒与污水定律不同，后者讨论的是组织中的破坏力量，最短的木板却是组织中有用的一个部分，只不过比其他部分差一些，你不能把它们当成烂苹果扔掉。强弱只是相对而言的，无法消除，问题在于你容忍这种弱点到什么程度，如果严重到成为阻碍工作的瓶颈，你就不得不有所动作。

4、马太效应

《新约·马太福音》中有这样一个故事：一个国王远行前，交给3个仆人每人一锭银子，吩咐道：你们去做生意，等我回来时，再来见我。国王回来时，第一个仆人说：主人，你交给我的一锭银子，我已赚了10锭。于是，国王奖励他10座城邑。第二个仆人报告：主人，你给我的一锭银子，我已赚了5锭。于是，国王奖励他5座城邑。第三仆人报告说：主人，你给我的1锭银子，我一直包在手帕里，怕丢失，一直没有拿出来。于是，国王命令将第三个仆人的1锭银子赏给第一个仆人，说：凡是少的，就连他所有的，也要夺过来。凡是多的，还要给他，叫他多多益善，这就是马太效应，反应当今社会中存在的一个普遍现象，即赢家通吃。对企业经营发展而言，马太效应告诉我们，要想在某一个领域保持优势，就必须在此领域迅速做大。当你成为某个领域的领头羊时，即便投资回报率相同，你也能更轻易地获得比弱小的同行更大的收益。而若没有实力迅速在某个领域做大，就要不停地寻找新的发展领域，才能保证获得较好的回报。

5、零和游戏原理

零和游戏是指一项游戏中，游戏者有输有赢，一方所赢正是另一方所输，游戏的总成绩永远为零，零和游戏原理之所以广受关注，主要是因为人们在社会的方方面面都能发现与零和游戏类似的局面，胜利者的光荣后面往往隐藏着失败者的辛酸和苦涩。 20世纪，人类经历两次世界大战、经济高速增长，科技进步、全球一体化以及日益严重的环境污染，零和游戏观念正逐渐被双赢观念所取代。人们开始认识到利已不一定要建立在损人的基础上。通过有效合作皆大欢喜的结局是可能出现的。但从零和游戏走向双赢，要求各方面要有真诚合作的精神和勇气，在合作中不要小聪明，不要总想占别人的小便宜，要遵守游戏规则，否则双赢的局面就不可能出现，最终吃亏的还是合作者自己。

6、华盛顿合作规律

华盛顿合作规律说的是一个人敷衍了事，两个人互相推诿，三个人则永无成事之日。多少有点类似于我们三个和尚的故事。人与人的合作，不是人力的简单相加，而是要复杂和微妙得多。在这种合作中，假定每个人的能力都为1，那么，10个人的合作结果有时比10大得多，有时，甚至比1还要小。因为人不是静止物，而更像方向各异的能量，相互推动时，自然事半功倍，相互抵触时，则一事无成。我们传统的管理理论中，对合作研究得并不多，最直观的反映就是，目前的大多数管理制度和行为都是致力于减少人力的无谓消耗，而非利用组织提高人的效能。换言之，不妨说管理的主要目的不是让每个人做得更好，而是避免内耗过多。

7、手表定理

手表定理是指一个人有一只表时，可以知道现在是几点钟，当他同时拥有两只表时，却无法确定。两只手表并不能告诉一个人更准确的时间，反而会让看表的人失去对准确时间的信心。手表定理在企业经营管理方面，给我们一种非常直观的启发，就是对同一个人或同一个组织的管理，不能同时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人同时指挥，否则将使这个企业或这个人无所适从。手表定理所指的另一层含义在于，每个人都不能同时选择两种不同的价值观，否则，你的行为将陷于混乱。

8、不值得定律

不值得定律最直观的表述是：不值得做的的事情，就不值得做好。这个定律再简单不过了，重要性却时时被人们忽视遗忘。不值得定律反映人们的一种心理，一个人如果从事的是一份自认为不值得做的事情，往往会保持冷嘲热讽，敷衍了事的态度，不仅成功率低，而且即使成功，也不觉得有多大的成就感。因此，对个人来说，应在多种可供选择的奋斗目标及价值观中挑选一种，然后为之奋斗。选择你所爱的，爱你所选择的，才可能激发我们的斗志，也可以心安理得。而对一个企业或组织来说，则要很好地分析员工的性格特性，合理分配工作，如让成就欲较强的职工单独或牵头完成具有一定风险和难度的工作，并在其完成时，给予及时的肯定和赞扬；让依附欲较强的职工，更多地参加到某个团体*同工作；让权力欲较强的职工，担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感，让员工感觉到自己所做的工作是值得的，这样才能激发职工的热情。

9、蘑菇管理

蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。相信很多人都有过这样一段蘑菇的经历，这不一定是什么坏事，尤其是当一切刚刚开始的时候，当几天蘑菇，能够消除我们很多不切实际的幻想，让我们更加接近现实，看问题也更加实际。一个组织，一般对新进的人员都是一视同仁，从起薪到工作都不会有大的差别。无论你是多么优秀的人才，在刚开始的时候，都只能从最简单的事情做起，蘑菇的经历，对于成长中的年轻人来说，就象蚕茧，是羽化前必须经历的一步。所以，如何高效率地走过生命的这一段，从中尽可能汲取经验，成熟起来，并树立良好的值得信赖的个人形象，是每个刚入社会的年轻人必须面对的课题。

10、奥卡姆剃刀定律

12世纪，英国奥卡姆的威廉主张唯名论，只承认确实存在的东西，认为那些空洞无物的普遍性概念都是无用的累赘，应当被无情地剃除。他主张如无必要，勿增实体。这就是常说的奥卡姆剃刀。这把剃刀曾使很多人感到威胁，被认为是异端邪说，威廉本人也因此受到迫害。然而，并未损害这把刀的锋利，相反，经过数百年的岁月，奥卡姆剃刀已被历史磨得越来越快，并早已超载原来狭窄的领域，而具有广泛、丰富、深刻的意义。　　奥卡姆剃刀定律在企业管理中可进一步演化为简单与复杂定律：把事情变复杂很简单，把事情变简单很复杂。这个定律要求，我们在处理事情时，要把握事情的主要实质，把握主流，解决最根本的问题，尤其要顺应自然，不要把事情人为地复杂化，这样才能把事情处理好。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lxpbuaa/archive/2006/09/21/1261626.aspx

项目的成功受到多方面的因素的影响，而且各个因素之间还存在正反作用力。系统思维就是要让我们能够清楚的认识到影响项目目标和成功的各个要素，以及它们之间存在的关系。形成一种适合项目的动态系统模型，通过这个动态模型去平衡项目各方干系人的利益，平衡项目四要素之间的关系，平衡项目的短期和长期的利益。项目经理的一个重要能力就是平衡，没有最优解，只有满意解，懂得了平衡就知道当项目出现变更和调整的时候如何更好的应对。从单要素最优的单向思维过渡到关注整个系统的全局思维模式上。

风险意识简单来讲就是项目在执行过程中可能发生的各种问题我都事先预见到了而采取了适当的缓解措施，这样才能够真正的让项目能够按照预先制定的计划和目标进行。再简单点就是如果风险管理做得好，项目是不应该失败的。君子安而不忘危，存而不忘亡，治而不忘乱。风险管理的重点正是在于要形成风险意识，要能够通过历史经验的积累，能够把项目的关键风险识别出来，使项目能够从事后的救火转变到事前的防备，使项目能够在前面紧张后面轻松。

要谈及量化管理首先应该要培训用数据说话的分析思维。在软件项目管理中我们做度量的目的，就是要收集和分析各种历史数据，通过对数据的分析来知道项目真正的效率，同时为后续项目提供各种估算参数数据。以数据说话让我们从全凭主观经验臆断转变到对事物的客观数据分析上。只有能够收集数据，分析数据我们才可能持续改进。有了数据意识后就是要有统计和量化管理方面的意识，利用统计学的思维和量化管理手段不仅仅是让我们的过程稳定和受控制，能够去发现项目执行过程中特殊原因引起的波动，针对特殊波动进行根源分析并采取纠正行动；还能够让我们能够根据预测模型更加准确的预测项目能够达成目标的程度和概率。

svn中建立branch或者tag的方法比较简单，totoiseSVN中的操作是:
1.选择Branch/tag..
2.在出来的界面中的To URL中填上URL，一般是svn://IP/Project/branches/branch-1, 这样就建立了一个branch-1的branch. 建立tag是一样的操作，只不过URL一般是svn://IP/Project/tags/tag-1
3.后面的Create copy from是用于选择从你当前的working base中的哪个版本中建立branch/tag，可以根据自己的选择来订制，一般选择Head Revision
subclipse中几乎是一样的操作。

Merge分为很多种:
1.多个branch之间merge
2.branch merge到trunk
3.trunk merge到branch
第2种用的比较多，比如在otfs接口中netamount的需求提出后就得建立一个netamount的branch，trunk继续在非netamount的情况下继续开发，netamount单独开发，当netamount功能测试通过后，将netamount branch merge到trunk下，然后将trunk release。
第3种情况用的也不少，如上的例子，当用户进行netamount测试时，如果用户不想只测试netamount的功能，则需要将trunk中的修改merge到netamount branch，然后从netamount branch中发布一个版本供用户测试。

branch merge to trunk在tortoiseSVN操作如下:
1.选择TortoiseSVN->Merge
2.选择Reintegrate a branch
3.选择From URL,URL填好之后可以点击Show Log,可以看看这个branch是否是你要merge的内容,下面的Working copy中也可以Show Log，可以确认一下你的工作目录是否是trunk。确认后点击Next
4.Merge Options里面有些选项，根据需要来选择，Test Merge按钮会告诉你这次Merge会做哪些操作，最好先Test Merge一下!如果是预期的Merge操作，点击Merge则可以将branch Merge到本地工作目录下
5.有冲突的文件需要解决好冲突，解决之后点击svn commit则完成了merge

从多个revision中merge到本地工作目录在tortoiseSVN的操作如下:
1.选择TortoiseSVN->Merge
2.选择Merge a range of revisions
3.URL to merge from填上merge的来源，merge 来源一般和你的working copy是不同的branch或者working copy是trunk 而merge from是branch
4.Revision range to merge填上需要merge的revision，格式是1,3,5或者 1-10
5.后续操作同Reintegrate a branch

subclipse进行Merge操作同tortoiseSVN的操作方式有所区别，原理基本同Merge a range of revisions。
点击Team->Merge后，只有一个界面，这个界面提供了两种Merge操作方式:
1.Merge某个版本范围内的修改到本地工作目录上
2.Merge feature branch到trunk (也需要先merge到本地)
第1种的操作方法是:
1.在from url中填上branch的url
2.from revision中选择建立这个branch的revision号,不是最新的那个版本号!
3.to url框中勾上"Use 'From:' URL"这个check box, To Revision中选择需要需要Merge到的revision号，一般勾head revision
4.Dry run让你预览一下merge效果，Unified Diff将Merge的两边进行Diff并将Diff结果保存到文件中。(在我机器中Dry run没有窗口出来，diff结果的文件除非只有很小的变化，不然看得头大)
5.点击Merge将merge到本地，这时候与版本库进行一下同步应该和上一步的dry run有同样的效果，如果merge过来的东西不是你预期的更改可以选择revert，但是新增的文件需要手工删除!如果是预期的merge效果，那commit，记得在comments中写上merge来的branch、from revision、to revision(不要写head，写数字)

总的来看subclipse的merge操作并不方便，不如tortoiseSVN

转自：http://cddcdd.javaeye.com/blog/353146

http://eyejava.javaeye.com/blog/308411

1、掌握Spring、Struts，Hibernate(或ibatis);

2、熟练使用SQLSERVER 、oracle、 mysql数据库系统一种或以上；

3、熟练使用Tomcat、jboss、websphere 等J2ee服务器一种或以上；

4、熟练使用eclipse等Java开发工具；

5、熟悉javascript编程，使用过ext或者dwr的优先考虑；

6、有团队合作精神和良好的沟通能力及心理素质，责任心强

7、有JBPM使用经验者优先考虑

8、有AJAX使用经验者优先

符合以上条件三条以上者工作年限不限

最近想招聘一批java的开发人员，简单要求写一下

1、在将要格式化的系统上安装WINPE

2、备份你的系统盘C盘上的资料到D盘

3、重启计算机，PE启动

4、ACPI

5、启动虚拟光驱

6、加载windows2003的ISO文件

7、格式化C盘

8、SETUP操作系统

9、win2003的序列号 JYCJX-CHTJX-RGH97-86WM9-RB6B6

10、高级选项选中从安装CD复制所有的安装文件

11、五分钟的时间安装完成

12、安装你的驱动程序（我的机器是顶星主板）

就是这么简单轻松搞定你的操作系统。

《离退休干部信息管理系统》课题于2003年由省交通厅离退休干部处立项，交通厅离退休干部处和公司共同承担。项目自2004年2月份开始实施，先后进行了系统调研、软件开发、硬件配置、人员培训、系统测试，自2004年5月系统进行试运行，提交验收请求以后一直没有进行验收，于2007年3月21日下午15时省厅老干部处组织项目验收。业主方即省厅老干部处项目的技术负责人以及相关人员，省厅科教处请来的5位技术专家，还有我们公司的项目负责人参加了项目验收。

鉴定的流程

1.       成立鉴定委员会

2.       讨论通过鉴定大纲

3.       课题组作课题研究工作总结报告、技术报告、经济效益分析报告

4.       介绍用户使用报告

5.       现场演示

6.       鉴定委员会对提供的鉴定文件进行审查

7.       各子组形成子组意见

8.       起草讨论鉴定意见

9.       形成鉴定意见

10.   专家签字

验收总结

在会议上由我们施工方做的工作有：项目研究技术报告、系统的现场演示。

在昨天验收会议上我总结了几点经验拿出来和大家分享，有什么不足之处还请各位更正，总结如下：

1、          做项目研究报告的时候注意演讲的条理清晰，应该本着由上向下的思路，首先需要介绍一下系统的设计思想、运行环境、开发工作、使用的框架等，然后介绍一下系统的模块划分情况，以及模块下面的子模块。

2、          进行验收的演讲人员一定要对开发的系统非常的熟悉，包括业务需求和技术实现。

3、          在演讲的过程中，注意不要被专家问倒，专家提问的时候要及时的回答，如果专家提出的问题确实是系统的bug或者设计的不足之处，那么你要主动的承认这个缺点，目的是不要出现僵局。

4、          在验收之前把项目研究技术报告制作成ppt，质量要高一些，便于简明的说明系统的原理以及功能模块。

5、          注意在验收的时候，准备的测试数据一定要正规一些，不要成为与会专家的话柄。

6、          最关键的是在软件设计的时候注意，软件的易用性，前后模块的关联性,非法数据的处理等。如：（录入日期的时候，日期变化了对应的星期也得同时变化；资料信息维护的时候最好用附件的形式；姓名输入1，2等数字的时候不允许保存数据；）。

转载注明出处：http://blogjava.net/badboyryan

1．认为必须要用Visual Studio.NET来开发.NET应用

你只需安装可在微软网站上免费下载的.NET框架即可。 安装了.NET框架，你就可以应用你最喜爱的文本编辑器和.NET工具命令行来进行开发。而且，你还可以应用第三方开发工具，如SharpDevelop。

2．独占信息

开发人员的显著特点之一即他们趋向于密藏信息。晓人所不晓的能力常常引起错误的优越感。相反，分享信息则有助于团队扩充知识。另外，随着其他团队成员的加入，分享的信息还可得到改进。最后，当你向另一个或一组开发人员解释一个观念或理念时，你的知识也得到扩充。

团队合作精神是Agile Software Development之类运动的驱动力。另外，许多团队利用同行代码评估（peer code reviews），即开发人员对其他开发人员的代码进行审查及评论，这种方法促进了双方的学习与理解。

3．忽略代码注释

给自己的代码加注释是一个简单而直接的方法，但为什么大家总是忽略这一点呢？一些开发人员错误的认为减少文件证明（任何形式的）能够改善工作安全。这与前面讨论过的独占信息一样，是一种谬误。

少量合理安排的注释能大大改善代码的可读性，并方便代码的管理。现在有一种过于使用注释的趋势。基本上来说，这些注释应对代码、变量、方法等作一简要描述。许多团队在对代码作出修改时喜欢插入注释。当（如果）出现问题，我们容易找出以前做过哪些修改。

4．没有看到版本控制系统的价值所在

大多数开发人员都十分熟悉这种情形：你推出一个重要网络应用的新版本，第二天一大早你的手机就响个不停，里面满是网站问题的叫声。

只要你愿意承认你可能犯过一两个错误，在这种情形下版本控制系统就是你最好的朋友。通过使用版本控制系统如CVS, IBM Rational ClearCase, 和Microsoft Visual SourceSafe，你就可以轻易地还原到以前版本的应用软件并进行生产。这让你有时间在生产地点已经准备好的情况下在开发环境中找出问题所在。这种方法比通过搜寻生产代码来找出问题要优越得多。

另外，源控制系统允许不同的团队成员同时开发相同的代码。当开发人员检查对系统所作的修改时，这些改变就结合起来。

一些开发人员不喜欢版本控制系统的原因之一是因为它给开发过程增加了一个步骤，这意味着向源控制系统提交代码并通过它来恢复代码的过程要减慢。这个额外等待的时间打击了一些开发人员的耐心。

5．认为所有项目都需要网络服务

由于对网络服务的过分宣传，许多开发人员认为在开发项目时必须以某种形式用到网络服务。尽管在开发过程中使用网络服务可能是必要或是恰当的，但并不是完全可能。你需要分析不同的情形，以决定是执行网络服务是否恰当。例如，另的技术如remoting可能更为恰当。

6．忽视了确认数据的重要性

在应用代码中，数据以不同的形式进行处理。因为这一原因，开发人员应该在开发过程中确认数据的完整性与有效性。这就是说，数据要通过可返回零字符的终端数据库读取。在执行前，就对数据进行检查，因为大多数的操作中都不能使用零值。

原文：

http://www.zdnet.com.cn/techupdate/security_protect/skill/story/0,3800081011,39431655-2,00.htm