现代软件工程 第九章 练习与讨论

9.5.1  PM们的故事

讲了这么多条条框框,我们还是来讲几个故事吧。

A)是不是所有的好功能都是由PM主导,一步一步根据用户需求,按照用户场景设计,然后进行可用性测试等等步骤之后得来的呢?

功能本天成,妙手偶得之——一个来自微软的故事

约摸在1985年,微软的一个叫Steve Hazelrig的工程师正在写Mac Excel 版本的打印功能,那时候激光打印机很贵,而且离办公室也不近。他懒得经常跑到打印机那儿取打印纸检查打印效果,就写了一个小程序,把要输出到打印机的图像显示在屏幕上,还有一个放大镜功能可以把局部放大以检查每个像素的位置及效果。这时一个PM路过看到了这个小工具,说,这么酷的东西,为啥不做成一个功能呢?

所以后来微软的编辑软件都有了“打印预览”这一功能。然而,用户们并没有正式地要求这一功能。

B)PM怎么说服聪明的同事?

这个故事在[注4, 注5]中都提到了。在Macintosh研发的过程中,由于计算能力的限制,计算机的图形显示非常缓慢。一位聪明的程序员展示了他的新算法,能很快地画圆形和椭圆。当他得意地展示给Steve Jobs看的时候,(作为一个不懂编程技术的PM,Steve应该表示仰慕才对……)Steve平静地反问——你能继续改进,让圆角的矩形框显示速度加快么?程序员说:这个太难了,也没有必要。椭圆不是挺好的么?Steve为了说服同事,建议两人到外面散步,然后指出现实世界中的各种告示牌都是用圆角的矩形框来实现的,走了一圈,同事就被说服了。过了几天,圆角的矩形框也可以很快速地在屏幕上显示了。

C)PM如何找到需求?

一些人常说PM负责提需求,Dev就管实现就好了,那需求从哪里来呢?我们用了一章的内容来说明这个问题,参见本书“第8章 需求分析“。

D)PM的分析能力和韧性

能把市场、我方的优势和劣势、创新的机会讲得头头是道,也是一种能力。在“第8章 需求分析”中我们讲过NABC方法[YEKA3] 。乔布斯在NeXT公司时也做过很有说服力的分析:

http://v.youku.com/v_show/id_XMzE1Mzc2NTE2.html

注意,这么厉害的PM,分析得这么透彻,但是NeXT的产品还是失败了。

但是乔布斯没有气馁,又投入了另一个公司的运作——Pixar。

你有这些能力么?

微软的PM有着独特的历史和价值,正如Steven Sinofsky讲的:一直被拷贝,但很少成功复制……[注6] [注8]。新的技术浪潮和商业模式给IT人士提供了一波又一波的机会,了解PM的特点和要求,对想要进入这一领域的同学来说很有好处。

9.5.2  在校学生如何为成为PM做准备

不少大学里的同学都有一个想法——先做几年技术,然后做管理;也有一些同学说——我技术不行,希望直接找到一个做管理的工作,就像PM那样。课程的老师邀请了几位在工业界工作的PM来和同学们谈谈PM在他们项目中的作用,PM在整个公司的作用,如何从别的职业转为项目经理,如何在学校里为PM这一职位做准备,等等。

9.5.3 生活中的三元组举例

我们说过, 大部分优秀的团队可以做到目标三元组 (多,快,省)中的两个,类似的三元组还可以用来说明各种商品或活动的不同特性, 例如,如果你和你的小伙伴想周末去某地旅游,交通工具的选择也可以用一个三元组来权衡(快速,灵活,便宜)。请分析各种交通工具的特性(长途汽车,火车,自驾,飞机,自行车,等)。


现代软件工程 第九章 练习与讨论,布布扣,bubuko.com

时间: 2024-10-13 12:11:36

现代软件工程 第九章 练习与讨论的相关文章

软件工程—第九章

第九章—软件实现 这一章重点讲述了软件代码编写过程中的规范和一些经常遇到的问题. 软件的实现过程包括代码设计.设计审查.代码编写.代码走查.代码编译和单元测试等基本活动. 在规范代码的编写过程中,要注意以下几点:1.文件命名与组织:一般说来一个java源文件的长度最好不要超过2000行.2.代码的版式:要有适当的空行,要注意代码行及行内空格,分行.对齐与缩进,还有命名规则与声明.注释. 从案例中分析了程序注释.变量命名.内存异常.异常处理.性能等问题.

现代软件工程第一章练习与讨论

