软件开发过程和问题

其实,这两三年来,关于软件的开发过程已经越来越模糊了。


由于刚入社会时所工作的公司是一家外包公司,加之所开发的软件都是一些传统的基础系统,项目的开发模式决定了和现今的互联网的平台开发模式相去甚远。

当然,现在回想起来,也许当时他们一直在采用一种快速迭代的方式在开发,但是在版本的发布周期相当长,所以基本上可以把其开发模式认为是传统的软件开发。


这里所谓的「传统软件开发」,特指软件在确定需求后,开发团队根据需求来进行建模、开发、测试直至最终的发布,整个软件是完整开发后才发布,而不是根据功能模块的权重进行模块划分然后边开发边测试边上线。

简单来说,就是软件必须在所有的需求都开发完成并通过测试后才能上线。


这几年所做的工作,基本上是和互联网/服务平台有关系。虽然在开始接触的时候,还是一直强调传统开发流程的重要性,但是在很多时候根据实际情况来调整开发模式也是常有的。


总而言之,这种服务式的开发(敏捷开发?),相较于传统软件开发,在很多时候更加的灵活,特别是在一些业务模式并不稳定,还处于探索阶段的企业,这种开发方式让整个系统能够根据实际的业务变化而不断迭代进化,有足够的轻量和快速。

这种情况下,一般不怎么要求太繁琐的文档和流程,主要的需求文档、数据库设计文档管理好,上线更新时把好关,基本上也不会有什么问题。

开发进度管理也较为方便。因为需求拆分得较细,在分配任务时根据不同的权重来分配,开发时间相对也切小,更容易对进度进行跟踪,也不需要陷入各类不同的文档中不能自拔。

想在这方面达到很理想的状态,那么要求开发人员或者负责人对系统架构、需求都很了解,在分配任务之前,对任务功能之间的耦合性有足够了解并且能较好的解耦,否则的话,就不容易做到小块任务快速完成开发上线,更危险的是一旦此功能有迭代,那么将会陷入泥沼,是非常痛苦的事。


毕竟,服务类平台,特别是面向公众的服务类平台,很多时候需求是不稳定的,往往一个功能刚上线,下一分钟就开始讨论调整需求。碰上靠谱点的需求人员还能根据用户的反馈、数据的分析来讨论是否有调整的需要,碰到各个拍脑袋的大佬们,基本上就是想到了就要做、看到那个有了立马要跟,分分钟要你命的节奏呀。

这种情况下,我并不喜欢一下子做一个很精致的东西,而更倾向于先搭架子再根据需求慢慢雕磨出一个使用的东西。

一方面是不想过多的返工(不是产品需求迭代,而是无用功。),另一方面就是出于成本的考虑,包括时间成本、人力成本。


做一个很精致的东西,需要费的时间和精力太多,而还在摸索阶段公司耗不起这种成本,一旦做完了发现这东西不能用或不适合用需要重新修改,那前面为了细节所花费的时间很多时候是白白浪费的。

碰到那些因为只是尝试性的业务而被抛弃的功能,对其所花费时间来精雕细琢做了一堆的预留扩展,实在是没有必要的。

做一个架子,把提到的或需要的功能往里面堆叠、调整,一旦有问题了,也不需要因为细节浪费太多时间,只需要把其中不合适的就进行拆卸、调整或者替换,整体的框架还是稳定的,不会因为这块业务就影响整个系统功能。


之前有人说过「别什么事都考虑成本!要把一个东西做好。」

我和他说这是他妈屁话。


如果负责人不是你,你不需要担责任的时候,那当然不需要考虑成本。

我当然也想好好做个完美的东西,慢慢磨出一块美玉,至于什么时间、人力的,管他娘的~~~

但是当上头说要在 xx 时间内完成如此这般的若干功能时,那还是先考虑交差吧,如果还想继续待着的话。任务不能按时完成时,需要考虑的不是这东西完美不完美,而是连东西都没有要怎么负这个责任的问题了。

真是「站着说话不腰疼」。


做一个很精致的东西,估计是很多产品、开发人员的梦想。

自从乔帮主的 iPhone 横空出世后,各种所谓的工匠、Geek 纷纷粉墨登场,言必「完美」、「用户体验」,对于每个功能点,哪怕是根本就不知所谓的东西,也要求精雕细琢。

虽然我并不反对做一个完美的产品,但是在各种不分轻重缓急一律一把抓的盲目「完美主义」,简直是恶心到想吐。

这种事情从来都是说得容易做得难,而当它被限定了实现时间后,整个事情就悲剧了。


毕竟他们觉得改一个东西,比如是改一个描述,只需要几分钟就搞定了。

他们当然不需要知道这个文字是要改代码、还是修改数据库、或者是改系统配置文件,改完后发布所需要的时间是多少,因为这个东西而被打断的思路要怎么拉回来。


这本来就不是他们的事,他们只需要负责提需求罢了。


矛盾基本上是不可调和的,只在于负责人怎么平衡!!!