如何组织头脑风暴

Posted on Mon 16 August 2010 in 我思 • Tagged with 头脑风暴

头脑风暴规则

看了Six Great Ways to Ruin a Brainstorm,对头脑风暴的选题、组织和讨论原则又有新的认识。

选题和组织

选择问题

用一个问题来明确讨论目标。提问的原则是既要清晰,又不能限制讨论思路。 目前的头脑风暴都是事先想好问题,直接开始讨论。以后可以尝试大家共同决定问题。达成一致后再把问题写下来。

选择参与者

从人数上来说经验值是6~12人。太少的人数会使头脑风暴的素材不够丰富。而太多的人又难以控制,限制了个人的发挥。这个感触很深,主持了两次20人以上的,根本形成不了风暴。 从参与者的类型上来说,引入不同背景的参与者组成的讨论,效果是最好的。这些人可以涵盖不同的年龄层次、男性和女性、经验丰富的老手或者新人,等等。这点做得不够好,以后要尝试一下。

总结性发言

总结性发言分成三个部分:
  1. 有见地的想法
  2. 有趣的想法
  3. 反对意见
若在有见地的想法里,有特别出色的点子值得马上去实施的,应该立即将之作为一个实践项目交予相关的实行者。

可以使用五分制评分法选出最好的创意。参与者为每个想法打分。他们可以自由的将五分分配给喜欢的想法。比如 ...


Continue reading

【头脑风暴】带新人的思路和方法

Posted on Fri 13 August 2010 in 我思 • Tagged with 头脑风暴

开场白

我们的目标是让新到岗的程序员尽快上手并融入团队。

提出我们在带新人过程中遇到的问题,分享我们带人的经验。

几个比较好的问题

1. 面对面交流时,新人不好意思问问题怎么办?

进而引出如何与新人建立信任关系。 一个办法就是和新人做朋友,不过这个办法属于简约而不简单的,因人而异,不好推广。 还是王征同学,提出信任、辅导、放权三部曲。

2. 文档问题。写还是不写,这真是个问题

葛旭同学很中肯:文档不一定准确,因为没有时间来维护。不如面对面交流。新人应该自己记录。 苑琦同学说得也很对:文档可以长期看,分享给更多的人。面对面交流的开销更大。 王征同学讲得好:知识分为“道”和“术”,流程、规范之类的可以写成文档,经常变化的不一定要写文档。

对应到今天的话题,于是就有了皆大欢喜的解决办法:面对面指导新人,让新人总结成文档。既考察了新人对知识的掌握,又能形成文档,可以扩大共享范围。 另外顺便再强调一下大家尽量都写写纪要,会议纪要呀,沟通纪要之类的 ...


Continue reading

随笔

Posted on Tue 10 August 2010 in 我思 • Tagged with 京东

觉得华仔买的硬盘盒不错,接上我家pc前面的usb口竟然能够正常工作,这样的移动硬盘还是第一次遇到。 搜了一下,他的硬盘盒貌似是这个元谷星钻Mini iPD-eSATA移动硬盘盒,京东链接:149块,还就是一分钱一分货。

这次从他那里导了星际2,哪天有空一定要玩赏一下,希望机器能跑得起来吧。 另外导了一个连续剧,硬盘地方看着不太够了,得再收一个硬盘了,顺便把pc也变成linux host得了。

最近启动新项目的冲击波也影响到我这一亩三分地儿,今天和新阳讨论工作和人员安排,觉得挺受启发的。捋清人、事关系应该是一直在做的事情,不能放,这样才能在面对变化时应付自如甚至藉此优化现有结构,真是个既有挑战性又有成就感的事情。

今天除了这个管理性的工作外就是两个技术决策了,一个是性能日志,另外一个是某服务的优化方案。本周计划还是把数据拆分的工作作为重点,希望明天能有点儿时间和明飞把设计文档弄出个大概来,后续就是要和各个相关部门通通气,提前大好招呼了。


Continue reading

【头脑风暴】程序员的职业规划

Posted on Thu 05 August 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理, 职业规划

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

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

把思维导图拿出来和大家分享:业规划


Continue reading

计费服务开发需要进行一些改进

Posted on Mon 02 August 2010 in 我思 • Tagged with 研发管理

最近计费组人员变动较大,所以我对计费服务关注比较多。在实际开发中,除了因为新人业务不熟造成的调试效率不高外,系统本身也存在一些需要改进的地方。

1. 被动调用和主动发起最好分离

被动式调用:大多数计费功能都是被动式的,接收合作方或我们自己的服务器发送的请求并进行规定的回应; 主动发起: 但也有一些周期订购逻辑,需要计费服务器主动发起一些请求。按照业务要求,主动发起只能由一个实例发起。

目前每个部署实例中,都包含主动和被动功能。现在依靠在部署环境中添加特定环境变量的约定来限制主动发起功能。是一个容易出问题的点。还不如把主动与被动分开的好。

