团队感悟--个人信念与团队信念

团队感悟----个人信念与团队信念

前记：

这是一个有关“团队建设与体会”的系列博文，其中的每一篇都记录了我曾经一段时间的真实想法和作法，即使到现在，我也常常把这些文章翻出来读一读，每读一次，感悟就更深一点。经历过由无到有，由小到大，由不被提及到渐被重视后，我试图发现和真实记录这个团队和这个产品成长过程中所经历的每一个关键细节，也许，将来的某一天，它的价值将不仅仅是几行文字。

下面，是此系列文章的第一篇，它主要想说明这样一件事：一个团队，首先要有核心人员，核心成员构成了团队的核心精神和核心价值观，核心人员自己要具有极强的个人信念，然后，要通过各种方式将这种个体信念转化成团队信念。此外，我还想表达的一个意思是，团队并不是万能的，作为一个团队的核心领袖，更不能单纯地迷信团队，因为在很多的艰难时刻，很多的问题，是需要你独自一个去单独承受的，其他任何人，都帮不了你。

史玉柱的核心团队， 从巨人大厦， 到巨人网络， 跟了他十年;

马云的核心团队， 从阿里巴巴创建以来， 也一直跟了他十年;

牛根生的核心团队， 从伊犁出来作蒙牛， 一跟也是近八年。

大凡这些取得重大成功的企业和企业家， 其背后都有一个持久的团队。 在我研究这些公司时， 我也在慢慢观察和总结他们的共同之处， 与其说是有很多共同之处， 倒不如说: 成功的团队， 都是很相似的。

一个成功的团队， 需要靠哪些东西来支撑呢？

需要的东西， 很多很多。 对于这个问题的回答， 也见仁见智， 每个人都会有自己的看法， 我也把自己一直以来的研究， 观察和亲身实践的东西总结一下， 跟大家分享。

首先， 我们要明白 "团队， 是一个什么样的概念" ？？？

是不是只要一群人聚在一起， 就叫作团队？？

是不是只要分好了工， 划分好了职责， 就叫作团队？？

是不是整天装模作样的搞得很忙的样子在每个人之间来回协调， 就叫作团队？？

是不是一帮子人整天在一起吃吃喝喝， 嘻嘻哈哈， 就叫作团队？

显然不是。

我们常说， 要有"团队观念"， 要有"团队观念"。 而实际上， 一个团队， 之所以能够形成一个团队， 往往是因为某一个个体或某几个个体作为核心的， 而这个核心所倡导的， 所坚持的， 所贯彻的价值观， 就是这个团队的核心价值观。 以这个核心为主导， 才形成了一个有凝聚力的团队。

我说这个话是什么意思呢？？

我的意思很简单: 一个团队， 首先， 是要有一个或几个核心人物的。

这个核心， 在每个重要的时刻， 都可以冲在最前面， 挡在最前线， 他们具有超强的将事作好的信念， 不管外围的环境多么恶劣， 他们的信念从不动摇。

也就是说，？在一个成功团队的核心价值观里， 有一条是最重要的: 在任何时候， 要有极强的信念， 要永不放弃。

信念这个东西， 是可以传染的。？

所谓的信心， 便是来源于超强的信念， 而一个团队的整体士气和信心， 就来源于团队的整体信念， 最初是来源于核心人物的个体信念。 但是， 有一点很重要， 核心人物的信念， 必须是可被传播的， 而且， 不能太虚妄， 要符合实际， 要让团队成员觉得可信并可依赖。

信念不死， 精神就永存。？

马云在财富人生的访谈中， 总结的这么多年最重要的经验就是: 坚持!

这个曾经被我们说过无数次的词语， 如此朴素， 却又如此难以作到。？

作为团队领袖， 或者团队核心， 他最起码应该具备这样的信念: 即使我一个人， 也要把它作下去， 只要还有机会让我作。

很多时候， 在实际的工作协作中， 我们力求发挥每个人的创造力和积极性， 讲究充分授权， 但这并不意味着我们要因此产生很强的依赖心理， 实际上， 在团队管理中， 产生依赖心理是非常危险的行为， 它把作事与感情混为一谈， 将工作变成了类似家庭琐事之类消磨斗志的玩意。 既要充分发挥每个人的积极性， 也要随时准备着有: 这个世界离开谁都转的打算。？

而事实， 确实也如此。？

我们需要建立的， 是这样的一种信念:？

1。 在任何时候， 尽可能以积极的心态去面对每一天， 相信明天会更好， 踏实一件件小事作起，？作到极致;

2。 用你的信念， 去鼓励其他人， 将你的信念传播开去， 将个体信念转化为集体信念;

3。 在任何时候，？"你自己"永不放弃的信念， 才是最彻底， 最可把握的， 只要自己不放弃， 那你就不会被任何人或事放弃。

作团队感悟----凡人心态

前记：

千万不要以为，作团队，只是管理者的事，只是团队领袖的事，只是产品经理的事。

一个好的或者坏的团队氛围，相当大程度上决定了产品质量，研发速度以及工作效率。好的团队，会让工作变得不再枯燥和令人生畏；好的团队，会让你不由自主的想多在公司多呆一会，多干一点活，因为，那里HAPPY，也有成就感。

千万不要以为，“管理”，只是管理者自己的事，普通一员就不用考虑任何“管理”的事。事实上，这要看你如何理解管理。

“管理”，并不只是“管人”，我认为，它首先指的是管好你自己：管好自己的时间，管好自己的精力，管好自己的能力，等等。也所以，每一个知识工作者，又都是自我管理者，只有作好了自我管理，你的各项工作才可能进入一个良性循环，否则，就只能怨天怨地，怨公司怨老板。

所以，无论对于管理者，还是一个普普通通的程序员，都应该首先学会自我管理。要努力提高自我管理水平，要努力尽快把自己培养成一个可以独当一面的人。

同时，必须指明的是，在我的这个“作团队”系列文章里，有很多话，是同时对两类人说的：一是管理者，二是被管理者。如果你是管理者，可以多比对一下平时对团队的管理方式；如果你是被管理者，你也可以从这些文章中找到适合自己的作事方法。

在任何时候，我都主张积极的生活态度和工作态度，以积极的心态去面对每一天，从无数个细节处想办法提高你个人的工作效率和质量，想办法提高整个团队的工作效率和质量，总有一天，你会得到你该得到的一切。

回到本文，这是一篇有关“凡人心态”的作团队感悟，主要是想说明这样一件事：不要一味地试图在团队中塑造所谓的“明星队员”，即使你心里想，也不要很显式的表现出来，不要过份突出某一个单个个体在团队中的作用，即使某一个人发挥的作用很大，也不用整天把他的功劳挂在嘴上不断宣扬，那样作，于团队而言，弊大于利：爽了一个人，羞了一大群。对于确实有很大功劳的“明星队员”，可以用报酬及其他隐式的方式给予与其付出相称的回报：你可以肯定一个人，但不能打击一群人。要让人人都明白，团队之所以成为团队，是因为：有你，有我，有他，每个人都有自己的优点，每个人都可以为团队尽可能地发挥自己的优点，他可以，你也可以。

马云在总结他的团队成长经历时， 不止一次说过这样一句话:？我们是一群凡人， 在作着一件不平凡的事， 如果你认为自己是个牛人， 请你离开， 我们不需要你。

呃， 让我不禁感慨: 原来， 成功的有凝聚力有战斗力的团队， 大家都是相似的。 回望自己的这个团队的成长历程， 又何尝不是如此？ 我们曾经迷信牛人， 曾经以为有所谓的团队救世主存在， 曾经以所谓的牛人论为核心。 然而， 我们错了， 这直接导致团队士气低落(因为只有牛人干起来有劲头，其他人都看着他干)， 进而导致开发效率低下， 更进一步大大加剧了产品风险， 所幸， 我们的醒悟来得并不晚。

凡人心态， 首先是团队成员自己对自己的要求， 这是一种从下向上的要求。？

要在心里时刻记着: 你是一个凡人， 现在已经是一个要求高度团队协作的商业社会， 如果想干成一件事， 单靠个人成功的可能性远小于依靠集体的努力。？

同时， 自己心里要非常清楚， 并引以为戒: 地球离了你照样转， 别以为你自己就是救世主， 你在的时候， 作为团队的一份子为产品的成功贡献力量， 但是， 当你不在时， 世界并不会因此而改变， 其他的后来者照样可以推动团队向前走， 切勿妄自尊大， 以为老子天下第一， 以为你走了团队就散了。

凡人心态， 其次是团队这个集体对成员的必然要求， 这是一种从上向下的要求。？

作为团队的核心价值观之一， 团队核心有必要将这种"凡人心态"广泛传播开去， 让团队的每一个成员都能很好的认识到这一点， 不管他是高学历， 还是高能力， 不管他是能上知天下知地， 还是能玩转ACM， 在团队里， 每一个人就是普通一员， 团队给你的回报， 永远是看你给了团队多少贡献。？

弄清楚并让所有人明白这一点非常重要， 这直接关系到团队的稳定， 以及积极健康的团队氛围的建立。？

你无法想象， 在一个以某一个牛人为核心的团队里， 团队的其他成员会如何积极的发挥自己的作用， 因为他们知道， 即使他们再努力， 上面的人看到的也只是牛人的功劳， 而不是自己的功劳， 与其这样， 还不如让牛人们自己忙活去， 也名正言顺。

同时， 作为团队管理者或者团队核心， 要让团队的每一个成员充分知晓这一点:？即使是管理者或者团队核心自己， 也是一个凡人， 在这种理念面前， 人人平等。 千万别把自己当牛人， 否则， 对不起， 你离被抛弃已经不远。

说到底， 凡人心态， 是一种真正的合作的心态， 也是一种积极的向上的现代人的心态。？

自认为老子天下第一的人， 很难真正融入团队， 也很难真正作成一件大事， 其失败是必然的， 其失意也是必然的。？

我们现在招新人的一个最基本的要求就是: 水平不见得非要多么高， 但必须具备团队精神， 姿态要低， 要具备凡人心态， 要有拼搏精神， 要敢于迎难而上， 要勇于承担责任。

我们认为:"凡人心态"， 首先， 代表了一种明智的自我认知能力，？其次， 代表了一种良好的抗压能力和自我纠错能力，？最后， 它更深层次地代表了对团队其他成员的最起码尊重。？

因为， 我们认为， 这个世界上， 每个人都不笨， 你觉得你聪明你能干， 那只是把你放在了那个位置让你有了那种经历而已， 换作他人， 只要努力， 也照样可以作到， 没什么大不了的。？

由于把自己定位为凡人， 他会更积极的学习新知识， 在遇到挫折时， 会更理智的去解决它而不是为了面子捧着错误而不修正;

由于把自己定位为凡人， 在面对强大的竞争对手时， 会以更务实的态度去一步步脚踏实地的逼近对手， 而不是就此止步或逃跑或者盲目冲锋;

由于把自己定位为凡人， 他所有的努力都会更加务实， 以实用为主， 不喊口号， 不唱高调;

凡人心态， 会让我们更加积极， 更加努力， 它代表的是一种积极的阳光的生活态度， 也是一种走向成功的生活态度。？

这种心态， 是我们成长为一个真正成熟的职业人所必须具备的基本素质。

如果你想融入一个团队，？你需要具备凡人心态;

如果你要带领一个团队，？除了自己要具备凡人心态外， 你还需要在团队中建立并传播凡人理念。

作团队感悟(3)----信任，授权与自我管理

前记：

作为团队管理者，我们总希望团队中的每个成员都能具有充分的自我管理能力，都能在某一方面有所特长，都能独档一面；而作为团队成员，又都希望自己的上司能给自己充分的授权，可以放开手让自己干，可以让自己在编程这件事上享受充分的自主权。

乍看起来，似乎二者的目标完全一致，理应配合得很好。而事实呢？

事实是，很多的管理者，不敢对下属充分授权，因为总是担心他们作不好自己交待的事，怕耽误了项目，进而怕影响到自己在公司的位置；而作为下属，又普遍抱怨没有开发自主权，抱怨上司管得太细，细到一个函数接口都要跟你唠叨半天，让编程这样一件极具创意的事变成了一件只用码字的苦差事。

好吧，我要说的是：这是没办法的事，在你个人和你所在的团队，没有成长和成熟起来时，每个团队和项目都必然会经历这样一个阶段，关键的是，每个项目和团队，应该按照什么样的一个方式来慢慢的让双方都能相互信任，从而达到上司愿意授权而下属又能独当一面的境界。

这是一篇有关“授权与自我管理”的作团队感悟，其想表达的一个核心思想是：世界上，没有平白无故的信任，也没有平白无故的授权，作为团队成员，每次工作的完成情况要尽可能比上司希望的更好一点，要不断努力以自己的成绩来证明自己已经具备自我管理能力，已经可以独当一面，从而获得充分授权；而作为团队管理者，应该在团队成员尚未完全成熟时，采取正确积极的方式引导他们养成良好的工作方法，工作态度和工作习惯，帮助他们尽可能快的进入角色，尽可能快的完成自我成长和进化，不要凡事大包大揽，觉得下属干不好就亲自上马，应该努力培养下属的工作能力，否则，你的产品和你的团队就永远作不大。此外，比较有意义的是，文中也提到了一些具体的措施用来加强团队成员的自我管理。

一个有强大战斗力的团队， 其重要特征在于:？团队成员都能在各自的岗位上积极充分的发挥自己的才华和能力， 在任何时候， 愿意为团队整体着想， 而不是只关注自己眼前的一亩三分地。 换句话说， 要让团队成员具备我们当年少小时也曾被反复灌输的"主人翁"意识。

那么， 要如何才能让团队成员觉得是在为自己作事， 把产品当作自己的产品？

首要的， 当然是产品取得收益后要给团队成员以相应的激励， 但除此之外， 还应该给予团队成员充分的自我成就感。 特别是， 当一个小公司处于创业初期时， 由于创业资金有限， 给的待遇普遍不高， 这种情况下， 如果能给团队成员提供充分自由的发展空间和自我成就感， 确实是公司留住人的一个非常重要的方法。

"信任与授权"， 这两个方面都是很依赖于决策者个人经验和眼光的东西， 只有在有了充分的人生阅历后， 才能真正作到: "信任值得信任的人， 授权给可以授权的人"。 因为， 并不是每一个人都值得信任， 也不是每一个人都值得授权， 能遇到一个这样的人， 是幸运， 能遇到一群这样的人， 就更是难为可贵了。

但是， 反过来说， 只有当一个领导者本身作人没有问题时， 他的身边才更有可能聚集这样一群值得信任和可以授权的人。 所以， 从这个意义上说， 团队招人， 团队留人， 团队培养人， 归根结底， 还是领导者个人作人的问题。 所谓"物以类聚， 人以群分"便是如此。

对于普通的团队成员而言， 在"信任与授权"的条件下， 更强调团队成员具备这样的基本素质:？良好的自我管理能力， 懂得合理规划自己的时间和精力。？

换句话说， 只有具备这种能力的成员， 才是值得信任和授权的， 也才是作事让人放心的。 如果你连今天该作什么事都不清楚， 都没有头绪， 你又怎么能指望团队把那些重要的事交给你作， 对你放权和信任呢？

虽然作IT的人， 都是一群在知识文化上算是比较高的人， 但是，？很多的时候， 我觉得IT圈的管理是很幼稚和不成熟的。

举个很小的例子: 在成都时， 经常能看到上午某饭店在一天的工作开始前把职工都集中在一起， 由工头介绍今天的工作安排， 偶尔甚至会喊喊口号， 振奋振奋精神， 激励激励斗志。 不要小看这样每天的一个晨会， 它至少会让团队成员的每一天， 都过得很有目标性， 都很明确今天自己该干什么， 也知道别人该干什么以及自己需要提供什么样的配合。？

而我们的IT团队管理呢？

我们往往在制定了一个所谓的开发里程碑后， 在中间开发的过程中， 就不再或很少进行有效率的质量和进度追踪， 导致了我们的开发效率极为低下， 开发人员的斗志极为萎靡。？

我们为什么不向传统行业学习学习？

如果团队成员缺乏自我管理能力， 我们就应该慢慢培养他们学会自我管理;？

如果团队成员不能合理安排自己的时间和精力， 我们就应该慢慢教会他们学会管理自己的时间和精力。

以我们开发组为例， 每天早晨， 都会有一个晨会， 在这个晨会上， 每个团队成员都要发言， 发言的内容主要是三项:

1。昨天完成了哪些工作;

2。今天准备完成哪些工作;

3。昨天的经验以及今天的工作需要哪些人配合(可选)。

作为团队领导者， 只关注我们作的结果， 不再关注我们具体作(写程序)的过程， 让我们每一个系统的实现者都在写代码这件事上有充分的自主权利， 可以自由发挥我们自己的想象力和创造力。 而过程， 由谁来管呢？ 由我们自己来管。？

上面提到的每天说的三个方面内容， 都是明确的自我管理内容， 在这个自我管理中， 非常强调两个字: "完成"。？

