在这里，我们将简要描述一下研发过程的一般过程，在每个阶段的主要工作，人员投入，以及产出是什么。当然，采用这样的描述方式，我无意于误导大家采用瀑布模型来进行研发过程。瀑布模型不是说一点用都没有，但是，在实际中实用瀑布模型将把你们的项目拖入一场灾难中，因为他有意无意地排除了一个最重要的因素：沟通。在现在商业软件的开发过程中，缺少这个因素，什么都做不好。

然后，我们用PM的9个知识体系，作为我们的纲，来简要地说说，在研发过程中的项目管理。这里之所以用PM的9个知识体系，不是我企图抄书，而是综合看起来，这9个知识体系，总结得还是很不错的。你可以把几乎所有的内容放入这个框架中。所以采用。

OK,让我们开始吧。

首先，对于研发过程来说，我还是前面说过很多次的一种概念，不是说，我们懂得了理论上应该如何，就一定能够做好管理的。如果你的团队连SCM什么的都做不好，和一个已经能够执行日集成的团队。管理方式绝对是不一样的。所以，无所谓别人最佳实践是什么？要看，是否适合你的团队，是否能够为你团队带来效益。

下面，首先说说我对于三种程度不同的团队的一个建议，当然这仅仅是个人的看法（更加专业的，恐怕是CMM的5层模型，呵呵，也值得大家看看，多看看不同意见总是没有太多坏处的），说这些的最大作用是，需要你根据团队不同情况，抓不同的重点，不要胡子眉毛一把抓，最后恐怕什么都剩不下来：

对于混乱型团队：典型的做法是，听一点，做一点；带头的哥们站起来在办公位上大喊一嗓子：“改改！错了！”。然后大家就按照这个哥们的意见改。今天过来一个同仁，看看，说：“这不好！改改！”，明天那个同仁说：“那不好，改改！”，于是不断的镀金现象在无控制的情况下不断出现了。团队成员的日常工作似乎就是构造软件和修改软件，若有若无的测试使得软件...

查看更多...

说服能力，对于一个管理者来说，是非常非常重要的。你有时候需要说服你的老板（你总不能命令你的老板吧！），你需要说明你的属下（当然，你可以命令，但是效果往往并不是很好，特别对于软件行业来说，这一点更难受了）。

说服别人跟着你的道路去走，是需要很多沟通技巧和一点点心理学以及其他学科的东西的。我们在实际工作中，总是能够发现，某些人会使得我们容易听从他的意见，而有些人，总是让我们很难受，即使执行了，也感到不愉快。

一般来说，如果你希望说服一个人，首先要从对方角度出发考虑问题。如果你仅仅是说：我得到了什么，团队得到了什么。结果为了团队或者为了我，把别人整个都牺牲掉了。这种事情发生一次两次也罢了，但是老是被别人牺牲掉，恐怕就令人极其不爽了。你这时候，还企图说说服别人，无异于缘木求鱼啊。

如果你希望说服一个人，特别是一个下属，你需要指出这件事情对他来说利益何在，他可以通过这件事情得到什么好处？但是，不要去做一些很夸张的承诺。夸张的承诺也许能够一时生效，但是长起来说，将使得别人根本不愿意和你对话。谁愿意和一个骗子对话呢？

不要老是企图用权势去压别人。用权势来压别人，总是比较容易的。你是老板，我是干活的人，反正你发我的工资，无论干得好不好，你总得给我工资，不是吗？那么我就听你的好了，你说如何做我就如何做，不管理解不理解，照做就是了。如果一个团队，认为某个项目是PM的项目，而不是我们大家的项目，那么很多事情将变得很难做。如果对一个小型项目来说，也许问题还没有暴露出来，这个项目就结束了。但是对于一个长期的项目来说，如果还面临着快速的变化的高难度项目来说，如果这种想法植根于项目组团队中每一个人的想法中，PM你就等着郁闷好了……。

在告知对方利益的同时，也如实告诉对方，你可能失去的。原因很简单，对方不总...

查看更多...

