【项目管理】如何成为合格的项目负责人

随着团队的发展壮大,越来越多的同学开始担当项目负责人的角色。那么,如何才能成为一个合格的项目负责人呢?

根据自身多年工作经验的积累,我对项目负责人需要完成的工作如下:

  1. 做好通报工作:信息同步
  2. 做好协调工作:资源协调
  3. 做好管理工作:稳步落地
  4. 责任义务权利:权责分清

一、做好通报工作:信息同步

想要成为一个合格的项目负责人,首先需要履行的职责是:向自己的上级、团队、相关合作团队以及关注项目进展的人,及时同步项目的动态。

为什么要做信息同步?

首先,从风险角度来看,信息公开,可以帮助降低项目落地的时候失败的风险。

信息公开,不同角色的人会通过不同的视角来看,目前项目的状态会有什么样的问题。比如:一个项目立项之初,如果事先沟通得不充分,可能会发生:排期预估乐观、人力资源申请存在不到位、技术方案考虑不周等。通过信息公开,不同角色的人可以看到项目状态,如果遇到一些风险,可以主动提出,在事发之前就做好准备工作,可以大大降低事情落地的风险。

其次,方便其它有依赖或有交集项目上同步信息。

比如是一个产品功能的开发项目,一般一个产品要新增加一个功能,会同时有产品、市场、运营等同事同步自己的工作,比如:3-8日要发布一个功能,那么运营同学可能会提前预约3-10号的发布会,来专门推广这个功能。如果项目一旦出现延期、质量问题、功能缩减等,那么需要其他成员同步调整自己的计划,避免因为信息不同步,导致乌龙。

做基础服务的项目,也可能会同步有业务方进行依赖,比如:新增一个Feature或者修复一个Bug,可能都会对业务方有影响,如果需要对方调整,则信息同步是很好的方式的一个提醒。

再次,里程碑事件是最好的“证据”。

团队协作里面,很难免会遇到“扯皮”的事情发生,不管是因为职业素养问题,还是因为某个人“记错了”,我们尽量去避免这类问题的发生。那么,信息同步就是一个很好的方式。不要扯皮,看邮件。

再再次,让你的上级“知道”。

是不是经常听说:你做了很牛逼的事情,结果老大不知道,还以为你一天无所事事,最终郁闷地错失了升级加薪的机会?换个角度考虑,你的老大可能同时跟进N个项目,对很多项目的细节并不清晰,老大如何知道你做得牛逼?

当然,这是从我们自己的角度来看这个事情。让老大知道项目进展,可以帮助你获取他的更高层级的协助。比如:我们会在通报里面,描述工作的计划和方案,有的时候这个计划和方案在老大看来,有更好的解决方案(比如:通过资源解决问题,某某团队已经做过了,我们直接拿过来用;或者,某个方案有更好的方式),那么这个时候,他会从资源、“过来人”的角色来帮助我们更好实现项目落地。这也是让老大知道的意义。

综上,作为一个项目负责人,如何信息通报做得不够好,那么我们认为这个负责人是不合格的。

什么情况需要通报?

一般情况下,我们会有几种场景下做通报:

  1. 项目进展,达到某个里程碑阶段
  2. 项目进度,出现变化(故障、异常)
  3. 项目的一些结论性质的内容
  4. 定期的项目进展通报

1、项目里程碑通报

常见的里程碑事件,有:项目立项、方案沟通与评审、阶段性的进度通报、项目提测、项目部署、项目结束等。

通报的内容以“项目达成某个点”为主,比如:

【立项】**项目立项通报、【上线】**项目部署完成/小流量部署完成。

一般情况下,有些里程碑事件可以省略,比如:某些封闭项目、大家都知道的立项环节等。

2、项目进展出现变化通报

常见的有:项目延期、需求变更、方案或资源变更等。在我们项目中,经常出现周期上的变更(延期)。偶尔会出现人力资源的调整,比如之前由于某某离职、晋升等造成变化。

比如:【变更】**项目成员变更通报

3、项目的一些结论性质的内容

项目的进行过程中,经常会有小范围的沟通、讨论,往往这些沟通和讨论都会达成一些共识和下一步的计划。那么,这种情况也需要进行通报,比如:会议纪要。一般这类通报包含以下几方面内容:

  1. 参与人(都谁参与了)
  2. 时间(什么时间讨论的)
  3. 主题,讨论了什么问题
  4. 结论,达成了什么结论
  5. 后续计划,接下来怎么安排的(由谁什么时间、负责完成什么事情)

