本文主要是介绍以为4天能搞定的项目，结果搞了近一个月……，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
有朋友提到这个问题：
我最近做一些小项目，兼职的，几个人讨论着4天能完成的项目，结果整个周期花了将近一个月。
预计是4天，结果几个人时间不合拍，花了一个月。 还有时间也不统一，沟通不方便 ， 光沟通都花了不少时间。一般是客户把需求传达给我，我再传达给开发人员，这样从中就浪费了很多时间。并且客户需求不是很明确，我的理解和其他伙伴的理解也不一样。因为合作的少，没有那么多默契，技术上面也有时候对接不上。
俺的见解：
开发去估算时，往往假定需求就是这样的了不怎么会变，然后估算开发工作量时，往往认为一次可以搞定，不会出什么大差错，不需要啥沟通成本，测试可以一次通过，甚至没有估算测试和修复缺陷的时间，也没有估算做出来后客户变来变去的时间，等等。
这样估算就会变得超级乐观，根据这个估算做的判断都会失算。这是学习和成长的过程了，至少先做到敢于估算，这还是很不错滴。
导致估算严重偏小，还有两个我们容易忽略的地方：
1）项目组内部的磨合
项目小组成员以前没有一起在项目中工作过，会出现很多磨合的问题。一个3个月的项目，理想状态下项目小组至少要磨合1.5个月，严重情况下项目完成了项目小组仍然有很多磨合问题。要完美解决磨合等等问题，一方面需要大家有一起工作的经历，一方面要想办法找到让项目小组合作无间和高效运作的方法和过程等。
2）和客户的磨合
首次和这个客户做项目，各种磨合问题就会来了。客户的难缠、反复、深不可测、最后让你大吃一惊等等状况都会出现。未做项目之前，你见到的客户是“表面”的，甚至让你认为是“友善”的，但做项目后特别是涉及到利益时，你才能逐步发现客户的“真面目”。
从另外一方面看，客户对我们的感觉也是类似的，开始可能觉得我们挺高大上的，随着项目开展，才发现我们低水平、理解不到我的说话、承诺的东西做不到、经常延迟交付、改一点东西诸多理由和推托等等。
估算的时候，这两点可千万不能漏了，可以将保险系数搞大一名噢，咔咔
经验值介绍：将你原来的估算值放大200%，其中100%给内部磨合用的，另外100%给跟客户磨合用的。（仅供参考，后果自负）
项目估算是个老大难的问题，我的这篇文章供你参考，这是系列文章的第一篇：
实践敏捷估算（1）——不仅仅是估不准的问题
http://blog.csdn.net/fireball1975/article/details/28437245
这篇关于以为4天能搞定的项目，结果搞了近一个月……的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
