标签归档:认知

对于系统复杂度的认知:从滴滴超大型线上故障想到的

在当今时代,互联网已成为我们生活中不可或缺的一部分,涉及到日常的方方面面。无论是打车、购物还是社交,我们都依赖于各种应用程序。但是,这些服务一旦出现中断,就可能引起严重的后果。

2023 年 11 月份,我们见证了两次重大的网络服务故障:11 月 12 日下午,阿里云服务出现异常,导致依赖其服务的多个厂商及其产品功能受损,包括其自身的产品钉钉。紧接着,11 月 27 日晚,滴滴打车应用程序出现故障,直到 28 日中午才逐渐恢复正常。这次滴滴的服务中断超过了 12 个小时,引起了用户和司机的混乱和不便。

就在昨天,12 月 1 日上午,上海医保系统无法进行结算,网友形容「看病一分钟,排队两小时」,凸显了网络服务依赖的脆弱性。

特别一点说,滴滴出行在 2023 年 11 月 27 日发生的故障,使我们不得不重新思考我们对系统复杂度的认知。从滴滴的恢复过程中可以看出,系统经历了部分恢复、再次出现问题,数据混乱等现象。整个系统看似处于混乱之中,但在多方努力介入处理后,逐渐恢复稳定并重新运作。这个过程好比一个受伤的系统在逐步疗愈。

公众的反应也多种多样,有人归咎于滴滴的「降本增效」策略,有人认为是管理层的失误,还有人指责技术升级不当。但如果把滴滴看作一个整体的系统,它无疑是高度复杂的,由人员、组织结构和各种在线系统组成。这个系统的复杂性在平时可能被我们低估,因为每个人通常只关注自己负责的那部分工作。

要理解一个系统的系统复杂度,可以从四个维度来考察:组分复杂度、结构复杂度、功能复杂度和描述复杂度。

组分复杂性

组分复杂性是指一个系统中各个部分(或称为「组分」)的多样性、数量以及它们之间的交互关系所带来的复杂性。 这种复杂性主要体现在以下几个方面:

  • 1. 构成复杂性:也就是系统由多少个不同的部分组成,这些部分又是如何相互关联和影响的。滴滴出行的系统由订单处理、司机分配、定位导航、支付处理、用户反馈等多个子系统组成。这些子系统都有自己的运行逻辑和规则,而且它们之间还需要相互配合和协调。这些系统的交互和协调就构成了滴滴的构成复杂性。
  • 2. 分类复杂性:指的是系统内部的各个部分有多种多样,它们分布的规律性、差异性以及由于各个部分的不同性质带来的复杂性。如滴滴的用户包括乘客和司机,他们的需求和行为都各不相同。比如乘客可能有急需用车的,也有提前预约的;司机可能有全职的,也有兼职的。而滴滴系统需要根据这些不同的需求和行为来做出响应,如何处理这些不同的分类就构成了滴滴的分类复杂性。
  • 3. 规模复杂性:这是指系统内部包含的部分的数量和种类的多少。数量越大,种类越多,系统的复杂性就越高。滴滴的用户数量非常庞大,每天需要处理的订单数量也是海量。这就要求滴滴的系统必须能够在短时间内处理大量的信息并做出决策,比如如何快速匹配乘客和司机,如何计算最佳路线等。同时,滴滴还提供了多种服务类型,如快车、专车、顺风车等,每种服务类型又有自己的规则和特性。如何管理这些大规模的数据和多样化的服务就构成了滴滴的规模复杂性。

结构复杂性

结构复杂性关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。这种复杂性主要体现在以下三个方面:

  1. 组织复杂性:这是指一个系统内部各个部分之间的组织方式有多么复杂。例如,一个公司的组织架构,有多少部门,这些部门之间是如何分工合作的,就构成了组织的复杂性。又或者像滴滴系统是由多个子系统组成的,包括订单处理系统、定位系统、支付系统、评价系统等等。这些子系统需要协同工作,以提供顺畅的出行服务。

  2. 层次复杂性:这是指一个系统可以被划分为多少个层次或等级,以及这些层次之间的关系也会非常复杂。如滴滴的系统,从上层的应用架构,到底层的服务架构,再到更下面的物理架构层,每个层次都有其内在的复杂性,而层与层之间的交互和协作也会引入额外的层次复杂性。以基础设施为例,这些基础设施的任何故障都可能导致滴滴的线上故障。

  3. 过程复杂性:这是指一个系统内部的运行和交互过程有多么复杂。滴滴的运行涉及到许多复杂的过程,如订单匹配、路线计算、费用结算等。这些过程中都涉及到了大量的计算和决策,而且经常需要实时地调整和优化。同时,滴滴的运行还受到外部环境的影响,比如交通状况的变化、法规政策的变更、天气变化等,这些都会影响到滴滴的运行过程,使其变得更加复杂。

