前言：职场如战场，老生常谈却又经久不衰的话题。相关文章业已不知凡几。然而，大道理讲得多，可借鉴的经验不足，欠缺可操作性指导。本文另辟蹊径，以职场情景再现为切入点，剖析来龙去脉，进而总结出言简意赅的操作要领，应对类似场景。希望对大家有所裨益。
情景再现：小张是某软件公司的一名测试工程师，入职一年左右。今天主管交给小张一个任务，对开发部刚刚调试完毕的一个功能模块进行测试，时间为期一周。看着主管的任务邮件，小张犯了难，这个模块之前没接触过，该测哪些，怎么测心里着实没谱，想不出个所以然，小张决定去请示主管。“老大，您看这个模块应该怎么测呀？”小张略带迷茫地问道。“怎么测？这个问题不应该是我告诉你，应该是你告诉我才对呀。回去想想该怎么测，拿出测试方案给我。具体问题和开发多沟通。”“呃。。”就这样，小张有些委屈地回到工位。“怎么会这样嘛，没告诉我咋搞，还挨顿批，主管不是应该指导手下做事吗？到底哪里出问题了呢？”
情景分析：可怜的小张到底哪里做的有问题呢？简单的说，小张犯了两个错误：第一，技术问题不该求助主管。主管擅长的是管理和决策，即便他精通业务，他也不会乐意告诉你怎么做，那不是他的职责范围。事实上，领导还会这样想：小子，还想让我手把手教你呀？那我要你何用？我自己搞定得了。试想，这样的情况下，小张能不碰钉子吗？第二，提问前未做准备工作。正如主管后半句所说，小张应该先去尝试整理工作方案，了解任务执行的难点，识别出任务目标达成的风险，需要的求助等等，拿着方案去找主管审阅，主管自然就会做出协调人力，延长时间，或者缩减任务量之类的措施帮你达成目标了。请谨记，领导喜欢的是拍板来解决问题，而不是分析来解决问题，分析工作是身为小弟的你该做的。
应对攻略：基于前文分析，小张正确的做法如下，第一步，找开发获取模块资料，仔细研读，理解模块功能、应用场景、实现细节等，然后拉上开发进行讨论，印证自己的理解；第二步，整理方案，给出要做的工作内容，具体工作量，难点和风险等；第三步，拉上团队内的骨干员工评审方案，将其意见和建议丰富到方案中；第四步，拿着方案请主管审阅，明确提出自己的诉求和风险，比如需要哪些部门的人力支撑，需要哪些设备资源，任务达成的时间是否足够，和手头工作是否冲突等等；第五步，方案获得主管审阅通过，所提诉求获得满足后，就进入任务实施阶段了，按计划执行，及时发进展汇报。
以上是基于软件测试员工请示工作的情景加以分析，其它职位的类似情景应对攻略大体相同，工作任务内容稍作置换即可。请示工作的攻略分析完毕，希望对大家有所帮助。下一节将针对本文末尾提到的工作汇报加以分析，敬请期待。
