我们常说工作中应该“对事不对人”，但事都是人做的，不同的人做相同的事效果可能相去甚远，再好的业务如果用错了人也会全盘皆输。正所谓“事在人为”嘛，识人、用人、聚人是一个团队管理者获得成功的基础。 先说怎么认识人 人格矩阵法。即所谓的Topk技术，Topk就是由：tiger、owl、peacock 与 koala 4个英文单词的第一个字母组成，即把人
从书上看到的两个技巧，比较有意思： 催眠对话面试被提问的时候，无论什么问题，回答的一开始先要点头称是，喊对；如果有机会提问，也要抛出让对方答“是”和“对”的封闭式问题，这样两个人的对话在一开始就进入了互相肯定 的思维下意识，这就是催眠的本质——控制对方的思维下意识，这叫催眠对话。 反面试你提问题给面试官的时候。 说自己思考了很久的问题，就是这家公司和它的竞争对手最大的区别在哪里、对员工的待遇
“实验日”——你爱叫什么都行，算是这么一种方式。 在这样的日子里，开发人员基本上可以做任何他想做的事情（我承认这种想法是从Google来的）。比如研习最新的工具和API、准备认证、跟同事讨论乱七八糟的事情、开发自己喜欢的项目等等。 如果你是开发经理、研发主管或其它什么技术管理者，可以在每个迭代周期之间安排这么一个实验日。这样不仅你能得到自然的休息，开发团队也能了解自己感兴趣的、最前沿的知识。
首先强调一些Scrum的基本概念本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验，供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之，但是仍然，我还是要强调以下我们对Scrum达成的“共识”:-) Scrum开发流程通常以30 天或者更短的一段时间为一个周期，由产品经理（Product Owner） 提供新产品的需求规格开始，开
任何成功，都有太多的偶然；而任何失败，都有太多的必然。 ——不犯错误，就存在成功的“偶然”。 总有人急于把自己的结论先抛出来，然后再摆事实讲道理以求对方接受自己的观点，其实这是严重的次序错误，因为没有人心甘情愿总被他人说服，尤其是老板，都习惯由自己得出结论。所以，引导远胜于说服，而最能体现“润物细无声”一般境界的引导方式就是“拾遗补缺”：在老板考虑的诸多因素中，凡是对我们有利却被他遗漏的，就提
相信软件开发人员能轻松的、自动化的完成工作？ 不！他们的主要工作是人类交流，将需求变成计算机程序，不管我们怎么改变、优化软件生命周期，这项工作仍然是必须的，并且它是不可能自动完成的。
首先，我们需要先达成一些共识：这里的“新科技”是指信息化技术在现代企业中的应用，“价值”对于企业来说就是利润、收益，也是企业经营的根本目的！ 那么，一项新的科技（或者说“技术”）在什么时候才能带来价值呢？ ——只有当一项新科技令企业冲破一个现存的限制时，这项新科技才会带来价值 。 但往往是在新科技实施的过程中，人们忽略了改变相关的运作规则，仍然沿用旧的运作规则，那么这些旧的运作规则就是“限制
超限效应” 是指刺激过多、过强和作用时间过久而引起心理极不耐烦或反抗的心理现象。可以通俗的理解为大话西游中的“唐僧效应”。 试想一下，如果一个长辈在孩子耳边喋喋不休、一个“权威”对年轻人没完没了的强调他的经验，会不会得到叛逆、反感的回应？——对于管理者来说，往往最简单的话语最管用。 面对频频犯错的下属或晚辈，要坚信：“指点一二”，更能令其醒悟；“点拨两下”，更能令其思考 。有思考，才存在悔过和
应该理解个人工作风格，并且牢记这些实践经验。以下所列的项目应该成为与人相处的第二种本能。也是每个想成功的项目经理必备的常识： 尊重每一个雇员，包括供应商、合作伙伴 虚心倾听 做出见识广博的决策 不要当众批评别人 了解自己的实力和做事的先后顺序 真诚地听取团队成员的意见和建议 对目标和交付产品有清楚的了解 在IT团队中提倡合作和信息共享 了解每个人的做事风格及他们的优缺点 表扬应以团队成员喜欢的方
将你置于死地的，不是你不知道的东西……而正是你“知道”绝不会置你于死地的东西。
在工作中，愤怒都是因为恐惧。 ——采取行动，防止人们随便发怒。
书是经过反复琢磨写出来的东西，往往饱含了作者的心智，相对而言，是垃圾信息最少的载体。——多看书！ 人的情绪不是由某一诱发性事件本身所引起的，而是由经历了这一事件的人对这一事件的解释和评价所引起的。——这是心理学著名的一条理论。拾遗补缺。——不要急于抛出自己的观点
Lucene乃是当今免费开源搜索引擎的霸主，确实它十分好用，发展势头也很生猛，在Apache组织的支持下不断的更新、推出新版本。 但是其存在一个隐藏的很深的bug，相信困扰了不少和我一样研究使用过它的人，这个bug从早期的版本到目前的V2.3.1一个存在，不能不说是一个遗憾。 具体触发这个bug的原因很复杂，在某些环境、服务器、应用中…… 表现为建立索引文件和执行查询时报“NoClassDe
CSDN上的技术牛人真的不少，相信各位应该经常制作PPT（Power Point）演示文档做培训或进行技术传播吧。正好不久前完成了公司产品培训及工作流概念培训，同时最近在准备个SOA/Web Service的技术培训，期间看了不少人的培训、介绍演示材料，颇有些想法，在这里想到多少就说多少吧。 1、既然去培训别人，自己应该很了解要讲的东西。所以，PPT上的内容应该简明扼要，直击要点，让人印象深刻，
我认为主要是为了用工程的思想去规范化软件的开发过程。 以往非工程化的软件开发方法，用在需要长期投入、多人维护的非单一版本的大型软件研发过程中会造成难于维护、混乱，甚至开发陷入“泥潭”（见《人月神化》中的描述）中而无法继续进行的情况；而且非工程化的软件开发不能保证一个规范的开发过程，从而不能有一个可控的质量标准，造成软件质量得不到保障、缺陷得不到控制和不可度量等情况。 CMM可以为我们带来成熟的
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
