需求工作反思I

背景：排课系统会议讨论出勤率问题时。

出勤率：真实业务中是每个课程单元的出勤率，但是没有统计数据。此处要求提供模块级别的出勤率就可以了。佳哥提议，不再有此部分内容的输入位置，首次使用的历史数据，直接加入数据库内容。

• [popexizhi]嘻嘻，交流现场pope激动了，因为至少到现在觋祉认为这个还是要有用户接口的，否则如何从用户那里要到对应的数据呢？这个可能是pope激动的原因所在。 （如果当事人可以看到这篇问题，先说句sorry，当时不够冷静了！：>）但是从需求的功能上划分，这个工作是设计人员的职责范围，不是需求的，不是吗？这个决定设计人员有权处理。并且你的理由如果只是基础数据的话，这个是可以解决的。现在想来补充唯一可以说的，就是历史数据如果不准确这里提供用户接口可以方便修改，不用直接操作数据库。别的没有了，但是不打算再用这里理由说服谁了。这件事上觋祉要带走的经验如下：
  （一）工作时再次明确自己的职责范围，不要因为可能涉及到的困难或好处去做决定。而是你的工作范围第一，ok？需求和测试工作都是如此。不要越俎代庖！记着随时提醒自己啊！
  （二）评论不是不可以做，但是这个工作是居于分析信息和推理内容，不是情绪。根据你的这个疑问，你可以深入分析可能的问题，以及预测走向。但这个只是用来锻炼自己的分析能力的，不是说服他人的工具。：）看来这个是自己下面要做的了。
  [doing]分析这样设计的结果和发展（好处是什么？如果有问题会是什么？）