第一版上线后,研发团队可以做什么?

理由
举报 取消

创业公司,产品第一版上线后,此时产品经理在收集真实的用户需求,在这个时间段(或许1-3星期),研发团队可以做些什么呢?因为马上就有真实需求了,所以不想安排开发任务,但是研发人员又不能闲着。开发用户数据统计功能,或是后台管理功能?(开发这些不涉及用户需求的功能?)或者是改剩下的不重要的BUG,或是优化体验细节,或是优化代码?

2018年2月21日 10 条回复 1987 次浏览

回复 ( 10 )

  1. 孙志超
    理由
    举报 取消

    从题主描述来看,做的是面向新需求的产品。因为如果是成熟的产品形态,通常后续开发的内容大致上都会有规划。

    那么研发团队在首个产品上线之后做什么,取决于你采用的是哪一种开发模式。不科学的是 incremental(增量),更为正确的是iteration (迭代):

    看起来都能达到最后的结果,但普遍意义上说,下图才是敏捷开发想要的结果。因为前者不到最后无法了解系统全貌,而在后者情况下,产品方向清晰,并且随着迭代进行越来越清楚。

    当然,如果你做的产品比较复杂,刚开始再怎么简单搭建都要花很多时间,有另一张常见的图来解释:

    和上一张图想表达的意义相同,但下半部分表达得更清晰,一开始做的是滑板,接下来是自行车,然后是摩托车、汽车。虽然同样都是通过每次发布来了解客户需求,再调整方向。但最大的不同是每次都交付了完整产品,对用户有价值。

    如果采用的迭代模式科学,那么在首个版本上线后并且bug修复完成时,这个阶段正好适合让整个产品开发设计团队一起来参与产品规划,人人都做一回“产品经理”,可以一起探讨后续的产品功能列表,分析优先顺序及可能会产生的问题;探讨目前的产品有哪些优缺点、风险为何;与竞争对手产品同时使用,看功能上是否能胜出;观察了解产品运营数据等。

    此外,不管是什么开发模式,在空闲期间都可以发动大家去接触用户,让员工做不同的角色扮演,扮演不同的用户角色并思考他们的需求,之后再接触实际的用户反馈。这可以让开发人员更能体会用户的状况。之前我开发游戏的时候,到产品上线测试时产品通常已经成形,这个阶段已经不能算标准的敏捷开发,通常上线之后,几乎所有成员都会加入到玩游戏的过程当中,不完全是为了测试bug,更多是作为普通玩家身份在体验。

    任何产品或服务的用户都可以分成三种:第一种根本没听说过你的产品;第二种听说了你的产品但没用;第三种听说但不想使用。对于创业公司来说,大部分工作都应在前两种用户身上发力。第一种用户,无非是增加产品曝光。但针对第二种用户的办法比较复杂,但同时也存在着无数的机会,需要更深入地了解这类用户,包括他们是怎样看待和体验产品的流程。

    其实对于创业公司而言,所有成员的目标都应该是一致的:想办法让更多的人使用我们的产品。不需要把产品人员和其他员工隔离开,对产品有更深认识的技术人员通常会更愿意分享想法,以帮助证实某种需求并且更加积极地参与开发。

    而且这是营造公司文化的很好方式。我见过一家技术团队创业的公司,一般来说这种团队往往存在风险。技术工程师常被认为忽视市场或是太有个性,而且是不容易协作。但这家公司从创立开始,永远都是一群人在一起讨论事情、解决问题,从上到下融洽无间地沟通。后来在多次市场起伏中这个公司也逐渐成长,不知不觉之间培养了一种无坚不摧的团结文化、上下密切沟通的文化,最后取得了很不错的成绩。

    无论以上这个案例是否放之四海而皆准,不必死守“按职能划分工作内容”这一点,不光可以解决初版产品上线时的空闲期,长远来看也是非常有价值的。

  2. 匿名用户
    理由
    举报 取消

    这么“功利”的问题,从一个创始人,或者管理人员脑子里跑出来,比较“心寒”,忍不住要说几句。

    产品上线,“研发”的工作告一段落,接下来的工作,就是“运维”,日常运维的工作量不会“小”到题主认知里的“白拿工资”,只是没有“研发”那么废脑子。

    运维工作繁琐到让人想死,监控产品、故障处理、产品性能优化 、数据库管理、程序bug等问题制定处理、没有什么可处理的也得有个预案,反正工作量多到你难以想象。个人经验而言,比起“运维”很多程序员更喜欢“研发”,题主居然认为人家“居然要占公司便宜了”。

    即便是“什么都不干”,难道不应该?送人家出去旅游,修养,都是应该的。“人才保养”比“人才培养”更重要。

    难道一定要是“飞鸟尽,良弓藏;狡兔死,走狗烹。 ”这种剧情剧情才好看?

  3. 徐文瑞
    理由
    举报 取消

    啥话不说,就是干!

    其实研发来说永远都不会闲下来,莫不说第一版在开发过程中遗留下来的小 Bug 和为保证进度临时砍掉的需求,上线后在用户的真实环境下也会暴露出来一些 Bug,还是需要及时修复的。

    另外包括题主所说的用户数据统计功能或者后台管理,这虽然不涉及用户需求但是需求依然要产品经理来提,也不是研发团队可以自己来做的。

    类似的不涉及用户需求的也有很多要做,一个是优化效率(优化无止境),一个是做好基础架构(包括一些前后端的数据分析、错误收集等),还有就是可以做一些诸如整理代码规范、补充测试的工作(我们团队中就对测试这一块缺了很多)。

  4. 蓝色
    理由
    举报 取消

    技术探讨与分享,休息。

  5. 白乔
    理由
    举报 取消

    举杯同庆,放假三天

    三天后满血投入工作

    汇报并研讨目前的架构方案

    人尽其言

    分析其存在的问题

    包括未察觉的隐患和临时的应付方案

    制订优化方案及预案

    结合新的需求

    讨论新版计划

    尽量让全员参与

    让他们体会到张弛有序和参与技术决策的乐趣

    让开发人员的灵魂都为你工作

    当然,如果你想做个短视的老板可以这样做

    继续加班,不准懈怠,加强考勤

    产品上线关你们猴子鸟事?

    抓cto闭门做好技术规划

    规划好了猴子们上

    别唧唧歪歪,强制执行,按代码行考评。。。

    产品的需求讨论、技术方案讨论关你们猴子鸟事?

    公司赚不赚钱关你们猴子鸟事?

  6. 杨明
    理由
    举报 取消

    改bug。

    一般上线运行后就会发现一堆问题,然后玩命改,等功能模块基本上都被用过了之后,程序差不多就稳定了。接下来就是无穷无尽的需求变更,开发团队是不会空闲的。

  7. yanyiwu
    理由
    举报 取消

    先休息休息,然后显然是优化代码和重构等,代码架构好了,下次需求来了的时候完成需求才能更【快准狠】。

    一直没有重构过的代码,怎么走可持续发展道路,怎么建设中国特色社会主义和谐社会。

  8. 吴敏
    理由
    举报 取消

    准备好被辞退,参考X格。。。。

  9. 我未成妖
    理由
    举报 取消

    为啥会有这种问题,难道不是上线之后会发现一堆bug吗?以及会发现各种蠢哭的设计和实现上的大坑。

    有时候上线之后才是真正开始作死的时候到了。当然了,你也可以说,这是技术太挫导致的,但是须知现实总是不那么美好的。

  10. 用户头像
    理由
    举报 取消

    第一版后面还有300个版本,你确定现在就干掉他们?

我来回答

Captcha 点击图片更换验证码