基于语境收敛的项目实施流程
2020-10-29 / modified at 2024-09-15 / 4.9k words / 16 mins

本文主要是通过基于符号、概念、属性、类比的认知方式,降低项目分析的Context失真,在拍脑袋与事必躬亲间做一个平衡的选择。

本文提供一套framework实现了企业级产品中较为灵活的需求分析与实施流程,并只针对如下问题

  • have a demo for now
  • make it the way we expected

面向读者

  • 带有5到6名组员,同时兼任需求分析,方案设计,质量控制的基层员工
  • 进行编码工作,但希望提高效率,减少加班的员工
  • 本文不严格要求必须掌握某项技术

总流程

我们将项目开发分为三个阶段

  • 在需求上,要进行形而上分析,并解释为可命名的概念树(本文仅简要介绍)
  • 在计划上,要基于管理framework去进行标准评估、决策与分工(本文跳过)
  • 在实施上,要基于“熟练度”情况而采用严格或者宽松的实施框架(本文详细介绍)。

完整流程如下

$2收敛需求(本文大致跳过)现象定义关联概念创造概念现象解释覆盖解释因果解释柯里化可行性分析与计划(本文跳过)技能培训研发工具链标准工时规划实施低熟练度事必躬亲形式化文档例外与抽查高熟练度收敛概念

总体上,是从灵活到固定,从高风险到事务工作,从高语境到低语境到流程。

背景

众所周知,项目管理无法同时满足质量、成本与速度,只能三选二。

随着项目的发展,我当前参与的项目有如下特点

  • 产品是toB SaaS类型,核心技术基座已经自研完成,但是更多的债务、定制与客服需求砸过来了
  • 存在大量繁琐的后台CURD、前台、运维、客服、招聘相关工作,但是没有HC
  • 项目成员分散在四个地方,基于语音/文字进行远程沟通

即使人月神话、敏捷管理等理论中均强调软件开发是外科手术般的精英活动,思考是不能外包的。但是受限于当前寒意,大量工作仍然需要依赖低成本的解决方案。

对于此,我的选择是在成本(HC限制)有限下,尽可能高交付速度优先,而牺牲一定的质量与灵活性,即开发“快餐化”。质量方面通过管控CheckPoint进行维护。承认自己与组织的局限也是一种妥协,理想与完美主义只有在预算充足下才可以实施。而在外部环境限制下,只要损失可控,过程可控即可。

软件设计的角色

软件开发是将客观世界的现象收敛为低语境代码的知识协同过程,收敛过程会失真,代码质量也可能有损失。而你负责是叫做“再表现”的工作,就是作为杠杆,让组织迭代速度更快。

再次强调,软件设计定位是“再表现”,而不是上传下达的“复印机”。你的角色是“教练/せんせい”,而不是“工厂领班”,要通过你的“经验与理性”的认识论作为Context,让项目组员去Intercept,而不是去repeat。

需求

(本文只简介部分事项,具体流程跳过)

网上有很多需求分析的框架,比如

咨询领域实践使用

  • 5W2H
  • LTC(线索到现金)
  • HW的双V模型
  • IBM的IPD流程

这些模型已经可以处理复杂的企业项目了。

此外还有软件理论领域

  • DFD设计/UML设计/ER设计

田野调查注意事项

如下CheckList

  • 事实:用户对现象的描述是什么,是否可观察,是否有符号/概念可以指代这个现象?是否有可以参考的同类产品,同类产品中叫做什么?事实一定是循证客观(可证伪)的场景。
  • 观点:“我认为”/“客户认为”/“领导想要”/"领导抢地盘"这些都是主观的观点,是不能作为论据的,而需要经过自己验证。

