Posts Tagged “项目日志”
发现客户有时候会自己骗自己。 最开始，客户主管会计说她需要需要一个财务轧帐功能，需要按月查看应收应付、实收实付、预收预付情况。我们就按照各需求给客户做了轧帐功能。 做完之后给客户现场演示，他们也认同了这个功能，觉得是他们想要的功能。演示完后的第二天这客户的主管会计电话过来沟通。说需要按照不同的业务类型来做轧帐。当时我正在做一些其他功能的设计，只是简单的记录下她的要求。 今天她再次电话联系我，说给我发了个邮件有一个她期望的界面。我当时心想真是个好客户，都直接把UI 给我设计好了。后来一看还真是有那么几分样子，Excel里列举出了他们所有要求。 后来一细看原来他们的要求是前后矛盾的，就预收预付这一块，一开始客户是要求按照她什么时候录入系统来做完实际业务预收预付的时间。可当她自己开始解释自己设计的Excel表的时候发现原来她们还需要一个转凭证的功能，并且按照凭证时间来做轧帐。 这个过程本身很有意思，也让我开始慢慢开始尝到Scrum的甜头。我很庆幸我没有马上去动手设计某些具体的UI或者DB，没有一开始的就埋头很细节的东西，而是等到另外的时间来做一个讨论，而且这个讨论时客户发起的。 觉得这个事儿跟某些大家常说的“生气时不做决定、高兴时不做承诺”很像，不在兴头上胡乱做决策。因为这时候往往会不自觉地屏蔽掉很多的其他信息朝一个死胡同去走。
最近几周一直在试图提高开发效率，让团队能敏捷起来。 首先是试着将一些很大的Story切割，切割成相对较少的、有商业价值的故事。为了这个Boss还采购了很多书，业界比较响亮的《用户故事与敏捷方法》也被买回来了，可惜我自认为没到那个境界，翻译版的读起来特别别扭，看不下去了。找了些其他的资料，参考着小范围内的重写了一些story。 然后根据上几个Sprint的观察，发现沟通是很很多不畅，大家的理解不一致，又开始加强在沟通环节的投入。但实际上效果都不好。 而今天的一次重构，好像让我发现了问题的根源–我们开发本身不够敏捷。现下已经完成的代码里，任何一个修改，都会带来不可预知的灾难。因为我们根本没法在每次交付的时候保证自己完成的东西是否已经满足既定的需求，更别提按照敏捷的思路来进行迭代了。 敏捷本身是要去快速交付，快速完成可以工作的软件。起码交付出来的东西必须可以工作才对。无论如何去剔除故事，捡业务里面相对简单重要的故事来做，需要满足客户的需求这个终极需求不会改变。如果每个故事或者开发的task本身交付出来就无法保证正确性，又何来在其上的调整完善呢。 或许敏捷在task级别或者编码级别对开发者的要求要比瀑布的高，还是我们的team压根就还没上路？
以下内容整理自一封我发出来的内部交流邮件，略去一些内部信息 最近对项目进展缓慢我个人觉得有两个原因。 1、 开发组的技术能力 可能还真的没达到可以实施敏捷的水平，或者是没能达到很好的发挥敏捷益处的水平。 2、 咱们目前三个组的配合上和衔接上也有一些不协调的地方。 目前对于第一点，我觉得暂时没啥好的解决方案，只能不断的提高大家的技能水平。 但是对于第二点我倒是有些想法。就是对原来我们做的那个领完任务然后开始给设计讲解对需求或者设计的理解来扩充一下。 我觉得要强迫大家多思考，然后再开始做，思考的过程中需要包括对风险的评估、对自己业务范围内编码设计的评估，那怎么来强迫呢，最简单的就是将给别人听，给别人讲明白了。本来我们就需要大家都来理解业务，来挑战设计，以便以后能将设计降到每个小team里。 因为每个sprint都需要来分组，我就想在原来讲个我听的过程稍微扩充一下，讲的过程中带上一些实现的思路，让另外一个组也听听。这样至少两个组都能了解业务，对他自己遇到同样或者类似的场景，可能借鉴或者参考对方组的思考方式。但是昨天跟@P讨论时候又有一些新的想法。就是在两个组互讲的基础上，再往外扩张下。将测试和框架拉进来。
最近不在客户现场，很多时候都是电话或者邮件跟客户沟通，发现了一些比较有意思的现象 距离带来的效率 一般我们都会安排一些时间到客户的office或者会议室讨论一些大的需求。在预计的时间内，很难达到想要的结果，往往会超时，效果一般还不理想。而当我通过电话或者邮件来确认一些问题的时候，往往会更高效，甚至更发现问题。 好像非面对面的沟通反而效率更高了，后来我想想可能是大家在非面对面的情况下有更多地空间和时间来做思考，然后决策需要那种结果。 选择题 有的时候客户要实现某些个业务需求，但是往往又不清楚自己到底要一个什么具体的实现方式，我们就会试着给客户设计几种解决方案。然后我们挨个给客户讲解这些解决方案，客户往往会按照我提出的顺序，选择在中间（如果只有两个选项，一般会选择最后一个）给他介绍的一个解决方案。 晚上google了一番，发现 心理学 里好像有专门讲这个的东西，周末再看看吧