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

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

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

面向读者

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

总流程

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

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

完整流程如下

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

背景

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

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

• 产品是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等严格需求），或者签字盖章的合同交付件。

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

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

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

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

注意熟练度的量化标准并不是按照年龄或者工作时间来划分的（比如3年Java），而是与具体的任务相关，避免出现光环效应。

在部分toB项目中，我见过有些管理者自己不知道要搞啥，就让开发者去猜去试错，做错了后又把责任推给开发者。这种操作极其打击士气，最终就可能直接把项目PL干跑路了。我曾经救火过这种烂摊子（上层焦虑，中层跑路，下层混日子），这种项目就是讲故事骗公司，除了全部换血没有别的办法。

例外与抽查

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

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

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

语境收敛的实践

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

分工决策

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

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

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

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

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

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

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

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

风险管理

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

高语境下的时间估算

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

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

QA

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

在本文中，多次强调了借助“流程”与“规范”以提高效率，但是这样会不会让某个员工成为呆板的螺丝钉呢？其实不然，原因如下

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

空闲时间多了，就有空进行提高了，至于团队的知识管理与改进，以及是否愿意“抬头看路”，不在本文讨论范围类

需求突然变更了怎么办？

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

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

我教他还不如自己做？

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

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

本流程的不足

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

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

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