项目管理：问题探讨与解决方案

在前面《25 - 项目需求如何有效梳理》文章中，已经说明过项目需求应如何依据实际情况进行梳理。不过，那是针对单个项目的情况。 倘若项目负责人负责多个项目，且这些项目之间存在一定关联，例如同属某个具体行业，此时，项目需求梳理就会面临问题。 该项目负责人所在团队有 10 人，负责项目 A、B 两个项目，这就需要两份需求文档、两个项目计划以及两个版本发布时间。 项目 A 的需求文档和项目计划 项目 B 的需求文档和项目计划 按理来说，这种安排并没有什么问题。然而，由于这两个项目均由这 10 个人负责，存在人员复用的情况，项目 A 的需求和计划一旦发生变化，就会对项目 B 的需求和计划制定产生影响。 对于项目负责人而言，项目管理的难度显著增加。一方面，需要在不同的项目文档里整理需求；另一方面，还需在不同项目中修改计划。 此外，还有两个版本发布时间，原本 10 个人负责的工作，却出现两个目标时间节点，无论是目标导向还是上下级沟通，都变得很复杂。 如何解决这一问题呢？ 一方面要简化项目负责人对多个项目的管理工作，另一方面要让这 10 个项目成员更具目标感和凝聚力，设定唯一目标，即 10 个人要在规定的时间节点前完成安排的任务。 鉴于项目 A 和项目 B 同属一个行业，可以把它们转为子项目，重新创建一个总项目，下设子项目 A 和子项目 B，如此一来，就只需一份需求文档、一个项目计划和一个版本发布时间。 但这里存在一个问题，总项目的版本号只是用来做需求规划的，项目 A、项目 B 都有各自独立的版本号，并没有办法沿用总项目的版本号。那么，如何将它们与需求文档关联起来，以便追溯呢？ 例如，项目 A 线上出现了 Bug，需要查看这个版本更新了哪些内容，才能判断 Bug 的影响范围。 假设总项目需求文档是 V1.0，而项目 A 当前版本是 V2.1，怎么在需求文档中查看项目 A 的 V2.1 迭代了哪些功能呢？ 我能想到的是，只需要在总项目每个版本的需求文档里，在项目 A 旁标记当前版本号，并评估这些迭代功能是否需要升版本号即可。 ...

最近，我发现有些事情安排下去后，如果我这边没有跟进到位，过一段时间，这件事情可能就突然没了下文。 起因是之前我和项目负责人沟通一件事，有个项目的原型和已有项目基本没什么差别，于是探讨如何复用和设计，以实现前端组件复用，减少工作量。 当时，我们在座位上沟通，也说好方案大概完成的时间。然而，过了一两周，我看项目需求文档时，发现上面压根没记录这件事。和他沟通后，他才又想起来好像有这么回事。 乍听之下，肯定觉得这是项目负责人的问题。但深入思考后，我才意识到，很可能我这边才是最大的问题。 为什么这么说呢？ 因为我习惯在滴答清单上列出每天要做的任务，每做完一条就勾选掉。这本身没什么问题，问题在于对于安排型任务，我也是如此处理。 通常我会和项目负责人在座位上沟通，把事情的背景、要做什么、为什么这样做以及要达成什么结果都说明清楚，然后给出大概的完成时间。 之后，我就在滴答清单上把这条任务勾掉，觉得事情已经安排下去，就算做完了。 但这个事情进入下一个环节，会出现哪些情况呢？ 如果项目负责人本身具备及时反馈的意识，那还好说。但要是项目负责人不重视，或者被其他事情干扰、疏忽了，而我这边又没有及时跟进，过了一两周甚至更久，才突然想起好像有这么一件事，那时可就晚了。 这个时候，我能去问责项目负责人吗？ 其实也不是不行，但对方也有理由，这一两周也没闲着，只是事情太多太杂，忘记了而已。 通常都是这类理由，所以问责也于事无补，反正也改变不了现在这个结果。因此，没必要问责，还是要从最本质的问题出发，找到最根本的原因，再通过一些策略彻底解决这个问题。 首先，从我自身角度来说，就是要跟进到位。那怎么解决任务跟进的问题呢？ 我想到一个方案，就是在企业微信上创建一个任务清单表格，把需求提出方、提出时间、任务内容、安排时间、计划完成时间、验收情况、进度情况都填写清楚，并实时更新。 每周都要梳理一遍上面的任务情况，再结合每两周一次的项目进度会议，及时更新任务进度。 如果出现任何问题，比如事情被遗忘、遇到困难、无法推进等等，及时沟通解决。等事情验收完成后，再在任务清单上标记已完成。我觉得这样就能解决上述问题。 总的来说，安排任务时，不能只是把任务分配下去就高枕无忧了。虽然每一条任务的发布和验收形成闭环是很理想的状态，但在这个过程中，及时跟进也至关重要。

