铁三角搭档
PL
<div>PL-Project Leader 项目Leader：承担项目交付职责，负责将产品经理的需求分析后转换为各个模块的子任务，确保需求按承诺交付。主要输出件是线上版本。</div>
TL
<div>TL-Technical Leader 技术Leader：承担模块代码执行，确保需求高质量完成，包括代码质量、可靠性、可维护性等。对线上版本运行质量负责，输出件是系统可靠性设计、物理部署设计。</div>
PM
<div>PM-Project Manager 产品经理：对用户负责，对体验负责，对业务成功负责。输出主要是原型图,协调UI/UE输出高保真页面。</div>
原则
快速响应，敏捷交付
一个项目组由开发+测试+产品组成，项目组可以完整交付。子团队敏捷交付。
内部资源市场化，人员可以流动
重点产品重兵投入
子团队根据产品线市场业绩考核
结果为导向，成功的产品才会有成功的团队
决策链短，避免层层汇报，尽量扁平
技术架构协同
技术栈经过架构组审核，避免个人喜好带来的不必要的浪费
很多问号
愿景如何实现
我们都知道未来是什么样子的
多久可以实现？
每个阶段的milestone
口号如何落地
互联网思维？
工匠精神？
建议
互联网思维容易产生歧义，一万个人有一万零一个解释
要有自己的解读，通俗易懂，贴近客户
打土豪、分田地
要想富，先修路，少生孩子多种树
做生意，用有赞
……
工匠精神和有赞对比就行了
同样的页面，是不是响应比有赞快
同样的功能，是不是上线比有赞快
同样的功能，是不是bug比有赞少
同样的产品，是不是用户数比有赞多
……
业界通用的组织架构
按技能划分团队
移动团队
前端团队
平台中心
……
优劣
劣势
部门增加导致沟通管理成本过高
客户需求无法及时响应答复，涉及到多个部门的沟通协调
千米组织架构
优势
需求响应及时，一个团队搞定，不需要多部门协调
一体化团队，可以按feature交付版本
劣势
对员工素质要求高，技术栈全面（前后端通吃）
对依赖中心模块的人员素质要求高，需要高P工程师把关
角色&业态
角色操作最终还是映射到各个子产品线和子模块的
产品相对于人的思维可以固化，一个产品团队也可以聚焦，不会被客户跳跃的思维左右