结构复杂性就是由于一个系统内部各个部分之间的关系错综复杂,使得系统的行为和性质变得难以预测和理解。

功能复杂性

功能复杂性实际上描述了一个系统在不同情况下处理问题的难易程度,包括预测、保持和调控三个方面。

  1. 预测复杂性:就像预测天气一样,系统未来的状态可能会因为很多不确定的因素而变得难以预测。如滴滴系统在未来某一时刻的状态,如,预测在特定时间和地点的需求量可能会因为许多因素(天气、节假日,甚至是附近有没有大型活动等)而变得相当复杂。

  2. 保持复杂性:保持系统稳定正常的运转也需要对各种要素进行精细的平衡,如遇到大流量的冲击,安全攻击,甚至爬虫或者某些 BUG,想象你在平衡一只装满水的杯子,这需要非常多的复杂性和一些精细的调整。

  3. 调控复杂性:如果你想改变系统的某些功能,就像在一个复杂的机器中更换部件一样,像增加某些功能,对于现有复杂度的影响,以及删减某些功能或子系统,对系统中的组分的影响,结构的情况等等。

在我们面对一个复杂系统时,对系统进行预测、保持和调控都是在钢丝上跳舞。

描述复杂性

简单来说,描述复杂性就是理解和描述一个系统需要多少工作量和信息量的度量。 稍微复杂一点,描述复杂性是从描述系统的状态的工作量、信息量以及存储量角度来定义系统的复杂性。它以数学的复杂性理论和信息论为基础,主要包括以下三个方面:

  1. 计算复杂性:这是指解决一个问题所需要的计算资源,包括时间和空间,也就是我们在编程时常说的时间复杂度和空间复杂度。例如,一个问题如果需要很长的时间或大量的内存来解决,那么我们就说它具有高计算复杂性。

  2. 算法复杂性:这涉及到解决问题的过程中的多样性和随机性。想象你正在解决一个复杂的拼图,需要尝试不同的拼接方法,这就是算法复杂性,描述了解决问题的过程中的步骤和方法有多复杂。

  3. 有效复杂性:如果你要向别人解释一个很复杂的概念,你需要多少话才能解释清楚,这就是有效复杂性,代表了描述一个系统的规律性需要多少信息。

在这些方面中,计算复杂性和算法复杂性主要关注解决问题的过程,而有效复杂性则更多地关注对问题本身的描述。

上面四种复杂性中,组分复杂度和结构复杂度看起来会有一些相似的地方,容易搞混,它们关注的角度和内容有所不同:

  1. 组分复杂性:这是关注系统中各个部分(或组分)的多样性、数量以及它们之间交互关系的复杂性。组分复杂性的关注点在于系统的各个组成部分以及这些部分之间的关联关系。例如,一个城市的交通系统中,公交、地铁、出租车、自行车等多种交通工具以及它们之间的转换和配合,这就构成了交通系统的组分复杂性。

  2. 结构复杂性:这是关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。结构复杂性的关注点在于系统的整体架构、层次关系以及系统运行的过程。例如,一个公司的组织架构中,不同部门的划分、部门之间的协作关系,以及公司运营、决策的流程,这就构成了公司的结构复杂性。

简单来说,组分复杂性着重于系统的各个部分和它们之间的关系,而结构复杂性则更加关注系统的整体架构和运行过程。在实际应用中,我们往往需要同时考虑这两种复杂性,以全面理解和处理复杂系统。

通过这种四种复杂性我们能较全面的评估我们所面对的系统的复杂度,不低估,也不过度夸大它的复杂性。