1. public class c30questions { public static void main(String[] args) { print30Questions(); } private static void print30Questions() { //说明:打印30道题函数,把接收到的题目字符串按照指定格式输出. for (int i = 0; i < 10; i++) { System.out.print( i+1 ); System.out.print(".&qu

现代软件工程讨论第九章-十七章

第九章 9.5.1  PM们的故事 9.5.2  我是做PM 的料么? 在校学生如何为成为PM做准备 你是否觉得你的长处不在于写代码和debug,而是协调.沟通,让一个团队或组织有效运转起来?你是否喜欢表达,善于和各种专业背景的人沟通?你是否经常思考如何改进生活中点点滴滴的小问题?你会思考这样的问题么:新浪微博.豆瓣.qq.微信都可以社交,它们的定位.产品特性.用户群.解决的需求,有什么不同?你是否对以下领域感兴趣,甚至自己找过相关的书来看:心理学.社会学.组织行为学.统计学.商业模式? 如果你

现代软件工程 第十二章 练习与讨论

1  什么时候开始考虑用户体验? 既然用户体验和用户界面对一个项目这么重要,但是负责这类工作的设计师并不是软件工程师,设计师们什么时候加入进来为好呢? 不同的人有不同的看法. 最先:“你要从用户体验开始,然后反过来寻求技术的解决方案”.[i] 最后:代码写得差不多了,请设计师(或者美工)来美化一下,画个图标,对齐一下文字. 你认为应该如何根据项目和用户的类型来决定设计师与工程师的交互方式? 2 个人电脑界面的演变 参考下面这个网页和其他资料,练习自己使用软件的经历,讨论个人电脑界面的演变, 以及

现代软件工程 第十四章 练习与讨论

15.3.1 有些成功人士或公司认为不需要独立的测试角色(Test),你怎么看? 我猜想和踢足球类似,还是那几个原因: 人太牛: 不世出的天才,例如高德纳写书时发现排版软件不好用,就自己写了一个.也没听说他为这个软件项目请了什么独立测试人员.对了,他不读Email,有秘书帮他处理这些事——这也是一种分工! 有些软件工程师是在后台钻研和开发高难度的算法,或者做某种后台的处理工作,这个工作本身的难度较高,测试主要是自己通过工具完成.如果一定要找一个测试人员,这个测试人员的水平要相当高才行,如果水平那

现代软件工程 第十三章 练习与讨论

13.5.2  有错不改 果冻: 微软的产品经过这么多版本的不断完善,应该是把所有问题都搞定,“止于至善”了吧? 阿超: 那也不一定,在非常有名的电子表格软件Excel中,就有这样一个Bug:Excel 的日期计算功能认为1900年是一个闰年,这是不对的,但是它愣是一直没有改正这个错误. 众人: 真的?为什么屡教不改呢? 阿超: 故事是这样的,当时这类电子表格软件的市场领头羊是Lotus 1-2-3这一款软件.它的日期计算功能有一个Bug,就是把1900年当作闰年.这类软件在内部把日期保存为“从

现代软件工程 第十五章 练习与讨论

15.3.0 案例分析 可以看看这两个学生项目的例子,推断出这些团队的血型: STG游戏的跳票(为了完美,推迟了7天,但是7天之后也没有发布……)[leal1] [i] 英语学习软件(说了“明早发布”,但是明早一直没到)[ii] 15.3.1  反动分子阿超 在最后的稳定阶段,阿超不断地把事情推到下一个版本,二柱和果冻都不耐烦了——为什么不拼一下,把所有事情在第一版搞定? 阿超: 有两种做法—— 1. 根据事情的轻重缓急,安排大部分事情在下一个版本做.正因为我们对项目.团队.商业模式有信心,才会

现代软件工程 第七章 练习与讨论

7.7  移山开发方法——比TFS敏捷更精简 几个软件学院的学生来请教阿超,同学们自豪地说,我们要用全套TFS敏捷开发模式开发项目! 真的?阿超不敢相信. 同学: 对!我们要用全5个工作项类型 – 任务.缺陷.场景.风险.服务质量需求. 阿超: 你们有多少实战项目的经验?哦,都没有.这么说这是你们第一个真正的实用项目,我建议你们先忘记这么多工作项类型,把时间花在写代码上好了. 同学: 可是老师要我们上敏捷开发模式呀? 阿超: 当敏捷模式变成强迫,那还能敏捷到哪儿去呢?如果你们非用不可,我建议你们

现代软件工程 第六章 练习与讨论

6.3.1  什么时候适合选择敏捷 我们看了这么多方法论之后,一些同学一定比较困惑,到底选择哪一种开发方法比较好呢? 这在实践中不是难题,有学者还列出了一些简单的问题来帮助人们做决定[i]: 表6-3 问题引出方法 问题 Yes – 偏向传统的瀑布+文档的流程 No –   偏向敏捷流程 1. 项目需要有明确的spec 么? 2. 项目没有明确的用户,也无法联系用户进行沟通 3. 软件系统是大型的么? 4. 软件系统是复杂的么?例如实时系统 5. 软件的生命周期很长么? 6. 你使用比较差的软件