前言
对于程序员来讲，很多时候会纠结一个问题，我做了这么多项目，除了上线了产品，自己的逻辑、对产品的设计进步了哪些，这一点对前端、后端其实都是一样的具有迷惑性。
对于技术人员本身来讲，除了项目经验，技术的沉淀以及对技术的把控是一个程序员的命脉，但对公司来讲，产品功能和用户需求才是公司的命脉，看似矛盾的两方该如何抉择呢？
基本观点
完成产品需求是必须做的，最优先做的
- 如果说某个产品的某个需求是紧急的，必须上线的，那么无疑整个研发团队都要放下手里其他的工作，把这次的需求完成。但这只是非常规的意外情况，而不是或者不建议是产品的常规开发状态。
- 常规的需求一定是按照合理的迭代或者开发流程，每一步严格把关、验证、回归，基于评估，在充分且稍宽裕的周期内完成的。而且在需求完成之后，需要需求发布评审、项目复盘、分析整个过程的合理性等。
- 在每次的迭代需求之间，需要一定的间隙时间用来给各个职能做缓冲时间，这个缓冲时间用来：
- 身心的休息
- 下次迭代的准备
- 需求的相关性以及优先级在排序
业务开发与技术研发必须分开
- 为什么要分开？ 因为你的常规业务开发中总会遇到不同的技术问题或者技术瓶颈，而对于某一特定的需求其解决方案在一段时间内是固定的，所以如果我们拿出一定的人力时间去固定的做较难需求、定制需求的攻关，那么我们对需求的解决方案会更加固定、方案更加成熟、对需求的把握会更加精准，业务的开发进度也能够尽可能的忽略技术的延期风险，尽量的在目前的技术方案允许的情况下设计合理的需求。
- 分开之后的职责划分 技术研发：1 作为公司的高端技术储备，为公司未知以及已知有技术难度需求的部分进行技术的预调研和调研；2 为公司的整体项目代码的规范性，科学性，模块化，业务的解耦以及耦合提供合理的方案； 3 为业务开发的同学提供高质量可用的工具或者工作方式，尽量的向工程化、自动化靠拢 ；4 对目前市场的主流实行技术进行研发，引导产品的交互或者功能优化。 5 实现技术布道，为广大的程序员谋求技术福利、技术学习和成长空间 业务开发：1 针对需求使用公司已有的技术栈、研发同事的技术成果、自己的技术栈进行具体业务的开发 2 对具体需求的完成、上线、bug直接负责 3 及时向技术研发反馈技术需求
- 技术研发出现的场景 场景一 ：产品需求的强制及时的需求 场景二：开发效率的提升 场景三：技术架构已经不能支撑目前的业务量 场景四：开发流程的不合理，原有框架的重构 场景五：作为公司的技术储备，用来应对以后未知和已知的技术需求
- 技术研发与业务开发的比例 一般的建议是2:8 ,当你的团队成员超过10的时候，建议其中1-2个人全职去做技术研发的部分，或者重点关注架构。
- 业务开发与技术研发需要细分 业务开发需要区分具体的业务线以及业务线负责人，方便进行交接、串联设计、总体设计。业务开发需要按照计划或者版本进行。 技术研发需要针对不同的技术需求和业务需求列不同的技术专题，针对每个专题列出可用产物，针对日常研发以及里程碑研发列出相关的计划。
什么样的人可以从业务开发转到技术研发
- 首先技术研发必须有两年到三年的业务开发经验，然后技术研发必须有跨职能的全方面常识，其次对自己擅长的领域的多个细分领域有深刻的研究和实践，技术等级能达到阿里p5最少，对架构设计有雏形的认知和长久的规划。
- 业务开发分初级以及高级，初级的进行基本的业务开发，如果达到一定等级和经验积累可以负责业务线，与技术研发属于不同的晋升路线，不存在高低之分。
产品与技术必须信息同步
- 产品规划同步
- 技术能力同步
- 对专业概念认知同步
- 相关的开发资源以及设计资源同步，时间吻合
流程以及规范
- 规范的项目开发流程必须不断的进行贯彻执行，有优化的必要就要优化
- 代码规范以及技术方案必须进行布道，进行文档化
其他
如果你对研发与开发，或者其他角度有更好的建议，欢迎讨论哦。
