现在,我正在意识到,在我目前的位置上,我没有定期完成请求,而是间隔了请求的完成。但是为了接近我真正的能力,我想在一天的过程中尝试,为了我的第一次尝试,在一个工作日(8小时)内推出3次中等大小的提交。
平心而论,我使用的是普通PHP、MySQL和甲骨文,除了jQuery之外没有其他框架。而且目前我花了足够的研究时间,我可以磨练。
一次提交对应于通过电子邮件接收到的支持请求,有些请求尚未完成,但尚未准备好提交。现在,我正在包括未提交的已完成的支持请求,这些请求将首先被推送过去。
I向这里的社区征求关于我的过程在最长2小时内的总体有效性的反馈,并提供了上述信息
提高工作效率的Proposed解决方案(如果我每一步花费10分钟以上的时间,没有任何进展)请立即通过电子邮件与经理或请求者核对。
Preparatory用于我确定的步骤的处理过程,首先指定的项目点是
在收件箱和电子邮件回传日志中确定4个支持请求以解决,考虑优先级和完成时间。与经理或请求者检查整个过程。
对每一项支助请求
10分钟 0)读一两次电子邮件,然后用我自己的话写问题。打开目标请求的网页以验证遇到的问题。写下第一步所需的问题和澄清.
5分钟
5分钟
5分钟
5分钟
10分钟 6)编写伪代码并绘制流程图(分别为半页、一页)
10分钟 7)写出特定语言的代码行(主要是PHP和SQL),以与步骤5相匹配
30分钟
10分钟
发布于 2021-01-04 13:54:14
创建一个解决问题的标准时间框架似乎是个好主意,直到一个问题不能很好地融入时间框架。我的经验是,你不能预测这类事情。在您建议的工作流中,唯一看起来有风险的是您期望花费的时间。
每个工作要求,无论是增强还是缺陷,都将贯穿每一步。每个步骤和所有步骤总共花费的时间将取决于工作请求的范围和难度。
在讨论这个问题之前,先找出是否有一个Service级别协议()适用于这个应用程序,并以此作为指导。如果不存在这样的协议,那么如果你愿意的话,你就可以定义一个。
真正的问题是,你的用户对他们得到的服务水平不满意吗?
如果他们是快乐的,那么你可以保持这些步骤和时间框架的隐私。设定崇高的目标并努力实现这些目标是没有错的。
如果用户对服务水平不满意,那就联系你的客户。与他们会面,看看他们的期望是什么,以及你是否能满足他们。不要把所有的负担都推到你的肩上,而是看看把代码带到生产中的更广泛的过程。减速可能在你无法控制的范围内发生。你只能写代码和点击按钮如此之快。找出取得进展的其他障碍,并努力解决这些问题。
发布于 2021-01-04 16:20:26
处理支持请求的方法似乎是very结构化的(有些人会说是僵化的)。这可能是一个很好的指导,或者至少是一个清单,以确保没有忘记任何东西。但假想的时机从何而来呢?这只是直觉吗?你刚才在一些简单的问题上尝试了你的方法吗?因此,在设定任何时间目标之前,开始收集数据:收集在一组有代表性的支持请求上花费的时间。
如果你对科学管理方法很在行(泰勒在1911年提出了这一建议,并在IT领域引领着瀑布式的方法--同时也知道它只能在非常罕见和特定的情况下起作用),那么你就会把测量的平均值作为一个目标。如果有人有的不幸得到一个真正复杂的请求并成功地解决它,那么您可能会指责他/她不尊重SLA,而不是祝贺他/她所做的出色工作。你要去这里吗?
但是,有了更多的统计知识,您就会发现平均值是没有意义的:一个小的软件错误很容易解决。但是,如果这是一个基于某些特定输入的事件,再加上一些峰值时间网络条件和复杂的计算,可能需要更长的时间才能计算出来!因此,您可以按照复杂度级别(低、中和高)设置请求,为每个类别设置不同的假设时间,而不为高复杂性设置时间(如果您正在准备SLA契约关系,那么您应该预见到需要提供高复杂性的证据)。
最后,不要微观管理。只为较大的块定义时间,以消除每个详细任务的波动。不要忘记,分辨率可能还需要迭代步骤(越复杂,迭代越多)。
https://softwareengineering.stackexchange.com/questions/420630
复制相似问题