就是说， 一定要强调自己作的结果是怎么样的， 因为对于产品而言， 只关注结果， 所以， 无论你完成到哪个阶段， 你都要明确告知你已经完成到了哪个阶段， 完成了哪些内容。 而且， 把这些内容当着大家的面说出来后， 也是一种反向激励， 自己如果作得不好， 或者没有作完， 那就会觉得不好意思， 在第二天就会激励自己去更加努力。 这就是一种促使团队成员养成自我管理能力的很好的方式。

团队领导者， 有责任和义务帮助团队成员自己学会成长， 在不断的自我学习中， 养成良好的自我管理能力。

当团队中的大多数或相当一部分人具备了自我管理能力后， 团队的整体作战能力也必将跨上一个大台阶。 而一个缺乏自我管理能力， 时时事事都要由领导者自己去干， 自己去催促的团队， 其战斗力也必然是低下的， 斗志也必然不高。

一个由领导者事必躬亲的团队必然走不远， 而一个充分发挥了大多数人积极性的团队， 成功的机会必然更大。

作团队感悟(4)----分享的心态

前记：

我们作团队的目的是干什么？？

当然不仅仅是为了建立一种貌似和谐的公司内部关系， 也不是为了弄一个具有专业背景的"高科技"哥们组织， 请一定要记住， 我们从始至终的目的， 只有一个: 作产品， 作更好的产品， 同众多的竞争对手在市场上正面交锋， 除此之外的对作团队的定位， 都有可能让你走入歧途而失去本该追求的东西。

"凝聚力"和"战斗力"， 是决定一个团队可以作成一件事的两个最基本因素。 前文所述的"团队及团队成员的自我管理"， 意在增强团队的"战斗力"， 而本文所说的"分享"， 其意义不仅仅在于可以增强战斗力， 也同时可以增强凝聚力。 而凝聚力， 是一个团队可以持久存在的重要支撑。 有了持久的团队， 才会有持久的产品， 有了持久的产品， 才可能有时间和机会让你对产品精益求精， 而精益求精， 是成就一个成功产品所必须的东西。

分享的出发点， 首先是在于"想帮助别人"， 帮助那些可能与你遇到相同问题的人; 分享的出发点， 绝不应该是"炫耀"， 含有这种心态的分享， 是一种变了味的分享， 也是很难让其他人信服和坦然接受的分享。 既然这种分享难以接受， 那它也理所应当失去了分享原来应该有的意义和效果。

互联网， 从产生到发展到壮大， 靠的就是两样东西: 开放和分享。 也所以， 身处这个充满了开放和分享大环境下的我们自己， 又有什么理由不在团队内部务实的培养分享的心态， 分享的方法， 以及分享的习惯呢？

这是一篇有关"培养分享心态"的作团队感悟， 其核心思想是:？任何人， 不论他贫富贵贱， 都可以分享， 只要他愿意分享， 即使他是个技术新人， 也一定有值得分享的东西， 所谓"三人行， 必有吾师"。 作为团队， 应该努力培养每一个人都逐渐具备分享的心态， 要努力在团队内部形成一套可行的用于知识和经验分享的工作方法。 ？分享， 不仅仅包括着知识与经验， 有时， 甚至更多的， 也包括着利益分享。 一个作大事的人， 必须学会把利益分享出去。 对于员工， 我们希望他能以开放的心态更多地分享自己的知识和经验; 对于老板， 我们希望他能以开放的心态更多地分享自己的利益。？

不愿分享的老板， 永远只可能是一个小老板;？而愿意分享的老板， 其获得的东西要比他分享出去的东西要多得多。

不愿分享的团队一员， 永远只可能是一个按步就搬的工作机器;？而愿意分享的团队一员， 其获得的将不仅仅是高效率的协作关系以及优秀的工作成果， 还有现今社会已非常难得的"情义"二字。

分享， 不仅仅是领导者一个人的事， 也是普通的团队成员要学会的协作方法。

一个人， 并不是只有在自己富了之后才能够才可以分享， 愿意分享的心态， 来源于长久以来形成的处事观， 而不是一时冲动或者一时的急功近利。

一个人， 并不是在成为顶级技术高手之后才可以分享， 愿意分享的心态， 可以让你更快找出自己的短板， 也可以让你更快融入一个团队。

一个人， 可以分享的东西， 不仅仅只有金钱和利益， 甚至可以广而泛之包括你的时间， 你的精力， 以及你投入在事业上的感情。？

一个建议， 可以分享;一个创意， 可以分享;甚至， 一个BUG的修改过程， 也可以分享。

再实际一点的话:一包烟， 可以分享;？

一瓶酒， 可以分享;？

一顿饭， 可以分享。

这些， 虽然这些可能与团队无关， 但却能很好的帮助你与他人建立顺畅交流的基础环境。

虽然在某些人看来有点俗气， 但却是一个团队慢慢由攀比走向融洽， 由松散走向凝聚很实在可行的一条路。？

有的人， 自命清高， 说自己从来不搞吃饭喝酒这一套也照样可以作好工作， 是， 没错， 但要看你想作一个什么样的团队。

不与团队成员打成一片的领导者， 总让团队成员感觉中间隔了一层什么东西， 可能会被随时背叛， 也可能会被经常误会。

沟通， 便在于这些细节处。

要想降低沟通成本， 最主要的， 是让团队成员充分信任并理解你。

而要达到充分信任与理解， 分享， 是必须要作的一件事， 最起码， 你要学会分享自己的时间和精力， 当然， 这是在你完成自己工作的前提下。

当然， 作一个团队， 肯定不能整天分享吃分享喝。？

在其他的团队成员出现困难时， 你愿意把自己的时间和精力分享给他， 跟他讨论解决方法， 为他出出主意， 这也是另一种形式的分享， 也是比吃喝更重要的分享。 友谊的可贵， 体现在他人最需要的时候， 你是不是适时的伸出援手。

对于知识与经验的分享， 我按以下方式排序:1。 文档形式的分享， 是效果最差的分享;2。 IM， 邮件类的分享， 是效果次差的分享;3。 电话再次之;4。 面对面的交流， 效果较好;5。 带着他人一起作， 一起协同工作， 在具体实践中的分享， 是一种让人记忆最深刻， 效果也最好的分享。

分享， 不仅仅包括着知识与经验， 有时， 甚至更多的， 也包括着利益分享。 一个作大事的人， 必须学会把利益分享出去。

而作为老板或领导者， 愿意分享的心态就显得更加重要， 是直接影响团队稳定的大事。 当然， 这里的分享， 更多的是指利益的分享。？

牛根生有句很著名的话: "财聚人散， 财散人聚"。 当你散一散自己的钱财时， 大家会更愿意跟着你作事， 即使当你不如意时， 如果你之前一直坚持分享的心态， 你的团队也不会离开你， 因为， 他们相信，？只要你有吃的， 你就会分给他们一口。 这些看似简单的道理， 很多的领导者却不一定能作到。 所以， 从另一个方面说， 能遇到拥有良好分享心态的上司是一件幸事。

象之前文章提到的这三个人: 马云， 史玉柱， 牛根生， 每一个人都有很好的分享的心态， 他们愿意并切实执行着将自己的财富分享给团队成员， 所以， 他们的团队才有了最现实而有效的存在基础， 团队成员才一跟就是八年十年。

马云本人在阿里巴巴上市公司里的股份只有10%的股份， 他的18个创业伙伴同样分得了股份， 马云没有控股;

史玉柱， 虽然没有给团队核心更多的股份， 但他是通过给现金的方式变向分享， 与马云相比， 既跟团队分享了财富， 同时也掌握了公司的控制权， 不得不说是一种比较聪明的作法;

牛根生， 打小时就经常把家里的东西分享给自己的小伙伴， 而作蒙牛时， 又自述种种待遇不如副手。 拿工资时， 将工资分享出去; 作企业时， 将股份分享出去。 在我看来， 这不是炒作， 而是一种很务实的心态， 也是一种很有效的团队管理手段。

在充分自主快乐的作事和获取高额回报之间作选择时， 如果是二选一， 可能不少人会在两者徘徊， 有些人选择拥有更多自主权， 而有些人宁愿暂时委屈一下自己多挣点钱。 而如果， 我们给他提供了两者皆可的选择， 我觉得团队成员除非有不可抗力的因素才可能离开团队， 除此之外， 他会非常死心踏地的跟着你干。

人， 是一切。？

得人心者， 得天下。？

只要有了人， 你可以作任何事。？

只要得了人心， 你可以干成任何一件事。？

一个不愿意分享的领导者， 无论他说得再天花乱坠， 团队成员也会认为那是他自己的事业， 而不是我的， 团队成员也就不可能始终跟着他打天下。 分享， 不仅仅是一种姿态， 更是一种作大事的正确心态。

作团队感悟(5)----人性化反思

前记:

我们人人， 都希望生活和工作在一个充满人性化的公司氛围里， 可事与愿违， 即使是那些口口声声在招聘公告里对人性化再信誓旦旦的公司， 当你进入公司后， 你会发现， 所有关于人性化的宣传， 可能只是一种对企业的公关行为。 而能不能作到人性化， 以及作到什么程度的人性化， 则与你的想象大相径庭， 那么， 公司有错吗？？

这是一篇有关"人性化反思"的作团队感悟， 其核心思想是:？这个世界上， 公司毕竟不是家， 不存在所谓绝对人性化的公司， 千万不要把对公司的感情类化为对家庭的感情， 否则， 受伤的， 可能是你自己。 公司以赢利为第一目标， 为了利益的争夺， 常会"有必要地"牺牲"小我"， 这是一种常态。 而另一方面， 如果你想在公司享受更多的"人性化"， 最重要的方法不是向老板哀求和索取， 而是用自己的业绩来说话， 业绩好了， 赢利多了， 再提这些要求或者建议， 就更容易实现了。

引入正题----

"人性化"这个词， 被诸多大公司在自己的招聘公告和公司文化中一再宣扬， 而这一点， 也一度成为诸多刚毕业的学生选择公司的一个重要考量。？

但是， 反观这些宣称人性化的公司，？其日常运作中是不是真的作到了恰当好处的人性化？？有没有真心作过人性化？？有没有滥用了人性化？

作为一个 公司， 其首要任务当然是取得赢利， 上对得起天地， 下对得起员工; 作为一个项目团队， 其首要任务当然是要按时按质作出产品， 上对得起公司， 下对得起团队。 没有赢利或没有希望取得赢利的团队， 无论谈什么样的管理和人性化， 都是不能长久的， 赢利不仅是对团队本身水平的认定， 也是团队成员本身自信心建立，巩固并坚守的最重要因素。

但是， 是不是为了赢利， 我们就可以忽略其它所有的一切？？是不是， 当一个成员已经生病感冒时， 我们还要强行让他坚守岗位？？是不是， 当一个成员确实已经身疲力竭时， 我们还要逼着他坚守到下班的最后一秒？？是不是， 当一个成员回家完婚时， 我们所有的人因为所谓的工作太忙， 而连打一个电话的时间都不抽出来？？

我不是让大家放纵自己， 我只是想说， 其实， 很多的时候， 压力是我们自己给自己的， 除非非常非常紧迫， 无法推迟哪怕一分一秒， 大多数情况下， 我觉得， 团队领导者在这个时候， 就要勇敢担当起项目延期的风险， 而让你的团队成员尽可能放松一下。？

我们， 要力争作到急在平时， 而不是只急在这一刻。？

把功夫用到平时， 平时抓紧时间， 抓紧效率， 即使偶尔出现这样的伤病减员， 其开发速度与质量也不会受太大影响。 千万不要作那种平时松松散散， 里程碑快到来时再拼命加班补漏之类的蠢事。

人性化是什么？？仅仅是口号吗？？人性化与规范的管理是一对矛盾体吗？？是不是因为项目压力太大， 我们就无法作到人性化了？

说句让很多人受伤的话， 所有对人性化存在上述疑惑的人， 你们都从不曾认真关爱过自己的团队成员。 在我看来， 人性化， 最本质的， 是对作为团队普通一员的人的最本真的关怀，？只要你真心关怀着自己的团队成员， 而不是因为团队或项目所需去虚伪的假装关怀着， 人性化， 便时时处处存在， 也时时处处的彰现。

没错， 我们每一个现代人， 工作压力都很大， 自私的人， 会只关心自己受到的压力， 而从不曾想着团队成员也面临相同的压力， 说不定， 把你放在他那个位置， 你的压力会更大。 一个团队的精神所在， 其意义， 就在于， 在这种如此之大的工作压力之下， 你还能抽出时间来关怀关怀自己身边的兄弟， 跟他们聊聊天， 谈谈心， 说说玩笑。？

我们都希望， 在上了战场后， 有可以互相依靠着可以放在自己背后， 彼此互相挡子弹的战友， 但这种可以舍命付出的情谊， 不是一时半会就能造就的， 它来源于团队生活中的点点滴滴积累:？

在无数个关键的时刻， 大家都能立场一致的向着共同的目标发起冲锋，？有人受伤了， 其他兄弟要背上他，？有人落后了， 其他兄弟要拉一把。？

我们不能作"士兵突击"里的"成才"， 在关键时刻， 抛下战友， 独自冲向胜利的终点， 如果那样， 那个终点代表的就不是胜利; 我们要作许三多， 即使在关乎自己个人命运选择的重大时刻， 也能关照自己的战友， 努力一起向前。

真心关怀你的团队成员: 关怀他在工作遇到的困难， 关怀他对项目的疑惑， 甚至， 关怀他生活中遇到的困难， 人性化的诸多细节就会慢慢积累出来。 而真心帮助他解决工作中遇到的困难， 是最大的人性化。 当你用心去对待别人时， 他们也一定会比以前更加认真对待自己的工作， 也会更加珍惜跟你在一起打拼的机会， 你可以让一个人去独当一面， 但你不能真的让他以为自己无所依靠， 至少， 要让他知道， 他的背后， 还有你。

作为团队核心和团队领导者， 不要轻易将自己的不好的情绪传递给团队成员， 一时的不克制， 会带来更多人更长时间的不愉快， 你一个人爽了， 而其他所有人都蔫了。？

"永远把苦难留在心里， 把微笑留给团队"， 一点点尝试， 你就可以作到。

真心对待你的团队成员， 让他们每一天都能快乐的工作。 而快乐工作的本身， 就是一个团队最好的润滑剂和推进剂。 好好想想， 如何从一些小的细节开始， 让你的团队成员每天都能快乐起来。

小结一下我的团队观

1。 我为什么这么重视团队建设？

这个理由是个人应该都知道吧， 一句话: 作一份事业， 人最重要。 找对了人， 凝聚住了优秀的人， 你的事业就会更容易成功， 更容易取得持久， 较大的成功。

作一件事， 总是有成功， 有失败。 所以， 我想首先让自己弄明白， 这次的成功是因为什么， 这次的失败是因为什么。 而不是稀里糊涂向前走， 把成功或失败都用运气来总结。

很多人， 一时取得了成功， 但很可能他自己都没弄明白他为什么这次就成功了! 这样的状态， 进而导致他错误的复制过去的所谓成功的经验， 但往往却莫名其妙的失败了。 最终， 他们自己都迷茫了。 而我， 不想这样。

如果我成功了， 我们成功了， 我就要非常清楚我们是因为什么成功了， 我们有哪些值得总结和提炼的东西可以跟同事， 同行来分享， 进而有可能帮助更多的人取得成功。 这也正是我写博， 写这一系列文章的最主要原因: 我要记录我们自己的成长历程， 我要记录我们自己成功或失败的历程。 如果我成功了， 我要知道原因; 如果我失败了， 我更要知道原因。 我们在网游界的这几年， 有哪些人真正深入思考过自己成功或失败的原因是什么？ 我们不能再这样盲目下去了。

我对团队的理解， 大体经历了这样几个阶段: 对团队协作的完全无知--->对团队的过度依赖---->渐渐成熟的团队心态。 前面两条路， 都是很极端的路: 要么是根本不理解不执行也不信任团队协作， 要么就是过度依赖团队没有了自我， 而到了现在， 我才慢慢明白了， 尽管团队很重要， 但作为一个有志带领一个团队的人来说， 首要的， 还是作好自己， 让自己不要先倒下去， 要让自己变得坚强和厚重起来， 不能过度依赖团队， 也不能过度依赖他人， 对于团队涉及的方方面面， 要有自己的主张和判断， 不懂就要去学习， 去提高， 但不可自己一点都不学习而完全寄希望于团队他人可以完全帮你完成。

要让团队里的成员明白， 很多的事， 我们不去作， 并不是因为我们不会作， 而是因为我们没有精力和时间去作， 这样， 其他人可能因为独门技艺而产生的骄傲情绪才会有所收敛， 也才让他们更加明白: 团队并不会因为缺少你一个就运转不下去了。 当他们明白这些道理的时候， 再把事情放出去让他去作， 他会明白， 这不仅仅是完成一份工作， 更是出于我的信任: 尽管我自己已经能作好， 但我没时间和精力去作， 我也相信你能作好， 所以交给你去作。

