1.解释做了什么
解释软件开发过程是很让人崩溃的一件事。那些不会写代码的家伙可能在这一行有所了解，但是正如定义所说的，他们不会写代码。在他们眼中，我们就是一群待在昏暗的房间中弓着背噼里啪啦敲键盘的程序猿。
2.可视化解决方案
假设给定一组简单的——难听点说就是考虑不周的——需求，你需要制定数据存储库、代码结构、算法、通信协议，以及只要能解决业务问题就得去完成的各种技术内容。然后，还需要用一种通俗易懂，哪怕是外行人也能明白的方式解释出来，并在规定期限内交付给客户。

3.预估交付时间
这是每个开发人员的噩梦。试想一下，以前一点也没有接触过的任务，突然要你确定完成它所需要的时间，是不是有点天方夜谭呢？可能曾经也写过类似的代码，但是却并不是在有着相同问题和限制的同一个系统中，好吧！
这个时候，那真的只能靠经验了。但是大多数程序员会低估时间，原因可能是因为他们只考虑了编码这部分而忽略了其他。
4.借鉴别人的代码
条条大路通罗马，解决方案也是。借鉴别人的代码可能意味着要花上很多时间去研究上千行代码以了解整个的思路。而且，要是恰巧原先的开发人员一点也不留注释和文档的话——甚至只是个半途而废的半成品项目——那就更加令人头大了！
5.范围蠕变和你自认为神奇的功能
敏捷开发会造成范围蠕变，这让人既沮丧又无奈——特别是当你突然心血来潮要加点什么愚不可及的功能的话，更甚。结果如何你自己心知肚明，你的团队也明白失败没商量。但是客户其实知道得更清楚，所以要是失败不可避免地降临时，那么就全都是你的责任，因为你居然不相信客户的眼光。

6.优化不足和过度优化之间的平衡
复杂的软件永远达不到完美的境界。我们不可能无限制地优化，这也是为什么软件项目从不在规定日期到来之前发布的原因。
另一方面，很多人都会抱有“先就这样吧——以后再来改进”的心态。现在这些代码是可以好好工作，但是这些人也明白这会成为明日的烦恼和失败。当然，你不会再来修复和调试了，它们会被留给下一个可怜的开发人员。
7.测试代码
既可以自己编写单元测试，也可以组团通过软件来测试，不过不要妄想能发现所有bug……
复杂的软件可能会包含成千上万行代码。系统可能有着数十亿种可能的相互作用和路径，想要全部测试是不可能的。
同样的，一个软件在不同的条件下，不同的系统里碰到的软件不同，其交互的结果也不尽相同。我们没办法测试所有可能的情况。
想要编写出好的单元测试是一件既繁琐又艰难的工作。在理想情况下，测试应该在软件开发项目开工之前就写好——但是要是我们先写这个的话，我们怎么向客户解释四个星期过去了为什么一点进程都没有？
单元测试不会突出显示每一个bug。虽然我们都希望能有一个专门的小组来编写测试然后积极去发现问题，但是由于现实条件的限制——成本控制和时间限制，这对于很多项目而言都是奢望，所以大都需要开发团队自己来编写测试。而他们在编写时总是会无意识地避免任何不妥当的边界情况。
程序员会用一种逻辑方式去解决问题，但是用户很少会这样做；所以有时候用户会帮我们找到一些我们自己察觉不出来或者根本想不到的问题。

写文档的确是费时又费力。很少有开发人员擅长并愿意花时间去写/阅读文档。
9.处理硬件问题
我们每天都需要处理各种技术问题，例如硬盘崩溃、驱动冲突、软件故障等等。虽然这并非是我们软件开发人员的工作，但是要是不解决这些的话，我们是没法继续工作的。
然而很多人却会莫名其妙地认为，搞IT的就应该懂所有关于电脑的东西。当他们碰到问题，他们第一时间想的就是联系我们来解决，而且不管什么问题都这样，真心是让人无语又崩溃。
10.和人打交道
上述任务通通可以总结为“如何与人打交道”。令人奇怪的是，非专业人士不会去指点飞行员应该如何驾驶飞机，也不会跑去和电工说我的房子需要重新布线等等，但是他们却非常喜欢在软件开发上面指手画脚，提供各种异想天开的点子。
天瑞地安软件开发部工程师们：软件开发过程中需要工程师们认真、细心、各个环节要做到无缝对接。这样才能事半功倍！