Skip to content

牛国柱

欲成国柱,须勤耕田

  • 首页
  • 专题
  • 分享
  • 关于
  • 每周一句

Archive 2019-07-21

  • 首页   /  2019   /  
  • 7 月
产品经理, 学习生活 7 月 21,2019

一个有效的思维工具

在我们日常的工作中,经常会面临各种各样的问题,需要我们对问题进行分析,最后采取行动,解决问题。或者在产品的使用过程中,我们经常会接受到用户、客户上报的bug,我们需要对bug进行分析、定位及给出解决方案,这个过程我们也称之为troubleshooting。

针对在上面我们碰到的情况,我们需要一套行之有效的思维方式或者思维工具,才能确保我们分析到位、方案合理,最终解决问题。

这个思维工具是我们抽丝剥茧、逐步找到本质问题、给出最终解决方案的过程,按照顺序列举如下:

1. 现象是什么?

想象是一个问题的表现,是我们能够看到、听到、尝到、触到、感受到的部分。收集到足够全面、完整的信息,才会对我们接下来的分析打好基础,才能够保证我们接下来的分析正确,不偏颇。

2. 原因是什么?

原因是对现象的第一层分析,是我们自然而然能够想到的浅层次的问题。一般来讲,这个原因是很多人能够想到、理解、认同的,因为这个原因浅而易见。比如针对北京的交通太拥堵了这个现象,我们都会认同或者自然而然想到的原因是北京车太多了。这就是我说的浅层次的问题。为什么是浅层次的问题?因为我们都知道这不是根本的问题,所以接下来的思考就应该是问题是什么?

注:如果我们把北京车太多了当做北京交通太拥堵这个现象的问题的话,就会像现在的政府一样,得出办理进京证及限号的这个解决方案。事实证明,这并没有有效的缓解交通压力。北京的交通还是不如上海的好。

3. 问题是什么?

问题是对现象的第二层分析,或者说是对原因的深层次分析。往往不同的现象背后有不同的原因,但是所有的原因背后却都存在着相同的问题。所以,对解决问题来讲,最有效的是我们找到问题到底是什么。这个问题就是原因的原因,现象的第二层分析及深层分析。

继续以北京交通拥堵这个现象来看,原因有:

  • 北京车太多
  • 北京规划以功能性为主,办公场所聚集在一起、商场聚集在一起、居住都聚集到五环以外等,导致了每天固定并且方向一致的交通流向
  • 北京的交通以二维环路为主
  • 北京的环路连接线不通畅
  • ……

以上原因仅为不专业的分析,但是我们仔细思考一下,都明白以上的原因是标,而不是本。造成以上原因的原因是什么呢?或许是北京市政府的城市规划及建设思路,或许需要对规划和建设思路来一次全方面的革新。

4. 解决方案是什么?

在我们找到了原因的原因——问题后,我们就可以很容易的给出解决方案了,并且我们有很大的信心来从根本上解决我们碰到的任何异常现象。因为这个强大的思维工具非常的有效。

经常遵循这个工具来思考我们社会上、工作上、生活中的一些现象,你会得到快速的提升,避免人云亦云,长而久之你会发现对任何问题,你都能够轻而易举的、一针见血的发现本质问题是什么。这在碎片化时代、KOL横行的时代、短视频短信息泛滥的时代非常重要。

作者 牛 国柱
产品经理, 项目管理 7 月 14,2019

项目管理杂谈

我相信,任何一个负责项目管理的同学,都会在项目准备阶段对完成项目抱有极大的信心和极高的热情。我们会将任务按照要求进行拆解,拆解到每一天、每一个人的身上(如果上文所讨论的),根据拆解的情况,我们得到了完成项目的路径。我们坚信,按照路径执行下去,项目最终会按照预期完成。

但是,无数次的现实总是让我们被打脸。你会发现,我们很少能够按照预期完成项目,总是要延期或者上线后出现bug。这种总是失败的挫折感会严重影响我们的信心,会变得不自信,无法在工作中进行合理的承诺,导致同事对你的不信赖。同时,这种挫败感会对团队的士气产生影响,久而久之,低落的士气导致团队的成员之间互相指责,最终分崩离析。

其实,如果我们能够提前认识到项目管理的一些规律,提前做好准备或者预案,会帮助我们在碰到困难时更好的应对,以顺利的完成项目。

1. 项目的资源一定是有限的

通常情况下,我们总能听到抱怨:“项目的人力不够,所以不能做完”、“项目的时间太紧,无法按时完成”等等。这些同学以此为借口来告诉负责人:“到时候项目没有做完,全部是因为资源不足导致的,不能怪我们”。恕不知,对全世界的项目来说,都是在优先资源的情况下来进行的,不是人力不足,就是资金、时间不足,从来没有一个项目是在资源充足的情况下来完成的。

所以,资源不足是项目的常态。所以,项目管理的一切方法论都是在此基础上如何更好的整合有限资源,达成预定的目标。所以,每一个不同项目都是在考虑到既有资源和预定目标的基础上,创新性的工作安排,我们不应该照搬之前的成功经验,必须结合实际。

2. 项目执行过程中一定会出现预期外的问题

从来没有一个人能够完全预期项目中可能出现的问题,比如人力减少、技术难度超过预期、项目需求发生改变等等。我们需要认识到这一点,这非常重要,只有认识到这一点,我们才能做到随机应变,灵活调整我们的计划,而不是一直处于抱怨的状态。同时,只有认识到这一点,我们才能在碰到问题时,坚持的寻找解决方案,而不是改变我们的目标。

reality

