写了这么多文章，技术屌丝味太浓了，以前每次想写点随想也是起了个标题就没下文了，正好今天早上看到了一篇喷技术创业的文章，文中观点不敢苟同，趁着早晨清醒的时刻，咱也文艺范一次，写点有感而发的文字。

很多公司，无论大小，都想将部门划分的细之又细。所谓麻雀虽小，五脏俱全。随意拉一张公司的组织结构图出来看看 – 总裁办，行政部，人力资源部，技术部，产品部，市场部，客服部，运营部。。。别人有的我们就得有，别人没有的我们也得有，不论有些部门是不是必须，只要一两个人也能成立个部门。不明真相的人跑来一看，瞧，多正规，高端洋气上档次。

且不论其他职能部门，我就来说说跟研发关系最大的一些部门，以及如何显得他们的工作是不可或缺的。

产品部

产品部本身就是一个比较扯的部门，因为这个词打击面太大，整天挖空心思想点子的，想的是不是产品？没日没夜扣腚的，做的是不是产品？上线后胆战心惊监测的，维护的是不是产品？我们尊崇’less is more’，谁也说不清产品到底是个啥玩意，但是就有这样一个部门，叫做“产品部”。

再回到这篇文章的观点，技术人员过于注重技术，而忽略了对产品的思考，所以需要专门设置这样一个产品经理的职位来构思整个产品的走向。看似有理，但是他的前提是“技术人员不会思考产品”，这就是一个弥天大谎，我见过的大部分技术人员，对于项目的细节，业务逻辑的理解都比普通产品高出不知道多少个档次，我们不能纸上谈兵，只有真正理解了产品实现的业务逻辑，才能提出更有建设性和创新性的意见，这叫站在巨人的肩膀上。但是我看到的很多产品是，进入公司一个礼拜都不到，以前从来没有用过公司的产品，就能洋洋洒洒写出一大篇设计文档来，而问到为什么要这样改，则又支支吾吾，说不出个所以然，最后来一句我看到某某网站也是这样做的，所以我们也要这样做。

回到技术人员的自我修养上来，我认为每个研发应该视自己开发的产品如孩子一般，在关注技术进步之余，能花时间来培养这个孩子，让其更健壮，更优雅，更招人待见。同时，也要多看看外面的世界，试用别人的产品，包括竞争对手的，以和自己创造的孩子进行对比。技术人员提出的产品改进意见往往更务实，更切中要害。

将这种视如己出的概念再推广到所有员工身上，其实人人都可以为产品添砖加瓦出谋划策，那么，产品部门存在的价值何在？

测试部

测试可以分为好多类：1.做黑盒的。2.做白盒的。3.自动化测试。 我们一一道来。

先说第一种，做黑盒的。很多公司曲解了黑盒的意思，认为做黑盒就是一个功能开发好了，你拿去用，不出问题就行了。这样就把软件开发变成了一个劳动密集型行业，这样的测试与拿到内测账号的用户有什么区别。更何况我们有些测试人员的使用经验可能还不如用户。这样的测试，效率既低下，效果还不明显。

再说第二种，做白盒的。一些公司有白盒测试，其实就是看看代码。很多公司认为，这个人写代码不行，就让他做测试吧。这是一个大大的误区，对测试人员的要求应该比研发更高，因为我认为读代码往往比写代码更难。上面这种做法的后果就是，一些人做白盒测试的时候，一旦看到不明白的地方，就跑来问研发，需要研发手把手的一条条教来，这不光是浪费双方的时间，也是在做无用功。我相信任意一个合格的研发人员，在提测之前应该都对代码做完整细致的自测。

最后说说第三种，做自动化测试的。这个其实要求较高，很多公司没有，即使有也是认为装个hudson写写配置文件就算自动化测试了。而我认为的自动化测试应该有很强的编码能力，能写出简单有效的单元测试用例，能配置不同的运行环境来确保软件的跨平台性，能进行性能测试，来保证软件的工作效率。这都对测试人员提出了较高的要求，这种人少之又少，而我见到的大多数测试人员连apache的vhost文件都不会写。

真正的测试人员应该得到相当的尊敬，因为他们需要对业务和代码都有很深的理解，他们比程序员更细心，既能防止程序员犯一些低级的错误，又能在一些容易忽略的问题是上保持警惕。

假如找不到这样合适的测试人员，测试部就没有存在的意义。

