程序员怎样做好业务

前言

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

背景

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

面临一些问题

我对B系统不熟悉

对团队人员不熟悉

对公司的框架不熟悉

反正就是干

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

砍需求

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

思维转化

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

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

加班

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

市场部沟通

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

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

变化

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

结语

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

是否延期

是否了解整个系统和细节

是否在写代码以前就能预见到细节问题

核心逻辑能否一次性思考完善，不出逻辑漏洞

带动其他同事，推动整个业务前进，正能量

同样的错误最多只犯一次

产品思维，关注用户体验

合理的时间，可持续性，工作量饱和

及时汇报