这里说的活动发起能力，说的是当你需要推进一个新的事情的时候，你会如何推进这件事情，使得团队能够接收？这一点是如此的重要，因为，这个能力决定了你是否能够把你的想法落实在实际操作中。

最简单的活动发起能力，无非是强制执行，对一个颁布的新的做法，给予一个公开的解释，然后安排人员进行Check，对于不按照此流程操作的人员，给予强烈的负面反馈，使得团队按照自己的想法来往前走。如果你希望尽快地落实一件事情，这种看起来非常粗暴的做法，也能获得比较不错的结果。但是这种做法未必是最有效的，他看起来有效仅仅是因为这是最容易进行操作的，管理者也相对来说更省心。但是，说他不是最有效的原因是，这种做法依赖于强烈的压力，使得团队成员按照自己的做法来做。支持他的观点认为：依靠着团队执行某一个流程，然后发现流程的好处，把这个流程转换为自身执行的流程，那时候将不需要过于多的监控。但是从现实工作的情况上来看，这种现象似乎并不是很多。如果你所有的流程都是如此来监控，一方面使得管理成本急剧上升，另外一方面，压制了团队自我的创造力，因为团队已经习惯于在一种高压下进行工作，并且使得他们觉得任何对现在流程提出改进的做法，都面临一个风险，那就是你企图不执行流程。这一点如果扩展开以后，将使得事情很难操作。管理者过于忙碌，而且觉得团队很难管理，同时团队觉得自己象一个小小螺丝钉，没有太多的主观能动性。这是一个必然的后果。而且，相对的来说，这种做法是不能持久的，当压力被慢慢消除的时候，团队会放弃这种做法。

其实，我们来想一想，为什么某一些做法能够得到团队成员几乎全部成员的支持（比如尽量好一些的版本控制方式），但是某一些过程不是呢（比如强制需要团队做出尽可能详细的设计文档，然后再进行编码）？这一般来说有两个原因，第一，目标本身就存在着问题，这种目标并不能解决关键性问题；其次，做法是存在问题，...

查看更多...

在这个章节中，谈谈招聘和面试的过程，这是一个团队成长起来以后，所必然碰到的问题。那么我们如何做好招聘和面试工作呢？

一般来说，你的团队工作强度超过80%-90%的时候，你就需要适度来注意一下，是否有必要进入新的人员。因为人员使用到这个层面上，如果有一些突然的任务下达下来，你的团队将可能难以应付起来的。这时候，一般来说，要说服你的老板进行人员招聘。至于如何说，那是你的事情，在这里不准备展开说了。

一般来说，在决定招聘何种人员的时候，我会考虑以下的问题：

1. 目前团队中，工作最为紧张或者最为紧缺的人员是哪个岗位？在考虑这个问题的时候，要注意一点：任何团队，任何管理者基本上都处于资源饥渴状态，所以，你一眼看去，将都是需要资源的地方，但是你必须能够分辨清楚，你需要什么岗位。

2. 明确描述清楚这个人员进入公司以后，将从事的工作是什么？这一点很重要，假设你自己今天接收了一个新的同事，那么你将期望他承担那部份工作。至少在招聘期间，你不要期待于：等人员进来了，我再考虑他的工作任务是什么。这一方面会导致你在招聘过程中，目标将不断漂移；比如期待进来的人员做项目经理，但是在面试中，90%的问题，都是问你某个Java程序如何写。结果觉得不错，招进来了，发现当项目经理不太适合，如果是这样问题就大了。另外一个方面，也会使得人员进来以后，发现工作重迭，人员迟迟不能进入状态，导致工作满意度下降，在短期内离开公司。我们花了那么多精力和时间来招聘一个人员，如果结果不够理想，就不太划算了。

3. 考虑一下，这个岗位是否可以由内部人员培养顶替，比如让一个干得不错，而且总体意识比较好的人员，从中级工程师升为高级工程师？而从外部招聘一个中级工程师？当然，在考虑这...

查看更多...

人才依赖于外部空降还是依赖于内部培养，这一个问题不能一概而论。自己培养起来的人员相对的来说，对企业文化等方面理解比较深刻，和企业更容易丝丝入扣，但是新的思路不容易建立。而空降进来的人员，会快速带起一个团队，但是需要解决一个是否和企业适合的问题。这两点都很讨厌。

