角色的转变

       我2005年出来工作到现在也快两年了，时间过的飞快。想来在这两年中也没做过很自豪的东西，就是东做做，西扯扯。感觉对整个架构的设计没什么了解。不过现在机会来了。公司决定要做一个比较大的平台，涉及到web，wap，kjava，pc客户端的东西，开始公司成立小组的时候，自己很明确自己的角色，开始我感觉公司就是让你做编码，把这些功能做出来，但，实际却不是这样，前几天这个项目小组去喝早茶，公司领导绕了很多弯子，最后才明确，要我来定需求，并定义整个平台的架构出来，说这样很容易让一些人加入进来。哈哈，以前做编码习惯了，反正来了需求就帮他实现，其他都不管。一开始角色还专变不过来，跟领导沟通起来出了很多问题。
 
    说实话把这么大的担子给我，我压力大啊。我相信在这个论坛的很多牛人都有曾这样的经历，可否给我一些建议啊。

      从一个编码设计到一个架构设计的转变需要经过些什么历练。高手们，砸砖吧。^_^

需要一些实际的经验和综合的多方面能力，其实很难一概而论的，你做的越多，知识面越广，经验越丰富，自然越拿手。如果心里还没有什么谱的话，那么就把握一个简单原则，越简单越好。

robbin说的很对啊。
开始我觉得，把平台设计的完美点，觉得越难才能体现出自己的水平，不过发觉错了，简单才是美，简单才是一个架构设计师的终极目标。
个人觉得越简单反到是越难设计了，把握一个原则让客户觉得操作简单，让开发实现者感觉到简单。
我想我的目的应该是这样。

恭喜恭喜

写程序得时候，考虑得更多是自己如何做。做架构设计得时候，就要为所有得开发人员考虑周全，他们想到得你要想到 ，他们想不到得你也要想到。

另外，既然刚开始转变，就一定要多请教其他人，多跟同事沟通，集思广益。 出现了问题要及时得向上反馈，这样能在出问题得时候尽量减少影响和危害。

总之，现在看问题得角度要比以前更高一些才好。先把握整体思路和规划，然后在细分下去。 千万要理清自己得思路，不可以自己混乱。

你就想所有的人都很傻。。。。
只要能一下办完的事不要让他们作两个步骤
能不用看的东东就不让他们看，
能简单明白就简单明白。。。。


用不着，你又不是神，所有的事都要干的好。

敏捷为上

挑战不同角色 “假装”自己很厉害的样子  慢慢的就变成了真专业。。。。。

我见过一些人，有些时候你如果不把事情都给他交代清楚，他会自己发挥自己点思维和想法，按照自己得想法来做，等到你review得时候，才发现原来他所做得并不是按照要求或规范来的。既然lz是负责需求，架构设计，那么就一定得把设计架构得规范和要求都定出来，通知大家，让大家都按照这个来办。 

你把所有人想得很傻，可惜别人都不傻，谁都会有自己的想法。

而且，我的意思是让lz把份内的事情都做好，弄清楚条理顺序，何为“要把所有的事都干的好？”。如果连需求，架构设计都不做好，其他的人如何继续下去？

哈哈。看了这么多高手的肺腑之言，个人也有感受。
说敏捷吧，我自己也想，但一些共同合作的业务员不了解，跟他说等于对牛弹琴，而且他们也老催你，要求你给个真体的思路出来。
沟通也要转变角色了

：），我能体会博主的心情
我去年刚毕业进入现在这家公司，因为只是进来时说对架构设计有一点经验和很感兴趣，竟真让我去做架构（不过实际上也只限于技术选型和系统体系设计，不涉及具体业务），拜网络所赐，有很多优秀的开源架构和设计范例可供参考，学习了很多，有机会能接触到j2ee系统架构的全貌，现在我们项目是C/S + B/S架构，然后整合jms，jbpm, IM等等一堆开源框架。从刚毕业只会用webwork和简单的spring,hibernate应用，半年后到现在整合起公司整个项目架构，定下开发规范，并在公司做培训，真是非常有益的经历，遇到很多挑战，也学习了很多技术之外的东西。

其实很多东西都是在javaeye上学习的（CSDN就免了），比如robbin关于领域模型设计的巨多的讨论和系列，远程调用也采用robbin的方案，摒弃DTO模式
对于j2ee，我始终感觉都是一个新手，也谈不上什么经验，只是聊聊自己的经历和体会，希望能和博主共勉。