Tag: 工作

这是一个抱怨工作的日志。

目前的工作做了两年多了，我还是不理解我老板和pm对我的要求：我们不own逻辑，但是我们own这些job（不own逻辑到底怎么维护job？）。其中有一个job是给外部送文件，我一直被告知这个job我们priority很低。前一阵把那个job完全refactor一遍后，那个job出了错。那个错是我没仔细测试造成的。的确，做了两年基本上没有什么数据的逻辑是很清楚的工作后，我对自己的要求降低了。因为出了这个错，我配合英国同事修补数据，有一个星期里通宵了三天。只要我和英国同事交流的时候，我都很清楚他们要我干什么。但是我PM介入的时候，我一半的精力都要用来应付他，总是让我感到怨气冲天。

不过我今天要抱怨的是这件事之后的事情。因为犯了这个错，忽然发现这个job的重要性是很高的，闹到了很大的老板那里去。然后，我们老板忽然说，这个东西很重要的，下周我们开会的时候我们会说，我们已经加了validation的job。我问那么业务逻辑呢？PM说，业务逻辑你敢问吗？问了以后你就要做主了啊。我顿时火气超大，弄清楚业务逻辑是PM的工作，我也需要知道一些，但本质上是PM的事情。现在PM和老板做事是很巧妙，但是就把风险转嫁给我们开发了。一般数据validation要懂得逻辑才能做，而我们的逻辑都是从代码里看来的（而在refactor的时候老板说，你不需要看代码，机械地转就可以了，越想越觉得，我现在的混乱是老板造成的，当然，我也要小心人总是喜欢怪别人的倾向）。

然后事情继续在让我生气的路线上发展。因为这个事情很重要，所以我的工作狂同事介入了。她二话没说，就写了个validation脚本（写的时候随时打断我问我问题）。写完后叫我帮忙上线。我准备上线的时候她又轻飘飘说了一句，你顺便测一下。我拿到代码后才发现她只写了逻辑，而schedule什么的都要我来写，等于我承担了三分之一的开发，50%的测试（她说她测过一些），和80%的风险（上线），结果这个事情还是她做的，我真是吃力不讨好。

然后不要忘了，这些validation都是为了老板在开会时可以说一句“我们已经加了validation”而做的。实际上我们对业务逻辑还是没有更多了解。甚至，validation的逻辑也完全没有讨论过。如果validation不通过要走怎样的流程也没商量过。这不是最近黑五到了，销售数据普遍飙升，我们的validation就开始挂掉。上周有一天我在工作狂同事的指挥下一会儿发文件一会儿删文件。搞到晚上很晚，她还说，要是英国那边没回复，你今晚带电脑回家去。为了我晚上带不带电脑回家这件事我跟她争执过好几次。我并不是完全不带电脑回家的，但是她明确要求我这么做让我非常生气。我老板也没这么要求过（老板他太人精了）。

但是我工作狂同事真的工作太卖力了。我估计手机上收到工作邮件她都会及时看的（而我最初配置手机邮件的时候，因为手机root过不符合公司安全政策，所以没有装。现在我买了iPhone，但是看到工作能在业余时间也占据人的心思还是怕了没配置工作邮件。我以前的工作也有过这种问题，我像刷社交媒体一样刷公司邮件，迫不及待想要keep up to date）。平时她来办公室比我早，离开办公室经常比我晚。有时候早上六七点钟，或者晚上十一点出了什么事，她都可以立即开始工作。而她还有个两岁的孩子。我其实很感激她有时候帮我挡住无知又自大的pm。而当我有什么不确定solution的开发问题，她都会提建议（虽然，我经常觉得她的做法我不太满意。我更喜欢在事情都澄清了以后好好地做和测试。在她的建议下，我take了更多的risk，有利有弊吧。）。但是，她这样任劳任怨真的是助长了我老板的人精。我老板还是觉得我们不own逻辑，不需要很多的人力，按照这个去安排工作。但是实际上我工作狂同事一人做了两人的工作，而且造成我们team如果想要做得不出错，别人也要这样才行的局面。

这是周日早看了一眼fail的数据的人的抱怨。虽然，比我起得早的工作狂同事已经处理了，但我还是觉得怨气冲天。

一直在想要把工作的感想给整理一下。看到这篇文章里写的效率低的开发团队的几个特点/分类，我们公司的膝盖已经戳烂了。（看到“保姆式开发”几乎从不说脏话的我嘴里迸出了卧槽二字。）

