Open hunter-ji opened 9 months ago
设想一个场景：
你作为一个程序员，听着攒劲的小曲，写着优雅的代码，加班加点终于写完了迭代中分配的模块需求。然后你跟别的同事一联调，却发现各种问题。
你跟同事A说：“你得在这种情况下给我数据A。“
同事A一脸懵逼：“这种情况需求也没写啊，在这种情况下我也没有数据A啊！“
然后你和同事A一起顺着业务流程，找到了负责上层模块的同事B。
同事B一脸懵逼：“这个迭代中我没有这个模块的开发需求啊，这种情况下我也没有数据A啊！”
然后你和同事A、同事B一起顺着业务流程，找到了负责上层模块的......
最后，你和同事ABC...一起找到了产品，产品一脸懵逼：“那没办法，就改需求吧......”
你眼看着所剩无几的迭代时间，生无可恋地掏出手机，发个微信取消了这周末的相亲...
不知道程序员xdm有没有经历过这样的场景，如果各位程序员xd没有经历过这样的场景，那真的是恭喜你了，且行且珍惜！从毕业后参加工作开始，我是真的经历太多了，太痛了！
我之后不断学习各种方法，尝试去破解这样的困局。虽然说，工作中的问题很多，但是能解决一个是一个，后面再慢慢跟各位分享其他问题中我的解决方案。
所以，本篇文章将分享一波关于这类问题我的解决方案。谨代表个人主观观点。
需求是用户的痛点，但是在这个场景下，是程序员的痛点...
那么，仔细分析一下，这个场景下的痛点，到底是什么呢？我认为是如下三点：
当然，可能有程序员xd会疑问：这种问题不是靠严谨的开发流程就可以避免吗？
理论上来说是这样的，但是以我个人经历而言，不管是大团队还是小团队，总有很多不稳定的因素，比如说迭代周期、协作流程的规范性等等。
特别是在创业团队，或者有些项目特别着急的时候，经常是没有足够的时间给到团队的各个角色去充分准备的，甚至为了赶时间，会精简一些环节甚至直接去掉。这种时候出现这种问题导致改需求，往往是非常可怕的，后果也往往是开发团队加班。
我目前发现且实践后效果较好的方案，就是“曳光弹式开发”。
经常关注军事的小伙伴儿，应该了解，曳光弹是一种运用于军事场景的特殊子弹。
我们都知道武器发射时需要瞄准，比如枪就通过照门和准星来瞄准，而坦克和装甲车以及飞机都有专用的瞄准具，非常复杂。对于轻武器来说，一般攻击距离都比较近，使用自带的机械瞄准具或者外加的光学瞄准镜都足够，但是在距离稍远的时候瞄准镜显然不够。而对于飞机和战斗机来讲，在空中飞行时飞行姿态变化多样，有时候进攻的时间很短，需要快速射击并且调整弹道，这时候就需要可以发光的曳光弹。
曳光弹正如其名，可以发光而且指示弹道。曳光弹的结构比一般子弹更加复杂。子弹的弹壳部分和一般子弹一样，前半部分是钢心或者铅心的弹头，但是在后部有一个空腔，一般称作曳光管，里面填充着曳光剂。曳光剂的成分还比较复杂，一般来说主要成分是镁粉和铝镁合金粉，用来燃烧，除此之外还有硝酸锶。这样一来，燃烧的时候硝酸锶就会发出红光。大家平时看到的很多曳光弹还有黄光和绿光，加入钠盐就会发出黄光，而加入铜盐就会发出绿光。除此之外还在表面加入一层过氧化钡，以保证曳光剂被点燃。
对于机枪手来说，如果射击距离较远，自然不能选择过于精确的设计方式，也就是说不能靠瞄准具来射击。而一般的机枪主要起压制和面杀伤作用，加入曳光弹就是机枪手更加快速方便的控制弹道，随时变化攻击的方向。如果没有曳光弹的话，射手根本无法发现自己的子弹弹道，也就很难去调整弹道。毕竟枪械射击温度升高之后，弹道会有所变化，不同的弹药不同的枪管也都会改变子弹的弹道，如果仅仅依靠枪械自身的瞄准具去调整反而会适得其反，而曳光弹就很好的解决了这个问题。
理解曳光弹本身在军事中的作用后，我们再来看曳光弹式开发如何在开发中起作用。
开发团队在接手到产品给到的业务需求后，特别是构建一些以前从未做过的东西时，对这个产品/功能的最终成效是模糊的。
程序员就像坦克上的机枪手一样，在尝试在黑暗中击中目标。但是如果像文章一开始的时候，大家先埋头写自己的模块，然后再联调，最终发现问题，感觉就像一上战场，大家都朝着各自理解的方向拼命清空弹夹，击中目标的寥寥无几，最后受伤的还是自己。
所以，此时，就需要先使用几颗曳光弹，去击中目标，在黑暗中划出轨迹，开发团队再调整方向，对着目标集中火力。
非常简单！步骤如下：
这样，射出一颗曳光弹，穿透客户端、后端、数据库、运维、测试等不同层面。一旦击中目标——即符合用户需求，后续的任务便大都是搬砖的活儿，去丰富这个骨架。
曳光弹并不是总能击中目标的，中途若是发现未能击中目标，便可在前期以极小成本去调整曳光弹的方向，继续发射曳光弹。
如果你要问，什么是“最基础的完整功能”，那么可以这么说，那么举个例子：前端不要任何样式，直接能够满足比如表单功能即可，后端不用任何校验，能够处理和传递数据即可。
为了解决文章开头的问题，需要使用曳光弹式开发，先开发一个骨架，确认满足需求后，即可继续丰富骨架，完成产品。
作为团队的一员，团队的每一个角色都很重要，程序员跟产品也是需要紧密协作，互帮互助，才能使得产品更好，也使得业绩更好。
一. 前言
设想一个场景：
你作为一个程序员，听着攒劲的小曲，写着优雅的代码，加班加点终于写完了迭代中分配的模块需求。然后你跟别的同事一联调，却发现各种问题。
你跟同事A说：“你得在这种情况下给我数据A。“
同事A一脸懵逼：“这种情况需求也没写啊，在这种情况下我也没有数据A啊！“
然后你和同事A一起顺着业务流程，找到了负责上层模块的同事B。
同事B一脸懵逼：“这个迭代中我没有这个模块的开发需求啊，这种情况下我也没有数据A啊！”
然后你和同事A、同事B一起顺着业务流程，找到了负责上层模块的......
最后，你和同事ABC...一起找到了产品，产品一脸懵逼：“那没办法，就改需求吧......”
你眼看着所剩无几的迭代时间，生无可恋地掏出手机，发个微信取消了这周末的相亲...
不知道程序员xdm有没有经历过这样的场景，如果各位程序员xd没有经历过这样的场景，那真的是恭喜你了，且行且珍惜！从毕业后参加工作开始，我是真的经历太多了，太痛了！
我之后不断学习各种方法，尝试去破解这样的困局。虽然说，工作中的问题很多，但是能解决一个是一个，后面再慢慢跟各位分享其他问题中我的解决方案。
所以，本篇文章将分享一波关于这类问题我的解决方案。谨代表个人主观观点。
二. 痛点
需求是用户的痛点，但是在这个场景下，是程序员的痛点...
那么，仔细分析一下，这个场景下的痛点，到底是什么呢？我认为是如下三点：
当然，可能有程序员xd会疑问：这种问题不是靠严谨的开发流程就可以避免吗？
理论上来说是这样的，但是以我个人经历而言，不管是大团队还是小团队，总有很多不稳定的因素，比如说迭代周期、协作流程的规范性等等。
特别是在创业团队，或者有些项目特别着急的时候，经常是没有足够的时间给到团队的各个角色去充分准备的，甚至为了赶时间，会精简一些环节甚至直接去掉。这种时候出现这种问题导致改需求，往往是非常可怕的，后果也往往是开发团队加班。
三. 解决方案
我目前发现且实践后效果较好的方案，就是“曳光弹式开发”。
1. 什么是曳光弹
经常关注军事的小伙伴儿，应该了解，曳光弹是一种运用于军事场景的特殊子弹。
我们都知道武器发射时需要瞄准，比如枪就通过照门和准星来瞄准，而坦克和装甲车以及飞机都有专用的瞄准具，非常复杂。对于轻武器来说，一般攻击距离都比较近，使用自带的机械瞄准具或者外加的光学瞄准镜都足够，但是在距离稍远的时候瞄准镜显然不够。而对于飞机和战斗机来讲，在空中飞行时飞行姿态变化多样，有时候进攻的时间很短，需要快速射击并且调整弹道，这时候就需要可以发光的曳光弹。
曳光弹正如其名，可以发光而且指示弹道。曳光弹的结构比一般子弹更加复杂。子弹的弹壳部分和一般子弹一样，前半部分是钢心或者铅心的弹头，但是在后部有一个空腔，一般称作曳光管，里面填充着曳光剂。曳光剂的成分还比较复杂，一般来说主要成分是镁粉和铝镁合金粉，用来燃烧，除此之外还有硝酸锶。这样一来，燃烧的时候硝酸锶就会发出红光。大家平时看到的很多曳光弹还有黄光和绿光，加入钠盐就会发出黄光，而加入铜盐就会发出绿光。除此之外还在表面加入一层过氧化钡，以保证曳光剂被点燃。
对于机枪手来说，如果射击距离较远，自然不能选择过于精确的设计方式，也就是说不能靠瞄准具来射击。而一般的机枪主要起压制和面杀伤作用，加入曳光弹就是机枪手更加快速方便的控制弹道，随时变化攻击的方向。如果没有曳光弹的话，射手根本无法发现自己的子弹弹道，也就很难去调整弹道。毕竟枪械射击温度升高之后，弹道会有所变化，不同的弹药不同的枪管也都会改变子弹的弹道，如果仅仅依靠枪械自身的瞄准具去调整反而会适得其反，而曳光弹就很好的解决了这个问题。
2. 在开发中的作用
理解曳光弹本身在军事中的作用后，我们再来看曳光弹式开发如何在开发中起作用。
开发团队在接手到产品给到的业务需求后，特别是构建一些以前从未做过的东西时，对这个产品/功能的最终成效是模糊的。
程序员就像坦克上的机枪手一样，在尝试在黑暗中击中目标。但是如果像文章一开始的时候，大家先埋头写自己的模块，然后再联调，最终发现问题，感觉就像一上战场，大家都朝着各自理解的方向拼命清空弹夹，击中目标的寥寥无几，最后受伤的还是自己。
所以，此时，就需要先使用几颗曳光弹，去击中目标，在黑暗中划出轨迹，开发团队再调整方向，对着目标集中火力。
3. 如何应用
非常简单！步骤如下：
这样，射出一颗曳光弹，穿透客户端、后端、数据库、运维、测试等不同层面。一旦击中目标——即符合用户需求，后续的任务便大都是搬砖的活儿，去丰富这个骨架。
曳光弹并不是总能击中目标的，中途若是发现未能击中目标，便可在前期以极小成本去调整曳光弹的方向，继续发射曳光弹。
如果你要问，什么是“最基础的完整功能”，那么可以这么说，那么举个例子：前端不要任何样式，直接能够满足比如表单功能即可，后端不用任何校验，能够处理和传递数据即可。
四. 总结
为了解决文章开头的问题，需要使用曳光弹式开发，先开发一个骨架，确认满足需求后，即可继续丰富骨架，完成产品。
作为团队的一员，团队的每一个角色都很重要，程序员跟产品也是需要紧密协作，互帮互助，才能使得产品更好，也使得业绩更好。