但是无论如何，都需要面对一个人才培养的问题。对于一个软件团队来说，产品的产出固然重要，但是至少同等重要的是，培养出来一支具有战斗力的团队。这支团队将在下一个项目中做得更好。一个管理者需要在这方面下更大的功夫。特别是承担People Manage工作的人员。

首先，先讲一个笑话，放松放松。事实上，我也亲身经历了这种过程。这是一种对付刚刚进入公司的新人，好像有个名词，叫做“蘑菇疗法”。说的是，刚进入公司的新人（特别是刚毕业的学生），管理者会把他往一个黑暗的角落里一扔，然后不时给你浇上一盆子“生物化肥”（就是大粪啦！），放这么个2-3个月。这种员工就会给培养成一种工作饥渴症。具体一点的做法是：就是找个角落，给你一台烂机器，然后开会的时候叫上你，平时也没有什么事情干，但是不允许你上班的时候干和上班无关的工作（也就是说，你实际上，就是闲着，什么都没得干）；然后，即使给你一些工作，也没有人给你任何的指导，就是让你这么自己胡乱做，然后干得不好，就是一顿批评；然后再闲着。很难受的。我经过了这样的疗法，大概有2个月。不知道他们是故意的呢，还是无意中如此干的。

突然有一天，一个项目经理对你说：“别歇着了，和我一起干项目吧！”，那时候，让你干什么，你都很拼命，而且这种害怕再次回到黑屋子的心理会不时影响你，使得你总是在一种工作渴望中。这种员工一般来说，工作会比较认真，而且危机感比较强，比较好使。但是这种员工，将来也需要再次教会他，不要去承担太多工作。呵呵。不过那是很以后的事情了。暂...

查看更多...

这一点，每个管理者的做法都不同了。有的人很严肃，有的人很没有架子。倒没有什么证据说明，一定严肃的管理者，团队的绩效高呢，还是随和的管理者的团队绩效高。

一般我习惯的是一种更加默契一些的团队关系，也就是说，我希望我们不仅仅是工作上的同事关系，也希望是私下比较谈得来的人。但是，我不刻意追求这一点，如果能够成为朋友，那么就是朋友；如果合不来，就算了。我没有意愿把工作中所有的人都变成私交的朋友。而且，一般来说，我也不会刻意给私交好的人员更高的评价，但是这一点是难以避免的，因为我们私下里价值观比较类似，所以相互观点也比较容易接受而已。但是这是一个鸡生蛋，蛋生鸡的问题，不想过多说。

我知道，很多管理者都希望看见团队内部很默契。但是一般来说，我们首要的目标还是绩效。没有业绩的团队本身对公司来说，就没有太多必要存在。而且，管理学上也没有明显的证据说明，内部关系很好的团队，就是一个高业绩的团队。只有证据说明，一般来说，一个非常高绩效的团队，基本上内部关系也不太差而已（我们最好不要从结果反过来推原因）。

我相对喜欢的一些Team Leader和属下的关系，是那种Team Leader作为一个环境维持者，他会替员工着想，同时，依靠员工完成自己部门的目标。在完成的过程中，他会团队成员提供各种建议。

总之，也许，我是一个相对来说比较平和的人，所以我一般来说，喜欢在团队中维持一种比较平和的气氛。希望我们工作得更快乐一些。仅此而已。

没有必要一定要同仁们把你看成什么什么人。你是什么就是什么。你在某一些地方上，也要能够容忍自己不如别人。简单得看待一些事情，总是让自己放松的事情。至于一些管理者，非得大家围着他转，才满意，这又何苦来着，你的生活又不是仅仅工作这一块。放松一些哦！不然会很累的。

查看更多...

绩效考核，是每一个管理者，每隔一个时间，都需要花很长时间来做的一件事情。而且是管理中很重要的一件事情，他绝对值得你花很多的时间去做。而且它的影响对于团队来说，将非常非常重要。