工作感想还没整理。现在意识流一篇帮助自己整理。。。

我并不是很想做开发。在逻辑思维方面我比较迟钝。做开发的话我的优点是愿意尝试和不assuming（简直paranoid）。只要有文档和尝试的环境，搞各种script我是没有问题的。我另外的长处是对BI数据库比较有经验。我对Application比较没经验。我们公司的BI产品，还有一部分是application的成分（客户使用界面），想想我在现在公司的5年，最大的收获大概是瞥见一眼application开发，我们公司的开发水准很烂，但看到开头提的那篇文章之后我想我也是得到了一些关于烂的思考。

我喜欢捣鼓script，我更喜欢借用我会技术又会沟通的能力，做一些桥梁工作。工作这么多年来，我见过的人里面，除了极少数人，沟通和技术结合没有我比我强的。当然比我会说话的人多了去了，然而我认为实质的沟通的基础是你要懂你沟通的东西。我也和销售打过交道，有的销售是非常有魅力的人，然而他只负责散发魅力，说实质的东西的时候必须站在他的角度才能沟通。懂数据，懂技术的人，能像我一样沟通的人很少。That said，我加入现在公司的初衷是做这样的桥梁。我加入的是operation部门。我们的operation部门不仅给产品上线、monitor它们的运作，还要保证数据的质量并处理各种客户的咨询。由于我擅长看数据和写脚本，我加入不久就写了一系列脚本帮助monitor我们当时几百个instance（如今已经超过一千个了）。这里对我的技术是有提高的，在之前我只写过ETL的SQL和简单的shell script，连个DB store procedure都没见过。但这家公司的ETL是基于SQL Server的DB SP的，我一边理解产品，一边写出了那些脚本。开发中有些愿意讨论问题的，我也有时候找他们请教。Operation部门工作了两年，我意识到我们产品的问题这么多，其实需要的是开发质量提高。中国办公室的开发老大愿意让我去开发部门继续做更深的技术支持，我就答应了。因为在operation做得再好，也是我已经做了两年的事情了，做得好不再值得骄傲。当时在我看来开发部门有很多事情我可以帮助做好的。比如，开发部门的沟通太烂；大部分开发查数据的技能比我差；大部分开发互相之间都在鸡同鸭讲更不要说和别的部门讲了；大部分开发都不知道operation是怎么deploy和monitor我们的产品的，也不知道客户一般都喜欢干什么。

到了开发部门，我的第一件事是理解release流程。我很惊讶地发现，给定一个特定的时间，在产品环境的某个版本发现了问题，给开发开CR去修复的时候，修复哪些版本这个问题是没有定论的。每一次开CR都需要问release manager，而得到的答复也没有确定的准则。在开头引用的那篇文章里，对此有精确的描述：

配置管理上的问题。对于源代码的配置管理，其实并不是一件简单的事情。配置管理和软件和团队的组构的结构非常有关系。我看到过两种非常没有效率的配置管理，一种是以开项目分支的方式来做项目，同时开很多分支，分支开的时间还很长，导致merge回主干要花大量的时间去解决各种冲突，另一种是N多的团队都在一个代码库中做修改，导致出现很多复杂的问题，比如某团队的改动出现了一个bug，要么所有的团队的功能都得等这个bug被修复才能被发布，要么就是把所有的改动回滚到上一个版本，包括其它团队开发的功能。很明显，软件模块的结构，软件的架构，以及团队的组织形式都会严重影响开发效率。

我们的情况是上面说的很多module在一个库，一个bug会导致所有的无法上线。我们情况的区别是，我们的产品环境压根从来没有回滚上一个版本的功能。很长一段时间我不理解release management对QA提供ETA的要求。ETA方便给客户期待，然而我找QA问ETA的时候经常得到的答复是这样的：如果开发下周二之前把修改提交，那么我们的ETA就是周五。然后周五的ETA就被宣布了。根本不给“开发如果没有来得及修改提交”或者“提交后又测出bug”留余地。

