iamsujie的评论(17)

1。作者阅读量真的很大； 2。内容还是适合大公司； 3。只说了要“做什么”，“为什么”和“怎么做”说的不多； 4。摘录的各种案例、文章、书籍的内容略显过多； 5。感觉飘在天上，兵法的比喻有些生硬。 ……...... (3回应)

提示：评论里有关键情节透露

> 没关系，可以显示全文。

前段时间把交互设计之父Alan Cooper大爷（此牛也是VB之父）的《About Face 3.0》中译版《软件观念革命：交互设计精髓》翻完了，发现自己对交互设计的“术”兴趣不浓，所以还是留给更专业的交互设计师去研究吧，自己只记了如下一点点笔记： 知识体系的4P，这个总结的很通用，可以映射到很多事情上，赞： Ø Process，过程，整个设计的过程。我的理解，比如一些常用的流程。 Ø Pattern，模式，一些解决问题的方法论。比如用户研究。 Ø Principles，原则，一些习惯用法的规则。比如“不要让用户思考”。 Ø Practices，实践，把上述3个理论具体化，找到所在产品、团队的较优实践，每次都会不一样。此外还有与产品有关的周边团队的影响，不要让非核心的失误坏了大事。 产品的三个模型： Ø 现实模型，描述产品是怎样...... (1回应)

我们整天在说话，其中很大一部分都是逻辑学意义上的“论辩”，可是论辩到底有哪些规则，我们又习以为常的犯着哪些错误，有多少人想过？前段时间弄了本《逻辑学基础教程》翻了翻，发现其中对于论辩的章节说的还是比较清晰的，笔记如下。 这里没法标重点，原文在 http://iamsujie.com/simple_life/logical-argue-9-ruleslogical-argue-9-rules/，欢迎大家来讨论相关话题 论辩是一种说服型对话或批判性讨论，通常有>=2方参与，以意见分歧作为起点，目的是通过理性的方式来消除分歧，作为一种典型的对话，其表现形式为语言行为交流序列。通常有9条规则论辩规则。 1. 自由规则：论辩双方不得阻止对方提出立场，或者阻止对方质疑立场。  谬误：限制对方提出立场或质疑，宣称某些立场是神圣不可侵犯的或不容置疑的，宣称立场是一种禁忌  如：“你居...... (10回应)

这篇其实是《别做正常的傻瓜》第九章的读书笔记与感想。题目是：你想让朋友和员工更开心么——赠送礼物和激励员工的艺术。“道”的东西，我很怕自己理解成“术”，希望大家也不要误解如下九条。 原文在 http://iamsujie.com/5000/5007/，欢迎大家来讨论相关话题，：） 大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条400块的围巾效果好于送一件500块的衣服，我们应该尽量找一些高级的小玩意。 有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的奖杯，刻上他的名字，千万不要是几瓶酒这种，能喝掉、能送掉。 需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒...... (6回应)

看完之后对产品经理有了更全面的理解，正如Product Manager是从宝洁的品牌经理发展而来的一样，还有很多工作是PD平时接触不多的，因为公司里有专门的运营、PR、市场、销售团队会做相应的工作。不过2008年手上的产品没有专门的运营团队，而且又加入了销售团队的邮件组，正好给了我接触相应领域的机会，列几个还记得东西吧。 包装：对互联网产品来说，我的理解就是产品的portal、登录页面等，这块是给用户的第一感觉，重要性不言而喻。 （iamsujie补：2008年下半年开始，我们发现互联网的软件如果通过渠道卖的话，也有必要搞一个实体的包装，不然用户花了几千块钱，你只给他一串数字（登录帐号），实在有点说不过去） 定价：有很多种理论方法，比如成本导向、需求导向、竞争导向等等，似乎还有种更常用的，就是：老板开会讨论法，=,=。 促销：“广告”和“公关”（“臭名昭着”的PR，...... (1回应)

产品与对应的市场/用户都是有生命周期的，最佳状态就是彼此之间完美的配合。结合一个自己做过的产品，从起步到进入成熟期和衰退期，说说从头到尾的过程与体会。主体思路结合了《跨越鸿沟》一书，可惜还没有看过（作者Moore的另外一本《公司进化论》好像更有名一些，很巧是浙大的陈劲老师翻译的，读过，思路很清晰），它说了“生命周期”轴线上用户群体的五个细分，以及相应的产品特点： 原文在 http://iamsujie.com/7000/7013/，欢迎大家来讨论类似话题 Ø 创新者：新鲜感强，消费能力强，但是忠诚度不高，需要新鲜的东西不断刺激。这批人都有Geeker气质，乐于探索，这一点与产品设计人员比较像，所以做这种产品会让设计师比较兴奋，产品可以做的偏向“专家用户”，但长期商业利益无法保证。 Ø 早期追随者：观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品。他们是信息......

贴不了图，原文在 http://iamsujie.com/7000/7011/，欢迎大家来探讨相关话题 人治–>法治–>德治（无为而治），大公司多为第二种：法治。1和3外表很像，区别在于1无法，而3的法在每个人的心中而非纸上。这是产品和团队发展的必经阶段，我们的现状就是“1–>2”，开始规范化，正好有同学原来熟悉UML，所以大家也都开始学习一下。 UML就是统一建模语言，它试图将软件工程的过程给规范化，从产品设计的角度，我对它的简单理解就是用一系列的标准图把需求分析的过程串起来，充分体现了“字不如表，表不如图”的原则，我以单个用例的粒度为界，把相关的图为两个层面。 上层的图中，用例是最小单位，不涉及用例内部，主要有： Ø 类图：感觉有点像实体关系图（ERD，更接近现实世界的对象，类图更接近技术实现的对象），描述系统中出现的各个对象之间的关系，以及和外部系统的关系。这......

2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。 瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是不错的。 敏捷迭代开发，如果断章取义是极其危险的，比如没有迭代的测试跟上，到最后发现问题的时候就已经晚了。 介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下： Ø 拥抱变化，大......

前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。 原文在 http://iamsujie.com/7000/7009/，欢迎大家来探讨相关话题 Ø 敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。 Ø 项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。 Ø......