在产品需求确定好后,接下来就是产品研发。研发的本质是在确定一种解决问题的可行方案。

从项目流程上讲,对上完成产品的需求实现,对下为生产与市场提供可靠的产品。这个环节集中了项目的大部分风险与跨部门沟通等诸多麻烦事。产品经理、研发、测试、财务……

研发过程是个很大的不可定量型流程,不可能做到绝对最佳,只能相对优化。而对其的优化能极大的推动公司盈利流程的运转。

1.研发应参与到需求讨论中

一般研发在产品确立初期就要参与到需求讨论中,评估一些需求是否做、如何做的问题。毕竟产品的理想很丰满,但不一定能落实。另外在确定了大致需求后,后期难免会有很多需要修改调整的地方。不过也有些不懂开发的公司上需求时竟然不让研发参与评审的……

2.信息同步

接下来需求流转到研发内部,可能会被划分为若干个子模块进行。这些模块间有些是具有依赖关系的,比如上层要调用下层的接口,有的模块间要相互联调才能运行。在出问题时从直接关联模块到依赖模块一级级定位原因,每人各司其职。这种依赖分有横向依赖和纵向依赖,纵向依赖影响更加严重。

不过这样也会有点问题:很多时候上层很难确定一个问题是否是上层问题,对下层的依赖又不熟悉,这样可能导致上层耗时空转。尤其是有时下层修改了东西,但又不通知上层的时候,上层就开始抓瞎了(这就是纵向依赖)。不知道让下层在修改时,必须广播出自己的修改可能造成的影响,这个主意怎么样?起码可以引起后期排查问题时的重视吧!此称之为信息同步。

3.技术沉淀

研发大多数时候不是从0开始,而是基于现有的积累进一步开发、组合实现自己想要的功能。而这种积累就是一家公司的沉淀和核心资料。所以一家公司的研发一定要形成自己的知识库,同样的知识是非常消耗人力物力的。而且这样也能减小因员工流失产生的影响。一般一个小公司的研发团队的人员配置比例是1个架构师带2、3个技术骨干与6、7名新手。这也算是符合金字塔原理。这样即可实现技术攻坚,又可进行成本管控。而想让新人能快速参与到项目运转中来,前期整理的知识库和流程文档显然是非常有必要的。这就叫经验复用。一家公司的技术强不强,看它有没有内部的知识库大致就清楚了。

从这个角度讲,我一直觉得公司留老员工是非常有必要的,老员工知识量大、熟悉流程、更不易犯错,性价比不见得比新员工低。嗯,希望在我35岁之际,公司不要开除我!

4.接口规范

不同的程序员能力不一、编程习惯不一,这样在使用一些代码时就不会形成统一的规范,看别人代码时就会耗时。形成公司内部统一编码规范有助于解决此问题。一般研发在处理问题时,需要知道复现步骤、现象、概率、log等信息,而测试若在提交bug时标明这些信息,就可以一定程度上避免研发进行二次沟通。

良好的沟通最好是自己知道的多多益善、需要别人提供的信息越少越好,这样就只需弄清别人提供的关键节点即可;另一方面在向别人传递信息时宜把对方当傻瓜,把详细流程写清楚,这样避免对方理解错误。但事实往往是人们在向别人提供信息时少的可怜、甚至不成逻辑,还嫌别人蠢;而需要别人的信息时却是自己缺乏理解能力,需要从头到尾把细枝末节讲清楚。

接口要形成规范,这样才能做到你所表达的,即是我所想知道的;我所提供的,即是你所需要的。

5.开会的艺术

研发过程中经常会需要开会议过进展、讨论问题,这似乎也会是很多人不喜欢开会的地方。很多时候,开会并不是需要大家都参与,或者是只是需要自己参与其中一小段时间而已,这样把所有人都弄着一起会很耽搁时间。想过进展,倒不如让开个excel共享下,让每人填下进展。

至于会议讨论,很多人喜欢开会议讨论问题,但他们往往做错了一件事。开会讨论是要讨论采用什么解决方案,而不是讨论有什么解决方法的。一个问题其本身往往根据其代价与效用就决定了其是否能解决、是否需要解决、该怎么解决,简言之其解决方案是固定的几种。开会时就应该想好各种解决方案,预估采用哪种解决方案,这样才能节省开会时的时间。

另外开会时活泼点固然能让气氛融洽,但也要注意开会的目的是解决事情。有些人脑洞很大,总是喜欢在开会时聊着聊着就吹逼去了,他自己吹逼不要紧,但是不能拉着别人一起吹啊。有时吹完后,他的事情结束了,但别人的任务却来了。所以终究需要一个人把握会议方向,把会议拉回正常运转流程上。