Posted on Thu 08 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理, 系统监控
监控的目的 确认故障点 分析历史数据，预判故障
- 监控具体的工作内容： 按照对目前工作的认识，监控由下往上分为系统监控、业务监控、用户监控 系统监控包括： 网络和硬件的有效性监控；服务请求相应时间、服务请求总量等 业务监控：包括基础业务数据信息获取 用户监控：从基础数据中基于用户标志进行关联组合，获得用户行为
监控还包括阈值判断、触发报警判断等功能
- 怎样来做： 目前的监控系统建设交给运营支撑线去做，有些过于纠结于运营部门提出的业务逻辑。最好从基础业务信息获取入手，好好分析一下目前到底能够拿到哪些基础业务数据； 然后可以继续深入，提高基础信息的关联性，把基础业务信息和一个用户使用我们产品的行为关联起来； 基于以上的工作，再来和运营讨论业务监控逻辑。
也要思考怎样做服务可用性的监控。
Posted on Fri 02 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理
主持人： 李焱 参加人： 组长 结合工作，从以下三个方面挑选一、二发言：
Posted on Fri 02 July 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理
- 讨论内容的范围 结合工作，从一下三个方面挑选一、二发言。
Why 重要性
What 什么事情该计划
How 怎样定？ 怎样完成？
- 分享
“凡事豫则立，不豫则废。言前定则不跲，事前定则不困，行前定则不疚，道前定则不穷。” ----《礼记·中庸》
Posted on Fri 25 June 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理
请大家回答两个问题：
Posted on Sun 13 June 2010 in 我思 • Tagged with 头脑风暴, 研发管理, 管理
群峰提出了问题并进行了思考，主持了这次头脑风暴会议。大家对这个问题，都一些心得，讨论得很热烈。讨论内容记录如下。
- 跨线部门的范围
上游的需求部门（产品中心或运营中心），兄弟部门（开发中心的其他部门或开发小组），下游部门（测试部、系统部）。
- 需求有效性的问题
群峰提问：上游需求部门给出的需求不够清晰或者存在争议，如何解决？ 发言： 老郝：需求沟通后，沟通结果抄送需求方领导，留作凭据。 王征：避免需求不全面，存在争议或未经过全部干系部门确认，需求需要抄送相关干系人。 明飞：需求不全，打回。描述含糊，我们进行分析，给需求方选择，与需求人一同确认。提示需求人组内沟通。产品运营跨部门需求，开发方提出双方沟通。研发人员主动沟通。 我：完整的需求应该包含业务功能，业务逻辑，技术架构。我辈需要努力进行完善。 总结：
上周部门例会开始了一个新的话题：汇总大家在工作中遇到的各种问题，共同进行思考和讨论。关于职业规划、团队建设、或者是业务或技术方面的，只要和人有关的都可以。有什么困惑或者曾经想明白了的问题，都可以讲出来。
这么做的目的就是希望激发Team lead们的积极性，促进团队之间的经验分享。关于这个话题的第一次例会的议题就是问题收集。
在收集问题的过程中遇到了两个问题，我是这样处理的：
我得到的问题是这样的：
问题都是好问题，但在提问过程中我觉得有点儿什么东西还在我的控制范围之外，这个感觉直到今天我才找到答案。那就是我们还没有为提问回答定一个原则，我们要就哪类问题提问。其实这也是我们的工作原则，左思右想，就这么两条，请各位拍砖：
最近在和一些同事聊天，有些经验体会由于没有很好的抽取整理，表达起来模糊不清，不成体系。昨天早上看到新阳撰写的两篇博客，发现他把我想表达的意思说得非常清晰明了。接合之前的一些资料，于是有了这篇文字。和广大程序员分享。
把控需求这块是重中之重，需求没做好，会降低系统的稳定性、可维护性、开发速度、处理业务的性能，更会增加改进的难度。 把控需求的工作，体现在这么几方面：
从管理者的角度看问题，结果比过程重要。研发管理的目标应该是：
大局观很重要。创业型的技术公司一般都从产品视角看待研发工作，作为研发部门，不能仅仅是被产品经理的需求驱动，自己一定也要积极参与到产品设计过程，这样才能有完整的视角，和公司目标一致。
然后就是带队伍。和团队一起工作、学习和成长，选出最适合的往往也是最优秀的来担当产品经理的角色。
最后一点也是目前最欠缺的一点，就是开发工作最后形成不了产品，团队很辛苦，事情也做了一大堆，但没有形成一个系统的东西。所以，在日常的功能点开发时就要做产品化的考量。做直接被其它产品调用的公共组件，团队很难有高昂的士气。
Posted on Thu 24 December 2009 in it • Tagged with 研发管理, 职业规划
《程序员》10年1月期会有个关于开发者的五项软实力的策划，现在大家可以去参与调查（需要登录csdn）。
这个提法很不错，对开发者技术能力之外的隐性能力做了定性的分类，我们可以看看：
软实力即软技能，来之于英文单词“Soft Skill”。软件开发者在工作中都会采用一定的经验和方法，这些经验和方法的运用，体现了开发者的实力。相对于硬性技术，沟通、协作、团队领导、问题解决等方面的行为能力与表现就是开发者的软实力。它涵盖的范围非常广泛，日益受到人们的重视。软实力，往往易被IT从业者所忽略，但实际是至关重要的。它决定了人们事业的成就和职业发展的高度，包括一个人职业升迁和发展的前景等。
对软件开发团队来说，最关键的是交付能力，团队整体的沟通协作、问题解决能力在其中起到了决定性的作用。这些在日常管理中很难量化考核的指标，往往会决定一个项目甚至一个产品的成败。那么这些能力也可以称做是开发团队的软实力吧，我觉得应该可以包括一下能力：
Posted on Mon 30 November 2009 in 我记 • Tagged with 研发管理, 管理, 通讯协议
今天上午和下午分别在CEO和研发VP的屋子里面开站立会议，别误会，此站立会议不是Scrum里面的那个Sprint中每天早上的那个站立会议。开会的目的是要落实业务导向的研发组织结构。
上午的会给出了一个比较激进的研发管理结构，把客户端和服务器的研发也都按照产品线给合并了，相比之下，由我们部门自己规划和发布的两条线变成了三条线的这个变化，就不算什么了。大佬提出的这个方案，在总监层面的反应不是特别的积极，研发VP建议大家回头各自整理一下，再继续讨论。
中午吃饭前看到RTX上老汉发了一条消息：服务器和客户端能不能分头开发？华仔的回复是“可以啊”。我回的是“为什么不呢，分开搞爽死了”。遥想第一次在公司开季度总结会，我就向研发VP提出建议服务器和客户端分开开发的工作模式，被拒绝了。上次一块吃饭的时候，又提过一次，记得拒绝的理由是怕两方沟通不畅。这次老汉提出这个建议后，结果又会怎样呢？
下午4点半大家聚齐后开始讨论研发组织结构，大家集思广益，的确有所收获：1. 研发矩阵式管理模型的明确；2. 服务器、客户端之字形演进方式的讨论；3. 三级研发人员的KPI考评体系。分别展开记录如下：
原有的按平台和技术划分的部门为纵向结构，继续保持，由产品线经理统领，在招聘、培训、资源分配等方面进行管理；横向按照产品线进行组织，由产品、运营和研发（客户端、服务器各一人 ...
上周发生了很多事情：来自其他中心和部门的同事通过各种渠道，反馈了他们对研发的不满和期许；公司请来业内一家著名公司的研发总监，和我们探讨研发管理经验--当然，对我们来说，基本上是请教；部门内部也有一些情况，重要产品的研发组长觉得身心俱疲，需要向他提供更多的指导和帮助。
这些情况都和一件事有关，那就是公司的产品研发管理方式。要想看清公司的产品研发方式，必须把握组织结构和产品研发过程。
现有产品研发管理情况和问题分析：
静态上看产品、研发和运营三个中心是独立的组织，产品的研发依赖三个中心的频繁沟通和紧密配合；动态看是通过项目管理把三个中心的人员组织起来，共同完成产品研发的小步快走。
三个中心互相独立的好处很明显，产品、研发、运营是公司的三架马车，通过紧密合作共同打造产品。但随着公司产品线和各个公司人员的扩充，沟通的代价也变得越来越大，而做为产品、运营需求实现者的研发部门，已经处于疲于奔命还无法满足方方面面众多需求的境地。
基于项目组织产品研发好处也很明显，可以很灵活，快速的把交付的软件投入市场，由项目的逐步实施来形成产品。这个思路很美好，也没有太大的前期资金投入，但是这样做出来的软件，在产品架构上存在先天性的不足。
从管理上看，产品、研发、运营各个部门独立，很难形成共同目标--这是造成沟通代价的根本原因。由于研发部门基本处在执行层面，开发人员性格又都比较内向，在现有的研发过程中，完全处于弱势地位。而研发目前的基于质量的考核，对开发人员的创造力，客观上是有很强的抑制作用的 ...
今天临时被叫去参加一个会，结果开到后来，变成了一个对研发中心的批判会。因为会前没有会议邀请，会后也没看到会议纪要，不是很清楚会议议题，不过感觉应该是探讨公司怎么改进测试过程的。
我被叫去是因为带人在做的一个协议原型，开始是为了方便演示，顺便在里面写了个通用的能模拟业务逻辑的测试框架，这个框架完善后可以照搬到现有的应用中，有这么几个好处：1. 通过单元测试表述应用逻辑，做为文档的替代，能加快业务逻辑的传承；2. 能提高现有的单元测试的强度，提高代码质量；3. 模拟业务逻辑足够全面后，能够替代手工测试，大大降低测试代价。
我们部门，在测试环节暴露出的问题：
这几个问题我真的不好回答，按照我了解的情况，第一条是之前为了让开发人员工作饱满，跨产品线分配任务而且没有问题分析、文档整理时间造成的；第二条是具体当事人的问题；第三条是合并代码过程复杂造成的，想要改变这个过程，必须进入业务，和一线开发人员一起改进。
研发中心都存在的问题：
最后老总的总结我觉得是很有道理的，做为管理人员，最重要的工作就是定岗定编定流程，问题原因分析下来就这么几类：业务、管理 ...
- Reffer:
http://www.bokee.net/dailymodule/blog_view.do?id=69926
http://blog.163.com/jacksun10168/blog/static/275324872008330673348/
管理者的职责：
管理者常犯的11个错误：
Posted on Tue 16 December 2008 in it • Tagged with 研发管理, 管理, 软件开发
KPI（Key Performance Indication）即关键业绩指标。对本部门的指标量化和考评，我们将做如下尝试。
1. 分岗位制订考评系数（总分系数）
架构师、组长、DBA（1.2）、开发人员（1.0）
对组长和核心开发人员（架构师、DBA）倾斜，提高他们的系数，鼓励他们的工作
2. 任务完成率（基础分）
部门内部，项目和短期任务统一考评。
本季度内投入的工时数，单位为人天。
举例：假设某季度正常工作日62天，某人全勤，且加班12小时，则他的基础分62+12/8=63.5
这个本意是考察程序员的产出，因为目前无法量化每个人的具体工作量，只能按照工时来统计了。
3. 质量保证指标（扣分指标）：
1）每次svn提交，开发人员必须填写提交信息： 提交目的 ...