24 年我做了一个创新性项目，从年初的第一行代码到现在，项目已成功打通，并在市场上得到了验证，也获得了盈利，明年就开始做增量和平台化。
我在四年多时间一共做了四个项目的探索，这是我近些年第一个做成的项目，昨天在复盘的时候我在想，如果当时做到哪些，可以让项目发展的更好，这篇文章是我的感悟。
人员结构
在整个周期中，最大的困难是既要写代码、想实现方案、技术选型，也要做决策，和运营反复分析、拉扯方向、目标、细节，这导致精力完全不够，两头都顾，但两头都做的不够好。
如果我能力够强，能够完美兼顾两边，那当然最好，可惜我没强到那个地步，真正做决策是很难，这要求不仅有技术实现方案，还有对业务有绝对深度的理解，要有产品思维、流量思维、商业逻辑，对业务有前瞻性，对行业有经验和理解。
否则就会陷入到运营说什么，研发做什么，然后运营一直改，研发同步改，搞到后面，研发崩溃，创新性项目和普通项目相比，需求更多更杂，不确定性更多，但需求这样天天改，没人受得了。
所以需要一个做决策的人，把控整体，为什么研发适合？因为研发懂技术实现，剩下的流量思维、产品思维、商业模式那都是可以短期学的，或者聊一下就懂个大概，但指望运营短时间理解技术，非常困难，他们只会问为什么不能上线，而不管怎么实现。
我的解决方案是加大研发资源，一个人负责把精力重点放在业务和技术实现方案，其他人负责细节实现。
研发负责人平衡需求准确性和业务迭代。
拆解目标
这是保证需求准确性的具体方法。使用目标五要素：做什么、为什么、做到什么程度、截止时间、资源。
运营有天说要做个活动，好，那就分析一下做活动的目的，比如拉新、复购、日活、冲 GMV 等。
分析了一通运营说，我全都要，那说明没分析到具体问题，继续分析，万一真有拉新、日活都要的情况，那就要以这两个目标接着拆分。
假设最后得出的结论是，要做拉新和日活。
那先来分析拉新，如果目标是拉新，有没有别的实现方案？比如直接买流量，或者做裂变，对比不同方案，找出最合适的。拆分日活目标也是同理。
现在对比了各种方案，发现活动是最合理的，要以做活动为目标。
那要做到什么程度？是给潜在用户发推广短信，还是要搞个双 11 规模的？确定具体事项、目标边界。
然后再看要达成这个目标，有多少资源，估算的上线时间，和运营期望的是否相符？
如果不符合，研发就解释下为什么要这么久，具体的实现方案，让运营理解研发的工作量。
要是项目有期望的 DDL，再看怎么配合协作，要么砍功能，要么加资源。
这里不能为了快速上线，过于牺牲代码质量，否则后续踩雷了，真心难受。
沟通汇报复盘
上面说的是具体拆解方法。在实际工作中，目标总会变的，尤其是创新性项目，变化之大超乎想象。
这时研发负责人要保证写代码的人不能被打扰，和运营重新拆解目标。
在重新确认目标后找项目总负责人过一下，一般是大老板，做好汇报。
运营汇报以数据为主，每个目标执行后，有没有达到预期的效果，为什么没有，下次怎么优化，方向对不对。
研发汇报以进度为主，可以重点说说达成了哪些里程碑，做到了什么阶段，现在目标是什么，攻克了什么困难。
毕竟研发和运营讨论出来的方向不一定和老板想的一样，所以要和项目负责人同步，如果有不同看法，那就拉着重新拆解目标。
这里重点要保护核心写代码的成员，不能被太多杂事打扰，分工协作，效率翻倍。
即使目标改变，研发负责人做好方向和架构，再重新交写代码的成员开发。
如果我早点能意识到这点，也许我没那么累，效率也更高。
代码重构
在需求不多的空闲期，一定要及时重构代码。
即使做到上面说的，也会有非常紧急的场景，突然来个明天要上线的需求，或是之前目标还是变了，代码写一半强行扭转。
我回顾自己写的代码，很多逻辑自己都不记得，改动一个地方会影响到哪些，也不清楚，这就是没有做好重构和梳理。
重构除了处理废弃代码，还要对业务核心逻辑，一遍又一遍梳理，直到记住每一个场景的流程，每一个操作的细节，做到这个程度，基本上不会有 bug。
这个很难，而且还在一直迭代，对记忆力要求也挺高的，算是道坎吧。
好了，以上就是我的感悟，加油，共勉。