博客园_天亮说晚安

架构师的工作准则

2010-07-13T14:16:00Z

刚在网上看到一段话，很不错,醍醐灌顶,转录过来以时时提醒自己。(转载自javaeye一个叫凤舞凰扬的人的回帖)

优秀的架构师应该是设计解决方案。不管架构师做出来什么东西，封装也好不封装也好，他必须解答6个W：
为什么要这么做（Why）：架构师要解释这样做的目的和相关的背景条件。
做出来的东西包含了什么（What）：方案中包括些什么东西，解决了什么问题？
谁会从中获得好处（Who）：架构选择这种做法，谁能得到益处？开发人员、客户还是公司？
设计的思路是怎么样的（How）：整个设计的思路及过程是怎样的。
是否还有更好的选择或者做法（Whether）：是否有比现在更好的解决方案？是不是做过其他方案的分析比较？
它的设计时效是什么（When）：它是一个长期解决方案还是临时的？

本文链接

IT从业者的新起点

2010-06-22T04:00:00Z

刚刚看了一则新闻，说惠普宣布裁减9000个IT职位，其间提到了云计算，提到了IT部门的价值，提到了业务与IT的关系，与我最近的一些感悟挺接近，所以由感而发，胡说几句。

算算信息化进程也搞了这么多年，是该上个台阶的时候了。那些在第一次IT浪潮中身不由已被卷进来的企业领导人在呛了几口水之后已经缓过劲，明白了IT是怎么一回事，提出更高要求也在情理之中，而IT部门作为企业的一部分，以企业业务需要为导向，提供信息服务和技术支撑，这是IT部门的工作。这些工作不仅仅是软件开发，维护服务器这么单纯的事，这样的事以后会被专业的公司取代，而IT部门要考虑的事将会是：如何应对互联网经济带来的挑战，推动商业模式的创新和发展。互联网经济是一个大浪潮，要么被冲下去，要么潇洒帅气的行走于风头浪尖，而商业模式的创新和发展就是一个冲浪板，能不能玩的好就要看企业的行动力和创新意识。这里边IT部门能够起到很重要的作用，因为它具备很多其它部门不具备的优势：同时熟悉信息化和业务，与各个部门都有往来，熟悉业务的整个流程，是综合性很强的多面手。基于此，IT部门是该被重视的，是可以在企业决策时有足够话语权的。所以IT部门的地位并没有降低，反而是提升了。

对于像我这样混迹于企业的IT从业者来说，要想在这个企业长久混下来，除了服务器玩的转，软件搞的定，经济学也是要研究的，有朝一日，CIO会遍地开花，而系统分析师和架构师却只能存在于专业的软件公司。。。。

本文链接

团队建设的总结

2010-06-16T14:12:00Z

展开说团队建设之前,先说下我们之前的工作模式。我们这个开发小组的人数不多,前几年一直维持在五六个人的样子,人员组成是一个组长,剩下全是程序员,由于项目也不多,基本上是哪个项目急先做哪个,大家一块上,组长负责需求,一个程序员搭项目的架子,然后分模块,需求分析由程序员自己做,完了把项目凑一块去,项目就成了,很作坊式,这中间的问题想必搞过开发的都知道.这样的情况持续了四年的时间,后来部门进入到一个高速发展的阶段,项目越来越多,人员也越来越多.在这样的情况下,原来的作坊式开发就成为了一个发展瓶颈.在痛苦的挣扎了半年多后我们痛下决心要改变,整个改变是逐步进行的，因为一切都是在摸索中进行，中间有一些反复，最终好的东西保留了下来，虚的或者不适合我们团队的东西被放弃或被改进。

明确分工，各司其职，扁平化管理向层级管理过渡

之前的工作模式以模块为划分单位，大家做的工作都类似，整个流程所有人都要过一遍，这样的问题是有一些软件过程很容易被忽略，像详细设计、单元测试这样的工作，基本上没人会做。最终的软件质量也只能凭借程序员的个人能力和责任感来保证，而项目的管理者在这中间的监控能力是很弱的，除非你深入到每个人的工作中去，否则在过程中，你很难控制风险，一旦出现问题管理者只能祈祷相关的人员赶快搞定它，因为没有其它人能帮上忙。这种工作模式把程序员都煅炼成了全能手，这是好的地方，也是不好的地方，每个人的性格都不一样，擅长和感兴趣的地方也不相同，让合适的人做最适合的事，从效率上来说是最高的。另外一点，从个人的发展来说没人想当一辈子程序员，管理者必须照顾团队成员这种要成长的心理，也必须留下这么一个空间，让大家看到希望。

于是团队中开始有了分工，最初的分工是项目管理（兼测试管理）、系统分析师、开发管理、开发人员这四大类。项目管理是项目经理工作中偏管理那部分工作，具体说开就是进度控制、风险控制、质量控制等工作。系统分析师主导需求分析工作，工作的成果是详细设计。开发管理负责软件技术相关的工作，像技术选型、开发、部署相关的工作等。这样的分工明确了岗位，让人尽其用，同时也形成了一个开发流程，每个环节的时间预先都有计划，拖的久了自然会有压力，扯皮的事也少了，你这个环节做的好不好，所有人都看的很清楚。

这样的分工多少还有些教条化，项目分工要以人为本，最终的分工协作模式还是要根据团队成员的特点及项目特点来对细节进行调整。经过一年多时间的逐步细化完善，上面的分工其实有了一些改变，主要是因为有多个项目需要穿插进行，解决办法是增加了系统分析师的人数，项目负责人的指定更加灵活，不是只有项目管理岗位的人担当，系统分析师和开发人员很容易从一个项目出来转向另一个项目，增加了人员的灵活性。

制度保证，让团队敏捷起来

因为我们选择了ruby on rails，所以敏捷开发模式也就顺理成章，如何保证团队敏捷起来，在前期一些明确的制度是少不了的，例如每日早会、周例会、即时讨论、详细设计审查等等，每日早会可以让团队中的问题及早暴露，让项目的进度管理和风险控制在早会中完成，周例会召集客户，展示一周工作成果，讨论需求。避免需求分析存在误差，更快的项目迭代。即时讨论是在需求分析阶段要求项目管理人员和系统分析人员随时就问题展开讨论，必要时客户也要参加。详细设计审查故名思义。

核心人员带头，培养良好的团队文化

团队文化的建立是一个长期的持续的工作，需要小组的负责人明确指导思想，核心人员带头才能完成，我们团队的文化用几个字总结就是：无私、分享、互助、协作。如何把团队文化一代代传递下去靠的不是喊口号，而是行动，用实际行动影响下边的人，使这些思想常态化，新人进来会被影响而自然溶入这个集体，成为这些思想的宣扬者。团队文化的形成是团队成为一个自冶、自律团队的基础，是团队建设的最终成果。

本文链接