大伟 2019-3-7 13:40:

是不是对需求能力不强的人来说，跳过需求工作直接写代码更好？我发现在写代码过程中对需求的认识更清晰了。

UMLChina潘加宇：

这是逻辑上的错误归因。我先说一个笑话作为类比。

*****************
女儿：妈妈，二年级是不是比一年级懂得多呢？
妈妈：是的。
女儿：那我有个好主意，从今天起，我不做作业了，等到二年级的时候，我再来做一年级的作业。等到三年级的时候，我再来做二年级的作业。
*****************

之所以"对需求认识更清晰"，是因为随着时间的推移，开发人员和涉众的交流以及对需求的思考不可避免地增加了（就算交流和思考的方法再差），这个时间里干的活是不是写代码其实关系不大。如果这个时间有的放矢地用在需求上，"对需求认识更清晰"所需要的时间更短。

以下是针对此问题的扩展评论。

如果需求出了问题，在投入了分析设计的工作量之后再修正，损失的代价很高昂（Barry Boehm的研究是高达100倍以上）。所以需求是软件组织最值得改进的环节。这个道理大多数软件组织是懂的，即使有的组织暂时不懂，碰壁之后也很快就会意识到。于是领导下定决心，"下一次要重视需求的采集"。

可惜开发团队缺少需求技能，需求也不是蘑菇，乖乖地躺在森林里一采就得。

很多时候开发团队也匀了时间来做需求，但不知道具体该怎么启发，怎么建模。一拨人到了客户那里，随便看看，问一些问题，开个会，就不知如何往下走了。开发人员只好自己"头脑风暴"，胡乱猜想系统的需求，然后投身于最擅长也最喜欢做的事情――编码。

更要不得的是，有些开发人员为了掩盖自己的无能，干脆假装需求技能不存在，以"敏捷"、"迭代"为名，放弃了这些技能的修炼。

"敏捷"、"迭代"只是一个底线，不是上限。

就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说："唉，这些技能没用的，反正再高明的大夫，也不能一个疗程把患者治好，干脆我也别花那么多心思了，先随便给患者打一针看看吧，不好再来！"。

确实，再高明的大夫也没有把握一个疗程就治好患者，所以要按疗程试试看，但是每一个疗程中，依然要尽力检查、诊断、拟治疗方案。检查、诊断等技能越精湛，所需要的疗程就越少。