先分析当前现象,再讨论实现方案,不要将主观的观点与客观的事实混到一起,否则语境很容易发散。常见问题

  • 有些客户可能了解一些技术术语(terminology)就认为自己懂了,甚至未经试用就对你的产品进行乱评价,可能把项目搞凉,这时你更要注意及时拉回主题
  • 大部分客户不懂项目验收,没有结束上一个又给你安排新的工作,你要明确验收点,一件件清空
  • 有些客户跳过你,找你领导插队做需求,你要能承受压力,决策一定要客观循证
  • 有些客户的确需要某个功能,但是网上没有参考,这是高语境问题,要参考下文

你拍脑袋想出的通用功能,可能用户使用后全部给你推翻,这里就要及时纠正方向与持续改进,但是总体大方向要正确。千万不要抗拒贴身定制,如果有贴身定制说明你还能苟活着,降低成本是你而不是客户的职责。

需求收敛

任何语言都有局限性、模糊性的,沟通中有高语境(比如自然语言)、低语境(比如代码/流程图)的区别,因此用户使用自然语言讲出的需求或反馈一定是有模糊性的,甚至是Inteceptable的语句。然而代码却不能模糊,它是强逻辑的,因此我们需要将用户的反馈收敛投影为低语境的媒介。

这个过程,在知识论中就叫做“从原始现象到形成认知结果的过程”

现象解释

业务逻辑的解释只有四种

  • 覆盖或组合解释:对事物进行分类与枚举

  • 因果关系

    • 经验统计:内有时空连续,归类演绎方法。本质上是一种不严谨但实用的统计经验。
    • 逻辑计算:通过强逻辑符号进行证明,一般场景需要高度抽象。
  • 特征归纳:类似AI分类,比如贝叶斯/决策树。

  • 复杂概念:

    • 单纯繁琐的复杂:比如巨型MES/CRM/ERP类需求。这类需要复杂的概念化。
    • 非线性(反身性):即 Reflexivity,比如根茎状,Curry化,递归,此处跳过。可以参考复杂系统理论。
      • 正负反馈问题:或者称作滚雪球效应,或者“Indirect approach”。
      • Beer distribution game:指因果中间间隔了太久的时间空间,导致没有分析出来。

你最终的成果就是将场景概念化/投射化,从现象到本体,并输出

  • 术语Wiki一份,后续采用一致的术语对话
  • 覆盖了各种可能的情况和细节(这个是设计而非开发的责任)的场景模型,最好是WBS的树状分解。

将现象解释后,再与用户对齐一次定义,流程就清晰明确了。接下来就可以在现象的前提中加入假设(假设不一定要可证伪的,而是取决于你的信念),来验证你的逻辑了。

这里的解释方法类似“科学解释”,可以参考另外文章

可行性分析与计划

(本文只简介,具体流程跳过)

可行性分析

即寻找解决方案,尽可能找外援,参考业界的类似实践,然后考虑购买或者自研。好的结果并不能代表做出好的决策,反之亦然。

计划

培训组员,并将任务分给组员的分配流程,其中最难的是动作分析与标准工时的估算能力,很容易让整个计划Pending,这是一个复杂系统的BinPacking算法问题,大致流程如下。

  • 明确依赖关系:通过PERT图,找到高阶的项目最优先事项,生成为Backlog(难以通过IT系统承载)
  • 录入:录入本次迭代的backlog需求清单到本月区间,拍脑袋录入总员工小时
  • 排序:优先做场景需求,再做不赔本的需求,最后有时间再做些小改进。其它需求砍到下个月
  • 分配:评估项目组员与需求间的熟练度,优先分配熟悉的工作,等项目上线后,尽快做好知识外显化工作

这里可以尝试使用Azure DevOps的工具进行分配

实施

实施的前提一定要明确自己想做什么,切忌没有目标与验收标准就提前搞。就算当前目标可能是错的,也要先憋出一个实施计划,否则项目成本会极高。至少要规划一个月的验收标准。

再次强调,项目实施不是金字塔般地发号施令,也不是监工,而是作为观察者或教练,去观察计算指标,对组员进行指导,以反复提高组员的熟练度,进而后期升级为高语境来提高默契的流程,要把自己作为递归机器,辅助所有组员从“混乱”到“层化”。

实施中的高低语境

