一年前，我还在新浪时，写了一篇文章叫做《关于“产品驱动”和“技术驱动”》。我在雅虎、淘宝和新浪都待过，这些公司都是产品驱动型的公司，我很熟悉，而关于技术驱动，我只听之前的一位同事谈过，他去过美国google参观，了解过那边的文化，我是从他那儿听说的“技术驱动”。

那时的我，特别信奉技术驱动的工程师文化，技术驱动除了公司老板要担相当的风险之外，基本没什么坏处，是一种非常好的IT公司文化，懂得尊重工程师，工程师的忠诚度和满意度一定非常高，人员流失少，而且能技术创新出很多精彩的产品出来。那时我很憧憬技术驱动型的公司，觉得那一定是工程师的天堂。我在新浪的级别还挺高的，领导们很器重我，给了我不少机会，带重要的产品团队、内部培训讲师、校园网络学院讲师等等，还在一年后给我涨了50%的薪水。可是即便如此，我还是离开了新浪，去了国内某家技术驱动型的公司S，因为我对技术驱动型的公司实在是太向往了。想来，对新浪至今仍有愧疚，希望以后能有机会以别的方式来回报新浪。

一年多以后的现在，我在S公司感受了一整年的技术驱动文化，作为一个扮演多重角色的员工(产品经理、项目经理、架构师、工程师、策划)，我对技术驱动的利弊有了较深的感悟，想来细说一下“技术驱动”文化中的各种问题。

S公司的确是家技术驱动型的公司，公司管理非常扁平，从一线工程师，到项目经理，再到公司高层G，共起来只有三层。G特别忙碌，所有的事都要到他那里汇总，由他本人处理并反馈。苦了他一人，却给公司的沟通机制、架构扁平化带来了实实在在的好处，是S公司得以有效运作的幕后功臣。S公司的招聘很严格，所有招聘都要过G这一关，G很重视工程师的能力，宁愿招不到人，也不招能力普通的人，而S公司对招聘人才很舍得花钱，能力不错的人，一般都能以高于行内平均水平的薪资入职，所以这里其实是有不少高手的。这点和我在《关于“产品驱动”和“技术驱动”》中描述一致。——但，你懂的，会说的人比会做的人占便宜，而且G也不可能对所有人的判断都正解，所以S公司里也有些实力一般但薪水较高的人，哪个公司都一样，S公司也不例外。瑕不掩玉，总的来说，S公司的工程师们平均水平是很高的。

公司员工的水平高，而且个个都是通过G进来的，而公司的管理而极其扁平，对于工程师来说，是非常理想的。但其实这样的机制也会有相应的问题，如果管理不善，就会像孟尝君的门客了，吃吃喝喝行，搞的声势也很浩大，但实际产出却并不怎么理想。后文我会就自己的经历详述。

进入S公司前，我跟G谈过，我想来S公司建什么项目，入职以后，果然没有给我安排某个现有的项目，从我入职第一天开始，就可以开始设计自己的项目了。我自己一个人又做产品设计，又做进度管理，花了两个月时间，开发出了产品的原型。拿着产品原型，我参加了公司内部的立项会议——公司每个月会举行一次立项会议，想立项的工程师们可以准备一份ppt，在这个会议上进行讲解，产品的形态、目标、受众、开发周期、人物力估算等等。如果立项成功，就可以正式立项，提交里程碑给项管办，然后招人开工。

我对这种立项的形式非常满意，这是自下而上的立项方式，和产品驱动型公司，自上而下的立项方式不同，一线的工程师们不再只是项目的执行者，他们也可以发挥自己的创意，凭借对技术的敏锐的嗅觉，技术驱动立项。在立项前他们可以很自由地去专心开发原型，因为工程师的质量比较有保障，所以原型失败的风险还是比较小的。这样的文化的确可以孕育出不少精彩的火花。

我的项目很顺利地立项成功了。但人员配给并没有按我预期的那样有11人，包括我在内，项目只有三个人。三个全都是工程师出身。另外两位也都是有六、七年工作经验的老手，技术能力过硬，是圈子里有名气的"牛人"。人是少了点儿，但人少有人少的做法，人多有人多的做法。我想一边推进项目进展，一边招人吧。但事实上，后来事情的发展和我预期相差较远。不知道是公司对产品不是太重视的原因，还是因为要严格控制招聘人员的质量，所以S公司其实人手并不足够的原因，后来给我加的人也只有一个实习生和一个美术设计师。而我的项目其实是个不小甚至很有点大的项目，为了保证项目顺利推进，我不得不扛起产品经理、项目经理、架构师和工程师诸个不同的角色。