绩效考核可能仅仅是针对职责的考核，或者是针对目标的考核，我们先分析一下这两者之间的优缺点。

针对职责的考核，在每个季度（或者某个周期时间段，比如半年等等）末的时候，反馈上一个季度你所做的工作，比如我参加了2个项目，在第一个项目中承担设计工作，在第2个项目中承担开发的工作等等，然后针对这些业绩进行考核。一般我们推荐5分制的方式进行（100分的制度太细节了，而且不好处理，谁知道85和86之间的区别是什么啊？）。这是业绩的考核，然后，再进行行为能力的考核，比如执行能力啊，比如对公司的认同感啊，比如组织规划能力啊等等都是如此。最后做一个总评，就是你的绩效考核分数了。这种方式的优点是非常便于操作（上个季度做什么总是很明确的，而且针对任务的考核相对比较容易有说服力），缺点是，我们会仅仅关注一些自己的任务完成情况，团队的目标往往会被忽略掉。这种考核，直接的部门经理，会在每个员工身上花费大约2-3个小时（包括评价，包括面谈等等）。

针对目标的考核，则相对比较复杂很多了。在季度之初，部门会得到分解以后的部门目标，然后将这些目标分解到个人身上。并且和每个成员商量，这些目标是否能够达到等等。总之，是综合部门和个人意愿，达成一份双方认可的责任书。在过程中，基本上每隔一段时间要进行反馈一次，看看目标是否发生了变化；如果目标发生变化，则需要进行改变。然后在周期末对这些目标的达成情况来进行考核。这种方式的好处是容易把大家的注意力集中在公司的目标身上，目标不容易发生偏差；但是问题是操作难度太大，比如目标的分解是需要具备良好的能力的；而且对于一般的公司来说，稳定这些目标，在现...

查看更多...

一个管理者如果做不好授权这一块，那么对于团队和个人来说，都是一场灾难。一般来说，一个普通的管理者的直接下属的人数在7-8个之间。当然，随着工作的程序化的加强，相互之间工作差异性的减小等等，会增加你的直接控制幅度，但是这种控制幅度增加也不会很大，一般来说，直接控制12个人，几乎是一个极限了。到了这个极限以外，就需要来做分层的处理了。

这里就涉及一个授权。所谓授权，简单得说，就是把你的一部分权力，在某个情况，某个时间下，授予别人，这一方面使得你可以集中精力去做你最需要作的事情，另外一方面，使得属下承担责任，他们的主观能动性能够被最大地调度起来，从而更好地完成工作。这看起来很容易做，但是实际上，这是一个管理者最难做好的几件事情之一。因为有以下一些客观和主观因素，使得你的授权更加难以进行：

某些高管，要求你能够对手下人的事情了如指掌，那么你的授权就会发生一些限制。因为无论你如何授权，对Detail的控制程度都是超不过直接控制，所以，多次碰到一些询问细节的事情以后，将使得你不得不越来越插手各种细节的事情。这是一个占比例很高的因素。当然了，谈到这个问题的时候，我插一句，这并不是让你做甩手掌柜，什么都不管。我认同的一种管理者，是这样的管理者：他执行管理职能，并且在最影响部门业绩的领域中（比如如果你们的研发很成问题，你就需要花比较多的精力，投入这块的工作中），投入自己的精力，亲自做一些事情。现在纯粹的管理者，已经很少看见了。因为很简单，我们现在越来越看重实际的东西，而不仅仅是一些虚的东西了。呵呵，事实上，这样的要求也是部分的有理由的，因为管理者的一个责任是决策，比如你的项目已经严重Delay，你需要砍掉某些功能，那么砍掉哪些功能呢？这需要你对于客户的理解，对于项目研发进度的估算，对于各个Feature的成本估算才能做出这样的决定；当然，你可以说，这些...

查看更多...

OK，团队组建起来了。团队管理的东西太多了，多得几乎每一点都值得去写。但是最根本的，我认为无非3点：

1. 团队目标；

2. 团队规则；

3. 团队的文化；

下面展开，结合一些实例来说明吧。