当年我们还有一个非常低级的问题：我们的产品有一个版本号，在部署的server上，代码存在这个版本号为名字的路径下。后来bug越来越多我们变成两周更新一次release，但是版本号不变，这就造成如果不具体看代码你无法知道你面前的版本X是不是最新的版本X。对于DEV和QA来说，只要改好了代码，测试通过，他们就任务完成了——我们deliver了一个修改好的版本X。当时出了一系列问题都是宣布release了但实际上并没有更新到deploy server上。因为DEV和运维之间当时几乎一直在鸡同鸭讲。后来终于认识到需要更新到server上之后，还有很多问题。有些bug需要更新代码后重新deploy，有些bug只要更新代码就好，还有些bug重新deploy后还需要跑一些一次性的脚本。谁来跑脚本这件事一直没定下来。理论上让开发去产品环境deploy是很糟的。但OPS的技术能力有限，让他们跑命令行也经常很危险。还有的时候跑了一次性脚本之后代码没更新，下一次deploy问题又回来了。作为战斗在第一线处理产品问题的我，这样的事情见得太多了，我经常跟老板反应，但是总是‘解决问题更重要’，解决了以后大家就舒一口气又去忙各自的了。

那篇文章里的“保姆式”开发和我们的现状最像。

所谓“保姆式”软件开发就是——我只管吃饭，不管做菜洗碗，就像——衣来伸手，饭来张口的“小皇帝”一样，身边有一堆太监或宫女，不然生活不能自理。这种情况经常见于开发和测试，开发和运维间的关系。很多公司，测试和运维都成了开发的保姆。

我就能看到，很多开发快速写完代码后基本上都不怎么测试就交给QA去测试了，QA一测，我草，各种问题，而只会做黑盒的QA并不能马上就能确定是代码的问题还是环境的问题，所以还要花大量时间排除不是环境问题，才给开发报BUG。很多问题，可能只需要做个Code Review，做个单测就可以发现了，硬要交给QA。运维也是一样的，开发出来的软件根本就没有考虑什么运维的东西，因为有运维人员，所以我才不考虑呢。

我们公司的产品deploy一个的代价非常大，有几百个参数，好多机器需要权限。deploy过程中如果遇到错，需要各种技术能力来分析解决：DB的，java的等等。所以我经常看见开发问QA要环境进行开发。产品环境经常遇到的问题是，你改了一个代码解决了你的问题，但是这个代码在deploy别的类型的instance之后会有问题。当年我做开发的时候非常paranoid（当然因为我技术基础差），我一定要把我想到的所有情况都跑一遍才放心。我们的开发经常会说：“这个改好了让QA去跑一下吧。”，或者在你问他“XXX在YYY的情况会不会有问题”的时候经常得到的答复是，让QA去试试吧。

文章中说的watchdog式开发，我们也是很多。

什么是WatchDog？就是说——为了解决某个系统的问题，我要用一个新的系统去看着它。

• 我的系统架构太复杂，出了问题不好查找。咋办？那就搞个专门的特殊的监控系统吧……

• 我的系统配置太复杂，容易配错了。咋办？那就加一个配置校验系统吧……

• 我的系统配置和真实的情况有时候可能会不一性。咋办？那就加一个巡检系统吧……

• 我的系统测试环境和线上环境有时候会搞混了。咋办？那就为线上环境加一个权限控制系统吧……

• 我的系统有单点，那就加个负载均衡器吧，负载均衡器的单点呢？那就再加个等价路由器吧……

因为我们的系统很难从整体来把握。整个公司大概只有三个开发能从架构角度了解全局。而其中最重要的一个人，是个asshole。整个公司的人，素质好一些的都在尽力和他合作，素质差一些的整天在骂他。所有人都对他多多少少有点无奈。我曾经被他说哭过好几次。其中有时候的确是我的理解有误，如果我被直接告知我哪里错了，一般我会看我的错误并且觉得很羞愧。但是这个人指出错误的时候从来不说清楚，而且带着很挑衅的不客气语气，说着读不通的英语（印度人的英语其实是很好的，但是他一直散发着一种“我不care发表清楚的沟通”的气场）。

所以呢，开头说了，我来公司的第一件事就是写了个monitor系统，也算是watchdog的一部分，不过这是在产品之外的。我觉得很多真的产品开发，也是对他的整体设计不得要领无法写出integrate到整个产品的好东西，而是尽力保护自己开发的部分，即使冗余也不敢信赖已有的东西。我曾经听一个已经离职的开发经理说过，那个架构师的代码，即使他们看到有可以优化的地方，他们一般也不敢提建议。

