LEADERSHIP 领导力

Paul’s management experience. Unordered.
领导力经验，重要性无序:

1. Treat teammates the way I would like to be treated from my boss.
   我若要我的上司怎么待我，我也要怎么待我的队友，怜恤人的人有福了，因为他们比蒙怜恤。
2. Create Core Member group with 3/10- members involved, taking charge of quality management and program management together.
   创建核心团队，团队人数控制在三分之一项目人数左右，主要是以团队的方式负责产品质量管理和开发 Program 管理
3. Trust my team. “We are the best. All we need to resolve issues is just better management, coordinate, communication and training”.
   相信团队一定是最好的，有问题只是管理、沟通、培训与招聘机制的问题。
4. Project risk or hassle is all about management and leadership.
   项目出问题一定是领导和管理的问题
5. “Who is the best resource I can find to solve the issue?” Keep this in mind on every new task.
   遇到新问题时，首先想到的不是我可以如何解决，而应该是我可以找谁来解决
6. Tolerance on relationship, not job. Always try to do better on important task.
   关系上多多的包容，工作细节上却不要包容错误，而是应该努力的寻找更好的解决方案
7. To improve management skill is surely going to improve working performance.  
   提高领导力有助于提高效率，而领导力需要慢慢的学习和建立
8. What a leader should focus on, is drawing the blueprint and identifying the obstacles.
   重要的是画现蓝图，指明方向，指出障碍和问题
9. Encourage teammates with a clear and valuable goal and blueprint
   有清楚和高标准的目标与蓝图，可以更大程度的激励队友
10. Solving issue upon leadership impact other than job title.
    依靠影响力，而不是依靠职位来解决问题
11. 20131218 updated: Ask for every teammate keep a task list with task name/due date/checkpoint/note and send to lead, CC to manager if needful.
    要求所有队友保持一份任务列表，包括任务名称、截期、检查点和备注，发给lead，CC给manager（如果有必要的话）， 以下是参考模板：
    
    

    20140106

    Task name	Deadline	Check Point	Description	JIRA Ticket

    每周周一或者一个迭代需要对本周的任务进行排序、预估时间和预计完成的任务数。每个任务都应该有时长和截期

     

12. 20121218 updated: distribute tasks if possible. Trust teammates and only care about requirements, task projection (schedule) and training. 尽量将任务分出去，相信队友能做好，只关心需求、任务进度和给予必要的培训。
13. To create double developing group is to increase efficiency.
    建立双人工作小组，给小组指定组长，给小组指定双人开发任务。这样效率会更高，更好跟进。
14. Should implement Agile Development with all phases of product development.
    在项目的各个阶段，都要有敏捷开发的思维

    TO BE TRANSLATED.

     

15. 定期开展1对1沟通 – one one communication
    1. 维护一份文档，是与每个同事需要谈话、聆听和表达的文档，将所有赞扬、关心和问题都放到里面。在1对1沟通时使用。
    2. 文档中的赞扬或者询问或者问题，是要依据各样的贡献考核标准，个人情绪、感受和建议，团队的文化和目标来撰写

    3. 1.  Status

       2.  Challenge

       3.  Strong point

       4.  Week point

       5. interest

       6.  TODO list

16. 经常使用自己做的产品，这样可以及时发现问题，提出改善意见。不要一味地只是按照需求来开发。
    1. 每周都组织大家来玩玩自己的产品，每周玩1个小时
17. 有邮件进来时，应当立即暂停除开会外的工作，看看是否是优先级更高的任务。如果不是，则继续手头工作。
18. 不要扩散压力给团队的其他队员
19. 需要平衡应该做的和喜欢做的
20. 会议必须提前发Pre List和做Minutes， 并且让每个队员来参与做。
21. 关系，与队友、客户和上司相连是最重要的。依靠connection办事，而不是依靠职责。在请求帮助前，先触碰别人的心
22. 尊重队友，肯定并总结队友的优点和成绩，并制作成wiki
23. 不同的队友适合做不同的事，不要每个人都分配一样的任务；经常让他们选择自己喜欢做的
24. 成功的原则
25. 仆人式领导，牺牲式领导，看别人比自己强
26. 沟通原则
27. 以重要和紧急来衡量不同任务的优先级
28. 时间观念，及时响应（不是即时解决）客户需求，及时回复邮件。
29. 需要有可供跟进和衡量贡献的任务跟踪平台, 如trac
30. 不要把一些私下可以沟通的问题拿到会上说, 因为开会的成本是 time * N人
31. 应该完全清楚每个任务的进度, 不能估计进度的任务不是任务
    
32. 把不同的任务进行归类，绝大多数的任务可以归类
    
    
33. 让其他团队/个人参与进来前，先要跟他们讲明白办事的规则，给他们提供文档和遇到问题时的联系方式。
34. 向上级做报告时，主要是报告当前遇到的问题，剩余task的估计完成时长，本周解决了哪些问题，当前项目的总体进度
35. 为开会做Meeting minutes, 英文开会结束之后，要用中文把会议记录念一下，让大家在同一步伐上
36. 定期组织 Code 和Implementation review，让大家都参与，提高团队共享和合作意识
37. 如果有工作原则不能向团队有效推行，则可以在开会时拿出来讨论，然后让上级决定，最终成为团队共识。
38. 维护一个组织良好的wiki，是有必要的。所有的文档都要放到wiki上。
39. 如果说过的话不能实现，即便道歉了，个人可信性仍然会降低。所以说到做到，或者不说，或者少说。
40. 任务布置之后，要定期检查完成情况
41. 有邮件进来时，应当立即暂停除开会外的工作，看看是否是优先级更高的任务。如果不是，则继续手头工作。
42. 队友做得不好时，不是因为他们做得不好，是因为我没有培训和说服他们如何做
43. 应该注重培训：包括
    1. 项目状态
    2. 工作流程
    3. 绩效考核
    4. 团队目标和lead针对每个人的目标
    5. 代码结构和功能
