真正的难题

做工程的时候,

我们经常遇到难以解决的问题。


变化的需求,

无法界定的范围,

艰难的估算,

高昂的成本,

等等。


这是软件项目的困难,

看来与我们无关。


然而,仔细反思一下,就会发现,

这些恶魔其实是我们自己引来的


退一步海阔天空。


需求通常是不变的

我们经常听到有人抱怨,

客户的需求又变了


然而,是否问过自己,

需求真的变了吗?


客户今天想要这个,明天想要那个,

归根结底,他们只是需要一个能解决问题的软件


不能解决问题的软件毫无价值。

正如,不能吃的东西无法充饥一样。


找到他们的核心需要,

才能有的放矢。


以性价比最高的方式

填饱他们的“肚子”。


软件是解决问题的辅助工具

每一次和客户沟通,

他们想要的东西都不一样。

于是,我们就认为这是需求变更了。


可是,我们可曾想过,

客户说的是准确的需求吗?

或者只是对解决方案的描述


对于一个确定的想法,

人们尚且有不同的阐述方式。

更何况,软件是帮助客户构建一个新的方案


所以,

我们要协助客户,共同努力,

软件只是帮助我们解决问题的工具。


预算决定了产品

如果无偿获取,

那么当然是越多越好。


生活会有目标,

正是因为我们要考虑成本。


在同样的时间内,

功能点的数量和质量是不能同时满足的,

天下没有免费的午餐。


因此,

讨论之前如果不弄清楚代价,

需求范围就只能无限的扩大。


不要怪别人需要太多,

只怪让别人以为我们代价很小。


乘积悖论与交付时间

一个人在10个月能完成的事情,

10个人未必在一个月就能完成。


人们经常拿建筑来类比软件,

是进入误区的一种原因,

因为盖房子很难体现出问题组成部分之间的依赖性


一个人在10个月能砌好的围墙,

25920000(=10*30*24*3600)个人一秒钟也做不完。


因为,

砌墙问题无法拆分成25920000个独立的组成部分


能否切分成独立的部分,

让多个人并行工作

这是问题本身的内在属性。


不是所有的事情,

都可以让人们协同完成。


因此,到达一个界限之后,再多的人,

也无法将软件交付时间缩短。


软件开发的主要内容

我们经常要求评估,

一项工作需要多久可以做完。

这是没有办法计算的。


因为,只有重复性质的工作,

才可以准确评估。


而软件必然是全新的,

软件的本质就是处理重复。


怎样把实际问题,转换为一个已经解决的问题,

这是程序员日常的工作内容,

这个转换时间,就是开发时间


已经处理过的问题,

好的程序员已经把它做成了自动化方案

占比最大的还是那些未知的问题


对未知的事物进行评估,

这只能算是预言


不要浪费资源

事实上,产品的功能不是全部

它可能只占了很小一部分。


软件更多的是,

沟通,文档,学习,

工具,项目管理,培训,

售后支持,维护,推广,等等。


做好它们,也是需要时间的,

甚至,有些问题同样需要编程解决


如果只让程序员做产品功能,

这其实是很大的一种浪费。


应该用他们的能力,

为整个团队加速


结语

软件工程的问题,

更多是因为我们自己的错误产生的。


项目的参与者,

只有加深对软件的理解

才能解决问题。


客户是需要培训的,

那么何不先培训自己