第一版上线后，研发团队可以做什么？ 举报 理由 举报 取消 创业公司，产品第一版上线后，此时产品经理在收集真实的用户需求，在这个时间段（或许1-3星期），研发团队可以做些什么呢？因为马上就有真实需求了，所以不想安排开发任务，但是研发人员又不能闲着。开发用户数据统计功能，或是后台管理功能？（开发这些不涉及用户需求的功能？）或者是改剩下的不重要的BUG，或是优化体验细节，或是优化代码？ 2018年2月21日 10 条回复 1905 次浏览 互联网创业,产品研发,项目管理
回复 ( 10 )
从题主描述来看，做的是面向新需求的产品。因为如果是成熟的产品形态，通常后续开发的内容大致上都会有规划。
那么研发团队在首个产品上线之后做什么，取决于你采用的是哪一种开发模式。不科学的是 incremental（增量），更为正确的是iteration (迭代)：
看起来都能达到最后的结果，但普遍意义上说，下图才是敏捷开发想要的结果。因为前者不到最后无法了解系统全貌，而在后者情况下，产品方向清晰，并且随着迭代进行越来越清楚。
当然，如果你做的产品比较复杂，刚开始再怎么简单搭建都要花很多时间，有另一张常见的图来解释：
和上一张图想表达的意义相同，但下半部分表达得更清晰，一开始做的是滑板，接下来是自行车，然后是摩托车、汽车。虽然同样都是通过每次发布来了解客户需求，再调整方向。但最大的不同是每次都交付了完整产品，对用户有价值。
如果采用的迭代模式科学，那么在首个版本上线后并且bug修复完成时，这个阶段正好适合让整个产品开发设计团队一起来参与产品规划，人人都做一回“产品经理”，可以一起探讨后续的产品功能列表，分析优先顺序及可能会产生的问题；探讨目前的产品有哪些优缺点、风险为何；与竞争对手产品同时使用，看功能上是否能胜出；观察了解产品运营数据等。
此外，不管是什么开发模式，在空闲期间都可以发动大家去接触用户，让员工做不同的角色扮演，扮演不同的用户角色并思考他们的需求，之后再接触实际的用户反馈。这可以让开发人员更能体会用户的状况。之前我开发游戏的时候，到产品上线测试时产品通常已经成形，这个阶段已经不能算标准的敏捷开发，通常上线之后，几乎所有成员都会加入到玩游戏的过程当中，不完全是为了测试bug，更多是作为普通玩家身份在体验。
任何产品或服务的用户都可以分成三种：第一种根本没听说过你的产品；第二种听说了你的产品但没用；第三种听说但不想使用。对于创业公司来说，大部分工作都应在前两种用户身上发力。第一种用户，无非是增加产品曝光。但针对第二种用户的办法比较复杂，但同时也存在着无数的机会，需要更深入地了解这类用户，包括他们是怎样看待和体验产品的流程。
其实对于创业公司而言，所有成员的目标都应该是一致的：想办法让更多的人使用我们的产品。不需要把产品人员和其他员工隔离开，对产品有更深认识的技术人员通常会更愿意分享想法，以帮助证实某种需求并且更加积极地参与开发。
而且这是营造公司文化的很好方式。我见过一家技术团队创业的公司，一般来说这种团队往往存在风险。技术工程师常被认为忽视市场或是太有个性，而且是不容易协作。但这家公司从创立开始，永远都是一群人在一起讨论事情、解决问题，从上到下融洽无间地沟通。后来在多次市场起伏中这个公司也逐渐成长，不知不觉之间培养了一种无坚不摧的团结文化、上下密切沟通的文化，最后取得了很不错的成绩。
无论以上这个案例是否放之四海而皆准，不必死守“按职能划分工作内容”这一点，不光可以解决初版产品上线时的空闲期，长远来看也是非常有价值的。
这么“功利”的问题，从一个创始人，或者管理人员脑子里跑出来，比较“心寒”，忍不住要说几句。
产品上线，“研发”的工作告一段落，接下来的工作，就是“运维”，日常运维的工作量不会“小”到题主认知里的“白拿工资”，只是没有“研发”那么废脑子。
运维工作繁琐到让人想死，监控产品、故障处理、产品性能优化 、数据库管理、程序bug等问题制定处理、没有什么可处理的也得有个预案，反正工作量多到你难以想象。个人经验而言，比起“运维”很多程序员更喜欢“研发”，题主居然认为人家“居然要占公司便宜了”。
即便是“什么都不干”，难道不应该？送人家出去旅游，修养，都是应该的。“人才保养”比“人才培养”更重要。
难道一定要是“飞鸟尽，良弓藏；狡兔死，走狗烹。 ”这种剧情剧情才好看？
啥话不说，就是干！
其实研发来说永远都不会闲下来，莫不说第一版在开发过程中遗留下来的小 Bug 和为保证进度临时砍掉的需求，上线后在用户的真实环境下也会暴露出来一些 Bug，还是需要及时修复的。
另外包括题主所说的用户数据统计功能或者后台管理，这虽然不涉及用户需求但是需求依然要产品经理来提，也不是研发团队可以自己来做的。
类似的不涉及用户需求的也有很多要做，一个是优化效率（优化无止境），一个是做好基础架构（包括一些前后端的数据分析、错误收集等），还有就是可以做一些诸如整理代码规范、补充测试的工作（我们团队中就对测试这一块缺了很多）。
技术探讨与分享，休息。
举杯同庆，放假三天
三天后满血投入工作
汇报并研讨目前的架构方案
人尽其言
分析其存在的问题
包括未察觉的隐患和临时的应付方案
制订优化方案及预案
结合新的需求
讨论新版计划
尽量让全员参与
让他们体会到张弛有序和参与技术决策的乐趣
让开发人员的灵魂都为你工作
当然，如果你想做个短视的老板可以这样做
继续加班，不准懈怠，加强考勤
产品上线关你们猴子鸟事？
抓cto闭门做好技术规划
规划好了猴子们上
别唧唧歪歪，强制执行，按代码行考评。。。
产品的需求讨论、技术方案讨论关你们猴子鸟事？
公司赚不赚钱关你们猴子鸟事？
改bug。
一般上线运行后就会发现一堆问题，然后玩命改，等功能模块基本上都被用过了之后，程序差不多就稳定了。接下来就是无穷无尽的需求变更，开发团队是不会空闲的。
先休息休息，然后显然是优化代码和重构等，代码架构好了，下次需求来了的时候完成需求才能更【快准狠】。
一直没有重构过的代码，怎么走可持续发展道路，怎么建设中国特色社会主义和谐社会。
准备好被辞退，参考X格。。。。
为啥会有这种问题，难道不是上线之后会发现一堆bug吗？以及会发现各种蠢哭的设计和实现上的大坑。
有时候上线之后才是真正开始作死的时候到了。当然了，你也可以说，这是技术太挫导致的，但是须知现实总是不那么美好的。
第一版后面还有300个版本，你确定现在就干掉他们？