总体上,是从灵活到固定,从高风险到事务工作,从高语境到低语境到流程。
众所周知,项目管理无法同时满足质量、成本与速度,只能三选二。
随着项目的发展,我当前参与的项目有如下特点
即使人月神话、敏捷管理等理论中均强调软件开发是外科手术般的精英活动,思考是不能外包的。但是受限于当前寒意,大量工作仍然需要依赖低成本的解决方案。
对于此,我的选择是在成本(HC限制)有限下,尽可能高交付速度优先,而牺牲一定的质量与灵活性,即开发“快餐化”。质量方面通过管控CheckPoint进行维护。承认自己与组织的局限也是一种妥协,理想与完美主义只有在预算充足下才可以实施。而在外部环境限制下,只要损失可控,过程可控即可。
软件开发是将客观世界的现象收敛为低语境代码的知识协同过程,收敛过程会失真,代码质量也可能有损失。而你负责是叫做“再表现”的工作,就是作为杠杆,让组织迭代速度更快。
再次强调,软件设计定位是“再表现”,而不是上传下达的“复印机”。你的角色是“教练/せんせい”,而不是“工厂领班”,要通过你的“经验与理性”的认识论作为Context,让项目组员去Intercept,而不是去repeat。
(本文只简介部分事项,具体流程跳过)
网上有很多需求分析的框架,比如
咨询领域实践使用
这些模型已经可以处理复杂的企业项目了。
此外还有软件理论领域
如下CheckList
先分析当前现象,再讨论实现方案,不要将主观的观点与客观的事实混到一起,否则语境很容易发散。常见问题
你拍脑袋想出的通用功能,可能用户使用后全部给你推翻,这里就要及时纠正方向与持续改进,但是总体大方向要正确。千万不要抗拒贴身定制,如果有贴身定制说明你还能苟活着,降低成本是你而不是客户的职责。
任何语言都有局限性、模糊性的,沟通中有高语境(比如自然语言)、低语境(比如代码/流程图)的区别,因此用户使用自然语言讲出的需求或反馈一定是有模糊性的,甚至是Inteceptable的语句。然而代码却不能模糊,它是强逻辑的,因此我们需要将用户的反馈收敛投影为低语境的媒介。
这个过程,在知识论中就叫做“从原始现象到形成认知结果的过程”
业务逻辑的解释只有四种
覆盖或组合解释:对事物进行分类与枚举
因果关系
特征归纳:类似AI分类,比如贝叶斯/决策树。
复杂概念:
你最终的成果就是将场景概念化/投射化,从现象到本体,并输出
将现象解释后,再与用户对齐一次定义,流程就清晰明确了。接下来就可以在现象的前提中加入假设(假设不一定要可证伪的,而是取决于你的信念),来验证你的逻辑了。
这里的解释方法类似“科学解释”,可以参考另外文章
(本文只简介,具体流程跳过)
即寻找解决方案,尽可能找外援,参考业界的类似实践,然后考虑购买或者自研。好的结果并不能代表做出好的决策,反之亦然。
培训组员,并将任务分给组员的分配流程,其中最难的是动作分析与标准工时的估算能力,很容易让整个计划Pending,这是一个复杂系统的BinPacking算法问题,大致流程如下。
这里可以尝试使用Azure DevOps的工具进行分配
实施的前提一定要明确自己想做什么,切忌没有目标与验收标准就提前搞。就算当前目标可能是错的,也要先憋出一个实施计划,否则项目成本会极高。至少要规划一个月的验收标准。
再次强调,项目实施不是金字塔般地发号施令,也不是监工,而是作为观察者或教练,去观察计算指标,对组员进行指导,以反复提高组员的熟练度,进而后期升级为高语境来提高默契的流程,要把自己作为递归机器,辅助所有组员从“混乱”到“层化”。
需求实施的语境有两种体现,我们可以从两个极端来对比
这两种各有优劣,我们讨论的时候注意不要陷入非黑即白的极端对立。
高语境 | 低语境 | |
---|---|---|
定义 | 高度抽象模糊 | 明确严格约束,强逻辑 |
例子 | 创业;indirect approach | 我们要按照RFCXXX规范开发协议 |
优点 | 没有约束,不会限制大家的思考 | 高度约束;考试管控;估算准确 |
缺点 | 望文生义,缺少目标,放大失败 | 管理者单点故障;管控约束;冗余与泛滥;压榨 |
场景 | 创业、POC、MVP,高度长期配合 | 重复搬砖工作;外部人员管控;层层外包 |
针对这两种需求下发媒介的不同,在项目中我推荐基于格鲁夫的“工作成熟度(TRM)”的概念,量化实施者与诉求者之间的配合效率、实施效率的度量标准,进而选择一种语境。熟练度分类如下。
至于需求的格式承载,可以用在Agile协同、Excel、PPT、Markdown等工具,无强制限制
注意熟练度的量化标准并不是按照年龄或者工作时间来划分的(比如3年Java),而是与具体的任务相关,避免出现光环效应。不要让开发者去猜去试错。
当上述流程固化后,冗长的低语境将转为高语境,这时需要完善
没有必要长期进行每日例会,项目尽可能走向仅处理例外的方向。
下文是一个总体的实践流程,从接需求到实施验收的决策流程。
注意如下的颗粒度判断是基于你主观的经验与信念决定的(比如某人能否胜任工作是一个客观事实,但是你只能凭借现象进行主观决策),下面只是一个“经验公式”,不能从逻辑上证明是长期有效的。
我能梳理业务流程? | 我了解工程细节? | 我相信实施者能梳理业务流程? | 我相信实施者能了解工程细节? | 实施方案 | 简写 |
---|---|---|---|---|---|
Y | Y | Y | Y | 口头讨论需求,实施方输出业务图。快速搞定 | A |
Y | Y | Y | N | 输出技术细节文档 + A一起讨论 | B |
Y | Y | N | Y | 输出业务细节文档 + A一起讨论 | C |
Y | Y | N | N | 完善培养计划/重新招人 | D |
Y | N | Y | ? | POC技术方案 + A一起讨论 | E |
Y | N | N | ? | 输出业务细节文档 + E | F |
N | ? | ? | ? | 你这里已经是二传手了 | G |
这里可以看出,当某些场景熟练度较低的情况就会放大项目耗费时间
值得注意的是,我在“实施方案”中是故意没有写主语的,也就是说即可以自己做,也可以分出去给别人做。比如C中关于“业务细节”的场景
这两个区别就是上文提到的“语境(Context)”,这里是可以计算ROI的
需要注意的是,一定要用“流程框架”或者数据来跟踪进展,而不是你本人作为一个人肉for循环去搞假敏捷,否则人数超过6就扛不住了。
另外值得注意的是,你的组员一般都比你技能更弱,所以要提高平均能力。这时又回到招聘问题上了,为了避免“越干越累”,你就要考察出这个人在项目中,到底是只能干重复工作的“录音机”,还是懂得抽象的“钢琴家”,这两种并没有优劣区别,只有是否适合你的工作环境。
在高语境低信息的场景下,决策流程的依据不充分、过程管理重心偏高,最终长期看预判出现失败是必然的。因此需要长期短线微操,只不过比较无趣。
如果把任务全分下去,因为POC占用了更多的时间,工时估算将比较困难,这时只能通过高频决策来修正时间,这种管理流程可能是每周都有变化,因此不要把时间压太狠。
在本文中,多次强调了借助“流程”与“规范”以提高效率,但是这样会不会让某个员工成为呆板的螺丝钉呢?
总体上说的为了确定性,必然工作会是枯燥机械的重复,并且磨灭个人意志。
但是总体来说,效率会更好,原因如下
空闲时间多了,就有空进行提高了,至于团队的知识管理与改进,以及是否愿意“抬头看路”,不在本文讨论范围类。曾经有2位组员因为“过于无聊”而想平薪跳槽,最后仍然被挽留。
相关细化的员工关系建设,培训和职业指导,不在本文范围。
网上有很多瀑布与敏捷之间关于“需求突然变化”的争论,这种变化场景无非就两种
有时你在规划任务时,你会发现某些工作交给别人做比自己亲自做更耗时间(含设计与审计时间),那么是不是就要自己干呢?我的看法是要能容忍项目组员的不足,仍然要培训并分出去,原因如下
总体上来说,本方法是固化甚至是急功近利的流程。
如果是开展算法、技术、预研等产品,那么问题就成为了“外行指导内行”,要讲究“等米下锅”,本文没有能力回答了,可以参考HW的博士管理。