项目管理者和技术者的成才之路

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第四节惟手熟尔
    很多的高手，对于工具的本质并不是了解的。他写程序快，只是记忆中读过的、写过的代码多于别人；他思考问题比别人细致，只是因为他有过比别人更多的错误；他能带领项目团队，只是因为他经历过足够多的项目团队。
    这样的人可以算是能人：有能力的人。但未必真有识见，真有才略。
    我们看到：卖油翁一生卖油，临老了只得了四个字“惟手熟尔”。一个人的经验与技术，如果到了“惟乎熟尔”的程度，便也就进无可进了。
    陈尧咨所谓的“高妙之处”，与卖油翁一样都不过是手熟之技罢了。卖油翁把油杓举得再高一些，可能多卖几许油?陈尧咨把箭靶树得更远一些，可能多杀一个胡虏?
    浸淫于技法越深，便越容易忘记使用这种技法的较初目标和应用场合——就如同陈尧咨仅仅把射箭看成技艺，而看不到他作为战场武器的本质；亦如同卖油翁一味演练技法之高妙，而不考虑卖油才是目的，而技法只是表面。
    万幸的是，卖油翁终能悟到自己的神乎奇技，不过是“手熟”而已。而如今芸芸之中，众多的高手、熟手，可有多少还在买弄那技法之事，技巧之事啊?
    “尔安敢轻吾射!”当我在论及RUP(Rational统一过程)、UML(统一建模语言)这些具体的工具只是“工程之末”的时候，很多人愤而所言，与当时陈尧咨说过的话，又是何其相近?

第五节鲁班带了个坏头
    但是，问题的根源在哪里呢？
    现在，让我们先回到工程层状模型(EHM)图。我们会发现这样一个事实：在“团队”这个阶段(关注点)之前的整个思想体系，描述起来就是“程序=算法+结构+方法”。
    从另一个角度来看，于编程者而言， “结构”也只是一种描述现实对象的工具(面向实体)； “算法”则是运行于其上的一些工具(面向逻辑)。所以，“程序=工具+方法”这样的等式也是成立的。
    如果你愿意把问题想得更简单，那么你可以说：编程序就是拿一些开发工具，用一些方法来写逻辑。
    然而你再看看EHM图对这个阶段的角色的关注点的描述。是的，这个阶段的主要角色是“开发人员”，而关注点是“实现”。
    ——没错，这就是他们的本质特性。开发人员的主体，是关注于软件实现的工具和方法的。也就是说，他们原本就是愿意、打算并正在这样做的。如同我说愚公“如果闲得厉害，他们可能会去发明翅膀”，历史上这样“愿意、打算并正在这样做的”工程人员，比比皆是。
    先秦诸子中，有一“子”是公输子。他复姓公输，名班，居于鲁国。其实就是我们常说的鲁班。历史上，小到锯、刨之类，大到攻城机械都有他的发明。此外，传说他能削竹木为鸢(老鹰)， “成而飞之，三日不下"’，可见他技艺之高明。
    传统上，我们习惯于把工匠分成两类：器匠和技匠。前者“工而制具”，注重对新工具的发明创造；后者“工而制艺”，注重对工具更娴熟的、有创建的运用。两种方法都可以提高效率或提升品质。这样看来，作为工匠，鲁班在器匠与技匠两个方面都有非凡卓越的成就。由此，鲁班被认为是军事、机械、民用等诸多行业的奠基者。他同时被尊崇为建筑业的鼻祖、土木工匠的祖师，有“工圣”之称。在现代研究者中，甚至还有人给鲁班冠以 “中国科技发明之父”的称誉。
    然而，也正是鲁班给工匠们带了个坏头。他的成就掩盖了工程的诸多真相，使工匠们将视线停留在工具的用法和工具的构造之上。人们将具有这种品质的工匠称为“良匠”。
    “成为良匠”因此就成了工匠们的目标。但这个目标中却没有“完成工程”。因此鲁班所领的这个坏头，延展下来的结果，就是工程中没有任何工匠关注工程的完成——正如同我们从EHM图中讨论得到的结果一样，从本质上来说：他们更关注于“使自己成为良匠”的工具与技法。
    然而鲁班的问题，还不仅是这些。
    《墨子·公输》中记载了一段故事，说楚国想去攻打宋国，鲁班就为楚国造了攻城的云梯。墨子去见鲁班，鲁班说不过墨子，只好说是楚王想要攻打宋国。墨子又见楚王，楚王也说不过他，就说是鲁班已经造好了云梯，故而要攻打宋国。
    这里表达的逻辑是说：因为要战争，所以我造了利器；因为有了利器，所以我们要战争。
    这种逻辑是互证的。墨子已经说服鲁班与楚王“不必战争”，但还需要再证明“这不是利器”。因此墨子与鲁班以衣带为城、木片为器演战，结果鲁班“攻械尽”，而墨子“守固有余”。
    在这里我们就可以看到一个“以工具自恃”的鲁班。他与楚王都相信，因为有了更好的工具，所以一定可以攻下宋国。但是鲁班攻城的“器械”已经用完了，墨子却还有守城的“方法”。墨子以方法而胜工具。
    然而这还不够。鲁班工具用完了，他接下来的策略，是杀墨子则宋城不守。而墨子也有应对之策：弟子三百人守城，所以“杀臣，不能绝也”。
    这里又看到鲁班关注于技法、器物之形，而不关注实质所用的缺点。因为他并没有想到：消灭墨子，并不等于消灭“方法”。而墨子，深知器物技法的作用，是在于守城之实，而不是论战之虚。故而先命弟子三百人守城，后出而论战。所以从本质上来说，保住墨子的性命的，是团队的力量，而不是墨子的
