盖洛普Q12的学习笔记

起因

公司人力搞了一下Q12调查，并把大家交到一起做了一个培训。 觉得这个调查方法针对性挺强的，能让管理者有针对性的对工作进行改进。 今天又拿到我们部门自己的数据，就一边分析一边学习了。

关于盖洛普和Q12调查

盖洛普是美国数学家，抽样调查方法的创始人，后来创建了一家咨询公司，也叫盖洛普。 盖洛普通过对12个不同行业、24家公司的2500多个经营部门进行了数据收集，然后对它们的 105,000名不同公司和文化的员工态度的分析，发现了12个关键问题最能反映员工的保留、利润、效率和顾客满意度这四个硬指标。这就是著名的Gallup Q12。

12个问题

Q1：我知道公司对我的工作要求 Q2：我有做好我的工作所需要的材料与设备 Q3：在工作中，我每天都有机会做我最擅长做的事 Q4：在过去的7天里，我因工作出色而受到表扬 Q5：我觉得我的主管或同事关心我的个人情况 Q6：工作单位有人鼓励我的发展 Q7：在工作中，我觉得我的意见受到重视 Q8：公司的使命/目标是我觉得我的工作很重要 Q9：我的同事们致力于高质量的工作 Q10：我在工作单位有一个最好的朋友 Q11：在过去的6个月内 ...

Continue reading

周五上午的大会议室被人循环订上了，我们的头脑风暴就改到周四上午了，提前一天开，感觉准备起来有点儿赶。其实之前的积累还是挺丰富的，内容来自《关于职场规划》、《程序员职场生涯n次转型》、《职业生涯规划的九个立足点》。

因为是回家才开始准备的，对内容的组织，apple给了很多的意见，主要吸取的是增加了Why和Goal，说明一下做职业规划对大家的好处和本次交流的目的； 在现场怎么和大家互动也花了一些心思，准备了三个统计调查和大家互动； 在早上上班路上还在想，如何让大家对职业规划有感性认识？竟然让我想到拿旅游计划来类比，呵呵，现在想想依然有点儿得意，不过这应该也得益于apple最近正在准备的十一旅游。

把思维导图拿出来和大家分享：

Continue reading

如何做好知识分享

讨论原则

1. 总是想一下自己或自己的团队能做些什么
2. 心里阳光一点儿，多从积极方面考虑问题，不说负面内容

主持人发言

1. 形成知识分享的氛围
   1. 公司将积累的知识视为公司财富，肯定其重要性
   2. 本着拿来主义精神，对于不适合的知识分享，先肯定其工作态度再引导其正确的进行知识分享，不打消积极性，另外，可以开辟多个共享主题，明确主题内容
   3. 对乐于知识分享的人给予充分的肯定和鼓励
   4. 强调自觉的重要性，但是最好有一定的利益激励：如kpi加分项或者定期的组内表扬
   5. Open的态度：所有人都应该open，不断的完善，乐于接受意见及建议
2. 知识分享平台：Wiki
   1. 有明确的知识分类及索引，可以方便快速准确的查找问题
   2. 有确定的存储空间保存共享信息，防止愿意共享而无处共享的情况
3. 鼓励进行知识分享：KPI
4. 组长带头，在组员不愿意或者不清楚如何进行知识分享时，组长要充分起到示范作用
   1. DB组的wiki，组长先写好，整理好，然后发给大家，让大家看到知识分享的好处
   2. 组长要定期对共享资料进行整理，避免繁杂无序，无人愿意看
5. 不定期的面对面交流（面对面）
   1. 要充分鼓励培训和经验交流，花时间整理资料，会占用部分私人时间，建议组长带头做起 ...

Continue reading

主持人发言

讨论原则

1. 总是想一下自己或自己的团队能做 些什么
2. 心里阳光一点儿，多从积极方面考虑问题， 不说负面内容

抛砖引玉

结合工作，说说自己的看 法：

1. 换位思考，你觉得上级会关心什么？
   1. 工作是否主动
   2. 对工作是否思考怎样干的更好
   3. 是否坚持
2. 哪些工作可以提升我们的业绩？
   1. 体现主动性的工作
   2. 展 示自己的工作思路、总结
   3. 做好季度计划和总结
3. 公司目前的价值评估标准
   1. 贡献度： 收入、用户、影响力；
   2. 相 应速度、满意度；
   3. 投入产出比；
   4. 统一标准是绩效

换位思考，如果你是BOSS，你会关心什么？

