【总结】从0到1的项目经历

2020/05/16

去年7月底,接到公司安排,需要在一个半月内完成全新app的上线,需求文档与开发并行,由于时间紧迫,以及人力有限,当然就是享受了一次996,经历了之后,发现真是的是一次痛并快乐着的体验。这段时间加班稍微少了一点,趁假期写下这段经历的收获。

经历了这么一波疯狂加班后,我总结了一些经验,希望能对自己以后的快速且稳定的开发节奏起到辅助作用,也希望能够帮到正在读这篇文章的你。

注意,以下的所有建议,都是针对于没有按照正常流程走的创新性项目,不一定适用于已经稳定下来,需要按照正常流程开发的项目,当然有一些是可以借鉴的。

Photo by Mitchell Luo on Unsplash

提高沟通效率最好的办法,当面沟通

做这种996的快速开发,每个人每天都在争分夺秒,所以时间非常宝贵,遇到不懂的东西,通过即时通讯工具沟通效率是非常非常低的,不管是私聊还是群聊,不能一直等待别人的回复,如果有个很重要的流程阻碍到自己的进度,那么最应该做的事情是拉上相关的人,把所有相关的人集中在会议室中,明确讨论的主题,最后在白板面前画下流程,让大家一起对流程更加熟悉,找出更好的解决方案。每次沟通好方案以后,都要有书面记录通知到每一个参与讨论的人,保证信息的同步。

每天预留一点时间总结,及时mark下TODO项

在这么紧凑的开发进度下工作,是非常非常容易忘记东西的,当时的做法是每天下班后再留下半小时梳理当天完成的内容,划掉已经完成的工作任务或者优先级不在第一个版本的工作任务,然后当天加了什么功能,发现什么功能遗漏了,都写下来,以便安排第二天需要完成的工作。

如果实在太疲劳,做不到每天总结,至少每2天或者最低限度是一星期要做一次梳理总结,否则到最后关头才发现这也没做,那也漏了,那真的加班干到si都不能完成了。

这个习惯现在仍然保持着,现在项目进度稍微没那么赶,每个需求都会这么做,对能按时交付需求已经没有大难度了。

与产品沟通,做好取舍

在需求文档还没出完的情况下,开发在加班,产品也在加班,开发进行到一半,产品完成了部分文档,突然来了一个大功能,那么要在短时间内完成全部肯定是不可能的,只能跟产品沟通,看功能是否很重要,如果没有该功能是否影响产品的使用,保下最重要的功能,其他非核心流程的功能,留在下一个版本再迭代。

这一点最好应该在项目启动时进行,即使需求文档没有出完,但是可以梳理出最核心的功能,大家都朝着同样的目标去干。鱼与熊掌不可兼得,你不能什么都想要。

平时多积累项目的通用组件,并及时升级

在参与这些全新又紧急的项目,要想要马上就能写下第一行代码,平时一定要积累一些通用的组件、工具类,比如参数校验拦截器、时间函数、异常处理拦截器等等,有了这些,开发起来就如虎添翼了。

有了自己的项目框架,就不需要重新搭建,只需要关心业务功能的实现,当然,最好是能自己写一个脚本,一键初始化项目。

快的同时尽量稳

要求这么快交付的项目,bug多是肯定的,虽然可以允许少量的试错,但是关键的是要保证核心功能是没问题,且不允许出错的,核心功能无法使用对于用户以及产品来说,是无法接受的,会造成用户的流失,大大降低用户留存率。

及时休息

结束了每一天的忙碌之后,早点休息吧,记得当时差不多周一到周六,每天是9点半开始开发,晚上1点才停止。连续3周之后,到了周日的时候就是一阵头疼,痛一整天,基本上一天都做不了什么,然后又开始新一轮的工作。甚至有一天半夜醒来了,疯狂出冷汗,全身虚弱,而且疯狂地出冷汗,持续了大约10分钟,那一次真的把我吓到了。所以休息好很重要,有时间就休息,不能疯狂工作忘了休息,身体才是奋斗的本钱。

总结

经历了这一次的从无到有的项目开发,不可否认是很累,虽然中途也有很多挫败感,但也不可否认学到了很多东西,有了很大的成长,后续会慢慢分享这些学到的东西,可以说是自己工作以来成长最快的一段时间,感谢这一次的项目经历,也感谢帮助我的老大和每一个小伙伴。

最后的最后,当然希望大家遇到的项目都是能按照正常排期进行的,这样的节奏才是正常的,你好我好大家都好。

Photo by Jon Tyson on Unsplash



通过赞赏码赞助此文