这样是好事，也是坏事，好的是可以减少各环节沟通的成本，有技术背景的产品经理会非常懂得产品的各个特性性价比如何(功能重要性和实现成本)，而有产品经理title的项目经理可以更自主地确定各个功能的优先级，以及砍哪些特性留哪些特性。坏的是，产品经理和项目经理在决定产品开发周期和保留哪些性价比不高的特性时，会站在不同的角度进行PK，而产品经理和项目经理如果由同一人担任，很可能会出现“产品经理和项目经理联合起来砍特性，对工程师友好，但对产品不利”的情况，特别是像我这样技术出身的产品经理，会更加偏袒工程师。而S公司的一把手也是技术出身，所以也会较偏袒工程师，S公司的专职产品经理比较少，大部分成员是工程师，而这里由项目经理兼任产品经理的情况还是比较普遍的。近来S公司也意识到这个问题了，在逐渐加大产品人员的比例。

虽然产品经理和项目经理让一人兼任是利大于弊还是弊大于利有待商榷，但我个人是比较喜欢这种方式的。我对专职的产品经理印象不太好，可能我眼界比较小吧，我见到的大部分专职产品经理其实1对技术没有基础，2对产品认识并不深刻和有独到见解，基本上还处在一个到处抄抄，重排一下UI就叫微创新的阶段，门槛其实非常低，工作量不大，只会发号施令的催进度，提修改。而大部分工程师是非常勤奋的，看了很多的书，做了很多的研究，却因为岗位的原因沦为码农。再牛B的一群工程师，也扛不住一个不靠谱的产品经理。我还听到一个很荒谬却又现实的说法，“产品经理一个非常重要的本事就是吵架，不会吵架的产品经理不是个合格的产品经理”。这其实很病态。S公司让项目经理兼任产品经理，一方面有利于“技术驱动”，提高工程师们对产品的把控能力，另一方面，也有利于架构扁平。

但有好的一面，就有坏的一面。产品驱动型的公司，架构不扁平，工程师能力也普遍中庸一点，虽然工程师会感觉像个螺丝钉，不怎么受到重视，满意度欠佳，但同样的会降低他们对自己的”心理预期“，提高执行力。虽然架构不够扁平，有KPI机制制约工程师，是会官本位一些，遇到个糟糕的直接领导，很可能除了离职没有其他办法了，但对于产品经理来说，这样的团队比较好带，团队成员的执行力会比较高。而技术驱动型的公司，因为工程师们的职级都普遍较高——例如我带的团队，两位资深的工程师，一位和我职级相同，另一位职级比我高，而这些人又都是通过G招进来的”专家“，入职也好、分配到我的项目中来也好，都并没有通过我。以前我会觉得这样很好，产品经理应该只负责产品设计和功能优先级选择，项目经理只负责风险控制和进度控制，”管理“和”技术“应该是两条线并行的，工程师的级别并不需要比经理的级别低，国外的大公司似乎都是这样的，这样才是健康合理，非官本位的。当我刚进S公司，看到几个项目都是低级别工程师在带着一群高级别工程师做项目时，我觉得特别美好，这才是一个正常的团队，岗位和职级是分开的。

可是，我错了，我严重低估了技术专家们的”个性“。虽然在立项环节，技术驱动有着非常好的效果，但那只是对立项的工程师本人来说非常好。项目立项成功后，会需要加入其他工程师进入团队，其他工程师们又是如何看待项目的呢?他们并不一定喜欢这项目，只是他们没有立项，被公司安排进来的。特别是有了好几年工作经验，而且在业界较有名气的”牛人“，会特别有自己的想法和自己想做的事，加上公司并没有KPI机制约束，而他们又是G高薪招进来的，在某个层面上来，他们的虚荣得到了极大的满足，以“搞研究”的心态进入了公司。但其实我想任何公司其实应该都不会想招一些人进来纯“搞研究”，一定会需要他们有所产出的，“搞研究”和“做项目”之间应该是有个比例的，比如说前者只能占20%左右的时间，大部分时间应该还是在为公司“直接”产出有价值的东西。