2. 服务部署复杂度高,不同环境下的部署配置不统一

今天加班和这个配置不统一有关。出了一个特别奇怪的现象:两个环境下的代码和类库都一样,但在Release下计费服务一切正常,而Verify下计费服务无法加载正确的广播消息公共模块。 尝试在Release下模拟Verify的问题,但配置高度不一致,无法做;打算用正式环境的代码覆盖Verify,但这个操作只能摆脱系统部的人做(开发的没有这两个环境的权限),又怕引起多个主动发起,也作罢了。

3. 功能的模拟测试和自动化测试还需要加强

上周加了两天的班调一个计费应用,其实在这个应用中计费就提供了一个特别简单的接口,复杂性都在另外一个team。我们提供了一个模拟测试,让那个team的开发和测试人员都清楚的看到我们的接口是好用的。我们就不用跟着他们耗着了。 昨天和群峰、苑琪确认了,现在在Release和Verify都可以做模拟测试了。这个好习惯需要保持下去。


Continue reading

【头脑风暴】如何做好知识分享

Posted on Sat 24 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

如何做好知识分享

讨论原则

  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

现有架构中数据存储面临的挑战与应对

Posted on Sun 18 July 2010 in 我思 • Tagged with Architecture, CAP, Database

传统数据库方案(Oracle)面临的挑战

  1. High Performance: 高并发的读写
    • 高并发读写造成的锁等待问题
  2. Huge Storage: 海量数据的存储和访问
    • 传统数据库对海量XML数据结构的存储解决方案不太友好,类似vCard的存储
  3. High Scalability & High Available: 高扩展性和高可用性
    • 传统数据库Scale Out的解决方案复杂性高(业务相关的)且代价高

现有架构中数据存储面临的挑战

OLTP到OLAP的数据同步,实时性要求越来越高

我们很早就做到了OLTP和OLAP系统分开的:

  • OLTP(On-Line Transaction Processing)联机事务处理:OSS
  • OLAP(On-Line Analytical Processing)联机分析处理:DA-Server, SBX
但越来越多的数据分析需求,要求能够获得实时性性更高的数据。而高实时性会增加同步的代价。

业务间对共有数据操作的竞争

由于现有的数据库设计并没有对用户数据和业务数据进行逻辑上的区分,所有服务对用户数据都有相同的权限,操作同一块用户数据引起的问题无法从根本上进行避免。

业务间对数据库资源的竞争

目前的数据库是建立在一个Oracle实例(并且在一个用户下)中的,同时为杀毒 ...


Continue reading

【头脑风暴】如何让上级看到工作业绩

Posted on Fri 16 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

主持人发言

讨论原则

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

抛砖引玉

结合工作,说说自己的看 法:

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

换位思考,如果你是BOSS,你会关心什么?

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


Continue reading

【提纲】- 如何让上级看到自己的工作业绩?

Posted on Thu 15 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

结合工作,说说自己的看法:

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


Continue reading

【头脑风暴】说说监控

Posted on Fri 09 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理, 系统监控

主持人发言

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

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

监控提供的功能

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

内容

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

怎样做

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


Continue reading

【提纲】- 关于“监控”的头脑风暴

Posted on Thu 08 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理, 系统监控

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

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

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

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

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


Continue reading

汇报之后

Posted on Mon 05 July 2010 in 我思 • Tagged with 管理

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


Continue reading

【头脑风暴】工作的计划

Posted on Fri 02 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

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

  1. 为什么要做计划
  2. 哪些工作需要制定计划
  3. 做计划有哪些需要注意的因素
为什么要做计划
  1. 工作明确【王征】
  2. 工作没有计划时,很难让团队发挥主动性【郝庆治】
  3. 没有长期计划,自己很难提高;明确下来,才能够完成;不要怕计划完成不了而不定计划【刘苑琦】
哪些工作需要制定计划
  1. 招人【刘明飞】
  2. 非项目的开发工作【王晨】
  3. 任何事情都可以做计划【韩群峰】
  4. 计划有风险的地方,重要的里程碑【王征】
  5. 先做好不变需求的计划,为变化留出时间【宋斌】
做计划有哪些需要注意的因素
  1. 按固定时间段,比如一周查看工作完成情况【王晨】
  2. 整体目标必须明确,需要清楚公司的整体目标【王晨、韩群峰】
  3. 工作必须量化【群峰】
  4. 落实到具体的个人,可以开每天例会,8个人内不超过15分钟:昨天做了什么工作,遇到什么困难 ...


Continue reading

【提纲】- 关于“计划”的头脑风暴

Posted on Fri 02 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

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

Why 重要性

What 什么事情该计划

How 怎样定? 怎样完成?

- 分享

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


Continue reading

【头脑风暴】如何激励团队士气

Posted on Fri 25 June 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理

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

请大家回答两个问题:

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

造成我们士气不足的原因

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

如何提高士气

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


Continue reading