新手笔记-新手感想与尝试 (转)

新手笔记-新手感想与尝试 (转)[@more@]

标题：网站开发新手笔记-新手感想与尝试

关键词：网站开发

  6月29号：晚上，闷热的晚上

 XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

新加入一个其它行业的时候总是会有很多的感想，以前的工作习惯与新的工作环境之前的冲突也会使人进行思考与尝试。也许这就是老人们所说的树挪死，人挪活吧。

 

由于我是从一家软件公司进入到这家公司，一开始进入公司是极为不习惯的。上到企业文化，技术部门在公司内部的地位，下到技术部内容组织结构，人员结构等等，都与以前的公司有非常大的区别。应该说各种不同的组织方式都是有其各自的历史原因与现实意义。但对于一个新进入的同仁，会有什么样的感想？应该如何进行状态呢？

 

感想

最初的感觉，网站技术部的管理比软件开发的管理少很多的环节。也可以说相对管理的比较松。可以将这种环境与以前的软件公司管理的环境进行一下比较，我觉得有以下一些区别：

²  网站的管理中缺少类似软件公司中比较严格的技术管理；网站领导对网站开发本身的规律没有软件公司中管理者对软件开发本身的规则了解的程序高。

  在我所遇见的两个公司的最高头头对网站技术部工作开发的规律的了解程度来说，软件公司的领导者明显要高于网站的领导者。出现这种情况是有其特殊的背景的，网站公司的领导者很多的时候是要在网站的发展的总体角度来考虑问题，技术部门只是负责运行维护与页面的实现。技术部门在整个的组织结构中并不是最为关键的部门。（与我的朋友讨论时，得出的结论是如果网站的组织很好时，完成可以将技术部分的工作外包。），作为网站的领导者，可以对应网站技术部分开发的规则并不是非常的了解。网站的领导者唯一关心的完成时间与实现目标，这样就要求网站技术部门对自己的开发任务一定要定义出尽量细致的计划。换一个角度说，网站的领导者看待网站开发的角度类似客户看待软件公司的角度。（这种说法只是我目前的看法，说出来与大家的讨论。）还有，这也是技术部门在网站中进行定位的依据。（我的感觉是技术部门在网站的运营中是一个辅助性的部门，其重要程度与开发组在软件公司的重要程度有很大的差别。）

而软件公司是以软件质量与实现的好坏为唯一生死线。所以几乎所有的软件公司的领导者对软件开发的规则至少都有表面上的理解，比如软件开发要有需求，设计，开发，测试，上线等等几个子过程，(虽然大部分的情况是知道必须要有这几个子过程，但是面对合同的要求，就会把这些子过程的具体要求丢到脑后。)。所以很难说是采用网站式的管理方法还是采用软件公司式的管理方法比较好一点？？

 

²  软件公司对应的管理切的太细，每个子目标与客户离的太远。在管理好的情况下还好说，可是在管理一般的情况下容易助长技术至上的风气。（回忆以前在没头没尾项目的时候，花费太多的时间去讨论技术的架构，而忽略业务本身的失误。）

上面已经说过，网站公司的领导相对网站技术部门来说类似于软件公司的客户（当然是有生死大权的那种L ）。从这个角度来说，给了技术部门最大的空间与自由。而且网站开发本身的特点也可以使得我们在开发过程中比较自由的于任务进行切割。每实现一小块，都可得到很快的反馈。如果有一个很好的管理机制，那么可以很快的将反馈成为下一步工作的有益的输入。而相对在软件公司，管理的目标定的很细，各个部分应该如何进行管理都有很好的计划，但是有一点问题，就是可能导致每个子目标与客户离的太远，在技术管理上如果把握不好时，很有可能使得出现很多的子目标实现的程序与最终目标不一至的情况。例如，情况之一是助长技术至上的风气，开口技术，闭口技术，用户都是笨蛋的言论就可能出现。还有可能会出现设计过细，测试过粗等等情况。

 

