一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，点击查看活动详情。
画外音：
一直都在收拾了别人的烂摊子，总结一下怎么做一个"人见人夸"的功能设计。
这个系列主要写给产品看，最佳实践不敢说，失败案例我有大把可以分享和吐槽的。
研发请随意，有不妥的地方欢迎指正。
一、别造轮子
是的，你没看错，能不做，就不做。
人生在世，能做好的事情实在太少了，能撸出来一两个80分就不错了。
很多人总想着功能封装一下，造个轮子，感觉非常强大，写个PPT，刷个绩效（产品或是研发）。
然后就天天推着下游各种业务方接入、试用，年终拿到手，升职加薪跳槽。
实则一地鸡毛，底下的人敢怒不敢言。真心奉劝一句，轮子造出来恶心自己就够了。
当然也得感谢这帮人，走了之后换一拨人重构，又创造了一遍就业。
尤其这几年中台风很大，各厂的团队抢占了一堆山头。
夸张到什么程度呢，只要你想，每个API都能编出个中台来。
简单做个H5活动，得找十几个中台联调。
这就是传说中的“最佳实践”吧。
如果你跑得不够快，烂摊子最后你也要收拾的或者被恶心到的。
二、先盘组织
假设业务发展中的确需要一个轮子。
那要记得先盘组织，康威定律“系统复杂度随着组织膨胀而增加”。
想想甩给谁做，还是能不做就不做。
有些时候吧，总觉得先自己撸出来支撑业务再说，洗脑大家“不设边界”，自然会出现各种割裂。
一件事情，在组织内部大概率是能找到对应团队的职责进行承接的。
与其撸完被人抄袭复制替代，或者 逼你交接然后被边缘化，
再或者 合并团队职能，不如一开始就别投入。(如果你准备刷简历跑路，请忽略）
对方没人力，可以让业务方出HC出预算。排期慢，可以让业务方上升，甚至于 采购。
能花钱的问题，真的都是小问题。团队的人力是有限的，业务的需求是无限。
真的有那么多富裕人力，把他做好并长期维护吗？
这是产品与研发都该考虑的问题。
如果需要成立新团队，再考虑是不是安排自己人上手搞。
三、找对靠山
如果实在很不幸，这活需要自己撸。又或者，实在憋不住想造个轮子。先找对你的业务当靠山。
利用业务给自己制造“护城河”，拉高对手的入侵与复制的成本。
马云有句话，大意是：如果一件事要做10年才能成，9成9的人都会放弃。
别说10年，2年或者3年都没几个人愿意跟。
所以，先思考清楚 能不能与业务进行强绑定。比如UI组件库这玩意，就真的没啥必要了。
而不是在技术上卷，人家rest你非要graphql，不光恶心别人，还恶心自己。
不过，选对业务也是一门学问：
这个赛道火不火，资本还在投吗，发展到什么阶段了，利润率如何，能挣钱吗？
上头对它定位是进攻还是防守？进攻是在 财报上刷脸，对外公关 还是用来 凑数据的？
政治觉悟真的很重要，最好的选择当然是 在 一个有大市场的新业务里。比如 国内转国外。
主要特征就是 起码 成立一个 新的一级大部门吧。如果评估后觉得靠谱，那就赶紧润。
如果不考虑润的问题，就在当前现有业务上发展：
最好的建议就是：
在这个业务的营收或者流量等 主营功能上大搞特搞，并且找一个 业务的老产品 或者 老运营 带 。
架构设计/实现方案不一定要听他的，但起码人家的需求点弄出来的有人用。考虑 使用 或 拓展 强些。
至少不会像某些大厂找一些985的应届产品做一堆扯淡功能，
比如设计个九宫格抽奖：
要跑马灯动效，9个奖品让人传高亮与默认一共18张icon切图。
先不说 运营和美工的工作量很大，会被人骂“哪个傻逼做的”。
技术层面，一张切图就算50KB，18张都得0.87MB了。首屏速度和接口耗时都不用管了？
哦，如果你刚好是个产品，且负责这种 工程业务。劝你多了解业务，全链路思考一下。
真心不懂，就不耻下问。找同事问问，基层资历最老的运营是哪几个，挨个聊一圈。
尤其男的，比较好面子，大多数 “好为人师” 哈哈~
至于这轮子怎么思考，怎么设计，欢迎收看本系列的下一篇内容：造轮子的基础常识。
Good Luck。
