在接近三年的开发生涯中,做过了不少项目,但发现个人能力的成长上确没有达到自己所期望的程度。不能说自己不够努力,细细想来,每天都处于忙碌的状态。但是是否处于一个高效的工作状态,在开发中处于良性的循环?在产品开发的过程中,注重的仅仅是完成开发任务,还是关注产品的性能、架构以及代码的质量?在这些方面,就做的相当差劲了。
当然,作为程序员,这些方面都是我们应该关注的,毕竟这对个人的职业发展是相当重要的。但这只是个空口的希望(这句有点奇怪),现在的互联网行业中,产品的开发是处于快速迭代的时期,需求的不断改动对开发工作带来很大的影响,使我们的效率大打折扣。怎样使产品开发更加高效,质量更高,同时保证程序员对产品实现有着更深入的思考? 这便是作者思考尝试解决的问题,应该从以下几个方面做起:
1. 流程划分
清晰流程,详细的交互设计文档以及后台接口基本提供完善,才可进入App开发的阶段。我们在App开发的开始,是需要针对设计交互文档确认过,细至每个细节的交互都了解;开发过程中,可能产生的一些交互问题,都应该在交互文档详细地体现出来,做到一切有迹可循。程序员在开发过程中不再有模糊的交互,不再有口头上的交流,是我们在文档最终定稿应该达到的理想效果。需明白,在开发过程中,口头交流来确定交互的实现,对开发效率都是大打折扣的,出了问题,我们都是没法责任到人的。
这样,就要求在前期设计交互文档的人员的责任比较重,需要针对每个细节的实现都要考虑清楚,产品经理在对一个新的迭代的开发的同时,需要明确提及到这个迭代中的会涉及到的交互的实现。人无完人,不能各个层面都涉及到,所以在这个期间,可以让程序员加入来讨论,毕竟最后的实现是需要程序员来完成的嘛,有问题的过程再确定重新形成方案,必要的时候,可以给与程序员一定的调研时间,当然考虑地越多,意味着我们的工作将能够更加地明确。
清晰地可以看出一个版本的开发将会有两个阶段,阶段一 需求的定义形成设计文档,主要角色有产品经理、产品设计、产品交互; *阶段二 * 程序员进入开发阶段最后交付完整的产品。此时,我们可以让下一个版本跟当前版本做一个简单的交错,即在阶段二中,产品进入下一个版本的的需求设计阶段,借此来并行地保证各个部门的高效工作。
虽然看起来在操作过程中,可能会遇到不可料想的麻烦,毕竟没有一成不变地需求,这样就需要产品经理权衡,尽量将这些需求放在下个版本中,将是最好的方式。不然交错地流程开发,带来更多的是开发成本的上升,产品的迭代周期的延长。
2. 规范定义
界面设计、接口设计、App设计定义一些通用的规范。
- 接口设计需要对返回的数据进行统一格式。譬如:统一返回的是 JsonObject,其中包装成功状态result 以及错误的信息,真正的数据则统一放置在 data 字段中进行处理。
- 界面设计遵循设计规范。 Android 可以选择 Material Design,苹果也有自己的设计规范。若是不采用这些,则需要对一些通用的样式,做些统一定义,譬如常有的间距,弹出框样式,常用的颜色值,字体大小等等。这样客户端也可针对这些定义,遇到的时候则可直接使用。
- App开发的规范。统一的命名、格式化文件标准、尽量清晰的处理逻辑、类文件编写。
定义规范,即多做约定,最直接的好处就是:多人员协作能够有一套的标准,不至于杂乱无章。
3. 角色明确
这一点在小公司可能不太清晰,经常出现一人兼多职的情况,不太好定义。在成熟公司,这一点是相当重要的,因为角色到人,使得我们可以精确到单一问题该有何人负责。若是一个团队中出现职责不清晰的情况,使得我们解决一个问题便会出现踢雪球的情况,问题得不到解决,雪球还有变大的可能。
4. 产品至上
产品是最最最重要的。最终的成果都是拿产品来说话的,即使再牛逼的销售团队,再漂亮的设计到产品上,也经不住产品的不断闪退,卡顿,高耗电,不人性化。而这最终的成果的展示都是在程序员身上,产品的优化又是一个任重道远的过程,毕竟你产品经理还要加功能。所以应该以程序员的工作为主,API设计以及UI团队应配合甚至服务于程序员的工作,尽量保证程序员能够高效地工作。遇到过App展示一个界面,要发送三个甚至更多的API请求,只想说真是够了。所以这里应当简化App端的工作,能尽量少在客户端做的就少做,服务器端的改动肯定比客户端来的容易些。
总结
作者是站在一个程序员的角度上,以及要不断迭代地去开发一款长周期的产品,来看待产品开发应该具有一个怎样正确的姿势的,欢迎来拍砖讨论。当然,如果你就只是想快速开发出一款产品,那我上面的都是瞎扯淡了。。
PS
这里感谢Jaeger大神的审阅,并提出的修改。
网友评论