对系统复杂度的综合评估揭示了系统的脆弱性和潜在的优化路径,引导我们设计出更为韧性强、可适应性高的系统结构。这种洞察力使我们能够制定针对性的决策和策略,优化资源配置,创造更加流畅的用户体验,并在面对不断变化的需求和潜在危机时,保持服务的连续性与质量。

通过深入理解系统的组分、结构、功能和描述复杂度,我们不仅能够减少业务中断的风险,还能在持续的服务创新中保持竞争优势,实现系统的长期可持续发展。

提升开发效率的黄金法则:如何避免认知、沟通和非正常成本的陷阱

在前面的文章中我们聊了技术成本的精细化运营;聊了要识别出成本要素,找出每个要素的关键成本点,将成本定义为顾客付出的代价,根据成本的基本特性对其分类包括生产性成本、支持性成本、监察成本和浪费成本;聊了成本的核算以及成本和业务以及公司商业化策略的关系等等。

今天我们从一个技术团队的负责人角度来聊一下软件研发过程中的成本。

研发过程中成本主要包括研发过程的成本和对业务产生的影响而带来的「非正常成本」。而其中软件研发成本的核心是认知成本和沟通成本。

认知成本

认知成本是一个相对宽泛的概念,它涉及到所有获取、理解、处理信息以及进行决策的努力和资源。在一般情况下,认知成本可以分为以下几个部分:

  1. 学习成本:这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言,那么这就会产生学习成本。
  2. 理解成本:这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。
  3. 处理成本:这是指为了处理信息,比如进行分析、整理或应用,所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。
  4. 决策成本:这是指为了做出决策,比如评估选项、权衡利弊、制定策略,所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。

在实际应用中,降低认知成本通常是提高效率和效果的重要目标。例如,良好的用户界面设计可以降低用户的认知成本,提高用户体验;有效的信息管理和知识共享可以降低团队的认知成本,提高团队效率。

研发过程中的认知成本,其差异点在于对于事情的了解。从认知神经科学的角度来看认知成本又分为认知载入( Cognitive load )和认知投入( Cognitive effort )。

  • 认知载入是一个信息处理的心理过程,是装载、把…的信息加载到工作记忆的过程。
  • 认知投入是指在知识加工过程中付出的脑力及努力程度。

对于开发过程来说,认知投入往往相对平稳,成本的主要差异点在于认知载入,而认知载入和人的记忆相关。

记忆分为中短时记忆和长时记忆,中短时记忆一般只维持数十秒或数分钟,长时记忆可以存储很多年并可以被回忆,短时记忆中的内容如果不被刻意记录,可能会完全丢失。

工作记忆(Working Memory)是对短时记忆模型的一种扩展,代表一种容量有限的、在短时间内保存维持信息,并对这些信息进行心理处理操作的过程。工作记忆的内容可以源于感觉记忆的感觉输入,也可以从长时记忆中提取获得,并且后者是一个重要的来源。

据此,我们可以得出造成开发同学需要付出的认知成本的差异的关键原因在于:

  • 载入工作记忆中的代码内容来源:如果是自己编写的代码,它将唤起长时记忆中的回忆,更快地加载对代码内容的理解;如果是别人编写的代码,所有的内容需要经感觉记忆输入,它将变得较难理解,并需要更多的时间与长时记忆中的内容建立关联,或写入长时记忆;
  • 代码中的模式与长时记忆的关联性:如果代码遵循了一致的规范(包括命名、缩进、结构、接口标准等),大多数开发者都共享了这一规范(存于长时记忆),将能够更快地加载理解过程,从而提升处理速度;
  • 代码中的领域知识与长时记忆的关联性:与编写规范一样,领域知识是另一种可共享的长时记忆内容,它也能够加速理解的过程。

基于此,我们可以从认知过程的改进,论证得出减少认知成本,或者说在平时积累认知的方法:

  • 选拔正确的人:以选拔/面试的方式,找到满足认知成本的人;
  • 经常性的交叉评审代码:如果代码规模庞大,相比传统的代码走读方式通常为从核心模块开始,更推荐从活跃代码开始(如 30 天内的活跃修改范围),以更快地熟悉近期的工作;
  • 共享且强制执行的标准和规范:代码规范,数据库规范,文档规范……;
  • 共享的领域知识:包括系统顶层结构、如何开始工作和必须的业务知识,构建团队的知识库。