1. 【监控系统、报表系统】上级关 心的是系统的准确性和可用性。【郝庆治】
2. 冲刺 项目：关注的是进度；维护项目：关注的是稳定性【王征】
3. 这 个问题很复杂，不同角色关注点不同【王晨 ...

Continue reading

结合工作，说说自己的看法：

1. 换位思考，你觉得上级会关心什么？
2. 哪些工作可以提升我们的业绩？

- 换位思考，如果你是BOSS，你会关心什么？

1. 工作是否主动
2. 对工作是否思考怎样干的更好
3. 是否坚持

- 哪些工作可以提升我们的业绩？

1. 体现主动性的工作
2. 展示自己的工作思路、总结
3. 做好季度计划和总结

- 公司目前的价值评估标准

1. 贡献度： 收入、用户、影响力；
2. 相应速度、满意度；
3. 投入产出比；
4. 统一标准是绩效

Continue reading

主持人发言

结合工作，从一下三个方面挑 选一、二发言：

1. 目的： 监控应该提供怎样的功能
2. 内容： 哪些地方需要监控
3. 怎样做：结合工作谈谈怎样监 控系统设计、开发的思路

监控提供的功能

1. 确认故障点：目前计费报警不是 特别方便定位【葛旭】
2. 评估服务情况： 给出财务损失报告【李焱】
3. 服务能力预警： 分析历史数据，根据趋势为服务能力告警【李焱】

内容

1. 在数据库层面，对统计查询的监 控力度还不够；监控系统的可用性也需要监控【苑琦】
2. 系 统角度： 网络和硬件的有效性；服务请求总量；服务请求相应时间分布【李焱】
3. 业 务角度： 计费成功情况、用户成果推送情况【李焱】
4. 用 户行为角度： 用户行为分析【李焱】

怎样做

1. 监控报警不够准确，需要加强； 监控系统的可用性需要有保障 ...

Continue reading

监控的目的 确认故障点 分析历史数据，预判故障

- 监控具体的工作内容： 按照对目前工作的认识，监控由下往上分为系统监控、业务监控、用户监控 系统监控包括： 网络和硬件的有效性监控；服务请求相应时间、服务请求总量等 业务监控：包括基础业务数据信息获取 用户监控：从基础数据中基于用户标志进行关联组合，获得用户行为

监控还包括阈值判断、触发报警判断等功能

- 怎样来做： 目前的监控系统建设交给运营支撑线去做，有些过于纠结于运营部门提出的业务逻辑。最好从基础业务信息获取入手，好好分析一下目前到底能够拿到哪些基础业务数据； 然后可以继续深入，提高基础信息的关联性，把基础业务信息和一个用户使用我们产品的行为关联起来； 基于以上的工作，再来和运营讨论业务监控逻辑。

也要思考怎样做服务可用性的监控。

Continue reading

昨天到单位汇报部门岗位说明。之前就感觉不会就是简单的说一下，就早去了一会儿，想提前再准备准备。结果议程提前了，到公司就轮到我了。其实提前准备也没太大意义，因为根本没弄清楚领导想问什么。 现在想想，其实领导主要有两个意思：一个是现在云端的人太多，怕我对管理重视不够也担心我管的不好；第二点是希望人员尽量精简。 头一点我当时应对的不够好，直接钻进去了，Web/Wap组具体干哪些事情，都由谁来做。后来就老老实实告诉倪博，这两个组具体的工作都是新阳在带，目前已经按照公司意图拆分成负责具体任务的4个小Team了，其余那5个组，我都是直接在跟进任务和人员的分配。然后他们就继续往细节上问，直到把我给问住。这个问题我其实应该赶快扭转一下方向，清清楚楚告诉领导我的管理思路：整个部门分成7个组，日常开发工作的职责都交给组长。这40来人，做这么多的事情，我一个人来做中枢根本不现实。所以我的工作重点都是以小组为单位展开的，主要工作就是带领组长做季度计划、考评。 第二点当时宇平是明白领导意图的，所以直接就说，具体的人员需求，放到下面再谈吧，具体问题具体分析。这个处理方法非常好。 后来领导还表达了一个意思，就是工作思路上研发要更积极，这个话题我接了一下，因为现在开发人员在认识上都已经很认可这点了，从群峰、王征、王晨，到明飞、老郝 ...

Continue reading

主持人： 李焱 参加人： 组长 结合工作，从以下三个方面挑选一、二发言：