1. 前言 项目总负责人究竟应该在什么时候介入项目呢？ 这个问题的本质其实是在深入探讨，何时需要项目总负责人直接替代项目负责人做出关键决策，或者直接介入并解决项目推进过程中遇到的具体问题。 下面以项目负责人为张三、项目总负责人为王七的实际案例进行详细说明。 2. 事情起因 曾经有一次，客户在项目沟通群里反馈了一个问题，明确提到平台的地图功能没有正常显示出来。 当时正值周六，按照常规工作安排，大家都没有在公司上班，因此项目负责人张三可能没有及时留意到沟通群里的消息，也就没有在第一时间回复客户。 后来，有看到消息的同事将客户反馈的问题转发到了部门群，这样整个部门的人员都能看到客户的反馈内容了。 可即便如此，张三仍然没有在部门群里对客户的问题进行回复。 3. 张三为什么没有及时回复 事后了解到，他认为地图功能并不是由自己负责的项目团队开发的，而是属于其他项目团队的功能，自己负责的项目仅仅是在使用这个功能模块而已。 也就是说，他在内心将自己定位为功能使用方，所以觉得不应该由自己来回复客户，而应该由负责开发地图功能的相关人员来处理。 4. 王七为什么没有及时回复 事实上，项目总负责人王七在周六当天也看到了客户在沟通群里反馈的消息，但他同样没有及时回复客户，就这样任由问题持续发酵。 王七当时的想法是等着张三去处理这个问题 —— 因为在他看来，这是项目负责人职责范围内的事情。如果王七事事都介入处理，就相当于虽然已经对张三进行了授权，自己却又在一旁指手画脚，这样的做法显得有些奇怪。 不过事后回头来看，王七在这件事情上确实存在考虑不周全的问题，没有全面深入地看到问题的核心本质。 5. 从客户的视角看问题 换位思考，假设你自己就是那位客户，在沟通群里反馈问题之后过了很长时间都没有人回复，会作何感想呢？ 而且需要注意的是，这次反馈问题的渠道不是工单渠道，而是群内的实时交流渠道，在这种情况下，客户即便不生气，心里也会十分不爽吧。 毕竟，客户在使用功能时遇到了问题，急需解决以便正常使用，而我们却没有给予足够的重视。 6. 张三的问题与改进 张三的做法乍一看似乎有一定的合理性，但他根本没有想明白关键问题所在 —— 对外和对内处理问题的方式是截然不同的。 在公司或者部门内部，上面提到的那种想法虽然存在一定问题，但还不是特别严重。 因为无论对外还是对内，项目负责人的职责本来就包括对项目整体的管理，一旦出现问题，第一责任人肯定还是要找到项目负责人，怎么会有出现问题先去找具体功能负责人的道理呢？ 正确的处理流程应该是：客户的反馈先到达张三这里，然后由张三再去找对应的同事沟通并解决问题。在对外沟通时，个人所代表的不再是自己，而是整个公司。 因此，每一句话、每一个行为都需要用公司的标准来严格要求自己。 就算明知道问题属于其他项目组甚至其他部门，如果该部门的相关人员不在这个沟通群里，也应该先回复客户，比如可以说 “我先了解一下具体是什么问题”。 然后再去寻找对应的同事，不管是部门内部的还是其他部门的，都要积极去协商协调，最终把问题解决掉。 客户不会去关注你是哪个部门的，他们只知道你是这家公司的员工。 不管在公司内部具体是由谁负责这件事情，客户只需要你帮忙解决他们遇到的问题，仅此而已。 7. 王七的问题与改进 当客户反馈问题之后，已经过去了五六个小时，张三还是没有回复客户。 这个时候，王七可能觉得这是张三的职责所在，认为张三需要经历这样的事情，而这也正是导致王七没有直接介入沟通的原因，差不多就是想让张三通过这次犯错来积累工作经验。 不过，王七也犯了同样的错误：从想法本身来看没有问题，把全部职责交给张三，张三就应该承担起相应的责任。 但关键在于**要弄清楚是什么事情，不可能什么事情都能用来攒经验的。**就拿上面这件事情来说，客诉问题，一直是重中之重的事情，不可掉以轻心。 正如前面所提到的，客户不会去关心你公司内部的分工情况，他们只知道你是这家公司的员工，你在客户面前的任何表现，都直接关系到客户对这家公司的整体印象。 所以在这种情况下，当张三没有回复客户时，如果过了一两个小时，张三仍然没有回复，那么王七自己就需要直接介入，回复客户，并跟进这个事情，弄清楚到底是什么原因导致了这个问题，确保问题能有效解决。 至于要问责或弄清楚张三为什么没有及时回复客户等事情，可以等事情解决了之后再说，现在首要解决的是客户遇到的问题，一切以客户为先。