个人智巧。鲁班这种典型的“工匠思想”，总结下来有三个问题：
》    以良匠之名为目标，而不是以做工程为目标；
》    以工具之利为恃仗，却不关注工具用在哪里；
》    以技法之巧为较量，却不知技法应为团队所用。
现在来看，这不都是大多数工作流软件开发人员(和技术人员)的问题吗?这就是根源。
第六节工匠思想
    软件开发圈子中，持有这种“工匠思想”的鲁班门生历来不缺(很遗憾，这其中也包括我)。
    只不过大多数人把这种“工匠思想”的来源看成“八九十年代的个人英雄主义”。他们认为这种思想是一种现象的延伸，而不认为是一种“开发人员的本质特性”。
    鲁班的虚名，给工匠们设定了用以安身立命的目标：成为良匠。我尽管要说，这是一个坏的表率；但也要说，这的确是好的品质。
    为什么呢?
    我曾经在给CSDN的一篇文章中写过：
    所以在我看来，不同的电子商务工程角色的确应当有他自己的关注点。这个角色能考虑到别人想不到的问题，固然不错；但如果他恪尽职守，只关注自己的那一部分，也是本分。
    我们在EHM图中说，工程体系的第一个关注点是“实现”。也就是说，你可以是“关注于自己能否成为良匠”的工匠，但是作为工程角色，你起码应该关注于“如何实现”。放在项目中，具体的要求其实就是：一项技术是以完成工程需求为目标的，而不是以彰显个人技术为目标的。
    对于管理者来说，重要的并不是“让大家都关注工程的每一个方面”(这事实上也做不到)。工程管理者应当认识到开发人员的“工匠思想”的本质，并善用之。如同我们前面说的，你认为工匠思想“是个问题”，它才是问题。
    我在Y公司和N公司都遇到过这样的例子。某些开发人员是编程高手、技术尖子，因此一些供应链管理者想“发挥他们更大的作用”。于是将他们提上高位，许以‘‘经理”、 “副总”这样的职务和职责。但这些人要么工作不得力，要么工作不开心。较终工作没有做好，员工也没有得到激励，反倒破坏了组织结构。
在很多公司看来， “当官”可能是对员工的较大激励。然而身处官场的人又如何能理解技术人员的思想呢?其实很多的开发人员，无非是追求更宽松的工作环境、更好的学术研究氛围。换而言之，他们根底上就是关注于工具与技法的。
    如果公司不能利用这些“本质特性”，非要设定他们的“仕途”。那与以矛击盾有什么区别呢?——我们说过，大多数矛盾都是自找的。
    公司应当给出员工“在技术方向上的发展路线”。很多大公司在这一点上其实做得不错。他们把技术职级与管理职务分开，使得技术人员可能通过技术提升来得到与管理者相近同的薪酬。但事实上，管理者整体的薪酬总是高于技术群体的，因此薪酬的激励终归有限。对于开发人员来说，吸引他的是无限的发展空间。例如当初微软打算用三百万年薪和数万股股票从Borland挖走Anders Heilsberg，未果。后来，盖茨提出给他一个小组