27-项目管理制度难以执行的问题探讨

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

2025-05-26 · 1 分钟 · 43 字

26-项目任务繁重领导还要加新任务怎么办

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

2025-05-19 · 1 分钟 · 20 字

25-项目需求如何有效梳理

现在我们的需求梳理方式,基本上就是一句话。什么意思呢?就是有一个需求文档,项目负责人把要做的事情依次列出,再对其进行评估,如果需要设计原型,就安排产品进行功能原型设计,如果需要提供解决方案,那么就先安排自己或其他开发成员提供解决方案。 好像没有什么问题?其实,真正的产品需求文档,也就是俗称的 PRD 文档,是很规范的,就不说什么形式上的问题,比如文档信息、版本更新历史、名词解释等等。就光内容的要求,就很精细。就拿 APP 的 PRD 文档来说,是需要把原型的图片贴到文档里的,然后要对每个功能和交互进行说明,比如点击这个按钮,会出现什么弹窗,弹窗的布局是什么样子的,内容是什么,文本是什么颜色的,是使用什么字体的等等。比如,XiaoPiu 的官方示例: 这样详细的好处是,在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述,那就是避免需求边界不清晰,导致后续的返工。 但是,对于我们现阶段而言,项目的需求应该怎么梳理呢?这个怎么说呢?如果是在大公司,分工比较明确,那么这样做无可厚非,精益求精未尝不可,但是,如果是中小型公司,或者只是一个部门,要自负盈亏,考虑到实际工作中的产出,或者说性价比,那么就感觉有点过度精细了,说好听点,是追求极致与差不多这个度怎么把控的问题,说直白点,是怎么利益最大化的问题。 所以,从实际情况出发,虽然 PRD 文档规范化,有诸多好处,但是投入产出比显然很低的,因为没有那么多人手把这个需求做到这么精细的程度,加上平时沟通也很及时,有什么问题及时沟通处理就行,而且,PRD 文档规范化还有一个重要的目的是,为了和其他部门或其他公司进行沟通交流使用的。 可是,只是我们部门内部使用的需求文档,就没必要这么精细了,只要能做好这件事情就行。但是,虽然是一句话需求,但还是有优化空间的,我们做不到整个文档规范化,但对这一句话的需求,可以规范化。 上面说的是 PRD 文档的规范问题,但其实,对于需求的整理,可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程(XP)的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写,帮助团队更高效地管理需求,确保故事的可交付性和价值性。 INVEST 原则主要用于优化用户故事的描述,使其满足以下特性: 独立性(Independent):故事之间减少依赖,便于单独开发和测试。 可协商性(Negotiable):避免过早锁定细节,鼓励通过沟通逐步完善需求。 有价值(Valuable):每个故事必须为用户或客户提供明确价值,避免资源浪费。 可估算(Estimable):团队能评估工作量以制定迭代计划。 短小(Small) :单个故事工作量控制在几天内,以降低风险。 可测试(Testable):明确验收标准,确保功能可验证。 结合我们部门自身情况,需求来源其实很多的,所以可分为两种,一种是部门外,另一种是部门内,如果是部门外,需要加上角色;如果是部门内,角色可不加。可以简化为,是谁?要做什么?为什么? 这里就以设备管理功能,写一个示例参考: 深圳客户希望能看到自己有多少台设备,方便统计和日常维护。 是谁:深圳客户 要做什么:看到自己有多少台设备 为什么:方便统计和日常维护 通过这种方式,既能保证需求的清晰性和可操作性,又能在现有资源条件下实现需求梳理的优化,为项目的顺利推进奠定基础。

2025-05-15 · 1 分钟 · 45 字

24-项目测试流程漏洞分析以及改进

