spring, ruby on rails, Zend都是这样的工业级强度的full-stack的设计，我们的设计如果以他们为中心，生产力得到了极大的提高。

  但是我现在厌倦了，屁大的事，就要装模做样的写一个DAO，写一个Service，写一个Action，再写一个JSP，八股文式的开发模式，味同嚼蜡。我们的代码仍然在急速的膨胀了，我们仍然感觉很累，我们的千行代码出错率仍然没有减小，这不是个好事情。

  有人说，这就是设计吗，这连头猪都会。

  我做了电子商务网站多年了，无论是管理还是技术，都非常的有挑战性。

  从用户角度，前有看不见摸不着、挑剔的、脾气暴躁的互联网用户，后有工作量巨大、业务繁忙的后台业务部门用户，他们狠不得，用魔法棒，一指，网站上就会有这个功能，时间不等人。

  可是电子商务网站角度来讲，不同于一般的内容门户网站，出个错没有什么大不了的，当用户在我们的网站上看到的一切东西都是有法律效力的，当用户下单成功交易的一瞬间，这种关系已经实施，出个错，谁也担当不起，大家不记得DELL门事件，网上直销价格报错了，引出了多大麻烦，在外面，有公司担当着，在公司内部，估计当事人，也是痛苦的不得了。 

  我们即要追求快速开发，以用户为中心，拥包变化，又要保证工业级的强度的稳定。

  一般的发包，从需求收集，明确，整理，发布release计划，拉分支，开发，内部测试，提交功能测试，压力测试，on stage, on production，上线跟踪测试, 合并分支, 这样的流程，一个环节都不能少，不能出漏子（当然只是从理论上保证）。
   这样即使一个月发一个包，开发时间不过10多天左右，这样的发包速度，还是满足不了要求。当我们对他们说，这个功能，下个月才能上线，用户会无辜的睁大双眼，看着你。
   所以在设计这个层面上，我们需要更多的重用，更多的粗粒度的，工业强度更强的重用，可以更高层次的在大大提高我们的开发生产力同时，减小我们出错的概率，当你的程序出错的时候，你一般不会就认为是springe的BUG造成的吧，是自己的代码出错。 

   我们不需要供养着一批只是评审工具的、满嘴术语、动不动就用可用性、可扩展性之类的Matrix表格让我们看他们的评估结果的架构师。

   我们也不需要满口hign-performance、large-scale、群集、ajax，光说不练的家伙，对于一个成熟的电子商务网站来说，基于Scalability的架构已经趋于稳定，并有专有团队来维护，用不着你来天天搞群集。

   我们也不需要只会写个JAVA类的所谓的设计师。 

   我们需要的是full-stack的设计，我们需要的设计师，对于互联网应用来说，三层都应当相对精通，就像习武之人，任督二脉都打通那种高手，才是NB的高手，从front到database，都有要丰富的经验。

   我们需要的是基础扎实的，有热忱的设计师，能够真正的帮助开发人员解决问题，提高生产力，而不是那种只提供约束、规范，不提供方法，不解决问题的人。 

   full-stack设计体现的是一种设计思想，是要在不管是微观还是宏观层面上，去应用这种思想，并不是要一定要设计出像spring那样大的东东来，也不可能。 

   我以一个电子商务系统当中的业务基础数据字典子模块的设计（很多人都做过，可以做一个对照），在一个三层切面，论述一下full-stack的设计的具体应用：  

1.抽象描述层需求

(1)表现形式：下拉框、单选框，多选框，列表框，表格，文字
    不同的数据有不同的展现形式,  同一数据在不同的页面，也有不同的表现形式
    例如：我们在旅游网站上看到的，有的网站在选择城市时，是下拉框选择的，有的是弹出窗口，并将所有的城市按表格的形式列出来的， 还有的就是列表框显示的

    对于多选框，一般都需要自动添加一个全选的checkbox，并生成全选事件，不要调用者自己再写。
    如果是下拉框，要能够自动添加一个“请选择”的option或者从传参数中指定一个header. 

    默认选中值，当传入默认值时，能够设置默认选中。

(2) 控件事件模式
  要能够提供Callback，如Listener、Observerable模式的事件注入。 

(3)基础数据在页面上的布局方案，
   基础数据是放在Table的TD单元当中，还是DIV当中
   对于多选框的展现与布局，当多选框多的时候，使用表格来布局，来保证换行时，自动对齐。

