前言

  技术能做两种事情,通过技术实现业务和通过技术支持技术。我们大部分时候做的是前者,养活我们的大部分也是业务。  近两个月,作为项目负责人角色从0到1经历了新项目的几个版本迭代,跨入了部分新领域,也有一定收获,对如何做好业务也比以前有了更深的理解,所以作此博客记录项目中经历的事情,和自己对业务的认识。

背景

  从原公司转到兄弟公司,负责一个要求快速产出的新项目,团队人员也是从其他项目组过来支援的。  临近年关,2月初开始开发,3月初上线,中间还有过年的时间。  公司很重视,不能延期。  事态紧迫,研发部门领导综合考虑,过年加班才能赶上进度,因此在一开始就找到愿意过年加班的同事,并且向公司上层申请了加班奖金。  技术方面,需要申请两个公众号,公众号申请需要时间;涉及和另一个系统打通,需要对方支持和开发对接模块,文章后面称之为B系统。

面临一些问题

  • 我对B系统不熟悉
  • 对团队人员不熟悉
  • 对公司的框架不熟悉

反正就是干

  不熟悉的都可以很快熟悉起来,同事也可以协助自己。这种境况下,是一种挑战,也是能逼迫自己去更快融入环境。不怂~

砍需求

  团队合计了一下,按照初版的需求,即便过年加班也做不完,不能保证3月初上线,于是我们还是和需求方讨论,把非核心的需求一个个砍了,砍到最后我们觉得还比较轻松了,但实际的工作量仍然很大。  我们往往在拿到一个需求的时候,第一反应都会低估它带来的工作量。  因为细节还未完善,很多事情在开发过程中才会发现、沟通、解决。  当我们把零散的功能和页面做完,最后整合直到完全跑通整个流程,这期间也会花费很多时间。  无论如何,项目千万不能延期,要延期也不能是因为前期估算不准导致的,一旦估算时间定了,跪着也要如期上线。

思维转化

  最开始,在某些方面,自己都有一点缺少主动性。  当时几个同事在旁边不远讨论B系统需求的时候没叫上我。  也是因为才来,其他同事对我不熟悉,我自己包括大家都没有意识到我是项目负责人,我对自己的边界也有点模糊,我认为主要还是技术负责人。  看到他们在讨论,自己觉得好像没叫我,应该没我什么事,领导看到了,说我是负责人,那么多人讨论我得去听。  到后来,我也就明白了,涉及到负责的项目不管是什么事情,我都得站出来,否则怎么能称之为负责人,同事也不会信服这样的负责人。

  当一个技术人员,开发了一个系统,并且更全面的了解需求的时候,那他对整个系统的理解应该是超越产品的,我认为。  在项目开发过程中,我和产品发生了小小的分歧,其实就是一个文案的问题,那个文案可能会造成混乱或者误解。  从产品的角度,是我们太程序员思维了,作为销售渠道是能理解的,从我的角度,虽然能理解,但是概念有重合,需要思维转化,不直观,容易造成系统使用错误。  不纠结这个细节,问题在于我的矛盾,因为我平时做事想的多,提的多,但也知道自己的想法不一定都是对的,又出现了双方都不能说服对方的情况。  我后来想了下,如果对方已经把理由说清楚了,自己觉得自己的方案还是更好,那自己又有拍板的权利,就拍板吧。  如果对方有那个权利,就让对方拍板吧,否则就太浪费时间和精力了。  拍板之前至少要思考对方的想法,不能完全自己专断,同时也要时刻对自己保持怀疑。 

加班

  也是为了保证进度,今年过年团队部分同事,我们只休息了3天,公司放假是9天。  牺牲了假期,但是在上线后,我们确实也得到了相应的奖金。  领导说到做到,公司也体恤员工,这样的加班至少对我来说也是值得的。  加班这个事情,对我们团队来说,是一直保持一种可持续化发展的态度。  996是底线,一般都没有打破过,大部分的时间不会达到996的水平,  通宵就更少了。  但是团队的战力并不差,我觉得这样的状态刚刚好。

市场部沟通

  在项目第一版本上线以后,我们很快开始规划第二版,这次我和产品同事参加了和市场部门的需求讨论。  市场部门的需求一般要求快快快,他们面临业绩压力,自然这种压力也会倾斜到我们研发部门。  大家应该也知道一些段子:销售出去卖产品,给客户说一周之类就能搞定,然后签了合同,最后告诉研发部门,合同已经签了,预订金已收,时间就这个点,剩下一堆想离职的程序猿......  开个玩笑,当然我们没有出现这种事情~  总之我们需要和市场部门的对接人保持紧密沟通。 这次我们是和市场部门领导沟通的需求,连着几天拉着过需求,总体还算顺利,梳理的也还是很清楚。  其实和对方部门领导直接沟通,算成本比较低的。  如果说对方领导派一个中间人来对接的话,这对我们的工作量、时间安排、心理压力都会增加很多,毕竟他不能拍板,需求也不是直接来自于他。  

  因为和B系统强相关的缘故,市场部门给B系统提需求的时候,不知道涉及到我们系统,在一次沟通中,发现了一个需要和B系统对接的新需求问题,庆幸的是当时B系统的新需求和我们的新需求都没上线,所以还没造成严重的生产事故,这次以后,B系统有新需求我都得了解了,要避免系统间的风险。

变化

  迭代了几个小版本后,现在因为公司战略需要,团队被分散到其他项目做支持,项目迭代会暂停一段时间。  但是项目依旧要运营,B系统还会迭代,B系统的迭代需求可能和我们的系统冲突,或者造成bug。  所以B系统一旦有迭代,我都得了解他们的需求,评估对我们系统是否有影响。 

结语

  业务是饭碗,业务做不好,其他什么都别谈。  两年多以前有一个项目,因为自己的问题,导致了延期,对自己各方面的影响都非常不好,于是决心再也不能犯同样的错误了。  对于任何人而言,个人原因延期都是职场大忌,犯不得啊~  对于初中级前端要想有更大的提升,业务方面的能力要达到游刃有余才行,否则飞上去也会摔下来。  做好业务的标准是什么呢?我也不知道,列出一些我能很快想到的点吧:

  • 是否延期
  • 是否了解整个系统和细节
  • 是否在写代码以前就能预见到细节问题
  • 核心逻辑能否一次性思考完善,不出逻辑漏洞
  • 带动其他同事,推动整个业务前进,正能量
  • 同样的错误最多只犯一次
  • 产品思维,关注用户体验
  • 合理的时间,可持续性,工作量饱和
  • 及时汇报