OK，任何团队都需要一个目标，一个没有目标的团队，就象乡村俱乐部，仅仅是一堆人的聚会而已。没有太多的价值。目标能够使得我们在判断各种问题的时候，有判断的依据。如果缺乏一个目标，我们如何做都是对的，那如何还有战斗力啊？举一个例子来说，我们的目标是开发一个中间件产品，那么在作判断的时候，就相对比较简单了。比如，有个开发工程师过来告诉我，我们漏了一项东西，就是第三方接口的验证程序，如果缺少这个程序，等到我们的中间件和对方对接以后，出现大量问题的时候，排错成本很高。如果这是一个严格的中间件产品，而且我们的产品将要推出，那么没有什么可说的，即使开发难度大，成本高，也是必须去作的。但是，如果这个中间件目标是给我们的系统使用，那么这种验证程序，暂时是没有太多必要开发的。如果缺乏目标，这种问题会纠缠我们很多时候，公说公有理，婆说婆有理，实际上，问题的根源不是谁对，而是我们的目标是不明确的。顺便说一句，我在2000年的时候，非常惊讶于一些资深的管理人士能够迅速做出一些我认为很难处理的问题的决策。但是我现在至少明白，他们的心目中拥有一个非常明确的目标，并且有一条价值底限。用目标来衡量这件事是否要做，用价值底限来防止自己做出出格的决定，这样他们的决定也许不是最好的，但是大致也是不会错得太离谱的。这一点是如此的重要，以至于我决定在下面独立写得更详细一些，这里先放下，继续我们的话题。

团队的目标必须是清晰明了的，可能达到的而且有一定挑战性的...

查看更多...

Chief Scientist,Thoughtworks 2004.3 从无、到繁重、再到敏捷

多数软件开发仍然是一个显得混乱的活动，典型的“边写边改”（code and fix）。设计过程充斥着短期的、即时的决定，而没有完整的规划。这种模式对于小系统开发其实很管用，但是当系统变得越来越大，越来越复杂的时候，要想加入新的功能越来越困难，同时，错误故障越来越多，越来越难排除，一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期的感觉，从而对项目的完成产生了眼中的影响。

而“正规方法”（methodology），对软件过程有着严格而详尽的规定，以期使软件开发更有可预见性并提高效率，这种思路借鉴了其他工程领域的实践－因此我们称之为工程方法。工程方法存在了很长的实践，但是没有取得令人瞩目的成功，甚至没有引起人们注意。对这种方法最常见的批评就是他们的官僚繁琐，要是按照它的要求来，那有太多的事情要做，从而延缓整个软件开发过程。

敏捷型和工程型方法有一些显著的区别，其中一个显而易见的不同反映在文档上，敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档，从很多方面来看，它们更像是“面向源码”。事实上，它们认为最根本的文档就是源码。更深层的两个特点是：

1. 敏捷方法是“适应性”而非“预见性”的。工程方法试图对一个软件开发项目在很长时间跨度内做出详细的计划，然后依据计划进行开发。这类方法在一般情况下工作良好，但是当环境、需求有变化的时候，就不太灵了。因此它们的本质上是拒绝变化的，而敏捷方法是欢迎变化的。

2. 敏捷方法是“面向人”的而非“面向过程”的。工程型方法的目标是定义一个过程，不管是谁用都工作，而敏捷方法则认为没有任...

查看更多...

在团队这一章中，我首先提到的是团队沟通，因为这是最对于团队来说是最为重要的。特别对于一个软件项目项目组来说。我们在前面已经很多次地说到了这一点，软件行业的项目组将依赖于大家的沟通。在项目中，如何强调沟通都是不过分的。而事实上，绝大多数问题的出现，我们基本上都可以在沟通上找到一些问题的根源。举一个例子来说，我们很多人在工作中，都有一点感觉，我们之间的工作挂接不那么严丝合缝，似乎总是有一些灰色地带的存在，而正是这些模糊的地方，导致我们工作出现一些不和谐音。可以明确的说一点：这一点将在你的工作中，不断出现；而且随着你岗位的提升，责任的提升，这一点将变得越来越多。原因是，至少在现在我看来，任何组织结构都无法定义得如此明晰（因为我们面对着是变化越来越快的市场的这一个现实），所以，需要我们加强沟通，依靠沟通能力来弥补一些问题。