当然，上面的说法只是我的感觉。也许和我接触的公司的实际情况有关系，并不是所有的网站公司都会出现这些情况，更不是所有的软件公司都会出现技术至上的情况。只是被我遇上了而已。

 

还有一个感觉还是管理问题。曾经与一个海归朋友聊过天，了解他对管理问题的看法。他告诉我以前他在国外带的TEAM的时候，作为一个领导，最大的工作职责是将TEAM程序员的兴趣引导到所要开发的项目或产品中。而在中国，他进行这样的尝试后几乎是失败了。这种管理方式很难走通，或者说效果很不理想的原因是什么？他让我自己体会。我想他告诉我的这些尝试之后的总结是很深的经验积累之后说出来的，我对此的体会是：

1.  所作的项目在不断变化，采用的开发语言也在不断的变化：

也许以前所作业的项目或产品的竞争力主要在开发者的技术水平是否很高；（或者说，如果不是高手来开发，就不可能有成功的项目。）而在目前的项目与产品中，有竞争力的部分已经渐渐的转向业务是否挖的够细，业务上是否整合的好，是否有业务上的创新等等。这种情况需要的是将技术部门整合到业务部门中。开发语言也一样，以前的开发语言很难学习与应用，而现在的开发语言很好学，很好用。所以相对来说，可以将开发项目的人员的成本降下来，这种成本的降低是对管理提出了新的要求：变化的要求。

2.  人员的素质还是有一定的差别（不会比工资的差别更大）

人员素质应该还是有一定差别的，我想这是客观存在的，所以客观上要求定义出的规则更多，而不是放任不管，只靠大家的兴趣开发。（人员的素质差别绝不会比较工资的差别更大，10000$/月的人的素质应该比4000￥/月的人的素质要高一点吧J）

 

与这种情况类似，网站技术部的管理也面临同样的问题。我最早对这个网站的印象就是以一种非常宽松的环境，有最后实现上的要求，但是没有细化到各个应该实现的人身上，定出的计划有时并不能按时的完成。

 

还一些其它的感受，都是与上面所说的网站的技术部门在网站运营中的定位有关系，这里就不一一进行说明。

尝试

有了上面的感受之后，我想给我的第一步工作是可以将一些软件公司的好的经验挑选一些直接拿过来在这里进行使用。于是我进行了以下的一些尝试：

²  多动笔，请各种不同的内容部发过来的需求(也许并不叫需求)整理成统一的格式进行多方确认（包括美工，内容，数据库组。如果对组织结构不清楚，可以参见.NET/Develop/read_article.ASP?id=19347">《网站开发新手笔记-从头开始的新工作》）

²  在需求的基础上形成一些比较粗的设计，并找出对应的确认方式。

²  将大任务切成几个较小的任务，通过多种方式较早的得到反馈，并且对反馈及时回复：较好修改的部分进行快速修改，不好修改的部分回复出不好修改的原因，以及给出对应的修改计划等等，以加强其它部门对技术部门的信心。

²  对开发模式的一些修改，这个以后仔细说。

等等，尝试的初期取得了一些的效果。比如工作交互中的规则感强了，与我进行交互的其它部门的同仁也渐渐了解什么是属于他的责任，什么是属于我的责任。责任感的明确使得任务的更加的清楚。得到更多的反馈很快的提高工作质量，以及对反馈的及时回复提升其它部门对技术部门的信息。但是总体来说，这些尝试并不是在准确的去对目前已经有的组织架构，人员配比，以及具体的业务能力进行仔细的分析之后得出的整体方案，所以并不一定都是正确的，需要在了解的过程中逐步的形成完整的管理体系。

总结

经过三个月左右的尝试，从什么都不懂 到 入门成为一名网站开发的新手，这个过程对我来是一个非常快乐的学习过程，同仁们也给予了很多的帮助。总之，网站的开发使得我更加的贴近了业务本身，这个可以弥补我在以前没头没尾时失去的对业务的信心。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752019/viewspace-981472/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752019/viewspace-981472/