1. 为什么要做计划
2. 哪些工作需要制定计划
3. 做计划有哪些需要注意的因素

为什么要做计划

1. 工作明确【王征】
2. 工作没有计划时，很难让团队发挥主动性【郝庆治】
3. 没有长期计划，自己很难提高；明确下来，才能够完成；不要怕计划完成不了而不定计划【刘苑琦】

哪些工作需要制定计划

1. 招人【刘明飞】
2. 非项目的开发工作【王晨】
3. 任何事情都可以做计划【韩群峰】
4. 计划有风险的地方，重要的里程碑【王征】
5. 先做好不变需求的计划，为变化留出时间【宋斌】

做计划有哪些需要注意的因素

1. 按固定时间段，比如一周查看工作完成情况【王晨】
2. 整体目标必须明确，需要清楚公司的整体目标【王晨、韩群峰】
3. 工作必须量化【群峰】
4. 落实到具体的个人，可以开每天例会，8个人内不超过15分钟：昨天做了什么工作，遇到什么困难 ...

Continue reading

- 讨论内容的范围 结合工作，从一下三个方面挑选一、二发言。

Why 重要性

What 什么事情该计划

How 怎样定？ 怎样完成？

- 分享

“凡事豫则立，不豫则废。言前定则不跲，事前定则不困，行前定则不疚，道前定则不穷。” ----《礼记·中庸》

Continue reading

主持人： 郝庆治 参加人：部门核心开发人员及组长以上干部

请大家回答两个问题：

1. 造成我们士气不足的原因
2. 如何提高士气

造成我们士气不足的原因

1. 开发人员不知道自己的工作成果，看不到业务上的成就感[郝庆治]
2. 业务人员不喜欢和开发人员讨论业务[周涛]
3. 葛旭本周不在，负责处理计费相关问题排查，发现任务繁多，处理起来很耗费心力[海洋]
4. 需求方对合理化建议不是很重视，感觉需求方把程序员当成了电脑的附件；需求考虑不全引起的变更频繁[宋斌]
5. 士气和工作内容也有关系，维护工作，经过好多手，比较痛苦[欧阳鹏]

如何提高士气

1. 从其他部门收集工作成果，发送相关开发人员[郝庆治]
2. 我们既要有业务上的成就感，也要有技术上的成就感，在组内做好技术培养；避免开发人员感到挫折感[王晨]
3. 通过把手工工作系统化，提高成就感[周涛]
4. 让开发人员参与整个系统的开发周期，赋予职责，提高开发人员的成就感；组内开展技术培训；鼓励开发人员和业务人员做好沟通，消减无效需求也能增加开发人员的成就感[韩群峰]
5. 了解组内的开发人员的职业规划，有针对性的做指导[韩群峰]
6. 对业务流程充分掌握后 ...

Continue reading

群峰提出了问题并进行了思考，主持了这次头脑风暴会议。大家对这个问题，都一些心得，讨论得很热烈。讨论内容记录如下。

- 跨线部门的范围

上游的需求部门（产品中心或运营中心），兄弟部门（开发中心的其他部门或开发小组），下游部门（测试部、系统部）。

- 需求有效性的问题

群峰提问：上游需求部门给出的需求不够清晰或者存在争议，如何解决？ 发言： 老郝：需求沟通后，沟通结果抄送需求方领导，留作凭据。 王征：避免需求不全面，存在争议或未经过全部干系部门确认，需求需要抄送相关干系人。 明飞：需求不全，打回。描述含糊，我们进行分析，给需求方选择，与需求人一同确认。提示需求人组内沟通。产品运营跨部门需求，开发方提出双方沟通。研发人员主动沟通。 我：完整的需求应该包含业务功能，业务逻辑，技术架构。我辈需要努力进行完善。 总结：

1. 让需求人员、干系人、测试人员尽早体验功能
2. 做好需求确认
3. 沟通结果抄送需求方领导

- 项目资源冲突的问题 ...

Continue reading

上周部门例会开始了一个新的话题：汇总大家在工作中遇到的各种问题，共同进行思考和讨论。关于职业规划、团队建设、或者是业务或技术方面的，只要和人有关的都可以。有什么困惑或者曾经想明白了的问题，都可以讲出来。 

这么做的目的就是希望激发Team lead们的积极性，促进团队之间的经验分享。关于这个话题的第一次例会的议题就是问题收集。

在收集问题的过程中遇到了两个问题，我是这样处理的：

