作为一个程序员，肯定听过老板或客户问过不下数千遍这样的问题：请问开发这个软件要花多久的时间？如果很诚实的回复他们：该花多少时间就花多少时间。还会招来对方不放弃的逼问：所以是多少时间？至少给一个估计时间！
说到这，你心中是不是一把火已经升起来了呢？但再怎么怒火中烧，也不能让老板或客户不开心，所以只好丢个随意的数字好安抚老板或客户的情绪，表面上好像给了个交代，老板和客户也很满意的离去，但程序员真的有这么容易可以在预估的时间点内完成吗？●软件工程师为什么无法估算时间？用一个经典案例来解释再贴切不过了：假设我们要从旧金山徒步，从海岸线走到洛杉矶去拜访位在纽波特海滩的朋友，首先先摊开地图，沿海岸线画出路径，距离大约是英里这么长，预估如果每天以10小时为单位，每小时走4英里，一天下来就走了40英里，只要10天就可以到达目的地了！于是兴高采烈的打电话给朋友，还预约礼拜六的晚餐，当天晚上6点我们肯定能出现在门口。路线规划好了，餐厅也订了，双方都已经迫不及待能顺利会合！起个大早，开始迎接这未知但充满冒险的旅程，但…事情没想像中简单呀！这道海岸线拐弯足足就有一百万条，也就是说原先预估的英里仅能勉强走过半月湾，还有多出来将近英里等着我们…。●客户以为我们故意打混，但我们其实是忙着在解决所有未知变数此例子是否让你稍微理解程序员的处境呢？即便程序员给出一个五天、两个礼拜或一个月的估算时间，但谁也说不准是否会发生任何不在预期内的状况，例如某个套件突然无法使用，或跳出让人摸不著头绪的bug，久而久之程序员只好选择在时间内灌水，预先替「突发状况」保留缓冲空间。之所有会有此现象的发生，首先就要了解程序员最核心的本质是在，此工作并没有任何模组或现成程式可套用，而是需重头思考如何利用手边可用的工具来设计出新的东西，当然也有例外的状况，如果程序员曾经有足够经验涉足多项未知领域，而且跟之前做过的案子不谋而合，那才会有办法能从经验中推测完成的时间，这也就是解放号提出的"复用人的方式复用代码"的理念，就是通过复用程序员已有的经验，帮助用户真正在可控时间内高质量完成项目。●“九个程序员去生一个产品就能达成绩效?”有些老板或客户认为，只要让越多程序员进来投入越多时间，就能加快完成整个软件的完成速度，而在实际中，即便你在一个软件项目中增加再多工程师，团队同样还要再花时间开会、确认API、或找出到底bug是在哪个code里，到最后还是要花九个月的时间完成一个项目，更严重的是还有可能因为人员增加意见增多造成延后。所以在面对人员缺失问题时，选择众包的模式显然比盲目招人更能有效解决临时性的问题。说来说去，程序员口中常说的“该花多少时间就花多少时间”的背后，唯有实际去做才能得出个答案，但问题就是老板或客户讨厌这种模拟两可的说法，因为他们已经根深蒂固的认为预估就是一切，因而迫使程序员不得不随易捏出个数字好给个交代，此反而无行中让进度远比预估的还要落后。总归而言，不要期望老板或客户从此不再继续问这类的问题，作为技术人员：■就是帮助老板或客户明白预估方式的错误带来的后果；■不要用单一功能去衡量时间，而是以功能的整个技术基础为单位；■切记永远不要把估计时间当作承诺，你可以把它视为是对自己的任务所下的战书，并找到能让自己提升生产力的方式，设法处在一个高效率的环境下工作，如此一来也就能有效控制开发的时间。
服务号ID：jointforce_service北京白癜风医院的地址北京白癜风医院好