1.6　平台思维和情绪管理

不同思维模式，决定了不同的工作思路。进行思维模式方面的认知，有助于工作布局与决策。

1.6.1　项目制vs平台型

同样是IT工种，做属地订制化实施项目，与做SaaS化软件平台，是两种不同的工作思维模式：项目思维面向契约交付，平台思维面向能力建设。

1．项目型工作特点

就工作驱动力而言，项目型工作由需求与承接关系驱动，标准由需求方制定，承接方的重点是按期完成开发建设，考验团队在该细分领域的高度专业性和资源储备，包括同类案例经验，以及成熟可复用的（代码）干货，围绕SOW（工作任务说明）条款，进行点对点地实施、达标，项目具有短期性，拿到客户验收是衡量一切的标准，更是以结果为导向进行考核，资源调配相对较为被动。

项目模式的工作更关注业务分析，以及对技术栈的快速学习和代码上手能力。为了确保达到最短的交付时间，在既定配置下，团队不能将过多精力用于打造架构模式，后台架构师也难以在短时间内对一线工作进行直接支撑，因此，多数情况下，能够适度地在程序中运用代码级别的设计模式，就已经很不错了。

项目制具有周期性、攻坚性特点，多数情况下，在项目的周期内，一旦商业落定、启动开工，就需要团队全力以赴，周周打鸡血的状态最好不过，攻坚下每一个问题，最高水平的极致发挥，最大能量的冲刺，不遗余力完成交付。然后，在下个项目来临前，整个间歇期都是你的真正假期！

2．平台型工作特点

平台型工作，除产品需求驱动交付任务外，还有一半工作是自驱动，更考验主动规划力，平台的各项技术标准、各种公共抽象与共享、各类制度规范、环境的搭建、运维工作、安全工作，均依赖自己的团队来规划建设。

平台思维模式是一种互联网思维，一切都是开放的、去中心化的，实践中典型的工作特点和方法包括：顶层架构按照层级能力规划设计，如面向业务中台、数据中台提炼设计思想，以IaaS、PaaS、SaaS分层组织服务能力；更倾向合作借力，复用外部成熟的能力，擅长集成、桥接，广泛使用第三方（按流量收费）服务，乐于参与打造生态圈。

平台模式工作的长期性特点，必然要求更关注架构工作，更关注整体机制运作，更多投入到开源和创新型技术研究，通过架构底蕴推动对团队赋能，更加关注对平台中底层能力的建设、储备，依托中底层进行持续的技术发力，对交付形成长期的支撑。所谓磨刀不误砍柴工。

平台型技术工作是技术集团军的一场无终点的马拉松长跑，更需要规划性、持续性、稳定性的工作心态，不能急于流露所有的观点，不能力求于赢得每一次争论，也不需要事事第一时间做分工搞排期。在保持持久专注的前提下，“审时度势”“风物长宜放眼量”更为恰当，退一步海阔天空，避免快则不达。

1.6.2　不要愤世嫉俗

平台型技术工作的漫长工作周期中，很多中高级技术人员的发展，真正受限于对上游方（任务来源方，可能是商业方带来的需求，业务运营人员和产品部门的需求，以及监管和审计整改要求等）愤世嫉俗的情绪。技术“天才”们的内心独白经常是：“你们（上游）只会提要求，你们说的我都明白好吧，提要求没什么难的，技术上你们却什么都不懂”，进而发出自作聪明、居高临下的言论。“自我感觉良好”的思想，会让中高级技术人员在业务领域一败涂地，上游方却不会受到太多触动，他们之前或许就碰到过这样的家伙。

对项目型工作而言，一样会有这样的情绪，但是实在不行还可以申请调换去别的项目，或者“能忍就忍，忍过去、做完走人，江湖再见”，使得情绪的负面影响力小得多，这里说的有点极端，但确实是这个理儿，毕竟两种类型工作背后的商业模式不同。

满怀工作激情，但激情必须是协调的、正能量的，不要是带着愤怒、火气的激情。为业务服务是生存之本，如何与各相关方建立良好的关系，在分歧中前进，需要主动思考，克服思维格局边界，走出一根筋情绪的禁锢，是中高级技术人员的职场必修课。

成熟心态不是一天练成的，只能一天一天去磨练。

1.6.3　去除地盘意识