首先，团队沟通的成本上很高的，而且随着以下因素，沟通的成本会越来越高：人数的增加，工作地点的分离，缺乏共同的语境平台，不相同的价值观或者判断准则等等。

人数的增加，使得相互之间的沟通线越来越多，而且，信息的增加，不见得就一定能够把你导向成功，你将不得不判断各种不同的信息，从而使得成本越来越高。根据这点，我们在管理上，推荐进行单头领导（而不是多头领导）就是这个原因，我们赞成使用少量的高素质人员替代大量无经验的人员，也是基于这一点的判断。

工作地点的分离，也将导致沟通成本急剧上升。我不知道大家如何看待在这样的一个团队：我们的需求团队在北京，设计团队在上海，开发团队在武汉，测试团队在大连。如果是我看见这样的团队，将使得我很挠头。而且，但凡有可能，我极其不愿意使用这样一种团队，因为地点的分离，使得沟通和交流的数量和质量大大低于直接的面对面的交流。对于一般的开发团队来说，我希望他们不仅仅是在一个办公室里，而且更希...

查看更多...

下面我们要开始花很多篇章说管理了哦。如果对这块不感兴趣，请自行跳过，直接看后面的项目管理部分，但是我认为如果项目管理缺少人力管理这部分，就变得太不完整了。而且，我在项目管理过程中，一般对人员关注很多，所以，这里也就花比较多的篇幅了。

团队是如此的重要，以至于现在任何的岗位，都需要你首先是一个“Team Player”。那么团队是什么呢？首先不是一堆人在一起就是一个团队了，他只是一堆人的集合而已。我们想想，我们打牌的时候，和对家就是一个小的Team。这个Team具备了团队的基本一些特征：共同的目标（你们都想联合起来打败对手），你们有一些共同的工作规则（你们之间的默契，你们必须按照牌理出牌），团队的成功依赖于你们的共同努力（我最不喜欢和合作的牌友，就是一有好牌，就疯狂出打牌，根本不考虑如何利用双方的牌进行配合，然后抱怨你一手烂牌）。

同样，项目组也是如此，我们具有共同的目标（希望一个项目成功）；我们具有相同的一些工作规则（我们在一个规范下，进行研发），目标的达成，依赖于我们每个人的努力（缺少任何一个岗位的团队，都是残缺不全的，和离开成功希望越来越远的）。也就是说，我们是为了达成目标而集中起来的，我们的努力目标就是达成团队目标（以及在此过程中，达成自己的目标）。

这对我来说，就是团队！

说明白了团队，我们下面按照这样的思路展开吧：

首先说说团队沟通，因为他是基石，缺乏沟通的管理，根本做不好管理；

其次，由于团队管理方面涉及的内容太多，我取其中我认为最为重要的3点去说，然后展开一系列的话题，每个话题解决一个问题，当然这都是我的观点，看得不顺眼的就跳过不看好了。管理无所谓对或者错，只是个人的一种风格。

以此看来，用这种方法表述，对于个人来说，真的...

查看更多...

在上面，我们花了不少篇幅去写从一个项目经理眼中的各个角色。当然，还有很多角色被漏掉了，比如公司内部其他部门的人员，比如工程人员，比如售后人员等等，都没有很好地去表述他。这并不代表他们不重要。相反的他们很重要。但是，我也不想一一地说太多了。

软件是由那么多角色，人员配合才能顺利产生出来。其中必要的沟通和相互的谅解是必然的。无论做为一个客户也好，做为一个高层管理者也好，做为一个项目组中一员也好，只有大家都认识到这一点，我们才能构造出适用的软件。

其中，最为项目成功的最大的要素，不是其他的，是沟通！

贯穿于项目中点点滴滴的沟通，我们所做的各种额外的工作，绝大多数是为了沟通。在项目中，再如何强调沟通都是不过分的。

让我们为一个美妙的软件而合作，而沟通。