但“牛人”们似乎并不这么想，这应该是个判断误差。这个美丽的误差就只能由项目负责人来承担和消化了——一个没有实权的产品经理来带几个心气高的 “牛人”做项目，简直就是恶梦，你总不能什么事都往G那里告状吧?这只会显得你管理无方，不会团队合作，不懂团队管理的艺术。可是，如果不往G那儿求助，又靠什么来让这帮牛人专心工作呢?无论从级别上，还是行政管理上，或者是招聘上，没有一关是由我来把的，这样的机制我拿什么时候来带领团队?这样的机制，真心管不住人，不好把控进度。而项目进度控制不好，项目失败的风险无疑是由产品负责人买单的。这很病态!不只是我的团队是这样，我认识的别的团队也有相同的情况，这是这种机制的难以避免的弊端。

我的项目是做一个平台，项目本身可以分为“平台”和“应用”两个大方向。平台 + 应用 * N = 我的项目。我们团队的工程师们喜欢做应用，所以平台我就一个人来做了，让工程师们都去做应用。我关注软件工程知识快三年了，深知软件项目管理应该重人性，不要靠施压的方式进行管理，这样的做法非常原始，而且效果不好，很可能团队气氛压抑，员工离职率高。特别是系统学习过xp和scrum之后，我对团队自管理，scrum master帮助团队对抗外界压力，同时对团队进行辅助的模式非常喜欢。在新浪的时候，我很好地实践过scrum，scrum的威力也着实让我见识到了。

本着人性管理的精神，有scrum作为支撑，我在项目开始的初期是这么设定项目的开发方式的：我本人做为“平台”的产品经理、项目经理和工程师，独立负责平台的开发，并提供平台和应用的接口文档和技术支持，但每轮scrum都会和团队一起分享我的原型设计图和开发进展。而其他工程师每人做一个“应用”，自己做自己应用的产品经理项目经理和开发工程师，同样每个轮次进行进度分享。我的初衷很简单，对几位资深工程师充分信任，团队自管理，我只负责把握大方向，应用做什么，只需要跟我沟通一下就可以，设计和开发的过程都交由工程师自己把握。我本人非常喜欢这种模式，我认为这是对一个工程师最大的信任和尊重，同时能让他们按照自己喜欢的方式做自己喜欢做的应用。但两位工程师给我的反应却是不断地对项目质疑，要把项目改造成他们本人喜欢的方向。这是我在带这支团队时遇到的第一个问题，牛人有自己喜欢做的事，自己没有立项去做，而是要将我的项目改造成他们喜欢的方向，和原本立的项完全不同。这当然不行!!立项是要负相应的责任的，我立了个项目A，却完全做了一个不相干的B出来，这怎么行。人员不是我自己的招进团队的，这点无疑成了日后一个巨大的隐患。

我否决了这个提议，然后发现工程师之后特别消极。这是我遇到的第二个问题，牛人有自己想做的事情，如果不是自己想做的事情，执行力就特别差，还经常在会议上特意唱反调。我特别头疼，却又拿不出有效的办法来解决，我还算是个口才不错的人，所以就事论事对一定不能松口的地方会详细解释理由，本着尊重对方的态度，希望能得到同样的尊重。也不是说没有效果，坚持这么做下来，效果还是不错的，但抵触情绪还是一直都有，始终难以完全化解掉。

再之后遇到了第三个问题，工程师们对“一人开发一个应用，多线并行”的开发方式不太满意，希望能集全组之力，合力开发一个重量级应用。因为我很清楚人多口杂，每个人想法都不同，特别是几个人都是“牛人”的时候，谁也很难服谁的道理，因为人手不多，而项目进度需要赶得紧，而我本人要开发平台，精力有限，与其让团队陷入合作时无尽的激烈沟通，不如每人完整负责一个应用，自己做自己的。但既然工程师们希望合力做一个项目，我就合他们心意吧。但合全队之力去开发应用时，牛人们跟我说“我们需要策划，我不做策划，我只负责执行”。无奈，我本意是希望位能自管理，自己挑自己喜欢的应用做，给予最大的自由度，但似乎两人并不喜欢这样，也许是他们的完美主义倾向决定了“他们无法挑出让自己满意的应用”，也许是对项目没有按他们希望的方向改变，而做的抵触反应，我不清楚。

