大家好，我是七月，一名编程爱好者/高级接口测试员（老前端一枚），心血来潮，想跟大家分享一下关于工作安排的个人见解：
程序员这个神秘的群体，i人占据了绝大部分，其余则是由极少数的e人和被迫成为e人的IT管理者们组成。
作为i人程序员来说，相信大家都是相似的，只希望与代码多打交道，而少跟人打交道。但作为打工人来说，程序员除了需要接触同岗位或相似岗位的同学外，至少还需要接触产品经理、项目经理。他们一个告诉你接下来要干什么，一个告诉你啥时候得干完。这里就会衍生出两个问题，需求理解与时间规划。
相信大家对这两点并不陌生，因为它们充斥着你们的KPI表格...良好的需求理解能力和时间规划能力，能使我们更妥善地安排好工作。结合一些个人观点，大致聊聊：
需求理解
需求理解说白了就是听懂人话，排除产品经理表达问题外，更多的是需要我们有独立思考的能力，甚至举一反三的能力。
在开展需求评审会议之前，我们应该提前拿到需求文档、产品原型等等相关的会议资料，这个非常重要，其实有点类似于读书时期老师常说的“预习”。在这个间隙中，我们尽可能先放下手上的工作，去粗略地阅读一下，起码要做到了解这个产品是干什么的？为什么要干？这一期的需求大概要实现到什么程度？初步了解了这一些以后，有经验的同学就可以代入相似的项目经验，自我思考，这类项目一般会存在什么问题，比如项目本身合理性问题、需求合理性问题、用户体验问题、技术实现问题等等。
举个例子，假设现在我拿到了一个电子合同SAAS平台的需求文档和产品原型，当我粗略了解到这个平台的核心内容后，首先，我会思考，电子合同的必要性和合法性（当然，作为程序员来说其实这并不是你该思考的东西，因为可行性分析这些东西在项目立项的时候已经完成了，也就是这其实是产品经理、项目经理甚至上升到PMO的事，但是如果你有这方面的思考，会让你对项目本身了解得更深入，也有助于对接下来不同版本迭代需求理解）；其次，我会思考原型中包含的功能、逻辑是否合理，其中还包含对交互设计的思考，要知道好用的产品也是增加用户黏度的关键点之一；第三，我会关注一下有没有比较复杂或者反人类的设计，从技术层面可行性如何；最后，我可能还会跟后端同事先讨论一下特殊功能点数据交互的问题。这些问题可以是你的内心戏码（好像有点多哈哈哈），但却是非常有必要的，带着疑问去参会，总比带着茫然去参会要来的实际。延伸一个点，工作中的会议都必须要有结果产出，如果花了半个小时、一个小时去讨论，过程可能是激烈的，但如果没有然后，那就是纯浪费时间，即便产出一个双方观点都不成立的结论，那也是一个有成果的会议。
带着疑问去参会，我们首先要听产品经理如何围绕他的文档和原型进行描述，过程中可能你还会产生问题，但也有可能你带去的问题被解答了。这个时候我们需要保持头脑清醒，及时把已解答的疑问给过滤掉。新问题诞生的时候，我们可以先思考为什么之前我觉得没有问题，现在反而有问题了呢？这个问题是个人理解的问题还是产品经理在图文表达上存在问题，如果是文档或原型上表达存在的异议，我们可以建议产品经理进行修改，因为这个问题既然能让你产生误会，那就能让他（泛指项目组其他同学）也产生误会。我们的大脑每天要处理的事情有很多，不一定能把所有的事情都记住，即便今天能记住，难保在一个星期后正式开发这个功能的时候还能记忆犹新，所以有形的记录是最简单直接的。
当你把问题都搞清楚了以后，正式进入开发阶段，这个时候因为每个人看问题的角度不一样，也会出现需求理解的偏差。**不要慌、不要急，直接问产品经理是最实际的。**千万别猜，别模棱两可就接着开发，到头来可能气的是你自己，返工几率极大，不要问我怎么知道的...哈哈哈
除了这些看似流程性的东西以外，还有一些比较靠feel的点：
一、你对产品经理的熟悉程度，就像普通朋友和好兄弟、好闺蜜的差别一样，合作久了或许你们之间会产生一些默契；
二、你的经验赋予你对需求的感觉，通过在码海驰骋的经验，可能有些东西你看一眼就能知道大概是什么内容，八九不离十能理解到位，甚至还能提前预判，在开发过程中预留好拓展点，下次能直接用上；
三、需求分析切入点问题，前段时间我发了一个动态，大致是说“我想实现一个xxx功能，如果让你选用一个nodejs的框架来实现，你会推荐什么呢？”，其实我的言外之意是想调研一下如今的nodejs框架哪个会比较受欢迎。但是总有那么一些人跑过来说，这也用的着上框架？我跟后端打个招呼不就实现了吗？其实就跟别人问你：“我想喝杯可乐，你觉得用纸吸管好还是用塑料吸管好？”你的回答是，“这玩意要用吸管？我直接对瓶吹！”是一样的。理论上是没错，但有没有可能醉翁之意不在酒。适当地发散思维，不要钻牛角尖哦～
时间规划
时间规划是一个比较玄妙的活，你会发现职场中不同岗位的人对工作量、工作时间的定义似乎都不一样。
当你觉得这个模块需要2天去完成的时候，别人会认为需要2天这么久？当你咬咬牙压缩到1天或1.5天时，他又会觉得你在忽悠他。
作为程序员，首先要对自己的工作能力有一定认识，刚入行时可能这个概念是模糊的，那我们可以设定较为宽松的工作时间（一般企业都会给予新人较大的宽容和耐心，所以在时间规划上可以稍微拉长一些），在工作过程中，我们需要观察一下规划的时间和自己实际完成时间的差距，分析其中原因，心中有数。当然这个并非绝对的，随着我们的码量提升，我们对问题思考的速度也会提升，这样会直接影响我们的工作效率，所以观察这个事，并不只局限在入行阶段，而是一个持续的行为。
经过对需求大致评估完后，一般我们就把该项目的KPI表格部分完成了。那剩下的就是程序员最爱的和代码独处时间（狂喜）。怎么能保证我们在规定的时间内完成任务呢？其实也不难，因为我们在前面已经对需求有一定理解，而且对功能实现在技术层面也有了一些预案，我们可以把事情做出简单划分。一般而言，我们会把任务划分为四个维度：重要且紧急、不重要不紧急、重要不紧急、不重要但紧急，这个划分方式同样适合一些突如其来的任务（领导突然分配的任务）。了解这四个维度以后，我们可以先把一些重要且紧急的工作先做了，然后再把不重要但又很紧急的做了，接着就是重要不紧急，最后就是不重要不紧急了。这里面的轻重缓急，也可以根据功能模块的关联程度来划分，比如说这里有一个基础功能，虽然在技术实现上很难，但是如果不完成就会直接影响接下来的系统流程，那么它就是重要且紧急的。一般我会认为，比如一些UI上的小优化、图标的更改、文字描述修正等等都属于最后一类，不重要不紧急，毕竟这些都是不影响大体且能光速完成的事情。
除了以上这些“规矩”的方法外，如何能为自己留出宽裕时间完成任务和如何在有限的时间内追赶进度，这就是另外一门学问了～
总而言之，言而总之，打铁还需自身硬，不断实践和反复思考才能让自己的能力有所提升，加油吧各位老铁！