沟通成本

有同学说「白天在开会,晚上才能写代码」

有同学说「不是在沟通就是在去沟通的路上」

软件研发是高度协作的工作,沟通成本非常高。

沟通成本是指为了达成共识,传递和理解信息,以及协调团队成员间或者团队与团队之间的工作所需花费的时间和精力。在软件研发中,沟通成本包括以下三个方面:

  1. 信息交流成本:包括团队成员之间进行面对面交流、写邮件、开会等方式的沟通所需的时间和精力。
  2. 知识转移成本:当需要将知识或信息从一个团队成员传递给另一个团队成员时,可能需要进行培训、编写文档等,这都会产生一定的成本。
  3. 协调成本:在团队成员之间协调工作,比如确定任务分配、同步项目状态、解决冲突等,都需要投入时间和精力。

不管是哪种成本,从沟通的角度,本质是一样的,都是一个信息传输的过程

沟通过程中主体是发送者、接收者和渠道,主要操作是编码、传输和解码。

  • 发送者:沟通的发起者,本次信息传输的主导者;
  • 编码:整理信息,以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程;
  • 渠道:信息传输的载体,常见的渠道包括:语言、电话、文档、传真、电子邮件、各种 IM 工具等;
  • 解码:接收者对所获取的信息的理解过程;
  • 接收者:信息接收者、信息达到的客体,可能是一个人也可能是一群人,也可能没有人。

如我们想给比较多人的讲一个事情,一种性价比比较高的方式就是写文档或电子邮件发给这些人看,这个写文档/邮件,发给接收者阅读并理解整个文档的过程就是一次信息传输的过程,也就是一次沟通的过程。

在信息传输过程中,有较多的噪声会影响整个传输的效果,比如我们刚才说的写文档,编码的过程就是我们将想法、思想和逻辑转化成文档的过程,而每个人写文档的能力,对于问题的理解不一样,从而写出来的文档参差不齐,这里的差异就是我们编码中的一种噪声。

在语言沟通过程中,除了讲,还要听,做彼此的倾听者,沟通过程中随时调整沟通的方式和方向,以求达到沟而相通的目的。

从信息传输的模型来看,这里的倾听其实就是为了更好的解码,更好的接收传递过来的信息,而调整沟通的方式和方向是为了优化编码的方式,以适配对方的解码逻辑

汉字其实很形象地表述了听的逻辑,听的繁体字写法是「聴」,拆开来看,它要求我们听的时候要用耳朵、眼睛和心来聆听,这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」,这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」, 而且是根据对方的「斤」两来决定到底听还是不听。

从沟通的本质出发,降低沟通成本的策略可能包括:优化沟通方式和流程,提高沟通技巧,使用有效的工具支持沟通,以及建立明确的角色和责任,以减少不必要的沟通。

另外,从整体研发效率来说,可以设置不沟通的时间,如设置研发静默时间,专注于写代码。

非正常成本

非正常成本则相对难以预计和控制。它们可能源自多种因素,如项目延期、需求变更、技术难题、产品缺陷等。当这些问题出现时,团队可能需要付出额外的时间和努力来解决,这就产生了非正常成本。例如,如果因为技术难题导致项目延期,那么团队可能需要加班,甚至可能需要聘请外部的专家或顾问来帮助解决问题,这些都会增加非正常成本。

最为常见的非正常成本一定有过度设计和技术债务

过度设计是指在开发过程中投入的工作远超过解决问题所需的程度,这通常体现在过于复杂的系统设计、不必要的功能,或过早优化的代码上。涉及到开发、维护和产品质量三方面,这种过度设计会导致更多的开发和测试时间,更复杂的维护工作,以及可能降低的产品质量。

技术债务是指由于短期内的快速开发和决策,而在长期内需要支付的额外工作。例如,为了赶项目进度,团队可能会选择快速但不完美的解决方案,而不是花费更多时间来寻找更好的解决方案。为了解决技术债务,可能需要进行代码重构或重新设计系统,这将带来额外的开发和测试时间。此外,技术债务可能会降低开发团队的生产力,例如,如果代码质量低,团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

