在我本科毕业的第一份工作中，一年左右的时间之后，我就不得不开始总体负责当时部门最重要的产品——短信网关——的全部设计和主要开发工作。
而这个产品，在落后华为，中兴等这些最强有力的对手半年的情况下，最后我们做到了中国移动总公司技术评测第一，这还是在完全没有为评测做任何特殊处理的情况下（而我们当时知道，一些竞争对手为了应对评测做了很多特定处理）。而在中移市场的占有率也做到了第一（当然市场的事与我没啥关系）。
对于第一次主导设计这么一个需要7X24小时的电信级存储转发服务器，交付时间（包括实施）却短到几乎是不可能完成的任务，可用之人也只有寥寥几个。但最后我们活了下来，并且活的还相当不错。
能够让我们活下来的首要原因就是基于优先级的持续交付。当然这都是被逼出来的。因为在那个阶段，项目每一天都挣扎在生死边缘。我们必须搞清楚客户当前最关心的需求和问题是什么，然后一个一个的完成，解决和交付。那时候，几乎每天晚上我们都会在客户机房呆到通宵。因为凌晨四点是我们可以升级系统的时间。而几乎每天晚上我们都在把当天完成的工作进行升级。
这也正是后来我一看到敏捷就认为其完全靠谱的最主要原因。因为那正是我们在极端恶劣的环境逼迫下出来的自然结果，也正是这些保证了我们漂亮的完成了一件当时看起来完全不可能的任务。
另外一点，则是我的整个职业生涯里不断被验证和强化的：团队必须小而精。靠人头堆不出来高质量的产品，相反只会陷入恶性循环：产品质量越糟，需要的人越多；而人越多，则让产品质量越糟糕。
在雄心勃勃的短信网关2.0的开发中，老板给我了30多个人，但我很快就意识到人头多只会让事情变糟。因而，对于最关键的核心网关，我只需允许5个人可以修改其代码，而这5个人，除了我之外，还都是必须两两结对工作。他们虽然聪明，但毕竟都是刚刚毕业的学生。因而我要求他们，对于任何一行代码，在编写时，两个人都必须一起讨论。至于其它人，我则安排一些周边辅助子系统的开发，以及测试类，文档类的工作。
当然，从长期看，这对团队其它开发人员是不太公平的。但是，以我当时的认知，既然老板塞给我那么多人，我站在产品质量的角度，就必须作出取舍。而确实也有一些杂活需要人来做。
而在后来的职业生涯里，我经历的所有成功的交付，从来都是靠精干团队来完成的。而在这样的团队，无论是士气，凝聚力，创造力，还是个体的成长，均非常出色。
在这样的团队里，工作对我而言是极享受的事情。每天醒来，我都会盼望着到团队去，和团队一起，去解决团队面临的每个问题。这也是我工作至今，依然享受和一线团队呆在一起，做设计，写代码，解决问题的重要因素之一。
而每个团队在运作一两年之后，团队成员单拿出去都可以以一当三；而合在一起，则能发挥出以一当十的战斗力。
所以，后来总是有人问我，一个由上千号人参与开发的大型项目怎样才能高效。我的答案总是很简单：先裁掉至少70%的人。或至少让70%的人别做关键的设计与开发工作。
人永远是第一位的。
而如何去评价一个团队成员的绩效，也是一件对于很多大公司都看起来非常棘手的事。
但这对于我似乎从来都不是一个困惑。因为在一个成员合作如此密切，每个个体对于团队的贡献都可以做到心中有数的团队，这本来就不应该是一个问题。
直到今天，我都从内心一直特别感谢我当时的老大。是她教会我，即便团队已经比较大，但作为一个Leader，每天都需要和团队的每个成员有所交流，每个人并不需要特别长的时间，但是我需要了解每个人当前碰到的困惑和困难，然后看我能为他做些什么。
而《快速软件开发》那本书则让我很早就了解到，一个人对于团队的贡献，并不仅仅是从直接的产出来衡量的。有时候，一个人是团队的开心果，让团队氛围更加活泼，从而增强团队的凝聚力，这种贡献不是能够直接衡量的，但对于团队的成功价值却极大。还比如，一个人，或许并没有那么聪明，但他能够特别积极的帮助团队承担脏活累活，毕竟每个项目都肯定会有些dirty work。
而站在技术的角度，真正的好伙伴，一定是那些思考和动手能力俱佳，能承受压力，愿意承担责任，而最最重要的是：拥有化繁为简的能力。团队能得到一两个这样的人，是团队的福气。
而从一个人提交的代码量来衡量一个人对于团队的贡献，正如通过代码量来评估一个团队的工作是否出色一样，是极荒谬的。我就在某个团队碰到一个人，其化简为繁的能力一流，本身2000代码就可以搞定的事情，他一定会做到8000行，里面充满了自己很多臆想的东西。
另外，团队给他的所有建议他都不愿接受，把任何一个人给他的忠告都当作对他个人的冒犯。最后，guess what？，他的老大在明知他满身缺点的情况下，最后竟然以他提交了很多代码做为他最重要的优点而让他继续留在了团队。
而事实上，这样的成员对于团队的伤害是极大的，无论是从产品质量的角度，还是从团队凝聚力的角度。这个团队也的确是我碰到过的最糟糕的团队。无论你花多少力气，都无法粘合那一个人给团队带来的裂痕。
而这样的错误在他么？不在，在他的老大身上。兵熊熊一个，将熊熊一窝。一个不知道团队究竟意味着什么的糟糕老大，才是毁掉整个团队的罪魁祸首。
因而，当你有决策权时，如果发现团队存在这类人，一定要果断请他出局，越快于好。另外，要想让你的团队有真正的凝聚力，一定要尽力帮助你的下属成长和成功，而不是和团队争功。争功的事，你做一次，就会毁掉你的团队。
而选择工作时，则需要时刻铭记：跟对人永远是第一位的。否则，你不仅成长缓慢，更重要的是，工作不会给你带来快乐。因此，如果不幸碰到不对的老大，一定要尽快止损，越快越好。
一直以来，我都觉得我是个lucky man，整个职业生涯碰到的老大们，几乎都相当不错。是的，几乎。
我一直认为自己是一个average智商的程序员。因为我确实见过一些非常聪明的程序员。而和我一起工作的团队成员，大多也都属于average智商。因而，当我看到我们这群average智商的程序员，能够在一段时间之后，整体战斗力提升到显著高于周边的团队时，我清楚的知道，这不是因为我们有特殊才华，或特别的方法论。我们唯一做的事情，就是全力奔着目标前进。
和我一起真正战斗过的团队成员都知道，我极少谈敏捷，我们做敏捷。或更准确的说，我们也不是在做敏捷，而是怎样有利于团队更快的达到目标，怎样有利于产品和团队长远的发展，就怎样做。敏捷那个词汇，不管它意味着什么，都与我们没任何必然关系。我们可以从中学习对我们有帮助的东西，但敏捷永远不会成为我们的目标。
尽管我经常会表现的像个理想主义者，但我实际上是个天生的功利主义和怀疑论者。我读过很多的书，但只有少数的书真正影响到了我。对于任何概念，方法论，如果从直觉上和我经验中的问题不符，不管它在当下有多么炙手可热，我也从来都不会首先选择接受它；除非有一天我碰到了合适的问题，而它实实在在的给了我启发和帮助。
而事实上，只要你在这个行业呆的足够久，你就会知道这个行业从来不缺新概念，但大多都是潮来潮去，最终归于沉寂。
哪怕对于一个直觉上靠谱的理论，如果我还没有经过在实践中找到它可以落地的方法，那么它对我就属于“然并卵”。
当我表现的像个理想主义者时，那是因为我确实经过实际验证，那些看似很理想主义的东西，实实在在的有用。
可能正是这一点，帮助了我的团队不会受外界声音的干扰，始终聚焦在问题本身，寻找最合适我们的解决方案。
毕竟这是一个靠结果说话的世界。
做咨询师的最大优势是：你可以不断面对新问题。新的客户，新的产品，新的文化，新的人。这会迫使你不断思考，时刻保持状态。你的经验，视野，能力也随之不断变得广阔。
而做咨询师的最大问题则是：成功之日，即是离开之时。当团队经过一两年的磨合和成长，达到紧密合作、高效产出的状态，你也和整个团队成员建立了家人般的感情时，那就是你要和团队说再见的时候。
尽管长期的咨询生涯，让我越来越习惯于说再见，但每次到了那个时刻，心中依然会充满失落。尽管你知道你和团队的友谊不会伴随你的离开而消逝。但是，你也知道，下一个团队，即便是一个很好的合作对象，却也必须从头磨合起。而这个过程又需要一段不短的时间。
因而，我真正想要的，应该是和一个已经磨合好的团队，一起去不断高效解决不同的技术问题。
看来我真的是个问题驱动的技术男。
技术，对于一个公司的商业成功有多重要？这是一个放在不同场景下，会得出不同答案的问题。
对于一个要靠速度，靠质量获得成功的商业公司，至少在它获取竞争优势之前，技术是公司商业成功的重要保障。而在另外一些时候，技术的价值更多在于帮助公司节约成本。而对于不断有大把现金流进来的公司，开发的成本就会显得不那么重要。
而从根本上，商业与技术，无非是做正确的事与正确的做事。当然前者更重要，但这却并不影响后者自身的价值和意义。
因此，这个问题，对于一个真正的技术人其实并不重要。既然那是你的职业，你也喜欢这份职业，而你的工作也在实实在在帮助公司创造价值，那就固守技术的本分，竭尽全力去把技术的事做到极致。你的职业生涯在于整个行业，而不是某个具体公司，具体部门，具体产品。
那么你的心究竟因何而动？
联系客服