2。 博文中所说的道理是从书上看来的， 还是自己实践得来的？

当然是我从自己的实践中不断体会总结得来的， 其中很多好的方面， 是我们团队已经具备了的， 也有一部分是我们目前这个团队需要再进一步完善的， 但我们已经有了自我学习和提高的能力， 已经可以自我进化。

我是一个实践者， 最反对的就是教条， 形式主义， 以及没有任何实践经验的人在那里大谈理论。 我认为: 实践永远重要于理论， 也永远先于理论。 对于没有任何实践经验的人， 跟我谈什么团队管理或团队协作， 我是懒得搭理的， 也是懒得争辩的。

我的观点是: 无论你理论学习得再好， 基于你为人本质的进入团队之后该走的路， 你都要一一走过， 你不可能跳跃， 即使有跳跃， 你早晚还是要折反回来， 补回来， 把它再走一次(也就是说， 你的人品决定了你走的路， 当然， 人品可以进化， 但， 比较难)。 所以， 表面上， 可能你跟我在这里说的都是同样的一句话， 但是， 对于实践过的我和没有实践过的你， 看这同样一句话时内心深处最真实的体验是完全不一样的。 而且， 有很多很多的东西， 只可意会不可言传， 文章再好， 有些东西还是表达不出来的， 所以， 有的地方只能点到即止， 但我自己看到那些文字时， 我以及所有有过实践经验的人会更加明白文字之后的意思。

我之所以愿意作这样的记录和总结， 是因为我要让自己和自己能影响到的人清楚: 我们为什么成功了， 为什么失败了。

但是， 另一点， 当我开始关注其他团队的成长历程时， 我才惊喜的发现， 原来， 大家走过的道路竟然是如此相似， 特别是马云团队的成长历程以及马云对团队建设的理解， 与我们真是实在太像了， 所以， 我也才有了: 原来作得成功的团队都是如此相像的。

但， 正如我所说: 团队的成功， 需要靠产品的成功和赢利来证明以及生存。 所以， 我们同样需要作成功一个产品以证明我们自己。

3。 在现实中， 你所说的团队太难作出来了？

没错， 如果全要达到我文中所说的这种状态， 是很困难很困难的。 困难的原因很多很多， 有人的因素， 有公司的因素， 有老大的因素， 也有产业大环境的因素， 甚至有生活所在的城市的因素。

但是， 我想说明一点: 无论在什么样的条件下， 你都有选择的权利。 什么选择的权利？ 那就是选择积极面对还是消极等待的权利， 选择是乐观向上还是得过且过的权利， 选择是知难而上还是临阵退缩的权利。

在我前面所列出的各项内容"信念， 凡人， 信任， 自我管理， 分享， 人性化"等诸多内容中， 其中的很多内容， 既是对老板们说的， 也是对团队成员说的; 既是对别人说的， 也是对我自己说的。 如果你是一个老板， 在这些内容里， 有属于你的内容; 而同样， 如果你是员工， 这些内容里当然也有需要你作的工作。 象"信念"这个玩意， 老板没有了这个， 那公司和团队都作不好， 对于老板而言， 这个玩意比团队普通成员更加需要; 而象"凡人"心态这个玩意， 就更加强调团队普通成员自己要树立这样的心态， 如果团队成员树立不了， 那老板就得旗帜鲜明的宣扬这一点， 让它人尽皆知; 而象"分享与自我管理"等内容， 则是老板和团队成员都要学会的。

所以， 当你以一个积极的心态去适应一个团队， 去融合一个团队， 或者去带领一个团队时， 你总会在这些内容里发现适合自己去作的事， 最起码的， 作为职业人而言， 我们要学会自我管理吧？ 学会了自我管理， 将来无论你到了哪家公司， 哪家公司都会欢迎你。 因为你作事让人省心， 也让人放心。 而这个能力， 就是跨公司， 跨行业的能力， 远比什么会写C++程序的普通技术能力重要多了。

传统的高校教育， 只教会了我们识字， 背英语单词以及写几行程序代码， 但没有教会我们拥有一些可以跨公司， 跨行业或者跨年龄段的能力。 而这些能力， 从哪里开始学？ 最好的方式， 就是从一步步的学会"自我管理"开始了。 为自己选个目标， 为自己的每一天制定一些具体可执行可完成的工作内容， 认真作好每一天。

4。 既然团队观念这么重要， 个人与团队之间到底是一个什么样的关系？

大大出乎你的意料的是， 我想说的答案是: 个人信念更加重要。

我不知道该如何一针见血的说明这个观点， 只大致描述一下我的理由。

我们知道， 现实永远比我们想象的残酷。 很多的时候， 我们遇到的团队， 其情况可能并不如想象中那么好， 我们也可能没那么运气就碰到一群对的人能在一起作一件很好的事。 绝大多数的时候， 我们可能都不得不反复与人协商， 妥协或者争论， 以求一起把事作起来。

作成一件事， 真的很难。

所以， 在这种各个方面可能都不太让人满意的条件下， 只有我们自己更加主动， 更加积极， 更加向上， 我们才有可能去赢得进步， 赢得胜利。 作为一个有志向的团队领导者， 你要学会忍受孤独， 别指望有人能一直伴你左右陪你厮杀， 很多的事情， 需要你一个人单独面对和承受。 所以， 我说， 个人信念更加重要。

作好自己， 我们需要的只是把握好自己这么一个人， 而且， 完全可控， 所以， 把自己这个人作好了才是前提; 而要作一个好团队， 受制的因素太多， 而且很多因素根本不被你控制， 所以， 作一个好团队， 在一定程度上， 还要看运气。

我说个人信念重要， 并不是说团队信念不重要， 而是从一个务实的角度出发， 首先，？ 我们要把握住自己可控的部分， 进而再去争取那些不可控的需要一步步作的东西。

别把希望完全寄托在你的团队身上， 团队能帮你， 团队能撑你， 当然更好， 但是， 在有的时候， 你也要同时作好打算， 如果团队不支持你， 你该如何作？ 你要学会独立成长， 要有成熟心态， 不能象吃奶的孩子离不开娘一样离不开团队， 要在心理上断奶。

你要相信， 团队信任并愿意跟随你， 绝不是因为你依赖他们， 而是因为你可以给他们带来更加美好的明天和更加美好的生活， 他们相信你有这个能力(务实)， 有这个勇气(敢拼)， 也有这个度量(愿意分享)。

衷心希望每一个有志于作事的人， 能以更加积极的心态去面对自己的工作， 去面对自己的团队， 不断的总结和提高， 以务实的心态去对待自己的工作和伙伴。

执行比理念更重要

当我一步步深入的研究如何作游戏， 如何降低新手入门门槛， 如何更好促进玩家互动， 如何更有效的作游戏内容促销时， 我才感觉到， 原来当你用心去作一件事时， 其实， 这件事并不难， 一步步， 就可以这样走过来。

现在的我， 比起以前没怎么玩过网游的自己， 对网游有了更多的感觉， 很实际很踏实的感觉， 只要按这样的状态作下去， 我相信以后还会碰撞出更多的火花， 还会有更多精彩的点子出现。

而另一方面， 让我感受同样深刻的是: 其实， 有想法本身， 并不是一件难事， 当你全身心投入去思考时， 想法必定会有的。 关键的关键， 在于， 这些想法能不能以很快的速度实现出来， 以比较好的形式表现出来形成实际的东西。

在研究史玉柱和巨人时，？ 我们发现， 他的很多想法与我们是不谋而合的， 甚至在一些具体的游戏内容设定上都如出一辙， 我们能想到的， 他也同样想到了， 但是， 他与我们的不同点在于: 他已经把东西作出来了， 而我们， 还处于正在执行阶段， 还是慢了半拍， 这样是不行的， 效率要进一步提高。

从这样反复的对比中， 我自然而然地得出了这样的结论: 有理念， 并不难， 别自以为自己多聪明， 因为大家都不是傻子， 只要专心去作同一件事，？ 大家的很多想法肯定都是相似的， 但是， 能不能作出来， 能以什么样的质量和速度作出来， 那就是真正考验各个团队真实能力的时候了。

我们的想法， 已经足够多， 现在已经不是只谈想法的时候， 要进一步提高速度作出东西来。

我们总在说执行力是团队生存的首要力量，？ 但是，？ 要如何才能更好的提高执行力？

目前国内的网游研发， 在一定程度上， 都还处于比较混乱无序的状态， 因为大家的行业经验都还太嫩。 即使是以前作过单机的游戏公司， 他们在面对网络游戏这样面对网络的游戏研发后， 其原有的研发方式有很多已经不适应这种新的模式。 关于这一点， 只要看看目前国内成功的这几家网游公司没有一家是原来的单机游戏公司就明白了， 在这个时候， 单机游戏公司的惯性研发思维反而阻碍其自身的发展， 当然， 这是另一个话题， 另外开篇讨论。

要提高执行力， 第一步， 还是要培养整体的团队士气， 要鼓励彪悍和顽强的工作作风， 让每个人都能对自己负责的那一块负责到底， 对自己这一块的最终效果负责， 所谓的最终效果， 就是玩家看到的那个最终版本， 玩家的最终体验。

彪悍的作风， 仅仅是培养一种风气， 一种雷厉风行， 说干就干的风气。 但是， 光是蛮干也是不行的。 我们需要在作事的机制上不断寻找更优化的方案来避免错误， 提高效率。 很多的时候， 我们看到一个人从早忙到晚， 累得要死， 但就是不出工作成果，？ 为什么？ 这是因为他的工作机制没有理顺， 理所当然地， 就没有工作效率， 也就无所谓工作质量了。

在网游研发这样强调高度协同的开发模式下， 一些看似多余的流程化， 有利于我们在交流环节上尽可能的减少沟通时间和沟通成本。 比如， 有一些这样的简单规则可以遵守:

1。 当遇到问题时， 尽可能找相关责任人马上当面核实， 当面确认， 不要IM， 更不要邮件， 那样只会越扯越扯不清， 最差的方式也得用电话， 确认后， 最好有纸面的东西形成文档记录下来， 且这份文档人人可查阅;

2。 对于一些容易犯且经常犯的错误， 一定要想办法在流程上规范， 在文档上健全， 在健壮性上保障， 尽可能避免反复出现同类错误， 千万不能对这种情况视而不见， 否则， 久而久之， 就会降低整个团队对精益求精的追求;

3。 尽可能减少每个人"仅仅记在心里的默认规则"， 因这种规则只有当事人自己清楚， 其他人都不清楚， 这是非常危险的。 要避免这种风险， 一是减少这种规则， 如果实在有必要要这样的规则， 那就尽可能把这种规则文档化， 文档要作得言简意赅， 直接命中要点， 不要繁琐， 不要罗索;

4。 其实， 在协作上， 有很多需要注意的细节， 但那些东西需要你一点一滴去积累去体验去改进， 而有一条最最基本的规则你要记住: 要有为他人服务的思想。 你要记住， 你作的任何东西， 可能别人都是要看的， 都是要接手的， 都是要传阅的， 那当别人拿到这份东西时， 你要衡量一下， 根据你已有的已经作出来的这些规则和说明， 别人是不是能很容易就看懂。

提高执行力， 最优的方式当然还是靠大家都能积极主动的去作， 而不是靠他人的监督， 催促去作。 我始终坚信， 无论你所面对的公司是什么样的， 对于你本人， 只要你始终在积极主动的作事， 对于你自己只有益而无害， 这样， 一方面， 可以提高你所在公司的成功机率， 另一方面， 也会提高你本人的能力， 有利于你的自我发展。

提高执行力， 从自我作起。 不要单纯的作重复的事， 还要适时的考虑他人， 考虑全局。

作团队感悟(6)----允许犯错

前记：

一个人，无论是作项目还是作人，总免不了会犯这样那样的错误，有了错误，有了改正，才会有成长和提升。我们通常说的“经验”，其中很大一部分，就是你成长过程中积累下来的因犯错而带来的教训。

作为团队成员，当然，在犯了错之后，一定要总结教训，否则，这个错误就是真的成了对公司资源和自己时间的浪费；而作为团队管理者，应该在项目允许的范围内，适度地给予团队成员一定的“容错成长空间”，让他们通过碰壁更快的成长起来。学习，有很多种形式，“在错误中的学习”，是令人印象最深刻也是最刻骨铭心的。

这是一篇有关“允许犯错”的作团队感悟，其核心思想是想说明：在具体的项目实践中，你我都不得不务实的面对团队现状，没有完美的团队，也没有完美的项目，要想让团队成员每个人都真正进入可以不断自我提高的良性工作循环中，就要给他们充分的锻炼机会，这些机会里面，就包括了允许他们碰壁和犯错。对错误的容忍，不代表我们对产品质量的要求降低了，而是团队成长的一条必经之路，要正视它，把它向好的方向引导。

"允许犯错"， 其中的"错"指的是不影响团队整体战略方向， 不会导致团队灭亡的"错"， 指的是实施细节上的一些小错误， 它可能会给团队和产品造成时间， 资金或人才方面的一时损失， 但不会影响团队和产品发展的大方向。

"允许犯错"， 仅仅是一种整体的团队心态， 不代表"纵容错误"， 它更多的， 是想向团队成员展示一种包容的姿态， 会让团队成员更有安全感， 也会让整个团队更有凝聚力。

在"允许犯错"的背后， 我们还要作很多项"错前"和"错后"准备工作， 比如: 在错前， 预估此错可能造成的损失， 提前作好预案; 错后， 如何正确引导团队成员认识， 总结并提高， 这些， 才是一种务实的工作和方法。？

没有准备预案的"允许犯错"， 是一种纵容; 而在错后没有"总结和提高"的"允许犯错"， 是一种盲目的信任， 错误的价值就真的成为了零或负数。

既然， "犯错"会给团队和产品带来损失， 那么为什么还被我们"允许"呢？？

因为， 对于一个想建得很久， 想作得很久的团队而言， 在除了产品之外， 我们更关注的是"人"以及"人的成长"。 任何产品的成功或赢利， 离开了"人"( 有素质的"人" )， 都不可能创造出来。？

但是， 在很多情况下， 我们没有那么幸运， 从一开始就找到在各方面都合适都优秀的人， 所以， 我们要一点一滴的把普通人培养出来。 而培养的方法， 就是给他们充分的自主发展机会， 在他们成长的过程中， 就必定会犯错。

同时还有另一个问题， 很多的时候， 不同的人， 犯一个相同的错误， 其所受的处罚可能是不一样的。？为什么？？

其中一个很重要的原因是:？他们的心态不一样， 区别在于他们是不是真的用心在作这件事。？

只要你是在用心在作这件事， 犯了一点小错误， 团队不会计较， 因为团队相信只要你用心去作， 你会不断改进自己的工作方法和工作流程， 从而尽可能避免少出现同类错误; 但如果你在作这件事时三心二意， 根本没放在心上， 甚至在这种状态下屡次犯相同的错误， 那我想， 再好的团队也不会允许你这样继续下去。

我所说的"允许犯错"， 不是简单地指， 你犯了错后， 团队不给你处罚， 我更多的是指: 我们的团队， 应该具备培养人的心态， 把这个错误当作是你走向成熟的必经过程， 淡然处之。 而不是， 在你犯了错后， 虽然不对你进行物质上的处罚， 但不给你好脸色， 在精神上处罚你， 这并不是我指的正确的"允许犯错"的态度， 因为， 在大多数时候，？ "精神处罚"比"物质处罚"要来得更残酷， 也更没有人情味。

我们说， 一个团队很有人情味， 其含义并不简单地指: 在生病时多关心一下， 在困难时帮一把。？"允许犯错"， 在我看来， 是最大的人情味。 作好了这一点， 会让团队成员倍增安全感， 会让他觉得: 只要自己真心为产品， 用心作事， 就一定不会有问题， 即使犯了错， 也没有问题。

"允许犯错"， 也绝不是表示一团和气， 我前面说了， 它是一种态度， 我们认为这是每个人成长过程中所必须经历的， 因此才有了宽容心态， 也因此， 才不会责怪你， 不会给你过重的处罚。？

站在团队的角度， 首先， 其他人要宽容一点， 我们应该思考， 如何帮助他明白这次错误的原因， 并帮助他建立一套有效的方法来避免同类错误再现。

但是， 站在犯错者你的角度， 这些心态， 都是"别人"的心态， 而不是你自己的心态， 如果别人没有， 你也不能奢求。 在你犯错时， 你首先不应该期待别人有"允许你犯错"的心态， 你首先需要作的是: 弥补错误造成的损失， 并思考如何避免此类错误并切实予以预防， 这才是一种积极健康的心态。 如果你在犯错时， 总是期望着别人能有"允许犯错"的心态， 那只能在你与团队之间制造更多的不信任， 直至最终的分手。？

"允许犯错"， 不仅仅是一种理念， 你还需要想办法把这种态度以适当的方式在团队成员犯错的时候表现出来， 每一个有自尊的开发者， 都会因自己的错误而羞愧， 你要学会将这种理念转化成适度的安慰， 否则， 你的这种理念， 团队成员也是无法感受到的， 那效果就会大打折扣。