比较特殊的一种非正常成本是线上事故,线上事故对于任何技术团队来说都是一种非常严重的非正常成本。这类事故可能会对用户产生直接的影响,包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低,甚至可能导致用户流失。此外,严重的时候,线上事故还会导致公司的资产损失。

小结

在提升软件研发效率的过程中,技术团队需要有效地管理和控制「隐形」的认知成本、沟通成本和非正常成本。认知成本,包括获取和处理信息以及决策的代价,可以通过选拔合适的人才和制定共享标准来优化。沟通成本,主要涉及达成共识和协调团队工作所需的资源,可以通过优化沟通方式和明确角色责任等来降低。非正常成本,源自如项目延期、技术难题和线上故事等因素,其控制需要避免过度设计和及时偿还技术债务。

此外,团队需要有明确的计划,有效的项目管理和质量控制流程,并与业务部门和市场部门紧密合作。同时控制和防范线上事故也至关重要,技术团队需要在系统设计和开发过程中考虑安全性和稳定性,建立有效的监控和预警系统,并制定实施恢复和应急计划

因此,掌握这些研发成本的管理和控制,以及有效的项目管理和防范措施,构成了提升软件研发效率的黄金法则

你是团队的明灯还是卡点?聊聊项目管理中的角色认知与常见问题

一个技术团队管理者在带团队过程中常常要「通过别人的手拿到结果」,常常要主动去改变一些事情,去完成一些公司或上级的要求,甚至要自己去做一些事情……

仔细回顾一下,有没有出现你的上级绕过你直接找你的下属来处理问题,而你一无所知,只有出了问题的时候才知道?有没有出现你发起了一个事情,任务已经交给下属/其它同事来跟进处理了,到截止时间,结果和你想象中的不一样?有没有出现你实在忍不住,亲自动手把那块代码写了,一边写还一边吐槽,也就十几分钟的事儿,跟他讲的时间都已经上线了……

如此种种,是不是很是亲切,经常会遇到。这到底是哪里出问题了呢?

如果把这些事项都当作一个项目来看的,这些项目中有三个主要角色:发起人(Sponsor)、负责人(Project Manager)和核心成员(Core Team Members)。上面的这些问题大多数是角色错位,职责分工不明确或者项目成员本身对于自己所在角色的认知不清晰导致的。

今天我们就聊聊这三个角色,以及经常会出现的问题。

发起人(Sponsor)

发起人是项目的发起者,他们通常是公司的高级领导人或决策者,有权利和资源来推动项目的实施。他们的主要职责和特点包括:

  1. 确定项目的战略目标,并向所有相关方清晰地传达这些目标,一般不参与具体任务。
  2. 提供必要的资源和资金以支持项目的实施。
  3. 对项目有最终兜底责任,在必要时提供对项目的支持,解决可能对项目产生影响的问题和挑战。
  4. 监督项目的进度,确保其符合预设的目标和期限,在大方向上正确。

发起人通常是关键利益相关方,他们提供项目必要的资源和支持,并在决策中扮演重要角色。然而,如果发起人的角色和职责没有被正确地理解和执行,可能会出现一些「坑」:

  1. 不清楚角色:发起人需要知道他们的角色和职责,包括为项目提供资源、支持、决策和领导。如果发起人对自己的角色不清楚,可能会导致项目的推进中受到阻碍。

  2. 缺乏参与:一般表现为撒手不管,把目标提了就不管了,作为发起人需要积极参与项目的关键决策,以确保项目的成功。如果发起人缺乏参与,可能会导致项目偏离目标,或无法解决关键问题。

  3. 过度干预:与上面的缺乏参与相反,发起人如果过度干预项目的日常运作,可能会导致项目团队的困扰,影响项目的效率。

  4. 缺乏支持:发起人需要提供项目所需的资源和支持。如果发起人不能或不愿提供足够的支持,可能会导致项目的进展受阻或者失败。

  5. 沟通不畅:发起人需要与 PM 和项目团队保持良好的沟通,以确保项目的顺利进行。如果沟通不畅,可能会导致误解和冲突。

在上面的这些问题中,缺乏参与和过度干预是两个常见且严重的问题,这两个问题背后的原因是什么?

