第一章：入职

有年长的人说过，“人一辈子，赚钱的机会就那么几年，大多时候都是收支相当而已。” 对于我一个普通的程序来说，除了那一两个对自己影响很大的项目之外，大部分时间都开发着普通的项目。由完美世界公司出品的 88 邮箱，对于我来说就是那一两个具有影响的项目。

我是一名前端开发工程师，虽然在科技公司沉浮了那么长时间，然而直到遇到 88 邮箱的时候，我才得到真正的成长。如何正确的架构前端项目，一个成熟的 web 项目的架构样子，一个项目从 0 到 1 如何成长起来。这些是我所领悟的，也是我向分享给大家的。

2019 年的 9 月份，我作为 88 邮箱团队的第四个人加入了 88 邮箱的团队，前三个人分别是：项目负责人、HR、前端负责人。四个人在完美世界的 17 层的一个小隔间里面开启了 88 邮箱项目的开发工作。当时我的朋友们很是不理解，我为什么从一个独角兽的 AI 公司到来开发一个完全过时的邮箱业务。我也不是很理解，自己为什么从一个满是优秀同事团队跳到一个连开发机都是台式机的团队。在这些质疑和困惑中，我相信自己每走过的一步都是算数的，每一次经历都是成长的。两年之后，这些努力也确实不负我，我也确实成长了。

邮箱服务虽然是上两个时代的产品，但是它却也是一个复杂的互联网产品。想要开发好这个产品也是需要投入很大了资源、时间的；如果没有相关产品开发经验的人贸然开发，产品开发周期可能很长，也会趟无数的安全性的问题。因此，我们在负责人英明的决策下，采用了前端交互自己开发，后端服务采买国内知名的 XMail。后来的开发过程中，虽然多次 Diss XMail 公司市值太低了，不过不得佩服他们在软件开发功力，确实有着胜过 90% 的开发团队。

第二章：搭建团队

每一个互联网产品，都是需要一个团队一起完成的，这个团队会包括：产品、前端开发、后端开发、设计师、IOS 开发、安卓开发、运维工程师、测试人员、运营人员。当我们看到这个团队的角色的时候，我想我已经大概猜测了这个团队的未来。这样的人员配置，也就是完美世界这样有实力的大公司才能支撑的住。因此背靠大树好乘凉，既然集团给支持，我们也就按照这样的路线去做就好了。

要不说要钱好办事，我入职后没有多少时间，设计负责人、产品负责人、 后端开发负责人、安卓开发负责人、IOS 开发负责人、运营负责人、测试负责人就陆陆续续的就位了。 负责人到了之后，各个岗位的小弟们也就陆陆续续进来了。这次团队搭建的过程中，我也是真正的认识到什么是兵熊熊一个， 将熊熊一窝的概念。负责人能力强，招进来的人能力就强；负责人能力弱的，招进来的人能力就弱一些。因此，选择一个有能力的负责人真的重要万分。而一旦能力弱的负责人进来之后，这将在气势上、架构上严重的影响着团队的发展。这也是我们现在团队两三个月才能录取一个同事的重要原因。

第三章：开发基础

我们的前端框架的主要选型是：vue+typescript+jsx+less 。其中邮件编辑器，我们选择了 Prosemirror。由于之前的技术栈积累的比较薄弱，这样的前端架构让我面临着不小的压力。

首当其冲的就是 typescirpt。那时我对 TS 的了解还仅限于 any 到底。而周围月薪 50K 的朋友还在朋友圈里吐槽 TS 类型校验的不方便性。

其二，是我们是基于 XMail 的基础上坐的开发。没有后端的开发人员，只有一份文档，让我们自己来悟。邮箱有什么功能，参数应该怎么传，传什么参数会有什么效果，都是需要我前端开发人员一点一滴的去发现。刚开始时，我们还吐槽着 XMail 的文档的薄弱，接口调用的方式不传统，参数描述不明确。不过后来当我们自己的后端工程师入职之后，我们瞬间领悟到了 XMail 文档积累的功底之深。

其三，前端富文本编辑器的选用。邮箱最为主要的功能之一就是写信功能。Email 一个历史悠久的互联网服务，它的出现比 HTML 还要早。因此，Email 正文的格式会有两种格式，一种是 plain/text,一种是富文本。纯文本写信使用 textarea 就可以了，可是富文本的话，我们需要一个富务本编辑器。富文本编辑器基础有很多，包括第一代的 UEditor、wangEditor、summernote；专业版的：CKEditor、TinyMCE；第二代的：Quill、Prosemirror、Slate。由于写信的开发交到了我的手里，我就本着不作不死的精神毅然决然的选择了 Prosemirror 这个编辑器。当时组长好心的提醒我，不如直接选择 UEditor 这样的不需要二次开发的成熟产品，编辑器架构虽然过时，不过成熟好用。好在我力排众议（我自己抗雷），毅然坚持的 Prosemirror。不过随着产品设计的复杂性的升高，我发现我的选择是对的。后来，我在编辑器里面轻松的按照官方教程支持了：更换签名、mention、表格 等负责的功能。以至于如果有一天，产品希望实现协同写邮件这个功能，我们也是可以支持的。

