2014年工作总结

[hoperyy]

技术人员如何实现价值最大化

技术人员的价值，可以从影响力的角度去分析。

只影响到个人

• 提高开发效率
• 高质量代码等

影响本团队

• 提高开发效率的工具

影响其它团队

• 更多地将自身的技术和业务结合，提升业务效率、提高转化率等等

影响业界

• 如专利

工作中的好习惯

主观意识

• 能力模型

  • 第一级：无意识

    没有意识到自身的问题，更谈不上解决

  • 第二级：有意识，无行动（P5）

    能够意识到自身的问题，但稍微行动下或者没有行动去解决，浅尝辄止

  • 第三级：有意识，有行动（P6）

    能够意识到自身的问题，并且有有效的行动解决

  • 第四级：无意识，有行动

    可以快速无意识地发现并解决自身的问题

• 主动性

  • 主动承担工作，不能等待安排工作

• 责任心

  • 出错没什么，重要的是：如果是自己的责任，就敢于承担

• 执行力

  • 主管安排后，能快速拿到结果；如果是长期性的工作，及时沟通进度
  • 关键词
    • 立刻，马上
    • 不并行，做完一件事再做另一件

• 目标一致

  • 员工个人目标和主管对个人的期望目标保持一致。因此要经常沟通

• 要非常清楚主管对你的期望

  • 不满足期望：不合格
  • 刚刚满足期望：刚刚合格
  • 超出期望：优秀

• 让领导知道你在做什么

  不需要每天汇报，但关键进度要及时通知领导，主动通知

• 有投入，就要有产出

  • 工作：每做一个需求就要有产出
  • 学习：勤做笔记

• 思想要有一定的高度, 但是手底下做的事情必须是实实在在的

• 重视模仿，在合适的阶段模仿合适的人

• 有自己的开发节奏

• 求助

• 长策略、短执行

• 精一行，通十行

• 过程与结果

  • 过程
    • 回顾过程时沉淀出精华
    • 表现出良好的分析问题能力
    • 表现态度
    • 产生自己的影响力
    • 过程只是苦力的阶段
  • 结果
    • 快速拿到结果
    • 结果才能产生KPI

• 关于放弃

  • 不能遇到一点困难就放弃
  • 必须是在尝试各种方法都不行后，再放弃

• 遇到线上故障、投诉时怎么做

  • 不能慌乱，然后立刻认为是自己的错
  • 过滤、思考、分析

• 关于“拖”

  即拖延症，这个对于职业发展是致命的，职场中不能有拖延症。以下是要点：

  • 早上列举任务列表，今日事，今日毕
  • 避免并行处理事情，把一件事做完后，再做下一件事情。绝对避免一件事情没有做完又跳到另一件事情上去

• 自动化你的工作

  程序员的竞争力之一就是懒

方法论

• 收集 > 整理 > 思考 > 实践 > 分享

  • 收集
  • 整理
  • 思考
    • 写给自己看的总结文
  • 实践
    • 验证
    • 加深印象
  • 分享
    • 写给他人看的总结文

• 对于长线性质的学习

  • 要有学习计划，以及当前在整个学习计划中的位置
  • 不能多面化、细碎化

• 重视模仿，在合适的阶段模仿合适的人

• 目标导向

  • 目标要确定
  • 多种方案，最优解，是执行前的必要条件

• 多问几层“为什么”

• 晋升

  • 表达技巧

    • 分主、次，重点讲1件事情，其余做简单罗列或者附录，以备提问时再翻找出来讲述。

  • 晋升技巧

    • 把自己带入到晋升层级。
      • P6-P7，站在P6层级上述职，结论只会是优秀的P6。
    • 善于归纳总结
      • 提炼好价值点，用数据、截图来提亮工作成果，实现过程可以留待评委们提问时讲述
      • 给自己打好标签也很重要，宁愿让评委们来挑战自我认知，也不要羞羞答答被忽略
      • 避免：絮絮叨叨，试图还原工作过程中的所有细节，以期评委们能从中拾掇出价值点

定期要做的

• 给他人看的
  • 周报
    • 业务
    • 推进
    • 分享
    • 下一步计划
  • 项目周报
    • 项目背景
    • 项目计划
    • 项目进展
    • 风险点
• 给自己看的
  • 日记
    • 做了什么
    • 花了多长时间
  • 每周自身 review
    • 做事方式
    • 技术成长在计划中的位置
    • ……
  • 每月自身 review
  • 项目总结，参考“有效学习”
  • 每天的任务列表，必须无条件完成，不能拖
• 互相提醒

开发流程

• 意识

  • 尊重路程，遵守流程。如果不尊重、遵守流程，容易引起风险

• 介绍

  • 业务方提需求
  • 多方需求评审（前端、UED、后端……）
    • 了解需求。如果需求理解偏差，会造成错误的技术方案，最终浪费大量时间。
    • 从视觉、交互、业务等角度提出自己的见解
  • 等待UED出交互视觉稿
  • 根据视觉、交互稿评估工期，纳入自己的开发队列
    • 设定优先级，标准：重要性、紧急性
      • 既重要又紧急
      • 重要的
      • 紧急的
      • 不重要，不紧急的
  • 开发
    • 多花时间比较、制定方案，不要急于写代码
  • 上线前review：业务方、UED、后端等 review，修改
  • 预发布验证（预发布环境，非线上环境）
  • 制定线上出问题时的回滚方案
  • 上线
  • 线上观察（保证线上不出问题，即使出问题，也能及时回滚）