1. 前言 项目发起测试时,首先要在 OA 填写软件测试申请单。填好之后,由项目负责人准备当前版本的测试用例,交给测试部门,同时沟通确定测试周期,之后才正式开始项目功能测试。 2. 线上版本出现明显的问题 最近有个线上平台,客户反馈说平台里有个列表的按钮怎么点都没反应,而且弹窗的样式也错乱了。可这个版本明明是测试通过才上线的,这就说明测试环节肯定出问题了。 3. 问题产生的原因分析 为什么会出现这种情况呢? 主要还是测试流程有漏洞。因为项目负责人提供给测试部门的测试用例,只包含了当前迭代的需求。所以测试的时候,测试人员就只测了新增加的功能,而出问题的那个功能是旧功能,因为不在迭代的需求范围内,所以压根就没测。 按理说,这个旧功能没做任何改动,怎么会出问题呢? 后来发现,在开发当前迭代需求的时候,有可能开发人员不小心动到了这个功能的代码,或者是在修复其他小问题的时候影响到了它。 还有可能是当前迭代需求其实和这个功能是有关联的,但我们只关注了迭代功能有没有完成,根本没管那些关联功能,这才导致问题在实际使用的时候暴露出来。 4. 测试流程改进办法 为了解决测试覆盖不全,又不想每一轮都全部测一遍浪费时间的问题,我们优化了测试流程: 项目负责人这边要提供完整的测试用例,还要标注清楚当前版本里哪些功能必须测试,哪些不用测试。 测试人员分三轮进行测试: 第一轮,不管标注的是不是必须测试,把平台所有功能的测试用例都过一遍; 第二轮,专门验证已经修复的 Bug,同时再把那些必须测的功能测一遍; 第三轮,等所有 Bug 都修好了,确定没什么大问题了,再把平台全部功能的测试用例再过一遍。 这样一来,既能保证测试全面,又不会做太多无用功。

2025-05-14 · 1 分钟 · 27 字

23-项目当前版本中修复上个版本测试反馈 Bug 的时机

1. 前言 项目当前版本(假设为1.0)开发完成之后,会提交给测试组进行测试,然后,开始进行下一个版本(假设为2.0)的研发工作。 但是,测试组测试周期可能要一两个月,期间会不断的反馈 Bug 到系统里,等项目当前版本(1.0) Bug 修复完成之后,再进行下一轮的测试。 这时,项目新的版本(2.0)功能开发进行中,每个人都已经有自己的开发任务了,时间也排好了,应该怎么安排? 还有,在 A 功能模块上修复 Bug,而同时又在 A 功能模块上开发新的功能,代码合并可能会冲突等等问题怎么处理? 2. 权衡任务调整的利弊 因为测试反馈 Bug 数量不是一个可控的事情,有时第一轮测试完成,都没几个 Bug,有时第一轮测试就反馈好几十个 Bug,完全可以衍生新的任务,评估个两三天去处理。 所以,如果你打算,暂停或推迟当前版本(2.0)的开发任务,而去执行修复上个版本(1.0)的 Bug 的任务,很有可能收益不大,因为可能都没有几个 Bug 让你修复。 但是,如果你完全对第一轮反馈的 Bug 不管不顾,又会影响到测试组的测试进度。 3. 基于测试周期的任务调整 上面说的,虽然测试反馈 Bug 的个数是不可控的,但庆幸的是,测试周期是明确的,比如第一轮具体是什么时间段,第二轮又是什么时间段,这些都是前期沟通好的,虽然偶有变数,但是大体上问题不大。 在这个基础之下,项目负责人就要根据测试轮次结束的时间,对当前反馈的 Bug 情况,进行任务上面的调整,比如第一轮测试反馈了 50 个 Bug,然后按功能模块划分清楚,以及哪些功能模块对应的负责人是谁,修复这些 Bug 需要多少工作量,新增一条修复 Bug 的任务在项目当前版本(2.0)计划中。 4. 测试环节的漏洞 但是,如果 Bug 特别多,花费了大量的时间,甚至影响到了当前版本(2.0)的开发进度怎么办? 这个时候,是否需要延长修复 Bug 的任务呢? 缩短开发的任务时间呢? 加加班? 这些方式可以解决这个问题,但是,治标不治本。 因为在这个功能到测试组介入参与测试时,其实,已经有过三个环节,对功能进行测试了。 一个是功能开发人员自测,编写测试用例,然后对开发的功能点一一测试。 另一个是功能开发任务验收,这个验收的工作就是根据功能开发人员提供的测试用例,验收人自行跑一下这个测试用例,看下有没有什么问题。 最后一个是项目负责人内测,就是项目当前版本(1.0)结束,要给测试组提测之前,把全部功能都测试一遍。 上面这三个环节,为什么不能发现和解决掉一些很明显的 Bug,而一定要测试组测试时才发现? 5. 优化测试流程 理想状态下,每一轮测试都不应反馈那么多 Bug 的,然后需要排两三天的时间去处理的,通过一两天差不多了,甚至在开发当前功能时抽个一天的时间解决掉就行。 所以,回答项目开发中应什么时候去修复测试反馈的 Bug 这个问题,那就是做好下面的流程: ...

2025-05-08 · 1 分钟 · 97 字