除去自己发起的技术调研,其他技术调研都需要先了解需求。估计很多人看到这个就会心想,切,这个谁都知道啊。
是的,“了解需求”这是个人尽皆知且每个人在技术调研前都会去做的一件事。但不夸张地说,在这个阶段栽跟头的人最多。
很多人,特别是新人,在这个阶段出问题的普遍原因大概有以下几点:
诸如此类。
解决方案也很简单,咱们把问题一一解决。
首先是接到需求时,认真听对方讲,对对方所讲内容有疑惑的是可以在对方讲完后提问的。千万不要听的时候是懂非懂,想着待会私底下自己查(当然提问也要有技巧,这个自己琢磨去)。
然后假如不了解的东西太多(例如一上来就给新人分配一个陌生业务模块的任务,的确会一脸懵逼),又不想围着需求方各种打扰,完全可以请教下熟悉相应模块的同事嘛。
最后,假如是复杂的需求,可以在做的过程中,分步跟需求方确认,这个下文会展开。
这里举个例子:
一天,小明正热火朝天地写着代码,突然肩膀被人一拍,回头一看老大正站在背后。 小明,这有个调研工作你去做一下? 没问题,具体是做什么呢? 是这样,我们需要做一个 A 功能以支撑 B 模块,这块功能 iOS 端已经完成,可以与他们讨论下。 好的,没问题。
于是小明屁颠屁颠开始调研 A 功能是怎么实现,耗费了几天时间后,老大过来一看,诶,你这实现不是我想要的呀。
原来虽然小明选取的技术方案是业界知名的 A 功能实现方案,但却没法用到 B 模块上。而且需求隐含的意思是,既然 iOS 端已经实现了,需求的具体情况可以去询问 iOS 端对应开发。
在做好需求了解的前提下,调研本身会显得轻松点。
需要注意的是,进行调研时要合理安排时间,调研过程往往伴随着对新知的探索,很容易“沉迷于学习”。别忘了这是一项工作。(当然不只是技术调研在日常工作中也一样,要学会合理安排时间,注意时间成本)
个人有个小技巧,按照以下步骤来做往往效果不错:
以上是关于“如何做”的。需要说明的是这只是我的个人习惯,你有自己的做事风格更好,没必要强行一致。
还有一点需要注意的是,千万不要埋头苦干。
“沟通”应该是贯穿始终的一件事,在上文也提到了,对需求的理解偏差可能会导致整个调研工作推倒重来。
那么该如何沟通,以及沟通些什么呢?
第一个问题,如何沟通。我的方案是,阶段性得去跟需求方或者跟有经验的同事讨论。比如一个技术调研有四个阶段,那每完成一个小阶段,就可以尝试去沟通一次(必须强调下,规则是死的人是活的。假如对方很忙的情况下,你偏要强行打扰对方去沟通;或者一个很小的技术调研你也按阶段多次去沟通,就尴尬了)。
第二个问题,沟通的内容,我认为主要有以下几点:
做到以上几点,应该就差不多了。下面说说第三阶段,结果验收。
做完技术调研后,一定要有成果。
可以是调研之后发现“某个方案是最佳的”,也可以调研之后发现“尚无解决方案”,还可以调研后对需求本身提出质疑,但一定不能做着做着无声无息得做没了(不是所有技术调研都有需求方催促或跟进)。
反馈的展现形式根据需求来,有几种常见的展现形式:
个人比较推荐以文档的形式,大部分调研工作都很适合。
反馈的内容有几点是需要考虑写进去的:
大概是这些,总而言之,把一次技术调研当成一次绝佳的学习机会来做,那反馈的内容就不会显得空洞。
反馈的时机的话,在保证质量的前提下,尽量主动、提前向需求方或组内其他同事提出。一方面是你的反馈对别人而言也是一个学习机会,另一方面主动推送一件事也是一个优秀的表现。
以上是一点个人浅见,必须要说明的一点是,本人能力有限见识浅薄,上文的一些观点不一定正确。各位看官切不可太过信赖,还是要有自己的思考为妙。
另外,写到最后,发现跟“技术调研”中的“技术”倒关联不大了,哈哈。我也就不纠结这个了。
最后,我写博客的目的就是希望将个人的观点、观念摆出来让读者评价或吐槽,因此假如觉得有不妥或者可优化的地方,还请不吝赐教。