下载掌阅APP，畅读海量书库
立即打开
求学期间不论是在校外找机会做项目、接兼职开发的活儿，还是完成课程作业与实践课题，一切内容无一例外地属于小团队软件开发模式，每个人完成自己的任务，或是两三个人共同做一个任务，只要小于5个人，都算是小团队
模式。
小团队作战，具有更强的可观测性和可衡量性。
小团队作战，不会有委员会设计
问题，不会有分析瘫痪问题，一般也不会有设计过度问题。
小团队作战，会极致激发人类的艺术创造力。小团队不会期盼有救星。
小团队作战，既无项目管理角色配置，也没有软件测试人员，但只要有兴趣做某个软件，他们的代码质量就远高于很多现代企业里的团队。
小团队作战，是天然的“谁构建，谁运行”体系。微服务、DevOps……这些最先进理念所倡导的分工职责模式，在现代企业技术管理工作中，常因受制于部门墙、官僚思想而无法实践落地。这些难以克服的顽疾，对小团队而言，好像从来不是问题。
小团队不能盼望先有完美翔实的规格设计，然后编程。小团队会简化设计，关心编程和验证，以及对设计的同步修正。小团队对“提前设计”也抱有担忧，会关注如何让设计可以拥抱风险、适时变化。这些不正是可持续架构的核心思想，或者说是演进式架构所宣导的理念么？
我正式接触敏捷软件开发宣言，是在毕业后10年。敏捷宣言强调的四个核心价值是：个体和互动，高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。
求学期间的小团队作战经历，好像完美具备了敏捷的一切特征。换个角度说，敏捷，不过是职场上的乌合之众跟风一样的说辞。很多经理关心的不是公司如何成功，而是不承担决策失败的责任，所以，最安全的做法就是跟随大多数人的选择行事。
对于计算机软件开发，5～10个人是最完美的团队规模，沟通可以直达，不需要二级管理，单人效率最佳。我经常胡思乱想：软件工程是因为大组织、大团队的无能才造出来的学科，而项目管理，则是为低效的团队所配置的。小团队不需要这些。有句话说得好：“低位的人求安全，中位的人求公平，高位的人求价值”。在我眼中，学校中那些小团队创业者，永远处于高位的姿态，敢于创新、进取，即使失败也不曾真正低头。
我喜欢小团队的一切
，对真正的程序开发高手羡慕万分。从广阔的心胸和格局认识角度来说，越是争风吃醋，越会成为井底之蛙。因此，我从未以嫉贤妒能的心态看待真正的技术天才。相比于软件工程的社会性，在计算机领域中，我更喜欢纯粹的技术性话题。进入社会后，无论做多久的技术管理工作，纯粹的软件从业者们可能都会回到原点，用心审视技术本身。或许每个人的内心深处，都蕴含着对尖端技术的向往和追求，这是一份初心。
在那个技术创业的最佳年代，大概技术高手们没有必要“为五斗米而折腰”吧，毕业后其他人都开辟了独立发展的道路，宿舍里只有我进入了体制内企业的技术部，开始从事朝九晚六的坐班工作。离开校园进入职场之后，我再未能参与到真正意义上的小团队开发，再无机会去切身体会技术天才的艺术力。小团队的魅力，于我而言已渐行渐远。
在小团队中，几乎不需要使用软件工程来管理项目，小团队的天才们永远不会看一眼PMO办公室制作的繁复项目管理图。他们好像与现实格格不入，并以此为荣。我并非崇拜这种放荡不羁，但确实无比怀念这样的经历。
在企业的软件开发部门里，有一场永不停息的暗战，书生气的技术开发者与衣冠楚楚的职业经理（或是业务需求负责人）总是冲突不断，貌合神离。笔者见过这样的数据：即使最先进的高科技公司，大概也有80%的人无法从工作中获得真正的乐趣。仔细想一想，这样的观点不仅只是令人生厌而已，而是已经严重到成为“质疑人为了什么而活着”的哲学性问题。这正是“才华横溢的编程者，更喜欢单干”的原因。对世俗束缚的厌倦，古今中外大抵如此，否则为何会有陶渊明的那句“误入尘网中，一去三十年”？
有一项权威调研，在对学校教师的访谈中，有超过70%的教师认为自己的学术水平应该排在30%。将集体中每个个体的感觉加在一起，会得到明显错误的结论，这足以说明个体错觉的广泛存在。技术本身是客观的，可是一旦涉及评价、评判，则完全是另一回事。
如同“人之初性本善还是性本恶”的问题没有答案一样，我从始至终质疑技术管理的真实性。用“带有批判性的有色眼镜”来审视技术管理，可以帮助我们增加一些洞察力。下面列举几个读者并不陌生的场景。
●设计评审会上，事无巨细的模型让一切无所适从。细致的模型频被表扬，但实际上，这样的模型最后多数会变得面目全非。
●长达几小时的“巨大”周会，几乎耗尽了参会人的精力，仍无实效结论。对于我的大脑，连续运转1小时就会进入低效状态，如果失去了头脑敏感性，那么后面几个小时的会议意义何在？我很少从长时间会议的后半段感受到吸引力（或感召力）。
●技术决策者自顾自地提出一套架构想法，然后征求意见。但是其他人提的意见和建议，已如耳旁风，百无一用。技术决策者陶醉于自己构建的故事线中，浑然忘我、难以自拔。这并非是指责决策者的能力，这与技术管理工作的本质有关。尤其是架构管理，除非是明显荒谬或是有缺陷的，否则任何一个架构想法都很难被客观证伪。
这样的问题广泛存在于企业的日常技术管理工作中。放大至行业，技术管理者们创造出无数的理念、模式、战略。SaaS软件模式、中台化战略
、低代码平台等被证明是其中的佼佼者。而其余的大部分已经随潮涨潮落被人们所淡忘。很多主观意识形态的产物，并非硬核技术
，是“假”概念、“假”模式问题的重灾区。
以笔者拙见，从哲学角度看：管理学的主观性，决定其必然具有一定的“虚假性”本质。
著名的《第五项修炼》一书中有这样一句经典：“大多数管理团队会在压力下分崩离析，管理团队在日常问题的处理中可能运作良好，但是，当他们面对可能使他们陷入窘迫和危险境地的复杂问题时，那种团队性似乎就崩溃了。”吴军博士在他的《格局》一书中曾经讲道：“我从2007年开始做风险投资至今，几乎每一年都能看到共同创始人闹翻的事情。实际上，调解创始人之间、创始人和投资人之间的矛盾，成为投资人工作的重要组成部分。由此可见，共患难的朋友关系非常容易破裂。”这些观点都说明了管理在本质上具有相对性，难以从根本上摆脱人性的束缚。用难听的话说，就是“虚假性”。
多年从事技术管理工作，我的实践经历（作为凭证）足以印证这些观点的正确性，但因自己名气实在有限，用自己的语言毕竟难以服众，因此才引用大师们的金玉良言。
那么，技术管理又“真”在哪里呢？本书没有过多篇幅来讲企业管理，对于这个话题，希望通过一个例子，以点带面，将这个问题讲清楚。我小时候常经历这样的场面：一群男孩子蓬头垢面，在野球场上踢足球。这承载了我很多美好的回忆，同时，其中不乏值得思考之处：我们总是花很多时间用于吵吵嚷嚷，话题大概是“我们的球门摆得太宽了，要重新弄”“人分得不对，你们队伍厉害的人太多了”“不允许发力踢，如果踢出场子太远，自己捡球去”……再加上中间争吵谁谁犯规、谁谁进球无效。总之，有很多时间用在了扯皮上。还有很多次闹得不可开交，结果是不欢而散。
大家都不愿意看到这样的结果，来踢球的目的，当然是享受踢球，但是如此“内斗”却是为何？答案在于，这是必须要付出的成本。要想踢好球，必须将规则、规矩掰扯明白，不仅如此，甚至还要搞清楚谁是老大，谁的话语权是什么。这是在确定秩序，进行一场比赛、下一盘棋局、做一次游戏……对于任何既有合作又有对抗的活动，这都是必要的过程。正所谓“无规矩不成方圆”。
同理观之，IT技术管理也是如此。很多看似令人厌烦的管理类工作，恰恰是为了员工能够理解工作、执行工作、完成目标而做的前期准备和环境铺垫。
因此，最后需要以一个大转折结束本节内容。一个事物，虚假性越强，驾驭难度越大。难度越大，越是兵家必争之地，因此越是成功必不可缺之物。要在当今社会有所成就，单打独斗的成功案例越来越少，越发规范化、成熟化的社会形态，对技术创业者的高阶要求，必然是精通合理的组织分工、争取有利资源、获得广泛支持、善于利用人才。从这一点上来看，管理学无疑是门“真”学问，由不得半点虚假。小到技术管理、大到企业管理，莫不如是。