对于同样的需求,一个月做出来和三个月做出来有什么不同

程序员对于同样的需求,一个月做出来和三个月做出来到底有什么不同呢?
答:底层架构不同、可预见未来支持的扩展不同、优化不同。
或者可以这么说:从某个角度上说,是完全两种东西。

开发时间的常用评估方式

首先,评估开发时间的问题,两个常见的方式:
第一种,会从底层程序员往上报自己需要的时间,经过主管、经理再到总监每一层都会多报出一个百分比的时间,以备用来解决不可预知的问题或bug,其实不预估时间的项目往往是最快的,程序员尽力去完成,但在有一定规模的项目组中却不可取,没有哪个老板或投资人会对没有时间规划的项目开发组充满信心。企业也不会任由程序员来规定时间。而报到老板那的时间也会直接被砍一刀,三分之一的时间被砍掉都算是少的。

第二种,如果是合同定制的,开发需求非常明确的,一般都会有一个明确的开发周期和时间节点,开发任务会“以终为始”的方式来开展。
举个例子,六个月的工期,那么第六个月的时候交付产品,需求、设计、开发、测试各自匹配出相应的时间,在这个时间段内完成任务。只要对方不改需求,时间给的合理,这样反而简单了,一般情况下都可以保证deadline来之前上线交付。

开发时间被压缩的要求,往往来自于不懂行或者没有开发背景的老板,一方面是项目进度、企业进度这类客观性的要求,另一方面是怕程序员偷懒,工作不饱和,自己白付工资这种主观性的考虑。
在他们的视角中,开发一套系统,三个月的时间成本和一个月的时间成本是一个简单的数学关系。
外行人做管理层,从来不会关心你短时间内开发的系统所遗留的问题,他们会认为那是程序员应该解决的事,而这些问题实际上会像滚雪球一样一直堆积,最终在某个时间段内集中爆发出来,后果就是系统的架构已经无法再加任何的功能了,只能重写。

我们假定这个程序员的水平在中等偏上,不存在技术水平以及任何情绪的问题,一切都是按照比较公平的方式去比较,现在企业要做一套系统,需求明确度60-80%,为了简化模型复杂度,我们只要一名程序员,这名程序员负责系统的所有的任务,程序员报三个月的开发时间,如果这个时间被无端压缩至一个月,那三个月开发出来的系统和一个月开发出来的系统到底区别在哪呢?

架构不同,决定了对未来可扩展的支持的不同

系统做的可大可小,关键看给的时间,时间不够,即便有能力也会把系统做成小的、扩展性差。
为什么呢?
程序员都会选择当前环境下的最优解,和时间赛跑的项目最优解就是,快点上线。
底层架构?领导又不关心你操哪门子心。
未来可扩展性?表示不关心,只知道项目完不成会更糟糕。
反正先让你看到个东西,管他底层是啥样子呢。

举个例子,你的系统是做一个学校的客户关系管理CRM,实现客户的录入、分配、跟进、报名的功能。
假如老板或甲方压缩时间,给的时间不够怎么办,那只能做做表象的东西,一个客户表,一个跟进表,两者一对多关联,再加一个用户表和报名表,用户表和客户表一对多关联,客户表和报名表一对多关联,完工,项目做完啦。
其它不管了,也没时间管,谁让你给的时间少呢?那上面这套系统哪还有问题呢?
程序员报三个月,被老板压缩到一个月,老板是不是赚到了?

同样的东西,压缩时间做出来,老板真的是赚到了吗?

上面那套系统,程序员未来可预见的业务扩展,但由于被压缩了时间,所以底层架构是按照最快最简单的方式来实现的,那架构在哪会出问题呢?
问题可大了,比如:
对方需求没说支不支持多校区,整个数据库设计被设计成了一个校区,想要多校区?不支持的,你们没说,没这个概念。
班级的问题,你们没提,我们也没给你们加,一个学员可以进几个班,一个班级可以安排多少课,是分开计课时?还是一起计课时,不管你上不上都会划去一节课。
补课?缴费?退费?补款?没说啊,没说可不没有么?为什么我们不写啊,我们只写你们提的需求里的功能,谢谢。
操作权限问题和数据权限问题,一个客户的市场收集人、销售分配的人、登记客户的人是三个人?不支持,按需求合同来。
你还要统计跟进次数?什么,还按部门统计,你们重新提需求文档吧,先把第一阶段的给钱给结了。
访问速度太慢啦?把服务器的性能调一下,多加点钱就好了,服务器费用从每月3000增加到每月9000。

上面简单列出了一些问题所在,有看得见的功能上的完善,还有看不见的架构扩展,你只要不说我们就不写,你压缩时间,我们就压缩你看不见的,一切以时间为准,或者说一切看绩效。
这样的系统,再来几次新需求,可能就要重翻了,重新翻系统的话,该花费多长时间不会减的。
本来多给几个月,这些东西全给做上了,这一压缩时间,多花费出来的时间你还是要给程序员开工资的,别指望靠每天免费加班来榨取剩余价值,程序员离职对项目的损伤更大,并且,项目是公司的,公司是老板的。上有政策下有对策,所以业内有句话是这么说的,得罪谁,也别得罪程序员,否则,最后你怎么死的都不知道。而这句话并不是危言耸听,觉得程序员老实好欺负的老板的最终下场都很惨烈。

除了功能和架构以外,还有什么?

那除了功能、和架构以外,还有什么“本应该可以做”,但由于时间原因没做的呢?性能监控和优化、缓存、日志分割和备份、数据库备份、代码重构等等等等,这些东西你做了,别人看不见,不做,对系统交付也不会产生问题,时间紧任务急,被时间压急眼了,不做也罢。

原文:http://toutiao.com/group/6666373091565765131/?iid=0&app=news_article

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 230,501评论 6 544
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 99,673评论 3 429
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 178,610评论 0 383
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 63,939评论 1 318
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 72,668评论 6 412
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 56,004评论 1 329
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 44,001评论 3 449
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 43,173评论 0 290
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 49,705评论 1 336
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 41,426评论 3 359
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 43,656评论 1 374
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 39,139评论 5 364
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 44,833评论 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 35,247评论 0 28
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 36,580评论 1 295
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 52,371评论 3 400
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 48,621评论 2 380

推荐阅读更多精彩内容