4、定期的项目进展通报

这个比较好理解了,比如:项目周报、日报、季报等。定期的给出项目的进展、下一步计划、遇到的问题或需求的资源等。

同步方式

常见的情况下,我们使用:邮件(最常见)、即时通信工具(微信)、WIKI(Slack、Confluence等)、Tower(TB)等。这里我们仅讨论:邮件和即时通信工具(也可以用Slack代替)。

一些重要的结论,后续可查的,走邮件;比如:沟通纪要、双方的结论等;

一些及时性强的、临时的,走即时通信。

二者的区别在与:是否需要保留记录,是否及时。其实二者并不冲突,可以同时使用(即:既发了邮件,也发消息)

使用邮件

一般,标题能够突出结论或者主题,比如:

  【纪要】**沟通纪要

  【评审】**项目技术方案评审邀请

标题直接与主题相关,方便接受邮件的同事快速判断这封邮件是否需要看下去。

邮件内容,一般三段式:

  1. 结论先行(方便阅读邮件的人第一时间Get到点,至于过程看不看,根据结论判断)
  2. 补充描述(比如:结论是怎么得出的;
    1. 结论的产生很多是跟背景相关的(也可以叫:场景),缺乏场景的情况下讨论结论是没有意义的
    2. 除了故障是怎么分析、怎么得出的)
  3. 下一步计划(接下来怎么办,比如:如果是故障,则接下来安排怎么排查和处理,给出时间点和责任人;如果是结论通报,要么省略,要么可以说一下:反思的过程)

上面的结构可以满足大部分发邮件的需要了。

使用微信(其他通信一样)

微信的内容随意性比较大,需要遵守的是:一句话说明白。结论先行、补充描述即可。

同步对象

你的邮件、内容发给谁,你可得想好了。

原则上讲:你的内容希望谁看到,那么发给谁。另外一种定义是:项目相干方,及与项目相关的人。

这里,常见的候选人是:

  1. 你的上级(导师、项目的直属负责人)
  2. 执行项目的团队
  3. 你的业务方(谁的工作依赖你的项目)
  4. 某些特别的人(自已意会)

总结

综上,能够合理地做好项目通报,是项目负责人的基本能力。(当然,技术能力才是基本能力...)

二、做好协调工作:资源协调

项目往往会出现:人员变更、依赖工具、有时间限制,当任意一个因素出现瓶颈的时候,就需要来做资源协调了。

项目管理四因素

在一个项目中,我们考量:时间、成本、功能、质量四因素,几乎任意一个项目都可以由这四个因素来描述。

这里面,成本包含了:人、某些资源、工具、场地等。

这四者的关系可以总结为:

时间=功能*质量/成本。

图示:对角线为互斥:此消彼长;相邻为互助,相互促进。

那么,所谓协调,就是在这个四个里面做取舍。

处理功能

所谓功能,也可以理解为需求。

处理好需求(我们经常叫:控制好需求),是顺利落地项目的第一步。道理很简单,功能越少,难度越小。一般来讲,我们会根据时间来卡功能,敏捷里面也叫:TimeBoxing。在某些场景下,我们会直接进入研发,看看在某个TB下,我们尽可能地多地实现功能,实现多少算多少。

正常情况下,都是通过时间窗来卡功能的,因为一般上线的日子提前订了,那么这个时候就看能做多少了。当然也有根据功能来计划发布时间的,这个完全根据实际的情况来定。

处理功能,需要有优先级的概念,尽量将功能拉平成为一个线性维度的数据,而不是一个矩阵(二维关系)或者网状(多维关系)的数据。线性维度的数据更好地进行分析。

什么是矩阵数据、多维度数据?

我们在制定需求时,如果需求之间没有依赖关系,相互独立的,那么会认为需求的信息是线性的。在某些情况下会出现:A需求依赖B需求的情况,那么这个时候需求的信息就不是线性的了,这种情况下,如果依赖的情况比较复杂,甚至会出现:A依赖B、B依赖C、C依赖A的环形依赖情况,那么这种需求就属于整理得不好的。在经常的情况下,我们会将多维需求拉平成为线性需求,方便我们进行管理和开发。

最常见的情况是:我们将简单依赖通过合并、拆解等方法,彻底解开关系依赖,实现线性数据。这也能够解决常见的场景。

如果需求本身数量也多,情况比较复杂,那么这个时候就需要一轮结构化处理了(后面有机会专门来聊这个话题)

