@yogamaga 这个要看如何界定，站在系统的角度，系统在进入各个状态前都会有相应状态广播给上层业务，是需要上层业务根据这些状态及时处理做相应的资源释放。这里的场景就是我们开发的业务没有考虑到系统的状态切换带来的影响，该问题非该组员的锅，前期需求和场景没有定义这一部分，只是开发跟测试过程中发现的。 其实到底是系统还是业务的锅也不重要，重要的是对待这个问题的态度，单单根据现象就下结论“是系统的问题”我认为太轻率，以至于我后面写了这么一个评价。 唉，当时我不知道这么一句评价可能会伤到组员的自尊。
@NotLongNil 接受批评。但是不存在什么打压不打压，因为转正看的是评分，评分我都给了不错的分数。这里的评价是只有这个流程参与者中的少数几个人能看到，非公开的，而且这个评价压根就没几个人正经会看。所以你可以把这个评价看成更多是“形式主义的”，当然如何理解“有待提升”的性质也是关键，有待提升也不是否定，是希望加强一点。 总之，站在我的角度我可以说我问心无愧，站在他的角度我也可以理解。
@NealB 导师就是快速帮新来的同事熟悉业务和开发流程，公司的日常这些，并非专业领域上的导师。在专业领域上我也压根不配做他导师，该组员十几年的老工程师，之前在前司是资深的专家。 这里不至于是系统的问题，因为我就是做系统的，他可以说是该业务领域的专家。系统上开发该业务的还有其他应用，同一场景下其他应用不会导致系统出问题，因为其他应用有正常处理，而我们自己开发的就没有。 其实这里都扯远了，这个不是核心。
