== 1 == 贝壳做程序员到现在，没去过国企（好吧，和他们有过合作，可实在看不惯他们的作派，死也不去），没去过外企（也是有合作，可惜英语太差），全在各种私企里面打转。从初创公司到中型外包都呆过，还曾是某初创公司的第一个员工，可惜结局不怎么好——关门了。初创公司的一些问题，可谓前仆后继，大家的死法差不多。当员工时，不好给老板直接提意见。现在私下里偷偷说说，有想开公司的当故事听吧。
初创公司第一怕，就是没有经验。没有经验的程序员，没有经验的经理，所以很多事情都不知道怎么办，只能摸着石头过河。实话说，完全摸石头的，还不如不开了。最起码最起码，老板做什么，就必须熟悉这行。想干互联网，必须熟悉互联网。想干企业，就必须熟悉企业。没这个要求，不如不干。至于技术上没经验，可以找合适的程序员。如果老板熟悉互联网，很多做阿里巴巴阿，做腾讯之类的傻话都不会说出来了，他要做的一定是个没有的东西，或者说在中国没有，或者有，但是市场刚要起步。在一个饱和市场内挑战一个巨头，这和唐吉柯德挑战风车是一样的，能得到的只是海明威笔下的鱼骨头。
初创公司没有人熟悉技术怎么办？这就要看你的公司类型了。如果你决定以业务为核心，可以找个诚实可靠（别说看人看不准，如果人看不准，公司哪里都会碰壁）有经验的程序员做主管，记得谈分红或者股份，然后放手给他。他会帮你管理的很好的。不过记得偶尔就他的做法咨询一下其他懂行的朋友。通常这类程序员最好是来自于大型企业IT部或者大型互联网公司，他们会把大型互联网公司的规范带过来。当然，也不要无条件的接受。先文档后程序，重测试轻代码之类的东西对初创是不适用的。起码要等公司有10来个程序员再回头补课。这些人构成的程序部是写不出什么天才程序的，但是可以有效廉价的把你要做的业务做起来。
如果你决定以技术为核心（实话说，中国这种公司比例不高），你起码得有一个高手在手里，才能谈公司的问题。而且公司开起来，你得分给他很高比例的股份。大部分这类创业老板，都是自己就是高级程序员，觉得挺了解程序了。这种情况下的建议反过来，你要找熟悉市场的人，不要觉得你很熟悉市场。程序员不是一个典型用户，除非你的用户都是程序员，否则大部分的需求需要重新考虑，甚至商业模式都未必成立。
初创公司最怕的情况，就是老板不懂技术，也不找人，胡乱指挥。贝壳呆的头家公司，现在已经关门了，所以说说问题也不大。老板决定做销售管理软件，实话说这个决定没什么问题，问题是老板的生产过程。他先找了三个程序员过来（两个新手一个老手，贝壳就是第一个员工，当时年轻，什么都不懂），然后请一个大学教授当顾问。由于大学老师都比较忙，因此他让其中一个比较有经验的程序员负责平时管理，不过还是按照员工待遇。然后他开始做需求，结果时间太少，需求做半本就开始做程序。一下就犯了大忌，需求未系统化。老程序员心知肚明，可是能说什么呢？自己连合伙人都不是，根本说不动老板。
然后制定计划的时候，老程序员制定了一个相对保守的计划——这是当然，因为只有一个老程序员和两个新手，他怎么也不敢激进阿。老板当场否决，把时间提前了两个月，变成三个月完成，并且承诺会加派招程序员。又是一个大忌，拍脑袋决定周期，也没有标杆事件控制。当天我就看到老程序员白着脸进去黑着脸出来，然后很郁闷的修改时间。不过后面的事情好玩的很，程序员来一个走一个，基本留不住人。现在想起来，当时工资实在太低了。工资低是有理由的，贝壳当时基本什么都不会，光学SSH就学了一个多月——还基本不大会用。
做产品的时候，考虑使用数据库，一下子居然挑中了oracle。现在反观，我也不知道怎么做的决策。用oracle做互联网的公司，目前为止我还没听说过第二家，因为oracle的长处在于事务和稳定性，而不是性能。由于维护麻烦，因此也没有买oracle自己的授权，而是第三方公司卖的5W的版本。就贝壳后来所知，oracle从未有这个级别的版本，他们的产品都是20W一个CPU，可以支持25个同步连接来卖的。天知道这个所谓第三方公司是怎么回事。由于配置麻烦（当时还是8），因此抽调我过去处理oracle的安装问题。贝壳就花了一个多月，把linux和oracle安装学了一遍。不过这一来，一个多月贝壳就基本没怎么写代码。一个初创公司一个员工一个月不写代码，可谓是很无谓的损失了。
更夸张的是，由于老板考虑部署的时候，立足点都是——用户太多怎么办，压根没考虑过没用户的问题。所以他开始就自己买机器进行IDC部署。偏偏普通服务器他又觉得太贵，所以还自己装服务器。贝壳再跑了好几次电脑城，买服务器装。虽然采购还是按照采购流程走的，但是又大概一周不干程序。服务器终于全部搞定上线了，贝壳大概一个月花掉了。几个月过去，老板发现进度跟不上计划，就先推迟了发布计划，然后找大家紧急开会。结论是，他加速做需求，我们加班搞定代码。可是有用么？完全没用。下面几个月糊里糊涂，贝壳都不记得自己做了点啥了。发布计划一推再推，贝壳一点信心都没有，就辞职走人了。
后来听说，在长达一年多的开发后，他们还是搞定了系统，并且正式上线销售。但是只有几个客户愿意付钱。坚持了一段时间，老板看实在赚不到钱，只有关门走人。
回顾整个里面的问题，关键是外行领导内行。做顾问的教授是内行，但不是搞互联网的，又没时间。老程序员名义上是经理，却不能否决提议。实际上是最不懂互联网的老板自己在做决策，导致最关键的几个问题上，压根没有发现决策是错的。次之的问题，是为了省钱而浪费时间。程序员出价太低，招的都是新手。买oracle舍不得买原厂带服务的，非要自己搞。服务器都不买现成的，自己组装。这里面能节约的时间，绝对不是花钱能买到的。里面还有什么老板策划需求拍脑袋，听风就是雨，甚至要求我们做一个子功能，叫做"中国地图在线”之类的小事就不提了。
虽说不想埋怨老板，不过贝壳确实在那家公司浪费了生命中的八个月，除了自学linux和oracle安装外没有剩下任何有用的技能。现在这段事情也被贝壳当作一个教训，很多事情不是看起来好就好的，如果事情看起来不靠谱，早点割肉退出不失为一个好的方案。
== 2 == 上面一篇，贝壳说了说老板搞外行指挥内行的问题。这篇反过来，是我一个朋友X的经历。他经历的更加的传奇一些，是一个内行指挥外行的经历。
X是一家外企的程序员，原本这家外企没有IT部，后来为了做市场，于是成立了IT部。他是头一批的老员工，情况和贝壳类似。在他们之后，进来了一个很有水平的程序员Y。Y的水平很高，所以很快的就成了IT部实际的领导人。原本的外企中方经理很是器重，承诺分一定的公司股份，但是要求IT部能够达到一定目标。例如流量多少，来多少IP访问等等。Y很快就带领整个IT部开始行动了，需求分析，计划制定，时间节点分布，系统架构，都很中规中矩。SSH开发网站本身就是一个中规中矩的过程，没有太多的创意可说。半年不到，系统就上线了，基础测试通过，公司上下都很开心。
问题发生在Y拿到公司股份之后，通常按照协议，股份是不能很快变现的。我不知道Y和公司怎么谈的协议，X君作为一个局外人，也只能告诉我一些小道消息。据说Y的股票居然很快就出手了，而后Y君很快的辞职，开了家咨询公司。
而后公司系统陆续发生了一些问题，本来很稳定的流量一下缩水到几分之一，而X君说，他们的营销策略从未有大的改变。更麻烦的是，系统总是出一些莫名其妙的小问题，经常无法访问。公司没办法，只能高价请回Y君来解决。每次都是问题很快解决，但是另一个问题又再出现。几次往返后，公司实在不堪忍受，就再找了一个高手进来看看系统。X君说，人家上午过来，下午走人。说从未看过如此混乱不堪的代码，几乎没有可维护性，建议直接重写。
然后公司就陷入了两难，要不要重写呢？不重写，这个系统显然没有任何继续发展的可能。重写，又如何保证新来的工程师不会搞出这种不可维护的系统。 据说，到X走的时候，中方经理已经被迫辞职了，外方决定找印度阿三来解决这个问题。当然，后面就是一个新的传说了。
整个事情好像是一个职场阴暗面的故事，感觉平平无奇。不过实际上，整个故事还是有几个神奇的地方存在的。首先，公司没有做过Y君的背景调查么？还是说Y君以前一直OK？其次，通常股份都是不可立刻变现的，必须经过三到五年，其目的就是防止这种事情。类似的条件还有无法转让什么的，都跑到哪里去了？最后，公司所有人，包括X君在内，没有发现Y君的系统是不可维护的么？我始终感觉这个故事的背后还有其他故事，只是这已经不是我们讨论的要点了。
== 3 == 第三篇故事，是来自于贝壳自己的惨痛经历，在另一位朋友那里也有类似教训，可惜他未及早听我一句。
贝壳原来在一家公司里面做项目经理，公司做企业定制开发，现在仍在，所以具体情况隐去不表。因为某些情况，老板叫贝壳做了项目经理，按照资历和能力来说，其实并未足够。贝壳精通的是C++开发，而项目是使用 .net 技术做的。因此贝壳对项目的管理能力实际上打了一个折扣，只能负责结构设计和协调。当时对项目管理也不是很精通，可以说是半吊子水平。公司承接了一个企业的业务系统开发，经过前期准备，我们团队就开去了客户那里进驻。客户要求，界面一定要漂亮。因此我们选型下来的结果，使用了 .net 3.5的wpf开发。开发过程中其实还是有很多问题，很多都是新手问题，暴露贝壳总体设计和项目把握的缺陷。不过这和今天主题无关，就略过不谈了。主要是 .net 3.5开发，到了最后发生了几个严重问题。
首先第一个问题，是客户有很多win2000机器，甚至还有一些win98。这个在当初系统设计的时候完全没有考虑。我们开发的机器一律全是winxp，.net3.5 wpf可以完全的运行在上面。而对于win2000，wpf是无法安装的。于是，我们就必须要求客户升级到winxp。企业用户，他们还必须使用正版。其次，.net 3.5在进行远程SOAP调用的时候，会出现严重的内存泄漏。其实并不是真的泄漏了，只是.net 3.5的SOAP系统没有考虑调用接口可能多达数百个的情况，对每个函数都进行了序列化器缓存。这个缓存会耗费100-200M的空间，加上其他开销，我们的系统总开销是200-300M，比大部分游戏还高。这个直接导致客户运行我们系统的时候，必须多加一倍的内存。
更郁闷的问题还在后面，wpf是使用dx渲染的系统，因此如果客户没有独立显卡，系统速度就会慢如龟速。wpf的部署必须使用完整sdk，2.0的runtime安装包只有20M，而3.5的完整sdk高达350M。我们在每台机器上安装的时候都是用U盘完整安装350M的sdk。不过这都不是最郁闷的，最郁闷的是，我们项目最后问题实在太多，有个员工做了一个web版的。界面难看很多，但是方便移植部署，内存消耗小。瞬间得到全企业上下一致支持，他们的老板还问我们，当初为什么不这么设计。贝壳哪里好意思说，您不是要漂亮么？
实话说，要不是老板和客户关系好，我们非要给愤怒的客户踢出大门不可。这一个项目，成功的是老板，失败的是贝壳。
总结下来，两个教训。首先是设计必须实地的调查一线需求，不能光听上面的就得出结论，也不能光看部分典型用户就得出结论。如果有一些关键用户对构架支持不良，业务上又不能放弃，就必须权衡得失，甚至修改构架。如果当时我们知道win2000乃至win98的事情，就压根不会考虑使用wpf来做界面。第二个，就是不能迷信技术，或者激进的使用无法掌控的技术。宁可使用最土的办法，老老实实的把业务做出来。新技术由于刚刚出现，因此很多问题都没有完全暴露，很多领域也没有经验积累。例如这个例子里面的内存占用问题，安装包问题，系统问题，都是到了部署时才发生的问题。使用新技术，就会随时面对无人发现的问题，这和RPG的踩地雷战斗是一样的经历。只是这里不但没有经验值，而且踩多了还会直接挂掉。
== 4 ==
第四个故事来自一个朋友的笑话。说某人从一家公司辞职了，朋友问说什么情况。某人说，和老板相处不来。老板看到有人上班看网页，就出了条规定，不许上班时间看网页，否则罚款。看到有人带朋友进办公室，就出条规定，不许上班时带朋友进办公室，否则罚款。上个月老婆出差，没人照顾家里的仓鼠，带去两天，出条规定，不得带宠物上班。某人情感受到了强烈的伤害，所以愤而辞职。
其实说起来，这些事情都不是什么大事，鸡毛蒜皮到了我们可以当笑话说的地步。细究起来也确实是员工应当执行的，属于正常雇员的基本素养。不过如果您自己开家公司，照着上面的做，搞不好手下还真就一堆辞职的。
从某种意义上说，这是一个心理问题。在IBM，或者Oracle这种大公司，出现这些条款没人觉得有什么不对，关键在于两点。一方面，大公司本身就给人一种正儿八经，板着个脸的印象。员工进公司的时候，就知道自己随时会碰到各种狗屁倒灶的规定，有一定的心理准备。小公司通常老总天天见，搞不好下班还一起吃饭喝酒，上班的时候板起脸来做规矩，情感上受得了受不了就不好说了。另一方面，大公司的规定相对完备，什么可以什么不可以都规定的非常详细。小公司难免挂一漏万，天天改规矩，确实不怎么好看。
反过来说，这也是初创公司对大公司的优势。在大公司里，管理层显然不会留意到每个人的特性，并且针对性的管理。然而初创公司就那么几号人，大部分都是熟人。要针对管理不是一件不可能的事情。老婆出差，家里仓鼠可以带到公司，顺便睡在公司做程序得了，反正家里也没人。诸如此类的事情并不怎么难做。当然，当初创公司上了一定规模（推荐大概是10-30人）后，管理转换必然要产生阵痛。然而也远好过在三两个人的公司里面规定四五十条的规范。
Comments !