Archive For 九月, 2010
以下内容整理自一封我发出来的内部交流邮件，略去一些内部信息 最近对项目进展缓慢我个人觉得有两个原因。 1、 开发组的技术能力 可能还真的没达到可以实施敏捷的水平，或者是没能达到很好的发挥敏捷益处的水平。 2、 咱们目前三个组的配合上和衔接上也有一些不协调的地方。 目前对于第一点，我觉得暂时没啥好的解决方案，只能不断的提高大家的技能水平。 但是对于第二点我倒是有些想法。就是对原来我们做的那个领完任务然后开始给设计讲解对需求或者设计的理解来扩充一下。 我觉得要强迫大家多思考，然后再开始做，思考的过程中需要包括对风险的评估、对自己业务范围内编码设计的评估，那怎么来强迫呢，最简单的就是将给别人听，给别人讲明白了。本来我们就需要大家都来理解业务，来挑战设计，以便以后能将设计降到每个小team里。 因为每个sprint都需要来分组，我就想在原来讲个我听的过程稍微扩充一下，讲的过程中带上一些实现的思路，让另外一个组也听听。这样至少两个组都能了解业务，对他自己遇到同样或者类似的场景，可能借鉴或者参考对方组的思考方式。但是昨天跟@P讨论时候又有一些新的想法。就是在两个组互讲的基础上，再往外扩张下。将测试和框架拉进来。
最近不在客户现场，很多时候都是电话或者邮件跟客户沟通，发现了一些比较有意思的现象 距离带来的效率 一般我们都会安排一些时间到客户的office或者会议室讨论一些大的需求。在预计的时间内，很难达到想要的结果，往往会超时，效果一般还不理想。而当我通过电话或者邮件来确认一些问题的时候，往往会更高效，甚至更发现问题。 好像非面对面的沟通反而效率更高了，后来我想想可能是大家在非面对面的情况下有更多地空间和时间来做思考，然后决策需要那种结果。 选择题 有的时候客户要实现某些个业务需求，但是往往又不清楚自己到底要一个什么具体的实现方式，我们就会试着给客户设计几种解决方案。然后我们挨个给客户讲解这些解决方案，客户往往会按照我提出的顺序，选择在中间（如果只有两个选项，一般会选择最后一个）给他介绍的一个解决方案。 晚上google了一番，发现 心理学 里好像有专门讲这个的东西，周末再看看吧