《软件创新之路》的随手笔记——欢迎指正

[zhuma]

1．当电脑与行业结合时，我们应该注意的是行业，其次才是电脑。决不能为了所谓发掘电脑的强大，而任意放纵个人花哨的技巧。
2．应尽一切能力放弃那些复杂的、并非必须的功能。避免令人不快的行为和模糊晦涩的交互。
3．软件的目标并不仅仅是无可挑剔、精确的工作。
4．我们的电脑化工具实在是太难用了。
5．我们关注的应该是用户看到的方式，以及与软件产品交互的方式。
6．认识的摩擦。“超越”状态。
7．软件设计分两部分：交互设计、程序设计（不是编码）
8．交互不是与设计者的交互（这一点谁都知道），而是与角色的交互。
9．概念->行为->界面。
10．跳舞的熊。奇迹并不在于熊跳得好坏，而在于熊一直在跳。
11．电脑文化。贬义词。
12．仅凭“电脑强力用户”、“电脑文化用户”、“电脑文盲用户”三个概念是无法区分用户的，强有力的工具是“角色”。
13．只有功能表是不完整的。“攒”功能并不能准确描述产品设计。
14．帕金森定律(Parkingson’s Law)：工作将填满分配给他的时间。
15．推迟交货并无危害（说易行难）。
16．不可预测的后果是重复。
17．原型成为产品的危险。
18．“用户友好”只是心虚及不负责任的托词。
19．时间、项目、资源。
20．Web程序不需安装的优点掩盖了一般程序也有完全不可见的安装的可能（暂时不理解）。
21．实际能力、生存能力、期望能力。期望≠需要。
22．程序员对软件的控制力太强。
23．设计的强有力工具：精确描述我们的用户（角色）以及用户（角色）希望达到的目标.
24．角色不是“弹性用户”。精确定义（大量的细节定义），而不是准确定义。
25．用户不是买方。付钱的人和使用的人是有区别的。
26．任务不是目标。任务是手段，是过程，是可变的；目标是稳定的。
27．个人目标、公司目标、实际目标、虚假目标。
28．软件的彬彬有礼，即人性化。
29．10%，80%，10%；永久的中间程度。
30．你的界面不管如何酷，它要少些才会好些。
31．设计先于编程（地球人都知道）；在编程前测试（参见XP敏捷方法）。
32．程序员不适合做设计，因为他是“逻辑人”。
33．可视设计师不是交互设计师。
34．顾客驱动是危险的。概念的完整性是核心能力。（比较有意思的观点。在“服务第一”的时代背景下，作为内在创新的软件企业也被卷了进去，到底要不要自己的独立的视野。毕竟Apple的半死不活…）
35．设计文档是重要的。

[zzycad]

但我觉得书中对如何塑造“角色”并没有详细的描述，怎样定义一个“角色”？比如SONY的那个例子，他们构造了多个对象，是如何构造他们的“精确定义”，又如何取舍？

欢迎与我讨论 [e-mail]

[zhuma]

我觉得定义“角色”的过程
应该就是对需求不断深入的了解的过程
即找到用户真正需要的“目标”
然后把“目标”放进“角色”的背景描述中
这样不断细节化
慢慢的
一个活生生的“角色”就诞生了

写到这里
我不禁又迷惑了

“角色”的构造是为了明确需求而产生的
他应诞生在需求定义之前

但按我的理解
需求定义反而在前了

难道是迭代法？
糊涂中。。。

欢迎讨论

[superhasty]

该书籍阅读状态中...

[scalene]

迭代啊迭代。
没有“需求定义”这种说法。只有“需求调研”和“需求分析”。需求分析是一个过程而非一蹴而就的。所以分析-〉细化-〉反向分析-〉修改-〉细化-〉...的过程是非常正常的。如果需求发生变动，角色的定义也有可能发生变化，这当然是不足为奇的。
需求过程和程序员的一贯思路是不同的，是和用户交流，以及定义问题的过程。不要把自己的思维局限在编程状态里了。

[playstoneboy]

