求索

在一个软件开发组织里，若干职能单位负责各个业务模块，然后就是大小各种专项。专项可以横向拉通各个单位，但专项一多，或者有点泛滥，各个业务单位的职责就会有所淡化，目标也有模糊的地方。专项就像是东厂、西厂，可以四处横行，而业务单位却不断要进行各种配合。利也? 弊也?
所谓专项一般为攻关，拉通多个沟通不畅的团队而设。如果团队之间配合无间，规划和执行也都到位，又何来专项！

项目最本质的一个特性是不确定性，所以实际的执行与预估有些偏差很正常。预估较实际所花费的工作量时大时小，有人快，有人慢。单独从个人能力来解释进度并不客观，因为本来项目排程时就应当考虑到人的能力的不同。既然一切都在项目进度规划中定义，所有工作都能按步就搬的完成自然最好，但项目的不确定性告诉我们这是难以确定的。总有些任务会提前，也总有些任务会滞后。如果我们只关注滞后的任务，那可以想像项目总会

帕金森定律(Parkinson's law):   只要还有时间，工作就会不断扩展，直到用完所有的时间。   简言之，工作总在最后一刻才能完成。在软件项目管理过程中，开发周期和生产力往往是最难掌控的。一方面要确保一个安全的开发周期，另一方面又能让团队发挥出最佳生产力。单单强调人的素质等因素，会将事情变得更为复杂且不可控。关键链(Critical Chain)可以帮助解决这些问题

转载请注明出处:http://blog.csdn.net/horkychen (之前在世界经理人的翻译内容)职场新人通常需要从底层做起,他们常感觉到自己都快被僵硬的管理、过时的办公室文化以及挫折感给整残了。刚出校门，对未来充满憧憬，许多人都会挺过这一段时间,并转变到疲于工作的人。刚毕业的这段时间其实是对自己的职业发展，甚至是未来生活进行思考的绝佳时间，除非你已经自己开始创业了。

下次当你听某人谈到生产力时，仔细听一听说话的人是否用了“人员调整”一词，很大的可能性是他或她没有提到这个词。多年来从听到的关于生产力的讨论或看到的数以百计的关于这方面的文章中，我们从没有遇见一个专家谈到有关人员调整这个主题的任何事情。然而只谈论一个而不谈论另外一个有什么意义呢？下面评价一下公司在改进生产力方面要做的一些典型的事情：.  强迫人们加班加点.  产品开发过程的机械化

管理大师查尔斯•汉迪曾经在伦敦商学院教书。在培训一些经理人的时候，他讲了这么一段话：“你们不会把这次培训看成什么难忘的学习机会，除非它能帮助你们反思过去，理解从前的经验。如果能达到这个目的，它才能帮助你们更好地解决将来出现的难题。” 　　汉迪的这一段话，包含三个重要的公式。最重要的是第一个：经验+反思=知识。经验本身不是知识，只有经过反思才形成知识。你做了五年或者十年的管理工作，骄傲地

转自以前在世界经理人写的博客.转载请注明出处:http://blog.csdn.net/horkychen在职场中思索个人价值是个永恒的话题，其实想找一个等式是很难的，但可以给个定义： 个人价值取决于为公司创造的价值，也就是为公司解决什么问题!这就决定了个人价值是动态的，有一定的有效期，而且个人价值也不等同于价值回报。比如有“没有功劳，也有苦劳”这样的观点的人还是比较普

人可能出于以下原因不大情愿去做一件事:  1.太简单  2.太繁琐  3. 太难  4. 认为没有价值或意义 (或对工作而言，或对个人而言)  5. 时间上安排不了  6. 其它方面带来情绪上的影响首先要尊重个人的价值判断，如果是5及6，就不要强求。如果4，则要分开看。倘若个人明确了未来目标，且与现在的目标冲突，在讲清可能的收益后，就顺其自然。  倘若个人目标并

相对于软件公司中的开发团队，维护团队似乎常常默默无闻，做事相对于保守，远没有开发团队那样常常让人有新鲜感。这是一种很普遍的现象，也就是维护团队的价值常常被有意或无意地降低了。 事实上，维护团队的建设和管理比开发团队所应对的挑战大得多，而运行得当的话，可以同项目团队或开发团队形成互补，发挥驱动力。软件维护团队的目标和流程软件维护团队被赋予维护已交付产品的职责，主要工作内容是分析修复新

人绝不是一种资源。一方面我们不可能因人设岗，另一方面也不能忽略人性的差异。面对问题时，不要总是单纯地从人的态度或品德上查找问题，而是要反思人事安排和流程建设上的不足。奢望一个人改掉他的缺点，还不足充分发挥他的优点。前言MBTI将人区分为16类人格特质，我无法断言是否真得能表达出人的真实一面，毕竟只是统计性的结果。我的思考并不在于它归类的结果，而在于它的归类方法。

为什么我们在考虑代码管理的时候会担心影响程序员的积极性?精英化的团队是不是能完全解决代码质量的问题? 战功文化会引入什么样的代码管理问题? 以下是我对这些问题的思考。代码之于程序员，就像沙场之于将军。普遍希望完全控制代码，可以自由驰聘、攻城掠地。但对于一个团队合作下的代码，这种行为却隐藏着极大的风险。特别是在一个崇尚战功文化的团队里，在鼓励大家承担更多责任的同时，同时也要注重对代码上的

从局外人的角度的确可以清晰的发现问题，但很难得到一个合适的解决方法。** 只有将自己融进公司，融进团队，才能更清楚了解问题的本质，才能有好的应对方案。

有了职位说明书，看起来就像有了不同类型的材料，当需要搭个房子时候，就很清楚各需什么样的材料？费用会是多少？人才利用的效率自然能大大提升。但是问题在于材料的差异性可能很大，这里就列出几个问题，可以帮助系统地思考职位规划。

专业精神对于在我们这些在职场打拼的人来说非常重要。不论在哪个行业，也不论什么岗位，专业的做事都是同等的重要！而达成专业化，个人认为需要三个步骤。 一.最为基本的是保证质量。    你所交付的工作成果的质量就决定了你的基本价值，交付的成果必须是符合要求的，否则就是质量不过关，而且不同的情境下的“要求”是不同。以软件开发为例，自然是按指定的时间交付符合项目规划的软件产品。

“权力”和“头衔”只是一种形式，“责任”才是应当时刻记起的。

自我驱动或者自组织团队是现在软件公司努力建设的方向，自我驱动也常常挂在嘴边。但以我的观察，自我驱动或自组织团队建设并没有带有真正的团队生产力提升，反而很易遇到发展瓶颈！自组织团队的困境问题在哪里？ 我今天终于恍然大悟。这也许也是敏捷在中国一直处于困境的原因之一。简而言之，在自我驱动团队建设上缺少方法和执行力！思想是别人的，而做法仍然是自己的。可以简单地通过几个方向来审视

识人用人是指识别和发掘下属的优势与潜能，用人之长。对于不足的部分，也可以有效地加以补强。虽然这个工作很重要，但相关的研究和方法五花八门。个人觉得适合就好，倒不一定非要熟读九型人格，然后再加以套用,并且不见得合适。准确的认识一个人总需要一些过程，中间需要多次修正，才可能比较完整。结合所从事软件开发工作的特点，我使

主要内容:  作者及书。  Part I. 我们的行动如何创造事实，我们如何才能改变现实。  Part II. 第五项修炼：学习型组织的基石。  Part III. 建立学习型组织。  Part V. 实践中的反思。第五项修炼 (学习型组织的艺术与实践)from Horky Chen

周末参加了入职引导人的培训，现在结合我的经验总结一下个人感受最深的五方面内容。0. 明确入职引导人的目的和目标作为入职引导人，虽然不是一个岗位，也一定要清楚自己的角色和责任(Role & Responsibility)。理解责任，除了细节的条条之外，最为重要是清楚目的和目标。目的和目标要分开谈，目的(purpose)是深层次的要素或者驱动力，目标(target)是则一个清晰明确的定

转自之前在世界经理人写的博客.转载请注明出处:http://blog.csdn.net/horkychen在>中提到了一句话:"重要的是能做什么，而不是不能做什么!" 每个人都有其专长，正如每个都人都有缺点一样。关注于缺点，你看到的都是不足。关键要尊重个人特质，扬其长而避其短。有时个人的自我认识有些偏差，你认为是缺点的地方，对方可能还认为这才是个人最宝贵的优点。其实我们自己对别人的

原文地址: http://managementhelp.org/staffing/screening.htm  Copyright Carter McNamara, MBA, PhD你面试时的整体性和专业性，可以对候选人形成一个强有力的积极印象。它也传达了如果他们被聘请了也要这样做事。准备为所有基本符合资质要求的候选人安排面试。基本资质都被指定在职位描述中。这种做法有助于确保你

<br />在别人实现的基础上进行开发，基本是一种常态。特别是对原来的代码陌生的情况下，有没有什么好的实践方法呢？<br />基本原则:类似重构一样，尽量减少对原有流程和结构的修改，最好能兼容原有结构。上来就按自己的相法来修改代是比较容易的，这样做很大程度是因为理解原有的代码需要较长的时间且有一定的难度，但这样会增加系统的复杂度，也会引入许多不必要的风险。除非得到项目负责人的同意，否则相当然的直接动手重写，绝非是什么好事！<br />那么如何做呢？要花大量的时间从头阅读代码吗？你以为文档写得那么好吗？<br

除去基本的专业精神，以及一般的职业精神外，作为研发人员还有以下两项独特的职业精神: 一、无中生有---创新精神二、点石成金---勇于革新的精神研发人员在认识工作的价值时，不能单看工作最终成果的价值，而是结合自身的发展来看。从哪些工作可以先锻炼出坚实的基本功，得到有效的工作方法论，这是第一步。然后再思考团队(公司)需要什么，我可以做什么，以此选择工作。最后，才是以思考我的价值如何最大化的体现来选择工作。

最近经历了团队的一点小震荡，平生第一次劝退了一名员工。正在进行的项目上，沟通也是问题多多。每个人的想法各异，这是不争的事实！但如果都想坚持自己的立场，维护自身的利益，最后反而是两败俱伤，无一方得益。 想起《高效能人士的七个习惯》中所提到的共赢思维确实很精僻！一个人从依赖到独立，再到互赖，一定要学会共赢。遇事学会全方位的思考，争取一个大家都能接受的方案。工作中和生活中都是这样。我一个同事在吃

<br />http://www.ceconline.com/leadership/ma/8800056428/3d948f9501/?from=RSS<br /><br />绝大部分人都感觉自己已经非常努力地工作，但结果却不尽如人意，到底问题出在哪里？<br />　　我们都知道，管理实际上是人、物、事三者的辩证关系，不同的组合就会得到不同的结果，而管理，就是确保人与物结合后能够做出最有效的事来。所以我们有时会慨叹人和人的不一样，其实管理的奥妙正在于此，同样的人，同样的资源，交由不同的管理者来运作，结果会相

有时忙起技术上的事情，就容易忽略掉项目管理上的事！项目管理是件比较琐碎的事，牵连的方面很多,而技术还是单纯很多，不过需要大片的时间来找资料、学习和消化，然后还要总结和升化，最后分享给大家。工作上，想做到平衡，确实不易。对于较熟的案子，基本上就是项目管理的工作，对于新的案子，就会有一些冲突了！这是一个时间管理的问题，也是责任的问题！毕竟要对项目的产生负责！ 最近也在读>，要好好沉淀下心情，平

程序员流动性一直比较高,这里面有对理想的向往,也有对现实的无奈! 我想这里有一大部分原因应归结为定位偏差，个人的预期定位与工作中的实际定位的偏差（包括职责[发展方向]、职位及薪资）。【*注:薪资是由前两者所决定，很多人其实并不真正明白！单纯看重薪资，有时会帮倒忙！】 我们总是在工作中不断寻找自己的定位，总是要思考未来的定位，当现实与理想的差距太大时，便会有了换个环境的想法。这是一个模型，可

公司内部规划的新产品开发项目已经开展一个多月了,时间紧、任务重是这个项目最突出的特点,之后的需求定义一变再变，甚至于文档的格式也一变再变，而不变的是开发周期！　其中全无系统设计的时间，需求及功能分析也是草草了事，于是问题也不断的浮现出来！从项目管理的角度，只有重视风险评估，或许可以请公司上下的头头脑脑们静心观察一下这个项目。 总结起来，有以下几项是需要在需求分析时注意的:1.详细定

首先概括一下, 遵守公司的规章制度可以帮助开发人员解决以下问题:  1. 不会被老板或管理者死盯,不会造成"总是被管"的心理压力。  2. 节省自己的时间，不会被不必要的烦恼所干扰，从而集中精力于开发工作。  3. 因为1与2,所以更容易在工作上取得成绩,或者使自己的工作更为轻松。  4. 因为前面三条,一切可能因此会变得简单而幸福! 不了解或不遵守公司的规章制度会给你带来

读了一下>，最大的感触的是软件行业的问题似乎在这二十年没有变化过，作者也提到过软件行业的革新的速度只不过比钢铁企业稍快一点而已，我想应该远不及街头小贩的革新速度。如果是这样，既然这本书被如此推崇，却得到多少实质性的改变呢？ 说到底，这件事完全要看老板怎么看！即便程序员和项目经理再清楚这个行当所谓的真理，又能如何？ 人人都能有个靠窗的位置，人人都不用常加班而平衡地生活，真不知道老美是不是已经享受到了。但看看我们周围，那只能是痴人说梦一般。醒醒吧！变化是一步步进行的，环境也是这样！想要做到如作者期望的那般，还有

 让别人指出工作中的错误是需要学习的，并不是天生就会的。我们都自豪于自己的工作，从不乐于承认错误。我们不知道犯了多少错，也不愿意其他人发现这些错误。如果你正着手于建立成功的Peer Review,这些自然的抵触情绪就必须克服。Peer Review是和技术训练类似的社交活动。在一个组织中，逐步灌输Review流程，一定要了解组织文化和成员们所持有的价值观。经理们应当相信花在Review的时间是一种投次，然后为团队安排Review,你要理解为什么某些人并不愿意将自己的工作拿给同事们做详细的审查，而且牢骚不断。

<br />Review的结果不可用于个人工作的评价依据，这样会严重影响组织的文化，人人开始回避Review。可以使用总的统计数据进行质量改善。滥用Review会导致一些不良态度的产生:1.开发者不愿进行Review2.Review人员不会在会上直接提出问题3.Review过程中会进行激辨4.内部Review时会趋向发现较少的问题5.开发者可能反复提供相同的代码进行Review,以减少可能发现的问题。<br />作为一个Manager必须认真思考这个问题，帮助解决在Review上的抗拒心理。<br />Re

转载请注明出处:http://blog.csdn.net/horkychen来源 Check In, Don't Check Up (照看而不是介入!)我从来不是微观管理者(micro-manager)，特别是应用agile和Scrum之后。初入职场时，要不是太忙于和别人搅和在一起处理问题，我很可能就会成为一个微观管理者。但是当尽量避免同大家一起检讨细节问题时，仍要认真地照看(chec

原文作者: 孙振耀 发布于经理世界网惠普公司相信，有关领导和管理的培训课程，一定要由内部人员来传授。教导(Coaching)包含了知识、技能及企业价值观，因此不能用外包培训或企业大学代替。由于经营环境及战略的不断变化，职业经理人对员工的教导也就永远没有止境。很多时候，我们需要“用不太对的人做对的事情”，为了帮助“不太对”的部属完成任务，教导就显得更加重要。“经验总结－知识技能－传授影响”三

马云语录:  世界是由懒人来支撑的！  懒不是傻懒，如果你想少干，  就要想出懒的方法。      要懒出风格，懒出境界。McConnell在他的>提到三种"懒":"实在的懒","开明的懒"以及"一劳永逸的懒"。并说明第三种"懒"才是最具产值的"懒",因为它需要运用工具或者代码来为自己完成任务：这就是工作中的自动化。<<The Pragmatic

转自以前在世界经理人写的博客.转载请注明出处:http://blog.csdn.net/horkychen    以前总执着于学着抓大放小，于是自己也不断的学习各种方法论和创新思维理论，努力提高自己的层次。但是最近的工作中却状况不断，许多细节产生的问题而爆发出来。这一度使我困惑于对理论学习的怀疑！总不能提高的是对问题麻木的层次吧！    经过自我反思，发现根本原因是自己对于

“不想当将军的士兵不是个好厨子”，《武林外传》中的一句台词，让我们捧腹大笑的同时，更让很多人都记住了编剧宁财神这个才子。当一个人在某些时候被称之为“人才”的时候，实际上是因为此人在某一“专业”方面具有扎实的功底，这些“专业”本身也许并没有很大价值，但是发挥“专业”后却能够为他人创造出非凡的价值，这也是一个人有其个人价值的原因。网上很多人都在说，在美国请律师是一个很烧钱的事儿，你向他

转载请注明出处:http://blog.csdn.net/horkychen圈复杂度用来评价代码复杂度，以函数为单位，数值越大表示代码的逻辑分支越多，理解起来也更复杂。圈复杂度可以成为编码及重构的重要参考指标，以指导撰写可读性高的代码。有关圈复杂度的定义，可以自行搜索。《代码大全》有如下的定义:计算子程序中决策点数量的技术 (代码大全2,19章P458)1.由1计数，一直往

德鲁克说:“组织的成员作为个体，发展得越好，组织也会取得更多的成就。这一点正是今天所有经理人培训和资深经理人教育课程重点和背后的真谛所在。当组织严谨的作风和道德精神不断发展、组织的目标和处事能力不断提升时，组织内个体成员的发展空间也愈加广阔。”借着写博客把关于软件开发中新人训练的想法总结一下，也希望抛砖引玉，得到大家的指正。综合来说，一个软件工程师的培养需要涉及以下四个方面:

软件开发过程中的审查 (Review) 希望别人做些什么->定义出流程希望别人做出正确的结果->定义出审查制度  软件开发项目中包括很多的审查动作,贯穿于整个开发过程。个人认为审查主要有以下目的：1.尽早排查出潜在的问题(Potential Risk/Issue)   经过其他人的参与，以不同的视角提出不同的看法，会有类似头脑风暴的效果，集思广议来查找工程师未能注意的问