虽然我并不下决心想做开发，但是看看coolshell博客，简直觉得振奋。也许我对技术的热情也是有点“希望保持业余兴趣”那样。按照引用的这篇文章，我并不是个合格的开发。我会的技术太少。专攻技术的问题在我们公司的开发中也很突出，甚至明明都是ETL的东西，A开发的东西B就觉得自己没必要去了解。更不要说大部分BI开发不懂java的部分，而绝大部分java开发的SQL水平在我看来简直小儿科。在这个工作中，我也试练了我的学习能力。写SP对我很容易（来自SQL和shell背景）；查询MDX对我来说有点难：我按照MSDN上的教程自建了一个cube（当时我要就建cube的权限问题问了一个当时我们的cube专家，他都并不知道根本逻辑，只是建议我都用admin账号）、读了MDX Solutions的前几章；另外学会的是powershell。Powershell我不能完全说学会了，没有官方教程和完整的说明书（MSDN的结构太恶心了，PS的manual是和.NET的混合的），我看了powershell.net上的一个非官方教程，对变量、control flow、function、object等等理解了。但是后来看代码的时候还是看到了我本来不知道的东西。微软的环境很封闭，文档很难懂，依赖微软产品的我们公司应该也是直接间接受了影响。不过PS似乎代表了微软的进步（终于有比较成熟的script语言了）。最近又写了一点点python的脚本。

我愿意学习，也希望在厉害的开发环境工作。然而我更大的能力是沟通和英语水平。我这个没有计算机知识基础的人进入这个行业有一定的巧合，也一部分是因为这个行业发展快，还需要人手。看看我能找到什么机会吧。

这两天工作上发生了一件事，让我很难平静。

过年前最后一天（我买了五点半的电影票打算早走的，我知道过年前是最后能刷R1的时候）。下午三点的时候发现来了一个High priority的ticket，是一个中国cube的ETL挂在cube process上了，是比较基本的问题。我就先开了profiler看process的错误。很快发现是process measure group P的时候报了个numeric overflow bigint的错。然后我就想办法在那个partition找哪个数据的值超长了。看了一下P的view的定义，只看到一个column是bigint，再仔细一看这个column的定义，我记起来别的cube的这个column曾经也出过一样的错。这个column的设计本来就有点奇怪，把store_key, item_key和一个measure X的值concat起来（当中有2个0间隔）再转bigint。按照我们系统目前的store_key, item_key的位数来看，measure X只要超过两位数就会overflow。然而当时PM说，这个measure只能是0到5六个值。估计是开发看了这个需求，也没想过可能需要处理超长的效果。（去年11月的时候我第一次遇到这个问题时，我的第一反应是把这个问题给DEV，因为这样危险的设计在我看来很可怕。在和QA确认的时候才得知还有限制0到5这回事。）

当时我急着赶电影，我就回复了一下：“这和ticket XXX是一样的问题。X数据只能是0到5。可是现在我们有42002这么大的数据。请检查一下是不是又重复load了文件。我已经关闭了这个silo的ETL。”这一句重复的文件的猜测，是因为去年我检查这个问题的时候，时间比较充裕，就顺便检查了一下数据源的历史记录，发现了重复的文件。实际上，这一次不一定是同样的原因造成数据过大。然而我想，是个operation（他们天天看数据，天天set up文件load）都会明白，接下来就该是他们去修复数据了。

春节值班的时候，我特意留意了一下这个ticket，我惊讶地发现他们没有更新。我猜是因为没人看见我说我关了ETL，所以它没有继续报错，所以没人注意到这件事。于是我把ETL又开了。（我们的产品环境就是这么混乱。）

隔了几天我又值班，发现operation看到了这个ticket，然而第一个回复是（一个脑子比较僵硬的中国男operation）：“我没有看到有重复文件，所以根XXX应该不是一样的问题，请再看看为什么cube process挂。”在我之前值班的开发同学M回复说：“为了跑过去，我已经从DB里删了数据，并且把删的数据存在了table_name_bak里。”这里的table_name是我们基本的measure group A。接下来，是operation老大吩咐美国的operation把坏的数据用正确的方法unload掉。

年后上班这个ticket仍没有解决，并且变成了urgent回到我头上，而问题还是原来那一个。不过加上了最近有过attribute变动，变成如果要process，是把所有partition都要process才能过去。这个cube属于之前中国特殊数据load，为了缩短上线时间，他们把这个retailer的数据全都做了redundant load，实际客户看到的数据只有我们load的数据的十分之一都不到，所以full process很慢。负责monitor新数据load的operation女生不知道这些，因为是周一ETL总体很忙，她无法在数据源unload数据。于是她一个劲催我也删一下数据嘛。

