这一天终于来了。不管你是第一天工作还是已经工作10几年了,都无所谓。总有一天会有那么一个任务,让你连理解都理解不了。
那么这个时候你会怎么办呢?硬着头皮做,祈祷能成功?还是立刻告诉你的老大你做不了,因为你理解不了这个任务?
我想你知道,哪个都不对。
我发现,在编程工作以及其它任何工作中,如果一个星期(有时甚至是一天)都没有遇到让你理解不了的任务,那几乎是不可能的。
不过不用愁!好消息是你不仅能解决这个问题,而且它还可能是个好事。
这意味着你正以某种方式拓展你的知识和技能。
接下来,我将具体讲讲怎么把完成任务所需要的知识和任务要求联系起来。
你可能已经注意到我使用的词是“需求”,它的具体含义取决于你所处的工作环境。
经验而言,大公司喜欢提出需求,而小公司有时“不做需求”。我认为,这两种情况都非常符合我们的目的。
这是因为,作为软件工程师,我们所做的一切终归都是为了解决问题。
你会收到一份上百页的报告阐述如何解决问题(我曾经参加过的某个会议,花了一个小时来讨论按钮的文本)。也有可能是你的 CEO 轻轻地走到你的工位旁,问你能否在周五前把这个问题解决掉。
不管哪种方式,你都得到了一个任务。你得确定自己完全解理了问题,这样才可能正确的解决这个问题!
并非每个问题都需要用到下面所给出的步骤。只有最难理解的问题可能需要您仔细执行本文中将要讨论的所有步骤。
许多问题可能无法通过您提出来的需求或仅通过您的个人经验来回答。
您可能需要询问其他开发人员,您的团队负责人,产品负责人,业务分析师甚至您的祖母。 也许你必须在完成时问问所有人!
那很好。 这意味着你将利用众人的想法并将其凝聚在一起。 凝聚出的产物取决你自己,现在你将能够产生最好的结果!
在你了解步骤之前的最后警告:不要过度正式化此过程。 这里的重点是帮助您快速了解问题。 它不应该制造障碍或繁文缛节! 相反,它应该为您提供详尽的计划来解决您不理解的问题。
第一步:任务分析
在这个步骤,你要争取理解被要求做的任务是什么,而不用试图去判断怎么做。
两者的区别是很重要的。没有思考全部后果就直接跳到执行步骤,甚至还是在被要求任务没有准确认识的情况,是很危险的。
任务分类
将任务分类,意味着确定你为解决问题所做的,是属于哪种工作类别。任务分类例举如下:
错误修复
新功能
新应用
研究任务
性能优化
请记住上述例子不是全部的可选项。
分类的目的是确定你将要做的工作属于哪种类别。这会直接影响到你所做的工作是什么,所以很重要。
这一步骤对于模糊的需求尤为重要。举个需求模糊的例子:“网站更新后,我们需要一种方法来清空客户缓存”。
可能存在几种解释。
您需要立即实施一些缓存清除机制,以便客户端始终可以看到最新的更新。
您需要研究存储客户端缓存的所有方法,并确定在每次更新网站后破坏这些缓存的最佳方法。
客户端的缓存已经被清除,您需要找到并修复阻止它们清除的错误。
此时,如果您不完全确定使用了哪种含义,则应在继续之前要求澄清。
概述一下复杂的要求,就好似你被问到你今天在做什么一样。也许它不会那么简单,但你应该把它凝练至一两句话。
如果您无法概述任务,则可能意味着您需要将其拆分为多个任务。因此本质上这一步将成为一个试金石,以确定您是否已将任务组织成足够小的块。
关于摘要有一个很好的例子:“当我们更新网站时,我们会在文件中附加一个唯一的编号,以便浏览器知道它需要使用最新的代码。”
此任务通过简单的试金石,您可能不需要创建多项任务了。
评论删除后,数据将无法恢复
评论(9)