其实，对于很多软件人员来说，能够参与一个成功的软件的研发过程，都是一个美妙的过程。这是一个拥有无穷成就感的工作。让沟通，让理解把我们从一个一个软件噩梦中拯救出来！

祝福软件行业中的每一员，我相信，随着时代的进步，我们会做得越来越好。

之所以把客户列在其中，是因为客户也是项目组中的一部分，而且是很重要的一部分。

在这里，我主要想说的就是一点，如何和客户沟通。其他的部分，都不重要，但是这一点做不好，累死你也没有好下场啊。再往后，我们会讨论几个我们老是会碰到的问题。

首先，和客户沟通应该抱着一个什么态度？首先必须肯定的一点是：你不是什么救世主，客户不需要你来拯救世界；你也不要把自己看成帮助客户来改善他们的工作的专家，一般来说，这种态度往往得不到别人的认可，他们之前的工作已经做得很好了，不需要你来改善工作，你所做的仅仅是帮助他们更轻松地完成他们本来已经做得很好的工作而已。记住这一点！这很重要。这是一个沟通的站位问题。

其次，和客户沟通的技巧。技巧原则上其实很简单，这里我不准备详细说“服务客户技能”，这方面的内容，值得我为它另外写一篇东西。我这里就是简单说一说。你需要换位思考，首先考虑考虑你的客户的个人利益，企业利益，然后再考虑考虑你的个人利益和企业利益，如果都能符合了，那么恐怕就是一个好的提议了。比如要你的客户为你买单什么东西之类的东西，就不用说了，说了也是白说。一般的来说，对于客户方面的工程师来说，你首先最好知道他的背景，比如他是一个研发背景，希望将来在技术领域走得很深的人，那么你最好在适当的机会，提供各种设计分析等等内容，并且结合你的项目，提供一些结论性的东西，他会很自然去使用这些东西的；如果希望走项目管理路线的，记得组间协同和项目文档必须做得好，让他在汇报的时候，可以很轻松引用你的东西，那么将在他的老板心目中，给他造就一个人才的印象，这对你来说是很有利的；对于客户方面的中层管理者来说，一般来说，他们都希望事情能够安全做完，并且得到老板认同，那么不要用太多激进的东西会比较稳妥一些，而且他们喜欢看见数字性的东西，说明问题的时候，最好使用数字来说话，不...

查看更多...

高层管理者，这里之所以要提起，是因为，事实上，使得项目成功，在很大程度上也需要取决于高层管理者对于项目的一些做法和态度。那么做为一个项目经理的角度出发，我们期待于高层管理者如何呢？

首先，我们希望能够保证资源的供给，保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈，但是我希望高管们能够理解项目、工程的一般性原则，有时候，我们的确无法答应一些时间条件，不要和我过多地谈起我给你1倍的人，你是否可以少用一半的时间完成这种怪问题，我真的很难回答（当然，现在这种什么都不懂的高层管理者不多了，倒是看见不少底层管理者敢于对上面这个问题，回答“是！”）。如果我真的如此答应你，那么对于你来说，恐怕也是一场灾难。因为，我可能仅仅是因为希望扩大一些沉没成本而已，来使得这个项目更难以取消。

其次，我希望高管们，在一定时间中，维持一个相对来说比较稳定的环境，而不是变化多端的环境给研发团队，人的想法变化很快，但是一个项目目标老是改变，就很难受了。不是吗？至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化，但是不是说，去拥抱无节制的变化。比如，原先一个产品是为了解决项目中的实际问题而做的引擎，后期变成了为了演示而开发的引擎等等；这就多少让我惊讶万分了。

再次，做好你的事情，其他的事情，让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中，做为产品和市场方面的高管，每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱，对于一个新开始做的行业来说，在这段非常重要的时间中，我希望你能够提供更多的市场信心，找到合作者，找到我们产品的试用者，找到我们的合作伙伴，而不是一天又一天得和我讨论，项目何时开始编码比较合适。直到某一天，我的一个同仁对对方说：“某某，还是让周海峰负责研发方面的决定就可以了，毕竟他好歹也...

查看更多...