在项目管理中，我们常会制定一些规章制度用以约束行为，从而有效推进项目。但现实中，无论是开会沟通通知还是口头传达的要求，往往只能坚持一段时间，过后便会恢复原状。 正如那句话说的：“你无法要求别人做什么，除非他自己愿意去做。” 工作中亦是如此，即便强调过每天下班前要在项目任务系统填写当天日志，对方也只能坚持一阵子，时间一长便又故态复萌。 同理，项目计划需要实时更新，以避免信息同步不及时影响后续功能开发或决策制定，但很多人依旧未能遵守，大多是坚持一段时间后便打回原形。 这种现象很难单纯用对错来评判。回归本质，我们的核心目的在于：将所有问题公开化，通过即时沟通制定规章制度，确保各项目有效推进，避免延期，最终达成项目目标。 那么，该如何解决这些问题呢？发脾气或许能起到一定作用，但也要看对象，而且大多数情况下并不推荐。更合适的做法是找个会议室私下沟通清楚，避免当众批评，以免引发逆反心理，得不偿失。 因此，我们需要探寻有效的解决方法。就以任务日志缺填这一问题为例（实际情况中存在的问题远不止于此，此处仅作举例说明），可以采取以下措施： 首先，将规章制度以严谨的文字梳理成文档，并建立惩罚机制。例如，约定任务日志缺填每月不得超过 3 次，否则需赞助50 块钱到部门经费 ，同时，项目总负责人自己也需赞助 50 块钱。 这样做的目的在于：一方面，项目总负责人作为全部项目首要责任人，理应对项目中出现的任务问题负责；另一方面，避免将自己置于项目成员的对立面，减少摩擦，让大家感受到你与他们是站在同一阵线，制定这些规定只是为了更好地进行项目管理，而不是针对谁。 在落实过程中，月底统计时如果发现有人当月缺填超过 3 次，就需要当面沟通了解情况，探究缺填的原因。 沟通时要因人而异，大多数情况下，只要解释合理（无论真假），都按真实情况处理，并明确告知此次可以通融，但下个月如果再出现类似情况，将直接收取 50 块钱，不再给予额外机会。 因为，我们的目的并不是为了这 50 块钱，所以，给对方一次改正的机会，让对方感受到被尊重，后续会更愿意、自觉地遵守这些规章制度。 但凡事也有例外的，虽然应该不多。如果下个月对方依旧出现，任务日志缺填超过 3 次以上的情况，该如何处理？ 这需要根据具体原因来判断：如果理由充分、合情合理，可暂时不收取费用；如果理由并不充分，则直接收取费用，并与对方一同扫码将费用赞助至部门经费，同时在部门群内公开，以消除大家对项目总负责人是否也一起赞助 50 块钱了的疑虑。 如果下个月仍然出现缺填且理由不充分，在要求对方赞助 50 块时态度还很恶劣，那么，就需要明确告诉对方：制定项目规章制度的目的是什么？任务日志的作用是什么 —— 让项目负责人能够实时了解每个人的工作情况、任务进度，以及是否存在影响项目推进的问题，以便及时采取其他方案。 如果对方依旧不服从，就需要强硬处理，因为规章制度刚落实时如果不及时拔除这根钉子，后续将难以服众。 总的来说，项目总负责人应以身作则，制定合理的规章制度，并通过实际沟通和客观判断，赢得大家的信任，促使大家养成良好习惯。 实际上，设置 50 块钱赞助部门经费的规定，重点并非在于金额多少，而是形成一种无形的约束。 理想状态下，一年可能就收个两三次，大概就 300 块钱左右。毕竟，钱好像不是很多，但是要让大家白白支出这笔钱，肯定觉得太亏了。相信这样应该能有效解决一些项目管理中遇到的问题。