总之,需求这里一定要可控,在自己能够处理的范围来处理。

遵守时间

时间也即周期,我们完成一件事情所需要的时间。在很多情况下,我们拿到一个需求,会进行排期(计划时间,什么时间完成、什么时候进入测试、什么时候发布)。

在指定时间的情况下,就不说了。

在需要给时间的情况下,比如:这么多功能、你的团队需要多久能做完,潜台词是:功能确定、人员确定(成本)、质量保证下线,那么需要多长时间。这种情况下,一般我们会进行功能、人来进行任务划分,划分后,根据经验来给出时间。最常见的,就是:排期。

排期

排期一般分两种情况:阶段性周期(里程碑)和任务计划。

“完成技术调研需要1-2周”属于阶段性周期,而“用户登录API开发需要16h“属于任务计划,二者的区别是:

  1. 周期长短不同,阶段性周期粒度长一些,计划的粒度会小一些
  2. 阶段性的周期可以是一个范围,不确定的;计划就需要确切的值

了解一个项目的周期,我们先了解一下:PDCA(戴明环)

对于项目,项目的周期为:

对于项目而言,我们经常接触的是:Plan和Do的环节,Check和Analysis的环节很少想到,很多情况下,我们发布的项目后续都由运维接手了,然后便开展了下一个版本。其实,C和A的事情我们都做了,只是很少会把它单独拎出来而已。

比如,系统上线后,进入运维状态,那么这个过程就进入了长期的Check状态,当出现Bug时,就会进入Analysis了,接下来修复bug的场景就是下一个版本了。

管理成本

一个项目,可以投入一个人来做,也可以投入十个人来做;可以自己团队花很久来研发,也可以买现成的商业方案。这些都是成本。做项目就没有不付出成本的,只有成本的高低之分。我们最常见的是人力不足时,向其他团队”借人“的场景,这个情况也比较简单和常见。

如何选用第三方方案

还有一种情况,对于很多技术出身的人才来说,就有些困难:使用别人现成的方案。之所以说这种情况比较困难,主要在于:

  1. 有些是能自己写就自己写,不想去理解别人的技术思路,不想去学习;
  2. 有些是能用别人的就用别人的,总觉得别人写的就是最好的(某个NPM的故事)

就这里而言,这个没有什么固定的答案。一句话:因实际情况而异。

当然,实际选择的时候,我会关注:

  1. 我们的团队是否有能力自研(或者为了提升自研能力)
  2. 选用的组件是否是公司的发展方向(如果是,优先,甚至是必须)
  3. 现在什么比较富裕,什么比较匮乏(比如:钱比较多,用现成比重大些;人比较多,自研比重大写)

总之,谁负责谁决策,无论做哪种选择,都需要足够的勇气承担风险。

多跟老大要资源

在一般情况下,老大会帮助自己来提前调度资源(老大不就是干这个事的么),但是在某些情况下(比如:难度超过预期、老大对项目细节并不熟悉等),老大给的资源跟实际的需求有出入,那么作为项目负责人有必要也有责任向老大申请资源。

控制质量

互联网经常有一句话叫:要时间不要质量。在保障核心功能正常使用的情况下,减少非核心功能的测试时间,来追求发布上的快。(不知道现在腾讯帮助中心的检索的bug修复了没)

这里,质量一定要分级,分级的原则是以影响面来衡量,而不是修复难度。

为什么要分级

在时间、资源充裕的情况下,是不需要分级的。测试做个一年半载再上线也是可以的。然而现实是,老板永远催着你赶紧上线,我们的资源也不是可以无节制消耗的。那么要找到:既能保证质量达到一定的要求,并且在有限的时间和成本下完成,就需要一个平衡的折中方案。质量分级是一个常见的方式。

有些人认为,在有限的能力下完成牛逼的事情,更能凸显自己的能力。这个话讲得没错,但是合理的利用资源,也是一种能力。(想了解为什么?以后有机会讲职业发展的时候,再详细展开)

质量分级

一般来讲,我们根据Bug的影响面作为标准来定义等级(切记:不是修复难度,而是影响面)。这里的影响面从两个层面看:

  1. 业务影响:比如显示金额出错,数据并没有发生变化,可能是一个笔误导致的,修改起来很容易,但是对于用户来讲,可能会觉得自己的钱丢了或者赚了,转而产生客诉或者其它负面影响,虽然修改起来容易,但是带给客服、用户、外界对公司的印象会大打折扣
  2. 系统稳定性影响:比如写数据写失败、写错误、隐藏的bug等,触发概率大且一旦触发会造成系统不可用或者数据损坏,那么这个也会比较严重