"允许犯错"， 对于一个团队而言， 丢掉的可能是一时的严格要求， 却可能换来团队成员更加努力的付出和更加积极的心态。？

谈谈七、八十年代的人学毛泽东

毛泽东， 留给我们七十年代末， 八十年代初人的印象， 远没有我们的父辈祖辈来得深刻， 我们更多的是从文献， 从媒体， 从野史小说里了解他， 当然， 我们也同样多的从初中， 高中， 大学的各种政治课本里了解了他。

也许， 是年少时被强行灌输了太多的他的理论和思想， 以致于我们这一代人， 在面对他的这些思想和理论时， 会天生的产生反感， 甚至厌恶， 不想谈及。 与他的思想相比， 我们甚至会联想到更多我们父辈在文革时受的迫害及苦难， 这样的痛楚要来得更具体， 更深刻。

以前， 我根本无法理解， 为什么中国这么多的民营企业家这么喜欢研究毛泽东？ 难道仅仅是因为他们的年龄比较大， 比较怀旧？ 还是， 仅仅同样是因为他们文化不怎么高， 没见过真正的所谓高人？

而， 当我不带任何政治抱负和热情， 也不带任何第三方的愤慨去重新关注他的思想时， 我才渐渐明白了他理论中的一些经典之处。 但是， 我要说的是， 他的经典， 不仅仅在于总结了这些理论， 更在于他把这些理论运用得炉火纯青。 放在战争年代， 他是一代英雄; 而如果放在创业年代， 我相信， 他也会具备相当的"职业水准"。

我只在这篇文章里针对他的两点思想说说自己的感受:

1。 农村包围城市;

2。 将支部建在连队上。

"农村包围城市"， 是他当初带兵打仗时总结的一个战略。 而这一条， 放在如今的商业社会， 也仍然有效。 但是， 名词可能已经不是这个名词， 而换成了"蓝海理论"或"长尾理论"之类的东西。 在我看来， 无论这个词的叫法如何改变， 它的本质从来没有变过: 避开单一资源相对优越的热点人群或热点地区， 寻求更广大更普通更上规模的目标人群和目标地区。

作理论的人， 喜欢隔三差五的弄一些新鲜词汇出来糊弄人， 其实， 说到底， 这些思想是早就有了的， 即使在毛之前， 也是已经有了的， 只有那些没有沉淀， 没有任何分辨能力的人才会被人家的新理论忽悠着一直牵着鼻子走， 从而迷失了自己的方向。

"将支部建在连队上"， 这个想法的重点在于: 支部书记这样的人。 连队管理层的组织架构是: 连长+书记。 前者管业务: 打仗; 后者管思想: 抓团结， 鼓士气。 上头的任何政策， 任何战略， 其最终， 都是通过连队这样的基层单位予以实施。 而相应的， 在公司里， 上层的任何策略也是通过每一个单独的研发团队来逐一实施。

我认为， 一个好的稳定的团队， 也应该具备类似的架构: 有带头搞业务的， 也有搞思想工作的。 指望一个人既能业务优秀， 又能很好的作别人的思想工作， 在多数情况下， 是不太容易的事情。 但是， 也不见得非要在结构上去配齐这样两个人， 如果我们的团队只有一个带头作业务的， 那么， 其他的团队成员， 应该协助他完成"作思想"这一块的工作。 团队的整体士气， 是在一点一滴中积累的， 这些琐碎的工作， 需要我们主动去摆平。

润滑剂的作用， 不可小视。

让你的团队与你一起成长

一个人成长了，最多只能算作是一个榜样和标杆，而真正要作成一件事，就需要团队里的每个成员都能有所成长和进步。团队中每一个人的水平都提高了，那产品的质量和研发速度自然就获得了保障。这样的循环，才是一个良性的循环，也才是一个逐渐派生出新意，派生出趣味和创意的开发方式，在这种开发方式里，团队的成长将和产品的成功获得同步。

与产品的成功相比较，团队的成长，显得更为重要，因为：我们所要作的产品可能并不止这一款，只有团队成长了，我们才可能作出一系列许许多多成功的后继产品来。而如果团队成长缓慢，甚至跟不上产品研发的进度，那这样的团队，不仅每个成员工作不开心，也难以有更好的工作效率。

我们的开发，基本上是一个完全自主的开发，是一种自我管理的开发方式。正是在这样的一种大环境下，我才有了更多的自由想法，针对于我们自己的产品研发方面的。所以，也就有了我把自己掌握的资源分享出去，散播出去的想法，而这种散播，我希望达到的效果正是：团队中的每一个人都能获得能力和知识面以及经验的提升。

首先，来总结一下我手里的资源，它们主要包括：自己的时间、精力和经验，新系统的各项需求，产品研发过程中的各种文档，测试过程中暴露出来的BUG。与其说这是我的资源，还不如说是我的工作所涉及到的诸多内容。

我坚信，中国网游的未来发展趋势，必然是一种策划与技术不断融合的趋势：当策划的，要了解技术，甚至本身就是作技术出身；而作技术的，也要了解游戏，熟悉各种常规系统的设计方案。就象现在的暴雪团队一样：作程序的本身就是资深玩家，而作游戏内容设计的又基本都了解技术。而反观这两个方面，当策划的要了解技术，这个难度绝对要远远大于作技术的要了解游戏。

现在，我把这个问题扩大开去，我想让团队中的每个人都逐渐了解点技术方面的东西，我将尽我所能将我所了解而他们又能明白的东西传授给他们，这个“他们”，包括了：策划，QC，甚至是我的技术搭档：客户端的同事。

那，如何作才能让团队中的每一个人都能一起成长，都能逐渐了解点技术方面的东西呢？

针对于不同的人，我准备是从不同方面加以引导：

1。针对于QC，我会试着让QC同事去自己改一些自己报上来的BUG。在这个过程中，QC的同事由于要熟悉代码逻辑，当他们看不懂的时候就必然会过来问我，这时，我再将这些细节的逻辑和设计的思想与框架讲解给他们。其实，如果是我自己改这个BUG，时间肯定会比让QC同事来改要快得多，但是，这个问题，我们要放在一个更高的层面来看，我的目的，不是要改掉这个BUG，我的目的，是想通过这种比较直观的方式让QC同事对代码流程，对关键数据结构能有个比较清晰和深刻的理解，这样不仅加强了他们本身的技术修养，同时也进一步保证了产品质量。而我们因此所要付出一点小代价是：可能我们要因为培养QC的这种感觉而多花费一些自己的时间和精力，但是，我认为这是值得的。

2。针对于客户端同事，我会试着让客户端同事去作一些服务端的逻辑，这其中，包括比较复杂的底层引擎控制和数据库的逻辑。与QC同事相比较，客户端同事的培养要简单一点，毕竟已经有了一定的技术功底，所以，我只要解释清楚服务器的关键逻辑，常犯错误就行了。更深一步的，我要引导客户端同事逐渐站在服务器的角度去思考问题，学会思考关系全局的关键数据结构如何去设计。我个人认为，客户端与服务器，在逻辑设计方面，最大的不同点在于：客户端所看到的，只是主角自己，而服务器的逻辑时时刻刻都要盯着全部角色和全部怪物，服务器是一种全局视角，而客户端的视角就是一个相对独立的视角。视角的狭小，造成了在数据结构设计上的一种思维惯性，他们不太容易站在一个相对比较高的角度去设计一个好的数据结构，而我需要作的，正是把这种经验和教训传给他们。

3。针对于策划同事，我不得不说，这是最难走的一条路，但又是必须要走的一条路。从目前国内网游的研发方式来看，真正懂得技术的策划很少很少，但从项目研发的可控、速度和玩法方面考虑，策划了解相应的技术后，会更容易换个角度思考问题，当程序提出某个玩法作起来比较复杂时，懂技术的策划就要很容易的变换思考的角度去重新设计玩法，以求尽最快速度将东西作出来。我们不能总指望着在策划案出来后，由程序进行评审时和制作前再建议策划来逐个修改策划案，而事实也一再证明，策划案没有真正的付诸实施之前，连程序自己可能都暂时无法评估某个玩法制作起来的难度。由此看来，“策划懂技术“所带来的优势更为明显：这会大大降低产品本身的研发风险。试想一下，如果有一天，你与某个公司的某款产品正面碰撞，短兵相接，那这个优势将给你更大的取胜把握。

这必然是一个长期过程，可能因项目压力在不同时间而不同也会间歇性的采用，而不会一直都有时间这么作，但我想，有了这种想法后，只要坚持作，至少团队成长的目标是明确的，而因此获得提升的团队成员也会对自己的项目更有信心，产品的成功与团队的成长就会进入逐渐同步的良性循环。

作团队感悟(7)----如何处理争论

前记：

几乎每天，在项目中，我们都要不断的与队友沟通设计方法，编码方式，在论坛中，也经常会看到大家对于一个技术点的无休止的争论。

有人说，“真理越辩越明”，这句话，没错。但是，你自己要弄明白，你是为了弄清楚一个真理的合理性，还是为了作成功一款产品，带成功一个团队？

这是一篇有关“如何处理争论”的作团队作产品感悟，其核心思想是：我们一切争论的目的，其出发点，不能是仅仅为了证明观点或者技术的对与错，我们的目的，应该是如何作对项目更有利，这种“有利”表现在高效的出版本，稳定的运营，快速的修改和维护。观点或技术的对与错，在大多数情况下，其实，于产品，并没多大的实际好处，我们需要的，是团队成员在不断实践的过程中养成了一些好的思维习惯，好的编码习惯以及好的设计习惯，而这些习惯，更多情况下，需要依赖团队成员自己的自我学习和成长，并不是一两句争论可以解决的，我们应该更加务实一点，让团队成员在具体的实作中成长，而不要过多的指望靠争论来帮助他们成长。“停止争论，马上实作”，在实作中改进和提高，这是我们处理争论最务实的办法。

我们这些作技术的，有一个说好也好，说不好也很不好的习惯，那就是，大都喜欢在某个技术点的讨论中，非要一争高下不可。比如：常见的WIN平台和*NIX平台优劣的争论；C/C++与JAVA或DELPHI的争论；各种设计模式的争论；各种第三方库的争论，凡此种种，不一而足。人人都想通过争论证明，自己用的，就是好的，其他人用的，就是不好的。

呃，这样作，有意义吗？我们作技术的目的，是干什么？就是为了争个高低，炫耀一下吗？即使让你炫耀赢了，对你自己对他人，又有多大的好处呢？即使有好处，你也只不过是过了一下瘾而已，而坏处却是，让你变得更加不务实，更加忘记技术的目的了。

作为一个身在产品中的人，我们作技术，从始至终的目的，都只有一个，那就是：充分利用自己的技术和技能，为产品作贡献，要始终围绕着“又快又好出产品”这个唯一的目标进行。

你在外面跟人家争得春风得意，但在自己的项目中，由于使用了过于复杂的架构，让项目在维护和修改中付出了大量本不该花费的时间资源，即使你在争论中赢了，你在自己的项目中，也是一个彻底的输者。

而自己的项目和产品，往小的说，是你立足公司的根本，往大的说，也是你可以在行业立足的根本，万事，以业绩说话，不要以为你掌握了一些书本知识，一些软工理论，跟大家混了个脸熟，你就是业内资深人士，就会到处受人膜拜了，如果你的项目作得不行，你再怎么吹，这个泡沫也早晚会破掉。

所以，停止争论吧，马上，现在，开始务实的作好自己每天的工作，从每一小处的细节入手，把你的工作效率作得更高，工作质量作得更好，一切从项目和团队的实际出发来选择技术方案，不要人家说什么好你就一定要用人家说的方案，你便是你，你的项目便是你的项目，这就象谈恋爱，那些在旁边给你出谋划策的人，永远没有你更了解你自己的心上人和你自己的真实感觉，他们出的主意，也多半都是馊主意。

从这个角度说，国内技术社区的作用，在我看来，已经被相当扭曲了，讨论问题的，要么就是问题太小白了，只要一GOOGLE就可以出来，要么就是不断地在谈论“大道理”，每天，在坛子里吹得不亦乐乎，很多人可能并不知道，他自己可能都没有在自己的项目实践中用过他自己的那些理论。

我是一个彻彻底底的务实派，再牛的开发思想，再先进的开发理论，到了我这里，如果不符合团队和项目实际，发挥不出它应有的作用，我也会坚决CANCEL掉，因为，我认为，对于一个项目而言，我们最可宝贵，最无法挽回的损失，就是：时间。

一方面，我们希望我们的团队成员，每个人，下到C++底层的细节，上到设计模式，都能了若指掌；而另一方面，我们不得不面对的一个现实是，在绝大多数的团队里，能作到这个程度的人，始终都是一小部分，大多数的团队成员，都只是在某一块自己熟悉的开发领域里，是一个熟练的编码者而已。

所以，我们选择务实的作法，当对架构，模式甚至是代码细节出现争论时，不要过多的陷入进去，当你发现争论不可能有好的结果时，应该果断结束，把决定权交给真正要作这件事的人，让他们自己去选择，在无法确定哪个方案谁好谁差的情况下，我们的作法是，首先，你得让作这件事的人自己觉得爽才行，只有他自己觉得爽了，他才会更主动，也才会更多的在后面考虑改进。

我们作项目，分成三个阶段：第一步，要尽可能快的出版本，出结果；第二步，要保障快速高效的运营；第三步，要尽可能快的维护，修改，发新版本。

“快”，决定了你在市场竞争中的优劣地位。只要你始终在想着"开发快，易运营"这两点，很多的事，该如何作，如何选择，你自然会有个结论。

作团队感悟(8)----有效沟通

前记：

“有效沟通”，这里的“有效”，指的是有效率。

这是一篇有关“如何进行有效沟通”的作团队感悟，其核心思想是：在实际的开发实践中，我们需要不断优化各种各样的工作流程，而流程优化一个非常重要的方式，就是“有效沟通”，所谓的“有效”，是说对于表达者，要明确表达自己的意思，对于接受者，要准确理解对方意图。我们经常说，“执行比理念更重要”，而有效沟通，就是“有效执行”的大前提，所以，要努力培养团队成员养成有助于有效沟通的一些好习惯，比如：要多读书，多思考。从另一方面来说，学会对问题的基本分析与判断方法，是一个职业人应该具备的基本素质之一。

引入正文----

在团队开发中，我们总免不了与上上下下，左左右右的人协作，交流与沟通，上到一个需求的含义，下到一个函数的接口。如何作到“快速开发”？有效的沟通，成为第一个我们需要面对和解决的问题。

所谓沟通者，参与的人，无外乎两个方面：听者与说者。所以，有效沟通，具体的应该是指：1。对于说者而言，要想办法组织好自己的条理和语言，把复杂的问题简单化，力求“一针见血，言简意赅”的表达自己的想法，对于说者，你的任务，不仅仅是“说”，而且，是要“说清楚”，要想办法让听者更易理解。2。对于听者而言，要认真收集说者语言中传达的各种信息，理出有效信息，记下，并在随后的交流中进行复述和确认，对于听者，你的任务，不仅仅是“听”，而且，是要“听明白”，你的理解要跟说者达成一致。

我们总是痛苦于这样一种情况：辛辛苦苦说了半天，结果，我们的“听众”听到最后，还仍然是不明白。我们埋怨对方的理解力太弱，埋怨对方不认真听，进而失去耐心，认为这样的沟通是在浪费时间，于是，便不再进行沟通，而不沟通导致的结果就是对方作出来的东西不是你想要的东西，于是，出现了不断的返工，浪费了更多的时间。

每当这个时候，其实，最应该反思的，是你自己，你应该仔细反思以下内容：1。你所说的话，有没有条理性，有没有一是一，二是二的理清关系？2。你是不是把简单的问题复杂化了？能不能作到复杂问题简单化，你的想法能不能只用一两句话就能明确表达？

在涉及到多人协作的团队开发中，我把第二点看得更加重要，一件事，如果不能用一两句话说清楚，那在他传我，我传你，你又传另外人的几个步骤后，很有可能就会造成理解扭曲，第二点能力，可以简单地说，就是“抽象的能力”和“形象的能力”。

“形象的能力”，是指借用打比方，类比之类的方式，来把一个陌生的观点和想法通过听者已经熟知的内容传达给听者，把想法尽可能具体化。

如何培养“抽象的能力”？阅读+思考。我记得很久之前，读初中时，我们每学一篇议论文，学习之前，语文老师都会让我们记一下这篇文章的“中心思想”，也就是这篇文章的核心观点，然后带着我们围绕着这个“中心思想”去分析作者如何从各个方面为自己寻找论据的。

所以，针对这个“中心思想”，从听者和说者的两个角度，应该努力作到：1。说者要尽可能“明确表达”这个“中心思想”；2。听者要尽可能的从各种信息中“判断”出这个“中心思想”；3。听者“心里”明白了，还不行，必须要跟说者来确认这个“中心思想”，确认双方对它的理解是一致的，而确认的方法之一，就是由听者对“中心思想”进行提炼，概括，复述。

