需要思考，而不要等待

LJ

实际的测试项目，做起来才是头疼

咱们的工具能不能在实际的项目里减轻测试人员的工作量，才是问题的关键

怎么体现工具的价值啊

LJ

我跟你说我的两个观点：

第一，作为产品，需求设计是第一位的，功能不好，没办法让人用。

第二，作为公司的管理人员，应该使用的是结果导向的方法

LJ

对下属的要求，应该是具体明确的,可度量的
LJ

这个观点供你参考吧

STST

嗯,非常好

STST

有一个问题需要明白:

这个项目是创新型的,意味着不会有太多的借鉴,也不会有明确的需求,一切要靠我们自己去思考,需要的是大家一起发挥主观能动性,主动去思考,而不是被动地等待任务,软件项目的特点和其他行业的特点是有巨大差别的,软件项目的困难在于要整理明白"要做什么",而"如何去做"绝大部分情况下都很简单,和其他的行业比如建筑行业,正好相反,建筑行业要明白"做什么"很简单,困难经常在于"如何去做"。

STST

软件项目不可能象建筑行业那样,把问题细分到很细的粒度,然后分配给各个工人去做,这是这么多年来软件工程发展总结出来的最大的经验,所以软件工程师千万不要像建筑工人一样去思考,去等待,这对己对公都是一种伤害

STST

在每个模块做出来给大家使用之前,我也不知道需求是什么,可能只是知道一两个名词,有可能去把问题"分析"全面了再去实施吗?这是绝对不可行的,不把这最初的一两个名词所代表的概念实现,大家就没有一个讨论的基础,这就是"迭代",或者叫"敏捷",这是这么多年的软件工程发展的精髓

STST

所以,请大家思考,而不是等待任务,大家做完了的每一项任务,我敢说都不理想,包括我自己的所做了的所有任务,所以需要不断地去雕琢(软件工程里叫重构),只有在持续的雕琢过程中,你才能明白所面临的问题的真正含义,也许这些话显得有些空洞,但是是我的切身体会