但我没有后援，我虽是个项目负责人，要对项目责任，但我没有实权扣他们KPI，因为S公司压根就没有KPI。无奈只好我自己兼任策划。我来把东西规划清楚。但我预料的问题果然避不开，团队合作之后，开发进度并没有快多少，牛人们似乎并不怎么爱沟通，所以在分工之初，没有出现scrum说的团队自管理，自己沟通，确定接口什么的，只是分开写模块，然后集成时遇到问题。然后跟我说，一个人来做这个，我去做别的，两个人一起做速度只是1.2个人的速度，不快。我去，你早干嘛了?为什么一开始要多人一起做“大”应用?那做大应用吧，你得一开始商量好如何合作再分头行动啊，不，一开始自己做自己的，最后才告诉你只是1.2个人的速度。这是哪门子的多人合作?会合作吗?这像是资深工程师的做事风格吗?说到底，还是没拿进度当回事，没压力。

然后是第四个问题，公司的态度。公司的策略是放养策略，对立项的各个项目并不做过多干涉，甚至不怎么过问。项目缺人手，很难给你配，就我知道的，很多项目都严重缺人。这和产品驱动的公司又是截然相反的做法，产品驱动的公司对产品的开发周期，上线时间有非常严格的预期，高层会催，会问。很多时候给出的时间很不靠谱，而且时间点一旦定下来了，工程师们就是加班加点也要赶出来，时间和任务量基本都是定死的。以前我会特别反感这样的方式，特别是scrum提出的，只对当前轮次做清晰且明确的规划和预期，而对未来则保持一个粗略的预期，这样的开发方式才是靠谱的，才是能保证产品质量，才是保证工程师不会因为疲劳过度而离职的。

但后来我发现，对于产品驱动的文化，对时间有比较强烈预期的开发方式使用scrum才是特别有效的，因为这样的文化工程师长期处于紧张的节奏中，scrum对他们来说是恩赐。而对于技术驱动的公司来说，特别是放养策略来说，工程师往往是比较懒散的，特别是定位于“我来搞研究”的牛人来说，主观上就不会给自己上弦，客观上公司又不给压力的话，其实会对产品非常的不重视。再加上公司对产品不怎么过问，也不配充足人手的话，更会让牛人们觉得“公司根本不关心这个产品，进不进度的没所谓”，“这是项目负责人个人的项目，不是公司的项目”。这大大加大了项目负责人对执行力控制的难度。

我的团队就是这样，牛人经常出席各种公司外的活动，回到公司后也大量工作时间做自己感兴趣的事，“搞研究”而不是开发项目。我对这样的牛人非常反感，你喜欢搞些研究很好，你很喜欢参加公司外活动很好，可是应该分得清公事私事，如果公事对你有需要，请在工作时间之外再去做你的研究。工程师不关心项目的进度，认为那是“项目负责人的项目”不是公司的项目，公司对产品的态度有不可推卸的责任。以前我觉得能采取放养策略的公司，是特别伟大的，但现在我发现这其实给项目负责人带来了极大的麻烦。即使放养，也应该有套机制进行约束才好，就当是让项目负责人有个可以“狐假虎威”的依靠也好。不然，项目执行力低，责任归到负责人不懂管理上，其实是不公平的。

第五个问题，scrum和加班问题。scrum是不提倡加班的，希望工程师们能够在一个合适的强度下工作，尽量反映出真实的开发速度。但其实 scrum应该是用来解救那些被“时间点”折腾的工程师的。在技术驱动的公司里，工程师很可能并不劳累，相反相当松散，使用scrum反而是种约束，而不是解救了。因为第四点的原因，我不得以使用scrum来强制工程师们提高执行力了，但这里又迎来了新的问题，就是scrum周期结束时，任务完成不了怎么办?按照scrum的做法，如果没有特殊原因，scrum结束时应该尽量全部完成，如果实在完成不了，只要理由是合理的，不做什么责难。我也是本着这样的思想去处理的，可是，这里有个前提是你在开发的过程中，要全部投入到项目中来啊。如果中间你去做别的自己感兴趣的东西，最后周期结束了说完成不了，那 scrum还用来干嘛?scrum的宽松态度不是为了满足“不责难”这一点才存在的吧?如果宽松态度换来的是消极待工的话，那还有什么可以约束工程师干活了?完成不了就加班?靠这种原始且恶劣的做法来约束你上班时间干项目需要你干的活吗?项目经理被工程师逼着反敏捷,这估计也只有这种文化下才会出现的奇观。

