标签：
LJ
实际的测试项目，做起来才是头疼
咱们的工具能不能在实际的项目里减轻测试人员的工作量，才是问题的关键
怎么体现工具的价值啊
LJ
我跟你说我的两个观点：
第一，作为产品，需求设计是第一位的，功能不好，没办法让人用。
第二，作为公司的管理人员，应该使用的是结果导向的方法
LJ
对下属的要求，应该是具体明确的,可度量的
LJ
这个观点供你参考吧
STST
嗯,非常好
STST
有一个问题需要明白:
这个项目是创新型的,意味着不会有太多的借鉴,也不会有明确的需求,一切要靠我们自己去思考,需要的是大家一起发挥主观能动性,主动去思考,而不是被动地等待任务,软件项目的特点和其他行业的特点是有巨大差别的,软件项目的困难在于要整理明白"要做什么",而"如何去做"绝大部分情况下都很简单,和其他的行业比如建筑行业,正好相反,建筑行业要明白"做什么"很简单,困难经常在于"如何去做"。
STST
软件项目不可能象建筑行业那样,把问题细分到很细的粒度,然后分配给各个工人去做,这是这么多年来软件工程发展总结出来的最大的经验,所以软件工程师千万不要像建筑工人一样去思考,去等待,这对己对公都是一种伤害
STST
在每个模块做出来给大家使用之前,我也不知道需求是什么,可能只是知道一两个名词,有可能去把问题"分析"全面了再去实施吗?这是绝对不可行的,不把这最初的一两个名词所代表的概念实现,大家就没有一个讨论的基础,这就是"迭代",或者叫"敏捷",这是这么多年的软件工程发展的精髓
STST
所以,请大家思考,而不是等待任务,大家做完了的每一项任务,我敢说都不理想,包括我自己的所做了的所有任务,所以需要不断地去雕琢(软件工程里叫重构),只有在持续的雕琢过程中,你才能明白所面临的问题的真正含义,也许这些话显得有些空洞,但是是我的切身体会
标签：
原文地址：http://www.cnblogs.com/stst/p/4904620.html