我的各种本能都告诉我不该在产品环境删数据。以前我的经理是BI开发的经理，如果他在我会跟他聊几句，肯定会避免发生接下来的事情。现在我的经理是APP开发经理，他的BI经验其实不多，我就没想跟他聊（实际上他虽然看所有的urgent ticket，但也并没有明白我实际上后来犯了个错）。

事实就是，我知道这是numeric overflow；我知道>5的数据都不对（进了cube也会因为dimension没有而不显示），虽然如果是8这样的值还不会造成overflow报错；operation一直在跟我强调过年值班的开发M同学删了数据后面就process进去了。“你看他那时回复的呀！”我有一种如果我不删数据，我就没有M同学有能力的压力。（实际上，M也是有技术但没有产品sense的人，在BI的方面，经验也是比我差一截。然而他是开发我是产品技术支持，而且他是男生，男生的无知自信对技术和产品sense差一些的人来说，就等于强大，不幸的是我们公司都是这样的人。）我还有一半的思绪在想如果要对这么大的表删数据，性能会不会很可怕。

结果我就按照M说的，把measure group A的不合法数据删了。

接下来是7小时的full process。

昨天早上上班的时候，我看到晚上的process挂了。我幡然醒悟：造成overflow的数据是measure group P的。P是从A算出来的。等于我删数据并没有帮助数据process成功，反而耽误了一天的时间。

我把这一点告诉了operation的女生，她还疑问：为什么M删了以后就process成功了呢？要么是M其实删了P的数据。如果要删P数据，鉴于它的计算逻辑非常复杂，如果暴力删数据会造成什么情况我说不清。我当时是觉得M一定是删了P的数据，因为他对P的逻辑肯定没有我熟悉，所以因为无知无畏而删是有可能的。后来仔细看超级长的ticket，我才发现更合理的解释是美国的opertaion当时unload掉了错误的数据（P会在ETL中重新计算一遍），只不过新的错误数据又来了。请operation按照正常的手法unload数据才是正确的做法，是我一开始的建议，但是在催促和担心自己看起来没有男开发一样的本事，再加上没有人来管我，我做了一个错误的操作。

现在，在我的坚持下，operation终于退回去修了数据，现在cube process终于跑过去了。

这个错误并没有引起任何关注。这件事的后果只是，本来delay了7天的数据多delay了一天。我的经理没发现我做错了，operation还没有来责怪我，我估计也不会。因为在我们其他的产品支持工程师里，比我这个错厉害很多的错多了去了。我一直在配合大家工作的同时，默默尽力坚持我的标准。这个错已经不是第一个让我觉得“啊，我现在怎么标准降低这么多啊？”的事件了。

一方面没受到指责，也更说明管理的混乱。另一方面，我自己也很难原谅自己犯了一个可以避免的错误。我从一开始对问题的鉴别，和对解决问题的建议都是正确的。我们公司的管理太fucked up才造成我从这么正确的起点开始都能走到错误的操作。

我觉得自己和去年的时候没有什么进步。离开上一份工作的根本原因是，我不看好他们的营业模式，和所处的行业。现在的工作的行业是所有人都能看出作用的零售行业，比上一份更合我意吧。而营业模式，在面试的时候很向往的Software as a service，真的就是这样的吗？我感到有点失望。

在商业还是技术这个选择上，我还是摇摆不定。我看不出自己有成为技术大牛的潜力，我也绝不可能充当纯商业的角色。介于两者之间，这个世界上应该是可以有我的位置的。

我一向是把工作看得很重要的。为的是什么？我想主要是为了自我发展。如今我很快地适应了新的环境，并取得了一些成果。但是我并不开心，因为似乎看不见自己的发展在哪里。公司里有Role Model的人物，但是离得太远了。我周围的人，似乎没有可以学习的人。理论上，我们公司还处于发展阶段，对个人还是有很多发展机会的；环境也比上一份工作公平。但目前，我还看不出自己在自己的发展这件事上，还有什么可以主动做的事情。

我现在常常会想起自己的第一份工作。DX说过的话，常常出现在脑中。不过我并不后悔当初出来见世面的决定。

离职的打算，我是早就定下了。为了顾及大局，也是提前很多时候和上司沟通过。目前的工作，我能做好，但是没有发展空间了。本来，拓展我的内部客户，可以是比较愉快的工作成果，但是后来，任务繁重到了很不健康的地步。辛苦不要紧，对我自己的帮助却不大，我认为这时候，是该跳槽了。