发起人可能因多种原因缺乏参与。这些原因可能包括时间和资源的限制,使他们无法深入参与每个项目;对团队的信任,使他们选择让团队自主执行;缺乏特定的技术或领域知识,使他们在技术性项目中保持距离;以及角色定位不明确,使他们不清楚他们在项目中的参与程度应该是多少。无论原因如何,发起人都需要保持对项目的关注,并定期与团队进行沟通和反馈,以确保项目的顺利进行。

发起人过渡干预的原因也有多种,概括起来为以下五点:

  1. 太想要: 发起人对项目结果的强烈期待可能促使他们深度介入每个环节,并且确保结果符合期望。
  2. 太着急: 发起人想快速拿到结果,这可能导致他们过度干预项目的进度,甚至可能在没有充分理解或考虑所有可能影响的因素的情况下,推动项目快速前进。
  3. 不放心: 如果发起人对团队的能力或执行力有疑虑,他们可能会更频繁地插手过程中的工作。
  4. 控制欲: 有些发起人有强烈的控制欲望,希望对每个项目细节都保持控制,这可能导致他们过度参与。
  5. 不知道: 如果发起人对自身在项目中的角色不明确,他们可能会尝试涉足所有任务,而非专注于他们应该完成的职责。

这样的过度干预可能会导致一系列问题。首先,它可能会打乱团队的工作流程和效率,因为过多的干预可能会导致团队成员混乱或者反复更改方向。其次,它可能会破坏团队的士气,因为团队成员可能会觉得他们的专业能力或决策权被忽视。再次,过度干预会阻碍团队成员的成长,特别是对于 PM,过度干预可能剥夺他们解决问题和独立决策的机会,从而限制他们的职业发展和成长。最后,过度干预可能会阻碍项目的进展,因为发起人可能会过于关注细节而忽视了项目的整体进度。因此,发起人需要找到一个合适的平衡,既要关注项目的进展,也要尊重和信任团队的工作。

负责人(Project Manager)

负责人直接对发起人负责,是项目策划和执行的总负责,是项目团队的领导者。

PM 的主要职责包括以下四个部分:

  1. 全面负责: PM 对项目的策划、执行和成功负有全责。PM 需要领导项目团队,完成全部项目工作,实现项目目标,满足客户需求。

  2. 目标设定与资源分配: PM 需要与项目发起人协商确定项目目标,并平衡项目的资源、时间和风险。PM 需要带领团队制定一个多个达成共识了的项目计划。

  3. 团队建设和沟通: PM 需要组建并领导核心团队,需要保持与团队成员的及时沟通,确保团队成员了解任务的背景和目标,以便高质量地完成任务。

  4. 项目监督和沟通: 在项目执行过程中,PM 需要实时监控项目的进度,提供必要的指导,持续与团队和其他相关方沟通,以确保项目按照计划顺利进行。

对于 PM 来说,要达成上面的目标,必须要有强大的领导力、沟通能力、组织能力和决策能力,以及对项目管理的深入理解和专业知识。

在实际工作过程中,作为 PM,可能会出现以下的一些问题,看看这些问题里面有没有自己的身影:

  1. 视角局限: 一些 PM 可能过于专注于执行任务,而忽视了他们作为领导者的角色。PM 不仅仅是执行者,他们需要负责项目的全面管理,包括规划、分工、监控和调整。解决这个问题的一个方式是提升 PM 的项目管理知识和技能,让他们了解到 PM 的职责远远超过了单纯的任务执行。

  2. 角色误解:  PM 的角色不仅仅是协调者,他们还是项目的领导者和决策者。他们需要对项目的成功负全责,而不仅仅是「拿到一个鞭子到处抽」。PM 需要理解他们的角色,并尊重他们的职责。

  3. 忽视相关方: 项目的成功不仅取决于项目团队的工作,还取决于与项目相关的所有方的合作。PM 需要理解并满足相关方的需求,与他们保持有效的沟通。否则,项目可能会因为没有满足相关方的期望而失败。

  4. 与项目发起人的沟通不足:  PM 需要与项目发起人保持密切的沟通,确保项目的方向和结果符合发起人的期望。如果没有有效的沟通,项目的结果可能会与发起人的期望存在偏差,导致项目失败。

核心成员(Core Team Members)