需求实施的语境有两种体现,我们可以从两个极端来对比

  • 高语境/战略领域:宏观方向,计划(比如我要做一个医疗SaaS系统),概念关系,心流
  • 中语境:比如Java design pattern,algorithm等约定俗成的pattern与decorators。
  • 低语境/确定性工作:基于符号逻辑的形式化规格(比如地铁,飞机、通信、仿真、DSL等严格需求),或者签字盖章的合同交付件。

这两种各有优劣,我们讨论的时候注意不要陷入非黑即白的极端对立。

高语境低语境
定义高度抽象模糊明确严格约束,强逻辑
例子创业;indirect approach我们要按照RFCXXX规范开发协议
优点没有约束,不会限制大家的思考高度约束;考试管控;估算准确
缺点望文生义,缺少目标,放大失败管理者单点故障;管控约束;冗余与泛滥;压榨
场景创业、POC、MVP,高度长期配合重复搬砖工作;外部人员管控;层层外包

针对这两种需求下发媒介的不同,在项目中我推荐基于格鲁夫的“工作成熟度(TRM)”的概念,量化实施者与诉求者之间的配合效率、实施效率的度量标准,进而选择一种语境。熟练度分类如下。

  • 新员工/跨部门对接:需要先培训,并细化到接口/DB/索引等细节都要关注
  • 一两个月后:只用提供接口与表设计,技术细节不再关注
  • 长期配合:只用提供符号与符号的相关性,只关注产品层,让员工去设计方案

至于需求的格式承载,可以用在Agile协同、Excel、PPT、Markdown等工具,无强制限制

注意熟练度的量化标准并不是按照年龄或者工作时间来划分的(比如3年Java),而是与具体的任务相关,避免出现光环效应。不要让开发者去猜去试错。

例外与抽查

当上述流程固化后,冗长的低语境将转为高语境,这时需要完善

  • 流程外的处理方法
  • 抽查流程
  • AAR持续改进,上线前后的版本改进会

没有必要长期进行每日例会,项目尽可能走向仅处理例外的方向。

语境收敛的实践

下文是一个总体的实践流程,从接需求到实施验收的决策流程。

分工决策

注意如下的颗粒度判断是基于你主观的经验与信念决定的(比如某人能否胜任工作是一个客观事实,但是你只能凭借现象进行主观决策),下面只是一个“经验公式”,不能从逻辑上证明是长期有效的。

我能梳理业务流程?我了解工程细节?我相信实施者能梳理业务流程?我相信实施者能了解工程细节?实施方案简写
YYYY口头讨论需求,实施方输出业务图。快速搞定A
YYYN输出技术细节文档 + A一起讨论B
YYNY输出业务细节文档 + A一起讨论C
YYNN完善培养计划/重新招人D
YNY?POC技术方案 + A一起讨论E
YNN?输出业务细节文档 + EF
N???你这里已经是二传手了G

这里可以看出,当某些场景熟练度较低的情况就会放大项目耗费时间

值得注意的是,我在“实施方案”中是故意没有写主语的,也就是说即可以自己做,也可以分出去给别人做。比如C中关于“业务细节”的场景

  • 可以由我输出书面的详细业务流程,再书面告诉实施方如何搞,然后开工搞(低语境,强指示)
  • 也可以由我先和实施方口头传递,讨论后再由实施方补齐业务细节文档再次对齐,然后开工搞(高语境)
  • 当然你也可以选择拉上一堆人开会,效率就不得而知了

这两个区别就是上文提到的“语境(Context)”,这里是可以计算ROI的

  • 比如你认为“事必躬亲”更快,当然可以自己搞,但是你会越干越累,而且反映了招聘与培训的不合格;
  • 如果你认为可以分出去,那么可以让别人先POC再等汇报。
  • 就算是拍脑袋,也要输出验收标准与关键节点的CheckPoint。

需要注意的是,一定要用“流程框架”或者数据来跟踪进展,而不是你本人作为一个人肉for循环去搞假敏捷,否则人数超过6就扛不住了。