第四章：产品定位

由于业务负责人是一个有经验的互联网老人，有着一套自己的方法论。由于我没有成功过，所以我觉的这个方法论还是非常不错的。从 0 到 1 推出一个产品的方法论就是：

1. 品牌定位。首先我们需要定位产品的品牌调性。调性定位好了，我们就有前进的方向；方向定位好了，剩下的我们只需要按照导航向前进就可以了。我们可以看看有哪些成功的品牌调性，如：“钻石恒久远，一颗永流传”、“今年过节不送礼，送礼只送脑白金”、“让天下没有难做的生意” 等等。于是，我们在运营负责人，产品负责人、设计负责人的一众讨论下，我们确定“88 邮箱让沟通更完美、更正式”这样偏向商务型的定位。然而就是这个定位，让我们看到了 88 邮箱里会有着团队的功能（尽管我并不想看到这个功能）。

当我们定位到为商务的时候，我们团队中有人拿着钉钉和飞书出来举例。依稀记得有人反复的说着钉钉打开的方便性，然而我作为一个邮箱的开发着来说，对这个功能没有丝毫的感觉。在向大老板汇报这个品牌定位的时候，我作死的问了一个问题，就是：“飞书在北京有着 500 人团队，我们选择和他们在这个赛道上硬碰硬，突破不了怎么办？”。这时，有人说：“如果咱们赛道选错了， 我们一年后重新选择赛道就好。” 结果一年后，我们再也没有重新选择方向的机会。

1. 差异化分析。

由于我们的定位的是商务，又由于我们希望服务中小型团队，于是我们产品的差异化出来了，那就是团队模块。于是，我认为我们在还没有完全弄明白邮箱是什么时候，我们的在里面植入了差异化的功能：团队功能。我不得不承认，这个功能确实给我们的带来的一定的差异化体现。不过外行人看热闹，内行人看门道。我怎么看这个团队模块，没有任何的方法论在里面，只是一些简单而 CRUD 的功能的堆叠。

在我们的后来看飞书的介绍的时候，他们提到了信息流改成数据流。在后来我使用一段时间之后，发现这应该才是真正的差异化的体现。

在我看来，我们解决问题的时候，有一些方法论会比没有方法论要更好的解决问题。比如，我自己经常使用的方法论是：是什么，为什么，怎么办。这个方法论我相信很多人也在使用，不同人使用这个方法论达到的效果也是不一样的。因此是否会有，尽信方法论，不如没有方法论呢？我也没有成功过，也就只能在这里画一个大大的问号了。

第五章：研发日历

在 2020 年 8 月份左右，团队决定开发邮箱的日历功能。然而，日历和邮箱其实相当的两大模块。日历显示不难，日历中创建日程、发送日程则是有着大量的逻辑。在拿到产品文档之后，我研究了 iCalendar RFC、扒了飞书和谷歌的日历功能。每在飞书上确认一个交互，就跑去和交互设计师去确认一个交互的实现。在这样的工作方式下，一个交互设计师、一个前端、一个后端历史两个月完成了 88 日历的开发。88 日历功能不做评价，不过我想处理表面的使用之外，应该不会再又一个人对其实现的逻辑清楚了。

第六章：裁员与离职

脉脉上的消息总是又快又准。在 2021 年春节之后，同事间就开始讨论裁员的问题了。才讨论没有多长是时间，公司就在 4 月 1 日宣布这个决定。工作多年，我还是第一次面临团队裁员，虽然知道无论怎样裁我的概率很小，还是让我让我异样的工作状态。

4 月 1 日宣布裁员的当天，我的前端组长就被通知被裁了。这让我很惊讶。因为无论从邮箱的运维、邮箱主接口、前端架构来说都是他最为熟悉。他竟然被裁了！既然组长被裁了，我们也选择拿 N+1 走人吧。我当时向 HRBP 表达了这样的想法，不过集团后来发现了异样的端倪，通通否决了我们主动请裁的机会。既然不能被裁，我也没能替代离职的组长职位，也只有离职来黯然收场了。

最后，我非常感谢完美世界提供的工作机会，也非常感恩和同事们共同奋斗的时日。