穷则变，变则通

一群古惑仔，一队民兵，一支军队，一个超级英雄团队。

组织的演变是管理模式的不断升级，如果管理跟不上组织进步的速度，那么团队就容易乱。

一个人走的快，一群人走的远。

怎么让一群人向着一个目标远行呢？我觉得需要靠义气，利益，制度和梦想。

人少的时候，喝一顿酒，吃一顿饭，撸起袖子就干起来了。

慢慢的人多了，饭局难凑了，那么就需要利益的勾引，要谈上升，要谈工资。

接着人数再次上升，厉害的新人进来，熟悉的老人离开，开始有了熟人，陌生人，大家开始有了比较，干了这么多年，为什么他比我好，我比他差，这时，就需要制度，需要公平。

最后当人不在为了工作而工作时，就是实现自我价值的时候，这个境界我还不懂，就不多说。

曾经，我经常为了实现一个业务，发布一个功能，加班到很晚很晚，可当时一点都不觉得加班很苦，当时就是想着要实现讨论好的内容，不能有bug，要对得起“朋友的专属晚班车”，要对得起领导的一次次请客吃饭。这是我的系统，我要让他更友好。

后来，来了新人，不能一个人干了，开始考虑怎么分配任务，怎么拆解任务，没有需求，想需求，哪里不好，改哪里。我就是跑在前面的卒子，带领着我的小兵跑，可跑着跑着，发现小兵不乐意了，总是做业务，总是做需求，总是在重复劳动，今天没有我的发布，我还需要留守么？今天怎么又是改这些东西，有没有有意思的任务？此时才猛然醒悟，人心是独立的，带人不光要考虑做事，还需要让人有进步，有价值，有上升。我在努力的时候，得到了领导的认可，那么我的兵呢，他得到自身的认可了么？得到我的认可了么，得到公司的认可了么？认可和利益是绑定的，努力工作实际就是为了上升，为了利益。

我很感谢我的领导，他对我的认同让我不知不觉就得到了自我进步和公司认可。

我也感谢我的组员，他的诉求让我理解了作为一个组长，最重要的第二个特质。组长要带人做事，更要带人上升。

做人做事一定要有追求，只有追求，才能带动自身的进步，如果只做自己能做的事情，并且甘于做自己能做的事，那么最后就会变得麻木，得过且过，然后工作没法超出预期，自然而然就没法有优秀的表现，没有优秀的成果自然得不到公司的认可，接着就会开始自我否定，反正再怎么做，都是做不好，那么何必想那么多呢？当一个执行者吧，“他”说怎么做就怎么做。最后离开公司。

可是追求，也要讲方法，错误的追求会让事情变得很糟糕。

由于很多老的系统，都是我设计的，业务上的变更，我都是想着，基于老系统做优化，用最小的代价，做最满足业务需要的系统。我拒绝产品的思路，拒绝屠宰式的系统重构，我天天跟产品吵架。

一个思维发散的产品，天天跟我说，我们不能照搬网页那一套，做app要有app的思维，不能复制一个东西出来，要做大做强，超过支付宝。

我就纳闷了，现app定位还不清楚，就开始想着怎么赶超支付宝，我们能不能先把地基打了？先把网页有的功能移到app，然后根据业务发展，门店反馈，寻找app的定位，有准确的定位，才能做符合用户的产品吧，轮子没造好，跑那么快，会翻车的。我们是先驱者，是没有借鉴的啊？我每次开会，都很慌，这个家伙想的太快，太远，太高了，不敢做。

可能有人觉得这个时期，app一定做的很烂吧？其实不是，这一年里，app做的还是极其符合业务预期的。产品想的太快，但是我想的太短，我和他抵平了。

让我认识到我想的太短视，是跟另一个产品对比出来的。

由于团队的扩建，新来了一个产品。这是一个向上管理的产品经理。他能准确的把握住领导的意思，抓住领导的思路。他每次都拿这个需求是领导定的来压我，逼我妥帖，逼我插紧急任务。我极其讨厌她。他确实能够把握住领导的问题，但是他的设计没有条理，没有逻辑，都是基于业务而业务，基于领导的解决方案而解决方案，每次问题，按照领导的这个做法做，那么以前这个业务怎么办？他就说你自己想办法，被我逼急了，他就说那就加个特殊判断，先走通再说。能不能基于整条业务线，我们讨论一个双赢的方案？领导说的就是对的么？我需要的是一个逻辑思维，不是一句“领导定的”。这段时间配合不好，系统也做的不如人意。

后来调来一个新人，这个新人工作年限比较久，经验是有的，但是最重要的是他很“聪明”。由于他是新人，不理解系统的老逻辑，每次产品经理拿着领导的“需求”，他们商量的都很和睦，没有老系统的包袱，先按照领导的要求做，出了问题，再改就是。他们两可以说是串通一气，完美的互补，为了完成董需，想方设法。这个阶段，他们俩深深的得到了领导的认同。他们两做的系统模块对业务的支持和发展也是真的有长足的进步。

