因工作原因，近期笔者以相对偏IC的身份，牵头一个两个team共建项目的产品研发工作。在这个过程中，笔者也简单积累了一些IC工作的经验，踩了些坑，也有一点阶段性成果。这篇文章就根据自己经验聊聊作为IC角色，怎么去把控整个产品研发的规划和节奏，给一些实战当中的Tips。
整体来看，首要任务是了解自己角色需要做些什么去推动整个项目运作，其次是拆分任务确定哪些先做哪些后做，最后才是做技术实现，每一步都把最关键最优先的成果做出来。
IC的角色和一般的后端开发，以及和带实线管理职责的技术或者业务架构师，职责上都有区别，也许和搞开源会比较类似。首先在后端开发基础上，IC需要承担产品效果评估、需求拆解、架构设计之类相对宏观的工作，其次在管理上IC偏虚线，甚至是无管理职责做跨部门沟通，因此比起管理更多依赖协调方面的技能。
所以综合来看，要推动整个项目运作，首先需要从自己角度出发，对项目的里程碑有自己的理解，然后再和队友做讨论，看每个时期需要实现怎样的产品形态，确定一个个子目标。其次就是做技术架构设计和演进方案，看怎样的技术方案能够满足产品的演进，兼顾各方的利益。最后才是技术实现，最好的形式是1到2人主导整个架构，每个模块保证不同人负责，且考虑到一般IC在虚拟小组，整套代码架构最好也有明确的研发约束，保证大家的研发行为趋近一致，避免重构成本。这样从宏观来看，整个项目要做的事情和每个时期的交付都有预期，每个人也能够持续逼近自己的目标，保证各方的生产效率。
这里一个关键点是，比如跨团队协作，每个团队的利益、做事风格和职责节奏都不一样，如果需要做些什么的话，最好要找到自己的价值点主动补位，比如你负责业务开发和基础架构对接，那么你就可以去主导业务部分的产品逻辑和模块设计，因为基础架构同学对这部分不甚了解，不然研发效果就越来越偏，如果你是基础架构方，那么就可以去主导整个微服务架构跟三方依赖的设计，因为业务同学通常是依赖使用方，对于基础架构很多潜规则也不会很了解，所以这部分让基础架构的同学实现合适。
其次是做任务拆分。在笔者的工作环境，会经常遇到同一时刻被很多人很多事推着走，如果对这样的现状没有很好应对的话，那么一是很容易内耗导致身心问题，二是项目进度无法推进。解决的办法就是打太极，化被动为主动，既然面对很多事情，那就把这些事情全部记录下来，然后结合自己项目的需要，自主决定哪些先做，哪些后做，哪些先要出结果，哪些要长期治理。如果要实现产品MVP，那么产品MVP必须的技术组件必须放在前头，用户的具体需求要靠后，不然自身难保；如果要快速拿业务结果，那么用户需求要放在前头，技术优化和稳定性巩固放在后头，先把业务跑起来再做重构优化，先60分再80分。
当然，实际场景下可能会更加复杂，这里主要强调的点是，对于任务如何拆分，怎么依赖，实现先后，时时刻刻都要有自己的把握，均衡好人力和产品效果。同时技术上重要的是，结合自己的技术经验，设计一套强确定性的代码架构，长期让更少的精力投入到代码研发上，这样才会有更多的精力去成事。
最后就是技术实现。这里的技术实现不仅仅是研发交付就完成了，作为主导产品研发的角色，研发内容提测、灰度和上线过程，相对于普通开发都需要做更多的干预，保证产品最终的交付质量。相对于事情推动和拆解来讲，技术怎么实现也许是对于IC来讲最不重要的部分，但技术毕竟是产品的血肉，交付质量肯定要去保证的。所以一个残酷的点是，如果要做好IC，那么前提是你在技术实现方面已经形成了成熟的肌肉记忆，有能力去无脑实现很多东西，这样就能把更多的精力放到宏观的事情上。否则，还是建议考虑其它的角色。