创业不易，我也无意泼冷水。
至于拒绝缺陷，tapd 的处理方式是这样：

支持根据解决方法检索或统计缺陷。
中间还有哪些想抽取出来拆成不同的状态呢？
新改的那张图上还是有很明显的 bug，为了产品形象建议再看看。
最后的建议是想清楚到底是管理敏捷开发过程还是只管测试，目标用户是哪一类，他们的痛点在哪，现在定义的流程适合他们吗。

感觉你的回复暴露了更多的测试管理方面的问题，缺陷常见状态就下面这些，目前看足够覆盖所有的业务场景。

已改未确认跟已修复或者已解决有什么区别？非错未确认跟已拒绝又有什么区别？
换个表述意味着客户得重新接受一次概念，这里的风险产品经理要不要考虑？
已改/同步到测试环境这状态是想解决什么问题，测试工作产出不是针对指定版本、指定环境吗，这样是不是带来测试管理的混乱。
最后说下那张图的毛病，
1、测试任务与项目测试是通过什么维度并列展示在一起的
2、项目研发下面为什么放的是测试任务
3、如果说每一栏最上面一行想表示项目生命周期的各个阶段，缺陷跟踪怎么又和测试执行并列了
4、需求部分为什么不在敏捷测试的测试迭代里
5、需求管理下面怎么列的是维护测试模块？

1、作为产品不在细分市场寻求突破，追求全面，就有可能因为某一项赶不上别家而被全盘放弃。
2、太多的度量指标，给人的感觉是产品方自己在测试领域没有沉淀，所以就把能透出的指标都透出来，让用户自己进行选择。
3、某些概念没有采用通用标准来描述，比如缺陷状态的已改未确认，非错未确认，不太明白开发者是不知道怎么描述还是刻意寻求差异化。
4、敏捷测试管理那张图逻辑性也有待商榷，参考https://www.cnblogs.com/linkxu1989/p/6673087.html，不是说老外总结得就一定好，但现有的这张图说服不了我个人。

看看是不是请求头的设置导致返回内容不一致了

只要业务还在，你留下就是老大

吾之美食,汝之鸩毒

挺有意思，先试用下

如果研发团队已经很牛逼了，就根据团队安排的来做
如果研发团队不行，你很牛逼就搭框架，定流程，定标准，卡准入准出
如果研发团队不行，你也不太会就忘了这事

感谢分享，顺便挑个刺，

8 小时了没人回，非特殊性的问题百度，google 一下不是快得多么