核心成员向 PM 负责,其职责是对项目目标的实现提供关键支持,通过其专业技能和决策能力,推动项目的成功执行并解决项目过程中的重要问题。其主要职责包括:

  1. 参与规划和决策: 核心成员通常会参与项目的规划和决策过程。可能需要提供专业的建议和意见,帮助 PM 制定计划和做出决策。这个非常重要。
  2. 任务执行: 核心成员负责完成分配给他们的特定任务和工作。这可能包括设计、开发、测试、文档编写等各种任务。
  3. 沟通和报告: 核心成员需要与 PM 和其他相关方进行有效的沟通。需要定期报告工作进度和结果,以便 PM 可以对项目进行有效的管理和控制。
  4. 问题解决: 当项目遇到问题或困难时,核心成员需要积极找出问题的原因,并提出有效的解决方案。
  5. 质量保证: 核心成员需要确保他们的工作满足项目的质量标准。他们可能需要进行自我检查,或参与项目的质量保证活动。

核心成员在项目管理中扮演着非常关键的角色,具体职责可能会根据项目的性质和规模有所不同。在实际的工作过程中,有一些常见的和核心成员相关的问题,如下:

  1. 团队角色和职责不明确: 如果核心成员的角色和职责没有明确,可能会导致混乱和效率低下。核心成员应清楚了解他们在项目中的作用和期望。
  2. 团队成员技能不匹配: 如果核心成员缺乏完成任务所需的技能或经验,可能会威胁到项目的成功。确保核心成员具有执行他们角色所需的技能和知识至关重要。
  3. 团队沟通不足: 如果核心成员之间或者领导者与核心成员之间的沟通不充分,可能会导致误解和冲突。建立开放和有效的沟通机制至关重要。
  4. 核心成员过多: 如果核心成员过多,可能会导致沟通和协调变得复杂,影响项目的推动。合理管理核心成员规模和结构,或者建立有效的大型团队管理策略,可以帮助解决这个问题。

其它坑

对于这三个角色,我们常常会踩一些坑而不自知,或者明知道是坑也忍不住踩了进去。

首先,三个角色「发起人、负责人和核心成员」都有可能面临「不知道自己不知道」的问题。这里最常见的表现是对当前所处的角色不清晰、对角色的职责不清晰,不知道应该是这样。为此,我们需要不断地学习和探索,以增强自己对项目管理的理解和自我认知。

其次,「知行不一」也是一个常见的问题。在认知上没有问题或者问题不大,但是实际执行时却做不到,无法达到预期,可能是自我管理的问题,比如各种原因控制不住自己,一直想插手等等。这就需要我们提高自我管理能力,包括情绪管理、时间管理和责任管理。需要学会信任团队成员,允许他们犯错误并从错误中学习,而不是总是亲自介入。同时,也需要学会管理自己的时间,把宝贵的时间用在最重要的任务上,而不是溜进琐事的无尽轮回中。

第三个问题是「短视」,只想着解决了眼前的问题,搞乱了整个事情,搞乱了机制和整盘棋。这可能是因为过于关注眼前的问题,而忽视了整个项目的大局,或者为了短期内的效益而牺牲了长期的利益。这需要发起人、负责人和核心成员时刻记住,他们的决策不仅会影响到眼前的任务,也会影响到整个项目的运行。需要考虑每个决策的背后,不仅仅是短期的结果还有长期的影响。为此,需要学习并运用项目管理的方法和工具,例如风险评估、影响分析等,以帮助更准确地预测每个决策的可能后果。

对于如何应对这些问题,我们都需要有耐心,用长沙话来说就是「耐得烦」,尤其是在面临困难和挫折时。多反思自己的决策,思考可能的后果,并努力做出最好的选择。此外,还需要在工作中积极合作,通过观察和学习来提升自己的技能和认知。如果能够做到这些,那么项目就成功了大半。

最后,「独木不成林」,一个人能力终归有限,这是对个体力量的客观认识。即使一个人的技能极为出众,他的时间和精力也是有限的。我们需要与他人合作,共享知识,共享经验,共同面对挑战。通过团队的力量,我们可以实现那些单个个体无法达到的目标。

最后思考:如果把工作中这些事情都当作一个个项目来管理,思考一下,在项目管理过程中,你的角色是什么?你这个角色的职责是什么?你把这个角色的本份做到位了吗?