最近有机会在一个项目中负责其中的核心功能，经历了需求分析，任务拆解，任务实施的全过程。这次的经历给了我一个新视角去思考怎样做一个领导放心的下属，如何资源推进项目，如何分析安排需求等等。

分析需求和安排任务

这次的项目我也是第一次接触，业务逻辑刚开始也不清楚。我的处理方式是仔细看了一遍需求文档，然后再基于现有的系统功能，操作了主要的界面，看了主要流程的代码，大致了解了它们的大体逻辑。

这个过程中，我逐渐在脑海中形成了第一版对需求的大体理解，随后我再咨询了接管需求的人员和了解业务的相关同事。确认我的理解，和他们要求是否有偏差，以及是否有遗漏。这里的确认，还只是在大体范围方面[如明确需求中的几大主要点，哪些重要，哪些次要]，还没有到具体实现等。

当然在交流过程中，会了解为什么有这个需求，这个需求是为了解决对方什么问题，以及需求中他们认为哪些点很重要，哪些点暂时可以缓缓等等。

在确定大方向是正确和摸清主次后，我再根据需求文档的要求，设计具体实现方面的细节，如设计表结构、界面原型图、接口等等。并将过程中遇到的疑问记录下来，待第二次交流时确认。

待需求具体实现方案设计出来后，我再次找领导确定方案的可行性，以及一些问题的确认。其中每个不确定的问题，我会向领导给出我自己认为的解决方法，但需要领导拍板具体哪种方式或者是他是否有更好的想法。

在找领导确认完需求实现方案后，一般还需要进行一些调整，调整后再找领导确认，如果没有问题就进入人员分配环节。此时，可以自己先将需求的功能点，按照业务的关联性等进行拆解各个小任务模块，其中完成任务时限最长不宜超过3天。

在将任务分配给各个开发人员时，一定要任务模块责任到个人，不宜将某个任务分摊给多个人，必须指定到某一个具体责任人。

在这次需求实现过程中，我和其他开发人员描述任务要求时，直接是照着原型图和他们讲解了要开发成什么样子，哪些注意点等等。这种方式虽然简单和快速，但是存在弊端。因为，不管前期我的需求设计怎么准备，总会有考虑不全的时候，如果只是告诉开发人员要实现的结果，而不告诉他这个功能为什么开发以及重点等等，他就不加思考的按照你的想法去实现了(这还没有出现他的理解和你不同时)，不管合不合理。

但是如果，开发人员也和你一样了解这个功能点，那么他就可以基于现有的需求情况，知道怎么解决开发过程你设计时没有考虑到的问题了。这样他就不会在开发过程遇到问题就不停的咨询你了，因为他知道如何决策。即任务分配后，就全权他负责，问题可以他自己搞定。
[让你的下属明白做这件事的缘由，哪些点很重要，哪些点可以忽略，这样他就可以自己决策了，不必总是向你请示了。]

此外，对于不确定的需求，要快速迭代方案。不然，随着时间拉长，变化会越来越大。

如何推进项目

这方面我做得不好，没怎么推进，但是磊哥有每天做。对于小项目，各个组员还不熟悉或者项目比较赶的情况下，可以每天下午下班前问下各个的进展，有没有需要外界帮助的问题等等。当然在项目开始时，会将项目进度安排的文档共享给大家。每天下班前的沟通一方面时提醒组员对任务时间需要有概念，另一方面便于领导知道项目的进度，同时，增加人与人的沟通。

对于大项目，不一定要做到每天过问进度。但是，也要定期了解项目完成情况。

另一方面，我觉得每天的晨例会很有必要。大家可以说昨天做了哪些事情，遇到了哪些问题，是怎么解决的，今天打算做什么。每周一可以说下上周做了哪些事情，以及这周的主要任务。

如何做一个称职的下属

也是这次经历，才让我换了一种视角看这个问题，也让我意识到自己之前好些地方做得不好。

领导有很多活儿要做，很多是你看不到的。当他把任务分配给你的时候，其实他是希望你全部负责的，即这块有问题就找你。而不是当出现问题了，你对领导说一句“你当初这么设计的，我完全按照你的原型或者方案来的”。

不论什么时候，由于种种原因，总会出现领导在设计考虑不全的情况。所以在接收任务时，一定要领导反复沟通你对功能的理解，为什么做，什么重要等等，这将是以后遇到问题时决策的依据(我个人感受，我更希望组员和我确认，他对任务的理解，但很多人在接任务时一点问题都没有)。在开发过程中，一定要有自己的思考。其实在某一个功能点上，你应该是比分配任务给你的领导更权威。

对于复杂、不确定的需求，你最好在最短时间内做出第一个版本，找你领导确认是否有问题。当然，你领导可能会提很多问题，但是你要抓关键点修改，对于某些次要的问题，可以暂时不管。总之，重要功能的实现要超出领导的预期，非重要的功能实现即使稍微低于领导要求也没有关系。

还有一点，最好每隔一段时间，主动向你领导反馈你的进展，不要等领导问你进度。这也算是给领导吃了个定心丸。