另外值得注意的是,你的组员一般都比你技能更弱,所以要提高平均能力。这时又回到招聘问题上了,为了避免“越干越累”,你就要考察出这个人在项目中,到底是只能干重复工作的“录音机”,还是懂得抽象的“钢琴家”,这两种并没有优劣区别,只有是否适合你的工作环境。

风险管理

在高语境低信息的场景下,决策流程的依据不充分、过程管理重心偏高,最终长期看预判出现失败是必然的。因此需要长期短线微操,只不过比较无趣。

高语境下的时间估算

如果把任务全分下去,因为POC占用了更多的时间,工时估算将比较困难,这时只能通过高频决策来修正时间,这种管理流程可能是每周都有变化,因此不要把时间压太狠。

  • 不要有小市民的算计心态去“低估”工时,“咬下的分量超过你可以嚼烂的限度”会导致无法承担意外
  • 即使全部开发任务让组员去干,讨论与验收(流程图/QC/用例)也需要占用你的时间,个人的最近验收耗费比例大致为1:4
  • 部分业务随着进展需要不断决策(比如网上没有参考项目),因此需要定期对齐语境,这场景估算工时基本上不准确,可以采用后记录的方法录入。
  • 这种方法本质上是精确化生产,管理压力极大,但是速度是真的快

QA

普通员工会不会技能废掉?

在本文中,多次强调了借助“流程”与“规范”以提高效率,但是这样会不会让某个员工成为呆板的螺丝钉呢?

总体上说的为了确定性,必然工作会是枯燥机械的重复,并且磨灭个人意志。

但是总体来说,效率会更好,原因如下

  • 此方法久经考验(本质是泰勒模式),而且权责边界清晰,不会遗漏
  • 员工的大块完整时间(比如5小时)会被合并为核心业务,而不用反复开会、客服等讨论导致被动打断/切换Context
  • 最终需求成本低,上线快,加班少。

空闲时间多了,就有空进行提高了,至于团队的知识管理与改进,以及是否愿意“抬头看路”,不在本文讨论范围类。曾经有2位组员因为“过于无聊”而想平薪跳槽,最后仍然被挽留。

相关细化的员工关系建设,培训和职业指导,不在本文范围。

需求突然变更了怎么办?

网上有很多瀑布与敏捷之间关于“需求突然变化”的争论,这种变化场景无非就两种

  • 产品经理或者SE一开始就拍脑袋搞错了,这种必然是产品经理交学费了,即羊毛出在猪身上。
  • 由于外部环境导致发生了变化,这个本质上是复杂系统中的啤酒销售流通试验,是要通过降低反应延迟来解决的,这里还是要提高语境收敛的速度

我教他还不如自己做?

有时你在规划任务时,你会发现某些工作交给别人做比自己亲自做更耗时间(含设计与审计时间),那么是不是就要自己干呢?我的看法是要能容忍项目组员的不足,仍然要培训并分出去,原因如下

  • 你的输出评价是团队的总输出,而不是单人的
  • 招聘与培训是你的责任,目前来说大部分工作即不用拼天赋,也没有能力成长
  • 如果你的“验收组员时间”与“亲自开发”的时间比例为1:1,建议尽快换人。

本流程的不足

总体上来说,本方法是固化甚至是急功近利的流程。

  • 基于泰勒的模式,过于官本位,其设计、计划与实施被严格地分工,弦蹦得太紧。
  • 固化的流程与框架可以优化进度与质量,压缩时间,但是相应地出现了惧怕失败与保守主义,压抑了创造性的活动。比如在这个流程中,能高效完成现场已知的交付,但是很难从无到有创造新东西(进度压着你)。
  • 将所有人变为了可替换原件,但是这种搞法只适用于中低难度的快餐式开发。

如果是开展算法、技术、预研等产品,那么问题就成为了“外行指导内行”,要讲究“等米下锅”,本文没有能力回答了,可以参考HW的博士管理。