本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh)

本文作者: 苏洋

创建时间: 2018年05月23日
统计字数: 2243字
阅读时间: 5分钟阅读
本文链接: https://soulteary.com/2018/05/23/professional-thinking.html

-----


# 职业上的思考

从`FD Con2018`会议回来之后，有的事情还是在脑子里转。

> 天翔和之昊讨论1秒内首屏性能、播放器组件等问题时的状态。 
> 之昊期望的“我的产品给我的孩子看到的内容、受到的影响”，以及自豪的说出：“当做事业去做”的状态。
> 看到议题中有人也去尝试了自动化测试的感慨。
> 和英杰大叔午饭，新UED团队展现出的勃勃生机和些许羞涩。
> 勾股提到的一些事情，关于技术信仰、技术产品坚持、机会的把握。
> 米棕提到的团队的栈、做的工程产品，还有团队的一些问题。
> 凌霄人生角色的转变，恭喜。

看起来风马牛不相及，其实无非是两个关键点和几个关键词：

1. 职业规划：业务领域、技术方向、技术深度、团队建设、文化建设
2. 生活规划：婚姻、家庭

## 职业规划

- 未来能给自己带来归属感、成就感的产品和领域。
- 技术相关性更大的产品：
    - 长期看会随着技术变化而产生产品形态的改变。
    - 存在相对复杂的技术挑战。
    - 可以做0-1，建设团队和技术设施，但是不能止步于0-1、1-60，要能够去做60-100。
- 有技术品牌建设、技术文化营造的环境。


下面有一些看法。

### 团队职能和氛围

任何一家公司招募技术人员都是要用来解决实际问题的，而这些问题按时间维度去划分，一般可以分为两类：现有问题和未来问题。

现有问题多数属于业务实践范畴，实践多于规划，少数属于工程架构范畴，规划重于实践，长远的问题多数属于工程架构范畴，少数属于业务实践范畴。

团队一般分为生产业务团队和技术架构团队，有的公司会把两者合并在一起，有的公司会在业务团队中添加一个架构小组，也有在两个状态中来回转变的团队，还有公司的架构团队会自己找业务，做创新。一般来说业务团队的数量会远远大于技术架构团队。

两种团队的存在都是有必要的，在不同的时期和状态下价值是大不相同：业务团队在产品前中期价值巨大，随着各种平台的接入、产品形态的稳定，业务团队的价值是逐渐减少的；架构团队情况相对复杂一些，不同产品情况差异较大，早期团队基本是没有这个规划的，可能会出现在项目前期（有储备的公司），一般只有到中后期原本技术设施面临瓶颈、团队需要进行标准化建设提升效率和凝聚力的时候才会出现。

两个团队KPI天然不同，所以经常会看到业务团队极其在意时间，架构团队极其在意标准，如果团队天然隔离，架构团队的改进措施落地难推动慢，如果团队耦合在一起，技术不足够被重视的情况下，架构方案势必畸形，特异化严重，导致后续升级维护成本偏高。

新技术的出现，多半伴随着激进，如果团队负责人倾向偏保守，技术出现创新可能性非常小，产生畸形的轮子的可能性偏大，不利于团队整体技术氛围的建设和技术积累。

如果做技术管理，那么在所属环境下，是否能建设一只尖兵队伍，不断挑战业务，挑战自己。

如果做相对单纯的技术架构，大环境是否有技术工程的背景或者基因。

### 产品迭代过程的态度

初期最小成本试错，很可能一个MVP Demo就上线了。

但是随后的迭代可能会说明许多问题，要不要标准化生产交付，如果没有标准化流程，是否要投入建设，包括：规范交互、统一视觉、衡量技术性能等。

如果一直是以打补丁的方式进行迭代，到后面很可能是补丁裤而不是一件精致的产品。

团队里要允许“工作就只是工作”的论调存在，但是必须存在“这个设计的用户体验太差了，必须改进”的声音、最好也能存在“要考虑后续开发维护成本”的切实行为。

如果有打造优秀产品的倾向，优先考虑充满活力但是不失远见的团队氛围。

这里有一个无法考量的变量：产品负责人，很难找到业务背景契合，技术专业，对事情上心跟进的人。


### 技术态度和技术深度

> 多数场景下二八原则是生效的，对于二八原则不生效的情况下，很多情况下，我们的选择是绕开它。

- 使用“low方案”实施：
    - 没有low的方案，只有是否合适
    - 妥协方案带来的后续影响是什么，能否通过少量工作补救来挽回
    - 失去了一次探索尝试的机会，和技术深度上的延伸
- 砍需求：
    - 并非所有需求都不合理，并非所有需求都无法实现，reject需求的同时，可能失去了一次新的业务上的尝试、或者妥协了现有产品在用户体验不足上的问题

除了啃文档、啃源码外，提升技术深度最好的方式就是用合适的技术方案改造现有的产品、流程，提供给好的体验和输出结果。

倾向绕过技术问题的团队，多数情况下技术储备只是能原地踏步，妄谈改造体验。    

### 团队建设和文化建设

每个人都是独立的个体，有鲜明的特点，在团队成员为团队创造价值的同时，团队是否能反馈给成员他们自己追寻的东西呢：

- 技术成长的空间
- 职业经历和职业提升空间
- 薪酬待遇

除了最后一点是有可能短时间提供给成员的，其他两点都需要漫长的时间来建设和证明：

- 更好的技术可以带来产品上更高的收益
    - 重视技术氛围，设置技术导师、技术培训和分享...
    - 新业务尝试新技术，复盘是否有价值收益
- 人是公司最重要的资源
    - 当前这个岗位领域是对公司很重要，建设职级通道
    - 当前这个岗位对公司产品发展很重要，进行持续招聘和培养

而这个建设不是一两个人就能完成的，需要技术团队整体一心，至少管理们将这个事情重视起来。不需听别人如何说的，去感受是否有整体变化。

关于文化建设，小到活动、行政关怀、文化推广、对外形象营造，大到理念推行，说起来可以聊的有很多，但是不如闲聊时分问问同时，你觉得公司最大的特点是什么、公司的文化是什么。


## 生活规划

- 今年年内，找一个合适的时间点，和家长们再次沟通婚事。
- 带着她好好的旅游放松一下，感觉这几年两个人在一直奔跑，不得停歇，很是疲惫。

---


先写到这里。

--EOF