3. 项目中的站会不是为了汇报工作进度,而是为了同步风险

很多公司的项目管理中,都会在每天举行站会。但是经常的情况是,每一个同学汇报我昨天做了什么、今天要做什么。汇报的人会产生不被信任的感觉,尤其是很多互联网公司的项目经理都是产品经理在兼任,开发和测试同学汇报的多了,会让团队产品和开发、测试的矛盾逐渐产生并逐渐尖锐。同时,汇报并不能达成站会的效果,我们站会同步工作进度的目的是为了提示和发现风险,千万不能本末倒置。

只有完全理解了“站会的目的是为了同步风险”这一点,我们才能够做好项目的管理工作。

4. 项目的成功不是项目经理一人的功劳,而是团队的功劳

如果项目最终如期保质保量的完成,请注意:这是所有团队成员的功劳,而不是项目经理一人的功劳。作为项目经理,需要让所有的团队成员都感受到完成的喜悦,需要让所有人共享这份荣誉。

avengers

作者 牛 国柱
产品经理, 效率, 项目管理 7 月 6,2019

项目管理中,如何更好的管理任务?

什么是任务

在互联网公司的项目管理中,我们会将目标宏大、耗时较长、以及复杂度高的工作进行拆分,将其拆分为许多个目标具体、时间可控并且复杂度可控的任务。这些任务互相关联,通过工作流程或者接口协议的方式组合起来,最终实现了我们最终的项目目标,同时这些任务之间又相互独立,独立到可以让一个人在一天或者两到三天完成,不需要两人共同完成。在有些公司或者在某些项目管理的工具中,我们也会称这些任务为story、task或者卡片。

任务的建立和管理是我们需求管理和产品设计范畴内的工作,非常重要,因为这是我们项目开发工作的源头。在任何一家互联网公司中,开发、测试以及上线、销售、运营等工作都是在此之后。如果我们在任务拆分和任务描述中出现任何细微的差错,最后都会被成百上千倍的映射到我们后续的工作中,这种影响与距离任务的工序长短正相关,如同我们甩鞭子时候,手部的动作不大,但是鞭子尾部的摆动幅度数倍于手部摆动幅度。这种现象被称为牛鞭效应。

bullwhip

这些任务做为我们项目开发中的最小组成单位,就是我们项目的细胞。犹如人体细胞分有益细胞和癌细胞一样,这些任务同样如此。对任务的合理划分、对任务高质量的描述和设计使我们生产出了有益细胞,确保了项目的稳定和质量。反之,混乱的任务划分、模糊不清以及错误的任务描述和设计就像癌细胞,只会让项目陷入困境,最终摧毁项目。

如何划分任务

对任务的拆分并没有定理或者公式,因为这并不属于一个客观世界的问题,有相当的主观性。同一个人不同项目中,或者不同的人相同项目中,任务的拆分结果都不一样。我们还是要结合项目团队成员数量、能力来定。不过,任务拆分的原则还是有的:

  1. 任务要拆分到只需要一个人来完成。
  2. 任务要拆分到在迭代周期内可完成,或者可以在1-3个工作日内完成。
  3. 所有的任务组合在一起能够实现项目的目标,也就是说,不能有遗漏。
  4. 在以上原则下,拆分的任务数量要尽可能的少,不能为了某种汇报或者邀功的目的而拆分出大量的任务。

总之,任务拆分要遵循8个字原则:不重不漏,不共不难。

如何管理任务

管理任务可以分为两个方面,一是描述任务,二是为了项目管理而进行的任务状态变更。

描述任务

描述任务指的是对任务进行分析,给出产品设计和开发计划等。在这些年的工作中,我个人最为常用或者喜欢的对任务的描述是按照以下结构进行的:

背景
收益
产品设计
测试点
详细设计
测试用例

  • 背景的描述非常重要,一是为了让合作的其他同学能够快速了解为什么要做这个任务,同时在了解的过程中,其他同学也会逐渐具备行业知识;二是为了将来的查验或者其他新同学学习。

  • 对我们个人或者公司来说,我们的时间或者资源永远都是优先的,因此每时每刻我们都在进行选择,选择使我们的收益最高、机会成本最低的事情或者工作。我们将基于何种规则进行选择呢?对于产品经理来说,就是每个任务可能获得的收益。所以,这一点的重要性不言而喻。

  • 产品设计是产品经理的硬功夫,也是一个检验产品经理真伪的试金石,在这里我们会发现,真的不是人人都是产品经理。卖书的人这么说,买书的人就这么信,就too young too simple了。在这个部分,最值得我们思考的不是这个设计是否实现了需求(当然这是前提),而是为什么选择了这个设计。请注意,对成熟的产品经理而言,一个需求可以通过多个不同的设计来实现,如何选择最优的设计才是大牛级的产品经理最常面临的问题。

  • 测试点是产品经理从业务需求的角度提出的需要特别注意的一些内容。

  • 详细设计以及测试用例是围绕着任务实现需要开发及测试人员来进行思考和设计的内容。

任务管理

任务管理指的是任务的状态管理。在敏捷开发中,我们会对任务进行状态的划分,很多的项目管理工具都支持这种划分。虽然有的工具叫board、有的叫看板或者kanban,有的叫视图或者状态栏,名字不一样,但是管理思路都是一致的。所有的工具都会将任务分为以下状态:

to-do
doing
done

基于以往的工作经验以及项目管理的实践,我会将状态分为以下几种:

backlog
to-do
developing
ready to test
testing
ready to deploy
deployed

作者 牛 国柱

Proudly powered by WordPress | Theme: BusiProf by Webriti