根据上面两种情况,我们定义:

质量等级
质量定义
处理建议
描述
1
  1. 核心业务功能,产生会造成用户歧义的
  2. 核心功能不可用
  3. 核心功能上,会产生错误数据的或者会造成服务整体不可用的bug
必须处理如:充值不可用
2
  1. 业务上会造成用户产生歧义的(错别字、数据展示错误等),从而带来纠纷的
  2. 核心业务上,程序逻辑错误但未造成数据损坏的
  3. 非核心业务上,会产生错误数据的
必须处理如:用户余额单位显示出错
3
  1. 非核心业务上,程序逻辑错误的
  2. 非核心业务上,概率性触发或仅影响小范围场景的
  3. 非核心业务上,UI与实际不相符但不影响正常功能的
建议处理如:找回密码 的界面跟UI设计不一致的
4
  1. 某个极不重要的业务上发生的,且不会造成数据损坏、整体服务稳定性的
可处理可不处理如:页面未严格按照UI实现,但相差不大的(<4px)

等级没有绝对的边界,根据实际情况来调整,但是就是一个原则:以Bug的影响面为准。

总之,做好协调工作,可以让工作更有效率。

三、做好管理工作:稳步落地

项目的执行过程,我们的敌人:风险。我们接下来所有的事情,几乎都是讨论怎么对付它。

过程管理你一定不陌生,定期的进度review、各种的站会例会,几乎充斥到我们工作的每个环节。如果想让项目顺利落地,即便项目中出现风险,也可以降低本来应有的损失,那么我们需要学习一些基本的知识:

  1. 目标管理(SMART)
  2. 时间管理(重要紧急四象限、《高效能人事的七个习惯》)
  3. 结构化思维

以及一些常见的敏捷实践:scrum、极限编程、TDD。

什么是执行力,我的理解是:把不确定的事情确定下来,把计划的事情落实下来,就是执行力。

先说说,一些基本知识

目标导向

目标导向可以理解为是一种价值观,事情的优先程度永远与是否与目标有关而相关。这里就要说四个概念:

目标:要解决的问题或者要实现的目标。比如:降低数据库压力、增加公司营业额。目标是应该有明确的指标,这个指标是很好衡量的。

方法:也叫手段、方案,从现状到目标实现的过程或者办法。

现状:目前的所处的状态

背景:这个范围很宽泛,主要交代了前因后果,以及一些隐藏的限制条件

了解完这些概念之后,那么就需要明确规则了:

现状、背景、目标是常量,方法是变量。

意思是:如果执行的过程中实现得不顺利,那么说明方法需要调整了,而不是调整目标。这也是目标导向最重要的概念。

目标管理

我们在制定目标的时候,会遵循SMART原则,那么什么是SMART?

Specific:具体的、确定的,可衡量的

Motivating:有激励的,有挑战的

Attainable:是可以实现的

Responsible:有责任的,这里指的是有责任人

Time-related:有时间限制的

(这个真的版本太多,我找了很久,组装了一个合理的)

一般,我们安排任务都会出现:某某负责**事情,实现**指标,某日子前完成。

时间管理

我们必须承认一点:人的精力有限、时间有限,如何在有限的时间内做价值更大的事情,是时间管理解决的问题。

时间上面,有几个原则:

  1. 要事优先(什么是要事)
  2. 积极主动(多思考怎么办,少思考为什么)

对于事情,我们都可以分为以上四类。上面四类里面,肯定是优先做:重要紧急的事情,不做不重要不紧急的事情;那么重要不紧急和紧急不重要先做哪个?

这里有几个参考的方法,根据自己情况来定:

番茄工作法:

  1. 以每25分钟为一个番茄钟,5分钟为一个休息时间
  2. 一个番茄钟只干一件事,谁来打扰都不行
  3. 休息的5分钟用来上厕所、喝水、散步
  4. 每天回顾与总结
  5. 内部的中断:接受、记录并继续;外部的中断:2分钟内能完成就做,完成不了重新安排(当然是要分情况的)

以上便是需要准备的基础知识。那么接下来,我们开始“稳步落地”。

1、好的计划,是成功的开始

计划是典型的重要不紧急的事情(大多数场景下),计划越精确越好,但不是越细越好,一定要有合适的粒度。

