记一次“独立推项目”的心得体会


先说下标题,所谓独立推项目跟之前的推项目(最多只能叫跟项目)区别在哪里。

跟项目 推项目
项目来源 主版本的大项目,分了一小块给我来跟 由我向上面发起
需求定义 PM 说啥就干啥,PM 说砍啥就砍啥 共同协商,我拍板
风险处理 报给大版本负责人 自己消化,消化不了就背延期的锅
资源排期 整体安排,各别协调 啥啥没有,自己想办法

最明显的区别是,凡事没有退路。心(pi)态(gu)变换导致很多做事方法完全不一样

注:后面每个大标题都表示一块项目管理的工作内容,不分先后,重点写自己做的不好的,可以挑自己感兴趣的看。

为了便于后面描述,这里简单介绍下这个项目,简单说,我们做的就是统一实体的唯一标识。

比如用户的唯一标识是什么,至少我见过几种方式:user_id、id_card、phone、email等等。 不同系统存一个用户用的标识不一样,通信的时候非常麻烦,来回转换。

然而,我们系统内的情况更复杂:

  • 我们有10+种主要实体(课程、电子书、音视频等等)
  • 每个实体要对接8+种通用服务(收藏、进度等等)
  • 超过一半的实体都用了两种以上的标识(数字 ID、别名 alias、甚至还有人用课程关联的视频 ID 作为课程的 ID)

在我的理解里,N种实体,M 种抽象服务,如果抽象得当,那么对接成本应该是 N+M。但在这种实际情况下,对接成本可能到了 N*M*2.5。

除了开发成本,带来的问题更加可怕。

  • 用户反馈收藏的课程不见了,一查发现,收藏接口传的音频 ID,取收藏数据传的视频 ID,其实应该传课程 ID。
  • 某节课程的所有用户留言都不见了,一查发现,留言系统用的“课程所关联的音频ID”作为课程ID ,然而这批课程换了一批音频,音频 ID 全变了。数据也自然都对不上了。你说赶紧洗数据吧,可是都不知道哪些音频改过

后来我实在受不了这些祖传屎山了,就找老板讨个规范。老板一听很高兴,把我跟几个端的 leader拉了个小群,提了一下这个问题,说统一业务模型很重要、隔离系统边界很重要。xxx 来负责,先把接口搞干净。

于是就稀里糊涂地接了这个活,坦白说,这个事情技术难度只能算中等偏上,也就是一点点抽象能力。但它极大考验协调和项目管理能力。具体说,需要配合的人非常多,因为各个端都得改一通,在我司极少有项目需要牵扯这么多人和端。而且,我的职级也不高,要让这么多人因为我一句负面的吐槽就听我号令,实在是痴人说梦。

光我说难不算,我也问过几个leader意见。客户端某端负责人说,你们这么折腾,就相当于把 App 重写一遍。一位架构师告诉我说,去年就想搞了,但是端上的阻力太大,就不了了之了。

最后给我的感觉就是:大概率不成,全当一次历练吧。

万幸中的万幸,经过一个多月的鏖战,总算是上线交付,得到的评价还不错。

后面就来说说一些过程中遇到的问题

最耗精力的工作内容:划清项目范围边界。

一般随版本走的的产品需求,在开工前80%的需求都是确定的,时间点也是固定的,资源也比较足,按部就班地做一般不会出问题。

但是技术改造就很麻烦,名义上是一个独立项目,可以做完后单独发版,没有明确deadline。但实际上,每个人都会先做火烧眉毛的事情,没有 deadline说明还能放一放。而且老板那里肯定会有个心理预期的,不能一直拖。于是大家一起简单梳理了接口范围,定了个“一个月”。

技术改造还有个问题,准确的成本要看到代码才知晓。我们也是真正开工的时候才发现,这个技术改造跟其他6个技术改造项目有关联,比如迁移新接口、迁移新路由、 服务化改造、部分系统重构等等。这些改造目前都算是“重要不紧急”,很多都是说要做,但是做了一半就放在那里了。一说这次要动那部分的代码,都想着能不能“顺手”把哪个改造也一起做了。

如果拒绝有什么影响呢:

  • 面上的,减少项目成果,降低项目意义和价值。像是做了个半吊子工程
  • 部分代码要改,但改的不是最终版本,还要兼容,后面可能还要返工。这点会严重打击开发的积极性

如果接受,自然能避免这两个问题,但是会有其他问题

  • 改动代码范围变多,质量风险会大大提高
  • 项目范围膨胀,极有肯能严重延期或烂尾。
  • 这两点都算是项目的命根子,如果发生这类问题,约等于成果为0,前功尽弃

