摘要：XXX 作为一名架构师从程序员转到分析设计员再就爬到了架构师群体。当然架构师也分很多种比如应用级架构师，信息架构师等，从应用级架构师又可进一步发展到企业级架构师和平台架构师。当然你可能对这些不以为然，但这却是一个架构师的发展之路。本笔记是在XX培训时的体会，说实话本人在这领域也是菜的要死，不过我的研究方向是这个，以后继续努力，请大牛们多多指导。
正文：
有人说不要提前进入架构领域，过高的理论层次只能使你悬在半空，结果大家都知道....。不过理论先学并不裨益。就像我们学 TDD,DDD,AP 一样，虽然用到的机会不多，但他的思想会影响我们以后的软件之路。
对于应用级架构师来说除了对一些模块分割，框架选择，关键技术设计等的决策，在有比较难处理的就这需求，如果你是从程序员上来的，想必已经工作了很多年，习惯了研发室里一坐几天的感觉，很不适应和那些抠门的领导狡猾的客户们攀谈，做什么都绕圈子，很费精力，稍不留神就被套一番。所以说一般在需求调研时都会有架构师，领域专家和项目经理参加，可能这也是一个比较好的组合。
需求开发的主要困难与对策
1.知识技能问题
– 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但
当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充
满挫折的“第一次”，不可以逃避。
– 最好请既懂软件又懂应用域知识的行家来帮忙。
– 当需求分析员缺乏应用域知识时，他该怎么办？
• 快速获取领域知识，借助于互联网；
• 与领域专家交流获取领域知识；
• 与跨互访不断交流获取。
2.用户说不清楚需求
– 用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。
– 有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。
• 例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。
• 例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数
不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。
– 有些用户虽然心里明白想要什么，但却说不清楚需求。
• 比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿
鞋子去试，试穿时感觉到舒服才会买鞋。
– 需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。
– 无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑
战。
3.双方误解需求
– 人们在交流的时候，经常会发生“问非所求，答非所问”的事情。
– 有时用户会把开发人员的建议或答复给想歪了：
• 有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种好处，用
户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起
来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”
– 而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就
错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连 高智商的外星人都不能避免：
• 有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓
门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”
– 不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。
4.用户经常变更需求
– 需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题
– 如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产
品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方
应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。
– 如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了
“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
– 其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。
本博客为学习交流用，凡未注明引用的均为本人作品，转载请注明出处，如有版权问题请及时通知。由于博客时间仓促，错误之处敬请谅解，有任何意见可给我留言，愿共同学习进步。