Skip to main content

前端开发负责人指南

定位

要求

  • 知识面广 (前端、后端、数据分析、产品、交互)
  • 基础扎实
  • 学习能力强
  • 服务意识
  • 产品思维
  • 心态良好
  • 善于总结
  • 沟通能力

职责

  • 营造存在感、归属感、成就感
  • 把控技术方向
  • 新人引导
  • 促进团队提升、培养团队
  • 与其他部门衔接和沟通
  • 创造希望 (eg: 画大饼、某种意义上的程序员精神鼓励师)

关键词

团队建设、技术选型、人员安排

  • 团队建设
    • 技术氛围
    • 人文氛围
  • 技术选型
    • 产品需求
    • 稳定性
    • 兼容性
    • 开发效率
    • 招人难易度
    • 留人难易度
    • 转型成本(时间成本、学习成本)
    • 舍弃用户成本(转化率:兼容性; 访问量:SEO)
  • 人员安排
    • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
    • 让普通的人加速提升 (技术栈:最成熟的技术)
    • 淘汰余下的人

常见问题分析

面试时经常遇到一些人的离职原因就是以下一些

1. 没有提升

什么是提升?

  • 更快解决问题 7
  • 更优解决问题 8
  • 解决以前不能解决的问题 9
  • 编程能力提升 (编码、设计、架构) 9
  • 掌握新技术、新语言、新工具 5
  • 工资提升 6
  • 知名度 7 注: 数值为 XX 认为的较为合理的权重值,满分 10,个人意见,仅供参考 如何提升? 缺一不可
  1. 时间
  2. 方向
  3. 坚持
  4. 实践 加分项
  • 聪明 (XX 注:可遇不可求)
  • 有老司机指点 (XX 注:可遇不可求)
  • 好奇心
  • 自我驱动力/主观能动性
  • 专注 注: 除去 聪明、 有老司机指点, 这两个是可遇不可求的; 其余都是可以后天培养的。 为什么没有提升? 工作只使用旧框架、旧技术 【应聘人经常提及】 基础薄弱,学新技术难,求带,抱大腿 光看不练 没有时间 前端要学的太多太杂,学了这个忘了那个 新框架一个又一个, 来不及学 负责人能做的
  • 保证产品稳定性,满足产品兼容性需求的情况下,尽量让团队使用最前沿的技术
  • 推动团队技术学习、分享氛围,必要时给予物质奖励
  • 为成员腾出一定自由时间
  • 让自己成为队员的大腿、答疑解惑
  • 完善技术文档
  • 写优秀的代码
  • 造轮子、改进项目基础设施
  • 挡需求、砍需求、改需求、加需求 负责人不能做的/很难做的/不应该做的
  • 不应该回答 what 的问题、 减少回答 how 的问题,而是更多回答 why 的问题
  • 不应该每天催着队员去学习、去分享,而是要激发队员的自我驱动力、主观能动性
  • 不应该安排超负荷任务,而是分配合理的任务总量
  • 不应该花费大量时间(80%)开发业务需求,而应该花一半时间(50%)思考和设计如何改进现有开发模式

2. 没有成就感

如何获得

  • 回报 >= 付出 (精神、物质)
  • 对产品的认可
  • 对技术栈的认可
  • 对自己付出的认可
  • 对他人付出的认可
  • 助人且助人的反馈是积极的
  • 个人发展、晋升 概况: 回报 >= 付出 (精神、物质)

3. 加班太多 没有时间 到家后太累了

首先明确一点,业务需求是永远做不完的 我们能做的,只是每周根据已有的开发资源,开发相对最重要最紧急的业务 另一方面,也要注意: 程序员自我提升 的重要度也是极高的 队员层面

  • 合理评估工期
  • 不断提升自己,不断提高效率
  • 量力而为,保重身体 负责人层面 【主要背锅人】
  • 合理审核工期
  • 合理安排任务 【重要】
  • 技术选型是否合理、是否高效
  • 新人的引导是否到位

4. 技术分享参与度不高

如何改善

  • 负责人牵头分享
  • 奖励机制
  • 避免布置过饱和任务量 应聘人的期望
  • 我比较期待能有一个经常相互讨论最新技术的环境
  • 技术氛围好点,可以互相交流的,然后加班不要太多,有意义的加班可以接受
  • 希望有挑战性和持续成长空间,同事之间比较容易沟通的,当然做的产品有趣就更好了
  • 希望有大牛带
  • ……

XX 实践

团队建设