以我们自己项目的开发方式而言，说一说我们的方式。

通常情况下，我在布置开发任务时，会按以下方式来作：1。在布置具体任务之前，我会先交待一些开发原则，比如：要有防御性编程思维，服务器编程是基于“不可信任式”编程，安全是第一位的等等；2。明确表述需要制作的内容，按什么步骤来作，列出可以参考的类似实现；3。向接受方明确告知，什么是第一位的，什么是第二位的，当第二位的与第一位的产生冲突时，要舍弃第二位的。

其实，在我们的开发实践中，我们发现，大家普遍容易疏忽和出现问题的地方，主要是跟实际运营相关的，就是说编码不能仅仅是考虑编程语言如何组织，数据结构如何优化，不能仅仅在技术的框架内考虑实现方案，慢慢地，要学会在产品运营的框架下去考虑问题。而这种观点，就构成了我们团队沟通的基础，必须要不断强化运营的观点，让大家慢慢接受这种观点，这样，在以后的协作中，就会出现更多合作中的默契，而不用你一而再，再而三的去作唐僧式的宣讲了。

作团队感悟(9)----该对谁负责

前记：

人在职场，不免会受各种各样的因素左右，由于我们身处的位置，团队，公司，以及产业，对同一件事可能会有截然不同的看法。就比如，我将在此文中提到的“该对谁负责”的问题，可能现实的实践中，大家采用的就是完全不同的作法，也同样取得了成功。

所以，我只能说，这是我的选择，也是我所欣赏的选择，但是，我只是个体，代表不了大家，具体如何作，还需要每个实践者自己去摸索、思考和总结。

这是一篇有关“树立正确责任观”的作团队感悟，在这篇博文里，提出了两个问题，分别是：“我们该对谁负责”，以及，“应该以什么原则建立相应的责任体系”。我不赞成完全只对老板负责的作事方法，也不赞成一事多人的作事方法，至于我采用的是什么具体方法，详见正文。

引入正文----

责任感，最原始的动力，应该来自于“想把产品作成功”的积极心态，而不仅仅是上级的压力或者某种信任。我们提倡积极主动的责任观，也通过各种方式培养团队成员的责任感，并且让他们切实的对自己所作的事负起责任来。

一个男人的魅力，很大一部分来源于他有没有责任感；而对一个团队成员的评价，很大一部分也是来源于他对团队和产品的责任感。最理想的境界，当然是：人人都一心想着产品好，人人都努力作好自己份内的事，为产品作贡献，但在这种境界达成之前，我们需要作好许许多多的细节，让每个人都对自己作的事负起责任来。

在产品研发中，我们该对谁负责？对产品经理负责？对老板负责？还是对用户负责？

sorry，我想说的是，以上都不是，我们不应该对任何一个具体的人负责，而只应该对产品成功负责，如果非要具体到对哪个个体负责，我想，这个人，应该是你自己。

只有你自己从始至终一直坚持着“对产品成功负责”这个理念，你的所作所为才会不断向正确的方向修正和改进，你对产品和产业的把握才会越来越准确，你的信念会更加坚定，个人素质也会不断提高。

为什么不能以“某一个人”为你的责任对象？那是因为，是人，就会犯错，即使是公司老板或者你的上司。

“对产品负责”，可以让你始终站在一个相当的高度和中间的立场上去客观的分析问题，解决问题，不至于因为无谓的人事斗争或老板偶尔的失误而断送产品前途，同时，也会为你赢得其他人的尊重。

我想，没有任何一个人，会从心底里去尊重一个每天只会溜须拍马的马屁精，特别是，技术人员的群体中。所以，从这个层面来说，“对产品负责”，也是对你树立团队威信最好的选择。

确定了“方向”的问题之后，我们就需要考虑，在团队内部应该采用什么样的责任体系了。我们提倡和使用的理念是：任何一件事，其最终，都只有一个负责人，这件事，由这个人来负责牵头，组织，协调，跟踪实施的全过程和实施后的效果，他可以去动用团队其他资源去为这件事服务，简言之，就是：“一事一人”的责任体系。

一旦确定了负责人之后，不在万万不得已的情况下，决不中途换人，只要不换人的代价是项目和产品可以承受的，就会坚持用下去。

在用人上，最糟糕的方法，就是一件事指定了两个人或者更多人去负责，越多的人负责导致的结果，必然是越不负责。当然，我这里所说的“负责”，指的是责任人，不是指的参与者。

由于事情的大小，同时参与的人可能远不止一个，但是，负责人只能有一个，所谓“一山不容二虎”，我们首先，应该从制度上避免这种无谓的人事矛盾，为干净纯洁的团队氛围创造条件。

在实际的开发中，我们经常遇到这种情况：某一个系统，很多的开发人员都很有兴趣想作，但是，这件事，最终只能交给一个人去作，那我们该如何处理这种情况？

我们采用的是：“一人负责，信息分享”的方式。也就是说，这件事，最终还是交给一个人来负责和主导，但是，他可以把处理这件事前前后后的诸多细节和方案在所有感兴趣的人里去分享他的经验，这样，既满足了项目需要：“这件事需要有人来作”，又满足了其他人对这件事的兴趣和关注。

如果，其他人能够也有空余时间和精力的话，他们也可以通过负责人分享出来的信息，自己私下去思考自己的解决方案，虽然他的想法这次没派上用场，但在下次类似的事情中，说不定他就可以上场按自己的方式来表演了。

我们希望团队中的每个人，都能不断的成长，而这种希望，不能只是一种理念，需要团队为大家不断的创造各种条件让每个人都有机会去尝试。创造条件的具体措施，需要每个团队领导者去不断摸索，但只要你秉承这种理念，方法总会有的。

作团队感悟(10)----培养务实精神

前记：

“正确与错误”，“创新与保守”，“精妙与笨拙”，这所有的词，对于很多的人，在很多时候，都会选择前者：正确的，创新的，精妙的。可现实，让人郁闷的是，我们有时却要“被迫”选择后者：错误的，保守的，笨拙的。这到底是为什么？

跟若干年前的自己相比，我现在更欣赏和喜欢：用尽可能简单的架构而不是复杂的，用C而不是C++，用常见方法而不是各种“高深”的设计模式，用自己产品的库而不是第三方库。

这是一篇有关“如何培养务实精神”的作团队感悟，其核心思想是：“一切从实际出发，一切以实用为目标”，应该成为我们开发实践的指南。从个体来说，清醒认识自己，是最大的务实；从团队来说，清醒认识整个团队现状，是最大的务实；从项目来说，清醒了解项目目标，是最大的务实。有了清醒的认识，才会有务实的行动。知道自己缺的是什么，团队缺的是什么，项目需要的是什么，就会在各个方面以最实用有效的方式作到最好，这，便是务实的工作方法和工作态度。

引入正文----

网易教给了我很多，其中，最重要的一点，就是：务实。我想，这可能是让我受用一生的宝贵财富。她先是教会了我什么才是务实的心态，然后教会了我什么才是务实的工作方法。

我们说一个人务实，可以归结为两个方面，缺不一可：一是要有务实的心态；二是要有务实的方法。前者，是理论和精神层面的，后者，是实际操作层面的。

那么，具体一点，一个人，怎么样，才算是务实的？我想，不外乎以下几点：1。 首先，对于自己本身，要有个清醒的定位，清醒地知道自己的优缺点，清醒地知道自己在团队，在产品，在公司中目前所处的位置，以及所能发挥的影响力。一个对自己都认识不清的人，或者不敢正面面对自己的人，是很难谈得上真正务实的。2。 不爱慕虚荣，不图虚名，不唯资历，而唯实力，唯能力。3。 不论是评判他人或他人的成果，还是决定自己采用的方法，皆以实用，有效，快速为目标，不整花哨理论，以结果为导向。

如何培养务实的精神？简单的一句话概括，那就是：一切从实际出发，一切以实用为目标。前者，是起点；后者，是终点。我们从“一切从实际出发”开始一点点的作，一点点的想，然后始终以“一切以实用为目标”为方向来不断纠正我们的努力过程。

就拿我自己来说，写博客这事，没错，写了这些内容后，我收到了很多网友的夸奖和欣赏，也在很多人眼里变成了所谓的资深人士，而其实，在我自己看来，我自己在事业上才是刚刚起步，还太嫩，经历的还太少，现在只是学会了按照一套自己看来正确的方法，充满激情的去作一件事，目标和信念还算坚定，但是，我还缺乏许多在处理具体人与人或者人与事关系方面的技巧，还需要不断地扩展人脉，不断摸索和思考，不断精益求精的改进。

我自己很喜欢这种务实的感觉，这种感觉，会让你觉得，你就是一个平常人，不会有那种时时刻刻都端着摆着假装牛X的很假的感觉，活得真实，让我觉得没有压力，让我可以更放手按自己的想法去作事，去思考问题。

在国内IT圈子里，总体上，给我的感觉，南方的IT比北京IT要务实得多，南方讲究实干，北京讲究玩概念。这样的状况，是多种历史，环境和文化原因造成的，不仅仅是在IT圈，在其它领域，南北的差异也是如此。

我们作技术的，普遍具有而又很难改掉的一个毛病就是：死要面子活受罪。我们作技术的，很多的不务实，就是因为受此毛病牵连。要务实，首先，你得能放下面子。这一点，说起来容易，作起来很难，它需要一点点善于自嘲的勇气，一点点勇于承受别人暂时鄙视（可能别人根本就没鄙视过）的勇气，不熟就是不熟，不懂就是不懂，勇敢的承认，勇敢的说出来，摆正自己的心态后，你会发现自己作起事来更没有顾虑，也更容易发挥了。

在我们项目组的新人培训大纲里，明确写着一点：每个新人进来后，以前的成绩全部清零，每个人，在这个项目中，都是从零开始，不管他是本科，还是硕士或是博士，也不管他是ACM选手，还是DS成绩刚刚合格者。

我们之所以这么规定，有两个目的：第一，可以明确的告诉新人，不要以为你以前的成绩好，就有了一些什么资历了，在项目组里，“资历”永远只来自于你对项目本身所作的实实在在的贡献；第二，也是明确告诉新人，不用为了一个什么硕士博士的学位端着面子，既然我们愿意把你清零，也理应会接受你哪怕是弱弱的实际动手能力，理应允许你犯错，理应给你一个在实践中从零开始学习的机会，这样，不管是项目组原来的老同事，还是新人自己，在心态上都正面了很多，新人知道不会因为动手能力太差遭受太多鄙视，自己的心态也就务实了很多。

务实，是需要一定的经验来支撑的。很多的时候，可能不是你不想务实，而是你不知道如何才更务实。比如初入社会的新手，他的知识完全来自于课本和学校，而这些知识放在实际的项目和公司环境中，却不见得是完全可行的。所以，新人可能要经过很长的一段时间才会明白这些道理：1。 正确的，不一定就有用；2。 创新，不一定就是好事；3。 再牛X的第三方库，只要不是自己的，就尽量少用；诸如此类，等等等等。

因为，在学校里，我们始终被灌输的，是要不断的明确区分什么设计方法是正确的，什么设计方法是错误；我们被灌输，只有创新才能成功；我们被灌输，代码应该尽量复用，多用现有的，别自己造轮子。

为什么以上这些原本在学校里学的东西，放在实际中都走了样呢？还是那句话：一切从实际出发，一切以实用为目标。

每个项目，每个团队，都有自己的不同，不同的人，不同的资源，不同的公司氛围，不同的生存现状，以及不同的行业背景。在公司里作事，很多的时候，更讲究如何更快速度的把东西作出来，如何更好的把握产品质量。而一个“快”字，就足可以决定你的选择与你以前学的所有理论不同。

说回上面提到的三个典型问题：

所谓的“正确与错误”，在很多的时候，是相对的，与其总在那里争论谁对谁错，还不如马上动手去作，以作的效果来看更有说服力，也更不浪费时间。即使是“正确”的理论，也有可能不用它，因为我们更关注是否实用，是否好用。我们作的是产品，不是搞学术，产品要求的一是要快速度作出来，二是要便于维护和修改，而这二者，无论如何作，都是由人来实施的，所以，你要从始至终关注团队成员本身的技术能力和经验问题。

“创新”，必然会带来改变，而改变，必然需要团队投入新的时间和精力去学习和熟悉新的内容，我们有那么多时间和精力吗，我们作项目，仅仅是为了追求刺激和好玩吗？

再说第三方库，为什么要少用？因为，我们想让项目尽可能“可控”，你能玩熟这个库，不代表所有人都能玩熟这个库，团队的短板，在于团队成员中技能能力最差的那一个，我们需要考虑到项目轮岗时由此问题给项目所带来的风险。

当你想说“书上说如何如何”，“别人的项目如何如何”时，你要多想一想，自己的团队是何种情况，自己的项目是何种情况，以及你自己是何种情况，照搬那一套拿过来，合适吗？

但是，务实，也是可以一点点培养的。首先，你自己要有这方面的意愿，要意识到不务实是不好的，要意识到想作成功一款产品，务实的心态是必须的。有了这个意愿，你就可以放低自己的姿态，仔细想想你的产品与别人产品的差异和优缺点，仔细想想你自己与其他同事的差异和优缺点，弄清楚自己擅长的方面，最大限度的发挥到最好，发挥到极致，最终，你将会凭借此点在团队中立足，进而在项目和公司中立足。

个人务实心态的培养，首要的一方面，是在于明确知道自己的优缺点。

我反对非要刻意改变自己什么缺点的观点，我认为，每个人都有属于自己的优点，也都有属于自己的缺点，我们之所以能把一件事作成功，并不是因为我们克服了自己的缺点，而是因为我们最大程度的发挥了自己的优点。而且，优缺点，本来就是相对的，在特定的时间、地点，在特定的团队和公司，优缺点可能就是互换的，本来是优点的，换了个环境后，可能变成了缺点，本来是缺点的，可能也变成了优点。

所以，优缺点，在我看来，是个中性词，而且，是在一个特定环境下才具有意义的中性词，也所以，我们唯一需要记住并奉行的理念就是：在任何时候，要灵活根据当前所处的环境来灵活应用自己所长，把你擅长的方面尽可能正面的影响事件的发展，任何成功，都是需要因应时势变化的，不要想着照抄照搬别人的理念和方法，一定要务实的结合实际。

务实的认识世界，务实的认识他人，务实的认识自己，才有了务实的观点和方法，也才有了务实的实际操作。

务实的工作方法，就是，从自己现在当下可以实际把握的资源出发，加上自己的努力，不断把成果向前推进，一步一个脚印，直到最终的目标。学习如此，工作如此；作项目如此，作团队如此，作公司亦如此；我想，作任何事都应该如此吧。

作团队感悟(11)----跳槽、创业与个人发展

前记：

友说：“我要辞职了”我说：“为什么？”友说：“没有个人发展空间，本来那个位置应该是我的，但是现在被其他人占了”

这样的对话，我重复过不止一次两次，虽然每个人每次的情况都可能各有不同，但是，大家关注的问题，却是同一个，那就是：技术人员的个人发展问题。

对于个人发展空间，我们常常狭隘的理解为：哪个当官的位置我可以作？哪个重要的职位我可以升？但是，一个团队中，官位总是有限的，你坐了，人家便没了机会，而人家坐了，你也肯定没了机会。如果我们仅仅把个人发展空间理解为官位，那确实是非常有限的。

到底什么才是所谓的“个人发展空间”？是不是，只有当了官，才叫拥有了个人发展空间？

这是一篇有关“技术人员个人发展”的作团队感悟，其核心思想是：只有一起想着把产品这块饼作大了，个人才能谈得上更大的发展，在想着索取之前，先想想自己可以为产品作好作大贡献什么。一个技术出身的人，如果想要更广阔的发展空间，除了基于本职的相关技术技能外(这是基础)，还必须要掌握一些跨专业、跨公司甚至是跨行业的能力(更多的可能是非专业能力)，有了这些能力，无论将来从事什么行业，从事什么工作，心里都不会慌，因为你已经找到了正确作事的感觉、方法和状态。在我看来，所谓的“个人发展空间”，是说你是不是有足够的自由度去拓展自己想拓展的能力，这些能力可能包括：分析问题的能力，解决突发事件的能力，组织能力，协调能力，进度把控能力，与人交流能力，时间规划能力等等等等。如果给了你充分的自由度，让你可以去充分拓展这些方面的能力，那要不要那个官位又有什么区别呢？难道仅仅为了一点点虚荣心，就非要谋个一官半职吗？再者，只要把这些“当官”的能力锻炼出来了，即使在当前项目中没有发挥的空间，那在项目发展壮大了以后，或者，干脆在别的项目里，也早晚可以派上用场。所以，重要的，不是能不能当官，而是在于有没有机会去锻炼自己各方面的能力，有没有自己通过个人成绩去争取过这样的机会。在我看来，个人发展空间，是自己通过成绩争取来的，而不是别人恩赐给你的，“当官”，是能力发展到一定阶段、产品作到一定阶段之后的必然结果，而不应该成为追求的目标。