为了在这些矛盾点做取舍,我们耗费了大量的精力去讨论、调整项目的边界。如果一件事情不做,项目意义是否会丢失,丢下的有什么补救措施,是否还需要二次开工。如果做了,对我们目标帮助到底有多大,会引入多少风险,需要多少资源开销。

最开始的时候风险看起来不多,可以考虑多做一点,也很容易借此把大家团结到贼船上。到了中期,我们对整个项目的时间点已经有了比较清晰的预估,也提前协调好了测试资源和上线准备。但与此同时,整个项目有不断膨胀的趋势,我们几个主要负责人调整策略,一切以项目按时按质交付为第一目标。遇到任何带来风险的包袱,果断丢下。最终卡在边缘完成了交付。

项目目标同步不到位

这个跟上面的相反,范围不清晰会引来项目膨胀,但目标不明确,会在开发过程中丢三落四。

最广为熟知的案例莫过于造秋千。当工程师认为要做的只是在树上挂两根绳子时,整个项目已经在脱离目标和计划了。很多工程师最终得到的任务是给接口加两个字段,至于字段最后干嘛用,也不是特别清楚,更不用说加的对不对了。

同样,我们耗费了很多精力去说明白我们到底要做什么,要向大家确认,做的事情跟目标是否一致。

去年锁元老师带我们做了一个叫项目管理ABC的小游戏,我非常推荐刚开始接触项目管理的同学去玩两把。每次想到这个游戏和凄惨的结果,都觉得好像还有什么没跟大家交代清楚。

规范型项目,项目的意义和愿景要深入人心

我以为有了目标,这事就算结了。直到我发现有一位同学,在参与这次技术改造时,很配合地把那些乱七八糟的接口都改成了约定的 ID,结果在新开的项目和接口里又用回了乱七八糟的标识。交流之后发现,在他理解上,只是以为我们要把那部分接口改一下,为什么要改,不关心。也不会意识到以后新的接口应该按规范的方式来。

这件事情一开始我以为是规范没有确立导致的,加个明文规范:“强制必须使用业务主键来通信”。后来发现,这个规范其实跟没有一样,因为什么是“业务主键”完全是由开发自己说了算。

在我的意识里,所谓的 MySQL范式可能是不言而喻的,但是对于很多人来说,根本分不清何为实体(entity),何为标识(Identity)和属性(property)。你得去跟他们讲明白,举例子,为什么这个字段是ID而那个字段不能是 ID。在别人看来,可能也只是你的一厢情愿。

必须承认这里有个困局,一般项目宣讲会上,愿景、意义、目标普遍被认为是假大空,也是大家最不想听的,通常得到的反馈就是“你啰嗦了那么半天,我就想知道我具体要怎么做”。对于这一点,我自己也一直也没有什么好办法。目前唯一在尝试的,就是在过程中面对成员的困惑时,借机再用意义目标来引导。通常这个时候我讲的也更容易被接受。

最惨的一个教训:拆分到具体可观测的小任务。

站会的时候,我们得到了开发同学的答复:某个接口已改完。后来发现,所谓“改完”。。

这个问题以前就经常遇到,就连《人月神话》里也提过“已完成80%”的梗。但是直到自己的角色成了“项目负责人”,才真正开始思考怎样减少这类风险。

代码未动,计划先行。

计划不一定是把准确的尺子,但一定是任何情况下的行动指南。

最尴尬的问题:砍掉的范围,如何给后人交代

最没脾气的错误:对客户端的了解和发言权远少于后端

经常会面对这样一个场景,客户端告诉你这个太复杂,他那边不好处理。这个时候,即便你的意义愿景再牛逼,目标再清晰,这个时候也发挥不了什么用。

我的一个经验是,主动走进客户端,了解他们的架构。通常情况下,你会发现他们说太复杂是按照要改5个模块算的,当你看了他们的架构后,可能只需要改2个模块就够了。这个过程中,也花了不少时间跟客户端同学在一块,人手把手地给我讲客户端的一些东西。就这次的案例来说,我觉得还是很值得的。

你可能会问,这是否在质疑客户端的专业能力和架构能力。我觉得并没有,之所以能帮他们找到答案,并不是专业能力的差距,更多地是对项目目标的清晰认识和坚持,而他们,正因为对代码太熟了,更容易忘记自己当下的目的。举个不恰当的例子,我觉得我的器官缺一不可,结果一位盲人说,就算没有眼睛也可以活得不差。显然这位盲人并不是在说我眼睛没用。

应对突发状况:灰度前2个小时发现新问题

可以有两分钟的情绪宣泄期,但作为“负责人”,一定要尽快冷静,召集相关的人,商量解决方案,做好接下来的安排。

要顺势而为

开会叫多少人

最不好开口的:要资源

Avatar
huiren
Code Artisan

问渠那得清如许,为有源头活水来

下一页
上一页
comments powered by Disqus