比如,拿排期来说,那么根据项目的大小,一般4周以内的项目,计划的记录在1-3天比较合适;如果项目超过4周,那么粒度在0.5-1周比较合适。

在拿项目设计方案来说,如果是大型的系统架构设计,那么划分出子系统的定位和子系统之间的关系即可(参考:系统之美)。

除此之外,好的计划也是有“预案”的,预案主要描述了:一旦发生某些变化,就执行什么动作。

所以好的计划是:

  1. 精确的描述
  2. 合适的粒度
  3. 不可控因素的预案

计划需要多去联系和尝试,根据不同的情况,慢慢总结其中的细节和联系。

SCRUM中的计划会,就是来跟大家同步计划的(记住:这里是同步计划,不是制定计划,也就是说:会议上我们来分配工作的,不是来讨论怎么做计划的)

2、定期的跟进进度

我们在做敏捷实践的时候,经常会进行:SCRUM的四个会,这个四个会中有两个就是与进度有关的,这两个会分别是:

每日立会(没错,是“立”不是“例”,表示站立的意思)和定期review。

每日立会:团队内进行沟通进度的会议,长度不超过15分钟为宜。会议每个成员讲:

  1. 昨天的工作进度
  2. 今天的工作计划
  3. 我遇到了什么问题,什么会妨碍我的工作,需要什么样的支持

这里需要注意的是:会议上不分析出现问题的原因,也不追责,仅以发现问题为主。如果遇到出现的问题,单独计划讨论、会议来进行。

定期Review:一般在某一个小的里程碑的时候进行的,有的时候也会在每周进行(因为一些任务就是按周来计划的)。会议中一般讨论这个时间范围内的整体进展,以及遇到的问题和反思,长度15-60分钟为佳。

3、处理阻碍进度的绊脚石

项目中遇到了问题怎么办,那么这个时候我们需要在:资源、质量、功能上做文章了。

比如,某个任务花费的时间比预期的长,那么要保证按时上线,要么加人解决,要么放弃一些功能的测试了,或者砍掉某些需求。这些都是我们解决问题的思路。

在通过某些思路解决问题的时候,具体的方法因人而异了,比如:如何跟老大要人;如何跟平衡方案和资源分配,都是需要慢慢凭经验改进的事情。

另外,处理问题需要准确、快速(这是两个词,准确和快速类似重要和紧急一样,两个维度来描述事务,是不是出现了很多次),越准确越快速肯定是最好的,不准确又慢也是有问题的。在时间允许的情况下,优先保证准确;那么如果时间紧迫怎么办?这里就有冒险和求稳两种做法了:快速决策和跳过问题。

问题越早解决,带来的代价越小。(忘记是谁说的了,原话可能也不是这样,但意思差不多)

4、项目要复盘(也就是:Review)

Scrum里面的回顾会(Retrospective Meeting)。这个会议时间可以长一些,当然提前准备工作也是要做的。

  1. 这次项目里面,哪些是做得好的、哪些是不好的(可以提前收集一些材料,比如:邮件、纪要、WIKI等)
  2. 下次如何能做得更好,以及可以安排哪些新的挑战进来(什么是挑战?)

这个会议可以轻松一些,主要是总结。有的时候,我会准备一些小零食来帮助大家放松。

总之,好的执行可以帮助项目


其它的一些过程管理

高效的会议

如果想要会议很高效,那么有以下建议可以参考:

  1. 提前准备,提前收集各种声音,挺多数人的意见,跟少数人商量,自己做结论(出自:百度圣经)
  2. 会议要有明确的目标,是为了达成一致,还是为了同步结论
  3. 有限的人数,减少产生不相干的话题和无意义的争论
  4. 会议要以结论结束
  5. 正常情况下,会议15分钟左右即可(一些特殊的会议除外,比如:分享、培训、脑暴等)
  6. 会议结束后,对于一些结论,需要有会议纪要(这就是一个里程碑,方便大家后续以此为基础进行推进)

一些好的经验

  1. 事情赶早不赶晚(我在百度的时候,我的导师教我的,受用匪浅)
  2. 学会说“不”,对于没有明确目的的要求,可以说“不”,既是对自己负责,也是对对方负责
  3. 对事不对人,事情该怎么样就怎么样

四、责任义务权利:权责分清

