您当前的位置: author: selfimpr
blog: http://blog.csdn.net/lgg201
mail: lgg860911@yahoo.com.cn
copyright: 转载请声明原出处.
本文的创作源于一位产品同事的质问: "Bug反反复复出现, 这是为什么呢?", 因此, 文中很多观点/场景是针对作者当下正在参与的项目的.
简单介绍下该项目一些主要的关注点:
项目类型: 互联网社交类网站
2012年3月26日之前: 用某开源项目二次开发主站(该开源项目代码凌乱, 质量偏低, 面向中小型用户)
2012年3月26日-2012年4月9日: 我和我的团队加入, 初期尝试对之前产品做结构优化, 后迫于时间压力中止, 忙于Bug修复
2012年4月10日-2012年6月1日: 需要针对客户端(ios/android)提供业务接口, 团队讨论后决定开发新的框架做这块业务, 后同样因为时间压力, 框架有不完善的地方, 但相对主站, 已经足以称道.
2012年6月2日至今: 优化/修Bug/新需求, 进入了焦油坑...每天的Bug和新需求让优化成为一句空谈.
基于上面前提, 本文的描述会基于一个具体的项目, 因此, 不是完全项目无关的软件工程理论分享.
正文:
在收到产品同事"Bug反反复复出现, 这是为什么呢?"的质问后, 和我的直接上级xp进行了简单的沟通, 晚上回到家又回想这个问题, 我想起了小学时候老师讲过的一个故事.
故事是这样的:
一个x国的研究团队, 在全世界各国做一个试验, 让7个小朋友, 每个小朋友拿一个用绳子串着小球, 绳子在小朋友的手中, 7个小球在同一个瓶子中, 瓶口大小只够一个小球同时进出, 当研究人员说开始后, 大家要在最短的时间内把所有小球以最快的速度拉出瓶子.
故事的末尾说只有在中国, 7位小朋友鱼贯而出, 用最短的时间拉出了全部小球.
相信大家都听过类似场景的故事, 我们不去关心究竟是哪国的小朋友用了最短的时间. 而是以此模拟目前项目开发的场景.
目前研发团队的人力资源(主要包括人员素质和团队规模)就是那个瓶口, 研发团队的任务(主要包括产品需求/Bug修复/代码优化/文档完善/流程完善/技能提升)就是那些小球.
我们的目标稍微复杂一点, 需要不断有小球进入, 也不断有小球被拉出, 最终目标是没有可再放入的小球或放入/拉出速度比例达到平衡点.
我们所作的第一件事是把当时已知的小球放进一个瓶子, 迫于时间压力, 我们随手捡起一个瓶子就开始放入小球.
现在, 我们发现瓶口太小了, 它的极限不足以应付小球的流量需求.
问题已经出现了, 下面就是解决方案:
1. 砸烂瓶子, 释放所有的小球, 很不幸, 游戏规则说这样是失败;
2. 一开始就选择更合适大小的瓶口, 不幸的是, "开始"已经成为过去, 我们无法改写历史;
3. 既然我们不能改变"开始", 那就改变现在的瓶口
大家都知道, 当历史已经造成的时候, 我们应该选择第三个方案, 可惜的是, 事情并不是那么简单
瓶口在改造的过程中仍然必须承担运输的责任.
上面标黑的观点, 我想大家都应该是认同的!
所以, 所有期望这件事更好的完成的人, 目标, 认知其实都应该是一致的.
可是, 在对上面观点保持赞成的同时, 我们还应该认识到另外一个观点:
瓶口在承担运输责任的同时进行改造, 那么, 运输责任越大, 改造成本越高, 改造质量越低, 改造时间越长, 改造中车祸越多.
这个观点, 我想已经属于常识了, 就像运行中的高速公路一样, 它要进行维修, 必然也符合上面的规则.
责任是谁的?
一个可能有的错误认识是: 既然这样, 那责任必然在于选择瓶子的人.
不错, 责任在于选择瓶子的人; 但一定需要分析那个执行选择瓶子这件事的人, 是否出于本人专业素养/经验/常识等原因完全自主选择瓶子.
不过, 事情往往不是这样, 每一件事情, 执行者的意识干预通常都不是全部, 这一点在团队协作时尤其明显.
因此, 我们可以去观察很多事情, 意识的形成会受到各种环境因素的干预, 比如: 时间, 成本, 承诺, 合作者, 竞争者, 用户, 前置事件等等.
那么, 通常来说, 这个观点更加适用: 事件执行意识的产生, 由所有参与者共同决定(哪怕某个参与者自始至终没有一句话的沟通交流).
因此, 责任是整个团队共同的.
我相信这样分析, 大家会认同上面的观点.
如果你仍然不认同上面黑体大字描述的观点, 那么下面的内容将不会有任何意义.
如果你目前认同上面黑体大字描述的观点, 我们就用这些观点分析我们自己团队/项目的问题
场景映射:
1. 产品团队负责将小球放入瓶子
2. 研发团队负责将小球拉出瓶子
3. 瓶口主要受限条件为: 已有程序架构, 已有代码质量, 研发人员平均技能, 研发团队规模, 研发团队激情, 决策者等等.
限于开发之初的各种环境因素, 瓶口大小目前固定.
产品团队意愿: 增加瓶口流量, 加大单位时间完成量.
研发团队意愿: 放缓瓶口流量, 花更多精力拓宽瓶口.
矛盾聚焦:
产品团队: 当前响应速度满足不了用户, 到时候没用户你自己玩啊?
研发团队: 水库的闸还不稳当, 一旦开的过大, 必然导致无法控制, 到时候谁玩谁啊?
说到这里, 观点其实很明确, 经常和xp讨论问题, 最终都会归结到"度"的问题.
当研发感觉到需求过多, 无法控制开发过程的时候, 要么崩溃, 要么降低质量, 要么拒绝服务.
当产品感觉研发响应慢时, 必然满腹牢骚.
接下来谈谈关于问题的解决方面, 我的观点.
首先, 请不要和别人比, 在团队素质/团队规模/时间压力/成本投入等各种环境因素对等的条件下, 任何团队都可以做到!!!
当前的问题, 正如<人月神话>中所言, 我们和很多团队一样, 陷入了焦油坑.
这种情况下, 我们应该和<人月神话>中谈到的外科手术队伍一样, 有一个主刀医生, 在研发团队中, xp正在扮演着这个角色.
说的具体一些, 我们的产品需求和线上Bug应该有明确的优先级, 不过, 很多时候, 当研发团队提出这个要求的时候, "所有的产品需求都会变成高优先级",
或者说, "高优先级任务会很快突破研发瓶颈", 因此, 面对这些问题, 考验的不仅仅是研发团队, 因为我们所有人都在做同一件事情, 如果各顾各, 不会有长久的美景...
有一种工作方法叫做"Get Things Done", 还有一种方法叫做"Pomodoro", 它们更多的用在个人工作分片及时间的组织管理, 在写完上面的文字之后, 我觉得它们其实就是在防止"过多高优先级任务干扰视听"的发生.
最后, 引一句<人月神话>提到的, 新奥尔良Antoine餐厅菜单上的笺言: "美食的烹调需要时间; 片刻等待, 更多美味, 更多享受".
- 1楼ryysoft7分钟前
- 想精通软件工程，请来锐英源，www.wisestudy.cn，全国性价比最高