软件项目开发之实例类比

     今天遇到了一件非常紧急的事情，由于中午太困了，回家（家离公司有10分钟的路程）一睡就睡到了离上班时间之有5分钟的时候，我突然醒来，于是就拼命的往公司跑，一起跑的有另外一个同事。两人一路快跑，到了公司楼底，遇到了其他的同事，此时已经是只剩下可能不足2分钟的时间了，根据公司的规定，如果中午要是离开公司的话必须要打卡下班，但是如果不离开公司很远的话就不需要打卡，我还是打卡了，和我一起的那个同事也打了，而楼下遇到的同事则没有打，他们一直和我们说，时间已经不足了，迟到已经成为定局，于是我们非常的着急。到了8楼公司，一看打卡机只剩下了8秒钟，于是我就打卡（打卡是以指纹打卡的），但是由于手指有油，打了2下也没有打上，和我一起的同事也非常的着急，（他申请了数字打卡，所以只要按数字即可打卡，但我没有）他就在我第三次按下指纹的时候，也按在了打卡机上了，而电脑毕竟是单用户操作式，在数字和指纹同时操作的时候，出现了暂时性死机，剩下的5秒钟浪费了（过了10秒钟后恢复正常），两人都迟到了，但是后来那个同事以其他理由与人力资源部欺骗了而没有迟到，而我也也申请说指纹无法识别，也用登记姓名的方式避免了迟到。 
    看结局可能不算太坏，但是从整件事情留下太多思索，毕竟两个人都没有打上卡，我们现在可以从新让事情发生，把成果数字化，如果我打上卡数值为1，如果同事打上卡数值为，把时间发生的顺序做如下假设：
 1．如果我先按指纹，（我每打一次指纹的时间是1秒，而他按数字键只要2秒），我即使按下4次，也无法打上，他仍然可以打上卡，并且能有1~2秒的安全时间，我也可能因为多两次机会而打上卡，实现双赢，至少也能打上一个卡，也就是最后结果 >= 1
 2．如果让他先打卡，我可以更多的时间的打卡，他花掉2秒，我有6秒的时间，可以有至少6次的机会打卡，结果也是 >= 1
 3．打卡不上的主要原因是手上有油，如果我在上电梯的时候把手指擦干净，我可能就不用2次以上打不上，而可能只用2秒内完成打卡，而最后结果 = 2
 4．没有安排我和同事的打卡顺序原因是我们不清楚我们是否迟到了，因为我们的表与打卡机上的时间是不一致的，如果知道确切的时间，我们可能会抓紧安排，选择让他先打卡，我也有机会把手指擦干净
 5．假如我知道同事不是和我一样是按指纹进行打卡的话，而是事先知道他是按数字打卡的话（并且能保证一定能打上卡），也许会更加的应该选择让他先打卡。
 从以上的假设可以看出，造成整个事件的失败的主要原因是，不了解同事是数字打卡，没有做合理的安排，没有把手指擦干净，更不应该两个人抢着打卡。如果我们要把流程从新梳理一下，应该这样：
 对表（确保打卡机时间与我的手表时间一样）à与同事沟通（询问他会用什么方式打卡，并了解打卡费用）à 安排我们的打卡顺序（保证我们两人都能打卡成功的顺序） à 按照预定的打卡顺序执行 à结束
    看看，如果按照这样的一个安排，也许就不会出现我们的迟到的悲剧，也用不着我们通过撒谎或者用敷衍的办法搪塞事情的失败。
    其实拿这个例子看软件工程其实是一个很生动的教程，想想，我们在开发软件和或者执行项目的时候会怎么样？
    我们是否会关心我们当前所处的环境变量呢（对应于时间是不是准确的），我们是否会有更多的沟通（对应于了解同事的打卡方式和时间），我们是否会按照具体的流程开始我们的工作呢（是否会在上电梯的时候去擦干净我们的手指），是否做出更好的安排让项目流程有条不紊的进行（对应于安排两人的打卡流程），是否会在危乱的时候以利益最大化（对应于不应该两人抢着打卡）。其实如果我们如果没有做好这些工作，我们可能会发生很多尴尬的事情：
1． 不知道要做多少工作，时间过去了，事情也做了不少，但是始终发现事情没有作完，但是又没有办法去控制，因为没有一个能让自己了解的项目进度或者相关的信息去知道自己当前的进度
2． 不了解自己的合作伙伴的特点，由于减少沟通，经常的出现多人的项目开发过程中，一个人无意间把别人刚刚编写好的改进版本的文件覆盖成为上一个版本的文件，多人开发的函数或者对象接口不一致，不得不重新开发
3． 没有合理的工作流程，让有的人在等着没有事情可以做，而有的人却忙得要死，而实际的项目进度却又拖延下来
4． 对已经制定的标准或者流程不认真执行，按照自己的个性或者习惯，开发出一些垃圾代码，让项目中的其他程序无法使用。
5． 当进度无法完成的时候就用各种谎言遮盖自己的失败，于是出现很多可笑的借口
其实生活中很多的事情都是相通的，认真的想想想其实都是很有关联的，看你会不会把一件事情的失败看做是另外一件事情的启迪。