设计失败的挫败感--老资格给你的压力
前言：最近一段时间似乎感触特别的多，心情也特复杂的。也许你曾经有过同样的际遇，也许没有，但是我的目的只有一个：分享，勉励！
在项目中担任架构设计，不是想象中的那么顺利。在最初担任设计的时候，我为一个项目设计了一个架构，而且我自己认为设计的还不错。而且在开发的过程中，组员对于的反映也是不错的。但是越到后来，一种挫败感就来了。
首先，在项目开发之后，有一些组员会陆陆续续的加入，这些组员中有些资格比自己老。就是因为资格老，所以很多时候这些"资深的组员"就瞧不上看我做的架构。不管架构怎么改进，怎么完善，最后总是让他们不爽。有时候稍微出了点问题，不管是自己代码的问题，还是架构的问题，还是服务器的问题.....，最后总是会来一句"设计的什么鬼架构"。不管听没有听见，或者假装没有听见，但是心里还是特别难受的。
但是不管他们的抱怨是因为嫉妒，还是因为架构本身真的有问题，自己都要不断的分析，从业务上，技术上，分析架构存在的问题。尽管心里难受。所以，不要以为担任leade或者架构设计，自己就高高在上了，不是这样的。
还有一种情况比较郁闷的就是：你对于一个问题，想出了一些很好的方案(你个人认为比较好的方案)，当你提出来的时候，有些老资格就会说：你以为这个方法我没有想过？我之前在XXX项目就试过了类似的方法的，行不通...然后就"基里啪啦"的说教一大堆。对于种情况的时候，不要被他们吓着了，一定要自己亲自验证，当然，这里也不是说不吸取前人的经验：你可以加班加点的验证，或者事后验证，但是不管怎么，不要太相信所谓的"经验"，经验有好的，也有坏的。要有自己的立场。
还有些老资格非常"滑"，常常认为自己什么都大风大浪经历过的，动辄就在你面前来一句"想当初，我像你这样大的时候，也和你一样"，然后就说自己怎样，怎么样。最后的想表达的意思就是：你不要试了，没有结果的，等等。有时候，这样的话语，往往给你的热情当头来一盆冷水。
这时候，你一定要相信自己，相信自己就是唯一的，相信自己是与众不同的，他们失败了，不代表你就不能成功。(这点自信还是得有的).不要把他们的失败(也不能说失败了，或者说不成功)的经验套在自己的身上。失败或者说失意的人，往往是不希望看到别人成功的，也许他们是想告诫你，没有恶意；也许他们是想把自己的那个失败者的阵营扩大(以后你就跟着他们一起天天哀悼了)。
或许老资格是瞧不起你，不要紧，这样才能促使你不断的学习，分析，提高。当你在各方面都很强了，而且强大他们无法和你匹敌的时候，他们就不会在刁难你了。而且那个时候，你的心境也不会因为他们而烦恼了。一个人的胸怀有多广，造就就有多广。
说给故事作为结尾：有一个老农，背着一筐螃蟹出集市上面卖。当他坐在路上的时候，后面的人就喊道：老人家，你的框子怎么不盖上了啊？不然螃蟹都跑了。 老农笑了笑说：你来看看吧。老农把框子放下，给那个人看。老农说：你发现没有，只要有一个螃蟹想要爬出框口，下面的螃蟹就会一起把爬上的螃蟹拉下去的，所以，虽然框子不盖上，他们也跑不出来。
忆第一次设计Framework
前言：在进入打算做开发的那一天，就一心梦想着有一天能够成为一个很牛的架构师(相信这也是很多技术开发人员的梦想)。为这个梦想不停得学习，实践。等到机会来临的那一天。
记得，那时，公司来了一个新的项目，我没有担任这个项目的leader。一个很重要的原因就是：我太年轻了。当然，这也不能怪上面，因为公司有公司的考虑。 几乎所有的项目在时间上都是很紧的。我们这个项目也不例外，而且项目的业务比较的复杂。
在项目的分析大会上，我大胆的提出了自己开发的一个Framework，建议他们采用这个开发。其实我并不是突然就随随便便的提出这个Framework的。
之所以有这个Framework的产生，其实是有原因的：在刚刚进入这个公司的时候，就被分到一个比较的大的项目组，当时项目的开发可以说是历尽挫折，但是最后的结果还是使得项目不了了之，变得谁都不想碰的烂摊子。业务需求没有搞清楚是一个原因，另外的一个原因就是技术方面：也是分层，分布式等等，本来是开发者掌控技术的，但是最后却被技术搞死了。
之后，我就从那个项目组中出来了，开始做另外一个项目。我开始认识到一点：搞开发，不是做的项目越多就越牛。项目经验多少和牛不牛，没有什么正比性。可以类比我们当初高考时的那个”题海战术“--题目做的越多，考分就一定越高吗？要带思维和脑袋做事。
那个项目失败之后，确实失败的很大的成分还是在技术上。可是，事后，谁都没有考虑如果改进，如果避免重复的情况。作为一个开发，甚至以后的架构师，我认为，最核心的能力就是：分析问题，解析问题的能力。这不是空话，需要自己去做，思考。思想的高度，决定你人生的高度。
虽然自己当时已经到了另外一个项目组，我还是分析了之前项目失败的原因。万事开头难，其实当初也不知道怎么分析，于是就从DAL，BLL,Service,UI，一层层的进行了分析，认为这个地方有哪些问题，然后一条条的列了出来，并且一个个的给出相应的，确实可行的解决方案。
于是在自己第二个项目中，就汲取了教训，避免了很多在第一个项目中出现的问题。很幸运，第二个项目圆满成功了。
项目是结束了，自己开始发觉：很多的项目几乎都是重头搭建的，在每次项目大会上，都说要在项目中积累通用组件，通用模块，甚至是自己的Framework。但是，真正在做项目的时候，大家都只是想把功能做完，哪里还管什么通用组件，模块。
如果总是这样做项目，人会累死的，而且越来越累(特别是年纪大点的，有了职业病的)。所以，自己就开始思考如果开发出一个通用的Framework，来减少大家的开发工作。带着这个思想，就开始行动。
自己一边做项目，一边总结和记录项目中出现的问题，并记录自己的解决方案。同时，自己也开发Framework。慢慢的，Framework开发的有雏形了。并且认为可以用了，所以在项目大会上就提了出来。在会议中，我自己首先分析了之前项目中出现的问题，然后一个个讲述了解决的方案，并且得到了会议人员的认可。之后，我就推出了自己开发的Framework，并且和他们讨论了这套Framework是否适用这个项目。
最终，项目的leader决定采用。当时的心情很复杂，兴奋，更多的是担心，忐忑不安。担心Framework是否经得起项目的考验，而且万一Framework出了问题，崩溃了，自己要立刻给出就解决的办法。但是不管怎么，自己迈出了第一步。机会是给有准备的人，但是有准备的人要更懂得争取机会。
所以，年轻不是问题，经验可以积累，关键是：要有心。
项目的到底谁说了算
前言：项目到底是为谁而做，一个项目的成功到底是怎么样在评价：是领导阶层肯定，还是客户满意？
不久前加入了到了一个项目组，担任了架构设计，本来是很荣幸的事情，很快，荣幸就成为了”不幸“。
项目是为了参与另外一个公司的招标而做，开始时的情况是：人少，时间紧（一个月），需求不明白。但是上面的领导层说了：自己设计几个场景，自己编几个故事，把流程跑完。然后，一大堆的文档就整出来了。之前也是一个类似的项目，也是demo版的，做了一年。
但是本以为这个项目只是demo版的，很多的数据都是hard code的，流程也是尽量的简化。
做着做着，上头又说了：参照以前的一些系统做，尽可能的做真实：包括真实的流程，数据等。一个月，太紧了，大家玩命了赶。
终于，demo版的项目做的有头有脸了，项目组的人也有了信心。
做着做着，最上头的老大换了（专门负责接项目的那个人，专门为其他的公司提供解决方案的，简称“老大”，老大在总公司，我们在分部）。换了老大，就真是“新官上任三把火”，把之前做的东西几乎全部否定了，UI要重新搞，流程要重新整，最最要命的就是7天之内搞定，神啊！项目的权限控制那块居然是要求一天搞定，一天什么概念：之前demo版的项目中，连表结构都没有的，而且之前的那个老大也说不用表，现在老大换了，就不一样了。
本来设计好的程序，现在就成了代码的堆砌基地，什么重构，什么规范，什么性能，什么架构，在老大们的面前都是：废话，扯淡。老大要的就是结果。
老大每天发来一些新的需求，并且强制的要求立刻实现。终于逼急了，问了项目组的leader：这些需求是客户那里收集的，还是老大们拍脑袋拍出来的？
终于知道了：原来做项目还有更深的内幕：之前换了老大，新上来的老大为了邀功：自己提出很多的新需求，然后开发人员就实现，如果客户很满意，那么就说明现在的老大比之前的老大做的好。而且现在这个项目的成败不在于客户，只要使得几个老大满意就行了，至于最后项目竞标是否成功，都没有关系，关键是老大们要爽。
现在就有问题：如果老大们提出的新需求不是客户满意的呢？
于是老大不停得提出需求，下面的人就开始改，至于项目最后要做成什么样，能不能做完，谁都不知道了。一句话：瞎忙。
总结一句话：搞开发，不是只要技术就可以了的。
版权为小洋和博客园所有，欢迎转载，转载请标明出处给作者。