这篇文章只是提出一个运营上的模式，只是我个人经验总结而来的，仅供参考。从技术角度看向研发的管理，无非是要使制定一个计划保证研发的必要性和可行性，过程能够被量化，并确保最终结果合乎期望。下面是一个我认为研发最开始的时候应该要清楚的几个关键点，这些也可以作为一个立项模板来填写
问题定义
至少能够给出需要解决的问题的定义并说明必要性，这里一般是研发的，时间线会比较长的问题，例如说上个赛季从比赛结果来看我们出了什么问题。一般也不能是太广的问题例如所有机器人的稳定性，而是稍微的具体问题例如我们在与某个学校的比赛中因为机动性不足而处于劣势，因此需要提升步兵机器人的机动性，而后我们可以思考如何衡量机动性这一指标并给出解决方案。又或者说我们发现我们的阵容不足以击败一些强队，需要一台平衡步兵等。当然这里说明必要性也可以给出量化的指标，增强说服力。
需求分析
实际测试
这部分更像是我们说的调研，即搞清楚现状。以机动性为例，我们能够测试的指标有运动速度，到达场地某点的运动时间等。这些参数也可以与其他学校比较，方便了解我们目前仍然存在哪些不足之处。
临界情况
临界情况是指以我们目前的技术水平，现实物理世界规律的约束和当前规则体系下我们所能达到的极限，这个地方是用来尽可能列举条件，用于划分清楚哪些是我们不可能做到或者需要付出所有人无法承受的代价才能做到的，当然可能一些是违反物理规律的，将这些排除掉之后，剩下的才可以知道哪些是非常有机会能够改进的，这个研发计划才具有可行性。
已有参考
这个相对而言简单一些，就是前人的一些已有工作，在比赛里就是开源或者分享会的一些内容。一方面是能够了解当前这个比赛的实际水平，另一方面为现在这个研发提供一定的技术方案参考。通常即使我们自己想出来一个方案，也需要看一下其他人的方案，确定我们自己想的方案与主流相比如何。
需求结论
这个结论用于总结上面三点的内容，即敲定真正的需求。实际测试确保这个问题的确存在于现状中，临界情况确保解决方案的可行性而不是完全脱离现实，已有参考则是保证最终的研发结果合乎主流或者超越主流性能。这三步之后我认为大部分人能够搞清楚我们到底需要什么样的逻辑/功能/模块/结构，来解决一开始提出的问题。
量化参数
这部分是拿来给计算的时候用的，对于某些设计可能不需要，结合边界情况的一些数据至少能够给出一个相对合理的量化指标。例如在超级电容的设计内，这部分的内容就是描述电源输入输出要求，功率等参数，在最终电路设计中就可以根据这些参数选择合适器件，最终设计出成品。
方案选择
方案选择更像是电子设计大赛里面借鉴过来的东西，在这里我认为至少完成研发至少有两到三个方案，大部分情况会更多。如果你只看到一个方案，那么就应该重新再考虑上面实际测试，临界情况，已有参考三项的内容是否足够完善。
测试计划
这里解决的是完成研发的条件和评定研发结果质量的方法，即做到怎么样才算是完成了，怎么样的结果才是好的结果。通常最终的目标是显而易见的，但是将这个目标拆分成多项可实际操作的，可量化的指标就是测试计划的内容了。以平衡步兵为例，如果只是测试直立平衡的稳定性的话就已经可以写出一大堆的测试了，包括受撞击后的稳定性，跌落后的稳定性，飞坡后的稳定性等。这些指标在没有做出来前就应该被制定，后面的进度安排也会更好做。