(4) 数据转换与渲染

   在页面上，能够将ID值，转换成用户可读的文字值，如订单状态1转换成已成交，2已配送，3，已取消的形式。 

(5) 前后台数据交换机制：

    你可以使用异步应用，如ajax来解决问题，也可以使用同步的如JSP标签来解决问题。

    基于ajax的前后端数据交换格式：XML, JSON, DWR, 自定义等等。
   作为你自己的单独的应用，没有必要这么花哨，无论那一种，都可以。但如果是作为开源的、或者是商业产品，给未知的应用调用，就要考虑可扩展性，让调用者可以扩展，使用自己熟悉的方式，如EXT提供了XML,JSON都多种reader，你也可以扩展与DWR集成。 

2.抽像后台需求

(1)多数据源的屏蔽：XML文件配置、properties配置、本地数据库表、远程Webservice接口。

    如果是基于页面指定的查询条件，动态查询的接口，如类似于ibatis的查询接口

    List ds.queryForList(queryID, paramMap)   
  

(2)排序

   a、不同的基础数据在页面显示时，有不同的排序需求

      如城市是按拼音排序的，
      订单操作步骤数据是按序列号来排序的
      没有要求的，默认是按录入顺序来排序的  

   b、排序即可能在后台排序，也可能在页面上基于javascript排序
   所以无论是在前端，还是在后台，都要提供一个倒钩接口，让调用者可以按自己的要求对数据进行排序。 

