j****s
发帖数: 271 | 1 1。既然是要转到商业化上，就应遵循业界规范
技术维护要全部文档化，要有相关的bug report/request form,
problem analysis form, solution form, programming spec,
unit test report, 以供存档检阅，即使开发队伍换人也可以通过
文档实现有效过渡，维持队伍的伸缩性
haha,偶可以来管QMS
2。绝不可以搞唯技术论，通常懂技术的高手总希望用的技术
越牛越新越变态越好，其实不然，适应需求又省钱便于日后维
护的技术才最好，咱这就算是提个醒吧，呵呵 | t****a
发帖数: 554 | 2 1。既然是要转到商业化上，就应遵循业界规范
技术维护要全部文档化，要有相关的bug report/request form,
problem analysis form, solution form, programming spec,
unit test report, 以供存档检阅，即使开发队伍换人也可以通过
文档实现有效过渡，维持队伍的伸缩性
haha,偶可以来管QMS
2。绝不可以搞唯技术论，通常懂技术的高手总希望用的技术
越牛越新越变态越好，其实不然，适应需求又省钱便于日后维
护的技术才最好，咱这就算是提个醒吧，呵呵
这是最开始的原文，第二条我非常赞同，engineer最容易犯的
毛病就是盲目追求技术。都是聪明人，稍微警醒点就不会出问题了
第一条就是前面我说反对的。
不要PM/TM签字是不可能的，这个签字体系也是QMS的一部分
并不意味着低效率。组织结构的design当然也是QMS团队设计的
重要部分，而且相当重要。
此外，从后面的解释我明白了你的目的是3k现在负责的那部分
的规范化问题，这个3k自己也提到他注意到了。
可是我看到你提到一大堆analysis,spec.rep
【在 j****s 的大作中提到】
: 1。既然是要转到商业化上，就应遵循业界规范
: 技术维护要全部文档化，要有相关的bug report/request form,
: problem analysis form, solution form, programming spec,
: unit test report, 以供存档检阅，即使开发队伍换人也可以通过
: 文档实现有效过渡，维持队伍的伸缩性
: haha,偶可以来管QMS
: 2。绝不可以搞唯技术论，通常懂技术的高手总希望用的技术
: 越牛越新越变态越好，其实不然，适应需求又省钱便于日后维
: 护的技术才最好，咱这就算是提个醒吧，呵呵
|
|
