这是一个失败的项目的复盘，领导们当然是从一个成功走向另一个成功的说辞，不论是甲方乙方。
我还草稿没写完，callback就来了
1、项目开始于2024年的10月，但甲方一开始也只知道要求我们做好业务梳理，最大的要求是可以审计。但是审计需求是结果，是什么驱动的呢？并且新上任的二级为什么是管财务的呢？这下公开清楚了。md中期才告诉我们这是政治任务，二级三级混子之前也不知道只是在逐级麻木的传达混日子，但凡二级三级及基层项目经理好好领会上级，传达齐平信息深入贯彻落实也不至于那么失败。
2、20250117追加：写着写着还没写完，结果CEO高念书的大雷先来了，乐了
部门/人员背景
- 老部门经理，接触有限，没看出来他技术还是管理牛在哪，倒是留了个烂摊子，拍拍屁股去甲方了。后面上的新部门经理W是从老研发里上去的，管理手段自然是没有，其说话方式是用"这个怎么玩"来表达一个技术上的事情，模糊化边界，用人与人之间的私人关系来作为他管部门各个项目的载体，受益人是他，用此种沟通方式模糊化了每个人个人的利益与他的利益与部门整体利益，部门内已是离心离德（最新\除了准备养老的混日子的）。这种平均主义实质上是某种奴才制度，属于某种奶头乐，总体概括上我称之为温和派PUA，攻击性弱一些的人是不会察觉的。
当然我们关系还不错的说。
再往上新来的总监推他的"管理"制度，这个制度为：互联网的管理+传统行业的薪资+油腻男语录兄弟们努努力。而YX这个部门得以运行至今，底层逻辑为宽松的制度+结果导向，允许每个人占山头不可替代养老。如果他想让大家成为他的低薪零件，那部门会先散掉。
这下子这个总监和W就有机结合了，边界模糊的言语与刀刻般的制度利益侵犯。
-
因为域外项目，就要和北京现场部门的合作，而现场部门出了个项目经理，还是现场私人招聘回归的，一开始所有人都觉得她应该挺厉害，履历那叫一个精彩。但是项目失控后，她就被替换为了一个推广人员。怎么说呢，所谓的管理专业人才，会做成本预算之类的管理操作，但是对于0-1项目的落地落实来说，她的专业能力是不够的无法起到推动作用。祛魅：坐上那个位置不行也行，身份大于实力。
-
这个项目的中后期引入了战略ZL部门介入，也得说一下，ZL的总监和项目经理，从私人来说都是挺好的人，但是相处许久让人不得不思考到，他们的价值高在哪里；如果说是一般人员还好，但总监和经理看下来能力并没有超越，经理甚至是0业务吸纳能力，可以说是一个机器般（中性褒贬）的中年人坐在功劳谱上撞钟。ZL部门中间还摇来T4的人支援，结果不堪入目，能力极差。我对自己的重新定价以及对于高级人员的祛魅，他们功不可没。
-
别的不多就领导多，牵扯到3方部门自然3方一堆总监，出什么事都是假大空会议分析客户精神可以拒绝挂在嘴上是糊弄人的态度，真实没人去出头担责，然后总是去满足一切要求。飘在天上做指挥。
-
整体上的研发人员配置，比起迫在眉睫的缺口，那些领导会先考虑工时与成本分钱，烂到根上了，领导们实际上是为了自己的薪酬而工作而不是部门或公司项目，权责利益不对等。总体上给了10来个人，但要说符合我认定的5年该有的水平，只有2个人。
外部人员甲方、共同承建的后面慢慢引入
摇篮的开始-调研调研还是tmd调研
【202312-202402】
领导都在为了自己的工资负责，权责的不对等，催生出整体承担的负面结果。
提出问题也要解决问题，我们解决不了，领导出于对自己工资的责任会拉会，但是形式大于作用。
初见端倪的甲方国企病
请时刻保持攻击性与主见
想要忘掉技术
标
去年10月招投标，我没有参与，是W和一个新招的"规划部"的同事去的。形式居多，内定之后通过各种资质要求卡死其他公司。
我们部门参与进来是因为北京区的人接到了这个立项，而且认为这个我们的部门比较匹配。
当时W就和甲方业务侧有过沟通，但是研发思维只想着设计实现，没能识别出这里的业务，其实和我们的产品模式，并不是想象中的匹配。报酬专业领域的业务弯弯绕太多了。
同时复盘可认为，W的说话方式->思维方式，让他得知了一些业务侧提供的信息（洗钱黑钱数据准不了）以及其他产品可知的业务信息（类似），之后，只是当作了谈资，没能及时识别出这里的巨大业务风险，最终结合引出甲方就标书内容的无限甩手既要又要还要的真实建设范围膨胀。
从复盘的角度，他们没做好全部的本职工作，标确实稳稳地拿到了，但是漏洞百出的标书成为了这个项目一切祸患的直接根源。（虽然是因为Y系的甲方从来没有过和这次的甲方一样如此拟人的）
调研
这个大阶段，我先给整体的顺序概括下，后面回忆起来说的有些乱了
整体上调研是线上->线下1阶段（提纲、乱问、乱小汇报）->线下2阶段（业务流程）
标书确定下来之后，我们就立刻开始了调研，一切开始于12月中旬。
标分为了2部分由2家公司承办，后称我们为A，对方为B。
此处出现第一个巨大风险：为什么我们的人没有在PMO里，而是B，事实上多出来一层利益为PMO工资的B公司的二甲方。这直接导致了，我们的声音上不去，上面真甲方的声音被引导。
PMO只对甲方负责，甲方要什么他们就哈巴狗传达，甲方飘在天上夸夸群指点江山，B就无脑护着传达，这我们又怎么做的好产品呢？
- 如果这时候能够识别到，上报总监，不管他上不上CEO去要求我们也得在PMO有人，至少留个痕给内部和外部，后面吵架也好吵。但是......唉，即使当时识别出来，恐怕喝酒为主的北京总监ZHOU和我们的套话总监LK，也只会打哈哈把球甩给我们。
还是tmd标书的坑，要我们调研，调研甲方自己都梳理不清的业务，完全超过承建系统一般的实施范围了。此句话重点在于甲方自己都梳理不清
好了风险说完了，这个阶段的正题是调研，我们，要，调研，需求，做产品。
-
对，没错，我们一堆研发，去做产品。
-
我们一堆没识别到风险的研发，去跨赛道，做产品需求，同时还有B在那指指点点，不按她说得来，她就说汇报下甲方领导讨论吧。
-
当然她前期确实让我们学到了一些方法论上的东西，引导项目推进的套路
txt
长期目标与短期目标，要达成分别要做什么
结构化的预定要提供和输出的文档、产出物，确实做到了优化调研的执行，让临时人力和主干都有明确的方向
强迫（褒义）你也要你去输出总结，整理汇报，不止是应付上面，确实可以让思路更清晰
在推进过程中，时间的预设计划先行，我们的老部门经理管的一团乱就是因为他是混上去的研发，不懂这个
在跨职能部门间的合作中，对方并不一定会真的配合，只是装个样子配合或者他们不知道该这么配合，要充分考虑对方情况，让对方"知道"我们要做什么，以可以"机械式"的配合，最小限度的破坏以达成目标
现实中的事务不是搞技术写代码，这个那个人都想知道一下让汇报，所以每个事都要实时有产出随时糊弄。- 但随着项目一个个阶段进行，越来越发现B和后面研发阶段会提到的我们战略部门的项目经理HB一样，是吃老本的没有根据实际情况变化。
第一阶段是线上调研
STEP1：从甲方成本控制的考虑上，B认为我们应该先摸几个省的底，线上以会议的方式贯通业务后，再进行后续的系列调研。这个提案是很正确的考虑。
但是从复盘的角度，B忽略了一个事情，那就是这个项目的诉求特殊性是独一无二的，这种操作想达到预期结果可达成性为0
对于一个我们自己足够熟悉的赛道产品，去复用到同类产品上，是可以如此调研的，B给出如此建议我相信确实没有坏心思（至少现在没有），B的公司做的产品就是如此同质化的，所以给出如此建议很合理。
\
但实际上，马后炮：这个报酬系统的建设，是前无古人的，难度不在于业务的研发实现，业务本身才是难度。可以说不具备任何同类产品可以借鉴，因为业务本身的难度在于......嗯......在于"制度"，是制度与人心结合产生的庞杂的基层实际业务执行情况，我们首先不可能摸查几个省代表所有，其次这几个省也不可能线上拉个会议或者说线下会议就能摸查的清楚。
从调研开始，这个项目就注定不可能善终了，不是因为B的忽略，她没做错什么，至少现在还没
而是因为，即使识别出来，我们内部的体制权责，导致不会有人去压着甲方一级二级做决策更改标书的，标书已经注定了要做全国，那我们识别出来业务不可平铺又能如何呢？
甲方项目经理是个装嫩的"小姑娘"（代称YY），她整天拿着标书说事（后话，这里还没暴露），即使她领导其实至少当时还没纠结标书范围。我们在中后期得知了这个项目是个政治任务，时间不能改，结局已注定
说来说去怎么还是标书埋的坑，草。
后面我们就不提全国还是几个省了，就认命了，【全国】。
- 但话说回来，如果投标期就识别到项目的重要程度为政治项目，识别到业务巨大风险，我们可以去要求更多足量的钱，公司内部根据对应的钱也至少可以投入足量的人，各合作部门也不会扯皮你分多少我分多少，也不会到中期才升级为战略项目，我们对于甲方的沟通态度也会强硬很多，会更早的要求采用强硬态度的授权，也许发展会大不相同吧
虽然我悲观，一路做过来，我不认为自己的部门具备人才储备，即使升级战略项目投入人员也很一般很一般。但总得乐观的推进吧......
STEP2：线上调研需要提纲
这是B的经验主义（之谈），STEP1中闲聊过了，不可硬套。我们没人识别到，所以就盲从了。
我们提出了"不知道问什么"这一难点，B的解决答复是先按标书拟定一份收集材料让线上调研的省提供上来，然后阅读材料后对于再拟定调研提纲。
真是太厉害了B姐（棒读）
从复盘的角度，这不是循环自我论证吗......标书是10月拍脑袋聊业务定的，标书本身就不可作为业务可信描述以参考，用不可信标书的去收集材料，又能分析出个什么超过标书外的结论吗
即使抛开不可信的标书来说，收集材料即使是可信材料，我们也不必然分析得出有效提纲。
所以有个巨大的感悟是，语言的艺术，这和GPT类AI有共通处，连贯的语言并不具备离散数学上的命题真特性。话听起来是那么回事，但是内在因果是不通顺的。不幸的是管理类人才通常会说出很漂亮的话，经验不足无法当场反驳
最可靠的调研方式就在我们生活的国家中：到人民群众中去，上山下乡！
想做好这个项目，我当前复盘认为这个阶段只有一条路，下到每个省去实际参与到业务中。再之后才可能有足够的论据去说服甲方一二级，让他们再去和巡察组汇报，期许缩小范围或者延长时间且追加预算。
即使说服不了，那也可以归因于甲方支持力度不够，我们尽到了责任，而这些国央甲方最怕的就是责任在他。
调研方式的错误预言了不会产出期望的调研结果，我们按照当初的方式调研，发现最后其实没有东西去说服他们甲方。因为调研方式和出发点就错了 当时缺少祛魅，无法清醒，还会被W似乎有理有据的说一番，事后看他当时是被B洗脑了，要到4、5月份才清醒。
STEP3：执行线上调研
前面说的够多了，实际执行中，没有意外的发展成了很皮毛的业务"质询"，地市老师们也挺尴尬的。
从复盘角度，不出意外的没有什么有效推进项目落地的产出，摇篮呵。
之后已经是1月中旬了
第二阶段为线下调研
哦对了，我们热血澎湃的3人小队！我+部门经理W+北京出的项目经理ZHAO，没人意识到事情其实已经在失控的严重性，当时被B引导的在盲目学习她的套路。
对于ZHAO，我和W都是感觉很高级，海归+有大经验，说话一副英语说多了的感觉的中文（褒义），此为1；
加上W邯郸学步的管理方法论，在这时候考虑和北京的勾心斗角，让ZHAO去抗，想我们研发撤到幕后，此为2；
1、2结合产生的直接结果是ZHAO扛不住，我们的指挥体系一盘散沙，被B完全控制了。而这个时候W还没想着上升事态上去换人，而是拿这个和北京部门及其项目经理ZHAO扯皮能提供出多少人的工时挂靠。
ZHAO作为我方的项目经理扛不住，我们的调研方式实际被B非故意的引导到了错误的方向，综合决定了调研阶段的全面失败。从复盘角度来说，如果及时上升事态换人，摇来ZL部门的HB老油条，我们是可能把真实的调研诉求与计划独立性争取到的，即实地调研，并且也可以识别上报做全国还是几省的风险
- 这里的归因暂且只说我们自己的问题，甲方后面单独提
STEP1：服了，甲方内部就这么个政治项目支撑力度吗
在B的非故意错误引导下，我们列出了不可信提纲。
现实与代码不同，安排一次线下调研需要给每个地市的老师都安排好食住行，这个由甲方YY做了。
再之后我们还需要拟定每天的日程表，作为调研组各成员与来京被调研的地市老师的行动参考。
最后是给这个时间表填充上对应的提纲内容，理论上老师们提前准备对应的资料，以有效进行调研。
幽默的是，对于甲方老师们的欢迎，买些水果小蛋糕，居然要我方出资而不是甲方总部，无奈。
花点钱是小事，重点在于，甲方此时，是一点没有表现出"这是个政治项目"的样子，他们还会就老师们来几天多一天少一天来扯皮。这里说的扯皮没错我就是在指名道姓互联网上盛传的国央企酒囊饭袋领导：假大空话一套套，跟他要个结论指示什么都没有，你说要调研两周它说太多了，它说要你仔细分析是不是真的要2周，给出2周的依据。然后你给出了依据，B又横插进来说这个是不是真的要这么多时间，真是对自己的PMO工资负责，太负责了。你受不了妥协成少点时间，这个二级又说会不会不够。
- 此时不同方的想法
- 二级的视角是：厂商搞定一切，她所知的信息是：承办方都是长期合作伙伴，具备大量工程建设经验。她只需要关注下进度，提供些帮助。
- 我们的视角是：标书内容圈定了范围（我们并没有人仔细看过标书，包括参与标书拟定的W和规划部同事），我们就是来调查下业务细节按照标书实现系统的。我们知道要调查，但是其实很含糊，还没人意识到其实我们不知道该调查什么 我们的视野局限在了研发思维，大前提发生了错误，只想着和原有算酬系统类似，把模型往上套做个适配就好，可是这个项目从后期上帝视角看，重点在于帮助甲方梳理业务流程还要进行合理性改造
- YY的视角是：厂商要去按照标书去摸清全国各省的业务细节，然后建设系统，她不知道怎么做，但是知道我们要建设。
- B的视角是：B确实有资历，他是知道如果想做一个全国性的系统，标书只能作为一个承载范围，具体需要详细的收集各省差异形成标准流程的，这个STEP3可以提到她也有局限性。
- 上帝视角：
- 二级和我们一样，不知道这个业务的复杂性，她是管财务上去的，只知道自己一亩三分地财务的知识
- 甲方内部不知道流程该是什么样，总部对于各省无约束力和详细的知晓。
复盘的角度二级和B这时居然也还不知道这是政治任务，还在这扯皮我们能不能完成提纲日程的进度，还考虑各位老师的下班时间，出差时间？按我理解的政治任务那就一切以完成为唯一参考了。
复盘的角度，我们忽略的两大点
一为项目背景仅仅是技术+简单业务层面的，没有去考虑背后的时代背景、政治背景，也就是大背景；
二为没有及时定性甲方及我方各人员素质，定性后针对性的换人和开怼
第二点主要是针对甲方人员定性，他们居然惊人的符合国企尸位素餐的刻板印象。后面才会逐渐涉及到一个个人。
这可不是我有什么刻板印象，我是攻击性比较强，对抗思维的人，所以最先过敏了。后面来的各部门的项目经理、总监、CEO及研发测试运维兄弟没一个不在骂甲方不似人，一个50多北京本地部门的运维头头老大爷，多佛系的一个人啊，被恶心的群全退了拒绝和甲方继续接触。
STEP2：公务员的一生
在线下调研的推进过程中，感觉YY也挺可悲的，一个职责上是甲方的项目经理的人，每一步推进她考虑的都是端茶倒水，领导座位怎么安排，各位老师的行程怎么办，经费怎么办，具体的业务落地她实际上是没在想的，只是对于B言听计从。再多了解些知道了她是从地方调过来的，如果说是就靠这个本事，那这个企业算是完了，当然确实也是可持续性的在完蛋。
YY没什么自己的意见，领导的意见就是一切，她会无时无刻拿着领导的鸡毛当令箭来执行，可悲可叹，人是好人，在国企内确实需要这样的人，这样子也轻松些，一声叹息。
复盘的角度从识别到YY的特性后，我们就应该忽视她了，让喜欢做什么就做什么，但我们的执行上一定要可以越过她和B直面决策者，进行力争（虽然我们也说不出个123当时，但态度要出来，做这种项目先讲立场后讲对错缘由，不能让你决定了责任却是我的）。 但当时我们就当她是小姑娘做事毛躁心是好的，止步于此没有上心多去想想这会带来多少阻力。
还必须要提的是W的说话处事的圆滑方式，对于项目的害处：
- 圆滑的人可以在一心的体制内步步高升，但对于多方竞争的处境中，他在出卖我们自己的利益。
- 前期是不知道我们居然竞争至此，后期是他知道了还在那圆滑。
STEP3：机枪左移50cm
有人看电影看乐子，我感觉这个项目在照镜子。
1、线下调研前，我们要做几个准备工作：（1）结构化的提纲 （2）需要产出的调研结果模板。上文线上调研可能提到了，实质上我方不可能给出准确可靠合理的提纲和结果模板。在此基础上B也不懂这些业务，但是她却要审我们的调研提纲，并作出指导，同时又不对结果负责。
我当时提出了对于这个提纲的意义的质疑，但B按照她的刻板经验是这个流程就认定了这么做，而当时我缺少方法论也无法反驳他，复盘时才切实清楚了原理上为什么给不出唉。
我们的内部也就调研提纲的内容产生了争执，非技术人员认为于提纲应偏向业务实际操作流程，技术人员觉得是问case。
我的质疑也只是作为技术负责人，我认为这个调研是对于系统落地无意义的，我们的系统应该是配置化抽象承载、租户化定制扩展的，如果要落地只需要搞懂每个标书的功能点有多少种case即可，然后和之前的系统一样套路化的设计实现即可。
可是您可能也想到了，标书只是一个只是飘在天上的范围，这些功能都不一定准，甲方更关注我们去帮他们把业务流程梳理了，然后定制功能流程。
本质上的差异在于对标书的理解：我们想着参考标书建能力中台产品，甲方想的却是统一管控、业务流程收敛
2、线下调研的日程安排一团糟，B和YY以及二级，就调研哪几个省，来多少人及人员配置如何、会场分布如何，要求细化，我们一个个看：
- 调研哪几个：这个细化要求很合理，问题在于决策权责的颠倒，谁决策谁负责，但是B作为二狗子，和甲方搞成了我们好像有决策权但是实际要二级开心了点头，其实我们什么都定不了，但责任全在我们身上。
- 复盘的角度，这个东西就该是你甲方决策好的，我们是承建方，甲方你不知道哪些省业务什么什么样那是你内部出了大问题，我们可以做但得加钱，责任也不是我们的，这都要拎清楚，邮件是必须上去的，直接请命到总监和对方二级。您可能还记得，W的圆滑，这延缓了矛盾的爆发与对抗性证据积累的过程
- tmd还是标书搞得范围太虚甲方什么都可以往里加
- 人员配置：很合理，出差来的人应该业务职责上可以包住他们省全部的业务场景。
- 会场分布：细化要求是合理的，但是执行层面出了问题
- 从复盘的角度来看：实际是B有自己的小心思，我们两家公司承办的部分不同，也就导致了业务特性不同，差异化程度不同，B的业务产品同质化，差异化是可控的，调研方向是清晰的，他们的倾向是一个会议室同时调研3-5省，共3个会场。而我们的业务复杂度差异度都是不可预估，仅可知的是很复杂，我们的倾向自己分析出来应该是希望一个个省细化了解的
- 当时B有说过"我们终究还是一个项目"，并且YY没脑子和那个二级，也暗示一次做完，不要分开调研___原话是："不行，我们不分开调研"（自行带入小孩语气，唐完了）
- 复盘视角：我们不应该妥协，最好的处理是识别并要求甲方限期决策做全国还是几省，不决策那责任在谁清清楚楚，也不至于后面就总体计划要求延期没法据理力争。调研方式也按实情去要求，同意后那调研结果是我们的责任，不同意就是你的责任，可惜当时不清醒
复盘视角：这里首次出现了一个问题并贯穿始终：B不对我们的决定负责，却可以肆意以PMO之名干涉影响我们的决定。同时W的圆滑会模糊掉这种侵犯，会幻想问题可以聊天解决不上报，非主观故意但客观如此，聊天没有解决一次问题，只是压力到我方执行。PMO和我们是对抗方，她哄好上级领导就行了，不会在意我们的实情
祸根是最开头讲的，我们缺少PMO席位，标书唉标书。
3、我们内部对于线下调研的支持
（1）我们自己做的不到位，没能识别到B的调研方式对于我们业务特性不可行这是说了很多遍了，同时这里还有人力投入问题：各省分隔到3个会场，全部省业务都可以分为2种模式，简单算术知道需要至少（1主问+1备用+1支援）*3会场*2模式=18人。
但是W和北京部门都在推脱我的人手紧缺呀出不来人呀，最后搞实习生填线、规划的人填线、开发/运维填线，唯独没有专业的产品人员，还只凑出了9个人，无奈。
导致了什么结果呢？每个人都会按照那个不靠谱的提纲问，自然会被老师们发散开，然后每个人的侧重点就不同了，在[4、]中即时暴雷。并且人数不够场面控不住，对于老师们的利用率低。
（2）在群策群力拟定调研提纲时，发生了思维不统一的异端。原因在于我们中推选不出一个足够有自信乾纲独断的人来拟定，每个人都不专业。就出现了甲说这个要问，乙说这个要问，丙说我觉得这两个都不重要。 复盘的角度，如果我们足够敏感，就该意识到缺少专业产品及时升级摇人了
4、线下调研的每天晚上，B出于PMO的职责都会要求总结调研结果，开会交换信息改进/调整明日，这个执行路径无疑是正确的。
错误发生在执行细节，B的公司做的是同质化的系统我们之前提到过，他们可以轻易的做到给出合理的提纲，并根据提纲以一次一个会场调研多个省的方式，得到可靠结果，按他们自己的套路流程晚上输出结果改善第二天。
但对于我们来说，这就是不可行的： 我们的业务导致执行过程出现了，我们的问题，不够细。当我们抛出一个调研问题时，5省的老师会先回答，但是回答完后，反而变成了他们之间聊起了这个问题的发散点。我们对于各省业务复杂性的不知道导致无法控场，因为他们说出的每一个小点，都是我们的知识盲区，只得紧急学习记录。
结果是什么呢：每天我们都会收集到一堆堆的信息，但是和我们的提纲符合度较少，每天晚间我们A公司内部的会议都会抛出一个个新问题新盲点。同时我们居然还想着按照B的路径去整理出调研阶段结果给他们同步然后整改第二天。
生搬硬套结果可想而知，内部执行时怨声载道，一个简单的调研小点我们内部也达不成结论性的一致，缺少乾纲独断的业务专家。同时外部甲方也不满意。
我们那时候居然还相信B的方法"论"，忽视了根本性的业务&&产品差别，在那强烈尝试套过去。
执行下来的结果自然是，我们整理不出来调研结果，每天又累又焦虑，根源问题就是上面提到的循环自我论证。超脱不出去，不知道问什么，也不知道问了后对于项目的进步推进作用在哪。
当时B还是挺好的，作为PMO的职责一部分，她在尽力帮我们执行线下调研，也参与进来我们的调研内容中了，我们当时也感觉挺不好意思的，B和她的调研人员们帮助我们也发现了些新的业务盲点。
但是从复盘出发，上线后结果态马后炮，她们的当时心意是好的，但是作用是接近0，原因说了很多遍，根源上的业务对应调研方式错了。确实发现了几个业务盲点，这些盲点如果能及时点醒摇篮中的我们去正向推导我们要做好这个业务系统需要怎么做、甲方要的和我们以为甲方要的的差异之大，那是非常非常好的，可惜没有如果，这些盲点也只是汇报时提给领导看凑数的
根源上的差异导致了我们在这个路上不论如何努力，都不会导向系统的成功。
-
此时我们就已经初步明白了，我们做不到全国，几个省都够呛。但是还没有人意识到甲方之无赖和业务的根本性复杂度差异，没有及时升级事态
- 有一个点是：W开始去跟P还有YY聊我们是做全国还是几省，但总是没有结论，因为方式就错了，私下聊管什么用。和他的说话方式一个毛病，边界不分正式不了。
-
很生动的一次假努力只会导向失败的案例
STEP4：汇报，恩！情！
已经够乱了，突然调研中途，那个二级，要A|B两家公司都对调研情况进行汇报，哈哈哈哈汇报，噫我中了。
我现在复盘的脑子里已经开始播放将军的小曲了：将军：米饭是用米做的，泡菜要可以吃！
🖐️ 🖐️ 🖐️ 🖐️ 🖐️ 🖐️
\😭/ \😭/ \😭/
然后自然是集体通宵给他做PPT，从我们本来就残破不堪的调研结果里缝缝补补+编给他凑PPT。
此时已经有人发声了"这么调研不行，什么都写不出来"，但是身在局中，合着做个项目甲方对我们用疲敌战术呢，不给我们思考的时间，身心俱疲，在错误的路上一路狂奔。
B这时还釜底抽薪，要统一PPT格式，开始初见端倪滥用PMO权力，要A|B公司"协同"拟定PPT目录，然后统一格式，她还要审~
W此时是决定把事情上到我们自己的总监和北京总监捅上去了，之前的状态北京总监装死不管他事，W也只是一直要人力没有发现也就没报这种风险
first从复盘的角度，这时还有救，如果我方几个部门的领导干点实事，乾纲独断请命CEO，至少叫停汇报，再真的参与进来帮我们复复盘，不然你领导价值何在？
但制度呵责任呵，他们的取舍利益是要爱惜自己的，只是这份爱惜自己总是藏在爱惜部门话术的后面，是不能烧到CEO不能把自己搭进去，几个总监讨论半天最后的结论总是，我们要改变但先按兵不动继续汇报
second从复盘的角度，我们就该上报要求分配专业汇报人员了，比如销售。这个项目涉及到的一个销售上去的总监，以前是东莞洗脚喝酒那套的，和北京喝酒总监关系可好......销售总监当时提出了一些点，我记不清了，但可以确定的是，提出的都是PPT怎么写，领导想看什么，而不是业务怎么做，如果派专人来写PPT就好了，就这还勾心斗角，你一个销售，自己不写，光在那指点来指点去我们写PPT？这公司烂到根了
可以说汇报的事情，我们很不专业，所以立刻就提了需要专人执行汇报工作，但到3月份，也没派人来做汇报，后面就是研发了。复盘是复盘了，但顽疾已深
STEP5：插叙：走马灯.gif
-
piece1：刚到北京时，B和YY就在和W、ZHAO就在拟什么总体计划。但是八字没一撇，就算不谈业务复杂度那也连调研没做，系统设计架构也没出，他们就要总体计划，是不是疯了
当时：我们只是在盲从，盲从的锅我觉得一半在W，他给我们所有人都植入了B是专业的这个思想烙印。要不就我这攻击性都等不到调研后期，早就开怼了。
复盘：你B要这个总体计划的合理性在哪里？居心何在，为什么什么都没调查就要计划？我们最多配合到调研计划，就算是调研计划我也不想给，因为我们的计划应该为实地参与调研。我们不接受现在的做法。
但是：非技术领导本质上都是努力维系自己地位的空壳，他们那可是很需要安全感的，所以这个计划，我们还是要给的，只不过给计划的方针该是"哄小孩"，给她点信心，然后给自己留好余地（官方途径留痕），随时变更。可笑的是W总是会提不能吵架，说这种留痕就是吵架了，要保持好关系。那只会死守一个好关系原则，不知道能带来什么呢？后面HB老油条一看情况不对，不过一周就开始明确吵架了。
-
piece2：人在无语时会笑，YY这个小姑娘甲方项目经理现在就要出硬件资源规划、系统架构
当时：依旧在盲从
复盘：很清晰了，路径不对，很可能有B根据他们那种产品的路径依赖引导了YY，B她们可以复制改改就行。并且我们真的是问题很大没人仔细看过这份问题很大的标书，对于B她们承建的部分，按照标书做全国，是可以出资源评估系统架构了。但我们真不能，业务差异太大、数据量不确定、是否同构不一定，能不能做出一套服务全国都不一定。可当时摇篮中的大家都没人当回事，让做就做，我们也在拿以前的产品去套......
-
piece3: 团结紧张严肃活泼的甲方
团结活泼是甲方自己的，紧张严肃属于我们。甲方信安部门的三级我们称之为P。这个项目各个阶段都会有好几个甲方领导没事来看看，来中途指导，指导瘾犯了。如上文说过：我们应当提前定性甲方各人员画像，该当空气的当空气，该认真听的认真听。
调研阶段，P就喜欢指点指点方向，从W的视角看那是好人呀（棒读），但是从复盘的视角看，这种行为和看下棋时指指点点的围观大爷完全一致，并没有给出建设性的意见，只是在说话不腰疼装高人。 更恼火的是YY是P的小迷妹，它们国企内部真是团结活泼呀~YY作为项目经理没有独立思想，无语凝噎。
甲方当然也有好人，他们系统建设室的LEI，就真的会根据调研的一些情况，来给出他知晓自己内部什么尿性为基础给出的建设意见。从复盘来看，LEI的意见是正确的很懂的，我们由一些现状来推导出的建设思路过于理想化，忽略了执行在他们内部就是不可能行得通的，京管不动地方、地方管不动基层。
-
piece4：错误的个人责任认知
这个项目是P的部门主导的，YY作为项目经理，但她们如儿戏一般的做事方式，好像这项目做成什么样都和她们没关系。
他们比起是在和我们倾力协作，根本就是在享受当领导的感觉，而B则是把他们轻轻捧起的当作领导侍奉，甲方和二甲方通力协作，要求、意见一堆，时刻指导意见，帮助却是没有的。
他们好像真的以为这样子胡闹指点江山，飘在天上不下海，厂商就会帮他们把项目做好。一副高深莫测的样子，其实他们也不知道到底想要什么，就和大爷看下棋一样，这一步那一步指点下。
复盘：如果当时意识到权责问题，就可以明确的要求他们提供更多支持，或者否定我们可以，你得进行决策。用责任逼他们做出选择和帮助。比如你得找个业务专家给我们宣讲培训，你得提前决定调研哪些省，要不你就少干涉，我们自己做自己担，否则延误了呵呵呵。（无视掉W那种圆滑，对自己人没好处）
-
piece5：来到北京参与我们调研的地市老师放不开
总不能什么都说吧，总部的人在这呢，太多阴暗的小九九大家都知道，但就算是真的你也不能说！
连续组织了2批线下调研，第二批开始我们已经知道了要收集业务流程资料
第三阶段为成果汇报（正式）
STEP1：脑袋尖尖的
因为调研的根源性失败，与我们并不是汇报专业人员，我们通宵达旦也做不出有信息量的美观的PPT。
前面我们提过一嘴，B还要审，她定了格式还要审我们的格式，用她们的业务调研方式来强行套我们，PPT里每个部分填充的内容是灾难性的。
没人愿意或者能去进行汇报，实在没什么可讲的内容。
从汇报过程来看，从二级的言论来看，我们是在这里开始确定这个二级不懂业务的，她张口闭口都是财务相关的内容，只关心一个财务怎么算钱核账，忽视前置的各省市业务实际操作差异。
汇报的内容，B要求一定要画业务流程，她后面也会要求业务流程，这里我们是不理解的，因为我们的思维还是建报酬能力中台。
复盘发现，B其实一直都知道甲方要的是一个业务统管系统（报酬的输出只是一部分），而不是单纯的报酬能力系统。 我们也和B谈过我们的想法要建能力，但是谈的方式是W的聊天，对于调研没有产生影响，没有上升到甲方领导去定方向。
这个汇报后，所有人都知道了，建的是业务统管系统。
通过观察这个二级对于专业外的局限性，我们也要学到，在与其他或研发或运维测试人员沟通时，不能有先入为主的观念代入自己的领域中，最优先进行的信息拉平，互相补全，保证双方对于事情有一致的、全方位认知是很重要的。
STEP2：不太满意说是
"你们这调研结果不太行啊，我觉得得更细致些"
嗯嗯嗯说得对，我们也觉得。
复盘的角度来说，虽然调研的根源性错误导致了，方向错误与极其低效产出。但毕竟浪费了2周时间调研，东发散一下西发散一下，对于业务至少有了大致的了解。
可是这种程度的资料收集了解，对于我们实际要去做这个系统，却并没有帮助。之前对于系统的想法是什么样的，现在依旧是什么样的。我们知道了一些细节处的个性化差异点，但是却并没有一个体系去标准化的收集落实各省的差异点究竟如何，无法程序化的语言去落成文档参考，无法贯穿设计一个系统。
从这个角度出发，我们正确的做法首先1是上山下乡调研说过了，2是我们在调研过程中，应该以何种形式来承载产出物呢？从零开始的调研是无法标准化产出的，那个阶段应该产出一个业务系统的流程框框雏形，以此种形式，配合甲方对于业务流程有足够掌控的人，我们派出技术/产品专业的人员填充这个雏形，再合并分析。
剧透一下是：甲方派不出这个人，每个省都差异极大；我们实质上承担了帮他们梳理业务流程的职责，然后才是建设系统。
- 【谁是我们的敌人、谁是我们的朋友】/央地矛盾
进行了前面的调研，我们才知道
谁是我们的敌人：首先B是，她拿的那份工资天然对立我们。所谓职业经理人不对公司发展负责如是说。
其次各地市其实都是隐藏的敌人，总部收权各地市产生的央地矛盾。每个地市都有在现行制度下的小操作，总部的系统是要杀了他们，他们会在调研时隐藏一些关键信息，等到后面评估标准业务流程时又这个省说这不对，那个省说我这有差异。
谁是我们的朋友：概括的话是总部，具体的话YY、二级、P都是争取对象，他们与我们利益一致，只是躺在庙堂上久了，不知道什么才是真努力，尤其YY会做很多无意义的假努力感动自己。让他们意识到不决策且既要又要还要是做不到的，必须让他们意识到做不好这个项目的第一责任人是谁，以提供对我们足够的支持和放权。
从复盘的角度，我们这时候不应该继续按照B的流程去做调研了，首要的事情是先做完刚才说的由甲方真正懂的人和我们的产品技术人员整理出一套我们对于报酬管理的基础方案，和总部对话得到授权后，要求地市进行适配，否则需求膨胀没有尽头。但也是从复盘我们知道，甲方总部想把地市的权力收紧，但又没有决策没有决心去推行他们希望的系统，没有对于地市的管控力，同时也给不出全国业务专家这个人 ，只是想着尽量去适应地市的情况，让万能的厂商做一份适配所有地市的系统（后面标准化业务流程处会体现，流程不能变动只能去支持）。同时我方公司也并不具备这种报酬管理的基础方案的给出能力，因为这是"域外"，我们缺少经验与足够说服总部的案例。
总结下调研乃至全阶段一直存在的问题
W的说话方式并不对项目足够负责，他是个万金油。很多时候很难去坚定的认为他和我们是一条裤子的。
忽略的应当做的识别甲方人员素质
B只对自己负责
噩梦的钟摆-标准业务流程（业务塑形）
【202402-202403】
无力感
我只是一个super charge 研发头头，没有他们那样的力量.
- 我们一直不清楚系统要建成什么样去承载业务
主体调研已经结束了，业务流程也在调研中去收集了，但是我们依旧没有人知道，我们的系统该如何建设。
我们好像知道了业务流程，但却没有"实"的感觉，无法去对应上一个个需求与功能点。
当时我们的想法只是赶紧过这一关，迎接下一关，我们在B的引导下，并没有去按照自己的想法思考过怎么建设我方承建的部分是合理的。人员已经身心俱疲，如果遇到类似情况应当及时进行人员置换换个脑子了，当时的我们做不出思考判断。
原因归根结底还是因为多方对于这个系统的期望是不一样的，从复盘的角度，B的引导是按照客户的期许（一个统管业务系统）去进行的；而我们却在想如何把老一套算薪平台搬过来适配及业务对应的技术设计细节，自然会产生无力感。
此所谓信息的公平平齐非常重要，B知道、客户知道、我们也觉得自己知道，但每个人"知道"的内容是不一样的。B觉得我们怎么那么笨，我们觉得B你为什么要这么做有什么用。
- LEI的想法
在这个标准业务流程前的调研阶段，LEI和W互相聊过几次，也是关于无力感的，W也不知道我们到底要怎么建设成功这个系统。
在调研中间，我们知道了各省业务差距在流程、实操、业务类型细节方方面面，感觉到可能要给每个省做适配个性的代价过大了，然后LEI没事会来旁听调研，他们就聊了起来。
LEI也是系统建设方面的人，所以他的思想和我们比较接近，他给出的方法是只保大流程，具体的细节差异，由操作人员自己去做并记好自己省的映射关系，我们只去提供一个大的模板。
LEI是一个很好的参考，他比我们强很多在于他作为甲方的人知道甲方的"惯性"：所以他可以笃定的说抽象的配置化系统推广不动，要让基层用起来就越简单越好，让人去做一些映射。他照出来了我们的盲区，我们之前的算酬系统都是给甲方的IT人员去用的，但是这次的甲方好像......没这种能力。
得益于LEI的点破，我们清楚了一半这个系统的最终态会是什么样的，我们的逐步清醒不是一蹴而就的，是这个人、那个事点拨一下，慢慢清醒的。
这又引出一个话题，如果下一次承建域外的系统，我们要怎么高效的在最开始摸清系统的建设愿景及甲方的真正诉求呢？ 现在来看LEI承担了帮我们学会"产品"的能力，所以一个合格的在对应领域有足够经验的产品经理是最优先必须的；其次则是比起做事，应先与这个系统的相关方从领导到到基层领导再到使用者，摸清系统的定位、承载的能力，还有他们每个人部门的小九九，抛开既有经验，从0去摸象这个系统该长什么样。之后才可以去规划后续的动作，而不是这一次从开始就错误的-听从B的指挥。
唉，也就是既要听高级领导把方向，也要下到基层去走一遍。
- 甲方不作为+作为不动鸭
不作为：
中间穿插了不少汇报，W都会去讲什么什么我们系统建设难啊，难在哪，我们有多少困难点，需要甲方爸爸帮助。 这个策略是各位总监帮着拟定的，要让客户知道我们的难，知道这个系统的难度，管理好预期。
从结果上说，每次甲方都会知道我们难，然后进行一番虚头巴脑指示后，又让我们去推进，还真是那句话：提供除帮助以外的一切帮助。很多时候我们就是希望甲方决策一下二选一，代价都列出来了，但甲方就是不决策，而是既要好的方案又要保证排期不变。
有时那个一级二级知道了我们难在哪，会让P->YY去找难的相关方对接牵头提供帮助，但是执行下来，那两个废物就变成了给我们拉会拉群，就看看不管了。
甲方作不了为也有我们自己的错误，我们给他们列的难点，都是我们技术建设角度的，还是没拉齐目标和系统愿景，他们也就get不到难在哪。
后面的章节还会提到一些他们的不作为案例
作为不动鸭：不作为说的是YY以上的领导 exclude LEI
作为不动说的就是YY她了
YY的人物画像，在做完了这个项目后，我可以给一个准确的描述了：积极、努力（不管真假）、专业头脑缺失、令必达（领导命）、没有轻重缓急、缺少责任意识、不懂权责而滥用权力、不会自保。如果作为她的领导，那她是一个随时可以被放弃的忠心耿耿的人，但最好给他配个专业办事的副手。（不过看了一些新闻后，可以说如果你在体制内，那学YY干事是非常正确的，看看赋红码那位......）
在调研过程中，举个例子，本来我们是要梳理业务流程出文档的，但她所在的会场聊到了一些账务报账的信息，不同地市就各自的不同点就互相聊了起来，她就兴奋了，拉着各地市帮她整理各地市的报账流程，为什么这里我用"帮"字呢，是因为她并不专业，梳理起来与其说是产出文档，不如说是以她为中心所有人教她这部分业务，而她正乐在其中。
当时连做不做报账部分的对接都没定下来，YY一直拿标书说事，但是她的领导和领导的领导都是没有给准话的，一直在模糊化决策。所以我们的调研的目的是串通各省业务流程，再让她们领导给决策做哪些圈定边界，哪些可以砍哪些要定制，而不是这个时候就为报账部分的建设做准备......她的行为就和新开发会有一段时间去揪一行行源码一样。
她没有坏心思是在为项目努力作为的，可这就是作为不动鸭
- 系统地基：数据来源不稳--喝酒总监的大智慧
我们调研期间向甲方反馈的难点，有一个是数据源的难，数据源可以说是系统的基础建筑了。
数据源难在总部对于1、地方没有管控，各地都自建数据源平台（实操上基层会导入导出然后线下签字等流程）；2、政治任务上，要完成对于地方的报酬纳管，赋能审计，所以这一点要求系统必须走无人为干预的对接方式。
但是客户是鸵鸟，他们不接受我们的策略。我们的策略是（主打一个缓兵之计）几步走，把简单的一期实现，难的对接放到二期三期。
我们将客观存在的时间不足、需求不明确的问题提出来了，也表示了这个建设没有历史参考，时间不可控制不可预估，希望甲方可以理解并决策计划。不出意外的是甲方的结论：我全都要，你们要去做。
他们真的就是这个意思，很虚的要求你去做~ 你提出的方案他们挑刺，说时间说其他（比如满足不了审计，有风险，地市可能不配合，总体计划可能要延期，甚至于"不满足包书"），但他们却不输出自己要什么，全靠我们去一个个试错。
从复盘的角度看，甲方那些领导是很清楚自己公司对于地方的管控已经失能了，做不到要求地方全面配合，地方有无数种方式阳奉阴违，所以不可能给我们决策。但也不想担"点头决定不做什么"的责任，所以他们的选择只有让我们去"继续调查"给他汇报关于对接各数据源的方案。
在我们一个个建设方案试错的过程中，喝酒总监他涉及到数据源，给我们所有人印象深刻：他就说"导，让他们导"、"你别想那些，就让他们导"。我们当时是认为这个行不通，是无视了这个"非专业人员"的，因为当时都当调节气氛来看他的"导"的，客户侧不可能同意导入，客户总是在说要纳管审计收容，这一允许导数据就不可信了。每次汇报也是一说不对接数据源客户就炸毛。
但是从后期结果态来复盘看，喝酒总监他是真的懂，他以前做这个总部客户的项目，早知道这些人什么尿性了。
你还真别说，如果我们就按"导"，去和客户说我们只能这么做，其他方向方案出工不出力，还真可能心也不累了，到最后这些假大空的甲方领导，为了自己的乌纱帽开始急了就会主动从语言的艺术上什么都可以妥协，圆满完成一期建设（导！），后面再薅二三期建设慢慢做对接。
- 随时一波未平一波又起
这说一嘴那说一嘴真实如此，我写的也糟心。
B 在执行她的项目推进计划时不看实际、不看我们的情况，而是完全按照她们公司的产品套路去推进，且她会零过滤接受一切领导要求，所以现实场景真的是这打一枪要汇报、那打一炮要难点shoot（还根本shoot不掉）、突然再穿插一个新的从标书膨胀出的需求点要你去推进。
在中后期（功能+设计开始），我们之中经历过调研后面那段时期的人已经开始认为这女的PMO经理就这样了价值寄生虫 ，她休假时B公司的男领导顶班好沟通非常多，B公司的男领导虽然也会有关于二期利益的小心思，但还是和我们步调一致要做好一期的，目的一致哄好客户以推进落地为共同利益，这是和B她明显的差异。
我们真的需要说不，但是信任从最开始的错误丧失了已经......
- 复盘前面说的够多了，后面少些，总体是专业不对口+地基不好+客户不当人+我们不够硬，后面一直在填坑
STEP1：梳理标准业务流程
调研分2批，第一批纯浪费了，第二批是带着梳理流程的目的去的。
虽说如此，但是真的要我们合流整理一份标准业务流程出来，我们发现了合不起来，或是这个省其实串不起来，或是那个省和你负责的那个省不一样。我们发现了自己输出不了一份至少过内部关的标准业务流程。
合不起来原因在于：我们并非专业的产品人员，人员素质在对于产品、技术、业务的理解侧重点大不相同。虽然提纲已经尽可能去定了一份大流程框架，以调研时有个依照去问，但我们实际开始和地市老师进行沟通后，每个人对于沟通到什么地步，问出什么结果才算ok，各自的理解丝毫不同。且各个人的专业领域导致了会误判自己问的够了，但其实对于我们的目标"业务"流程来说，是不完备的。
另一方面是，1、提纲是不可信的，上面可能说过了；2、老师们更倾向于你问什么我答什么，老师们没有理由主动去把自己的底裤交给你教给你，所谓现实的角落不能明示。
也就是我们一群都不敢说自己是专家的人，在那里空耗整合，公说公有理。
那我问你，那我问你，你觉得DDD怎么样？DDD会要求你有通用语言、看图说话，还给用于描述业务的术语定义好了。 我是认为DDD的理论提出必然有和我们一样的场景孕育。
不管怎么说，事情都要继续做下去。调研结束后，一些临时从杭州借来的人已经回去了，他们留下了自己的产出/收集的资料。剩下的只有我们三人帮和那个北京本地的总监。对于这个标准业务流程，初版是我写的占七八成，W疲于应对各种膨胀需求，ZHAO帮不上什么忙 我当时仍然是技术思维占绝对主导，并没有意识到标准业务流程对于我们收集得到的差异情况，并不能用可配置、个性化来描述。 也许你可以说这么从技术上实现最完美完全可行，但是，客户并不想要，他们想要的是"标准"业务流程。
还是那个根本原因：我们那时依然以为是建能力支撑他们业务，想说服甲方，但没意识到大背景政治任务不可违背，甲方想的是统管业务系统。
在我写的过程中，我彻底笃定了B已经不是什么好人了，承认其在自己舒适圈的专业性，但是她并不懂也没有去变通，且只是因PMO的职责和我们貌合神离。
文档格式，和她们要保持一致，说是我们双方承建1个系统（事后看纯纯的扯虎皮）。但她对我们的要求和对B自己方的要求，是双标的，所谓草台班子呢就是这样，没有成文的可参看具备公允性的文档规则。
（1）我们写完后B她要审，她会说这我觉得不行，那也不太合适，但是她从来不给出指导改进的意见，作为PMO她这是渎职，实际上成为了二甲方这个层级，甲方可以扯大旗飘在天上那因为他是甲方，B她也配？
（2）一些格式上、业务描述上的要求（如泳道xy分别写什么，每个流程节点的该写什么的定义），B她们自己的文档也没有做到，却严格审查我们，她们是拿以前的同质项目的改了改就绿灯过了，所谓太监正如此，甲方好糊弄。（记忆模糊了大概这意思）。
STEP1.5：无尽的评审、宣讲，隐藏的外部系统大雷
B在那作妖，时间还是到了，该给甲方评了。
大概有5、6个大流程模块，每一个都举步维艰，艰难的原因在于~
- 1、上面提到过的，我们和甲方对于系统的理解不同：我们在那搞中台的思维写的标准业务流程，到处都是根据实际配置、个性化；而甲方想要的是统管业务系统
- 2、我们和甲方对于决策责任的划分理解不同：在调研过程中，虽然已经隐约有感觉到甲方"不靠谱"了，但是我们没能做到进一步思考背后的含义：：有些业务场景我们调研得知了差异，但我们没有去跟地市老师进行更细致的明确，而是"默认"了对于主干业务流程没有影响的可以吞掉然后继续推进调研，后面甲方做决定要不要还是允不允许改不改就好了。血的教训是，不要有任何"后面做"的想法，也不要自己做任何非正式的决策，一定要摆上台面留痕 ，调研到什么细致程度不是你说的算的，由需求甲方说的算。
- 这也就导致了，到评审时，我们说甲方这是你该定的，甲方反说这是我们该去调查清楚的。双方都觉得不该是自己做决定。公允的说，这是甲方自己的业务，不该是我们去决策的，但是......标书标书还是tmd标书，范围没写清楚是模糊的，甲方真吵架就拿着标书说这是标书范围里的。
好好好，那我们达成一致认栽了，我们去梳理去决定，你审批，开心了吧，但是仍旧不能皆大欢喜快速推进，这次的原因在于：
- 1、甲方是既要又要还要的，优柔寡断都是夸他们了，对于我们的结论，YY、二级、P、B总是能找一个他们哪个人觉得"不太合适"的地方，要求继续《明确》
- 2、依旧是对于业务的重点理解没有对齐：我们认栽了去梳理流程了，但由于我们终究是技术专业的人，梳理的流程还是抽象的。举例子是我们去掉了那些一开始写的是"自行配置、个性化"的地方，改为了我们根据调研情况认为合理的处理办法，所谓"标准业务"嘛。但是我们仍然没有意识到应该去关注纯粹的业务行政维度的管理："省市县各级的参与度"、"审批流程各级处理人设置的合规性"、"业务数据在省市县间流转时到底不同层级该承担什么职责，该不该，允不允许"、"不同省的外包服务商和甲方省市公司间的关系会产生的业务操作的法律风险（如灵活用工的灵活、事实用工的产生）"、"各地市如何处理审计"、"各省市有哪些极端业务场景又是怎么处理的"等----人的思维转变是很困难的。
- 我记得不清楚了，但是复盘结论是，我们的业务还是太嫩了，思维框架在技术侧太定势了。
- 甲方的关注点是对的，对于建设《统管业务系统》来说标准业务流程的梳理是非常必要的，没有这个标准化的动作，即使建设了地市也可以以无法支撑为由，拒绝使用被你统管的系统。我们和总部甲方的争执则是应当由谁（哪方）来做（或者已完成）这个梳理
- 3、评审的过程中总是会发生对于这个那个业务细节的辩经，B是最大阻力，她拿着PMO的酬劳与我们的对立点展露无遗。这种辩经你不能说它是完全无意义的，因为真理是越辩越明的，但是有没有可能我们在总部庙堂之高可以按下不表，计入待办，在宣讲时让省进行明确？
我们应当学会换位思考，从对方的角度
B的角度：她是PMO拿这份钱，要替甲方保证项目的安全推进，那她发现了我们有一个个业务疑点，她就来辩经，不允许继续下一步计划，那是合理的......个屁。如果没有B那面替他班的男领导做对比的话，我还真信了，那个替班男领导才是真的为项目考虑，B就是坏，只为自己的光鲜亮丽考虑
甲方的角度： 甲方的阻止推进倒是确实有原因的，这是总部，他们不该允许一份有明显不明确的漏洞的文档作为宣讲材料，从YY处我们应该意识到的，至少这个体制内结果导向行不通，反而是过程导向，每一步都不允许有损权威的漏洞。如果是那个替班男领导，和我们一起说服甲方接受也是可以的，可惜是精致的B，B常见话术："好吧，我们和xx总汇报的时候讨论一下，但是我觉得xxxxx"，所谓没有担当
每个大流程模块不知道磨了多久，终于是在总部层面审过了，该对省市宣讲了。比较幽默的是，连找哪几个省、选哪几个市来宣讲，甲方也不决策......无语
无语在于，当事人都能感觉到甲方对于某个省的倾向性，而我们也对于建设尽量简单些的诉求下有对某几个省的倾向性。结果就这么假谦虚上了，罪魁祸首在于YY、P、B三个蛇鼠一窝，甚至于二级也是欺上瞒下的报喜不报忧特性。他们的能力Hold不住这个项目，但又不能和领导坦白，最后可不是装高人指点江山嘛~
最后还是周例会猜中了甲方希望的，然后才顺利通过。
这里W做的好的地方就要认真学习：从调研起，他就是最先识别到这些省的差异对于落地的巨大阻碍的，而据分析他能意识到的原因是会落到笔面上/直接说出来，人在脑子里想和输出出来聊确实对于理解分析有差异。 可惜他的做事说话方式导致这个识别的风险并没有掀起惊天浪，圆滑地和所有人做朋友，那他和所有人切实聊都能聊出东西，可是这都是私人意见，不会产出决策性的结论，连邮件都没有正式落下来。
就像是我和你聊，你知道了有XX一回事，然后就没了，我还和你说XX这个事怎么怎么啊，但我不定事，上会我还是要你来决策，你还要给我证据。
某种意义上他的聊也算是对于我们的总监的欺上瞒下了（攻击性不足风险上报不足事态紧急程度被低估）？好像也是，当时上报只是在说超出标书范围了，就没更多了。
决定了宣讲的省后，宣讲执行后，不出意外的，省分意见是尖锐的。尖锐集中在
- 1、不想把数据交给你做精确计算：
在调研期间，我们想要看老师们真的拿数据去算，会感觉总有一层窗户纸，其原因正在于数据是各省的命，在线上调研和第一批线下调研，我们都是理论性的飘在天上的摸象调研，老师们回答时都会说"有"、"有规则"、"从哪哪拿的数据"、"按xxx顺序给过去算出来审批"、"excel有公式的，不是手填"、"有系统记量，然后算的"、"地市审区县的二次分配"、"有依据的"
但是此时宣讲，各省却又冒出来了闻所未闻的场景："基层组长给的量"、"我们只核时每月的总包"、"有些调整金额的要申请"、"每月地市总额有数的，是在盘子里再给区县分"
数据+怎么基于这个数据给发的钱，是每个地市的命根子，省都不太好问清了每个市的小九九呢......
在上面总部辩经这个宣讲内容时，此关于地市区县和计算用的数据还有报酬结果的争论是一个大头。从复盘的角度看，辩经缺少意义，总部想要的结果我们改变不了。
对比宣讲到的地市的实操和总部想要的结果，当然是总部理论上的结果更具备合规合理性，但是地市客观存在的实操情况+怎么让地市接受你的系统，这个没人在想且想了也是个死结，从复盘来看，天然的利益冲突，如果不准备打扫干净屋子再请客，那结果只会是妥协做出来个四不像。
你想打扫干净屋子，那地市也可以轻松用民生大旗反对使用你的系统，毕竟关乎到实际发钱，正所谓总不能什么都查吧，万一查出来什么呢？百万漕工衣食所系。
这是我又想起了喝酒总监："导！"，真是大智慧，他预言了最终的结果：空有流程，数据根本管不住，导！
- 2、抵触数据不出系统、全程线上化留痕：
和1类似了，一旦原先还能正常运行的数据进了你的系统，留痕60个月随时审计，那史密斯专员还怎么拿、地市各级人员还怎么努力工作进步。
变革点在于，原先数据也留痕，但控制权在省，总部查不出东西，极端点可以火龙烧仓。而现在这个系统可是总部建的呢喵~
每一个环节可能有说不清的灰色地带，而数据不出系统这可就要命了。
当然不会明说这些，但就是会不断抛出一个个小细节差异，说你这个系统统一不了，默契的各省配合游击。
- 3、报账流程的标准化确实存在的现实阻力：
这一点是最干净的，是纯粹的业务现实运行确实存在必要的差异
主要问题是一些垫资，延迟N结，外包与员工与省甲方的合同关系，次要是他们使用集团系统报账相关流程的执行颗粒度。还算可以谈的。
但是，这个系统充满了但是：可以谈，即使我们谈清了一个省的细节，那么问题接踵而至：哪个地市的最合理，最合理的流程又是什么？我们系统边界在哪，要做到什么地步，是否重复建设了报账相关能力？报账等系统可不可以适配些接口
集团内部繁文缛节又推动不了报账系统等系统来适配。他们也决策不动，庙堂之高，胃口之大，对上级负责缺忽视建设的客观难度，导致了讨论空中楼阁，最后还是最大程度支持地市现状，即"导！"。
当我们在总部指点江山时，先探索下总部能否做到令行禁止管地市吧~
- 总结、可以说实时是从这时开始确定了央地严重的对立关系、调研过程中省的藏私、未来的上线推行将遇到的阻力、总部的决心程度的关键性。
算是撕破脸了，不乐意配合你，但还要听总部的话。
这段时间成为了文字工作者，觉醒了奇怪的天赋。
STEP2：到底要对接哪些外部系统？
大抵是从调研第二批开始，YY在调研时突然间提出了"你们要去聊报账系统对接"。我们第一反应是"啊？我们不是算酬系统吗"
然后YY就掏出了标书......
后面断断续续的有反馈过（W聊天非正式），我们要对哪些外部系统、此系统的定位，不过由于时间的错误，在调研时还没有业务流程的雏形，所以我们和甲方都不知道正确的做法没什么结论。
现在标准业务流程出来了，矛盾就摆上台面了
从我们的视角，你甲方那么不讲理，延个期要你命似的，那我们肯定是尽量最小化完成系统，保你的时间。老师们一直会藏一些信息，我们对于报账实操的理解终究是理论性的，这就说对接太不可控了，拖延开发总计划是坑自己。
我们的口径自然是：我们算出来结果，之后导出去报账依旧由地市去线下做。
结果可想而知，甲方那可是要数据不出系统，要审计的啊，那可是他们建系统的目的呀，立刻炸毛（二级和B和跟风的YY和装高手的P）。
但你倒是冷静的想下啊甲方哥哥，我导出去的那份留档不就好了吗，做个对账可不可以（放二期三期）。明明是政治任务，这时却要考虑基层人员操作多个系统麻烦，实际上只要甲方够坚决，基层只有执行的份，太有人文关怀了这时候。
甲方结果性的口径是：要在我们的系统里完成报账，这里复盘的视角应该是B的妖风，如果没有B，我们坚持说做不到/要加钱/要延期，那甲方也只能选一个，我们给的方案也不是说不可执行的，而是满足了甲方最低要求的。但B就在那装好人替主分忧......
分割
除了报账相关的外部系统外，还有个提供OCR识别能力的功能要求，这个在我们的标准流程里对应的是最后的一个"xx回单审核"，标书里要求OCR智能审核，我tmd打死标书那个人
又是儿戏一般的推进，YY就拉了个群让我们去和OCR的人对接，甩手了。然后W就去试了下，发现他们这个OCR能力满足不了需求，G了。和甲方说我们不行别对接了，自建吧，甲方又冒出来集团xx三问，不能重复建设，那你说咋办嘛？又是既要又要还要。
这个OCR拉扯了很久几个月，最后眼看自己可能要担责，甲方妥协了，结论是满不满足好不好用不重要，你对接了可以用很重要，我学会了。わかりました、ありがとうございます。
小细节是，和他们x企对接，对方那人的水平哦，好用的文档没有，事讲不清，做事也不积极，感觉就是麻木撞钟久了。
以上关于甲方和B对于一个标书里埋的坑点扯皮的无奈描写，具体执行时，YY想一出是一出（会突然在拟标准业务流程时，让你去同步调查外部系统可不可以xxx，鉴定为领导病翻了），就要你去调研外部系统......而W那时候也完全和他们一致，不辩解，现在W也不会承认自己被影响了，反会PUA什么那时候没别的办法（好像确实）。
STEP3：全国还是几省&&穿插而至的一级要听汇报
全国还是几省的雷发生于标准化业务流程前汇报后，大概也是那个时间一级要的汇报，我写的都心累，记不清了
- 一级在上面的重要指示为：
一定要全国上线
允许分阶段
你们要去对接数据源
计算功能必须要有
要好好互相配合
- 一级很急+为什么急
来巡视组了，做不好要逐级问责，这下子后面二级变得非常关切，YY和P也不敢放P了，只有B更恶心了。
- 正式暴雷：全国还是几省
标书是全国，这个甲方是改不了了，唉标书
我们能争取的只有双方妥协，"第一批"的时间依旧按照标书，逐步全国接入
- 人造地雷：哪几个省呢？具体てき お願いします
- 你个二级不决策谁决策，请领导明示，总不能上到一级那吧
嗯......就是那种，我们好像可以决定，但若有若无的暗示，不行不行，还缺那个省
经过了一系列总部不决策，所以收集各省意见+主动沟通是否愿意，终于是把二级心里想的那个省（也是补充调研她说的那个省）加上其他4省列为了第一批对象。
推广完第一批就开始第二批，是这么想的
- 项目经理：没钱了
没钱了，这么做根本兜不住成本
尝试和客户说，客户开始CPU：你要想二期，我们会在二期给你们补回来的.无纸面gif
雷也爆完了，终于决策了做哪些省了
总体计划调整为，第几批第几批上哪些省，前途一片光明鸭，都是一级指导有方！
STEP4：补充调研，之后就是功能阶段了
标准业务流程好不容易通过了，做哪些省也定了，为了支撑系统的落地，需要补充调研上线第一批的省的细节。
插叙细节👇
- 1、YY还有B要求好好审视总体计划
并不是此时才出现的，一直都有这个现象，之前一级插进来要听汇报，也出现了总体计划扯皮，这个扯皮很频繁。
总体计划的调整会领导不开心。集团定了标书写了0630要上线死线。所以调整总体计划补充调研，那会不会来得及？答案当然是可能来不及，总体计划受影响，但是这就是X企病不讲理的地方，一切时间倒排，抛开现实不谈，只有领导定的时间不能变。这个项目从此开始会频繁且每次涉及调整个时间都很费劲，二级一级都会扣时间。
这就是无意义的扯皮，增加了新的内容，时间不可能不受影响，B却要你给出一个以结束时间不能变的基础的合理的总体计划，那只能是压缩后面的排期。纯纯的咬文嚼字面子工程......B只对自己的PMO工资负责的一个体现。做的事有没有推进意义不重要，做职责范围内的事本身便是意义。
说到底总体计划这个东西，之前YY和B硬要就是错误的，该正面对峙，他们说不出个所以然来。给计划纯粹为了满足领导指挥全局的领导瘾，领导看了计划也不会为此负责。从复盘的角度，此时我们必须强硬拒绝按B说的来调整计划，一味的满足甲方无理的要求，让B狐假虎威，最后坑的只是我们自己。打开天窗说亮话
B经常说"计划之前领导都看过了"
真恶心，为了自己的专业性，置整体推进于不顾
但也可以说复盘这也是死棋：我们经过失败的调研与标准业务流程产出，至此已经没有足够的"信任"去让甲方放权我们自由做了，一步错步步错
我们年轻一代欠缺的，我们会天然的抵触："做好无意义的事，保证自己不会被问责"。后面我们换新项目经理后便相对隔离了，哄客户开心的和真干事落地的分开推进。
- 2、那么下到省里的计划捏~🤭
插播：汇报后HB加入团队，老油条项目经理ZL部门的。
这里没什么可说的，又是计划、日程、人员配置。我比较震惊的是，P、YY及他们的助理之类的，居然依旧没有危机感，觉得是去省里玩的，这不是他们负责的项目建设吗......
下到省里好像是要实地考察了，结果......B又是要你提前拟提纲，搞她那套。
万幸是经过前面的折磨，我们从不断破碎零散的信息中，整理出了业务流程了，这时候至少提纲是可以细化到每个功能关心的细节了。
- 3、实地调研结果
收集上来了每一步的资料，操作流程也细致的记了下来，对于功能设计的细化/丰富有帮助。
但是仍然没有做到复盘角度理想中的"参与到实际工作中"这一状态，从项目上线推广期产生的问题来看，这次实地调研仍然是老套路的提纲质询。
STEPX：我们一直在被推着走，怎么办？
自我问题要认得清清楚楚：我们就是菜，专业不对口，没有自己的三板斧，这个客观条件改不动，赶紧换人来掌舵。同样的外部压力换个老油条来就能做好屏蔽外部杂音，让内部可以专注于有效推进。
外面的问题也要顶回去：哥们，遇到这种情况，第一时间往越高捅越好，就B、P、YY这种甲方、二甲方，给他们定性稳不稳另说，但求定性定的准狠，错杀也不放过，直接摇内部吵架高手来替班。你像W这样能说出来"你这样是给别人递刀子"的半瓶子水敌我不明这谁受得了，再来一次他做我方领导我是不干了886.
STEPY：复盘B，她的存在意义/定义在于？
用激进的言语概括的话，B是一个受过良好教育的、伪装在专业面孔下的old仙女。在对她的套路吃够了，祛魅之后，就会发现本质依旧是寄生虫寄生于高级领导，缺少理性思维并非实干。
STEPZ：复盘B，她如果存在PMO方法三板斧定式？
第一式：领导什么意见？
第二式：你们按领导说的做
第三式：我要审审给领导看的东西
此为B行动的框架，其当然具备一定的专业性，没有专业性不可能做到引导调研->标准业务流程->后续的项目落地，但她是在机械的执行套路，是秘书身份并非一个统管整个合建项目的PMO。
混沌的低语-功能清单还是研发计划？还有宣讲？？
【202402-202403】
HB在加入后，分析完局势后，与我们所有人开会：
会议主旨概括可以是：聚人心、齐目标、建信任
可是这破项目事后回想写的都心累，当时已经人均离职边缘了
聚、齐、建说的没错
问他怎么聚人心，他没能给出好答复。
问他我们的目标是什么，他说是建设好这个系统。
问他如何建立信任，他说先从每周例会任务清空达成开始逐步建立信任。
你还真别说，这些话最初一听会觉得是废话，但真的想一下，我们发现了自己其实处于"一问就知道，一做全不对" 的状态。
HB在项目周期里，给我的启示是：要管好团队就不要忽略任何细节不要觉得任何事情是无意义的，去想去做一些乍一看没用的事情。
HB这次会议还根据观察，观察到我们人员是集中式复用的，人人心累还效率不高，所以将我们人员重新划分为多条线，规划汇报线、功能研发线、调研线。
这是一种很奇妙的感觉，他一说出来我的本能反应是，"早该这样/这不废话吗"，但是为什么我们这么多人都没注意到，也没想去改变一些？也许可以说他局外人刚进来上帝视角看得清，但我觉得没那么简单，"老油条"的身上有一种特质，中年人的积累沉淀，看轻一切的超然，不忙不乱。"你说做，那就做，我们应该怎么做，我们应该这样做"，平和稳定的推进处理一个个事，我们小年轻没有身临其境经验积累是做不到的。
STEP1：什么？你现在就要画原型
我们的进度是落后于B她们公司的，阻碍太多，B也没有多上心也没能力上心我们的复杂场景。
在我们梳理标准业务流程的时间里，B公司已经汇报完成开始原型设计、功能设计，准备功能宣讲各省了。
B是什么德行大家都知道了，当时，我们刚结束标准业务流程汇报，正要进行上面说的补充调研。她却要我们和她们同步也出功能设计。
B的心态上发生了变化，从此之后吵架颇多，大家撕破脸了，W不再参与客户关系，而是比B更老油条的HB。
从一个装着优雅推动项目的PMO，变成了眼看计划异变横生，焦虑的要求他人按照她的计划维护他的威严。过往的荣誉束缚了她，她无法接受自己其实一直是受二甲方身份庇佑，而没有真才实干建设一个全新项目的事实。
在周例会上，B就说进度怎么怎么巴拉巴拉，总体计划上巴拉巴拉风险，我们最好现在就巴拉巴拉。B好呀，好就好在占着个替甲方君父分忧的理字，无法拒绝。
在无法拒绝的前提下，我们步入了并行一部分人补充调研，一部分人在出功能设计的情况。
值得一提的是，几位对于接受B的并行作业要求的理解是不同的：
W替她人着想，B有她的道理，我们也确实应该尽量赶进度，所以W同意并行。
W 从成为领导后，其思考方式就变了，在刻意的管理，却没有方法论。和W说这么并发，功能设计的产出物没有可靠度，返工算谁的，谁愿意返工。W却说我们拒绝不了（这个我认可），W却说至少应该有一部分能用的、尽量出（不认可）。
我认定这是他说话方式"玩"的一种体现，正式和私人边界很模糊，但都导向利"他/她/它"，如果你看过雍正王朝，那么八贤王......。他没有什么可信的依据来推断我们并行的劳动产出不是无用功，只是"觉得"可以有一部分能用的，如果我们和他正式一些，那邮件抄出去，你模糊地要求出一份不可靠可能浪费人力的功能设计，不尊重研发兄弟们的劳动。
HB ，他一点不懂技术，他接受我们的结论：这个并行可能产出的不可靠。然后他的处理是会问我们哪些更可靠一些，以我们的评估为准，再要求我们把承诺的可靠的部分的功能设计做了。他则去对外交涉承担责任--我们只并行做自己认可的部分，对比W这就成熟了非常多。
虽然都是要求先去尽可能做一些，但一个是在"玩"，另一个是每个人做自己专业范围内的事，按部就班。
唉，真是做事中每个人的专业技能是基础，做事前先把人性给摸透才好用人
- 分线操作清明加班出文档
W是部门经理+客户要求不得缺席实地调研，调研现场也必须有一个业务理解足够的人。团队里次之对于业务理解功能理解兼具的就我了（W他功能也不太行，一方面专业技能思考的模式丢失了，另一方面写C++的在我们部门和兄弟部门里我见过的都是面向过程，有着只关心自己的面向过程编程设计的臭毛病，设计功能并不合理），故我和一位前端分工到功能设计，同时又是从杭州临时征调一批人出差F省调研。
我去做功能设计也算是矮个子里抓高个子了，我是研发专业不是需求/功能专业，只能算半个。可当时形势上没有第二个理解业务的人，我们即使抓一个产品经理来他也不理解业务。这是我们自己的问题，没能及时识别自己的专业不对口去摇产品经理早加入。并且从近年铺开的DDD思想来说，我们调研这么久了却没有形成领域文档，传达低效阻塞。不止一次会议上会突然有一个人就一个细节提出异议然后又是找资料又是打电话耗费所有人心力很久。复盘马后炮：我们这种杂七杂八的调研团队，最应该使用DDD设计了
配套的前端也是尽显我们公司这个部门的完蛋之路 ，此项目跌跌撞撞这么久了，我们没有及时摇产品经理是自己的问题，可这时候摇一个会画原型图的，居然也不给配。又是W的"玩"，他的玩让绝对的该不该、对不对被抹除了：他居然以杭州研发部门只有一个原型图会画的人，且这个人工时在别的项目借不到来作为理由，得出结论让北京前端现场学画原型，还说什么他W也可以学，ZHAO也可以学。真是分不清主次轻重缓急鸭。
试问：该不该给一个专业的原型图资源
试问：把资源倾斜给更重要紧急的项目对不对
试问：如果自己没有该不该去外部要
试问：模棱两可的让一个前端/其他人现学是对一个紧急项目的态度吗？是正确稳妥的处理方式吗？
画不好，最后内部定责，别人可以说，你为什么不和我们要，你也没说一定要啊，你一定要我一定给。
无语，W还会打滚说"那部门给你来管"，装模作样管理。
站在更高的视角看W、总监的关系就懂了：总监就是喜欢这样的W，总监不想要一个不断给他制造问题让他可能承担到责任或是把矛盾问题暴露出来的中层管理（部门经理），而W恰好又不太懂管理好控制，还是个交际花PUA大师，会自觉把问题吞掉，把矛盾用他的非正式私人关系"玩"给模糊掉。
- 做功能设计画原型的过程中呢？
1、痛苦地破除思维惯性
我们是研发出身，多年的工作和教育都让我们的思维惯性是技术向，只会考虑如何实现、要做什么 。而做功能设计画原型，则是要去考虑用户的使用上怎么用才是合适的。粗暴的将表模型、业务模型，1：1的体现到功能/页面上也不能说不能用，但是很烂的设计。
因为梳理总结的业务模型，和使用系统的功能的一步步操作并不对应：业务模型是调研总结的全局视角的一个规则性的东西。系统的功能设计/操作则要考虑每个业务的使用者职能视角的关注点和实操流程，怎么操作更贴切现实业务。
如何破除旧研发思想，从业务模型中得到系统功能的设计？这时就要回扣"标准业务流程"了 ，所以很上面可能说过，B的系统建设路径是对的，只是没有考虑业务难度。 我们的业务模型可以说在调研前后都没有什么实质性的变化，而围绕着业务模型封装的功能设计则要依靠"标准业务流程"了
在依靠"标准业务流程"的过程中，我们也认识到了B确实有些东西 ，理解了为什么在前述评审"标准业务流程"时B总是在"挑刺"了，没有B的挑刺我们的功能设计会更差。因为确实做的不够细致。思维定式太严重了，思考到抽象设计就停止了
有些功能的细节设计（如计算规则、策略），则是标准业务流程不关心也无法涵盖的，纯粹的实现功能后该如何使用交互细节，此类场景功能设计的就需要我们自己代入使用者，去把核心的计算模型打散到操作中。
文字只能很理论，总结就是实践出真知。
2、公司风气的惯性、非专业原型埋下的祸根
我们对于产出的资产过度不敏感了，画好的原型零零散散分散在不同人的账号不同的文档里，因为在惯性中这些原型不会再次用到，如果有修改也会是直接在前端开始时调整。我们又一次"默认"了替客户决策了，而客户事实上是要求几次三番改原型改到满意为止，国企特性是少犯错不在乎人力投入产出。
后面经过后面几轮宣讲后有所改动 OR HB他们线条要汇报给大领导看时，我们都在到处找当时产出的资产。
技术问题的流程冗杂化
STEP2：又是宣讲
客户还是那个客户，宣讲的流程没有变化，总部拟定邮件邀请xxx省派出可以定夺人参会，一个个模块每个半天。
事实上此时拉会议对草稿设计的功能宣讲无意义，举个例子是：对于算薪功能中的一个细节实现，宣讲后地市老师提出疑问如我有什么什么场景，你们能不能支撑。而我们的答复则是基于功能设计可以or不可以，不可以的就要考虑改动设计。
又一次进入了决策陷阱 ，从技术实现来说只要你客户开口，就按你说的来技术上没有阻塞，但这个项目坏不就坏在无人决策了吗~可想而知没有有效产出什么定论，就这么僵持了，后面还是靠甲方大领导急眼了才草草跳过开始研发推进。
并且在宣讲的过程中，我们（系统）和地市（业务人员）并不是一个团队，可以说没有什么通用的语言，地市其实听不太懂功能什么什么的。在项目生命周期里讲，预上线时才有能力做宣讲做培训会，纯粹培训如何使用不变了系统都要一两周，对比下来这时候还没起步就功能宣讲会只的是形式主义教条主义。
STEP3：仍然未和客户达成一致的建设范围
STEP2中大领导急眼了，所以宣讲进行到一半就开始去做研发计划和推进了。
这也就导致了，关于一些外部系统对接、行政流程支撑的功能开发到什么支撑程度，这一个从项目开始1个月到现在一直存在的建设范围意见不一致问题，再次搁置。
很奇怪为什么会到现在还没达成一致，专门回溯一下：
- 刚开始的时候，调研，我们自己没有意识到
- 调研中期二次线下调研时，我们意识到了，但是为什么没有决策下来？
- W没有及时上报巨大风险，而是和总监"玩"的会议汇报聊天，而Y信的总监主打一个不粘锅事情你做，无人去触客户这个霉头，皮球推回来，最后反正问责问到你W，总监也只会拉家常老好人保你（继续pua）。
- 标准业务流程时，已经暴露存在很久了，为什么还是没有决策下来？
- 每次周会反馈上去，都会被踢皮球踢回来，让你去调查可不可以接。而同时P和YY早有自己的想法，二级是糊涂车子。复盘才可以看出来，只是个过场让你去调查，而不是让你真调查告诉他们有多大阻力不能接，你的答复如果想被正式认可只能是"保证完成任务"。真是恶心当时我们还指望说服这帮虫豸。
STEPX：时间差不多咯该出研发计划咯
时间上，在甲方的功能评审宣讲尚未通过时，B就要求研发计划，混乱的并行着。
而W则是服从，要我辅助他给个雏形好汇报的研发点概要，即使W、HB我们都知道这个是失真的。
我们当时都在想什么已经无从考证了，总结下来只能说是形势比人强，不出研发计划不行。（核心问题是我们又一次忘了官方渠道申明我们的无辜，被迫出了一份自己不认的计划还落人口实，最后也确实被缺少道德的甲方用来扯钱扯逾期的事情了。）
在甲方大领导急眼后，研发计划正式出要执行的了，但是嘛，内部矛盾开始爆发。
要有一份可执行的研发计划的前提是你的功能设计（或者说叫概要设计是完善的），可以支撑下一步详细设计。 详细设计出个七七八八我才敢拍脑袋告诉你大概多少人天可以完成开发任务。
那么小伙子，现在功能设计宣讲一半被叫停了，同时一些对外部系统交互的功能的边界还是模糊的，这个概要设计的完善程度您觉得有几成。
那么小伙子在当前人力投入下，先不考虑概要设计的完善程度，权当能用，那么您觉得有谁（how many people）可以去做详细设计。又有哪些人可以帮助决策评审详细设计是否合适通过。
现在要你3天内出研发计划（B真是个畜生，寄生虫传话筒），回答这两个小伙子的问题后，就很显然了，这份研发计划不可能具备几成真实性，又一次的面向汇报编程。
内部的争执自然而然的发生了，对外承担压力的HB和被逼着出设计和人力需求的我都很无辜，都觉得受到了其他人的阻力和胡乱指导，但其实是客户和B的全责。
此时的研发计划是总体层面给大领导一级二级看的
之后研发正式开始后，我们的研发阶段才被分为了0430、0530、0630分3个版本上线
STEPY：技术方案PPT
值得学习的方法论：如何传递信息给他人的过程中发现不足之写写PPT。
在你写PPT的过程中，你会发现自己最初的以为自己完全知道这个系统长什么样、知道几个重点功能的模型是什么样的，是不可靠的。 只有当落到纸面上时，才会发现还有细节悬而未定，凡事预则立，这些细节再画PPT的过程中一步步变得清晰。
脑子里有雏形能够执行下去时慢慢清晰地完成执行是一回事，而能够书面清晰地讲出来传递给评审人员又是进步了一个阶层。
帝皇的货币-研发、测试、运维都不是人
【202403-202407】
STEP1：基础设施的摇摆
- 技术方案中涉及到系统架构，其中又涉及到云服务的基座，在这个客户的要求下是必须使用PJ平台的，悲愤交加的是：和向他们要求人员指导如何使用PJ平台，甲方居然说要我们自己一步步对平台，他们以前没有对接过，搞得自己集团内的事不关己，而这些对接内容也在标书里......
W居然寻求B的帮助，B的公司说是他们承建的部分比我们先结束调研开始的研发推进，所以可以帮我们出文档......但是还是太嫩了，怎么可能别人公司帮你上心做呢......事实也确实如此，那文档流水账都不为过，只有软件的安装指导能用，之后是我们运维专人去对接的PJ，文档量级翻了10倍不止。
- 数据库选型则是好像我们有得选，其实没得选必须用指定的国产化数据库，即使其他的国产数据库也在清单里，但是政治上今年只有PW数据库可以选。
数据库方面存在以下问题：
1、不知道自己的数据量级别：虽然是分几批上线，可能还会分到2期建设，但是数据库资源要考虑扩容的便捷性时间成本、稳定性（直接咨询数据库提供方），所以最好一次性申请全生命周期（至少5年审计满足）的资源。然而此时甲方内部提供不出一个省份/地市的月份数据量均值。
2、不想给成本高的资源：当我们评估出应对审计5年全部数据需要多大量级的存储资源，并由PW提供方提供满足应用服务规模下，每个CORE吃每个50个连接需要多大规模的CN、DN及主机型号性能后，提交上去审批。首先发难的是W，在天上飘久了屁股歪完了，需要多少资源白纸黑字算出来的有依据，他却先甲方一步拦截，说是"太多了，我认不了"，不知道他是出于什么目的发表意见不认的。 第二个不认的是甲方，理由很简单，太多了给不起，穷。
那穷确实没办法了，只能讨论一波波申请扩容了，评估下扩容对于运行态数据库服务的影响。
分布式数据库的评估看
1、其引擎是什么，Mysql还是Pg还是其它什么，关注其SQL执行时是下压DN执行还是拉取到CN大内存执行。关注这个是因为被中兴的GoldenGB搞到PTSD了，GoldenDB会动不动就因为大数据量SQL拉取CN大内存的模式把节点搞崩掉。下压还是拉取也会决定其事务机制如何保证，所以需要与数据库提供方沟通明确后研发内部全体知道。
2、数据膨胀率：你都需要分布式了，那数据量不可能小了，大数据量下膨胀率会带来恐怖的资源浪费，磁盘需求可能超乎想象的大于评估数据量。
3、和集中式一样都要关心的：主备主从一致性相关机制（数据库方提供）、多地容灾（我方要求）、扩容机制（数据库方提供）
4、锁的颗粒度，锁表还是锁行，我不要自己想我要数据库直接给我参考手册，这会影响到一些业务操作的性能问题变相影响设计取舍。CN局部还是全局锁，这个在测试阶段出现过问题怀疑，但结果上是全局的。
5、基础的性能：吞吐效率、压力并发下的性能、复杂SQL的性能降级情况
6、可靠性、稳定性：这个反而最无所谓，出数据库本身的问题了一定是PW团队背锅，打工仔别在意。
- 其他中间件评估问题：
Redis：
在这个系统中，Redis只是用作缓存和分布式锁，作为缓存我们原则上要考虑吞吐性能。但是1是此时建设全景不清晰，2是只有平台只给几种redis型号供你选择，所以我们简单的选择了高性能型号了事，属于是将问题延后到预上线阶段，出现瓶颈再扩容咯。一切战术转压测
MQ：
消息队列的评估其实没有评估用哪种Mq更好：我们只关心是否需要使用Mq，Mq对于我们的系统来说，只是为了传递不同功能间的事件驱动业务的传递下去，任何一种mq都可以满足需求。既然是平台提供的可靠中间件服务，所以申请新一些的rocketmq总归是好的。同样未评估吞吐量、持久化周期，选择高性能型号。（平台提供中间件是可配置项较少的没那么多八股的什么同步异步刷盘，什么是否开启同步持久化什么的）
- 开发环境也存在问题：
PW数据库、PJ云基座亮过相了，开发环境的问题轮到PZ一体化持续集成平台了，这三兄弟是一套，PZ主打代码仓库可以和自己的PJ、PW连通。
问题在于安全要求下，使用PZ的电脑必须安装零信任安全，而零信任安全会摧毁一个电脑的使用可能，无法用于其它任何事务。对于此风险，这时我已经从调研的恍惚出来了，能够判断并上报风险，邮件也该发发了。可是HB和W都没当回事，这就是整个Y信领导在天上飘的久了的问题，总以为自己领导有方可以和xx内一样说话发文解决一切。HB尚且可以理解他，不是技术人员，W则无从开脱。
因为风险被无视，产生的后果是推进PJ事务的同事电脑无法办公一星期。
这个安全软件废电脑的问题，单纯解决是好解决的，我们申请一台电脑专门干PZ、PJ的事务就好了，但是会在后面产生持续集成的问题：公司git和PZ git存在了2套代码仓库，而两套都有着自己的测试UAT生产环境的分支。---见持续集成MINI
- 资源评估也闹心：
此时还没有决策到底做几省还是全国，只是允许分成几批上线，所以资源到底按什么来评估也是个迷。此时的业务功能详细设计也没出来，用户行为自然也是不清晰的，要承载多大的性能指标故也不清楚，这拿什么评估。
且算薪部分的计算数据量也无从参考......算薪时间要求，他们也不给......
所以资源评估是保守按照以前做的省份评估的，往大了估。结果估完后甲方又不认账，觉得太多了......哥们这是建设系统你在这"觉得"是什么意思，你们的专家评审都没意见认了我的评估依据......
拖了一周终于开始申请了，又发现资源不够没那么多物理机，what can i say。
STEP2：内部还在人力投入扯皮
不枉你Y信有今天鸭，从CEO到他下面一级级领导全是歪把子。
人员质量
四处借人，都这时候了还在掰扯自己的人力工时，质量差，代码差，巨大风险，反正我抄邮件了。
STEP3.1：赶鸭子上架的系统设计
研发设计层面没什么可说的，架构服务划分之前技术方案已经做过了，这里就是业务模型去设计合理的数据库模型，然后作为参与调研的研发头头向每个近端远端研发传递设计拉会，进行保障。
详细设计是我独断的。
败笔是没有使用DDD，从复盘的视角看在研发阶段如果使用DDD可以降低很多我与其他研发的沟通成本，也可以兜底甲方在后面出现的紧急变动紧急改设计的情况
发现了：DDD在与越差的研发沟通时越好用的特性，传统的功能接口设计文档，在对于能力较差的研发沟通时，他们很慢很难理解业务与设计的关联性或单纯的业务理解。DDD具有起跑线拉齐的作用
在与研发沟通的时候，我们可以发现虽然从研发上去的领导们，总想着业务与开发分线条，这也是过去的大趋势。但是在实际沟通中研发必须理解一定的业务才可以开始工作，否则你对研发输出的设计将不得不细化到每一步操作即详细设计。
STEP3.2：仍然在摇摆建设范围的甲方
研发正式开始后，我们的研发阶段被分为了0430、0530、0630分3个版本上线
此上线版本划分、时间划分是没有可靠性支撑的，这个不必多说，HB拉出这个计划是"没用的事也要做"的方法论一部分，做出这个计划在所有人心中埋下一个潜意识的死线，如果没有这个死线潜意识，进度只会更加崩塌。--当然这不意味着可以不遵守时间交货，这是HB从研发反馈+客户压力权衡中给出的一个时间要求。
而在4月版本建设一半时，我们还在和客户拉扯到底外部系统对接的边界是什么。中途加入的测试专人SJ在空闲期被分配去专门处理外部系统对接的事梳理，至少没有再并行复用调研老人了，算是有点章法了。
悲哀的是他也步入了认真调查，然后被客户否定暗示你必须做的循环。我前面说过的：复盘才可以看出来，只是个过场让你去调查，而不是让你真调查告诉他们有多大阻力不能接。
是不是必须做这个摇摆问题，总的来看背锅的话，我们自己是没判断好-和-客户没正式表明审计是必须的政治任务，各占一半
在2、3月份得知了这个项目背着政治任务后：（1）客户未明确正式表明为了审计安全，数据安全，你们必须接xxxx系统，在那里指点江山过领导瘾却毫无决策负责意识。（2）我们该自己判断出来这个是他们的核心诉求去帮助他们点破，不再浪费时间拉扯提前进入对接。而不是心存幻想听酒囊饭袋领导的飘在天上的指点如何省成本讨价还价。
STEP4：这时候临时要审批能力？
和STEP3.2的摇摆建设范围相似，这时二级三级P又接到上级指示：这系统啊，一定要有审批。
而万恶之源标书呃呃呃呃。
审批能力怎么来呢？此时有2个大路线可以选：1、接入B他们公司承建部分的系统，这个客户比较乐意看到，毕竟国企特色xx精神象征意义比较大，"兄弟们一个系统嘛哈哈"。2、我们自己建。
从跌宕起伏到现在5月份，我们已经对与B方（或者说B个人）的合作力度没有信任了，所以直接强烈否决第一个。我们自己建的话又该如何推进呢？
客观的说B他们也有成本考虑人力考虑，也不可能和我们认真对接，派个实习生了事是他们的作风。
而我们的内部建设如何落实：你可以看到内部4、5个总监的勾心斗角，他们飘在天上不在乎建设人员的死活，这时候还在勾心斗角怎么多分一点。
W和我通气的是：我们有没有能力自己建设，答案是有的，封装一个flowable/activiti的工作流并不是难事，开源的比比皆是哪来即用。那么分三个维度讨论：
代价：更多的人力投入：我的投入其它前端后端的额外投入。因为其他人放心不下，前端水平无法主导（灾难很好控制的零件）
好处：我们保证了自己部门对这个项目的控制力（金钱分配、代码控制）
风险：（1）我的抽身将导致主体业务研发停滞。（2）审批建设图景的不可预见，虽然薅一个开源的改改，技术路线是可行的，但是这实际上要求对于审批需求的再调研、画原型、出设计。
所以在HB的总监M提出把CRM的现成的产品里的审批拿过来改改时，我们接受了这个方案。 当然M把CRM的审批薅过来，也是要进行调研、设计、适配的，但是这样子推进的负责不再需要我们部门参与，由M分治。我们付出的代价是这个项目的报酬分到配有M部门一份。
确定了M总监亲自负责后，审批就稳了吗？答案是黑色幽默否定的：
M从CRM那里薅过来了一个T4人员负责此事，M要求其出个方案和我们对接，我们乐于见到这个场景。
在T4过来一周后，其进展处于部署一套审批服务的阶段，问题在于
1、这一周里前端配合其他将审批的页面搬移到系统内，虽然并不顺利但还算是在进行。
2、他独立要了一个研发云环境部署审批服务，我们并未关注。然而在与其同步信息后，此时才把问题暴露出来：他一直部署的审批服务要求一套自己的zk、antdb，而他这一周都没有与我们共同评估如何解决这个问题，一直默认当作我们会提供zk和antdb在那里死做。
3、他并未梳理一个可供评估的业务功能接入审批的流程/时序/接口清单此类文档。
what can i say？这就是Y信的T4，这就是M（总监）的管理（对于研发人员的管理、对于自己的CRM的掌握程度）。
做完这整个项目，我可以负责任的给Y信领导定个性：从研发做起赶上时代机遇，踩着风口扩张做上了领导位置，名不副实并不会管理只为自己工资负责的管理人。
Y信有今天的盛况，就是老领导们和老T4M4们互相成就倚老卖老的结果。
STEP5：没理由的分阶段上线军令状
上线几个版本被粗暴的划分为430、530、630，虽然是与我们有过沟通共通决定的，但还是很不爽。
所谓共同决定，即客户强压之下，项目经理做出的合理决策，必须要给客户可以吃下的定心丸，所以不管我们研发觉得这几个版本的意义是否具备实际意义（哪怕只有最后一版才可用），都要划出几个版本。
可以理解，嗯，可以理解，这确实是合理的做法。我们也配合他尽量划分的不要太破碎模块，让每个版本可以一部分运行起来。
但代价是什么呢？没日没夜的加班，同时对于我们（研发侧）自己这是给自己挖坑承诺按期交货。
现实是复杂的，HB有他这么做的合理性，但我们配合他之后，如果完不成按期交货，又要被他在会议上说，他也要保护自己的（他本身是跟着M总监的不是我们部门的），而那些尸位素餐的总监又看重这种勾心斗角（本身从项目开始不顺时各位领导就开始吵架了）
HB总是说"兄弟们努努力"，作为研发侧我们是很反感的，口惠而实不至，努力没有回报。但是如果客观看待，HB他说或是不说取一个更好的，那还是"说"对于推进和氛围更有利。一方面是这种"废话"对于推进是必须的，日常任务一样的话必须说，说了总比不说好；另一方面是，他老油条知道我们会不爽，但不爽骂给他就好了，不挨骂怎么赚钱，也是有利于推进的。
STEP6：进度要到百分比说是
HB作为项目经理每天都要"质询"进度，每次都要浪费所有研发人员上会1小时起步。
这个问题在于：
1、HB完全不懂业务也不想去了解业务，事实上之前的补充调研HB是随着一起去省内调研了的，但是到研发阶段了，HB依旧对于业务毫无认识，要了解我们的系统设计也就无从谈起，更无法理解功能间的关联性、功能自身的复杂度评估。
2、研发人员不知道自己的进度算什么情况：研发人员都是中途进入的，或者说在传统研发推进下，每个研发不会对整个系统设计有广泛的理解，最多按照代码开发情况给一个不可靠的单元百分比。而在计划排期中，完成一个单元的开发后就要开始测试工作，如果不同单元间存在依赖影响，那么实际无法开启测试工作/无法给出自己的单元百分比（因为还存在依赖）。所以给出的进度是强压下被迫给出的并不可信，只是他们让自己心安和向上向客户汇报的定心丸，无语，但又必须这么执行下去
综上导致，我们总会在会议上，HB向研发要求进度时陪同:
1、在存在多单元依赖关系时充当总控协调器来统计一个尽量可信的进度给到HB。不这样的话，研发在压迫下给出的不可靠进度会坑我们自己。
2、同时还要频繁反复解释几个业务间的关系所以为什么xxxx不能给你这个进度/这个先挂起。因为在HB的视角是排期出来就万事大吉了，即使这个排期时我们也解释过了不同单元功能间没法排准确时间，只是一个概括，只有二级标题是可信的功能点，再细的随时调整。进行中也会调整变动--但HB还是按计划时间在会议上反复要进度，要的颗粒度还是最细的一个个功能点级别，我们总要解释这个为什么调整那个为什么挂起，很难受。
最多是可以理解他也有焦虑有压力扛了很多外部压力，但是这种不变通不学习的把压力转移到研发是不好的行为
- 先这样吧累了
STEP7：形不成闭环的研发/测试/发布
极低的代码质量导致返工频发。偶尔我空了也会看看提交的代码，无语
测试不够专业仅单元功能
发布受到平台阻力gank，甲方也不作为，甚至临时领导视察还要装一版
上线就是成功，成功就是上线
到底为什么，这个项目所有人老油条都没意识到建设范围的不明确之祸患
从功能边界，至验收标准，无一明确。或者说是意识到了，但又是事不关己敲个钟，没去落实到客户麻烦事。
中间件也会暴雷
未提前进行可用性验证
政治怪帅导向的两个最终版本
计算版本
审计版本
都这时候了还在扯人力分配
怎么才算上线成功
这时候才定地市？收集模板？
急了，甲方不作为的傻逼三级P急了
不可能算得准，M：结果导向（真）
都这时候了你们还这个支持力度啊甲方真有你的
持续集成MINI
【202407-202411】
双git仓库&&各种临时版本、需求敏捷的CICD
在多人并行开发一个功能边界赶鸭子上架的初创项目时，该怎么划分分支形成提交规范呢？
分支的划分诉求本质上是
（1）代码间的干涉问题，无法保证不划分分支的前提下 （2）版本间隔离的诉求：不能把未审计代码发布出去
在最初的代码分支设计上，我们只有一个dev开发分支，因为此时的诉求是建设一个430版本上线，我们的诉求是这个430日期上线的结果将所有功能看作一个任务。我们的功能由自己0-1设计出来，在分配任务时总控将任务尽可能分配的不会产生多人互相干扰代码的场景，并且进行了人员间依赖的接口与其demo实现类的要求。在发布时发布人员从我们的git拉取代码，复制到PZ的git下再force push，PZ事实上只是一个对于我们git的镜像。
随着430、530发布后出现了新的问题，此时的代码已经具备了一定的规模，在进行630版本的开发任务时，不可避免的会出现新的未测试完成的代码在公共测试环境测试时会发现bug，并且会对已有功能产生阻塞/干涉，进而影响其他人的本地测试/公共测试环境测试。
我们可以创建每个人的私人分支以贮藏代码，自测通过再合并dev分支，但是问题并没有得到解决，问题的本质是我们只有一套公共的测试环境。想要进行联调就不得不发布到这个公共测试环境，如果想要保证公共测试环境总是可用的，就必须将联调测试的工作前移到其它环境（比如两个研发间本地互通联调，或每个人一套私有测试环境），此时"公共测试环境"实际上定义变为了"公共准发布环境"。
最终的结论是没有那么多资源且网络受阻的前提下，我们维持现状，依旧定义为"公共测试环境"就是用来测试用来测出问题的，同时进一步宣传"研发在自测时要足够充分"（也怪我们的研发质量实在太低了）。
此时分支包含每个人的私有分支和dev分支，PZ的git依旧只有一个dev分支作为完全一致的镜像。
再之后是630之后的一系列优化和新需求，因为正式的大版本发布完了，进入了一个迭代优化期，所以我们必须有一个可靠的版本与测试环境dev分支隔离开，故而新创建masterPW分支。此时masterPW分支与PW的git的唯一一个分支（dev）一一对应，我们的代码经过公共测试环境通过后再pick到masterPW分支，由专人专机copy发布。
此时存在的问题是：
1、git管控代码的最小粒度是文件，即"类"，而一个类中同时会存在多个不同发布日期的开发功能在进行，且这几个开发功能点是会互相影响的。这导致了：：研发如果提前开始了下个功能的开发，那么当到达发布测试日期后，在uat或准生产环境测试出现新的bug时，他必须在本地精细的调整每一个方法的代码以pick新的提交到masterPW分支。
2、敏捷的需求并不会允许你按排期进行发布：敏捷这个词说的好听，其实是需求塑形的不完善，并没有准确的细致的掌握需求全貌，故而产生了发布后客户准生产使用过程中的各类调整需求。在此基础上，每次敏捷都要求重新审视排期计划，如果进行了较大的调整研发就要回滚各种开发到一半的其它功能代码，很难管理并且会让研发产生无用功心理。
630里程碑后之后的一系列优化和新需求，为了满足上线发布的安全，是需要对每次版本做好回滚的，PJ平台提供了镜像历史的能力，那么我们只需要考虑一下代码是否也需要做好每个发布小版本的管控：结果上是不需要的，需求是单向滚动的，如果出现破坏性的敏捷需求那也意味着整体设计大改，客户如果发出这样的诉求，不会有回滚的余地。
其他变动：随着大版本发布步入正式化，PW原masterPW分支对应客户测试环境，新增-prod和-uat分支应对生产和uat环境
持续生产事故（划死）故事
网络不通
半夜死机，长期锁表
审批调度程序效率
与B联调
表规模超出预期
启动慢
驱动
地址还能写死
性能过差的导入
基础设计变动-person
不成熟的设计-ss select
八股文会说的分布式事务-审批发起
失败在于什么？
从头到尾没有确定建设范围，缺少议价权
对方决策者缺少担当，我方缺少对对方的定性，我方领导缺少担当
研发力量/激励不足，不做事
个体的力量是有极限的，建设好我们的青年同事队伍.jpg