这份旧版起草稿，字迹虽显笨拙，却藏着对规范最纯粹的初心，一笔一画的生涩里，是起草者对标准的敬畏与探索，是对严谨的执着追求，正是这份不成熟的笔触，勾勒出规范的雏形，奠定了后续完善的基石，初心在笨拙中闪耀，如同暗夜里的微光，指引着方向，让每一处修改、每一条细则，都带着最初那份对“规范”二字的郑重与热忱。
“17.c-起草旧版”——这串带着编号和“旧版”前缀的字符，像是从泛黄的档案袋里翻出的老物件，边缘或许还带着卷曲的毛边，它不是最终定稿的辉煌，也不是被奉为圭臬的权威，却是一段被时光反复打磨的起点，一场在粗糙与严谨之间反复拉锯的“文本实验”。
为什么是“旧版”？从“救火”到“立规矩”的冲动
写下“17.c-起草旧版”时，我们正处在一片混乱里，那是一家科技公司的创业期，团队从几个人扩张到几十人，项目从单点突破变成多点开花，却没人说得清楚“谁该做什么”“做到什么算合格”，客户投诉像雪片一样飞来，内部协作总在“我以为”“你忘了”的推诿中卡壳。
“得有个东西！”老板在会上拍了桌子，“把所有该做的事、该有的标准，都写下来！”“17.c”这个编号诞生了——它是当时《项目管理规范》的第17章，第c条，专门讲“项目变更流程”的，而“起草旧版”，是因为我们心里清楚：这版东西，肯定不完美，但总比没有强。
那时的我们，像一群第一次学做饭的人，只知道“生米要煮成熟饭”，却分不清该加多少水、煮多久，条款里写着“变更需提交书面申请”，却没说“书面申请要包含哪些要素”；要求“评估变更影响”，却没明确“影响要评估哪些维度”，甚至有些段落，是用口语化的句子堆出来的：“大家尽量别改，改了麻烦，真要改，提前说一声。”
但奇怪的是，正是这样一份“漏洞百出”的旧版，成了团队的“救命稻草”，当新的变更申请涌来时，大家第一次有了统一的参照：虽然条款写得模糊，但至少知道“要填表”“要开会讨论”，那些曾经被模糊地带掩盖的矛盾，被这粗糙的“旧版”一点点摊开在阳光下。
“起草”的笨拙：在争吵与妥协中刻下痕迹
起草“17.c-旧版”的过程，像一场没有硝烟的“战争”，跨部门的挤在一间小会议室，技术部说“变更要留足测试时间”，产品部喊“客户要的需求得赶紧改”，运营部抱怨“改了别的东西，我这边的数据对不上”。
为了“变更审批层级”这一条，我们吵了整整一下午，有人主张“部门经理批就行”，觉得流程短、效率高；有人坚持“必须CTO签字”，担心“小改背后藏着大风险”，最后折中：金额小于1万的，部门批；大于1万的，CTO批，可“1万”这个数字，是谁拍脑袋定的？没人说得清，只记得当时会议室的空调嗡嗡响，每个人的额头都挂着汗。
还有一次，为了“变更记录要存档”这一句，行政部的实习生小张拿着笔记本，一字一句地问：“‘存档’是存在电脑里还是打印出来？存在哪个文件夹？要不要编号？”我们面面相觑——谁想过这些？最后只能含糊地说：“先存在共享盘的‘变更记录’文件夹里，编号用日期加项目名吧。”
那些被反复修改的草稿纸，现在想来都是珍贵的“笨拙证据”，某页纸的边缘画着流程图，箭头歪歪扭扭；某页页脚有咖啡渍，大概是某次熬夜加班时碰洒的；某页空白处写着“这条款不行，明天再改”，字迹因为疲惫而潦草，正是这些“不完美”，让“17.c-旧版”带着温度——它不是冷冰冰的条文,而是一群人边摸索边前行的脚印。
“旧版”的价值：让“规范”从“纸面”落到“地面”
“17.c-旧版”上线后，并没有立刻解决所有问题，有人嫌流程麻烦，偷偷绕过审批；有人对条款理解不同，还是吵得面红耳赤，但它像一颗投入湖面的石子，至少激起了“规范”的涟漪——大家开始讨论“什么是合理的变更”“如何平衡效率与风险”。
我们收集执行中的问题，在旧版上贴满便利贴：“变更申请表要加‘客户签字’栏”“评估影响要加‘对上线时间的影响’”，这些便利贴，成了下一版“17.c-修订版”的素材，半年后，当“修订版”出台时，那些曾经模糊的条款变得清晰，那些争吵过的点有了明确的答案，而这一切，都始于那份“漏洞百出”的“旧版”。
后来，公司规模越来越大，《项目管理规范》更新了十几个版本，“17.c”也从最初的几条扩展成十几条，流程图越来越复杂，条款越来越细致，但每次培训新人时，我都会拿出那份扫描版的“17.c-起草旧版”，告诉他们
