挨踢项目求生法则——编码篇
摘要:
有一句古语“少壮不努力,老大做IT”,做IT确实挺悲剧的,但最悲剧的是做码农(程序员)!烂代码直接产出来软件,而烂代码是怎样产生的呢?是烂程序员吗?大部分程序员是追求进步和高质量代码的,往往是烂的管理方式、无节操的项目工期而导致程序员不知所措、疲于奔命、为赶工而写代码。当加班成常态,你还跟我谈什么代码质量呢!
什么叫挨踢项目?
IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死,你想不“挨踢”都难!
“无节操”的加班
某公司有个加班龙虎榜,每周按照加班的总时长进行排名,加班时间最多的就是状元,然后是榜样、探花。其实没有谁这么变态要打进三强,但大部分人不想自己经常出现在榜尾,因为让领导看见了不是很好,有可能会导致饭碗不保,所以只能“自觉”加班!于是加班成了家常便饭……
某创业公司的老板搞了个“奖罚分明”的激励制度,任务分派下来如果能提前完成,提前时间越多,奖励越多;相反,如果任务推迟完成,推迟越多惩罚越多。结果大家都懂的,这些任务基本都是 mission impossible,“提前完成”需要人品大爆发,“推迟完成”是正常现象,程序员们的薪金都被扣得差不多了,再推迟的话就要倒贴公司了!
一个人一天当中,能高度集中精神的工作时间有多长呢?你可以自测一下,我的答案是6小时,偶尔可以爆发到7-8小时。
如果不用加班,按一天工作8小时算,如果其中有6小时能高度集中精神工作,其实已经很不错了!
如果加班呢?我告诉你,原本还有6小时的高效工作时间,马上就会减少!加班越长这6小时减少得越多,如果加班时间家常便饭,那么这6小时就会变成零!
软件研发不是体力活,是高强度的智力运动,希望管理者要清楚明白这个软件研发的客观规律,我们不能违背这个自然规律。低效率的加班只能是一种心理安慰(这个心理安慰只对领导有效),只能带来更多的问题。
“奔放”的项目管理者
领导要K人,一般会把要K的对象叫进会议室,然后关上门来K,开门后就好像没有发生过任何事情一样,门外的人一律不知道发生了什么事情。(PS:这里说的K不是指打人噢,而是批评,俗称骂人。)
但是有些领导很“奔放”,直接当众K人,有些邮件K,但这个邮件会抄送项目组全体甚至全体员工!我运气比较好,还没有遇到过“奔放”老板,但万一你运气好,遇到了被领导“奔放”地K了一顿,你会怎样呢?当然你要这样想:这个领导其实算不错的了,在“阳光”下K你,如果他来“阴”的,岂不是更恐怖!
闷骚、腼腆、脸皮薄、心灵弱小,是程序员的特点,一般的程序员是接受不了“奔放”的管理模式的……
保命四招
如果你遇到“极端情况”,后面介绍的法则都不会适用,你要用的是这保命四招。
什么是“极端情况”呢?
那就是类似前文提到的“无节操的加班”和“奔放的项目管理者”这些情况,当然不限于这些情况,因为没有最惨只有更惨!
以下是保命四招:
1)抱怨有益健康。
有人说抱怨没有用,但如果不抱怨你会憋死,所以你需要宣泄,你可以约朋友吃饭喝酒齐齐诉苦,这样才能有益身心。但要注意抱怨并不能解决问题,不要沉迷抱怨噢!
2)忍一时风平浪静,退一步死无全尸。
工作中遇到不公想发作,你一定要用第二招:忍一时风平浪静,退一步死无全尸!要忍但不要退,要用耍太极的方式来推挡一些事情,不要累死自己便宜了别人。
3)自我增值才是硬道理。
增加你的价值就是增加你的谈判筹码,这就是第三招。我曾经和领导直接电话对骂,我居然没事,因为当时公司需要我完成这个项目,我有恃无恐!你可以尝试在公司爆发一下,测一下你的价值,如果爆发完你没事,说明你对公司的重要性不错。但如果出事你不要找我噢!我当年敢干这些出格的事情,是因为我年少无知、血气方刚,并且自以为自己很牛B!自我增值让你有更多选择,能帮助你选择更好的工作。
4)我只想将工作做好!——这不可取,因为这是你辛苦的根源。
在“极端环境”下,好的工作态度是不受欢迎的,只能变成折磨你自己!做好工作不是你一个人的事情,我们没有这么强大,我们只能顺势而为。很多事情我们改变不了,但我们能改变自己。我不是鼓励消极的工作态度噢,这是在你因为各种原因还不能选择更好的工作机会时的过渡方法,有好的工作环境时,你就需要重新树立“我要将工作做好”的态度!
面对“极端情况”我也没有什么好招,前面的内容实在是太多负能量了,实在有点“儿童不宜”!
下面将会介绍“正常情况”,“正常情况”当然也会存在很多问题,但这些问题都是有机会解决的,后面的内容都是正能量滴,是“老少咸宜”滴噢!
牺牲质量能提升进度吗?
项目管理基础知识中提到,项目管理主要管成本、进度和质量,我们不可能用很低的成本、很快的进度和很高的质量来完成项目,也就算俗称的“多快好省”地完成项目是不可能的。我们的软件项目成本是卡死的,进度也是很紧的,所以我们只能稍微降低质量来保证进度,这样的逻辑合理吗?
实际工作中我们其实就是进度优先,但仍然有很多加班。忽视质量其实并不能带来更快的进度,而是更多的加班!
我们为什么会加班?我们的加班大部分原因是要返工,或者是前面没有发现问题后期问题才爆发,简言之就是前面工作质量不过关,导致后续更大的工作量。工作质量包括需求的质量、设计的质量、代码的质量等等。重视质量反而会加速项目进度!我们需要定下项目的基本质量要求,想清楚才动手,一步一个脚印地做好项目。
代码的重要性
我认为项目中是两类文档是必须的,那就是需求和代码!有人可能会更绝,必须的文档只有一种,就是代码!没有代码就编译不出软件,其他文档可以不要,但代码必须有。而程序员是写代码的,非程序员是写其他文档的,所以除了程序员,其他角色也可以一律不要。其实上述说法是成立的,我曾经试过只有我和另外一位程序员的情况下,不需要其他人就我们两个程序员,我们就能做好一个软件并且这个软件的销量还可以。
代码及代码的质量其实是相当重要的,但很多项目可能是这样的一种现状:不抓代码质量,软件问题多多,但一抓代码质量,项目马上就会死翘翘!
如何解决上述困境呢,下面的求生法则可能有用!
法则1:问题根源80%在于需求
程序员的工作职责是什么?这个是单选题,你选择哪个?
A)写代码;
B)完成领导分派的任务;
C)实现自我价值;
D)实现客户价值;
标准答案是:D
客户价值就是通过需求来体现的,不要扎头就写代码,要弄清楚需求。需求文档其实是必须的,不过文档的载体和格式是不限的。
法则2:拒绝需求变更
某项目原定一个月发布某版本,但这个版本延迟大半个月还是发不出来。原来客户喜欢提需求变更,并且越接近发布日期,变更的要求就越多,客户希望这个版本包含的内容越多越好,而项目组为了不得罪客户答应了这些要求。不要怕得罪客户,要拒绝这样的需求变更,我会跟客户这样说:欢迎需求变更,但这个版本不考虑,下个版本再考虑。
这个法则并不是要你拒绝所有需求变更,而是某个一迭代中要实现的需求是稳定的,不适合再改的。盲目顺从客户最终并不会让客户满意,而程序员们因为要应对这些需求变更,需要反复改代码,这样是很打击士气的。
需求变更是不可能没有的,我们需要:
1)检讨需求分析的工作质量,请留意法则1;
2)原则上要拒绝当前版本的需求变更,下个版本再考虑;
3)万一遇到重大的需求变更确实需要马上实施,那可以停掉当前版本重新规划,一定不能用“逐步添油”的方式工作。(出现这种情况,通常是因为需求分析工作质量不过关导致的,所以法则1很重要啊!)
法则3:程序员的工作需要有灵魂
我们先看看什么叫程序员工作“没有灵魂”:
1)不知道自己为什么客户服务;
2)不知道项目的远景;
3)只有项目经理操心项目,而程序员以“打工”的心态工作;
4)程序员任何改进意见都听不进,能写完代码就阿弥陀佛了!
那怎样才能让程序员“有灵魂”呢?
1)让程序员理解需求,至少自己做的部分要理解;
2)让程序员先行自己估算自己的工作,项目经理给出指导;
3)尊重程序员的实际水平,想办法让他引爆小宇宙,而不是靠强压。
法则4:写代码也是在做软件设计
程序员们会用“码农”来自嘲自己,其实写代码是高技术含量的活,写代码其实同时也在做软件设计工作,包括软件的架构设计、详细设计甚至是数据库设计!
当你用开发工具规划solution、project的时候,当你在project中划分文件夹的时候,你其实就是在做架构设计;当你新建一些类文件,思考类的职责并且在注释中写下来,当你写下方法的定义(暂时没有实现的代码)的时候,你其实就在做详细设计;当你分析各种业务对象后,在数据库中去建立表、字段、表关系的时候,当你在代码中设计实体类的时候,你其实在做数据库设计及实体类设计。
所以我们不是码农,优秀的程序员其实也是优秀的软件架构师、软件设计师以及数据库设计师!作为程序员来说,不要将自己定位为码农,你可以站得高做得更好;作为程序员的领导来说,不要将程序员定位为低技术含量的工种,程序员其实是最重要最有技术含量的工种。
法则5:关注程序员的需要
问:工作了这么久,领导找过你谈心没有?
答:有啊,经常“谈心”呢!谈工作,谈进度,谈缺陷,谈做完了没有!!
我说的“谈心”是指领导和员工谈员工的职业发展,让员工说出他的想法,领导在公司层面给予支持和帮助。
程序员有什么需要?无非是以下需要:
1)薪金的需要;
2)个人职业发展的需要;
3)生活上的需要。
薪金的需要通常是不能满足的,作为程序员领导的你可能也对自己的薪金不满,更谈不上让你去涨程序员的薪金了。但领导是不是可以问问程序员的职业需要呢,他想学什么技术,做什么类型的项目等等,在工作安排上给予一定的照顾呢?在生活上是不是可以允许程序员稍微弹性上班呢?有些家庭生活上的事情可以让程序员先去处理一下,不用他请假更加不会扣他的工资,程序员没有后顾之忧才能做好工作啊。程序员可能是地球上最善良的一类人,他们会滴水之恩涌泉相报!
法则6:男女搭配效率加倍
有些公司比较“变态”:不招聘女生,如果要招聘就一定要找已婚已育的!还冠上冠冕堂皇的理由:女生出差不方便啊!女生加班不方便啊!
有些领导比较“歧视”女生:女孩子嘛,不适合干什么技术活,做一下测试或QA就好了。
女程序员本来就少,加上以上的原因,更加是少上加少!
女生的威力特别是女程序员的威力是很强大的,不仅仅是这位女程序员自身的作用,更重要的是女程序员对男程序员发生的化学作用!如果男程序员原来的战斗力是10,如果有女程序员一同工作,那么男程序员们的战斗力至少可以上升到15。所以那些老板们太不会打算盘了,不要只看着女生生孩子的那段时间,请一位优秀的女程序员,绝对是一个超值的投资!
法则7:编码规范不是摆设
问:你们有编码规范吗?
答:有!
问:谁能说出编码规范中最有用的几条要求?
答:……
不少公司的编码规范是“空降”的,或者是你来到公司后就一直知道有编码规范这回事,但一直没有见过这份文档,更加没有在工作中执行过。
“空降”的意思是所谓的参考业界标准“抄”过来的一份文档,或者从某CMMI多少级的公司中“抄”过来的文档,“空降”文档注定就是要被摆上神台供奉,不能落地的。
有效有用的编码规范可以很简单,最开始的时候可以一页纸就搞定!我们只需要总结出当前编码中出现的问题,针对性地定出规范,只制定当前能执行的规范,不能执行的不要写进去,这样很快一页纸的规范就可以定出来,并且大家都愿意执行。规范不在于长短,不在于参考了什么“伟大”的标准,关键是能不能执行!
所有的改进都应该遵循循序渐进、持续改进的原则,这样一页纸的规范将会逐渐添加更多的内容,这样也表明了我们的编程水平正在持续提升。
法则8:提升编程基本功
有些程序员是写不出排序算法的,更悲剧的情况是在一堆数中找出最大的算法也写不出来。
两个途径解决编程基本功的问题:
1)把好入职关,增加编程基本功的笔试题。
2)增强代码评审。
代码评审应该在早期就做,高手评初手,评审主要目的不仅仅为了发现和解决问题,更重要的是提升程序员的水平。程序员水平提升后,评审就可以减少次数甚至不需要。
法则9:零缺陷意识
MSF(微软解决方案框架)提到的“零缺陷意识”非常有价值!零缺陷代码可能真的很难写得出来,但零缺陷意识必须有。
作为项目管理者来说,你要知道零缺陷的代码才能准确预测项目的进度;作为程序员来说,你要把这个当成基本的素养,对自己提出严格的要求,不要盲目求快,不要说反正后面有测试,如果程序有问题,那就是测试没有做好。
作为程序员来说必须做到以下两点的最基本质量要求:
1)你的程序能编译通过;
2)你的程序能通过“冒烟测试”。
通过冒烟测试是指:
1)模拟用户的最常见的正常操作,程序不会出错。
2)点击所有能点击的按钮、菜单等,程序不会出错。
这个冒烟测试是程序员自己做的,程序员们要自己擦干净自己的屁股噢!
法则10:避免“外包人头”
某些大公司大国企为了所谓的降低研发成本,会使用一些“临时工”,这些临时工和正式工一同工作,通常正式工干主要的岗位,而临时工干码农的工作。这些临时工是一些合作方公司以“外包人头”的方式租给雇主公司,临时工是合作方的正式员工,但在雇主公司那里他们就是“临时工”。
将软件研发工作特别是编码工作看成是低技术含量的事情,将程序员看成“工人”,这本身就是违背软件研发特点和客观规律的不合理做法!对于一些公司这样的做法,我是强烈喷之的。这样的做法其实不会降低成本,反而是增加不少成本。如果你是公司的管理层,强烈建议你不要采用这样的做法,说得难听一点,这是“反人类”的做法,而且这其实并不是“同工同酬”,其实是违法的做法。
试想一下,“临时工”会有怎样的战斗力?不是他能力不行,而是体制上的问题,他愿意全力以赴吗?软件研发是高技术含量的团队工作,不是靠人多就搞定的。假设企业原本打算使用100名临时工,你不如招聘20名正式员工,20人的正式员工比100人的临时工的工作效率会更高,但总成本节省不少。企业还可以将节省的成本拿一部分出来,用来提升大家的薪金,这样整体效率会提升不少。
如果你的团队中已经有“临时工”了,你也无法改变领导层雇佣临时工的用工策略,你该怎样办呢?
相信你在工作中已经能体会到,你是很难调动“临时工”的工作积极性的,当然会有少数“临时工”是不错的。你可以参考“法则5:关注程序员的需要”,程序员是一种你对我好、我对你更好的善良物种。
小结
有那么一句话:找老公就要找程序员!
这句话不太对,你当女程序员不存在啊,这句话应该是:找老公就要找男程序员!
那找老婆呢?女程序员!遇到单身女程序员,一定要尽早动手,因为她很抢手。
程序员们是可爱的群体,编码是高难度高技术含量的活,希望我们的编码工作能变成富有激情和战斗力的工作吧!
如果本文对你有帮助,麻烦点一下“推荐”啦,谢谢!
作者:张传波
创新工场创业课堂(敏捷课程)讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人