有权利就有义务,有义务就有责任,这里几乎是可以划等号的。在我经历的不同团队里,这里是经常发生纠纷的地方:

  1. 边界与范围:哪些是该负责人负责
  2. 责任链模型
  3. 团队成员的边界
  4. 如何看待冲突
  5. 如何做决策

边界与范围

你需要做决策,并且需要为此负责

我经常遇到的一种情况是,负责人担心做出决策事后害怕担责,往往会寻求团队外部的合作人、自己内部成员来决策,造成一种“我没有选择”的假象,最终经常会演变成:彼此甩锅。

那么,我们认为:无论决策由谁来做出,凡是与团队有关的决策造成不好的结果,项目负责人一定是第一责任人

讲到责任,就必须得讲一个东西叫:责任链。

责任链,是一种责任的认定方式。一般情况下,责任的追踪方式有两种:从上到下的金字塔责任链 和 从头到尾的队列责任链。

金字塔责任链

当一个项目出现问题时,那么第一责任人就是这个项目的负责人,无论决策是谁做出,也无论客观因素如何。但是在这个团队内部,再次拆分责任的时候,就根据具体的原因来拆分了。而对于这个团队的上游(或者上级),在他的外部也需要承担失败的责任。这也是百度旗下任何的问题(不管李彦宏是否知情),大家骂的都是李彦宏的主要逻辑。

金字塔责任链主要适用于有明确上下级关系的场景下。

队列责任链

推动-协作者模型主要适用于平级或者跨团队间的场景。当一件事由专门的推动者负责推进时,就会由推动者来负责项目的推动工作,也承担着项目推进的责任。

因此,在责任上面,当需要某个人或者团队去执行落地某个任务时,充分的授权便是最为基本的条件之一。

团队成员的边界

我记得我们之前的KPI里面,个人绩效分为两部分:团队绩效+个人绩效。有的时候,团队绩效的比重占到了70%,个人仅占到了30%。这里的含义是:团队成就个人。这也与当今社会中的价值观一致。(比如:NBA总决赛的MVP大部分是从胜者的球队中选出的,金球奖的得奖人也是需要有团队的大赛成绩的)

因此有一句话:团队牛逼了,团队成员差不了;团队失败了,团队成员好不了。因此,当团队陷入某些困境中时,这样的原则要求团队成员思考如何帮助团队走出困境,而不是想好自己怎么不受影响,能够全身而退。倘若团队成员各自为战,团队翻盘的机会也就不大了。

不要害怕冲突,但要控制冲突的边界

冲突的发生有多重因素,但大多数都是彼此对于方案的不一致。冲突可以有效帮助彼此思考,方案考虑因素更多,但是冲突一定要满足:

  1. 就事论事,对事不对人,切勿将话题转移到人的身上
  2. 意见表达充分之后,给对方说话的“权利”
  3. 冲突的目的是结论,切勿无限制扩散

和和气气会慢慢降低大家对项目的严肃程度,适当的冲突帮助彼此监督,考虑问题更加完善。

另外,在别人产生冲突的时候,自己当裁判,而不是“和事佬”。当裁判并不是看谁说对了或者声音大,而是看谁越界了(谁超出了事的范畴),对于越界的人及时制止或者直接终止冲突,这是“裁判”的作用。

因此,不要害怕冲突,而要善用冲突

如何做决策

老百度有一句话叫:听多数人的意见,跟少数人商量,自己做决策

首先,做好调研工作(看看别人怎么做)

调研就是看业内同样的问题都有哪些解决的方案,看看别人的方案主要可以发现:

  1. 各自的场景有何异同
  2. 核心的逻辑和算法是怎么做的
  3. 最终的实现有何取舍(场景、目的不同,导致实现不同)

最终,都可以得出一个:基本的技术论调。

其次,听听大家怎么说(我们的现状和场景)

听听大家说,了解大家的诉求(也就是:需求)和方法(调用方式)。区分清楚哪些是需求,哪些是建议很重要。

需求:我希望你的项目能够实现什么功能,解决什么问题;

方法:你的这个项目可以通过什么技术实现;你的项目可以如何落地。

通过了解大家诉求,来了解我们的现状和场景。

再次,找到关键瓶颈点(成本关键点、技术关键点、周期关键点)

找到关键瓶颈点的原因是:如何做取舍。一个项目顺利的情况下,资源到位、时间到位、技术满足,那么项目仅仅是落地的问题。然而,在一些场景下,会发生:人不够用、时间紧、功能多等。这个时候往往就就是要做取舍了。

那么了解自己当前的瓶颈点,找到瓶颈点的确认关系,那么取舍的事情会相对比较容易。