1. 有人提出的问题大家都很感兴趣，就会把收集问题的会议变成对某个问题的讨论，对于这种明显跑题的行为，需要进行引导甚至制止；
2. 因为怕冷场，所以我在议题里明确写着每个人最少要提出一个问题。随着提问的增加，后面的人会感觉到自己的问题已经被别人说出来了。这时不能接受这个借口，给一点儿压力，能得到意外的效果。

我得到的问题是这样的：

1. 如何激励团队士气？
2. 如何提高团队的积极性？
3. 如何提高开发人员的责任感和主人翁的意识
4. 项目周期内如何做好跨部门、跨业务线间的人员协作
5. 如何预见和预防项目中的技术、业务、人员风险
6. [技术]如何做好Redis缓存系统的知识分享
7. 怎样进行知识分享效果最好？
8. 如何让上级看到工作业绩？

问题都是好问题，但在提问过程中我觉得有点儿什么东西还在我的控制范围之外，这个感觉直到今天我才找到答案。那就是我们还没有为提问回答定一个原则，我们要就哪类问题提问。其实这也是我们的工作原则，左思右想，就这么两条，请各位拍砖：

1. 我们只思考那些经过我们自身努力能够解决的问题；
2. 不要在公共场合说抱怨的话 ...

Continue reading

今天上午和下午分别在CEO和研发VP的屋子里面开站立会议，别误会，此站立会议不是Scrum里面的那个Sprint中每天早上的那个站立会议。开会的目的是要落实业务导向的研发组织结构。

上午的会给出了一个比较激进的研发管理结构，把客户端和服务器的研发也都按照产品线给合并了，相比之下，由我们部门自己规划和发布的两条线变成了三条线的这个变化，就不算什么了。大佬提出的这个方案，在总监层面的反应不是特别的积极，研发VP建议大家回头各自整理一下，再继续讨论。

中午吃饭前看到RTX上老汉发了一条消息：服务器和客户端能不能分头开发？华仔的回复是“可以啊”。我回的是“为什么不呢，分开搞爽死了”。遥想第一次在公司开季度总结会，我就向研发VP提出建议服务器和客户端分开开发的工作模式，被拒绝了。上次一块吃饭的时候，又提过一次，记得拒绝的理由是怕两方沟通不畅。这次老汉提出这个建议后，结果又会怎样呢？

下午4点半大家聚齐后开始讨论研发组织结构，大家集思广益，的确有所收获：1. 研发矩阵式管理模型的明确；2. 服务器、客户端之字形演进方式的讨论；3. 三级研发人员的KPI考评体系。分别展开记录如下：

原有的按平台和技术划分的部门为纵向结构，继续保持，由产品线经理统领，在招聘、培训、资源分配等方面进行管理；横向按照产品线进行组织，由产品、运营和研发（客户端、服务器各一人 ...

Continue reading

上周发生了很多事情：来自其他中心和部门的同事通过各种渠道，反馈了他们对研发的不满和期许；公司请来业内一家著名公司的研发总监，和我们探讨研发管理经验--当然，对我们来说，基本上是请教；部门内部也有一些情况，重要产品的研发组长觉得身心俱疲，需要向他提供更多的指导和帮助。

这些情况都和一件事有关，那就是公司的产品研发管理方式。要想看清公司的产品研发方式，必须把握组织结构和产品研发过程。

现有产品研发管理情况和问题分析：

静态上看产品、研发和运营三个中心是独立的组织，产品的研发依赖三个中心的频繁沟通和紧密配合；动态看是通过项目管理把三个中心的人员组织起来，共同完成产品研发的小步快走。
三个中心互相独立的好处很明显，产品、研发、运营是公司的三架马车，通过紧密合作共同打造产品。但随着公司产品线和各个公司人员的扩充，沟通的代价也变得越来越大，而做为产品、运营需求实现者的研发部门，已经处于疲于奔命还无法满足方方面面众多需求的境地。
基于项目组织产品研发好处也很明显，可以很灵活，快速的把交付的软件投入市场，由项目的逐步实施来形成产品。这个思路很美好，也没有太大的前期资金投入，但是这样做出来的软件，在产品架构上存在先天性的不足。

从管理上看，产品、研发、运营各个部门独立，很难形成共同目标--这是造成沟通代价的根本原因。由于研发部门基本处在执行层面，开发人员性格又都比较内向，在现有的研发过程中，完全处于弱势地位。而研发目前的基于质量的考核，对开发人员的创造力，客观上是有很强的抑制作用的 ...

Continue reading