背景：
核心业务模块突然需用 Flutter 进行重做，历经千辛万苦按时上线，达到预期效果。本文主要是项目中遇到的问题、当时的解决方案、以及反思。
成文初始吐槽过于疯狂，放置数月修修改改，凑合用吧。
本文不构成任何参考意见、仅作为回顾及吐槽
工期问题--
-【 极限压缩的工期 + 多方配合矛盾，前端承担巨大压力 】-
听到项目的当天就是实际开始开发的日子......一开始就确立整个项目“急”、“乱”的基调。后从立项书上得知在项目立项前就限制了产研测全部时间最多45天，为了赶在年底汇报前......
与各组简短的沟通后，测试需要15天测试时间，整个后端最快则需要30天，这一算下来···前端真是被放在火上烤。
【问题1】: 工期严重不足
- 要时间：与直属领导沟通，多部门协调时均咬死各自时间点一步不退。协调过程中又被强行砍掉了部分时间，让前端兄弟们消化一下按照997来
- 要人：得到3个小伙伴的支援
- 调整策略：降低开发工作量，例如开发仅进行必要主流程自测
在协调工期时，提前与领导沟通多给点时间，结果会议过程中反水，工时被再度压缩。
要人的时候期望符合标准的同学，但是最后分配的均为新人，且均未参与过核心模块的开发，使前期的培训成了必要工作，同时项目过程中还需要重点关注相关模块的业务及代码质量。
【问题2】: 依赖方工期冲突
- 细分优先级与时间节点，设置deadline：坚守前端时间的底线，要求后端主流程提测尽可能提前，并且要求接口文档的最晚提供时间
- 中间层兼容：前端进行防御性的冗余逻辑接入，先接入老流程，后续通过中间层来进行新老后端接口的过渡
- 主流程优先，提前冒烟测试：高优保障主流程，协调测试提前介入进行主流程进行冒烟测试，分摊开发压力
工期被极限压缩后，
通过拆分必要的依赖项，逐个争取各个子项的依赖方时间提前
为了不影响前端的整体进度，前端先行接入了必要的老流程，通过中间层去拆分具体的业务模块兼容老流程，迫于无奈耗费4pd冗余工作量由两个核心开发消化，只为最大化降低了前端受后端时间节点影响。
给测试充足的时间是必要的，在前端的联调时间不够的背景下，优先保证主流程的完成度，让测试提前介入主流程冒烟测试。给测试争取更多的时间让测试尽早参与到联调过程中，弥补联调不充分的问题。
任务分配
-【 多人配合+极端周期下，通过合理任务拆解与人员匹配是保障节奏的核心 】-
把合适的人放到合适的位置能事半功倍，人员配置为2个核心开发、3个支援同学、以及2个督军。
【问题1】: 极端工期下的任务拆分
在极端压缩的工期背景下，任务拆分不仅是将任务项拆细，关键的是理清任务项依赖关系，并细化至以天为单位的任务项。
细化至以天为单位、理清依赖关系均可充分的利用时间：分配任务时优先完整模块分配式的模块化分配，小模块、低关联度功能则用于任务补充，以此来减少耦合。
给关键人留时间Buffer：分配任务时要预留备用时间，尤其是对核心开发。整个项目中如果有问题，大概率是核心开发处理。在工期允许的情况下尽可能的去预留充足的时间，这次的项目很紧，预留时间非常少，也起到了非常重要的效果。
【问题2】: 任务项分配至合适的人员
综合考虑“技术能力”、“经验”、“过往表现”
其中的“经验”项在充分了解另两项后可降低参考权重，或排除，现在回想庆幸最初分配任务时“经验”项权重较低。
【问题3】: 让新人开发快速进入项目角色
- 非细节讲解：通过项目架构、业务模块的集中讲解来达到快速熟悉业务、技术栈的效果
- 使用进度看版达到鞭策效果，前期通过一定程度的施压来促进大家快速适应项目的高强度节奏
为了让新人开发快速进入项目角色，组织会议对业务的各个模块、项目进行
架构讲解，业务讲解，只需明确整体流程，细节上不进行过多赘述，相当于只给一个“施工图”，能最快的帮助成员快速搭建整体项目“脑图”。
进度把控
-【 精细进度管理+异常处理机制，保障主流程在混乱中稳步推进 】-
【问题1】: 如何保证项目进度顺利进行
- 最小单元控制：细化整个项目流程、模块，进行最小单元节点监测
- 进度巡检：制定站会、巡检等机制，尽早的发现问题。
- 工时透明+异常补救：按单位时间进行进度巡检（项目前期是每3天巡检1次，中后期、测试阶段每天发），异常时进行必要补救不影响整体节奏。
- 整个项目过程中，能使项目在极端压缩的时间内按部就班的一步步完成并上线、保质保量的关键就是进行了
“最小单元控制”，这里的“最小单元”并不是去限制开发每天应该做完什么，而是将精细化拆分的任务分配到具体开发后，通过各个大模块的“工时进度”来进行进度方面的巡检，“工时进度”相对于”任务项进度“更加精确，开发也拥有各自所负责模块进度的绝对控制权，对于不熟悉业务或者不熟悉技术栈的开发在前期比较友好，在其熟悉业务的同时，可进行一些次要功能的开发而不影响整体进度。能够立即发现是否出现进度阻塞, 也给予了开发最大程度的“灵活性”。每日站会、每周的完成度巡检可明确实际进度情况，与开发保持密切沟通，尽早排除阻塞点、发现隐藏问题。- 需要说明的是，这种方式仅对自觉性较高的成员有效，个别开发工时进度明显落后依旧不积极处理阻塞点，对实际进度瞒报、谎报、不报，再三询问却均表示没有问题。当时的处理方式是
“确认其进度多次异常后，不再对其投入过多精力，维持其原有主要模块，拆分出未开始的完整模块给到2个核心开发，以此来保障整体项目的进度”。（结果表明是正确的处理方式，在其进度越差越多的一周后，领导跑过来说其反馈任务太多太难做不完让分担他的工作时，举证拆分出来的模块已经被核心开发完成其剩余工作已小于实际要求，领导也只能作罢）。
一艘必须快速航行的大船，如果某一节船舱进水，快速确认是否可抢修，不能的话就立刻封闭，不要让其影响到整体航行。
【问题2】: 依赖方字段级逻辑梳理要求
在项目中期，后端要求前端去梳理所有旧有逻辑，精确到字段级。这种工作放在平时，需要大量时间。项目前期梳理的逻辑后端认为不细致，需要字段级的梳理。需前端写出一套完整的伪代码，后端明确要照着梳理出来的逻辑进行开发。这个梳理并不只是主流程，而是包含前端所有的显示的逻辑...这是整个项目过程中遇到的最意想不到，耗费精力远远超出预期的情况，不仅极大增加了工作量，也承担了所有风险，后续任何问题都可以说是梳理的逻辑问题。
断断续续的耗费了一周多宝贵的时间去梳理，呕心沥血却漏洞百出，前端代码横跨近10年，很多字段级逻辑极度分散，个别模块里三层外三层。有的业务场景的梳理经过三四次的校验还是会有遗漏的场景。现在回想那段时间还是能感受到当时紧迫感。
反思：现在回顾起来这里做的并不好，这样的问题暴露在项目最繁忙的中后期代表项目开始前及项目前期对接不完善。同时在处理该问题时不能无底线配合。
【问题3】: 项目过程中人员不断被抽调
- 公开风险警示：多次在项目群对更高级别领导进行项目风险警告
- 协调人员进行必要模块的分担
- 滞后非必要/非业务强相关的任务项
- 在前端工期被极限压缩的背景下，人员不停的被强制抽掉去支持其他项目，影响部分模块进度。当时向领导表达抗议无果后，在项目大群进行多次风险警告。
风险告知，收效一般。- 任务项的重新协调，大部分也只能分摊给核心开发，其本就严重超负荷，长时间的超负荷状态导致后期核心开发质量和效率明显下降。
- 协调人员分担只能部分解决问题，同时需要滞后相对独立、不影响业务流程的任务项，例如预加载此类对业务没有影响，不做也不会影响业务上线。
- 实际上，性能相关的任务项也是上级重视的点，通过滞后此类任务项来不仅可以集中精力
确保业务优先，也可警示上级“再搞事情影响项目进度，滞后的需求就肯定上不了线”
人员管理
-【异地协作+低权限管理下，靠细化制度与进度透明维系团队执行力】-
整个项目的配置分为2个核心开发、3个新人开发、以及两个类似钦差监军，除了两个核心开发其他基本都是异地，团队管理面临不少问题与挑战
【问题1】: 异地管理
- 精细化进度把控：细化任务，工时/完成度实时可见，透明进度监控保障效率。
- 保持紧密的沟通：站会，周会，巡检跟进，出现落后时主动干预，排除阻塞点。
精细化的进度把控主要通过
“实际达到的任务工时 / 理论应达到的任务工时”、“业务完成度走查”完成，在这种方式下可及时发现开发进度是否落后，方便后续的进度沟通与协调。
当进度落后时，沟通本身是一个了解情况的过程，为的是帮助解决落后进度，不能当作允许进度落后的原因，自己在项目过程中就犯了错误，好在及时进行了补救。上文提到的与进度异常的开发沟通时，对方说明了因外部原因导致进度落后，并明确无阻塞点会立刻追齐进度，三天进度异常后立刻进行补救措施，解决了其负责部分进度落后的问题，也在领导来要求分担时有了有力的理由回绝。
【问题2】: 配合度不足
- 团队面前强势拍版强势拍版，防止分歧内耗
- 剥离关键职责，保障主流程安全，减少影响面
质疑一切的开发非常正常，项目要顺利进行一定要
强势拍板。拿架构举例，经过多个不同的声明式技术栈实践后确认为最适合当前模块业务场景的架构。经过对业务模块、架构进行了详细讲解，依然阻止不了个别开发强制修改架构的情况，沟通时对方也只是仅质疑不给理由，最后强制要求其在负责的模块整体上最低程度上遵循整体架构及流程。
抛开技术能力不谈，插进来的监工分走了部分工时，会议上当着所有人的面强势表明不做复杂模块。这其实不影响什么，原本也只分配其不复杂的部分，接受分配的倒还好，对任务挑三拣四、业务逻辑均拒绝，还要求很多工时这种非常让人头大，领导却默认了......有意见也只能忍着。“当众拒绝工作并得到领导的支持”影响最大的是“削弱了名义上项目管理的角色在整个团队中的权威，尤其是职级不高，平时比较边缘化的（我...）”。后续将这种高纬度的“监军”放逐在外，不分配任何重要任务。
【问题3】: 缺乏责任感
在项目中后期，长时间的高压开发，还有监工唱反调的前车之鉴，个别开发开始了“技术性摆烂”，尽一切可能将自己的工作甩给其他人，哪怕是明确阻塞流程的问题。
- 通过制度明示模块进度与责任人进行鞭策
- 让上级了解问题源头，及处理方式，明确责任边界
项目前期能顺手帮着做的都做了，中后期直接整个模块、功能点甩过来。明确告知已进行了必要的分担，无多余人力支持。同时让前来施压的领导知道问题的根源不在于任务分配和管理，并已经进行了必要的分担与补救。中后期开始每日公示进度明细。
联调
-【结构性问题提前暴露 + 风险预警，保障主流程通顺上线】-
【问题】: 非预期问题
- 预留缓冲时间：项目初期有预计到会遗漏场景、功能点，预留了少量时间处理此类问题。
- 明确技术基建责任边界：部门的 Flutter 的基建一直存在着诸多问题，在项目前期就进行了说明，将风险暴露出去，明确问题责任。
- 区分主次：不同模块的联调，在保障主流程的前提下，尽可能的使各个模块在逻辑上独立，最大化减小后期联调的难度
项目在过程中爆出问题很正常，
初期需预留缓冲时间。
对于非项目问题要尽早的暴露出来，进行风险说明，报备。
分阶段进行联调，可在早期暴露结构性问题，分担后期压力。
部门配合
-【依赖方优先级变动时，需靠人盯人不断拉扯推进】-
【问题】: 依赖优先级变动
多部门配合的主要问题可总结为“依赖方积极性低”，积极性低的原因是多种多样的，最常见的是被其他高优任务项阻塞。
- 节点锁定：项目前期制定的各组节点时间，尤其是主流程相关节点督促依赖方严格遵守
- 人盯人式的推进：软磨硬泡，三十六计轮番上
基本上都被对方领导告知其他项目优先级更高（哪怕项目初期明确当钱项目为最高优先级），似乎没有什么好的办法，项目中的自己在前期制定的各个节点之前天天去磨依赖方，自己的越级Battle能力还需要提升。
质量把控
-【重业务+编码双重走查，测试前置+异常归类，保障项目质量】-
之前其他页面模块进行Flutter重构后，无一例外的出现了上线后发现问题紧急关量，最终修修补补半年依旧存在问题。本次项目将质量把控主要分为两个方面：“业务问题”、“编码异常”，除了必要的容灾机制（新老切换）外，如何尽可能多的发现问题，尽早尽快的解决是质量把控的关键
- 每日站会、每周业务走查：主要用于把控业务进度、阻塞点、以及开发自测流程。走查的大部分主要问题均得到了改善，提高了提测质量。
- 测试前置接入，缩短联调压力：在前端主流程开发完成后，让测试介入进行主流程测试来提升最终的交付质量，提前介入也可辅助暴露一些异常问题，使前后端开发有更充足的时间去解决
- 异常走查+归类处理：在项目完全提测后，借助已存在的监测工具每日对异常进行归类、处理，对问题进行归类，处理问题是对一类问题进行处理，而不是去处理单个问题、字段、条件判断，可极大提高处理效率。
上述的三个为质量把控的大方向，不包类似每周走查时还会进行的代码抽查等方式。在项目上线后除了个别0.0x%概率的非阻塞性业务流程问题，未发现明显的阻塞性问题，让最重要、业务最复杂的模块在上线后顺利逐步开量，未出现其他模块多次返工。
隐身的........
越写越觉得有必要单独列出来吐槽一下，三言两语难以描述这个“隐身”，简单地说是“需要时不见其影，不需要时使劲给你上强度”。
- 不见其影：需要拍板决策时不见其人，躲避所有可能的风险。很多时候更借不到力，经常我一个大头兵去跟别的部门领导Battle。也是经过这些Battle能明显发现，“利弊“是永恒的论点，”风险“总是用于拒绝我这种大头兵的最好理由，因为我并不具备去承诺承担”风险“的Level，也得不到话语上的支持。每次拼尽全力去争取，逐个节点、逐个任务项的去谈，
惨胜好过投降。- 上强度：多次强制抽调人力、新增非预期功能点、总是来私聊要加什么，要我去推别的部门增加什么任务，实际会议中一言不发，或仅在大局已定时做总结性发言。多次反馈无果，导致自己加班加点熬夜去赶进度。当时的自己越级在项目群中警示风险、划分责任边界。强制抽调人力的现象在越级警示风险后稍有缓解。
总结
-【从小团队到急行军中型项目，能力要求从“技术强”过渡到“推进力+管理力”】-
以前管理的项目都是在跟前的两三个人，一两句话就能解决很多问题。这次工期被极限压缩，技术能力的考验是其次，更重要的是有序管理并推进项目、异地管理......高压状态下还得维持高强度高质量的代码输出等等。磕磕绊绊的最终顺利上线，真是烧高香了。
人员管理上，尤其是异地管理需用制度约束，用流程管理，借鉴以往的经验根据当前实际情况去调整制度细节与管理方式。对于低效人员利用各种看板，进度日报、巡检可起到部分督促作用。
策略可以讨论，拍版必须果断，讨论是思维的碰撞，在一定程度上完善策略。同时也要认识到任何策略都有利弊，没有完美的策略。在问题讨论的差不多的时候要果断拍板，让团队脱离无意义的讨论，提高效率。往大了说是管理者承担责任、能力的体现，使团队成员信任，追随，凝聚力也更强。
中大型团队与小型团队的管理差异主要体现在“抓”与“放”的程度，小型团队中的管理者只是拥有一定权限的大头兵，可以面面俱到，任何细节都去过问，去疏导谈心，争取用最优的方式去解决问题。当团队规模达到一定量级时，需要把自己从执行角色中抽出来，将重心放在推动整个团队有序前行上，即“放权”。将非团队层面的决策权下放到合适的人手中，例如某个功能具体的实现细节，某个业务细节与协同部门的沟通等等。合适的人也就意味着“识人与用人”。能够有条不紊的推进一个中大型团队前行，手底下有“可用”“好用”的成员时，管理中大型团队的最基本条件也就达成了，能够有效进行向上管理就更好了。
文中提到的还有一点，实际权力被严重限制。拥有完全贴合岗位的权利是非常理想的状态，但这次是影响到正常管理，例如默许个别开发不服从管理，得不到话语权上的支撑无法平等的与其他部门沟通等，人员配置都得不到保障随时被抽取做其他事情。似乎没有什么很好的办法，上文所说的“越级警示风险”只是为了明确责任边界，敲打上级。其本身衍生出来的很多问题都需要想方设法去解决，协调人力、任务，很多难关最终还是两个核心开发去填坑。
整个项目就是一帮东拼西凑的“乌合之众”的急行军，“急行军不是春游！如果有人跟不上、捣乱，可以尝试去拉一把，拉不动就不要再对其投入精力，挡住了大部队就得快速抬到路边”。过程中，自己作为主要开发及名义上的项目管理者有些方面做的并不好，一心只在让项目保质保量的上线，需要提升的地方还有不少，算是对自己的综合抗压能力的一次检验。
回想起多年前还是学生的我在一个饭局上听着一位管理着数千人公司的远房亲戚说道：“管理者有三道坎：10个人，50个人，100个人，每道坎面前管理者都必须进行自我涅槃，管理能力是一方面，重要的是心态。”
以自己目前的经验总下下来：
小团队：执行到位+决策统一
中团队：授权合理+分工明确+拍版果断
大团队：识人用人+风险兜底
吐槽
-【高强度开发下心理与生理双重透支，需要管理反思与边界建立】-
成文的过程中，仿佛又回到了当时那个一天十二三个小时精力高度集中的时候，一边高强度代码，一边推动项目进展，天天被施压、砍时间、跟不同的人唇枪舌剑，每天一堆乱七八糟的事情，不忍细想。
不建议在实际工作中被逼迫到如此境地，连睡觉都无法保证的长时间高强度劳动下，不仅会降低效率、增加错误风险，给身体造成非常严重的负担，项目后期基本上都是边吃药边加班...真的是拿命在拼。缓了几个月才缓过来，也终于想通了：
拼命打工难致富，身体是一切的基础