44. 在项目的任何阶段发现潜在的缺陷、问题或者改进，就要随手记；再根据项目的状态来决定何时执行，当然，需要跟客户谈合适的解决方案和时间，不要放过任何一个问题。
45. 交给队友做的任务，要及时查看其结果是否是正确的，这点要保持不信任状态，目的是为了更好信任。
46. Leader 要做的，不是多写代码，而是要跟本团队沟通，激发他们最大的潜能；其次是跟其他团队和客户的沟通。
47. Leader要经常review整体的代码和功能：如果一个Leader没有时间看组员的代码是正确而且高质量，那么他必然把团队带得一团糟。
48. Leader需要花时间在整体进度、障碍上。知道剩下的工作在哪里，需要多少资源，多少时间。当前的状态，让队友清楚，也让客户清楚。这样队友就会努力，客户也不会轻易改需求。
49. 做项目就像行军打仗，军官需要得到的是士兵的拥护，而且责任是指挥全局。如果军官冲在前面，则他要死了，全军就解散了。
50. 开发团队的考核标准是少被发现Bug，QA的任务则是多发现Bug。这两组是死对头。
51. 所谓报告，就是报告已经解决了哪些问题，还剩下哪些，需要多少时间多少人力。
52. 经常组织Code review，让大家在彼此的提交中学到东西，并同时可以了解代码架构。
53. 非常明白地对队友提出他个人应该达到的标准，让他知道，如果他没有做好，可能会影响他的发展。
54. 以保时捷的自我定位来提供服务、制作产品和对待甲方，而不是比亚迪；
55. 对新来的队友进行系统的代码、团队合作和项目开发的培训

---

其他参考： 

一次特别的问题员工邮件, 20140414

• Expectation from Paul
  • 6 defects fixed at least for this week
  • AngularJS learning, all of the following
    • http://docs.angularjs.org/tutorial
    • http://docs.angularjs.org/guide
  • Task/Personal growth management Learn this week:
    • The Seven Habits of Highly Effective People
  • Report to Paul every 2 hour of what you are doing, from today. The end day would be set if you are in a good track of a good Senior UX developer.
  • Should arrive at Office before 9:30am and leave after 5:30pm, every day.
• Encouragement
  • We are a team. You are very important to BW. 
  • I am always standing in your side and expecting your growth day by day.
  • You would become better and better in terms of working on a real project in a team with my help and help from other team members.
• Warning
  • If you can’t fulfill my expectation, you might get a formal warning with CC to Manager *, and that would affect your performance evaluation negatively, even your career life in BW project.
  • This warning is being kept between you and me, without escalating to Manager * at this time.

一次特别的项目管理全组会议记录, 201403

• 所有的assign到你自己或者你开的ticket都必须链接到 feature 上面
• 对每个ticket定义优先级
• 做完每个ticket之后，需要 填写JIRA 的 Log work 
• 如果是开ticket并指给另外，则也需要填写你开ticket所花费的时间
• 如果是别人临时指给你的Need Info的ticket，你又指回去，也需要Log work
• 每个有代码提交的ticket下面必须建 sanity test case
  • 是否需要写Case
  • 需要跑完sanity之后，才能关闭ticket并提交
• 每个ticket 都要CC 给产品经理和交互设计师，如果是后端集成的，再加上后端架构师和开发工程师
• 所有的ticket，拿到手之后，需要进行时间评估
  • 估计estimated duration
  • 估计due date
  • 估计resolver build
  • 估计时，要使用专业时间预估机制，参考点
    • 难点
    • 现有技术可行性
    • 样式
    • 前后端沟通
    • regression
    • 资源投入
    • 模块抽象化
    • TEST case / sanity
    • 自我测试时间
    • resource risk / administration time consuming
    • code review
    • buffer
• 让**实行周三早上的UI质量监督
  • 对比Wireframe和Visual，看看那些关闭的ticket与设计是否一致
  • 不一致的，开新的bug
• 周一 10点半 半个小时 iteration 站会，严控时间
  • 管理分析Michael/Meko/Christina/Tim预期
• 每二、三10点半英文scrum svn 解释站会
• 周例会汇报ticket数量和时长
• 会议口头沟通与举例备忘：
  • 如果我们是奔驰公司的经理，我们的原则：
    • 我们不要
      • 使我们的价格更便宜
      • 赠送客户额外的礼品
      • 在同价格下买给客户更高的配置
    • 我们要
      • 提高售后服务
      • 改进Sales 态度
      • 更高质量和更多的推广
      • 更好的自我质量管理、测试

周一 iteration 站会

Items:

1. Go through all high priority tickets and status
2. Analyze expectation of PA
3. Define Project Scope of this week
4. Spot obstacles.
5. Define our goal of this week
   1. Project progress and performance
   2. Personal growth

周二、三的 scrum stand meeting

Items:

1. Explain SVN commit yesterday in English
2. Today’s JIRA task(s) to complete