最后,得出结论

已经做了比较充分的熟悉了,接下来结论也相对容易多了(也清晰了)。有了上面的流程,换个人得出的结论也基本接近。ba

附录

参考文章

  1. 成本和质量是常量,范围和时间是变量 http://blog.csdn.net/thinkinchaos/article/details/1303105
  2. 项目管理核心三要素 http://www.360doc.com/content/16/0411/22/4186849_549847818.shtml
  3. 敏捷迭代开发 Time Boxing http://blog.csdn.net/jiyiqini/article/details/51303235
  4. 结构化思维 http://wiki.mbalib.com/wiki/%E7%BB%93%E6%9E%84%E5%8C%96%E6%80%9D%E7%BB%B4
  5. PDCA戴明环 https://baike.baidu.com/item/PDCA%E5%BE%AA%E7%8E%AF/5091521?fr=aladdin&fromid=3716836&fromtitle=PDCA
  6. Bug的严重等级和优先级 http://blog.csdn.net/rabbit100/article/details/50980952
  7. 什么是bug等级和严重程度 https://zhidao.baidu.com/question/466544098.html
  8. 如何定义bug严重程度 https://www.zhihu.com/question/20280073
  9. scrum 百度百科 https://baike.baidu.com/item/Scrum/1698901?fr=aladdin
  10. SMART https://en.wikipedia.org/wiki/SMART_criteria
  11. 结构化思维 百度百科https://baike.baidu.com/item/%E7%BB%93%E6%9E%84%E5%8C%96%E6%80%9D%E7%BB%B4/1482961?fr=aladdin
  12. 极限编程 https://baike.baidu.com/item/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B/4690591?fr=aladdin
  13. 《高效能人士的七个习惯》 https://book.douban.com/subject/5325618/
  14. 《金字塔思维》https://book.douban.com/subject/1020644/
  15. 《OKR》https://book.douban.com/subject/27084312/
  16. 番茄工作法 https://www.jianshu.com/p/7d026e18c46d
  17. 《搞定》(英文:Get Things Done)https://book.douban.com/subject/4849382/
  18. 《系统之美》https://book.douban.com/subject/11528220/
  19. SCRUM的四个会议 http://blog.163.com/linfeng_0212/blog/static/622213820151034538512/
  • 8
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
云服务器数据安全保护项目询价文件 一、项目编号:计算机学院2017【009】号 二、项目名称:云服务器数据安全保护件 三、采购预算:12.1万元 四、采购设备清单与技术参数 " 指标项 "需求说明 " "系统环境 " 操作系统版本包括Windows 2003/2008/2012、AIX " " "5/6/7、 Redhat Linux 5/6/7、SUSE Linux 。 " "安全模式 "支持有代理和无代理两种模式的防病毒功能。能够对运 " " "行中进程和 I/O " " "事件实时病毒过滤;根据用户需求自定义扫描目录手动 " " "或计划病毒过滤,编辑扫描配置扫描范围、排除的文件 " " "和目录,以及如果在服务器上检测出恶意件时应采取 " " "的操作(例如清除、隔离或删除);支持对服务上的所 " " "有进程和文件执行完整系统扫描,或仅扫描计算机重要 " " "系统区域快速扫描。 " "服务要求 "在有效服务期内,免费自动或手工升级原厂最新安全组 " " "件、特征码、扫描引擎或版本等。 " "管理要求 "支持统一管理功能,能够通过一个中心管理管理所有的 " " "防护设备包括物理服务器和虚拟设备,提供病毒库统一 " " "下发、更新、扫描等安全管理。 " "补丁要求 "支持虚拟补丁功能,在出现0day漏洞和未对漏洞进行永 " " "久修复之前提供安全防护。能够防堵已知漏洞及零日攻 " " "击,避免无限制的攻击;自动防堵发现到的最新漏洞, " " "在漏洞修复后及时取消虚拟补丁的应用,无须重启服务 " " "器即可完成。 " "日志审查 "提供日志审查功能,收集和分析操作系统和应用程序日 " " "志中的安全事件,将事件转至SIEM系统或中央日志服务 " " "器,关联性分析、报告和归档。 " " "对侦测可疑行为、收集数据中心的安全事件和管理操作 " " ",并使用OSSEC 语法来建立高级规则。支持日志信息在 " " "控制台上展现、告警。 " "网页保护 "支持网页应用程序保护,防护SQL注入、跨网站脚本攻击" " "和其它网页应用程序漏洞; " " "并能够在漏洞修补期间,提供完整的漏洞防护。 " "防火墙功能 "防火墙功能, " " "能集中管理服务器防火墙策略,具有精细的过滤功能(I" " "P与MAC地址、通讯端口),针对不同网络接口设计的策 " " "略,可以防止DDos攻击和侦测扫描,包括所有基于IP的 " " "协议(TCP、 UDP、 ICMP 等)和所有帧类型(IP、ARP " " "等)。 " "完整性监控 "完整性监控功能,能监视关键操作系统和应用程序文件 " " ",如目录、注册表项及数值以侦测出恶意和未授权的更 " " "改;能侦测现有文件系统中的修改及新文件的创建,并提" " "供实时报告;可启动按需、计划或实时的侦测,检查文件" " "属性,监控特定目录。 " "多平台支持 " 多虚拟化平台支持、多操作系统支持,产品至少支持Vm" " "ware、Citrix、华三CAS、华为Fusionsphere、KVM等虚 " " "拟化平台的安全策略。 " 五、基本要求 1.本招标文件要求中,凡标有" "的条款为"不允许负偏离的条款",报价文件对这些 条款的任何负偏离,将导致其成为无效报价。报价人在响应询价文件中对这部分内容应 尽量列出具体参数或作出详细应答。 2.报价人应提供已注册品牌制造商原装、全新的、符合国家及用户提出的有关质量 标准的设备。设备在正确安装后,能确保在正常的使用过程中安全、可靠,并达到有关 规定的要求。设备应符合中国政府颁布的产品、质量、技术、安全标准及环保标准 3.所有货物及设计、制造、测试和安装都应符合采购时已颁布的现行中国国家或国 家认可的(部颁、行业)标准和国际标准化组织以及等效或更优的其他国家的权威性标 准和规范的有关条文 六、交付使用时间及地点 1. 交货时间:合同签订后30天内。 2. 交货地点:用户指定地点。 七、质量保证和售后服务 1.设备免费保修期限:验收合格后3年,保修期自双方代表在货物安装调试后的验 收证明文件上签字之日起计算。 2.质保期内,如货物或零部件因质量原因出现故障而造成短期停用时,则质保期和 免费维修期相应顺延。如停用时间累计超过60天则质保期重新计算。 3.在保修期内,如货品非因采购人的人为原因而出现的问题由中标人负责包修、包 换或包退,并承担修理、调换或退货的实际费用。 4.保修期内,中标人负责对其提供的货物整机进行维修和系统维护,不再收取任何 费用,但非中标人责任的人为因素、自然因素(如火灾、雷击等)造成的故障除外。 5.货物故障报修的响应时间为2小时,且在8小时(连同前面时间计算)内处理完毕 。规定时间内未处理完
某公司决定开发一个新的电商平台,以下是该项目的干系人及其需求: 1. 高管:希望项目能够按时完成,达到商业目标,提高公司盈利能力。 2. 项目经理:希望项目能够按照计划进行,控制成本和风险,保证项目的质量和效率。 3. 开发团队:希望有足够的资源和支持,能够按时完成开发任务,同时希望有足够的自主权来决定开发细节。 4. 测试团队:希望有足够的测试时间和测试环境,能够全面测试系统的各个方面,以确保系统质量。 5. 用户:希望系统能够提供良好的用户体验,易于使用,同时能够满足他们的需求。 6. 营销团队:希望系统能够支持各种营销活动,提升销售额和市场份额。 针对以上干系人的需求,项目经理需要采取以下管理措施: 1. 与高管密切沟通,明确项目目标和商业目标,并及时向高管汇报项目情况,以确保项目能够按时完成,达到商业目标。 2. 确定项目计划和进度,并制定详细的项目管理计划,以确保项目按计划进行,控制成本和风险,保证项目的质量和效率。 3. 与开发团队密切合作,提供足够的资源和支持,同时给予团队足够的自主权,以确保开发任务按时完成,并满足开发团队的需求。 4. 与测试团队密切合作,提供足够的测试时间和测试环境,以确保系统质量,并及时解决测试团队提出的问题。 5. 关注用户需求,与用户进行沟通和交流,了解用户的需求和反馈,并及时采取措施改进系统,提供良好的用户体验。 6. 与营销团队密切合作,了解营销团队的需求和推广方案,以确保系统能够支持各种营销活动,提升销售额和市场份额。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值