这个问题最初出现在技术管理沟通群里，有群友提问：自己负责的项目任务已十分繁重，可领导还要安排新任务，不知如何是好。答应吧，担心自己所在的小组即便累死累活也难以完成；不答应吧，又怕惹领导不高兴。 我想起之前看《铁齿铜牙纪晓岚 4》时，有这样一段剧情：乾隆打算在凌烟阁挂上二十四幅功臣图，众人就谁排第一产生争执。乾隆使计让杜小月说出，若让纪晓岚进入军机部，也能像和珅一样出色，所以不同意和珅比纪晓岚厉害。乾隆顺水推舟，安排了角色互换的游戏，让纪晓岚去军机部，和珅去修四库全书。结果两人在处理不同部门事务时，因为缺乏经验，导致处处受阻，只能私下碰头商讨对策。 剧中，纪晓岚说皇上让自己查张廷玉的几块银两用在何处，觉得这点小事不必斤斤计较。和珅则表示，皇上安排的事情，最怕的不是大事，因为大事有章法可循，按章办理即可；最怕的是小事，没有先例，只能琢磨心思、见招拆招，所以对皇上安排的小事，要特别小心。 还有曾仕强先生在一期节目中说道：“如果老板让我去死，我到底去不去呢？” 他给出的回答是，先应承 “好的，老板”，然后自己不去就行了嘛。 从上述事例中，我们能得到什么启发呢？一方面要明白领导的用意，另一方面是不要直接拒绝领导。关键在于不要直接拒绝，而非完全不能拒绝。 其实核心还是 “先肯定后否决” 的策略，这和我们平时常用的标准反驳句式如出一辙 ——“你说的确实有道理，但是……” 如果是我，我会先一口答应下来，尤其是在多人场合。如果只有自己和领导两人沟通，拒绝的影响相对小一些；然而在多人场合直接拒绝，领导可能会觉得没面子。要是领导心眼小、心胸狭窄，日后难免会给你穿小鞋。所以，先痛快地答应 “好的”，然后过半小时左右去找领导，解释目前手头上的任务太多，若新任务时间紧迫，是否可以将其他任务暂缓？如果不能暂缓，多项任务同时推进实在难以完成，恐怕最后会顾此失彼。 这样做既能表明自己有积极完成任务的态度，又能说明客观条件不允许。领导的回应通常有两种：要么让你先暂缓其他任务，要么让你推迟新任务的完成时间，问题往往就能迎刃而解。当然，如果领导听不进建议，仍然一意孤行，直接干他就是了（哈哈哈，你敢信，我就敢说）。 由此可以延伸思考，领导安排任务时，必然有自己的考量。一般有两种情况：一是从当时的实际情况出发，认为由你负责更为合适；二是借此进行测试。培养一个人并非突然委以重任或提拔，而是通过日常工作中的突然考验，时不时来这么一下，看你瞬间的反应，从多个维度综合评估你是否值得信任、能否为我所用。 可能有人会说，公司的组织架构、管理方式和领导的性格等各方面情况都不一样，但我觉得核心逻辑是一样的 —— 先肯定后否决，只是在执行方式上，需根据实际情况调整。比如公司是扁平化管理，上下级没有明显的严格层级划分，而你对自己负责的项目情况又特别清楚，领导安排新的任务时，你完全可以直接当面解释目前的情况，说明加上新任务可能会导致的问题，而不必非要一口答应，等到半个小时之后才去找领导解释，那样做事就太死板了。 不过话说回来，工作和生活本就是一体的，但又不尽相同，人在上面的行事风格差异很大。工作上的这种测试是可以接受的，毕竟只是工作。但生活中类似的测试，真的不能接受，因为很没意思。