我觉得书中说的程序员是逻辑人的观点基本说出了那些注重代码的程序员的通病和不良倾向，面向应用的软件开发人员应该更加面向业务，而不是面向技术。
书中关于角色的观点不错，角色要精确定义，并要从实际用户中抽象出来。举的几个例子不错。
关于程序员不适合做设计的观点基本正确，长期的编码已经使程序员的思维有点定型，他们习惯用实现的思路“怎么做”思维，而不是分析“做什么”。

[zhuma]

to scalene(南瓜汤)
for ***没有“需求定义”这种说法***

程序员10月期《谈应用软件开发与建模方法》一文中提到：
（在“需求是焦点”一节）
1。企业信息化的核心目的...的前提是将业务过程明确和稳定的被定义。
2。对于大多数企业来讲，在应用软件的开发过程中需要首先进行的不是需求的分析，而是需求的定义。
3。通过需求的定义阶段要给出一个《需求及规格说明书》
4。应用软件的开发需要需求定义，因为它是企业过程改进的重要步骤

[scalene]

呵呵，不想和你争这个名词问题，我想我要说的大家都明白。
我只是根据自己的实践经验，怀疑“定义”这种说法在需求阶段是否成立？作为一个程序员式的思维模式，认为需求阶段一切都以定义完整，我只要按部就班地按照需求“定义”和设计去写代码就可以了。这样的程序员，有用吗？

[zhuma]

其实我都说了迭代了

把需求定义当作每一次迭代后的里程碑
向目标的一次逼近
哪里有毕其功于一役的事情呀

我也一向不看重名词的
引用或生造一个概念只不过是为了表达方便而已

不要求全责备吧
嘻嘻

不过我的上述引述也的确生硬了
有拉虎皮之嫌
致歉

最后
仍然感谢 scalene(南瓜汤) 学长的批评
希望您能继续对我的不当之处提出指正
谢谢

另：
欢迎大家继续讨论
呵呵

[scalene]

总结的很好啊，都是一些程序员式的思维容易犯的错误。“跳舞的熊”是什么意思？呵呵，我想知道。

[arfayr]

你看看书就明白了。

我认为这本书的最大优点在于指出了程序员最容易犯的错误，指出很多时候应该以客户位中心，以未来的用户为中心。

角色就是用户代表的虚拟人物，确定一个角色不是那么容易的，比如银行系统我们定义角色：管理员、操作员、高级操作员，这个并不是他说的角色。他说的角色是一个具体的“人”（属于管理员或者操作员或者高级操作员），那么这个人操作系统的时候有哪些习惯？那些觉得不方便？如何最简洁明了的了解到信息和实现操作？就是说我们必须考虑角色的实际操作水平和应用环境以及这个角色的性格特点等等。对于操作员可以存在熟练的操作员、新的操作员不同的人物，那么必然有不同的应用和操作需求，如何有机的结合考虑这些需求，然后确定的最终交互方案，这样才能得到比较实用受客户欢迎和喜欢的产品。

书中举的那个例子很好很棒

这本书给人耳目一新的感觉，的确应该反复阅读

[arfayr]

书中最重要的观点就是交互设计的重要性，这点的确我们从前没有仔细的考虑过。

[zhuma]

跳舞的熊：
流浪的马戏团中的表演者——熊
作为舞者
熊那笨拙的舞技是无法令人恭维的
但观众
他们只关注熊在不断的舞蹈着
这一点已经让他们满足了

在软件行业中
设计的拙劣随处可见
但用户鉴于系统仍然在平稳的运行着
也就默默的容忍了

也就是说
跳舞的熊就是设计拙劣的软件产品


//凭记忆写的
//不当之处
//望赐教

[scalene]

呵呵，这个比喻真的很到位。我也一直觉得现在大部分的软件产品，在界面设计上都很不成熟。不过要想做好还真很不容易呢。
软件行业还很年轻，还有很长的路要走。有机会拜读一下这部作品。
多谢指教。

[zhuma]

结贴

感谢
zzycad(我想学编程)]
superhasty(鸟儿自空中飞过)
scalene(南瓜汤)
playstoneboy(尘中之尘)
arfayr(阿飞)