UED部

UED这个词是个舶来品，你甚至很难找到合适的中文替代词，只能用“用户体验”这种虚无缥缈的词来囊括。很多公司的UED，其实就是美工。

我自认为对设计和绘画不在行，所以我很尊重设计师的工作。设计师负责原型和效果设计，程序员负责实现，这是由人的左右半脑分工决定的，而且一个好的设计师，简而美的设计，应该是先在公司内部群体中产生认同感，才能让更多的用户认可。

下面是我的吐槽，一些我见过的设计师，可能读过一本Don’t Make Me Think，就能自诩得到了设计的精髓，接着就对页面开始做大刀阔斧的改革，也不需要其他人的意见，因为设计师都有一些自负天才的心理在作怪（嗯，其实程序员也有）。更有甚者，是一天一小改，三天一大改，也没有统一的风格，去别的网站东边抄一块，西边抄一块，就变成了咱家的东西。别人做瀑布流，我们也搞瀑布流，别人做下拉刷新，我们也用下拉刷新，可是从来没有独创的功能被人认可，这也是“一直在模仿，从未被超越”的典型了。

再说到“用户体验”这个词上，世界上恐怕再也找不到这样一个百搭的词了。一个按钮加大点可以叫用户体验，换个字体也叫用户体验，但是众口难调，人的大脑是很奇怪的，你喜欢的未必是人家喜欢的。所以真正需要做到的是在公司这个小范围内赢得众人的认同，然后将风格延续下去，这样才能让更多的用户接受乃至迷恋这种风格。有个很成功的例子就是苹果。

这里又要说到关于设计师和程序员两类人的区别了。我认为一个好的设计师和一个好的程序员应该是可以互补并相互学习的。我以前的一个研发经理，技术上肯定是毋庸置疑的，但是也做得一手好画，从鼠绘到原型到效果图，无所不能。这样的人才非常难得，但并不是没有，一个诸葛亮是远远高于三个臭皮匠的。而更多的人可以在学习中达到这个高度。

理想中的组织架构

任何组织发展壮大之后，人员就会变得复杂，管理难度相应也会增大。职场如战场，公司就是一个缩小的社会，我们不妨就从历史中找个例子出来。清廷倒台之前，曾有一番关于“共和”还是“立宪”的争论，两派人争得不可开交，最后的结果我们知道，共和派取得了胜利。

“共和”和“立宪”的根本区别还是权力集中在何处。相比帝制的独裁，“立宪”在名义上是说君主也要遵纪守法，权力还是集中于小部分人（真正的“立宪”君主只是个象征，内阁还是要选举的）。而“共和”则将权力下放于大众，政府则是大众意志的集中。

开源软件的圣经《大教堂与市集》其实也表达了这样一种思想。软件开发由自上而下的瀑布流发展到今天的开源模式，最有代表性的就是github flow。就是任何人都有权利对产品提出改进意见，并且可以亲自来实现这些功能，而项目的管理者(owner)在更新自己的产品之余，还需要接受来自四面八方的(pull request)。owner有权力决定这些功能的加入，也有义务鉴定这个功能的风险。

同样对公司的管理也是这样，权力不应该集中于个人，每个员工都应该有发言权。每个员工都应该有自由发挥的空间，来实现自己需要的功能。同时也不能忽略了合作的重要性，所以在日常的工作中，需要三两人一组，作为一个cell，可以是同一个部门中志同道合的人，也可以是不同部门中可以互补的人(比如设计师和程序员)。以cell为最小单位，来完成每个任务。最基本的目标：追求效率，追求自我提高，追求快乐工作。

这对个人也是有要求的，就是每个人都需要能独当一面。我想谁都不会愿意与一个一无所知和整日拖沓的同事合作吧（MM除外）。同时，管理层(owner)的责任就是协调cell之间的工作，有权力决定cell提出的功能的去留，也有义务听取大家的意见。

这也是我觉得创业公司比大公司好的一个原因，就是你有决定权，或者能将意见直接反馈到管理层，而不需要经过大公司死板结构的层层汇报。同样，这样的办事效率也是很多公司望尘莫及的。赠人玫瑰手有余香，以开放的心态接受他人，那么他人也会以同样的姿态来回报你。

最后贴一个豆瓣上的小段子，娱乐一下。不同部门员工吃饭时聊些什么。