地盘心态在IT技术部门处处存在，程序员只愿意跟随自己最熟知的领导，产品经理给技术员工派活会让技术部门负责人很不爽，上层直接找下层安排工作让中间层觉得自己被忽视……以及“护犊子”“小帮派”这样的例子不胜枚举，这些都是地盘意识在作怪，究其根本源自一种自私心理。

继续追问，职场自私，这种占有欲，到底来源于何处呢？

第一是认知狭隘，第二是不自信，或追求虚荣的心理。

地盘意识，让很多技能优秀者，距离卓越永远差那么一步，却始终难以跨越。殊不知，一团沙子，你越使劲握，从指缝之间流失的就会越多。带队者必须要认识到，“员工是属于企业的，不是个人的”，部门工作更是需要建立公允机制，不能一言堂，一切以客观开展工作任务为导向。

去除地盘意识，分为面向技术负责人自身的和面向团队的。对于前者，更多是解决个人心理层面的问题，这不是一本社会科学书，我就不在此大用笔墨谈性格与人生观了。需要注意的是，地盘意识的思维惯性很大，并非一朝一夕可以克服，对此应该有一定的心理准备。

对于后者，我们把话题拉回软件平台技术工作中，下面给出实际指导。

1．团队间人员短期借调使用

可以把各个技术职能组职责划分清晰，但不要把员工划分得太清晰，同类型（同工种）的职能组之间尽量能达到人力共享、混用的效果，在东边开发工作紧张、人手不足时，去西边临时借几个开发人员过来，约定好借的时间（一般1、2个月内为好），对这些员工做好鼓励，在心理层面要给大家轻松、可信的氛围，这种主动寻找机会跨组调动员工的做法，打破组织边界，极有助于培养良好的文化土壤，对于提升团队作战力带来的价值、意义远超工作任务本身。不能等出现了强烈的地盘意识再去扭转，而是把其消灭在日常。

2．主动推行小范围轮岗

如果没有借调这样的契机，应该有意识主动去创造。任务不紧张时，可以搞一次小范围轮岗。对人轮岗与对系统进行切换演练，两者有异曲同工之处，不同的对象，相同的理念。另外，应进一步考虑，重要岗位是否可以建立AB角色？如何把人力共享、混用方面的表现，作为重要的绩效考核项？对技能难以胜任，或者考核不合格的员工，是否积极推动进行岗位调整？

3．设置A、B角色

设置A、B角色是很多企业中常用的方式，对于技术部门来说，可以对组、团队层级的技术负责人设置A、B角色，应该是作为一种公开机制，但建议不要把敏感度提升到“组织级别”这么高，以“技术考虑”为口径来解释更佳。A、B两者可不是“轮值主席制”，而是正职和有潜力的培养对象之间的关系。正常情况下，A带队，B不对A形成任何威胁，仅在必要的情况下，用于适当平衡话语权、降低A的地盘意识，是以良性发展为出发点的牵制策略。

找到适合的答案后，这些方法都可以使用。去除地盘意识，可以让团队如钢筋混凝土一般坚不可摧。

时常检视自己是否存在私心，时常关注去除技术组织和团队中的地盘意识，能够积极主动地大范围调度不同职能组的员工互相帮忙，是我多年工作中最可圈可点的。在这方面，每次合理的尝试，结果都是成功的，每次都是。

人的地盘意识或多或少是客观存在的，有时是不合理的组织方式造成的。

在我的第一份工作中，有一个转变至今仍旧印象深刻，我们大约12个经理负责某业务板块的系统建设工作，当时一共带了30多个系统，后来机构改革，组织颗粒度细化了，我们12个人被分成了4个组，30多个系统被分拨划开，对应分配到各个组。貌似大家有更多的升级机会了，但这个好处是表面的，实际结果是整体承载力出现了巨大的滑坡，原来有点活儿互相搭手就完成了，现在情况呢？如果需要帮忙，要先请示，对方组认为这个系统已经划给你了，因而百般推辞，沟通成本极高，事情推不动。

就像与同桌儿在中间划了条线，领地意识、官僚化，这样的情况愈演愈烈，有些工作如同陷入泥潭，是我离开第一份工作的原因之一。其根本原因是组织架构调整中，切分组的颗粒度错误，最终以地盘割据为果，“惩罚”了我们。这种形态下，不应该将主因归结为人的自私心，是组织方式让一直客观存在的自私得以膨胀。

具体看个人心态，也可以将其当作“成长的烦恼”而已。前面说了，不要愤世嫉俗。但无论如何，这个例子作为典型案例，是很具有真实说服力的。