(3）分布式环境的要求
    分布式在中大型的电子商务当中，几乎是必须的，作为底层的支持，为其它分布在不同服务机器上的应用都要提供共用的的基础数据，同时要缓存，当数据修改后，要刷新缓存，并要通知第三方的应用。如机票、酒店、自由行、呼叫中心、配送、结算中心等等十几个子系统应用都要调用城市、支付网关列表等数据。

(4) 数据管理
  添加、修改、删除基础数据的权限.
  数据排序处理。

(5) 缓存
  缓存是一定要有的，一个是数据中心的缓存，当远程调用者又在本地做缓存时，数据变化时就要提供远程通知的接口，否则调用者客户羰的数据就不会自动刷新。

  缓存，可以基于spring+EHCache，配置缓存方案和策略。也可以通过适配器外接到其它的缓存配置方案上。

设计实施:

BasicData.config:{

    type:'select',//*下拉框、单选框，多选框，列表框,  文字, tbody

    id: 'select_id', //*指定绑定的控件ID，如果ID不存在，则系统会创建指定类型的控件，否则就绑定

    name:'city',//控件名称，不是必须的

    parentID:'div_city', //*父类容器ID，如果容器ID是tbody，则数据会自动填充到表格当中

    defaultValue:'1,2,3', //默认值，对于多选框，多个默认值时有逗号隔开

    resourceId:'', //*传给后台的基础数据标识，根据此代码，可以获取到指定的基础数据，如送票城市、转账银行等。

    autoCreaeSelectAll:'y', //是否自动生成全选 

    header:'请选择',//如果是下拉框或列表框，要生成一个header

    event:{name:'onchange', event:'changeChild'}, //事件监听

    comparator:'compare',//排序比较函数，

    cssStyle:'', //CSS风格

    paramMap:{} //用于后台动态查询的查询参数

    datasource:ds//设置数据源，可以为空，系统自动使用默认

}

调用者：

 /**

 *获取信用卡列表，进行复选框排列

 *@divID 你设置的DIV的ID号或其它父控件ID

 *@paramName 控件名称

 */
function setCreditCardList(divID_, paramName_, defaultValue_) {

    xBaseData.draw({type:'select', id:paramName_, name:paramName_, parentID:divID_, dfaultValue:defaultValue_});
}

整个方案实施的效果
  1.几乎是一劳永逸的解决了基础数据的需求问题
  2.开放者只需要在页面，一行JS代码或一行标签，就解决了问题，不用关心其它的东西了。
  3.使用者已经忘却以往的诸多不便，对一个局部的编码者而言，变化是小的，对于设计者，从全局几十个子系统，上百名开发者而言，效率的提升是显著的。所以设计者的格局要大。

  4.关于基础数据出错的概率，当然减小了。

　　一些优秀的开发与设计思想或技术，如TDD、MDD，大部分只流转于个别经验丰富的开发人员之间，在团队项目开发中，不见了踪影。

　　这些都非常不利于个人和团队开发经验的积累，更不利于推广。

　　虽然这方面的缘由甚多，例如，在大公司，更倾向于按部就班的，流水化作业的形式，大多的领导，希望以文档驱动的方式，来进行作业。例如在Microsoft，也是个别的团队首先偷偷摸摸的搞起敏捷，然后才得以向其它团队推广，但推广的方式是思想沟通、培训多于实际运作。（见CSDN程序员２００６年杂志）。

　　连Adobe这样有名的技术主导型的公司，，也不过是在2006年开发CS３的时候，才改变以往，吃尽苦头的，BUG成堆的，瀑布式运作方式，开始转向迭代增量开发。（虽然虽然迭代，在９０年代，就已经开始了）

　　参见：Adobe edits the development cycle　http://www.regdeveloper.co.uk/2007/03/08/adobe_cs3_development/
　　当时采访Adobe photoshop团队时，一个很直接问话：
　　If it's such a good idea, why did it take so long – and how did you manage to change this time?　（如果这是一个非常不错的方法，为什么你们到现在才开始使用？你们是如何在这次项目当中，转变自己的？）
　　
　　但是更多的方面，还取决于团队中的每一个member.首当起冲的是Leader，是否有丰富的开发经验，是否有执行力，是否有Open的精神，能否坚持不懈的把敏捷这种思想，通过不同的形式，一点一点的展现或灌输给团队。
　　一个自适应的团队，首先要来自于一个自我调节的Leader，能够通过沟通、持续改进等方式，来不断的调整自己的管理方法，不断的改进开发的过程，并且能不断的改进团队的思想，使团队的成员，不断的成长。
　　Leader也需要学习，需要成长，在敏捷的团队当中，大家都是互补的，不存在junior, senior之分。

　　所以团队的精心打造，就在于互补，很多领导寄希望于万能的Leader,　这往往是失败的开始，Team Leader往往成为进度的瓶颈，delay的主要因素，为什么？因为他只是扮演了一个救火队员的角色，到处都是失火，如何能救的过来。

　　自适应的团队，就在于人人都是主动的、自发的。问题出现的时候，不在于是你的问题，还是他的问题，而是立即解决，不是积累到失控的时候，才去解决。

　　所以打造这样的团队，不仅仅是对Leader要求高，对于团队中的每一个人要求都高。例如对于迭代中的一个best practice，就是要求，在每一个周期的，Time-box控制的都是相当严格的，要求Leader每天，都要跟紧成员的开发状态，以求每天都有结果。如果不是一个自适应的团队，如果一个团队有几十个人，那Leader都要累死了，每个人的座位走一遍，都快要下班了。

　　有人会说，这是太理想化的东西，我想，这是一个思想层面的认识问题，一个推动力，一个唱黑脸，敢于在组织架构上动刀子的问题。

　　这几年，我经历的团队当中，往往都是开始的，两三人，不断膨胀到十人左右，但真正起作用的，不过１／３，砍掉一半，团队照样跑的转。

　　我想一个３、４人的敏捷小分队，要胜过１０人的团队，很多PM总是在后期抱怨缺人，领导也一味的满足他们的要求，不断的在中后期加人，却不愿意在团队成立之初，去好好的考虑团队的建设问题！
　　

　　考虑一个团队的架构，很多人，自然会想到首先从技术方面想，如高级程序员，中级程序员，普通程序员，系统分析员等，一些大的公司，也会设这样的岗位，不同的岗位，Money不一样，职责不一样。这不过是一厢情愿的典型的人事设计方式，非常粗粒度的切割方式。

　　其实从技术方面，来考虑，是打造Team的一种主要的方式，但也并是说用这种无知的、分级的方式打造，这样只会损害团队的合作！

　　对于技术方面，要结合项目的特性，进行精细化的考虑，如果不知道怎么做，可以看看Microsoft的用户体验团队的组织架构：

　　
　　另外，也可以看看我最欣赏和羡慕的Google的开发小分队的组织架构，就像三角洲的小分队，精悍无比。
　　一个Team　leader, 一个用户体验工程师（不仅技术好，人机交互的理念也要到位）,一个teser.

    目前的开发人员，很多都不满足不了这样的要求，很多程序员，除了会写个Java代码，其它一无所知，甚至不知道怎么去写HTML代码了，怎么可能去做一个解决问题的开发人员？我现在的项目，采用的是原型迭代的方式，项目中的几百页的静态原型，都是我一个人做的，我想交出去，没有一个人会！
    现在的三层开发，误导了技术走向，很多人以为只会一层就够了，不会SQL，不会javascript，页面也不会写，要汝何用！

　　其实从管理、自制和思想层面，也是另一种渠道。团队中人员要考量他的交流、沟通能力，他的思想层面，是否有团队精神，是否能够接受新技术，热爱技术。对于恶劣的磁、破坏性巨大的程序员，要敢于清除出队伍，避免毒性扩散。

　　这是不是，还是非常的理想化，也许你们还是接受不了，宁愿十几人的干活的热闹场面，不愿意５个人以内的敏捷团队？

    1. 库表的复杂度，首先取决于需求，不取决于设计，设计能力强的人，也要遵守库表设计的规范，从巴克斯三个范式上，原则上也要遵守。不能说用了Hibernate,自己的库表设计能力就强了。不能为了用Hibernate，就去一味批判复杂的关系不对。复杂的关系设计对不对，首先取决于是否有复杂的需求，其次才取决于设计者的能力。

    2. 只要你用的是关系数据库，就必须要明白，为什么叫关系数据库，而不叫面向对象数据库，把面向对象的那些观点，拿到库表设计上，后期维护和调优上，你要担起责任，不能让开发人员替早期决策人员擦屁股。我见过有的人，打着OO和扩展性的旗号，硬生生的把一个表，拆成了三个表，而这三个表，本来，只需要增加一个类型字段，再做一些冗余，就可以是一个表。现在查询时，还要把这三个表Union到一块来查。当需求变更时，增加一个字段，不仅要改变三个类，还要改变三个表，简直是乱伦。

    3.One-One的库表设计，对于DBA来讲，并不是一个best practice的设计。不能为了Hibernate，刻意把大表拆成小表，再用几个小类，做成One-One的映射关系。整体性，是不能随便的分割，毕竟开发人在调试、测试和维护的时候，更喜欢看数据库里的数据，本来一个SQL，就查出来，现在要到多个表中去查。

    4. 增删改存的实体维护
       Ibatis比不上Hibernate，说实在话，现在让我写SQL来维护一个多对多关系的实体维护，我都要考虑上半天，别说写代码了。

    5. 你需要写原生SQL吗
       首先你要确认，你项目的要求不需要写原生SQL，再来讲Ibatis和Hibernate的好坏，在写原生SQL上，特别是动态生成的SQL，ibatis比Hiberante有得一拼，ibatis就像一个模板一样，将SQL写在配置文件当中，集中配置，特别方便技术领导者监控项目成员写的SQL好坏，而且没有什么学习曲线，就写SQL就完事了。

       有人会说，Hibernate也支持写SQL，但是写代码当中，就失去了原来基于Hibernate的DAO的简洁性。那个DAO一点也不简洁，如果你将动态拼SQL的代码也放在DAO当中，那个DAO就会充斥大量的If 。。Else。。之类的语句，一坨一坨的，非常的壮观。

       还有人会说，Hibernate也支持命名查询，将SQL写在映射文件当中，但是命名查询，只支持占位符固定的情况，也就是说，where a = ? and b = ? and c=?，是三个问号，就是三个问号，传参时，少一个都不行。但是很多项目的查询，都是动态的，也就是说用户选了这个查询条件，才会生成这个占位符的。

       Hibernate办不到。

       还有人会说，我自己用Hibernate写一个框架，也可以做到，那你写的可能比Ibatis好，也可能差，你要造轮子，谁来拦不着。
  

    5. 调优
       早期调优，有些Bad SQL，其实在code review阶段，只要看看Ibatis的SQL配置文件，就可以扼杀掉的，如果使用HSQL，可能不会被发现，因为它不仅隐藏在代码当中，有的时候，还需要程序跑起来，通过日志打印出SQL或者通过其它工具如P6Spy来看的出来。

       后期调优，既然是调优，我想就一定是遇到了瓶颈，可能要在库表上做冗余，可能要检查那些Bad SQL，可能要修改代码，可能要动用DBA层次上的一些调优手段，那么调优越深入，Ibatis的优势就越能体现出来，比如说增加临时表，中间表，增加冗余字段等。

    6. 开发速度
      
       如果项目当中，没有一个Hibernate高手，你的项目又相对的复杂，不仅有复杂的库表关系，还有大量的报表查询，那么使用Hibernate，速度上逊于Ibatis.

       问题在于，怎么样算是一个Hibernate高手，别看论坛上，那么多人，群情激奋的在说Hibernate的好，有谁真的是高手？

       我认识一个人，连Hibernate的命名查询、悲观锁、乐观锁之类的，都不清楚，还在那说：“说Hibernate不好的人，只是他不会用Hibernate，高手使用EJB也一样用的很顺溜“，我这辈子，最最讨厌的就的这样的人，人家明明用Spring很简单，很快乐，为什么要用EJB，充高手。换过来，项目使用Ibatis来做动态查询，很快的就解决问题了，为什么要去学Hibernate里面高深的东东，是不是这样就是高手了？

    7. 平台移植性
       如果你的项目要做产品，而且打算基于多个数据库平台的发布，使用Hiberante是没有说了。

    8. 维护性
       如果不考虑移植性，Ibatis的可维护不差于Hibernate，库表变动引起实体类变动时，HSQL也会有改动，有人说不用改，说这话的那个人可能整天只会有select * ，如果ibatis也是这样写，也不用动了。

       HSQL好阅读吗，From order，确实很简单，但实际当中，这跟拿HelloWord做例子，有什么区别？

     
   
    9. 我在实际项目当中的运用
    项目背景：
       我自己从Hibernate2开始使用，我现在也不认为我是Hibernate高手，我也没有时间去钻研Hibernate，更深的东西，我也不喜欢坐在开发人员旁边老半天，去帮他们解决Hibernate遇到的问题，因为我自己还有很多事要做。

       我的项目当中，在Hibernate方面，还有一个比我更强的人，他也很烦去看Hibernate打印出来的sql，看上老半天，再调上老半天，项目进度，嗖嗖的过去了。

       水平越高的人，任务越重，很少有时间和耐心去解决一般性的问题。

    最终的运用：

       在基于Spring的容器事务管理之下，
       增、删、改、存及在事务中的查询，使用Hibernate。
       非事务性的查询及报表，都用Ibatis，维护非常的直观方便，开发速度上也快很多。

       我觉得现在技术换代很快，使用一项技术，首先是要快速的解决问题，然后要学习他的思想，那些整天死抱着Hibernate，自认为学习到ORM的设计技巧的人，就去继续的学吧。

       我已经会用Hibernate的一些方面，我觉得够用就行了，犯不上，天天钻研HSQL，如果有时间，我觉得躺在草坪上看看Unix的编程艺术，看看代码大全，看看Oracle的编程艺术，比看Hibernate的SB书要惬意多了。

       简单能够带来快乐，用过EJB，再用Spring的人，都有体会，那简直是一种思想上的重生。

       Ibatis的设计者认为，在新的项目当中，可以使用Hibernate，在旧的遗留项目当中，可以使用Ibatis，不明白，他为什么说这样的话，这与新旧项目有什么区别？ 新的项目就真的可以使用Hibernate吗。

        我认为回避代码是可耻的，只要编码有意义，我们在任何阶段，都应当投入到编码当中。

   最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计，我做了一个设计的骨架，然后交给他们去迭代细化。下班前，我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板，我对他们说，不要求你们去写文档，我也没有时间去看，我不知道你们以前，是怎么做这设计的，但在我这个组，这样做，不行。做为设计者，首先是自己要理解要做的东西，并且真正知道怎么去设计它才能满足涉众需求，第二步，才是让别人能够理解你的设计。怎么样让别人理解你的设计，文档并不是唯一的途径，对于普通程度员来讲，白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人，我们很多的设计者，总是喜欢用大量的4＋1 UML图和文档中生硬、冰冷的词汇来吓唬程序员，恰恰反映出了设计者内心的空虚与胆怯。

   以往自身的设计经历，谈一下：
       我第一次给另一个组做一个子模块的设计时，心里很紧张，因为我不在他们那个组中，也不参与他们的开发，这个设计对于他们的项目进度来说，又是一个关键路径，我生怕我自己设计的不好，考虑问题考虑的不周到，在项目后期，如果出现问题，自己责任重大。

       我对他们说，这个设计需要两个星期，其实我只化了三天，就把接口文档写好了，我对着接口考虑来考虑去，还是觉得没有底，我忍不住想写代码，来验证这样做对不对，又怕别人说我的设计能力不强。我就偷偷摸摸的写代码，又和他们的组的主要使用者反复沟通了几次，根据需求，设计了几种不同的案例，来验证我的设计是否有漏洞。

   最后，又对接口修复了几次，觉得接口相对稳定和健壮了，就让他们过来看看，提出问题，结果也没有提出什么问题。于是我就交工了。

   实事上，这个接口，在开发后期，还是有一点修改，但并没有给他们的项目造成很大的影响，他们自己也认为能考虑的这么全面，已经不易。
       做开发这么多年，越来越觉得设计是一个很复杂的东东，他不像建筑工程中的设计一样，可以用工程化的方法去中规中矩的验证，并交给工人进行构造。但如果没有好的验证方法，一个设计就交工了，大家都没底。就好像选择是狮子还是公主，只有把门打开才能知道。

      这几年，我经历的每个项目，几乎都有评审，需求评审，设计评审等等，但我现在回想过来，我想不出对我的项目有太多的意义，很多人痴迷于通过文档和评审来试图证明设计是正确的，而通过评审，对于PM和Architect，似乎也被当做是一个项目当中非常重大的milestone，直到现在，我的上级和我的同事，似乎从未改变。而我的自己观点的表白在OP会上，迎来的是批判。

       我认为文档必须要有，总体的架构设计和模块的详细设计，都是需要的，但是设计者，往往忘记了，文档只是设计者自己对已经构思好的设计的一种反映，这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具，它绝对不是一个证明自己完成一个良好设计的方法。

        编码、测试、调试、交付用户UAT，都应当视为是设计的过程，也应当是验证设计是否正确的最好的办法。

        尽早的进入代码开发，是敏捷开发中一个很重要的标志，所谓的标志，我认为如果在项目前期的前一两个月，你仍然徘徊在需求分析、文档编写的工作当中，而没有代码产生，你绝对不是敏捷。这个观点是我自己加的，我很难容忍，我的设计、分析人员天天在写文档，开发人员在心猿意马的看长遍大论的需求和设计文档。
          一句话，越早进入开发，我就越主动。

   我验证设计的一些方法：
   1.根据以往的设计经验，做一些check list.
   2.写代码，做demo。做Demo是我非常喜欢的一个方法，一个可以运行的Demo，远胜过文档了。开发人员一看，直接copy、paste就完了。做汽车、计算机等新产品，都会有样机，对样机做大量的试验后，才能上线，大批量的生产，在软件当中，怎么一做完设计，就大规模的进行开发了呢。
   3.做测试案例，TDD是一种方法，有长期开发经验的人很容易吸收的思想，并且愿意在重要的地方使用，来理顺和验证自己思路。
   4.对于设计的涉众人员，能够尽早的看到，并充分的沟通，不要把文档写完了，才交给他们，那是一种思想上的强暴。很多时候，在领导的安排下，设计人员与开发人员，在能力上，并差不了多少。所以设计人员要虚心，并且要有责任心。

   好的设计应当交付什么：
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档

       其实，大家经常解释时说的一句话："我也是就事论事"，但在OP这样比较高层面的会上，还是尽量不要这样搞，就事论事，可以在下面一对一的搞，不要动不动都拿到OP会上搞，得不到别人的协作，要尽量的沟通，不能动不动，就上报给CTO之类的领导，这样会更糟糕。因为CTO可能会不能罩你一辈子。也并不是每个CTO都是清明的领导。

        email有email的用处，但它不是command, 也不是communication, 从你的坐位上站起来，在公司内走一走，要比一个email强万倍。

     4.架构师
       
        架构设计是个很复杂的东东，但如何选择合适的架构师，如何进行最终的决策，很多公司做的并不好，很多领导在架构师的任命上，很容易草率，说你行，你就行，说你不行，你就不行。于是一些不负责的、半桶水的人，就在领导的指示下，走上前台，将项目推向死亡之谷。

        架构的设计依赖你全生命周期项目经验的积累，格局要大，依赖于你对技术的敏感度，技术上比较全面，就像参谋长一样，从军校毕业的，就容易纸上谈兵，比较激进，从士兵，一路杀过来的，就比较慎重，但如果不爱学习上进，则又属于野路子，做又不究其理，不善于抽象，不讲究方法论。

        总之，在这点上，能找一个NB的，又有理性的，不太容易。

     5. 文档
       
         项目组与项目组之间，项目组与客户，项目组与测试部门，项目组与评审组之间的交互，有很重要的部分就是文档。

         文档这个东东，说实在话，就是一个鸡肋，但不要又不行，客户要签字，领导要评审，测试组要拿它写测试用例，但对于项目组来说，天天在那咬文嚼字的，实在是没有意义的，俺在原型分析与用例驱动上探索了很长时间，虽然用例直接了当，且很容易转化成功能书、测试用例，但工作量，比之传统的需求文档说明书，有过之而无不及，在时间紧的时候，也很难保持实时一致。

        我目前的做法是原型必须与客户的需求保持一致，基于静态页面的原型，修改起来，速度很快，且更容易被客户、程度员、设计者所接收，长篇大论，动不动上百页的需求文档，你喊破喉咙，也没有人看。

       文档，有专人写，专人维护，但会比较滞后，只要能够保证在提交测试部门时，有一份完整的文档，这样测试部门，也更方便测试。培训的时间也少。

        在评审时，可以评审，但具体文档要拖一拖了。

        客户签字，就以原型为主了。文档，它也不看。如果动真格，要看，那就抽时间赶出来。

        当然对于接口等技术文档，还是必须要的。

         (未完待续)
      
    

走下神坛的项目经理

　　以下的问题，谁看谁解答：
　　１、很多招聘项目经理的信息上，无异例外的提到：风险控制，以目前国内的开发现状，风险控制是项目经理的责任吗？ 你做到了吗
　　２、对于进度控制，项目工具、理论教条、计划、报告、经验的作用有多大，孰重孰轻，到底是什么是进度控制中的决定性因素。
　　３、性格决定命运，项目经理的人格魅力，亲和力，沟通技巧是不是项目成败的关键因素？
　　４、项目经理真的能掌控一切吗，遇到低素质的开发人员，性格怪异的程序员，桀骜不驯的程序员，你真的能搞定他吗，遇到啥也不懂的老总，遇到胡搅蛮缠的客户，怎么去搞定他们。
　　５、不懂技术，也能带好团队吗？能做好一个项目吗，至少我没有见过这样的案例。
　　６、项目经理如何能摆脱写作的海洋，要写计划，写需求分析，写进度报告，写设计记录，写会议记录，写考评记录，写....。文档真的就能提高项目质量吗，文档之与开发效率是提高，还是降低？你喜欢做这样的项目经理吗？
　　７、项目经理在开发期间需不需要写程序？，是审查文档，还是审核代码，需不需要考评（我工作这几年，经历N个公司，考评都流与形式，即浪费了时间，又没有效果，希望能有人给出明灯，照亮迷途）。
　　８、如果你到了一个新开张的公司开始了第一个新项目，没有测试部门，没有质量管理，没有规范，没有制度，没有企业文化，没有项目积累，团队需要你自己招兵买马（薪资不会很高，中间还有人跑掉），老总又不懂技术，你怎么来带好这个项目？
　　９、如果团队中没有一个懂得敏捷开发，指望看书，查资料，能应用到项目中去吗？
１０、如果新来一个软件学院的硕士，来做你们公司的开发部经理，天天都是软件工程，敏捷开发，测试驱动，RUP，IOC，你们怎样面对这样的开发经理？
　　１１、现在招聘项目经理的条件上，都附上了敏捷开发，RUP等，不懂这些，就不能管理好一个项目吗？

　　
　　程序员总是骂项目经理，他们人多呀，没办法，他们在人群中高呼，项目经理要爱护程序员，如何去爱护，相爱也难呀，人都是犯贱，你越是给他个好脸，他越不知道自己是谁，什么是都讲究个度，这是最难把握的。

　　领导老是说，要关心下属，了解他们的能力和缺点、性格与心理，一天就８个小时，十几人的团队，项目经理又不是８爪鱼，又不是心理学家，能做多少事呢。
　　
　　项目经理能辞退一个人吗，不能，
　　能选择一个团队吗，不能，
　　能主动要求公司给骨干成员加薪吗，不能（很多人动不动拿这涨薪资来作为项目经理管理的一条必做的内容，我觉得瞎扯淡，可能吗，薪资结构是公司的上层建筑，不可动摇，就算动了，也是毛毛雨，我们公司一个骨干，能力很强，在一次工程中，很努力，吃了很多的苦，结束后，公司主动给他涨了２００块钱，他觉得是一种侮辱，就BYE　BYE　了，太失败了）
　　如果在项目进展过程中掌握项目成员情况或平息人民内部矛盾就要多沟通，就要搞活动，请吃饭，公司不补贴的话，就要自己放血（我自己家里还一大堆人民内部矛盾呢），老总在和我谈话时，总是说要多请他们吃吃钣，唱唱K，我都想抽他。一次两次可以，多了我也不愿意，做人不能伪大方，最失败的是总见我请别人吃饭，没有请我吃饭。
　　项目成员要求上班有学习看书的时间，我觉得是扯淡，总不能让我一个人扛着，你们看书吧？我自己已经多长时间没有看书了，我也记不清楚了。
　　谁没有受过进度上的逼迫，有几个人能做好呢，项目经理不压程序员压谁，总不能被上头骂完后，跟没事的，还乐呵呵的请大家吃饭吧。
　　有人说项目经理要有骨气，要敢于说不，有几个呢，再说公司接个单也不容易，好不容易来个单，你又搞个一年半载才出来一个beta版，还被客户骂了半死。

　　我觉得大家都应当把自己的项目，自己的公司的，实情都说出来，不要讲一些书上才能看到的东西，撇开虚伪，敞开胸脯让大家来分析。

　　我对我们公司成员（包括我自己）的现状大体分析如下，可能有主观成分，大家仁者见仁：

１、并不认同公司的发展，混日子，你要说不想干了就走，他马上拿起包就走，没有一点留恋
２、热衷技术，有一定的软件工程基础，能够参与项目管理决策，能够对自己的分配任务给出合理的时间表（这种人真的很少，论坛中多，现实中少，现在是蓝领泛滥的社会）
３、普通的人，只能写代码，对于别人的事情，就是别人的事情，参与度不高，不愿意多做一项工作，９点钟来，６点钟走（太多了）
４、对于自己的任务，并不能给出合理的估计与时间表，如果让他做估计，常常是延期完成的，这时，你需要自己去帮他做，如果延误了，你需要要帮助他解决问题，批评与指责，告状，解决不了任何的问题。（比较多，很多项目经理对于进度，众口一词的说，把任务分解后，让成员来估计，是不是这样呢，他自己都不知道，估计什么呀！）
５、有困难也不说，死鳖一样，什么也不说，解决不了，就放在那儿，也不反映，如果需求或设计中有错误，知道错了，也不说，就按错的来。（有这样的人，当然不多，谁遇到谁倒霉）
６、有的人，完不成任务，总是一大堆理由，你想批评他一句，他能回十句，烦都烦死了
７、缺乏团队精神的人，别人犯了错，如果影响到自己就大声的骂，如果没有影响到自己，就嘲笑。背后搞鬼搞怪。自己出了错，就隐瞒，害怕别人指出自己的错误，不承认犯错，脸红脖子粗的跟你没有完没了。
８、刚毕业的人，脑子灵巧，基础不扎实，知道一点东西，就不知天高地厚，贪玩，写出来的代码功能虽然实现了，但跟大便差不多，看了都想吐。没有团队精神，没有价值观（公司薪资不高，就只能这样的人，需要加功夫培训雕琢）
９、传说中的项目经理：有一个平常心的，知道自己缺点不足，不充大，不自大，不吹毛求疵，真正在做项目管理的项目经理，能够真正理解和掌控整个项目进程的管理者（很少，连基本功能都没做扎实呢，却整天抓这个布局不好，那个颜色不好看，这个类命名不符合规范，程序员说完成了，他就认为完成了，整天只会问这个功能你需要多长时间完成，那个功能需要多少时间完成，程序员拍胸脯说９天，他就向上面拍胸脯是９天，到底需不需要９天，谁也说不清楚，９天过后完不成了，除了继续做下去也没折）

得出结论：一只高素质而且有着非长高的向心力的开发团队是传说中才能出现的。

作为公司一个PM，能做的事是非常非常有限的，谁有能力去撼动一个公司的企业文化呢，在百十号人的公司里说句话，有人能深情的看你一眼呢？再说了公司不发展，总不能自己也不发展吧，所以只能离开，去寻找党组织了。到底什么时候才能找到党组织？