接我的工作的，是两位应届生。交接的事情很早就开始做了，但是四年的数据库经验，是很难一下子传授给别人的。我只重点将文档交接给了他们。今天临走前，还在和他们说文档（第二遍）。我一直相信，经验丰富的一方向新来者传授知识的时候，前者需要更主动，因为能力大，责任也大。因此我本来一直很希望能够把交接的事情做得漂亮。结果呢，由于太忙，知识文档没有写好，值得作罢。

今天是最后一天，而明天立刻又要投入新的工作中去。这个时刻我只感觉忙和累。我觉得为新工作作的准备也不够。

想当初刚来安居客，我自认为起步做得挺漂亮。在入职之前，我就在考虑我需要了解些什么，可能的困难是什么。入职后吸取了多方面的信息，成长还是很快的。我对自己的成绩感到有点骄傲。

我似乎已经得出了对于我这样内向、有点迟钝的人，要做好事情的规则。内向的人也可以勇敢，想清楚的事情，就要勇敢去做。要尊重自己，但不要自尊太强……

……想来想去还是觉得，DNA那样丝毫没有恶意的幽默感，似乎可以给我力量击倒一切普通的困扰。而剩下的，则只有大的困扰了。大的困扰不会拖坏人，只会教人谦虚和懂得珍惜。

最近实在太忙了，在新工作入职前夜，我才挤出了这么点思索。换工作的一个目的也是希望能够把自己的节奏稳定下来。因为我想要的，实在太多太多了……

距离第一天正式脱离学校踏入工作，已经四年了。我的感觉是更加久。我对工作、对世界的看法也变了很多。当然并不完全是工作造成的。人并不是在明处学习，更多的是靠自己学习。工作小结一般是领导要求写的。那么这篇日志我想要为自己写一写我最近一年对工作的小结。

我本来的态度是，工作上面的事情，是和同事、上级、客户等达成的约定，只要honor这个约定足矣。9个月前的跳槽，改变了很多我对工作的看法。Honor约定，只是一个基础。在我现在的公司，要做到这些基础竟然还是很难的，然而却还要求一个人有更多。

一个人在这个世界上，就是一只萝卜，除了自己的坑之外，能看到的事物很少。因此，虽然我之前的工作中，我非常重视的一些原则，在这份工作里被打破了很多，但是我仍然不后悔能够看到这么多新的事情。下面就具体讲一讲吧：

1）像DX那样视质量为第一，这样的态度是不是偏颇？我觉得，如果真的要建成一个好的东西的话，质量第一，反复review需求、设计和代码，是非常重要的。但是如果商业上需要不明确，那么开发就需要更加灵活。现在想来，DX商谈项目的原则，造成请他的team来开发是一件比较昂贵的事情。

2）我所处的部门，实际上是个很有利的位置。如果我有能力，我可以学习到各个部门的工作。近几年我都一直有这个愿望，它也隐隐一直在我心里，那就是去理解和我非常不一样的人。我也想知道这个世界是如何运作的。当初让我决定加入现在的公司，就是因为看到了Gary的职业化的风度。理解这个世界，理解各种人，想办法和他们合作。这种态度，不是向世界妥协的态度。我发现包容得越多，一个人的intergrity越强。

3）又能把握细节，又能high level对话，这是一种很强的能力。现在最困扰我的一点，是我似乎需要在上下之间做一个选择。我哪边都不舍得放。

对于我服务的目的，说到底当然是商业。我对商业的态度，已经不是觉得它是个necessary evil了。越看越觉得这个世界上，商业的力量太强了。

我一直都有原地踏步恐惧症。那么和在DX的时期相比，我到底有多大长进呢？我自己看来，已经觉得好恍惚。我很高兴DX时期我打下了比较扎实的基础，现在移植别的环境后，使用数据库方面，还有和开发的交流方面，都比较成功。不过我很害怕这方面我一直在吃老本，以后会老化。

一个进步是，我比原先对数据更加敏感了，因此也比以前更容易查出数据的问题。有时候我很奇怪为什么那些脑筋灵活、对系统更熟悉、逻辑思维比我强的开发同学会没有发现一些问题。后来我想，这是因为如今我站在了更高一些的角度。

现在的工作中，我还能学到、还能得到的，主要是商业思维方面了。对于这一点，我好像不是很有热情。另一方面，我也可以学习如何贯彻商业思维，略微插手一些/学习一些项目规划方面的事情。我想，类似BA的工作，在别的公司也会有需要的。也许我的定位可以是，既有技术sense，又有商业sense的项目管理者。