引入正文----

01年，我大学毕业，7年的时间里，先是在一个学校老师办的公司里作网络教学软件开发，后来创了一次业并最终失败，再后来，从成都北上，想在北京寻找自己的未来，但几经辗转，最终到了广州。我想，如果用一个词来描述我的经历，“走南闯北”，也许真的蛮合适。

但是，也正是因为自己经历过这许多，自己内心的感悟才会更深刻。我想，我心中从不放弃的一个信念就是：我相信，而且，是当成信仰一样的相信，明天一定会更好，我也一定会亲手创造出一个更好的明天。

每个人，都有选择更美好生活的权利，所以，我从不避讳与团队成员谈及跳槽、创业乃至个人发展的问题，如果真的是一个很好的机会，我绝不阻拦，特别是团队核心人员，也绝不挽留，就象我曾经的一位老大哥对我一样，他把我从北京放走，跟我说的也是同样的话，我至今感激他。

无论是跳槽，还是创业，或者是在团队内部，涉及到个人发展的大问题，这样的决策，每一次，可能都会是命运的转折点，所以，选择一定要慎重。那么，每次面对机遇来临，我们该如何处理和面对呢？

个人发展，从方向上来看，可以分为在内部发展和在外部发展两种。前者是说在当前团队和项目内的发展，后者是说离开现在的团队，跳槽出去或者创业自己干。不到万不得已或者水到渠成，我不赞成轻易离开现在的团队。因为，每个公司，每个团队，每个项目，都会有自己不完美的地方，与其花时间去找另一个不完美，不如在现在的环境中尽自己的力量去把当前的东西作得更完善。换工作，绝不能仅仅只看薪水多少，更大程度上，还要考虑你在现在的公司已经积累的同事信任，上下级关系这些人脉资源以及你的项目经验等等，一旦换了一个新环境，这所有的东西，都需要重新积累。

之前，我也一直困惑，我们这些作技术的，是不是到了三十岁以后真的就没人要了，没法活了？我们的职业，真的是吃青春饭吗？

现在，我弄明白了：

一个人，只要把自己的能力真正的锻炼出来了，无论到什么时候，在什么单位，都有用武之地。这里所说的“能力”，不只是狭隘的专业技能，它更大程度上，还包括了“分析问题，解决问题，与人交流，与人沟通，把握人的心理”等等与技术无关的能力，而这些能力，常常是跨专业、跨公司甚至是跨行业的。只要真正的学会了这些能力，将来即使是去开个小面馆当个小老板也同样能派上用场，作得很好。

但是，很可惜的是，我们当中的很多人，作技术作了很多年，却一直没有什么大的起色，因为他们只顾埋着头作技术本身，而忽略了去有意识的培养这些跨专业、跨公司或者跨行业的能力。应该说，作技术的人，都还是比较聪明的，他们之所以欠缺这方面的能力，并不是因为他们学不会，而是因为他们从不曾意识到，从不曾留意过，也从不曾努力过。

有时，我们会开玩笑的说“书读得越多，人就越傻”，现在想来，觉得还真有点道理，书读得多了之后，就不知不觉的被绕进去了，就不知道从哪里能跳出来看看外面的世界了，我想，这也许就是，为什么一个本科毕业甚至是更低学历的，却可以作一个博士的老板的原因吧？因为老板看人看问题总是看得更透，行动也更务实。

说到团队内部的个人发展，团队应该积极创造条件，尽可能让每个人都能在自己感兴趣的范围内去自主拓展自己的能力，比如，我们可以下意识的安排一些需要组织、协调的工作给一些想拓展团队组织方面能力的同事，还可以下意识的安排一些性能调优，架构优化等技术含量高的工作给专心研究技术本身的同事，等等。从团队成员来说，也应该主动表达自己感兴趣的方面，同时，要在平时的工作中努力证明自己具备这方面的基本条件，这样，在需要的时候，团队就会考虑到你。

说到创业，也许，是我现在作事太过务实了，我基本很反对只靠一腔热血就准备出去创业的观点。有的人，是因为发现了一个市场机遇而去创业；有的人，是因为受不了公司的氛围而去创业；有的人，甚至是因为见着自己的上司不爽而选择去创业。很多人，可能连“自己为什么要去创业”这个问题都没想清楚就去创业了，这就更不应该了。

如果连一点基本的隐忍都学不会，还想在复杂得多的创业过程中有所成就吗？创业不是儿戏，除了你自己，还需要考虑到家人和其他更多依靠着你的人。

在我看来，创业，更象是一个自然而然的结果，当你的技能、人脉、资源，以及资本积累到一定程度后，创业便是自然而然的选择，你的身边也会自然而然的聚集一批志同道合者，对市场的观察以及对商业模式和商业前景的判断，也会自然而然催生创业的想法。可能有的人，会觉得这样的时间太长，受不住在这之前漫长的积累时间，等不了，他们甚至会反问：比尔-盖茨不是大学还没读完就开始创业了吗？国内几个门户的大佬创业时不都年龄不大吗？

我想说的是，创业，重要的，不在于年龄，不在于年龄大或者年龄小，而在于你自己可以把握的东西有多少，不能你认为一个创意好，就冒然决定创业，要知道，你认为的创意，于市场和用户而言，可能根本就没有你想像中的那么有用，而没有用的产品，又怎么能指望用户来喜欢呢？马云35岁才开始创业，还不是一样弄出了一个阿里巴巴？牛根生45岁时才开始创业，还不是弄出了一个蒙牛？他们之所以这么成功，是因为，他们在成功之前积累了很长时间，所谓“厚积薄发”。这样的例子，还有很多很多。

什么叫作事业？什么又叫作创业？

是不是只有当自己拥有了一家独立的公司，才叫创业？是不是只有完全按照自己的想法和规划来作，才叫事业？

不是，完全不是！

在我看来，一个人的事业，可以时时处处开始，只要你认为你是在作事业，你从现在开始就可以是在作事业，尽管那可能不是你的公司，不是你的产品，甚至，不是你的团队，但你一样可以在这样的环境下去积蓄自己作事业所需要的各方面能力。这绝不是自欺欺人，这是一种非常务实的创业观。在我早前那篇有关“抛开技术作技术”的访谈中，我就曾经说过：带着作事业的心态去作你现在的事，有百利而无一害，也更容易成功。

这个公司不是你的，这个产品不是你的，这又有什么关系？纵使所有的东西都不是你的，人家也没有阻挡你在这个公司，在这个产品上发挥你的才能，积累你的经验呀！把可能并不是你的公司或者并不是你的产品当作你自己的事业，绝不是犯傻，在享受成功之前，每个人都必然要经历漫长的积累，各方面能力和资源的积累，都必然要经历失败、痛苦和彷徨的挣扎，这是一个创业者所必备的素质，多点耐心，多点韧性，一切，就会在不自不觉中沉淀并最终爆发。

话说回来，对于一个初出校门的学子来说，无论是基于经验，还是基于对行业的把握，都不应该奢求太多，要能潜下心去，用三四年的时间去积累，去沉淀，去观察，而且，最好是呆在同一个公司里，因为对一个公司和一个行业的理解，没有三四年的时间，是远远不够的。特别是，对于中国这一个非常特殊的市场来说，技术所起的作用，真的很有限，我们需要锻炼和把握的，往往是更多技术之外的东西，比如：与人交往的能力，对行业本质的分析，对中国国情现状的把握，以及，对所服务用户心理的把握，这些东西，没有一个与技术相关，但却是决定你产品是否成功的关键。

自己作老板，并不是一件轻松的事，虽然得到的更多，但可能失去的也不少，虽然表面光鲜，但是，真正的郁闷只有自己知道，那么，问一问你自己，那样的生活，是你想要的吗？无论是否假日，也无论是否周末，你的心里永远都得装着公司，装着产品，永远都得考虑下一步怎么走，永远都要考虑风险如何规避，并不是每个人都适合作老板的。当然，也并不是只有当了老板，才能作一些事的，有句话，说得很有道理：当老板的，是给公司所有员工打工。

当然，如果你非要坚持现在就去创业，那我几句话送给你：1。 最好从一开始就能小有赢利，赢利多少并不重要，重要的是，公司可以由此进入一个良性循环；2。 慎用别人的投资，不用投资最好，特别是，当你已经具备了第1个条件后；3。 不要让家人参与公司运作，否则，麻烦会比正事多；4。 不要搞股权分立，要一个人可以把握公司核心资源，要拥有话语权和决策权；5。 不要跟学校的教授合作，也不要跟业内图有虚名的“资深人士”合作，要找，就找那些实实在在作事的人；6。 不要跟不正干或不走正道的人合作，没必要自己给自己找麻烦，这个世界的阴暗，是你所无法想象的；7。 不要怀着拉投资的心态去创业。你创业是为了什么？把自己的事业全寄托在拉到投资这唯一的“关键”问题上，是不是太幼稚了？太傻了？

创业要自主，要靠自己。

作团队感悟(12)----好团队源自我们自己

前记：

“什么时候，我能遇到象你们这样的团队就好了”，“真希望有机会能加入你们的团队”。。。

随着越来越多的朋友关注我的这个系列博文，我也一直收到越来越多上面类似的感慨，首先，还是要感谢大家的支持和信任，感谢大家对这些文章及文章所倡导的理念的肯定。

但是，我的本意，并不是想宣扬我们自己这个团队，我的本意，在于传播一种理念，一种积极向上的，主动思考的，务实行动的理念。

事实上，我们团队，也与其它很多团队一样，有着这样那样不尽如人意的地方，但比较好的是，至少我们已经进入了一个良性循环，已经慢慢形成了一种共同的价值观，已经有了一种良好的氛围可以不断的改进和完善自己。但是，我们这个团队，早前也并不是这个样子的，我们也是经历了诸多的磨合、诸多的艰难，才最终形成了现在这样的结构，这样的氛围。

这是一篇有关“好团队源自我们自己”的作团队感悟，其核心思想是：不要总羡慕别人的团队好，不要总寄希望于靠运气能碰到一个好团队，事实上，每一个好团队，都是自己作出来的。所以，放眼当下，把自己的综合能力提高，把自己当前所在的团队作好，才是最务实的作法。 “作好自己-->形成影响力-->弘扬正面的风气-->形成团队核心-->把产品研发推向正轨-->带来利润-->持续优化团队-->持续优化产品”，这，就是一个好团队的成长路径。一个优秀的职业经理人，不仅仅在于可以给公司带来利润，相当程度上，还在于可以给公司培养一支成熟的团队以用于公司的持续、长久发展。

引入正文----

我把作团队分成这样几个境界：1。 由单打独斗，转变成对团队精神的肯定，并进而想作一个团队；2。 由想作团队，转变成作成了一个团队，并进而对团队产生了依赖；3。 由依赖一个团队，转变成依赖自己，完善了自己作团队的各方面素质，坚信自己：换了个公司和环境，靠着自己的方法和素质，也一定可以再作一个团队出来。

由此看来，最开始，我们是依赖个人，然后转向了依赖团队；而第三阶段，又从依赖团队，转向了依赖自己。这是一种倒退吗？显然不是，这样的转换，已经有质的区别，因为在你经过第二阶段后，你已经具备了培养优秀团队的能力。而就第一和第三阶段这样的转换，从另一方面来说，这也正是我们所倡导的价值观：在任何时候，首先要靠自己，从自己作起。

随着大家越来越强调团队精神，处于第一阶段的人，是越来越少了，不管是否情愿，很多人都在向作一个好团队的方向而努力着。更多的人，是处在第二阶段，即：通过自己的不断努力，一个团队已经慢慢成型，也慢慢具有了战斗力。

但此时，容易犯的一个错误是，万事，太依赖团队，好像没有了团队，自己就没法活，没法干事了，我认为，这同样是不可取的。

对于我们自己而言，我们从始至终，要为之努力的，首先，都是要先让自己成长和成熟起来。

要让自己先慢慢具备培养一个好团队的各项素质，下到你的专业技能要有说服力，上到你的思想层次不能自私，要为他人考虑。自己成长了，才可能带好一个团队，作好一个产品。那些言必称团队，却对自己本身素质提升丝毫不作要求的人，带出来的，也只是一个虚伪和虚妄的团队，随时可能会再次成为一盘散沙。

而从另一方面说，只要你具备和完善了这些素质，又何愁不能带出另一个好团队呢？

随着你的工作环境变迁，你的职位变化，你所处的团队也始终处于不断的变化中，今天，你要跟这些人合作，而明天，当你换了一个新环境后，你又要与另外一批人合作，这些人，在某一个历史时期，都曾是你的团队成员，但又都无法固定下来，那是不是说，我们换个地方，就要带着自己培养出来的团队呢？

显然，这是不太可能的，这种想法本身也是比较幼稚的，就象一个已经十来岁的孩子还整天嚷着要吃奶一样，离开了娘就没法过了。

我们最需要作的，仅仅是，带上自己，带上自己以前积累下来这些作团队的经验，按照我们以往所恪守的理念和价值观，辅以与当前环境实际相结合的方式方法，去另一片新天地打造另一个优秀的团队和成功的产品。

我认为，作团队，最重要的两个基本素质，首先是：真诚，不自私。而后，你的各项措施，才有被人接受的可能。

有人说，遇到一个好团队，真的是不容易。是的，我承认。但是，我更想说的是，好团队向来都不是靠碰运气碰来的。同样的一批人，在完全不同的两种团队氛围下，其表现可能就是大相径庭，甚至，是让你目瞪口呆的，这并不是因为这个人是个两面人，而是因为他所处的是一个什么样的团队氛围。所以，从这个意义上来说，我从来就不相信靠等就能等来一个好团队，靠碰就能碰到一个好团队，我只相信：人，是可以塑造的，团队，要自己作。

职业经理人的最高境界，我想，绝不是只看赢利，还要看他走后，在他身后，留下了一个怎样的团队给他的老板。当他在时，公司可以好好发展，可以好好的赢利；当他不在时，公司却一撅不振，我想，这不能算是一个好的职业经理人。

一个好的职业经理人，应该是在他的所到之处，不仅解决企业当前的问题，同时，也在传播一种良好的作事方法和态度，传播一种可以让企业持续发展的整体技能，而在这些众多的技能里，其中有一条就是团队如何形成，如何协作，以及如何向前发展，这远比留下一堆表示利润大小的数字要重要得多。好的职业经理人，就象播种机，在他所过之处，不断地传播好的价值观，好的作事方法，不断培养优秀的人才，为行业提供更多的有用之源。

作团队感悟(13)----如何应对需求变化

前记：

过去，在传统软件行业里，开发的流程一般是：先作需求分析，然后确定功能，最后实施开发。也就是说，需求分析之后，需求基本就很少变了，会在相当长一段时间内，维持一个稳定的需求。

但是，在进入互联网软件时代后，事情已经发生了变化，仅就需求而言，“朝令夕改”已经不是什么新鲜事，作为系统的实现者，我们当然都希望需求越稳定越好，但那仅仅是“理想”，甚至，有时仅仅是“梦想”。因为，对于一个尚未成熟的市场，尚未成熟的互联网产品或者尚未成熟的团队来说，需求变动的推动者，可能是市场，可能是用户，也可能仅仅是老板的一句话，你无法说这个改动是对是错，很多的情况下，我们也没有那个精力和时间去争辩谁对谁错，对于我们而言，最切实可行的一条路，就是：摆正心态，积极应对。

这是一篇有关“如何应对需求变化”的作团队感悟，其核心思想是：在互联网软件时代，需求变化是软件开发的一种常态，我们再也不能用开发传统软件的思维来照搬互联网软件的开发。互联网软件“需求变化快，开发周期短”，从各个方面都要求团队内部要建立起应对这种快速变化所需的组织、流程、以及沟通氛围。作为底层的实现者，对于需求变化，很多情况下是我们决定不了的(要么是老板说了算，要么是用户说了算，要么是竞争对手“说了算”)，这时，对于我们而言，只有在力所能及的范围之内作到适当的架构灵活和适当的组织灵活，以积极的心态和主动的方法来应对这种变化才能把产品务实的一步步向前推进。

引入正文----

写程序，最痛苦的是什么？就是辛辛苦苦弄了半天，写好了，人家的需求却变了，刚写好的代码没用了，全部删掉。曾经以为，只有互联网软件里，才会比较经常的出现这种情况，但是，跟一些朋友聊了之后，才知道，原来，现在的传统软件行业里也存在同样的问题。不管这个需求来源于哪里，程序员除了抱怨一下，发一下火(还要看有没有那个“资历”)之外，该作的，还仍然要作，一个都逃不掉。

我们的开发中，也会经常遇到这样的问题，面对不断变化的需求，我们有过懊恼，有过气愤，有过不平，但当所有的情绪都发泄完了之后，静下心来想一想，为了产品，这些新需求还都挺有道理，都必须来实现。

于是，我试图想在这篇文章里，分析和总结一下有关需求变化的前因后果，还有我们目前的作法，以及我们如何看待需求变化这件事的，希望能给大家带来一些帮助和启发。