第六个问题，情绪控制和吵架的问题。我是个很能控制情绪的人，一般情况下很难发脾气，我一直觉得软件项目管理应该采用一种合适的态度，能让全团队保持一种轻松愉快的工作氛围，活不是压下来的，正常情况下，能让自己按70%状态持续开发就行，按100%甚至120要求团队开发进度是不合适且无法长久的。和团队成员没有管理，没有上下级关系，大家按一个科学的软件工程方法，就事论事，按照合适的方法推进，所谓“管理”不过是指引方向和辅助团队排除问题的公仆，技术和管理两条线并行，各司其职。

可是我发现在某些情况下，你对事不对人，你控制情绪，你尊重人并不能换来同等的回报，很多时候反而惯着牛人越来越离谱和不负责任。回到负责任问题上来，项目是谁的项目?是团队共同的项目，是公司的项目，不是某个人的项目!你不是为我工作，是为公司，只要公司支持这个项目，哪怕策略是放养，那也是公司的项目，是公事。我再会控制情绪也会有控制不了的时候，如果不想干，如果觉得你腕大，如果不看好项目，请公开的提出来，申请离开项目没问题。如果待在某个项目里，却又不把项目当做自己的事，那么请离开，专心去做你的研究，专心去业内发扬光大你个人的名声去。人有时候是犯贱的，一直礼遇，只会惯着对方，并不会因此换来对方的理解和回报，这是我以前天真的地方，最有效的方法，还是该吵的时候要吵，不能一味惯着，特别是对牛人，特别是在技术驱动公司放养的公司里，管理还真不能过于人性化。总有人要做恶人，如果公司高层不做，那么只能由项目负责人来做了，最后项目被砍，负责的是牛人们吗?不是，是项目负责人。如果不反敏捷，不给团队压力的话，那执行力会低到令人发指的地步!可是这压力，还是需要公司给权的呀，不然的话，拿什么压?

就是因为公司扁平，技术人员腕大，项目负责人没有实权，公司放养，惯得工程师一身的毛病。项目负责人夹在中间，特别难受。就是因为有这样的问题，牛人才会跟你说“完不成能怎么滴，你能去跟G说让我离职啊”。很多人仅仅看到我要做的项目和公司配的人员数量，就跟我说，“我要是你，就不做了”。要是他们知道就这几个人，还有这么多软件项目管理的问题，更是有多远逃多远了。

技术驱动型的公司，对工程师来说，很好，但对项目负责人来说，却是恶梦。我听说google虽然是技术驱动的，但其实是有KPI考核的，只是考核机制有点特殊：每个工程师有一张成绩单，这张成绩单会由其他工程师来给他打分(不是产品驱动型那样，由他的直接领导打分)，分数越高，涨薪越快，薪水越高。如果成绩单差，薪水也会低。所以google的工程师对别人会特别热情，因为这和他的利益相关。

公司也并非没有觉察到工程师中很多人混日子，执行力低的问题。于是采取了项目末位淘汰，淘汰项目人员重组或直接遣散的策略。借此来淘汰掉懒散的员工，让优质资源保留下来重组。这样倒是也的确可以刺激团队的执行力，但效果并不明显，而且其实受到最大影响的不是执行力低的牛人，而是各位无辜且无奈的项目负责人。扬汤止沸不如釜底抽薪，这样下去，恐怕最直接的结果不是提高了工程师的执行力，而是打击了工程师立项的积极性，应该采用更好的方式来解决这个问题。

说这么多，我倒不是对牛人们意见大，其实我意见更大的是公司策略。现在这样过于宽松的策略其实是助长甚至培养了工程师的懒散、随意和不负责任。我想同样的这帮人，换个氛围不同的环境，也许表现会截然不同，什么水养什么样的人，是时候改改水质了。

S公司有勇气和胆量玩技术驱动，我很欣赏，可是S公司也应该想一套机制对工程师进行一下约束，一点约束也没有是会坏事的。理论上一群牛人在一起工作，全明星阵容，技术驱动加上放养策略，该产生多么另人期待的奇迹啊。可是现实却是，团队合作、个人追求与项目需要、执行力等到多个方面困难重重，如果没有一套行之有效的方法改善这种局面，未来堪忧。

更多信息请查看IT技术专栏