而这时的我却陷入在老系统逻辑里，为了兼容老逻辑，绞尽脑汁，精疲力竭。

业务的发展是极其迅速的，公司不会等着谁谁进步，该跑的还得跑。如果跟不上公司的进步速度，那么真的还不如换个位置。

业务和人员到这个阶段后，向上管理人的弊端慢慢显现，我的疲于奔命对系统也是心有余而力不足。

于是公司空降了一个新领导。这个新领导是一个大厂出身，方法论是真的多。他来的第一件事就是调整组织架构，在这个契机里，我被安排成了“技术售后服务”。

我本以为，我不负责系统开发工作，系统会乱，实际上，并没有。

反而因为我的解放，业务和技术有了一个缓冲，我专职处理紧急的系统问题，在某种意义上帮助研发/业务抽出了精力，他们可以更大胆的去解决更多的运营规划问题。

这段时间，系统做了很多有意义的升级工作，几个重要的项目都在app落地了，app的定位也越来越明确。

回想起来，我对老逻辑的熟悉，限制了系统的创新，如果我没有做技术售后，而是还在技术组长的位子上考虑兼容系统老逻辑，我真的就成了阻碍系统发展的拦路石了。我进步的速度没有公司的速度块，换个位置真的是更合适。

慢慢的，又过了一年，不知道从何时起，大家心里有了一个担心，这个业务我不熟，我不知道怎么改？能不能问下产品。

产品说，这个业务有点复杂，有没有人能给我讲讲，我再考虑下怎么改。业务方你能告诉我需要怎么样么，我们按照需求去改。

业务说，我的需求怎么这么难排，我提需求的，产品能不能想全面一点，总是有漏，这种设计缺陷就是bug，我不想走排期，赶紧给我上，当bug修掉。

门店客服说，问题第一次遇到不会，讲过之后会了，后面没遇到 又忘了，业务问题就是阶段性的。

四个角色，四种苦恼，实际上，就是一个问题，现在系统特殊逻辑太多了，没人记得全，没人说的清，没人hold住。

以前大家都是务实主义，以最小的改动最大限量的支持业务，这造成了大量的基于现有业务改造，大量的特殊逻辑。现在体量大了，人多了，问题就来了。

我们现在就像印度超载的火车，有站人的地方，就可以先上车，然后车子说停就停，说晚点就晚点，并且还找不到停车的原因，找不到晚点的原因。

该断得断，以前是务实，现在需要务虚了，我们需要建立设计思维，定位标准和规范，把写到代码的死逻辑升华出来，让架构清晰，让代码简单，不能再让写死的逻辑，让因为业务而业务的解决方案多下去了。短时间的快，长时间是快么？

如果某个会缺少谁，就定不了方案，如果某个需求只有那些人懂，那么人多了怎么培训，新来的人怎么融入到集体，体量怎么更大。

需求不能只抓在少数人手里。如果只有少数人表现优秀，那么其他人怎么办。

很多人都想把工作做好，做到让公司认可，让自己认可，可现实就是这么残酷，制度，体制的问题，不是一个人能搞定的，多次的心有余而力不足，最后要么随波追流，要么离开公司。

怎么让需求不是只抓在少数人手里？

为什么一个新需求系统要从头改到尾？

为什么一个需求评估影响范围那么难？只有某个人能做？

为什么稍微修改个新功能都要一群人开会讨论，稍微少了谁，没有通知到位，系统就走不通？

为什么测试一个流程，要研发，测试从提测沟通到上线发布前？

稍微复杂的业务线，测试环境只能人为伪造数据去测试？没有办法像正常的业务一样操作出数据？如果哪个部门的测试忙，测试流程就被卡住，测不过了？？？为什么测试这么痛苦。这么多无法复现。

还有协作，一个需求要三个，四个，产品线协作，大家怎么高效率的干活？本位主义是不可避免的，都希望自己少改，自己的业务稳定，所以推进问题就是那么慢，那么难。

在总结下，我们的改进方面。我们要减负，要建高铁，要做基建。

我们需要一双眼睛，看到系统的问题，服务器cpu监控，访问量监控，日志监控等等，这些已经在做了，并卓有成效。

我们需要了解我们的身体，回归冒烟测试，自动化测试，压测等等，系统，这个还在尝试中，不够成熟。

我们需要知道我们的历史，温故而知新，这个我们有wiki，但是大家写文档，做设计的意识还在培养，很稚嫩。

我们需要武器，这个基本是石器时代，没有开始。菜鸟有彩虹桥协调测试，拉卡拉有准生产环境可以真实还原线上场景（不像我们ut这种残次品，啥都不敢干）携程/阿里，有技术社区，公众号，总结工作中遇到的问题，分享最前沿的技术。

技术服务业务，技术需要业务的滋养才能发展的更好，希望我们能穷则变，变则通。

公司五年随想-袁聪