对于我们凭一己之力无法改变或者无力决定的事，应该秉持两种心态：

1。 要以积累的心态去用自己的实际行动对它产生积极的影响力；

2。 既然我们无法改变它，就只有接受它，适应它，再慢慢引导它。

对待需求变化，也是同样的道理。

很多的需求，为什么会有，为什么会变，可能本身就是没有太多道理的，老板说这个得改一下，那个得改一下，在产品没有推向市场之前，在用户没有最终体验之前，你也很难说他的这个需求就是不对的或者不合适的，那这时怎么办？我们的策略是：争取一下，沟通一下，想想其它办法，实在不行，就什么也不用说，动手作吧。当然，这是一种被动应对的方式。

我们认为，这是没办法的事，一个团队，需要成长才能成熟，一个老板，也同样需要成长才能成熟。只有越来越成熟了，才可能会越来越多的提出更合理的更稳定的需求，而反之，当他不成熟时，他作出的需求就谈不上稳定和合理，那这时，是不是我们就不要作事了，是不是就只有散伙了？我想，动不动就这样去想的朋友，还没有真正悟出开发者应该具有的觉悟：其实，老板都差不多的，当你换了一家后，你可能也会遇到同样的问题，你能作的，不是逃避，而是正面面对它，如果他的想法不成熟，就帮着他成熟，如果他坚持，就照作，让事实教育他。当事实一次次告诉他，你的想法和作法才是正确的之后，他才会更愿意放权给你。而在此之前，你没有其它更好的办法，只有忍着。

也许，我们经常会有这样的抱怨：“我们不是约定好了吗，就按XXX来作的，怎么又改了”。我想郑重的告诉大家：不要相信约定，对于一个尚处在生存期的项目而言，你一切努力的目标，都是为了项目生存和发展，而不是为了一个“浪漫的约定”。市场和用户，只看需求，不会看你所谓的“约定”。

从另一方面说，很多时候，并不是老板自己想作出需求改动，他们可能是受压于市场环境，受压于同类产品竞争，也可能是受压于用户，总之，方方面面的原因，都可能造成需求改动，所以，我们没有理由、也没有必要一直坚持在“需求需不需要改动”这一点上来回的扯皮浪费时间，我们更多需要作的，是要考虑一下，在我们团队内部，以何种开发方式，以何种流程，以何种组织架构来灵活适应这种经常性的需求变化。

除了上面所说的被动应对，还有一种主动应对的方法，那就是，作为系统开发者，我们自己要不断的使用我们自己的产品，不断思考我们的系统需求，在你使用和思考的过程中，很容易发现一些极可能带来变化的需求，这样，你在设计和实现时就可以提前规避。不要认为一个系统你开发完了，就是完事了。很多的细节完善，其实是在你第一遍开发完成之后再慢慢添加的，而如何才能发现这些细节，只有你自己不断的使用自己开发的系统。

面对需求变化，首先，我们要摆正自己的心态：

1。 不要一上来就发火，要分析为什么会有这个需求，新需求的核心点是什么？

2。 对比一下旧的实现，这个新需求用旧的框能不能简单改改就可以间接实现？

3。 从心态上，把需求变化当作是一种项目常态，但是，要学会控制这种需求变化的趋势，不能任其发展。

除了以上相关的心态准备外，在团队内部，还需要建立一种能快速适应需求变化的组织结构，我把这种结构，概括为：一人负责制+小团队协作+信息共享。

也就是说，在我们所有开发的系统中，针对于其中每一个具体的系统，都只有一个负责人，不会有两个或者两个以上的负责人，这样便可以最大限度的加快项目决策本身所耗费的时间，有利于快速决策和快速实施。

小团队协作，是指，一个具体的系统，从开发到测试到实施，涉及的人尽可能少，两三个人，四五个人，最好。因为，一个系统，从设计，开发，编码，到测试与交付，其中可能会涉及到诸多环节，并不是由程序员作完编码整件事就完了，产品可不可用，最终还是要由客户说了算，所以，应该想办法尽可能提高产品从编码到交付乃至到用户反馈这样一个完整流程的效率，涉及到这个系统的所有人员的反应速度就决定了整个产品对于用户需求的响应速度。

团队协作，最主要的两点：分工明确+信息分享。分工明确，是说哪一些人负责作哪一些事，有明确说明，但除此之外，我们比较提倡的一点，就是：每一个人，其最终，都是对产品负责，并不能只关注自己所作的那一块工作，把属于自己作的工作作好，只是一个基本前提，具备完整产品思想的人，才能谈得上合格。而信息分享，是指通过IM群、邮件、小会等多种方式把需求变化的信息尽可能快的通知到所有涉及到的人员，以让这些人员更好的进行协同。

除了组织架构，我们还需要提高团队成员个体应对需求变化的相应能力，这些能力包括：提高代码架构本身的灵活性，提高编程人员本身的应变能力。因为代码最终都是由单个具体的开发者实施的，他们的能力大小决定了他们的痛苦程度。

代码的灵活，可以在一定程度上适应需求变化。但是，这并不是解决需求变化的万能灵药。因为，在实际的操作中，我们经常会因为无法把握“灵活的程度”而把代码本身写得过于复杂，从而甚至让代码本身丧失易维护性，这是我们所无法接受的。我们认为，代码灵活性的底限，是不能破坏代码的可读和易维护，如果到达这个底限，我们宁愿丢弃灵活性，宁愿将代码写得笨一点。

我这里所说的这种方法，对人员也是有一定要求的，比如，这个负责人，就必须是能独当一面的，要有比较成熟的作事方式、方法和态度，知道如何在高压力和短时间内开展最有效的协作。

很多互联网产品，可能都会遇到一种情况：一个产品的新版本刚刚发布了，但是，在引入大用户量测试时，却突然发现出现严重的问题，这时，就特别考验负责人的应变能力，这种情况往往都是比较紧急的，成千上万的用户可能在网上排着队用你的东西，你需要在一小时、半小时甚至十几分钟内作出有效修改，这种感觉，已经类似于打仗，虽然很刺激，但确实需要相当大的处变能力。

每个团队，刚开始的时候，可能都不会这么完美，有这么多能独当一面的人，但万事总要有个开头，团队的成熟并不是靠读一两本书，看一两篇博文就能实现的，它需要你和你的团队在具体实践中不断的磨合、提高、总结。

作团队感悟(14)----不能仅仅靠感情

前记：

这又是一个悖论：我们人人都希望在团队里，象在家里一样，处处洋溢着亲情、友情，但是，很多的时候，在很多的团队，这只能是一种梦想，而且，也没有太多的公司能作到这一点。为什么？

这是因为，人，在某种程度上，都是“自私”的，在一定的条件下，都会不同程度的先为自己考虑。所谓的“大公无私”，也只是在一定程度上而已。

我们需要作的，不是去批判这种自私，而是把这种“自私”向好的方向引导，让“自私”对团队和集体有用。因为，我把“自私”看作一个中性词，它只是对人性的一种客观描述。

这是一篇有关“靠什么维系团队”的作团队感悟，其核心思想是：单纯的靠感情来维系团队，是很脆弱的，维系团队的方法，其最终，只能靠成功的产品和共同的价值观。维持一个团队的正常运作，不能靠跟哪一个团队核心的私人关系好，而是要让团队内部形成一种人才输出的机制，让每个团队成员都能充分的自我成长，从而也同时为团队作好更多的人才储备。

引入正文----

很多人都有体会，维持一个团队很难，而想让一个团队走得很久就更难。大家每个人，带团队的方式也会不尽相同，有的靠利益，有的靠感情，有的靠忽悠。究竟，什么东西，才是我们赖以打造和维持一个团队的长久依靠呢？

我认为，这个长久依靠，首先，应该是：希望，事业心，共同的价值观，与收益分享；而后，才是私人感情。

“产品一定可以成功的希望”，“共同按正确的方法作事业的心态”，“对相同价值观的认同”，以及“多劳多得”的收益分享机制，是一个团队最为健康可靠的保证。

诚然，感情，是让人最觉温暖的依靠，但我们不得不面对的一个事实是，感情在作团队的过程中也是最靠不住且最容易带来麻烦的。

感情再好，每个人都觉得产品没前途，那团队一定会散；

感情再好，每个人都觉得不是在作事业不是在作公司，而是象小孩玩过家家，那团队也一定会散；

感情再好，但总是在一些重大价值观上产生分歧，那团队也早晚会散；

感情再好，轮到分钱时，分得不公不平，团队也很容易散。

不把感情放在首位，并不是说是管理就必须无情，而是表明了一种态度：事业，项目和团队，首先，还是要能给大家带来希望，能让大家有一个共同的事业观，能给大家带来收益，而后，才能谈得上所谓的感情维系。离开了项目本身和团队本身，而去单纯的说感情，不仅本末倒置，也会破坏团队作为事业凝聚体的核心价值。

大家每个人的团队，每一年，都会遇到团队成员离职的情况，如果是感情第一，那为什么还会有这么多的人不断的从我们身边离职，难道他们在离职的时候，就不曾考虑过我们共处这么多年以来形成的兄弟情和同事情吗？显然不是，这与感情无关。

有些人，是因为看不到希望而离开；有些人，是因为有了更好的归属而离开；而有些人，是因为与我们根本不是一路人，他的离开，不是因为他的技术水平不高，而是因为大家信奉的东西里没有交集。

我们很多的团队领导者，用于维系一个好团队的方法就是把自己和团队核心的私人关系搞得非常好，其实，这样作，不仅风险极大，也是对团队本身不负责任。靠这种私人关系维持的团队，一旦某一个人离开，对团队的打击将是致命的，将无法在短时间内再形成一个核心。

所以，我们需要依靠的，是：机制，人才输出的机制。

这种机制，可以让每个团队成员都可以充分的自我成长和进步，都可以慢慢由最最普通的一个团队成员成长为可以独当一面的干将，团队的核心人才储备也会在这种机制下日渐丰富。

铁打的营盘，流水的兵。

你无法保证，今天还好好的一个团队核心，明天不会因为各种各样的原因选择离职，作为团队领导者，在此时，不能去一味的懊恼，而是要在尽可能短的时间内选好继任者补上这个漏缺，让团队按着既定的目标继续向前。

对上面，我们需要把产品作好才能赢得更多资源和收益；其实，对于团队内部来说，想要维持稳定、持久，其最终，也是要靠产品，靠成功的产品。

从这个意义上来说，一个尚未成功的产品，也更容易发生人员流动，因为不同的人看待事情的眼光和观点是不一样的，他在这个项目里看不到希望，他自然就会选择离开去寻找更有希望成功的产品和团队。

所以，在一个项目尚未成功之前，我们更应该去培养正确的作事方法，作事心态，去形成更积极向上的团队氛围，这样，至少，我们就可以让大家感觉到产品的希望和团队的希望。

试想，一个尚未成功的产品和团队，整天工作懒懒散散，上班迟到，下班早退，里程碑从来不按计划时间完成，这所有的一切，表现出来的，就是给大家没有激情，没有动力，没有希望的感觉，那还要如何才能把团队维持下去呢？

在我们没有能力给大家带来更多物质激励的时候，我们至少应该在精神上给大家以更多激励，给他们以希望，给他们以目标，给他们以信念，最后，再以成功的产品，给他们以收益。

作团队感悟(15)----培养危机感

前记：

辛辛苦苦，从小学、中学到大学，终于等到了毕业，找了工作，进了公司。

在这之后，很多人所走的路，都将发生巨大变化，有些，甚至与他们在校的表现完全不同。而事实上，当走出校门的那一刻，一种完全依靠自己的自由人生才刚刚开始。

这是一篇有关“培养危机感”的作团队感悟，其核心思想是：团队的成长和成熟，很多情况下，依赖于团队成员自我要求的不断提高和改进，而之所以能够这样不断的“自我要求”，“危机感”在其中起了很大的作用。所谓“生于忧患，死于安乐”，只有当每个团队成员，都能明确知道我们与别人的差距，都能明确知道自己应该在哪方面努力，都能知道我们的团队和项目都有哪些危机，团队成员才会更有目标、争分夺秒地主动改进。所以，从这个意义上来说，“培养危机感”，其目的绝不仅仅是灌输一种压力，更深层次的，是想让整个团队不仅有目标，而且有动力。

引入正文----

我们常说，人比人，气死人。

但是，作产品，作团队，却不能不比较，不能毫无斗志的得过且过，中国人这么多，聪明人这么多，聪明的企业这么多，你得过且过一段时间，就很容易被别人反超，这不是你愿意不愿意的问题，为了继续生存和保持领先，你必须不断向前。

小到一个刚刚成立的小公司小产品，大到一个已经颇具影响力的大公司大产品，危机意识都必不可少，要时时刻刻看到自己的不足，时时刻刻想办法改进，这种意识要从团队最上层一直灌输到最底层，形成共识，形成合力。

危机感来源于哪里？

来源于与同行的不断比较，

来源于对市场与社会发展趋势的判断和预测，

来源于精益求精的自我要求，

来源于所有可能影响团队与项目生存和发展的方方面面。

要经常的跟业内领先者比较，比如说，我们自己的产品，要跟暴雪比技术、跟梦幻比玩法、跟巨人比营销；就象华为在不断地跟西门子、跟贝尔实验室、跟爱立信、跟诺基亚、跟阿尔卡特比，一样的道理。为自己树立一个标杆，知道自己的差距，不断追赶。这所有的目标，都会让我们时刻明确自己还有哪些事需要作，都会让每个成员都倍添压力感。

官越大，职位越大，压力也就越大，这是必然的，但是，作为团队领导者，仅凭一己之身承受所有的压力，也不是一种值得提倡的方法，要学会把自己的工作分摊出去，把自己的压力分摊出去，把自己的危机意识传导出去。一层层的传导这种危机意识，直到团队最普通一员。

团队是干嘛的？

团队，不就是用来一起承受压力，一起努力把产品作好，把公司作好的吗？这才是团队最重要的作用呀，凡事只靠一个人，那还叫团队吗？

一个团队，没有危机感，大家工作就会没激情，就会感觉没压力，就会悠哉悠哉，不紧不慢。有时，虽然作为主管累的要死，但是，他的手下却闲得没事作，无精打采，这样的情况，是对公司人力资源最大的浪费，而对人力资源的浪费，也是所有浪费形式里最不可宽恕的。

危机感，这个词，可以再具体一点：比如，一个项目，作不好，团队就解散；一个产品，里程碑完成不了，就换人。如果我们都不给自己一个最后期限，整天浑浑噩噩，就只能被生活吞噬。但是，我不得不说，这种情况下形成的危机感，并不是一种最好的方式。最好的方式，还是需要团队成员自己在心底里树立自发的危机意识和时间意识。

危机感，是一个时刻自我要求精益求精之人的正常心态，是一个具备大局观的人自然而然形成的认识论。危机感，来源于明确知道自己的不足，而要想知道自己的不足，又必须具备务实的精神。

我们经常遇到一种情况：很多的新人，进入项目组后，一时半会可能还没有完全进入状态，上班时聊聊天，看看新闻，泡泡论坛，一天的时间也就过去了，虽然我不好用“混”这个字来描述这种状态，但，这确实就是一种“混”的状态。

我想问一下，你想过明天吗？你对自己未来的规划是什么样的？你准备什么时候找女朋友，什么时候结婚，什么时候买房买车，什么时候拥有自己独立的事业？以上所有这些，离开了物质基础，行吗？但物质所得，不是靠“混”就是“混”出来的。你不希望通过自己双手的努力，来获得这一切吗？如果现在不开始，你又准备什么时候开始大展拳脚呢？

新人们，往往天真的以为，进了大公司，签了一个所谓的无固定期限合同，就是大公司的人了，生活和工作就会有保障了，工资和待遇就会稳定了。其实，我想告诉大家的是，在绝大多数的企业，包括大公司里，都没有所谓的“稳定与保障”一说，你的项目和团队，如果持续着一直没办法赢利，没办法为公司获得更多的利润，那早晚也一定会解散。

特别是，对于一个新的项目组而言，前途更是未卜。可惜的是，很多的新人看不透这一点，天真的以为进了大公司就象鲤鱼跳龙门一样，随后的荣华宝贵就会随之而来，我想说的是，世界上，从来就没有这样的好事，想要获得就必须首先要艰辛的付出。

人活着，要追求一种状态，一种向上的状态，一种只争朝夕的状态，而不能万事都不紧不慢，悠哉悠哉，到头来，你可能不仅失去自己的机会，也可能失去自己的团队和产品。要找到这种状态很不容易，而要保持这种状态，也不容易。让这种状态形成惯性，是保持它的好方法。

当你觉得足够好的时候，去放眼看看业内其它公司，他们是一个什么样子？是不是哪些方面比你作得更好？也可以去不断使用自己的产品，在使用中发现问题，体会问题，去不断的改进。保持这种作事的惯性，精益求精便是自然而然的事了。

作团队感悟(16)----连长+政委，黑脸+红脸

前记：