技术氛围

  1. 技术分享考评制度(鼓励竞争 、 与培训机会、年终考核挂钩)
  2. 定期 code review (2 周 1 次) 优先级: 高
  3. 不定期 小分享 (不限次~2 周 1 次) 优先级: 高
  4. 定期 大分享 (2 个月 1 次)
  5. 鼓励参与翻译英文技术文章
  6. 整理、维护、更新前端知识库 wiki (涵盖: 代码规范、工具教程、开发流程、组件 Demo、语言教程等)
  7. 前端每周一题 , 以经典案例题形式传授实际价值较高的知识点
  8. LeetCode 刷题活动 (算法题为主)
  9. 每周周会只探讨各自遇到的难题 1~2 个,思考更优解
  10. 开源项目 【构思中】
  11. 新技术交流、研讨会 【构思中】
  12. 以上各种分享,负责人带头进行 考核制度 DKP v0.1 版本 考察两个维度: 分享贡献度、业绩贡献度; 每个月设置合格线,低于合格线进入考察期
  • 试行了 1 个月,实际效果一般,参与度不高,仅一人达成分享贡献度合格;
  • 不同产品线业绩难以量化衡量;
  • 较反感惩罚制度 v0.2 版本 仅考察 分享贡献度。不设合格线,分值仅作为奖励评定标准 团队氛围 (需加强)
  • 多关心队员真实诉求,阶段性一对一对话
  • 设定阶段性目标(例如:官网重构计划),达成后一同庆祝
  • 定期组织 TeamBuilding 技术选型 数据驱动 + 业务驱动 + 人才驱动
  • 产品需求
  • 稳定性
  • 兼容性
  • 性能
  • 开发效率
  • 技术价值 (对程序员自我提升产生的价值)
  • 招人难易度
  • 留人难易度
  • 转型成本(时间成本、学习成本)
  • 舍弃用户成本 (数据驱动)
    • 舍弃兼容性带来转化率下降的成本: IE8 用户
    • 舍弃 SEO 造成访问量下降的成本: SEO 流量

人员安排

  • 让优秀的人变得更优秀 (技术栈:最前沿的技术; 老带新)
  • 让普通的人加速提升 (技术栈:最成熟的技术)
  • 淘汰余下的人 技术选型规划 以 PC 官网前端重构计划为例 现状 jQuery + 类 require.js 加载机制 + less + gulp + C# , 传统电商网站 目标浏览器 不低于 5% 访问量的浏览器 目标流量来源 SEM + SEO + 市场活动推广 其中, SEO 目前平均占比约 15% 流量 业务痛点 设计风格不统一、特别大量重复性工作 (各种合作方系统定制化移植官网)、 前后端耦合程度大 人员痛点 技术栈落后、招人难、留人难 重构好处
  • 组件化设计: 提高代码复用性;有助于快速移植组件、促进合作方项目进度同步
  • 技术栈升级: 有利于招人以及留人
  • 前后端分离: 有利于提升开发效率 重构弊端
  • 时间成本: 大量
  • 兼容性成本: 只兼容 IE9+
  • 白屏时间: 比起传统服务器端渲染,会存在一定的白屏时间,而短期内不一定会使用 node.js + vue.js SSR 路线图
  1. 在后台管理系统中试点 Vue.js 框架,积累 Vue.js 经验 【DONE】
  2. 在完成 2~3 个后台管理产品后,渐进式(帮助中心页入手)改造官网前端 【View 层 Vue.js 框架 ; Action 层 c# .net】 【PLAN】
  3. 在确定舍弃 IE8 用户后,官网全站转型 Vue.js 框架
  4. 在确定舍弃 SEO 流量 改用 Vue-Router , .net 只提供容器
  5. Vue.js + Node.js 服务器端渲染有一定积累后,官网前后端完全分离

近期实践

时间分类内容 2017.4.8 讲座前端小组集体参加中第二届国前端开发者大会…… 公司报销 2017.4.14 大分享 XX: 自动埋点工具介绍(很 low……) ATM https://github.com/xunge0613/ATM2017.4.21小分享XX: 掘金翻译计划参与体会 + GitHub Review 功能 2017.4.23 技术研讨官网 PC 前端重构规划

任务安排

2 - 8 原则 如何做 数值仅供参考,具体情况具体分析 每周任务安排 4 天工作量 每天花 0.2 天 , 约 1.5 ~ 2 小时,自我提升 目的 为了提升队员开发效率 定期安排技术型任务

  • 督促技术提升
  • 考核方式 按需分配需求 一般业务需求无非考验以下两点
  • 业务熟悉度
  • 技术熟练度 理想情况下,对于业务不熟悉的队员,优先分配需要熟悉业务的需求;反之亦然