如何在工作中拿捏客户、领导、同事【让编程再次伟大#9】

UP主: 原子能 · 时长: 10:36 · 🔗 B站原视频

发布: 2024-05-22 · 收录: 2024-06-19

标签: 职场沟通 · 项目管理 · 程序员成长 · 需求分析 · 职场博弈

项目地位高于代码：普通人能影响的是“项目”

大家好，这里是原则人。本期的 MapGuard 我们谈谈另一个 project。就像上期视频提到的，项目地位是高于代码，产品地位高于项目。对于大多数一线的程序员和项目的参与者来说，产品决策权还是很遥远的事情。

在力所能及的范围内，我们最能够影响的就是项目的进展。不管你是项目经理、技术负责人、普通程序员，甚至是做测试的那位，都可以在项目层面做出贡献，让项目变得更容易。所以本期就由我来分享一些让项目变得容易的小技巧。

反向引导客户：别接“实现方案”，要拉回“业务效果”

在 MapGuard 的第 1 期我就说过：不要轻易接受来自客户的要求。一个软件项目最和谐的合作形式，是客户提出他们在业务上想要达到的效果，然后由我们技术团队来设计打造最优的实现方案。

很多情况下客户喜欢越界，提出非常具体的实现要求。要求越具体，往往越不靠谱。因为一旦在策划层面你轻易接受了这些要求，就会很大地约束自己的发挥空间。

所以要让客户不越界，就得让他们觉得：具体的执行方案可以委托给你负责。做到这一点，我的个人经验就是反过来越他们的界。

用业务洞察“越界”：主动加需求、主动算投入产出比

举个简单的例子。我以前有一个广告拍卖系统的项目，我们这边开发一个内部系统去对接一个外部的 DSP。广告业务部门相当于这次项目的客户。

在项目开始之前，我从头到脚调查了公司当前所有对外广告的业务系统和项目，以及市场上的行情，比如头部企业都有哪些、他们都提供什么样的功能和服务、当前市场的主流热点是什么等。

最后在项目策划会议上，我会主动给客户介绍一些他们没有提到的功能需求。这些都是精心挑选过的：大多在技术上很容易实现，同时能对业务有显著帮助。

这类需求只要对业务有所了解，一般都不难挖掘。因为甲方不懂技术，就很容易高估一些问题的解决难度。同时他们会非常欢迎这些建议：见过推托需求的，没见过主动加需求的。

但他们也会提出一些明显是在模仿头部企业做法的需求，实际上业务重点不在这里，不应该投入过多资源。这个时候不要用“开发难度很高”之类的理由去拉扯。我会从业务层面出发跟他们算账，算这个需求的投入产出比合不合理，引导他们削减需求的规模和复杂度。

就是这样，主动地反向越界：在业务层面和需求层面主动发声，把具体功能需求的讨论拉到业务需求层面。久而久之，你就能掌握项目的主动权。

别教条化套流程：规则越严丝合缝，越容易牵一发而动全身

说到项目管理，很容易想到各种各样的流程和规则。盲目套用各种流程规则，是很多项目痛苦的源泉。

我刚开始工作的时候，我们部门有两个大组。我们组负责人脑子比较灵活，立项、开发、交付，就这样。隔壁组非常规范，请了一个头衔是 Scrum Master 的大叔作为总指挥，后来他一路做到了组负责人。

这个大叔上来就设立了各种各样的项目流程管理指标。当时公司买了 Atlassian 全家桶，他全用上了，包括 Jira 上那些我这辈子都没打开过的 ticket 模板、整合流程和功能模块，他们组基本全部用了。有些小项目，管理流程本身都比项目更复杂。

结果我们组开发了三个系统全部发布了之后，隔壁组还在第一个系统的开发地狱里挣扎。

软件开发项目是极不可控的。随着项目推进，各种意料中的意外情况会频繁发生：业务方改需求、做到一半发现定义有问题要纠正、申请外部资源或资料比想象中更花时间、突发事件插进来要提优先级等等。

当你身上套着层层规则时，每一个意外都会导致全组调整。规则越严丝合缝，变化就越牵一发而动全身。后来我听到的八卦是，他们有些项目搞到后面大家都不遵守规则了：story point 随便乱写，审核流程也直接跳过。

我不是说项目管理流程完全没用。很多项目管理做法来自制造业，制造业是严谨、规范、精准的，细致的管理流程能最大限度提高生产效率、减少人为误差。

