Works Applications是一个怎样的公司？ - 知乎1381被浏览311533分享邀请回答439139 条评论分享收藏感谢收起/cn/index.php/196 。 内推也已打开，请珍惜每一个内推机会。注5： 夏季校招已经开始，新一轮宣讲进行中，可以关注WAP招聘公众号获取详细信息。 我是谁？我是个“下意识层面”上很“懒”的人（意识层面也是），所以我愿意花精力去预知我生活里可能会遇到的大大小小的“麻烦”，尤其是枯燥的重复性的麻烦，然后用相对取巧的手段尽量提前化解它们。能用复印机达到以假乱真的手写效果，我就绝不会真的一张张手写请柬。技术，真是个好东西。我喜欢复杂的技术所带来的简化的便利。我现在是WAPC的VP之一。我在上海交大计算机系读了7年，12年4月毕业进入WAPC，如今整五年。五年中我先做了两年邮箱和即时通讯系统，又做了半年人才管理系统。然后加入HUE产品组（后文会有额外介绍），逐渐接触设计、产品和管理，慢慢在密密麻麻空降的日本同事中站住了脚，可以独自带项目。再半年后晋升Manager，开始了公司里第一个个性化推荐相关的项目，以及第一个移动端项目，兼顾办公室改善（下文也会有介绍）。再10个月后晋升VP，主要负责HUE的运维开发及客户支持（含项目管理）系统的开发。为什么要写段东西？写给谁看？“校招来了个WAPC，据说年薪40万（现在应该在37万左右了），那公司干啥的？”
“他们公司主页我看不懂，靠谱不？”
“ERP是啥？查了查看上去很土。”
“是不是跟SAP，Oracle差不多的？名字都跟SAP很像，是山寨吧？”
“参加招聘要腾出起码两个礼拜时间准备和参加，要跟老板请假，要错过另外两家企业的笔试面试，值不值啊？”
“offer好拿不好拿？”
“五险一金是在那40万里扣不？”
“能不能拿户口？”
“听说不分开发测试产品？那我进去到底都做啥？”
“一个日本企业，听说死板压抑，我去了是不是会格格不入被排挤啊？”
“就算做的好，机会也不会太多吧？不会让你一个外国人浪起来的，天花板会很低。”
“日企提薪慢吧？”
“拿到offer我能不能选择去日本工作？”
“在里面到底能学到多少东西？ERP技术都很老的。”
“这薪水，错过了是有点可惜，可是公司没名气，进去发现不合适再跳岂不是亏大了？”
“加班厉害不？”
“要是开始没觉得，干了两年发现没前途，再跳槽可比在BAT跳难多了吧？”
“手里好几个offer，到底该选哪个呢？”从带团队之后，我就开始频繁参与WAPC的校招。跟同学们在宣讲会上聊，面试实习时候聊，坐一起吃饭时候聊，知乎上聊（我知乎几乎没直言回答过WAPC相关的问题，因为身份略敏感，怕有言语不当。但竟然仍有同学按图索骥猜到我是WAP的找我咨询，还有人问我笔试题目，怒！），有同学拿到offer举棋不定时候也愿意跟HR要个中国工程师的联系方式聊一聊。我这几年跟许多同学聊过，但涉及的问题其实大同小异。我的求职经历与大部分人没什么两样，实习，海投，笔试面试拿offer。拿了WAPC的offer我同样喜忧参半，喜的是这么高的工资我没见过（12年CS白菜价十三四万年薪，大路行情所谓青菜价十七八万年薪，高者二十四五，WAPC是500*0.8=40万，与之匹敌的只有一个DeNA，做游戏，但是要到日本去工作），忧的是我听都没听过它，宣讲会都是陪人去听的。我搜了好几个搜索引擎，除了一个看上去很山寨的日文主页和新闻里据说什么最佳雇主，就几乎再也找不到其他有效内容。面对一个未知又重要的选择，我体会过，并理解其中的困扰和茫然。所以我每次接电话都愿意事无巨细知无不言。但我估计其中沟通还是会顾忌，不如都写出来干脆。何况因为人才增速一直达不到预期，今年WAPC在校招之余终于打开社招的大门，4月之后又会开通社招内推渠道（内推成功也有奖励，所以如果你哪个朋友旧识在WAPC，勇敢地找他们内推去吧。当然，没渠道找我或直接投给HR也行，但至少请读完此文，并确定你与我眼中的WAPC契合）。招聘的排程已经越来越满。可以预计到我又要回答同样的问题到口干舌燥。为了提前解决这个重复性的“麻烦”，我还是写出来吧。对于正准备走出校园的同学们，或者不满意现状正寻求变化准备跳槽的工程师们。希望这段东西让你们了解到一个更丰满的WAPC。这段东西应该怎么读？坐舒服点找个大屏读，因为即使虎头蛇尾了，
也能有三万多字.先说结论： WAP是一个正处于二次创业过程，用互联网技术支撑ERP业务（SaaS ERP，或者干脆称为互联网+ERP）的非典型日企。 接下来的文字，我会：先介绍下WAP及WAPC；接下来介绍WAPC（上海）工作的内容和日常，这可能是大多数同学最关心的事儿，因为它关系到你每天过得舒不舒服；然后是薪水、福利，这关系到你每个月底舒服不舒服；我会再尝试把WAPC与我印象中其他大公司做个对比，可能在你犹豫的时候给你一个选择的思路。再接下来，我来尝试回答在WAPC以后的发展会不会广阔，毕竟只关注眼前利益是短视的。最后，如果你真的对WAPC感兴趣，我再留下一点应聘上的建议，不要期待太高，不会涉密，但尽量是干货。二、WAP（不单指WAP中国）是做什么的？概括先行：WAP是一个正处于二次创业过程，用互联网技术支撑ERP业务（SaaS ERP，或者干脆称为互联网+ERP）的非典型日企。WAP的背景，主营业务和业绩WAP成立于1996年7月，到去年夏天整是20个年头。WAP由牧野正幸，阿部孝司，石川芳郎三人创建，梦想是提升世界的ROI（投资回报率）。这其中的逻辑简单点说，就是通过好用的企业软件，把人们从琐碎枯燥无意义的脏活累活里解放出来，专注于人们应该做的事情，提升生产效率。最美好的事情，是让人们拥抱每周‘三天休息日’。ERP，Enterprise Resource Planning，译为企业资源计划或企业资源规划，是一种90年左右提出的企业管理理念。前身是MRP，MRP II，有说目前已发展至ERP II阶段（关系见图1）。ERP系统被很多企业应用，它是个很广泛的概念，可能包含生产管理，进销存管理，物流管理，财务会计管理（我们叫Accounting），成本、需求管理，人力资源管理（我们叫HRMS），供应链管理，客户关系管理，项目管理，电销管理等模块，图2简单概括了ERP的全景。但总而言之，它是一个创建在信息技术基础上的系统化管理平台。用以为企业提供运行和决策手段。图1，国外ERP发展历程 资料来源：方正证券研究所图2，ERP的功能全景 资料来源：明硕信息，方正证券研究所WAP就是个做ERP起家的企业，所以觉得它传统那是非常自然。WAP的产品（命名“COMPANY”系列）有个比较独特的概念：全功能打包（package）销售，永久免费升级，添加新功能不收定制费。客户企业成本会比较容易控制，是个很好的shining point。“COMPANY”最初代的产品功能不像现在那么炫目，只是够用。但公司的销售团队（直到现在也是如此）非常会理解客户， 他们很擅长洞察客户的真实需求并为之提出方案，懂得站在别人的鞋子里思考问题、解决问题。所以产品刚有雏形就能获得认可。这个经验也在日后得到非常好的发扬，项目未开，文档先行，如果客户认同你的设计和文案了，把产品再卖给他也就不难了。这与“确保失败尽早发生，尽快发生，经常发生”的理念（《Team Geek》）不谋而合，越早征求意见和反馈，就能把风险降低，因为一开始就踏错步的概率是很高的。对于这点，后文（介绍工作日常的时候）我还会再提到。那个年代信息化还很初级，好用的软件不多。在最初几家客户比较艰难地拿下并支持好以后，“COMPANY”就证明了自己，有了一席之地。随着不断的改进，之后的业务规模就滚雪球似的增长了。尤其在千禧年之后的两三年，每年都有百家左右新客户开始使用“COMPANY”。到了第二十个年头，WAP有了超过一千二百家集团客户，约八千家企业， “COMPANY”系列，尤其是HR产品被广为接受，日本市场占有率傲人地超过了SAP，Oracle等行业翘楚。并且市场满意度相当高， 客户平均都持续使用十年以上，很少退出。 WAP目标客户里并没有中小企业，这个数字意味着基本上日本三分之一的上市公司都在使用“COMPANY”，其中包括非常多大家耳熟能详的名字（索尼大法，任天堂，欧姆龙，三得利…基本上你能叫出来名字的日本大企业，十之七八在用WAP的产品，所以虽然你可能没听过WAP，但它离你倒没那么遥远）。16年，WAP统计的销售数字达到400多亿日元（所以WAPC的同僚们这下不再好奇为什么公司发得起这么多人的工资了吧）。但当然，由于产品受众都是企业客户，加上ERP有很强的地域性，客户范围比较局限于日企，虽然ERP软件用户粘性大，客户忠诚度很高，WAP的口碑传播却也因此局限于岛内大型企业，普通民众并不了解，国外民众更甚。何况“COMPANY”出国时间也还短，国际化并不能算非常出色。所以到目前为止，海外客户中也以日本企业为主。“COMPANY”想走出日本国门，得到海外的认可，并不容易。这是公司必须要克服的困境，也是我们共同努力的方向。事实上一方面加紧提升“COMPANY”，另一方面二代产品也会在这方面多加注意，会对国际市场更为友善。图3，WAP的客户增长 （截自我的PPT） 图4，WAP的客户占日本上市公司的比例 （截自我的PPT） WAP的疯狂二次创业海外扩张WAP在日的“事业所”（大部分不是法人）如今分布东京、大阪、名古屋、广岛、福冈、德岛等。然而受日本国内市场规模和人才数量的限制，WAP的发展渐渐触摸到瓶颈，不得不着眼于更大的国际市场。毕竟即使能将全部日本大型企业都转化为WAP的拥泵者，销售额也不过至多乘三。而且，日本招聘及用人，向来不会像国内一样细化JD，按图索骥。他们更愿意结合企业理念来发布他们所需人才的人物画像，比如“有创新意识”、“善于沟通”、“积极挑战”等等，网罗英才。待学生入职之后，再给予全面的培养，根据特长和需要逐渐分配合适的职位。但日本计算机系生源很少（日本大学毕业生总数就不及中国的十分之一，计算机生源相对则更稀缺），慢慢地公司里做产品的码农竟然也出现了一些金融、法律等文科生出身，甚至我们有时候还开玩笑说会不会有神学毕业来写代码的。虽然他们同样优秀，也会接受很长时间的培训和学习，但毕竟缺少四年以上全职正规的专业教育，产品中也不可避免的堆叠了一些隐性的问题。随着产品线越来越长，产品越来越重，管理层也意识到只从日本国内寻求改变是不可能了。从2011年开始，WAP逐渐在海外设立或收购分部，有意在未来公司外籍员工与日籍员工比例达到1:1，甚至更高，成为名副其实的国际公司。如今在上海、新加坡、纽约、洛杉矶、印度清奈，都设有WAP的子公司（中国的分公司也在陆续筹备中，北京分公司的设立已经提上日程）。在上述分部中，有研发角色的分部为东京、大阪、德岛（新设立的NLP研究所）、上海、新加坡、清奈， 而班加罗尔和北京都初步有建立新开发据点的筹划。可以注意到，新的子公司，尤其是研发子公司的选址多在亚洲，且在人口及教育资源丰富，经济环境开放的中印新三国。而在同工同酬同等待遇，竭力招揽人才的大策略之下，WAP的吸引力也迅速走高，这样的扩张策略不可谓不成功。得益于中印新三国的人才补充，WAP近五年的扩张非常迅速，我入职的时候公司不过两千七八百位员工。到16年中已经有超过五千六百名员工，现如今应该已超六千人了。这个数字还在不断增长中。但相应的，员工工资作为软件企业最显著的成本项，也会给公司财务带来了一定的压力。优秀人才固然会显著提升产品数量和质量，带来良性循环，但这种快速扩张，在我看来也应该相当冒险。（好消息是，近期看到的财务和人事报告显示，近两年的人才增长的确带来了与之相当速率的营收增长）新一代产品AI WORKS（内部代号HUE）而仅有人员飞速扩张当然算不得二次创业，最多只能算疯狂，因为它短期内带来的仅仅是财务的负担。我所说创业，指的就是WAP新一代的产品AI WORKS的研发，在公司里我们叫它HUE，是High Usability Enterprise的简称。人们对于ERP传统落后的偏见是有根据的。我印象里的ERP也是一个个灰色的表单和按钮，人们就是要在里面重复地填上乱七八糟看也看不太懂的数据，机械式地用一堆不便利换来另外一些地方的便利，然而错误不断。填表，对账，销账…，这些年来人们也从未因为ERP软件的存在而让生活有很大改观。比如我在第五次人口普查时帮我父亲收集和（往计算机里）录入过人口数据，枯燥无聊，错误频发。比如你在学校里可能被要求反复在不同的系统或申请表里输入你的家庭信息，联系方式，一旦有了变化又得一个个改过去。又比如时至今日你去办个居住证或者任何什么证，也依然都要拿一堆其他的证件、填表申请，即使你觉得你填的东西理所当然政府部门应该都有。再比如，问问长一辈人，问问他们有几个人常用证件里姓名生日民族等等最基本的信息一点都没有错的？计算机系统过去似乎只被当成纸和比，只是翻阅的时候快一点，并不太能够帮人做太多事情，比如判断对错。反正我家几位老人证件全都有瑕疵，老夫老妻几十年了，岳父岳母代理办事情需要做公证的时候公证处不给办，原因是结婚证名字与身份证名字不符。如上种种，虽然发达国家状况稍好一些，但也仅仅只是稍好一些罢了。软件及理念的发展都需要过程，即便是迭代迅速的消费软件，漂亮的UI贴心的设计也不过在近几年才偶尔出现。ERP作为一类使用粘性大，开发惯性大的应用软件，“尾大不掉”是必然的。然而这种必然并不能让ERP软件商处之坦然。IT行业里日新月异。不改变就要被淘汰，柯达诺基亚雅虎，这么大的体量也逃不掉跟不上潮流的命运。WAP看来是意识到了这一点。乘着公司经营状况良好，没有资本压力的时候，倾其所有投入海外的优秀人力资产，并利用其尽快重新规划和实现下一代ERP产品，赶在对手之前抢占市场，催发更强生命力，这应该就是WAP的冒险策略。所谓不破不立，趁着这样的机会，把产品从旧有的Cobol（没错，50年前诞生的第一个高级商用计算机程序语言）、Delphi做的桌面程序，转移到更主流更便利的B/S结构，用最前沿的云、大数据、AI搭建日本第一个人工智能的SaaS ERP生态。让ERP不再仅仅是一张张不知所谓的表格，让ERP懂得人类真正开始服务人类（而不是人类来迁就ERP），让二十年积累的业务经验在人工智能的帮助下老藤开新花。在我看来，AI WORKS不得不算是WAP对抗传统ERP衰落的一剂的破釜沉舟方子。是否良方就我的水平实在难以评判，我自觉方向无误，但并非天时地利人和都占，还是喜忧各有。时间不等人，稍一迟疑机会转瞬即逝，而一旦在这匆匆间药没抓准，同样可能满盘皆输。除了不必担心吃了这顿没下顿，这与白手起家的创业实则没什么区别。所以我说，WAP现在非常像是一家创业公司。 三、WAPC的成立WAP中国的正式成立在2012年，说起来也是有点偶然性的。有听闻说在04年WAP曾尝试过进入中国但未果，太久了我有点无处考证。但确实从2010左右WAP又到中国开始尝试零星地招聘中国籍员工了。早在2010年初地在北京招到两位前辈，那时拿到offer还是要到东京入职的。2010年末2011年初应该算是个转折点，那时候很可能是WAP第一次比较大规模的海外招聘，当时应该是招到了十一位Top5高校的中国员工。不过在那个节点依然还是没有听到筹备中国法人的具体计划。所有预备员工都组织到武汉的日语学校学习了日语，做着去日本前的准备。但在随后的2011年3月，意外发生了。3月11号下午，日本的东北地方近海发生了9.1级大地震（也称311地震），是日本有观测记录以来规模最大的地震。这次地震使得本州岛移动，地轴也因此发生偏移，触动的海啸波及九万多平方公里（共500千米的日本海岸线海啸高度超过10米，最高达到40.1米，数据来自维基百科），沿海城市遭受毁灭性破坏，福岛核电站那时候就被破坏过一次发生过泄漏。东京地区所在的关东地方也有长达6分钟的震感。日本受到冲击非常大。因为考虑到日本的灾情，也担心中国员工们不愿意在这种时候去日本（最后的确只有两位去了东京），WAP打乱了原计划，将中国分公司的成立提前提上了日程。可想而知，办公室准备的会比较匆忙，员工入职时间可能也受到了些许影响。公司选址最初考虑香港，但由于签证与员工福利问题所以作罢。也考虑过其他城市，综合多种因素最后将第一个海外子公司定在了上海，延安西路1088号长峰中心的17层。上海长宁区算是一个日企的聚集区，因为它靠近虹桥经济开发区，在上世纪90年代，浦东机场成立前，很多来沪的日本人、日本企业会选择那里作为第一个落脚点。而且日本驻上海总领事馆也在长宁区，延安西路2299号，与公司在同一条路上。另一个原因是这里已经有一家WAP的关联公司：利众得(Legend Applications China Co.,Ltd.)。WAPC就在利众得还空闲着的办公区划了一块地方，地方不大，条件一般，就这么简简单单地开张了。刚入职的时候公司还在申请注册，我们还很奇妙地与日本公司签了几个月的合同，拿了几个月的日元（现在卡里还有一点当时剩下的日元，有的老同事留了很多日元，现在比较痛心疾首[邪恶脸]），缴了几个月的日本社保，直到公司注册成功正式挂牌。（后来工作关系签回上海的时候，社保大部分还给退了，很赞。）不过签中国合同的时候，实在有点不忍直视——公司注册的名字寓意不错——但，万 革 始……（我要静静。这样，来，我们拿出手机，打开Airbnb，跟我念，爱，彼，迎。现在是不是好多了～）公司成立前很多事情也都是我后来才知道的故事了，记忆也可能多少有点偏差。我是11年末拿到WAPC offer的人，也是那么几个比较早到处寻找“Works Applications（中国）是一家怎样的公司”的人之一。公司官网中一无所获，其他信息要么看不懂，要么没意义。在我们毕业前夕马上要决定要不要接受这份offer的时候，我们甚至都还找不到可以接洽问询的有点人事经验的中国人，找不到前辈问，也不知道哪里有办公室可以参观（我们也担心这是不是一家皮包公司骗子公司或者是传销啊）。尤其我们在WAPC申请户口资质上的疑惑他们无人能解。上海户口的价值相信大家都了解，应该能算是除了北京户口以外最值钱的城市户口了。我们几个小伙伴当时也是发多了邮件，互相间也说了不少悄悄话，打了不少算盘，说实在的做这么个决策真是个考验人耐性勇气和决心的活。然而我们最后还是接受了并不太易得的offer，因为这招聘形式真是闻所未闻，对公司期待和好奇还是有的。户口嘛，墨菲定律，自然而然也是没申请到。因为WAPC不满足成立须满一年的条件，无法替我们递交落户申请。虽然新创公司也可以比较容易可以申请特批，但我们接触到上海人事的时候很晚，已经过了新创企业可以申请特批的时限。即便入职之后我们又跟日本人事担当沟通过很多个回合，希望能找出一些合理合法落户的途径，但均各种各样的原因被否决了。这个麻烦甚至造成一些老同事至今买不上住房，孩子上学也可能受影响。其实这给我留下了对于日本人最初的印象：迂腐，傲慢，不负责，不越界，不犯错第一。跟传言的严谨并不相同，体验并不美好。当然过了这几年我不得不说这是为数不多的个例（另一个个例是汇率调整，好像都跟人事有关），但就被我们这么碰到了。可以说，那个时候，很有点两眼一闭舍不得孩子套不着狼的味道，一拍桌子去也就去了。也想明白了，反正年轻嘛，没啥好畏畏缩缩的。不行再换，好就赚了，还能饿死咋地？也没想到真的就这么呆住了五年。WAPC给我的第一份珍贵，不是这里的同学大多来自TOP10的院校，不是我们做了多么高不可攀的产品，而是同事之间的融洽——这里没什么利益纷争，更不见办公室政治。都是刚刚从学校里走出来的愣头青，都是相比于人相斗更愿意跟机器打交道一辈子的人。这里的关系比学校里面还要纯净，就那么十几二十几号人，见面就问好，不是在一起讨论功能，就是闷在格子里堆代码。聊得最多的八卦无非是世界杯开赛了，隔壁的筷将军（一个快餐）倒闭了，哪家好玩的电子产品出来了，谁谁谁的代码又不欧欧（OO）了之类。刚入职时小老板是日本人，最喜欢喝“东方树叶”，学中文学得很认真，每天晚上都会打印一张纸跟中国人学习，在上面花里胡哨地用不同颜色的笔写写画画，做拼音和各种标记。终于有一天，我看到他的学习笔记扫描件（说到这，又想起了背后悲伤的故事，小老板突发疾病去世，我们所有人都难以相信[活着真的是最美好的事情了，什么困难其实回头看都是小事]。我看到笔记是在整理他遗物的时候偶然发现的，一页页翻看，又楞了好久。我把它们整理好，做了封皮找印刷厂装订成册。在小老板父亲来收遗物的时候送给了他，留做纪念。小老板应该跟他父亲特别像，他父亲人和善也特别乐观，但白发人送黑发人，我能看到他父亲眼里深深的悲伤），发现他学的竟然是莫言的《蛙》，那时候莫言刚获得“茅盾文学奖”，后来没多久就荣获了诺贝尔文学奖。但再怎么好那也是“幻觉现实主义”呀，“生育繁衍，多么庄严又多么世俗，多么严肃又多么荒唐……”他竟然拿来做入门教材。不吹也不黑，其实他无论英文还是中文，语法发音都不好，最初一起工作很费劲，我用了几个月才能熟练地靠读他的脸和零星的几个词来明白他在说什么，因为语法时态完全都不对。后来熟悉了我们还会调戏他的发音。项目测试全绿那天，他特意买了个小蛋糕，准备了一段中文讲稿，想给我们个惊喜，结果后来照着纸念得自己脸都红到脖子了。图5，小老板的学习笔记的其中一页，以及我做的封面扉页尾页，我把它们装订了厚厚的一本渐渐地，人越来越多，组越来越多。17楼的小半层楼就不够用了。又向上租了22楼小半层，23楼一个小屋，直到后来下决心搬到月星环球港。条件越来越改善，人们也去去留留。但可贵的是，这份单纯至今未变（不过生人越来越多，很多新同事总是很羞涩躲着走不好意思打招呼，这得改改）。我的很多珍贵的朋友，都是在公司里结交的。现在他们很多已经自己去创业，平时联络很少了，但是有喜悦要分享的时候，还是会自然而然地想起他们，回忆起那段时光。四、 WAPC的工作内容及工作日常产品线 WAPC的日常工作当然都围绕主营产品的开发、销售和咨询支持等。产品线分新老，主营的老产品就是我前文说的“COMPANY”系列。上海主要涉及“COMPANY”产品线中HR系的CJK，CWS，CSR，及其他部分系列如CIM，CLM等等的开发。除此之外还有我比较熟悉的ATE下的项目。我对它们的介绍不会太详细，因为网上能找到不少信息。另外随着新产品的开发，一些老项目会慢慢淡出视野，即使上海的同事们很多也不大需要了解老产品的细节了，我也就随便那么一讲，权当故事。因我并不都亲历，所以可能有谬误还需要老同事们指正。HR产品是公司的支柱项目，市场占有率最高。上海经手过CJK，CWS，CSR三个产品，直到现在还有百分二十左右的同事（工程师+咨询+销售）在这三个项目上工作。CJK（COMPANY Jinji Kyuyo，COMPANY人事给与，国际版称HCM，（Human Capital Management）是HR产品的明星，支柱的支柱，所以也是比较早引入上海的项目。CWS（COMPANY Web Service，国际版称COMPANY Workforce Selfservice）和CSR（COMPANYShuro，COMPANY就劳，国际版称COMPANY Attendance Management）也随之相继引入。WAP客户数量很大，如果把各个客户中的集团公司分开来计算，有8000多家公司在使用COMPANY。其中绝大部分客户都在使用这几大HR产品。COMPANY是以package的形式售卖，并不提供定制，所有客户用的产品都是一样的codebase，只是配置不同。但实际上客户们的业务和需求显然是各不相同的，可想而知，作为需求的超集，产品网罗了非常多的业务，涵盖了压倒性数量的功能和细节，有极强的灵活性和可配置性（当然配置起来会繁杂一些，所以会有整个咨询部门提供售后的导入支持）。有着众多客户的支持，销售部的同事们也很自豪很有底气：“COMPANY支持了8000多家企业，为了创造出客户满意的产品，COMPANY吸收了前期用户大量的业务需求和经验进行改进。所以再后来的新客户，买的就不光是一个HR软件，而是融合着8000家企业管理经验的成体系的解决方案。”在上海成立HR项目之前，WAP在国际市场上还没有什么客户，而如今在中国大陆，台湾，新加坡，马来西亚，泰国，越南等地已经有大几十家集团在使用CJK/CWS/CSR了。因为这么多国家法规政策、商业文化和管理都有区别，再加上还要本土化，这些市场上的产品自然也与日本本土产品不同。原来的业务逻辑和流程都需要调整，代码也可能需要重构，这许许多多的改变都全权出自于上海。随着这两年的发展和业务调整，这些任务又逐步转移交到了新加坡。说到各国的文化区别，我又想到了一个好玩儿的事儿，不知真假。听闻泰国民众与我国内相反，很多都没有储蓄的观念，不少都是过了今天不打算明天的主儿。于是为了避免工人一领到工资就吃喝玩儿乐大手大脚花光，后半个月窘迫到没饭吃就莫名其妙的不来上班了，很多工厂都把月薪调整为了双周薪。中国工程师在这些（相对日新月异的新技术）枯燥的日常项目里也找到了自己的乐趣。CJK里有一个阶段性的工作，叫D2B（Delphi to Browser）和C2J（Cobol to Java），前文也提到过，事实上这也是为产品转型做铺垫。原来的产品终端都是桌面端，用Delphi写的，随着潮流和需求的变化，自然要改到B/S结构改用web方案来实现。原来产品的批处理基本都是用Cobol写的，同样也要用Java重写，为新产品做准备。积累了几十年的产品，任务量可想而知。当时分到上海这边有一百多个批处理要进行C2J（Cobol to Java），东京的同事估计按上海的人力要两三年才能写完。上海的这个组有个非常年轻的小伙子（16年他申请调到了东京，过去的时候就已经晋升到Manager了），一拍脑袋：“这活忒糙，我不能这么干啊！”于是他用一个礼拜针对性写了个Cobol到Java的编译器，百分之八十的工作嗖嗖就被机器做完了，只剩下一些修修补补和美化的工作。安排任务的同事目瞪口呆。除了“COMPANY”系列，另外在上海有重要意义的一个部门叫ATE。这是WAPC创建上海分公司时老板直接带过来的团队。大部分的中国同事其实都属于（或属于过）ATE，时到如今，ATE与新产品组合并，被称为HUE&ATE。虽然ATE是Advanced Technique Engineering的简称，但我们一入职就加入进去，身在其中却有那么点“不识庐山真面目，只缘身在此山中”的味道，没有感觉到很特别。直到新产品开始才理解了那时候一些工作的前瞻性。上海ATE的始祖项目叫webmail2，产品代号“Macky!2”。这个“Macky!2”也是现在依然还是WAP内部每天必用的企业Web邮箱（出于安全考虑，公司POP3/SMTP服务默认关闭，邮件客户端是无法使用的）。这也是我第一个参与项目。除了和邮件相关的开发，我还花了一个季度做了一个内嵌的即时聊天工具，很像gmail里内嵌的talk。项目不大，不过五脏俱全，功能性能和用户体验都考虑了（即便现在看来还显得稚嫩）。在开发机和局域网环境压力测试稳定5000条消息/秒左右，三台五台地测过可近似线性地扩容。不过那时候公司内在线人数也就稳定在千人左右，生产环境里再加上必要的HA，两台server也就够了。作为一个ATE出身的项目，项目的技术意义大于产品意义，再加上主要为内部使用，“Macky!2”里写catalog的氛围并不浓，只做功能和模块的设计就好。这算是个小遗憾，让我日后又花了加倍的时间去学习和理解一个catalog的必要性，以及了解“怎么才能写好一个catalog”。其貌不扬的“Macky!2”成为ATE的项目，其实已经是在为日后的新产品试水了。“Macky!2”里密集地尝试和应用了许多当时很前卫的东西，NoSQL数据库，分布式缓存，全文搜索，Spring MVC，JS MVC框架AngularJS（1.0），websocket，分布式MQ，分布式文件系统，less样式，主流前端样式库，多种VCS，协作管理，CI，测试（包括selenium test）框架，亚马逊云……时髦性应该不亚于在去年夏天玩儿React和TensorFlow。大量技术的实用性适用性被证实或证伪，大部分经验都被加以改进后迁移到目前最新的产品中。上海ATE的另一项比较重要的贡献是选型和架构了My Number Keeping System，对日本各大公司提供支持。这个系统是为配合日本My Number系统的推广，向商业用户提供My Number的保存和管理服务。My Number这东西怎么解释呢？应该就是日本的身份证号。身份证（号）是中国人再熟悉不过的东西，估计每个人都对自己的身份证号习以为常甚至倒背如流。但日本在二战之后就取消了这种统一的编号。与美国一样，日本没有单一的整体性的国民记录，各用途均有自己的文档编号，就医用保险编号，开车用驾照编号，出国用护照，个人有多个银行账号政府也识别不出来。根据2015年9月成立的My Number修正法，从16年1月起，将给每一个国民（包含永驻/中长期居住的外国人）配备一个号码，将个人收入所得，纳税，年金的情报管理在号码里。就相当于中国的身份证。由于每个 My Number 均属于敏感个人信息 (Sensitive Personal Information, SPI)，因此要求企业在处理涉及员工号码的数据和文件时必须使用最高标准的安全系统。我见过My Number证件，证件颁发到手的时候都在外面套着塑料套，塑料套上对应证件中有隐私数据（比如My Number号，签名，性别等——没看错，性别也是挡着的）的地方，都是涂黑的，防止被偷窥。日本对隐私的保护的确让人敬佩。证件底部还有个询问式的声明：“在意外身故的时候，是否愿意把自己的器官捐献给还能用到它们的人们”。证件持有人可以选择同意与否并签名。这样医院就可以在证件主人死亡后第一时间做出判断。我只是匆匆一瞥证件，不了解细节。不知道这种观念在日本是不是已经被广泛接受，但这么普及地印在身份证上，在国内确实是难以想象的（我还在想万一被人恶意偷偷伪造签名了会怎样呢？医院会不会也没能力短时间分辨出来？）。除此之外，ATE还做了很多探索，现在用在HUE里的有OCR文本识别，和DicingSearch搜索引擎等。ATE一度还有个比较有意思的制度，叫Free Tech Friday。周五大家都不用做手头的工作，放开心情去搜索和研究相关的技术。只可惜只执行了半年的样子，后来大家就腾不出时间这么奢侈了。新产品自14年6月左右，前期调研和储备有了乐观结果，全公司开始抽调骨干筹备新产品。AI WORKS（内部代号HUE）在上海和东京分别试上马。这也是上海第一次真正意义上参与自主设计和研发产品。随着项目的发展，越来越多的人从相对枯燥的老产品维护中“解放”出来加入HUE。16年，ATE与HUE合并，称HUE&ATE。
已有的固然要精益求精，投资未来却更加重要。到目前，相较于COMPANY的产品更新，我们已经将更大一部分精力放在新产品的开发。在上海也已经有大半工程师在为新平台工作了。接前文所述，HUE的宗旨是给客户提供最高“可用性”的ERP服务，是把ERP云化、SaaS化了，不知道能不能称之为互联网+ERP。把ERP放在云上，利用最前沿的人工智能相关的技术，提供各种各样在移动互联网产品里才见到的，便捷到“amazing”的服务。让机器代替人类完成枯燥的输入，琐碎的安排，杂乱无章的信息管理，以及无从下手的业务分析等。新产品业务范围与传统产品范围基本一致，只是对用户来说，在使用门槛上大大降低，可用性、易用性大大提升。对于产品介绍，现在不同于5年以前，公司官网内容设计、本地化都做得不错了。所以其实关于新老产品线和概念都可以看到不少，需要的可以去找找。不过官网上东西比较粗略，我还是自己来尝试用通俗一点的语言来解释一下，常见ERP产品（不限于WAP产品）里到底都有哪些东西？WAP里通常接触到的上海、新加坡、日本等地的同事们都在做什么？面向客户的产品：1. 首先是Human ResourceManagement System，HRMS，简称HR，人力资源系统。 简单的说就是：管人的。（有没有点像划重点？）可能涉及的模块有：招聘、培训管理入职管理合同管理奖惩及条例管理绩效考勤社保管理工资管理人才池等国内我知道的一些产品有北森、泛微等。单纯做基础HR系统的似乎并不多见，因为做得太基础就很容易被其他方向的产品打穿。所以自己主营HR产品的，往往会做很深，会各自做自己的特色，比如深挖考评、招聘、培训等等。HR是WAP的主营产品，所以战线很长，各模块也都做得相当深入了。HUE HR各地也都有分担开发角色。上海目前有一个组在做考勤管理，是位日本同事（manager）在这带队。另外有两个组在做招聘管理，全部都是中国同事带队（一位资深VP“九虎”，一个manager“Ebby” [哈哈，@Ebby，你比爱彼迎少个迎] ）。印度办公室也贡献了相当一部分开发。2. Accounting财会系统，显而易见，管钱的。财务很复杂，要支持财务会计也可能要支持管理会计、成本会计等。随手列列就能有很多内容（并未系统分类）：资金管理资产管理存货、销售、成本、工资核算税务管理报表管理发票管理应收应付、债权债务财务分析决策支持等国内做财会有种说法叫南金蝶北用友，简单地概括了国内中小企业财务软件市场的分布，不过这两年财报上看这种分布也越来越模糊了。大公司用最有名的还是老大哥SAP的产品，只不过SAP的价格相对也高些。国内也有一些做或水平或垂直细分领域做得不错的系统，如云账房之类。目前HUE的AC开发大部分集中在日本，并逐渐向外转移，因为财务系统需要的知识还是太深需要积累，并且市场的水也很深。上海和新加坡有涉及AC部分主要是费用报销相关模块。上海这个组是15年我建立的，做移动端的费用报销。一方面为了多了解一些业务，另一方面为了尝试移动端开发，毕竟现在国内人们对移动办公的认可度相当高。这个组制作了安卓苹果双平台上的客户端，产品除了能够便捷填表申请费用报销以外，更可以以OCR识别票据，公交卡读取出行记录，从Schedule里读取出差/访问计划，运动模式分析等等方法智能地辅助完成报销申请，这也算是AI的一种应用。新加坡的组工作内容类似，不过不做移动平台，是做一些报销相关的公共组件（基础设施），而东京也有组做PC端的费用报销。这种合作还是蛮有意思也蛮有挑战的。3. SCM（Supply Chain Management），管供应链（这是个很广义的词）。比如：计划策略管理采购及供应商管理制造过程质量管理库存管理运转、分销、配送、退货SCM也是非常非常传统的ERP模块了。最早的MRP跟SCM业务重合度非常高。对生产企业来说，效率就是生命。SCM就是用来提升生产效率的。领头羊也都是ERP行业的翘楚：SAP，JDA，Oracle，Infor，IBM，Highjump，鼎捷…… HUE的SCM业务主力同样在日本，是一批非常资深的工程师。4. CRM，管理客户关系。市场和客户销售管理营销管理客户服务电话中心公司目前没有正式的CRM产品线，不过我手里的一个内部的HelpDesk项目正向着CRM产品线发展。竞品比如Salesforce，比如Atlassian.5. EC(e-commerce)，管线上销售电商，大家都不陌生了，各种各样的购物网站，很多公司也拥有自己的购物网站。公司的电商业务目前由新加坡负责。6. OA系统，管办公室活动的。办公室职员都可能用过的功能有：日常沟通协同工作文档管理公告及内部论坛任务日程管理通讯录问卷调查知识问答通用流程审批等OA系统比较常见。国内OA向移动端倾斜比较迅速，钉钉，金蝶云之家、今目标等等都可以算比较常见出现在视野里的办公平台。HUE的OA功能被Enterprise Collaboration覆盖了，Enterprise Collaboration向大企业客户提供了如G Suit, Office 365的云办公套件。然而OA只是其基础的一部分。Enterprise Collaboration不止于OA，它与其他ERP业务的协调自然的整合，才是新一代的企业级协作应用服务套件的过人之处。Enterprise Collaboration也是众多业务中上海参与度最深的。大多数Collabo业务目前都由两位中国VP牵头和负责，另外还有一部分业务如云盘，邮件等在新加坡开发，但仍向上海汇报。Enterprise Collaboration对比上一代产品中的功能更为丰富、更为独立、更为便利、更符合现代的使用习惯。也尝试了许多之前没有想过的东西。所以可能反而因为上海和新加坡的工程师更年轻和前卫，没什么桎梏，突破更大。项目完全由上海和新加坡主导，效果和进度都非常不错，上海还因此拿过两次MBM（公司年度最高荣誉）。客户们对Enterprise Collaboration都很惊喜，要求多多反馈多多，小伙伴们成就感十足，也乐得忙得不亦乐乎。以上是现在我常有接触的产品，之后有想起来的再补充。产品脚下的巨人们：上述都是产品部门，与业务关系紧密。产品工程师们需要直接对运营、销售、咨询和客户负责，最终要把符合业务要求的、好用的产品如期发布给客户。除此之外，还有一些其他部门，会是比较基础性的、架构性的，对外界相对透明。7. BT（Base Technology），是HUE的“脚手架”。顾名思义，作为基础技术部门，BT要为产品组提供必要的底层支持。包括框架、组件、持久层、通讯层、安全控制、编程工具等等。最早BT就是在上海发展起来的，后来一度形成了上海新加坡做BT，东京搞产品的格局。上海绝大部分HUE的工程师都是做BT的。但没什么格局一成不变，最近一年BT又向新加坡倾斜。目前HUE BT也有超一百五十位工程师，大部分是在新加坡，小部分在上海（做前端框架，移动端框架等等），还有零星一些在东京。8. ATE，管HUE的技术“蓝图”。虽然ATE与HUE合并，但老的ATE还是作为HUE&ATE的一个重要部门出现。一方面负责HUE架构的审阅和改进，另一方面原有的一些ATE项目比如OCR，Search，NLP，AI等等也还是现在ATE的课题。ATE的布局没什么变化，仍然是东京一部分，上海一部分。现在有社招做NLP，机器学习等方向的，进来就很大可能加入上海的ATE。ATE招聘对专业要求特别高，相反对工程能力要求则不像其他组那么苛刻，迫切希望各领域里的博士和资深专家加入。9. CI、CD、QA、QE、Process Management，他们一起负责HUE的项目本身的正常运行。这是软件工程绕不过的话题。尤其是几千人的项目，管理、测试、集成、发布都是非常头疼的问题。各地都有，上海有VP坐镇，扮演了很重要的角色。10. Studio-A，负责“美”。Studio-A在东京，是一个妹子很多的组。她们比较符合大家对美工或者交互设计师的理解，定义了HUE的所有设计规范，专门审阅改进产品的界面和交互体验。曾经上海有过一个Studio-C（C=China），我还在其中感受过。实事求是地说，我们这帮糙汉子的确没有Studio-A那么专业，东拼西凑出来的“美”感总有那么点违和。如果哪位有资深的交互设计经验，愿意来ERP领域里也一展拳脚话，我想我们也会非常欢迎。11.咨询，站在客户背后的男人女人们ERP系统都无比复杂。根据不同客户们迥异的业务和需求，系统需要在导入之初进行详细的配置，使用中也要随时跟随客户，不断的变化和调整。作为以Package售卖为特色的WAP，产品的功能和细节更加庞大，配置起来则更需要对产品深入的理解。咨询团队因此应运而生，为客户提供售前售后全周期的产品使用支持。作为客户与WAP之间最主要的桥梁，他们必须充分了解客户的业务和现状，并透过现象，挖掘出真实的需求，然后在系统中给出解决方案。同时还要及时响应和解决客户在使用过程中遇到的各种疑问和问题。因此，他们常常出差在外，风餐露宿，很是辛苦。12. Sales&Marketing，我们的“门面”。 放在压轴位置，当然是因为这个团队的重要性了。公司的“开源”可就全仰仗他们了。上海的销售团队成立要晚于开发不少，但不知不觉中，上海的销售团队也成长得初具规模了。这可真真是个帅哥美女云集的地方，而且不仅颜值是担当，才气更是超群。全部是来自北大、人大、上外等高校的才子才女，说得一口流利的日语，都有几样拿得出手的才艺。这个部门可能是氛围最活泼团建最频繁文化氛围最浓的团队了，许多有趣的故事还是后面再表。13. SRE最后这个话题/部门应算是个“节流”的部门。这也是我目前所在的部门。SRE是来自谷歌的概念，Site Reliability Engineering。说白了就是DevOps的一种落地实践。WAP的SRE部门涉及的东西比较宽泛。包含传统的运维（也输出一些运维产品），也包含客户支持。日本SRE主要负责真实生产环境的运营维护，以及一部分自动化。我带着上海、新加坡和一部分东京同事做SRE中的开发工作。现在开发的有三个项目，一个叫Morphling（魔灵），是HUE的运维平台，可以部署、监控、调度HUE。另外两个可以合在一起作为HUE的HelpDesk（及客户关系管理），用于不同阶段的客户支持，以后几千家客户的售后服务会从这个平台走，毕竟产品帅起来了，售后支持也不能落后认怂不是。由于历史原因，SRE最初开发分布东京、上海、新加坡三地，但交流成本太高，一直在迁移和改进。16年中期东京分支转去支援HUE的架构，东京的开发内容由一位在日本两年多即将回国的同事带了回来。16年底，新加坡的业务重组了回了上海。17年初，上海又有一位资深VP加入。自此SRE的开发基本集中在上海，但会把一部分具体开发工作委托给印度清奈的Office，所以我们和印度的合作现在变得非常紧密。其实最初准备做运维工具的时候我们并没觉得做一个开发运维会很有意思。但渐渐地我们发现这个领域里我们有相当的话语权和自由度，坑是真多，收获的东西也大大超出预期。我们不依赖HUE的技术（为了保证鲁棒），所以框架和开发也不必像HUE里的那样重，我们精益管理，自治而且轻便，可以接触、尝试和选择任何有益的东西。Spring boot，React，ansible，docker，Kubernetes，Prometheus…相对来说，我们与各个部门，尤其是ATE和BT部门保持着非常良好的关系，因为运维工具与架构和框架耦合相当深。我们也可以算是除了ATE以外对整个HUE的架构都有较深理解的人。同时，在开发、测试、构建、部署上我们也必须与HUE相互独立，自给自足自成体系。所以组里每个人可能知识深度还需不断加强，但技术栈都相当全面，不拘一隅。对敏捷开发和“怎么做成一件事”应该都比较有感悟。这个HelpDesk也是个游离于常规产品之外的“怪胎”，虽然使用了HUE的技术栈，但也要从设计开发到CI、发布、运维全都自己做。因为产品本身的安全级别超脱于所有其他的HUE产品，组外人员无权碰我们的东西。我们面向的目标用户也非常杂，有WAP内自己的员工，开发、销售、咨询、支持中心、管理层，有客户的各业务的负责人，有可能有客户的员工，甚至还有可能有客户的客户。这个产品定位与普通产品差别太大，所以也定位在了SRE部门里自治。未来我是有打算把它发展成CRM产品的。概括地说，客户摸得着看得见的产品的开发，在各地均有。就过去两年来看，相比说日本办公室对日本本地业务的支持倾斜度高一些，而上海、新加坡对国际市场的倾斜度高一些。另外上海和新加坡对架构、框架、运维等贡献特别显著。当然这种布局并不固定，会随着市场和项目状况不断变化。这也正是一家“二次创业”公司的特点。工作风格和工作日常撸起袖子写代码？ 工程师真的好喜欢一言不合就撸！起！袖！子！写！代！码！但在WAP，你要知道，写代码是除了销售及人事行政部门以外几乎每个人都必备的技能，并且水平还不能差。所以它有时候显得没那么重要。写代码当然也还是分快慢和好坏，但在达到一定的水平后，我便认为它只是工具，用好生产工具，重要，但不绝对。代码不是全部，甚至产品也不是全部，业务才是。在WAP，每一个项目/子项目，以及每一个大的功能模块（功能可以支持大的故事，叫Epic）负责的工程师都要提供一份经得起推敲的catalog，内容有点类似商业计划书。做工程师的大部分不爱写文档，之前也从未听说过哪家IT公司会对一个文档这么重视与执着。我们最初也都觉得多此一举，有许多东西可能一看便知道该怎样做：客户的业务需要多人交流，那像QQ一样给他们创建个群不就行了？或者，如果不需要实时交流，那就做个BBS。当HR需要在人才库里为某岗位寻找胜任的人才的时候，让用户根据他们公司对人才的定义，输入一些合适的数字做各种能力的权重，我们计算并排序一下不就好了？那么剩下就是设计接口、数据库，赶紧实现，考虑怎么样让程序更快地跑了呗（不得不说中式教育让人容易踏入误区，99%的CS学生都知道时间空间复杂度的重要性，但却没几个人想着应该好好测测他们写的程序）。这多简单啊！但一段时间之后，尝试过一些碰壁，你会开始怀疑，“你以为你以为的就是你以为的吗？”你可能会发现，你之前所认为的理所当然的东西大多不是最优解，甚至都不是一个次优解。你期待用户输入的东西对他来说也可能完全不知所云。经验让我们学会了，在撸起袖子写代码之前，先在纸笔间记下和推敲你的solution（被润色过的solution和产品原型还可以让喜欢尝鲜的客户直观了解我们的计划，有所反馈和期待）。这并不是为了杜绝犯错或减少犯错。恰恰相反，这是为了让失败尽早发生，尽快发生，经常发生（“Fail early, fail fast, fail often”——Team Geek: ASoftware Developer's Guide to Working Well with Others）。WAP的一个工程师年成本50万人民币以上。如果在项目一开始我们就能够在不同的声音里发现这个提案里隐藏的问题，要远比几十个工程师忙忙叨叨开发一年后——拿到客户那里——再被请出来，成本要低得多。另一方面，即使不考虑到方向对错与否的问题，catalog同样是可以节省团队内/团队间的沟通成本的。一千个人心中有一千个哈姆雷特。“做个好手机出来”这样一个看似简明美好的要求在十个人脑海里就会浮现出十款不同造型和功能的手机（现在大部分人脑子里是iPhone了，但想想十年前的时候）。“吃顿大餐”，在一些人脑海里可能是鲍鱼海鲜，另一些人想的可能是烤全羊手把肉。所以把意见/建议都收集和统筹起来，形成一个大家都能理解和认可的模型，再坐实到笔上。才会减少团队里各自的输出有“驴唇不对马嘴”现象的发生。所以从经济角度上讲，写catalog是一个几乎可以肯定会为团队省时省力的选择。只不过自然而然这对写catalog的人要求和挑战很高。对广大工科科班出身的同学来说，“写文档还不如杀了我”，明知道有益也不愿意写。但在现代社会，“个人英雄”越来越式微。凡事还是要团队的交流与合作，这种“挽起袖子就干，只要干得好嘴笨点没什么”的观念是得需要改一改。那怎么样才能判断一份catalog的好坏呢？有人问过：“你敢review别人的catalog，是不是得什么都懂？”怎么可能呢，没长着三头六臂，同样获取知识的途径也相差不多，何况大家也都是出身211、985身经百战的高才生，专业知识的储量通常不会差异太大。区别不过有些同学会是在某些方面专精一点，而我则恰可能在更多话题上都是各懂一点皮毛。但问题是，不是很懂就没有办法判断东西的好坏了么？这不见得，家里的老太太不懂生产工艺，但同样能判断出一台电视机值不值得买。有时候反而还越是置身事外越能客观地判断好坏，因为，没有偏见。判断一个catalog的好坏，无非就是三点：结论、事实、逻辑。对，如果你还记得高中时候虐得你死去活来的作文写作的话，这其实就是一篇典型议论文：论点、论据、论证。而且一些其他行业用的报告甚至也是这么个套路。因为世间少有绝对的对错，结论（论点）反而往往成了最少去争议的点。只消事实充分（你要支撑的真实业务是什么样的？人们现在正在怎样做业务？需要解决的问题有哪些？竞品有哪些？研究的覆盖面够不够广？）清晰无误（的确是这样么？每个人都这么说？听到的会不会是假象？取样有没有偏差？哪些渠道可以验证？）归纳和推理的逻辑严密圆满，让人不自觉跟着你的思路走，且不会觉得磕磕绊绊得不舒服，没有漏洞，少有怀疑。那自然就是一份令人难以反驳的好文。我写catalog的时候习惯上还先用思维导图做个大纲，确保逻辑通畅，以免着手细节之后会忘了顾全大局。但如果我听你的介绍，边听边产生疑问（这个突然冒出来的归纳是哪里来的？我见过的客户明明不这么干吧？为什么这里有个参数“2”，不是“4”或者“5”？这句话说的什么意思？为什么要设计这么复杂？这里到底该输入A还是B？怎么保证一个全新算法的计算结果有意义？这成本是不是太高了？结论来的好突兀啊……），文章前后不能自证（比如前文明明说需要高可用，后面的设计里却出现了单点失败SPOF），那么这catalog自然就难以避免被人诟病。其中结论也无法让人信服，只好回炉重做。事实上review并不是目的，而是一层又一层地试错的一种方法。“如果你连我都说服不了，我们又拿什么来征服更加挑剔的老板和客户？”用自己的体验来说，最初对这种工作方式的不适，会在一点点尝到甜头之后慢慢习惯甚至喜欢。而在习惯这种比较严谨的方式之后，的确会在思考方式上受益良多。看事情会更加立体。而且按推敲出来的方案做事情也会更省心更踏实。自下而上，参与、自由在我看来，WAP喜欢会写catalog的人，另一个原因是“想写的好catalog，在思维习惯上就懒惰不得”，而能保持思维活跃的人，在工作中就肯定不甘只是一颗螺丝钉“programmer”，更是个上进而爱独立思考的“engineer”。而这些成百上千分布在各个部门里跃跃欲试的“大脑”，才是这个团体能保持活力保持进步的最大依仗。不需要凡事都必须老板下令，只需要指出一个正确的方向，这些分布的大脑们就会闻风而动，创造出各种各样新奇的富有创造性的点子们来，并一遍遍地去伪存菁，验证继而实施它们。这是听上去就很酷的事儿啊。所以在WAP，也是这么实践的，开发过程大部分都是自下而上的。就像catalog一样，开发中不停地有“挑战-改进-挑战-改进-向上一级挑战”的过程。（除了HUE伊始，HUE立项时是比较自上而下的，这与当时的情况有关。）很大一部分boss的理念里就认为：给你我所见的事实，告诉你我想要达成的效果，提供给你需要的资源和舒适的环境。接下来，怎么创造惊喜，就是你的任务了！当然如果你跑太偏了，那我得给你拽回来。然而每片叶子都有自己的纹路，不见得每个人都适合这样的工作方式，所以Office里有部分微管理也是能见得到的。但无论哪种方式，员工们的自由度都相当大。员工们在绝大多数团队里都可以自由挑选想做的工作（当然脏活总归得有人做，但大家通常轮着来，或者当它们影响效率的时候，也总会有人尝试把脏活变干净），而且只要做事靠谱成绩出色，什么时候一个话题做腻了，想要在团队间Job Rotation也少有被拒绝的时候（原则上两边的Boss都同意就好，这也是为什么需要你做得出色，“害群之马”在哪里都不会受欢迎）。上海两百多名工程师，可做的课题还是相当多的，想都做好做到腻可不是件容易的事儿。想转去日本或者新加坡工作的门槛也很低，踏踏实实工作一两年条件就基本都可以满足。同学们问得比较多的一个问题是刚入职通过STM研修期之后我能不能自由选组？对不起，现在还不能。按近两年的经验，一批同学入职，十之八九都想马上去AI、大数据、数据挖掘、机器学习、深度学习等领域一展拳脚，即便有的同学一丁点相关经验和背景都没有，甚至概念都用不熟悉，因为总觉得这就是大势所趋，这才是大势所趋。刚入职的同学们对公司和项目所知甚少，还稍显盲目，哪个酷就想做哪个，这很自然。但是做项目还是得讲朴素的基本法，不能只想云际不管落地。所以刚入职时候的分配是VP们根据每位同学的背景、性格、履历、作品和倾向等统一安排的。原则上不会有例外。虽不可能让每个人都十分满意，但会尽可能照顾各方因素。所以如果希望毕业伊始就能到一个与自己契合的组里工作，我建议新同学们千万别像“大姑娘相亲”一样“扭扭捏捏”，提前就主动一点，跟身边学长学姐们多接触接触，了解了解他们在做什么，产品有没有意思，需要什么样的人才。这样才能打有准备之仗，在表达自己的意愿时说的有理有据。（在VP们统计工作意愿时，合理地表述清楚自己的意愿和诉求非常重要。不仅是发声说自己想做什么不想做什么，最好还要让人信服地知道为什么你适合/不适合。）进组之后的工作日常又是怎样的呢？这个我无法足一而论。WAPC员工增长十分迅速，现在大大小小也有几十个组（四五人一组，由个leader或manager带队，是常见配置）。各大小boss的管理风格都不同，所以在每个组里的体验肯定都不相同。即使同一个组内，组织结构或项目状况变化，组里的状态也会不同。不过只要是开发组，除了项目内容和松紧状态会有区别，其他相对大同小异。大部分组都会用偏敏捷方式开发，吃自己的狗粮（有的组吃的多，有的组吃的少，有的组有人帮着吃，有的组不得不都自己吃）。有的精益管理，有的Metrics-Driven。大概都遵循PDCA（Plan-Do-Check-Act）的循环。HUE的BT和产品组6个礼拜一个迭代，我的组3个礼拜一迭代，近期准备统一调整为4礼拜长的迭代。所有的组都在一个相对紧凑的进程里，实际上都在不停学习进步挖坑填坑挖坑填坑……HUE太新又太大了。对于公司来说，这么大规模几千人的二次创业也是“大姑娘上轿头一回”，没有足够的经验教训可以汲取，没有足够的技术积累可以利用。但对客户的承诺不能缩水。所以说所有的组，有一个算一个，都不停地在挑战不可能。没有停止进坑的时候，挖过的坑也没有真正填完的时候，总在追求完美，一边挖一边填，互相挖互相填，乐此不疲，共同进步。产出呈现出来的时候，成就感真的难以言喻。坑多工作自然也要辛苦点，“是不是经常加班”这是我被同学们问得最多的问题。有啊，肯定有，你见过哪个互联网及软件公司不加班的？不过加班厉害不厉害？主观地说，不厉害。在入职头两年，进入HUE之前，我基本从没加过班，同事们七点以后也大多不会在公司了。进入HUE以后，时间不规律了许多。项目抽风的时候偶尔赶赶末班地铁甚至打打车，也是会有的事儿。节点过了，进度赶回来了，可能再放一放羊。现在我组里的孩子们责任心特别强，他们晚上不走的时候我也会有意识地多呆一会陪陪他们，也提前给项目铺铺路。不过我们一直都理解和提倡合理安排时间，常常还会催着孩子们走。中国的leader、manager、VP们都倾向于把计划做得科学一点（比如用Scrum的plan meeting，这样所有人都能参与进来评估工作量），容错性高一点（不至于因为一点变动就导致大规模未预期的工作）。尽可能把辛苦的阶段调节开，有松有驰才能长久。日本的同事们有的则相对更刻苦一些，有时候会push的比较紧，但也都在容易接受的限度内。何况WAPC本来就是弹性工作制，走的晚的时候通常我们也会来得晚些。甚至如果员工有事，提前跟老板和行政打好招呼发好邮件，可以很方便地晚来或早走，一天工作四个小时以上就不算缺勤。周末加班更是少见了，周末如果的确业务原因需要加班，必须要在系统里向Manager及VP申请取得批准才行，然后还能换对应天数的补休。实际上周末加班也只有去招聘的工程师才常碰到一些。为了照顾同学们，招聘活动经常安排在周末，工程师们要配合HR笔试面试实习，就需要周末工作。有的工程师还就喜欢周末招聘把假期攒到一起去旅游。周末以外的法定假日更是五年来从没被因公占用过（还没人拿过3倍工资），本来今年五一假期期间有一天还有招聘计划，但被VP们驳回了。加不加班也因人而异，Manager和VP们工作时间一般就比较长。就我自己来说，现在工作时间有时候不那么好算。因为很早就不写代码了，我的工作内容更杂更操心一些。不管是在公司、家里、出差，工作日或周末，我通常24小时手机开机收发消息。即便深夜我都有看邮件扫扫聊天频道的习惯。包括写这篇回答，虽然不算工作内容，但其实也是为了工作服务，我断断续续每天夜里写点，写了一个多月，最后是在带孩子旅游的途中完成的。后面一点点的校对修改，更是持续了几个月。但因为养成了习惯所以也都很自然，打游戏间隙的时间也能回回邮件，倒没觉得多负担，保持着一种有责任感的状态也很开心。待更新（最后更新6月25日）8543 条评论分享收藏感谢收起查看更多回答5 个回答被折叠（）}