我们这一代人，与我们的父辈相比，对毛泽东或者毛选的感觉，可能截然相反，因为我们从小学到大学，已经受了太多这方面的“洗礼”，以致于，现在任何人再跟我们提毛泽东或者毛选，都提不起我们的任何兴趣，甚至，还会因为那场中华大地上的空前文化大浩劫一直对他耿耿于怀。

而其实，很多的时候，我们在总结一些作团队，作产品，甚至是作市场的经验和教训时，一些曾经非常熟悉的来自于毛的理论和概念又会经常浮现在我们的脑海，比如：把支部建在连队上，再比如：农村包围城市。前者，被很多企业用在自己内部的人事组织架构上，而后者，被很多企业用于产品和市场战略上。不得不说，毛的理论确实很符合中国实际，也很符合中国国情，这一点，直到现在，在很多领域都是，很值得研究。

这是一篇有关“连长+政委，黑脸+红脸”的作团队感悟，其核心思想是：作为一个完整的团队，既需要关注业务，也需要关注思想；既需要关注业绩，也需要关注团队成长。但是，如果我们把这所有的责任都推到团队领导者一个人的身上，显然不合适，也不现实，因为，团队领导者也是一个普通人，其精力有限，其特长亦有限。所以，团队内部，需要有人在这些团队领导者顾及不到的地方进行有效协助，而这个协助，应该是自发的，不一定非要某个固定职位的人来作。

引入正文----

从组织架构上，一个团队可以是这样的构成：一个团队领导者+若干团队核心+团队普通成员。

早在第一篇文章“个人信念与团队信念”里，我就曾说过，团队领导者和团队核心是团队价值观的主要构建者和传播者，整个团队有没有核心价值观，主要是看这些人能不能形成一个稳定的核心价值观。而其实，我还没有明确说的一点就是，在团队领导者和团队核心这样的架构里，还同样隐含着“连长+政委”的模式。

所谓的“连长+政委”，并不是什么新鲜概念，它另一个更通俗易懂的名字叫：把支部建在连队上。

之前，我一直很好奇，为什么毛泽东在文革中犯了这么大错误，毁灭了这么多了中华优秀传统文化财产和这么多的知识及社会精英人才，而后人还这样崇拜他，特别是，中国改革开放中形成的第一代企业家，其中的很多人，都把毛泽东的治军、治党理论用于自己的公司管理，其中一个影响深远而又非常著名的概念，就是：把支部建在连队上。

“连长+政委”，其最原始的意义，是要加强组织对军队的绝对控制力，“连长”，可以理解为业务骨干；而“政委”，可以理解为思想工作者，用于协调团队内部关系，化解团队内部矛盾。“连长”，保证了这个团队在业务层面可以向前推进；而“政委”，则负责团队内部人员的协调、流程的组织。

我们总说“作团队”，“作团队”，其实，在我看来，在你自己可以充分作事正确作事的基础上，所谓的“作团队”，在人与人关系方面，需要额外考虑的无外乎两点：组织架构和流程安排。前者，是团队的静态存在形式；而后者，是团队的动态存在形式。不断优化这两个方面，就可以让我们的团队水平得到不断的提升。

说回文前，其实，你只要仔细研究一下国内几个大企业的组织架构，就很容易发现“连长+政委”这种组织形式的影子，比如：华为，海尔和曾经的巨人。但是，在我看来，体会最深的一点就是，我们没有必要在人事安排上非要弄出两个人来，一个负责业务，一个负责思想。如果要学习，就学习它最精髓的内容。

它最精髓的内容是什么？

说白了，就一句话：业务需要有人作，思想也需要有人作。

甚至，说得更通俗一点：黑脸需要有人唱，红脸也同样需要有人唱。

“业务+思想，黑脸+红脸”，可以让我们既兼顾到业务，又兼顾到“和谐”。

一个团队，其能存在和发展，最终，还是要靠业务作得好，靠业绩作得好。但是，如果唯业务论和唯业绩论，又很容易让整个团队进入一种非常偏执、压力非常大的状态，所以，我们不能一味的施以高压以获得唯一的业务增长，在追求业务增长的过程中，还需要考虑到团队成员个人的感受，个人的成长以及每个人自己的个性诉求。

如果我们把“作业务和关注团队成长”这所有的事情都寄托在唯一的团队领导者身上，显然是不太现实的，即使他是悟空，恐怕也是分身乏术。团队领导者，也是一个普通人，我们不能把团队成功的希望全部寄托在“团队领导者必须是全才”这样一个虚无缥缈的幻想之上。

所以，从这个层面来说，在所谓的团队协作中，作为团队核心，应该主动去承担一部分业务或者思想工作。

既然团队领导者，没时间去作思想工作，那我们就可以帮把手，多跟团队成员沟通和交流，帮大家多化解一些对团队和项目的困惑；

既然团队领导者，现在只有空钻研某一块的业务，那我们就可以尽己所能把其它需要钻研的业务主动承担起来。

当然，这样作的前提，首先是团队核心要与团队领导者充分交流、沟通，并达成一定的信任关系。

也就是说，在我看来，我们需要把握和关注的，是“业务和思想”这两样最本质的东西，而不是“连长和政委”这两个虚无的职位。我们人人都可以成为“连长”或“政委”，关键的前提是，你有没有意识到，需要在团队中主动承担一些角色，而这些角色并不是一定需要某个职位才能去作的，利用你的影响力，利用你掌握的专业技能，找准自己可以努力的方向，去帮团队作弥补。这也是我一直倡导的心态，在任何时候，以积极的心态把好的影响力带给团队，而不是相反，只会抱怨和苛责。

身处团队中的人，会经常发现团队有很多不足之处，很多人，习无为常形成的惯性就是：只知道抱怨这不好，那不好，却林不曾想过自己从哪些方面可以帮着团队作改善。我想说的是，如果你老是这样，你最终不是成为怨妇，就是被这个团队淘汰，团队需要的，不是将自己置身事外的抱怨和旁观者，你是团队一员，理所应当成为一个实践者，发现不足，就要从自己的角度想办法去改进，虽然不见得都有效果，但最起码会让你保持一种积极向上的心态。而这种心态，无论你将来到哪里作事，都会让你受益良多。

作团队感悟(17)----小结一下我的作团队感悟

从第一篇文章到现在，我从多个方面总结了自己的作团队感受，其中很多内容是涉及到诸如心态、目标以及理念之类的东西，也穿插着介绍了如何把这些精神层次的东西注入到我们平时的实践中。

我总结这些，有两个目的：一是首先对自己这几年来团队和项目的教训及经验予以梳理，让它变成一种可被记忆、追踪的东西；二是，想给业内诸多，可能与我们当初一样，还处于摸索期和困顿期的同业们以些许的启发，以助大家早日走上良性循环的发展之路。

不管是哪种目的，其最终，我就是想让这种作事的方法、态度和理念可以被复制，要么被我们自己复制到其它的团队或项目，要么被其他的人来复制。

我不能也不敢说，这些作事的方法和理念是多么多么的正确，多么多么的好，但如果你是从第一篇文章读过来，你应该可以明确感受到这些方法和理念背后所深深铭刻的东西，那就是：从不说套话，务实至上。也就是说，我写这些东西，不是想获取一时半会的文章点击率，而是以对项目和团队的实用价值为上，不实用的，在我自己这里，首先就过不去。

但是，我建议，读者在读这些文章时，不要只当作一般的小品文来读，要有自己的独立思考，要想想这些办法有哪些可以被导入到你自己的团队和项目。

在这些文章里，自始至终所渗透的一个理念就是：在任何时候，主动、积极地作事，坚持大产品观和大团队观。其实，这16篇文章，就是从各方面把这个理念说深说透，让大家看看我们是如何把它付诸实践，付诸细节之中的。

我们的很多人，生活和工作没有激情，或者是因为环境，或者是因为待遇，或者是因为发展前途，但其实，我最想传达的一个理念就是：无论在何种艰苦或者困顿的环境之下，“选择以何心态活着”，都是只能而且完全由我们自己决定。

以向上的心态活着，你的工作和生活就会不断向上；

以萎靡的心态活着，你的工作和生活就会一直不振。

对于我们可以决定的事，要尽可能在各个方面想办法提高作事的效率和质量；

对于我们无法决定的事，也不要灰心，要通过自己的努力去影响事情向好的方向发展。

在写作这些文章的过程中，有很多人或发邮件或留言，向我咨询各种事的处理办法，其实，我想跟大家说的是，这所有的办法，只是一个外人的建议，其最终，还是需要你这个当事人来根据项目和团队实际作出正确决断，何谓正确决断？判断标准就是：是不是对产品有利，是不是对团队有利。而且，从另一方面说，大宝的项目和团队经验尚浅，需要历练的东西还太多，提出的办法也不一定就符合每个团队的实际。

还是那句话：我首先，是要传达一种理念，而后，大家如果认同这种理念，就每个人根据这种理念去想问题，去办事情，要依靠自己，要养成独立思考和独立判断的能力，要不断打开自己的眼界，要不断思索精益求精的方法和措施。

也有人说，大宝你所说的这些心态和理念都太正面了，太理想化了，实际的团队和项目，其内情复杂程度以及所谓的阴暗面要严峻得多。是的，大家所说的这种情况都是事实，而我想告诉大家的是，我认为作大事者，不能仅仅只作到在所谓的各种利益团体之间周旋和逢迎，作大事者，必以大道而信之。

我追求的，是一种大道，一种既有激情又能自豪活着的大道，甚尔，我把它，当作是一种信仰。

我坚信：积极和主动会让生活更美好，”一定程度上的舍小我求大我“会给自己带来更大的成长空间。所谓“条条大道通罗马”，很多的人，使用各种不同的办法甚至是一些“歪门左道”、“趋炎附势”也一样可以成功，但，那不是我的选择，我也不想作那样的选择。

我想，在这个信仰普遍缺失、道德普遍沦丧的时代，总有一种东西需要坚守，总有一种理念需要传播，而这种理念，不能仅仅是高悬着供人遥望的灯塔，更要是山间崎岖小径旁的点点荧火，它并不遥远，也不耀眼，却可以在本是孤独无助的黑夜，引领我们一路向前。

后记：

这一个系列文章会写到什么时候，会写多少，以后的更新频率是怎样，现在都没有办法预计，但我会在平衡工作与写作之间，坚持把这些有益的东西不断总结出来，“作团队感悟”还没有结束。

作团队感悟(18)----如何引进开发方式

前记：

说中国IT浮躁，一种表现是，国外只要有个什么新鲜概念，国内圈子里就马上炒起来了，说：人家发明了一种什么什么开发方式，多么多么先进，效果多么多么好，要不我们也试试吧？

这是一篇有关“如何引进开发方式”的作团队感悟，其核心思想是：每个团队，都会在技术水平、团队氛围、心理心态等方面有诸多不同，我们不能武断地以别人对一种开发方式的评价而冒然决定在不在自己的团队中使用。即使是要使用这些新概念，也要根据团队实际情况进行改良和再造，抓住新概念的本质精神，对具体方式进行简化和借鉴，以求更好促进当前的开发。

引入正文----

敏捷开发，早已不是什么新鲜概念，但我本人对于敏捷最本质含义的理解，是在近一两年才逐渐深刻起来的。

我认为，敏捷二字的含义，至少有这样两层：

一是研发速度的敏捷，通过优化协作方式、设计方式等等快速推进研发过程；

二是对市场需求的快速响应，这个决定了产品的方向。

也就是说，在我看来，“敏捷”，是相对于整个产品线而言的，它绝不仅仅只是研发阶段需要，这个完整的产品线包含了：策划设计、产品研发、产品运营、客服反馈、市场营销等多个环节，敏捷的方法可以从研发拓展到其它多个领域，从总体上提高整个产品对于市场和用户需求的响应速度，从总体上提高整个团队对于产品战略的执行速度。

把“敏捷”仅仅理解为研发的敏捷，是一种狭隘，但研发的敏捷，是其它环节敏捷的根基所在。

单就敏捷开发而言，它本身只是一个概念，由这个概念衍生了很多可以让研发更快速的具体开发方式，比如结对编程，比如SCRUM。而无论采用什么样的开发方式，其最终目的都只有一个：又快又好的出产品，敏捷理论也不例外。“快”和“好”，成为我们不断为之追求的目标。

而事实上，当你对敏捷的应用越来越驾轻就熟，越来越心领神会的时候，你会发现，敏捷不只是一种开发理论，它甚至，是一种宗教。因为，它通过这种非常具体的方式在传播信仰，树立共同的价值观，这种价值观，就是：分享、务实、精益求精。这种体会，也在我们采用了SCRUM之后愈加深刻。

我们的SCRUM，严格意义上来说，并不是教科书上那种非常规范的SCRUM，我们只是截取了SCRUM中最精华也对我们最有用的部分加以采用。

早在前面的文章里，我就曾经提过，我们的研发是这样：

1。 制定阶段性的研发目标，之前的作法是整个团队有一个统一目标，现在已经变成每个小组有一个目标；

2。 在阶段性研发周期内，将研发任务拆解，我们没有特定的系统分析人员，每个人都从头到尾设计自己的完整系统，包括了：系统分析、编码、白盒测试；

3。 每天有一个晨会，每个研发人员都要参加，在这个晨会上，每个人简单讲三句话：昨天“完成”了什么内容；今天准备“完成”什么，需要谁配合；昨天的工作中有哪些教训和经验；

4。 在研发过程中，通过多种手段充分分享开发信息，比如：面对面的交流、IM的广播、电话交流等等；

5。 每个研发人员享有充分的自我管理权利，上级只关注你作的结果，而不再关心你作的过程。

由上面的几点可以看出，这种开发方式，要求每个人都能有良好的自我管理能力，要能管理自己的研发进度，研发质量和研发效率。但是，人无完人，并不是每个人都能很好的作到自我管理，遇到这样的情况怎么办？

我们的作法是这样：

1。 想尽各种办法，帮助他提高自我管理水平，比如：由有经验的同事传帮带，参与每个小组的小晨会和关键系统研发讨论，辅导他们的开发流程；利用各种方式将好的自我管理方法分享给其他人；

2。 如果他的自我管理水平实在太差，但他本人工作很努力，那就只有安排一些对自我管理要求不大的系统给他，把整个产品的研发风险降低；

3。 如果他不仅自我管理水平很差，而且不学习、不进取、不分享，我们只有放弃他，不会再在他身上浪费时间。

可能，我们使用的敏捷和SCRUM开发方式，会被很多正统人士认为并不是真正的敏捷和SCRUM方式。但我想说的是，我们学方法、学理论，最重要的，是抓住其核心点，要看怎么作才对我们的团队和项目更有利，完全没必要按照各种敏捷范式把相关的流程和人员全部准备齐了再来按书本上教的方式进行敏捷，每个团队完全可以根据自己的情况进行精简或者完善。

我始终认为，越简单的东西，就越容易持久。因为，越简单，就越能让更多数的人理解、记住并使用它。说到开发方式这一块，也是如此，如果一个开发方式的流程太过复杂和繁琐，它必然无法获得大面积推广。所以，在听到一种新的开发方式时，我会首先思考是否能用于我们的团队，而后，我会思考如何更简单的用于我们的团队，如果使用方式太过复杂，我不会选择它。

就各种各样的敏捷方法而言，我们绝不会教条化的去引进，需不需要用、能不能用，完全应我们自己的需求和感受而言。比如，对结对编程这种方式的使用，就是非常灵活的。

我们平时的开发，是以SCRUM为主导，以其它开方式为辅。如果我们遇到一块逻辑，在服务器和客户端的逻辑上是相似的，就会由参与者自己临时采用结对编程的方式，把这块逻辑作完。而一旦作完了这块逻辑，就又会恢复成各自开发的状态。

我听说，很多单位在采用结对编程时，为了让两个人能轮流编程，甚至采用了两个人只给配一台电脑的方法，在整个项目的开发期，都是两人用一台电脑。我不知道其他人在这种情况下会感受如何，就我自己的体会而言，我很反感这样长期的结对编程模式，因为它让我的工作环境没了隐私性和自由。在整个的研发周期里，编码只是其中的一个环节，还有很多其它的事要作，而这些事，我不想也没必要让旁边还有一个人看着。这样的方式，让我觉得太过教条化。

我们奉行的是，首先，要让作事的人自己爽起来，如果一种开发方式会让开发者很不爽，不管它多么先进，我们都不会马上强制采用，我们宁愿去花时间、花代价让开发者自己体会该不该用，能不能用，最终能自觉使用。

所有的所谓管理，其最终的落实，都在一个“人”字上，一种方式不行，我可以换一个，但如果你把“人”和“人心”给“毁”了，代价就要大得多。开发方式的选择要因应团队成员的现实状况，这个现实状况既包括了技术水平，也包括了心理心态，当技术水平和心理心态没到那一步的时候，强行推进一种开发方式，其效果只能是适得其反，在这种时候，我们更多应该考虑的是，如何更好更快的提高和改善大家的技术水平和心理心态。

本文来源：https://www.2haoxitong.net/k/doc/e2e2b36fb84ae45c3b358cf0.html