但软件开发，尤其在互联网时代，中心思想就是“小步快跑”，它和制造业的严丝合缝几乎是两个极端。所以复杂的流程规则很容易水土不服。

最合理的做法是做加法而不是做减法：从最低程度的流程开始，必要时才往上加，而不是一股脑把所有规则都用上，然后迫于现实压力再删减。还有，不要招什么 Scrum Master，你有这个钱省下来给项目组做奖金，对效率提升效果更高。

会议的真实成本：能异步就别同步，能缩规模就别罚站

会议从某种程度上说是流程的一部分，但影响力足以单独讲。会议一般分两种：对内的、对外的。

对内会议包括但不限于十几分钟的每日站立会、长达半小时甚至一个小时的周期性进度跟进会。这些很多都是浪费时间，因为它们是现代企业通讯软件发明之前的老东西，作用完全可以被聊天软件、文档、项目管理软件取代。

而且这些软件有一个无法替代的优势：异步交流。用小时候老师那句名言总结：你这个会浪费了每个人 60 分钟，8 个人就是浪费了整整一天。有些离谱的项目组能花 20% 的项目时间来开会，你算算浪费了多少。

对外会议，比如给领导汇报、向甲方演示，确实无法取消，但完全可以缩减规模。我说的是那些在旁边“罚站”旁听的项目组成员。我几乎没见过这些人在会议上参与任何讨论：进度由项目经理讲，演示由技术负责人操作，剩下的人要么发呆，要么用笔记本做自己的事。把他们拉进会议纯纯是形式主义。

这些被浪费的会议时间不仅影响项目进度，也会间接影响程序员的开发效率。写代码需要连贯思路，修 bug 也要连贯跟踪来源。写到一半被打断，去听一小时无聊会议，回来重新组织思路，刚找回节奏又被打断，这种感觉体验过的人都清楚。

很多情况下项目组会忽略会议带来的成本，是因为他们从来没把会议纳入开发排期。我见过不少项目组在排期时，会为了鸡毛蒜皮的小 task 扯皮半天，却没意识到：他们开会讨论这些 task 的时间，比 task 本身开发时间还长。

项目里很多矛盾不是技术问题：是角色目标和评价标准的问题

最后这个点听起来有点土，但每个开发团队都值得重视：即使在同一个项目里，每个人的角色、被委派的任务、验收要求都不一样。表面上大家为了同一个目标努力，但日常工作中每次交流、每个决策，每个人都有一点自己的小心思。

我见过技术负责人故意引进很炫酷的新技术新框架，除了他自己别人基本没用过。从他个人角度，新项目引用新技术对履历加分，甚至有助于加薪。但陌生技术意味着组员入门更久、应用更不熟，出错风险更高，最后拖累的是全队进度。

我也见过项目经理不和开发团队通气，就答应甲方一些很离谱的需求或非常临时的改动，为了显得配合、拿好评价。这样很容易把开发安排搞崩，尤其是非技术出身的项目经理，不知道表面看起来简单的改动可能需要后面系统大改。程序员对项目经理的仇恨值，90%都来自这种情况。

我还见过一些特别热血的年轻人，把全部精力放在抠细节上，抠到老油条都受不了。对新人来说业务不熟、流程不熟、框架不熟，要表现自己，热血就只能倾斜在能看得懂的技术细节上，比如代码规范、设计模式。他没错，只是有点轻重不分。

这些矛盾本质上不是项目的矛盾，而是人事的矛盾，或者说评判标准的缺陷。计算机行业过于注重个人表现，我觉得应该向体育行业学习。比如篮球评判球员优秀与否，不仅看得分篮板助攻这些能登记的数据，还会用更高级的数据统计他在球场上做的小事情：为队友卡位、拼抢地板球、队友失位时补防、无球跑动等。因为大家都知道得分篮板助攻是可以刷出来的，但只刷数据的人往往会成为毒瘤，数据刷到了比赛却输了就没有意义。

但在计算机行业，有大量企业和领导依然过于重视那些显性的成绩数据，导致大家更想在项目里给自己刷数据，而不是优先考虑团队配合。

回到本质：项目管理最终是人的配合与效率优化

其实在项目管理这件事上，《人月神话》这本“圣经”早在 50 多年前就把能说的都说了。这 50 多年来软件开发项目本质没多大改变，只是人更多了、工具更多了、场景更多了。

但好的项目管理技巧，最终还是人与人之间的配合，还是效率的优化。找准本质，我们总能让项目变得更轻松、更愉快。

我们下一期继续 MapGuard，拜拜。