Skip to content

牛国柱

欲成国柱,须勤耕田

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

Tag 项目管理

  • 首页   /  
  • 标签: "项目管理"
产品经理, 项目管理 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