标签：影响 里程碑 自己 难点 用户 包括 项目经验 比较 方案
文章试图总结作为一个技术管理者给下属进行工作分配时，需要从哪些方面考虑，以及需要注意的问题。实际上，也可以作为一个下属如何完成上级分配工作的一个指引。就像文章里说到的，我们在分配给别人任务的时候，别人也在分配任务给我们。我们在别人身上寻找某种特质的时候，别人也在我们身上寻找类似的东西。
一般情况下，管理者都会将工作安排给自己信任的人，因为对他的工作能力和工作态度都比较熟悉，能预估到他的工作情况，不会出现太大的意外，有更大的掌控，所以才偏向于自己熟悉的人。
那面对还没有建立起信任关系的人，应该如何分配工作呢？
通过第三方或者他之前的履历来衡量他的能力，这是做出这个人是否能胜任这个任务的起步基线。这一步，可能会包含太多的主观性，是要存疑的，要通过后面的步骤来确定。
在沟通任务的时候，首先要确保已经准确清晰的给他描述了任务内容。这时候要看他会提出什么样的问题，提出什么样的想法。有时候，『问对问题比正确答案更重要』。
还有一些细节，比如在问问题之前是否去有做过调研，在你给出建议或反馈后，他的反馈时什么，会不会又提出新的问题，这将提现他的工作态度。
能对任务有准确的工作量评估也是自身能力的一种提现，超前或滞后的评估其实都是对任务本身或者自身能力没有准确认知导致的。要懂得『近似的准确要好过确定的错误』，有相对准确的工作量评估，有时候甚至会影响整个项目的决策。
看他能否给出具体开发工作量有多大，需要依赖别人的工作有多少，有多少沟通成本，可能会碰到哪些技术难点，有没有现成的方案，系统框架用什么，后期的集成和测试的时间成本有多少，需要自己的上级提供哪些帮助，综合以后，再给出一个全面的时间评估。
很多时候，管理者希望能短平快地完成任务，在主观上就会倾向于那种给出更短时间的人，但实际上有可能是他在没有足够了解未知部分的情况下给出的乐观评估。所以，看工作量评估要有理有据，而且要全面。
有了时间评估，也就有了工作计划，接下来就需要依靠执行力来完成了。执行过程中，遇难就退，虎头蛇尾，都是不行的。这一部分考验的是『成事』的能力。
将整个任务细分，建立几个关键的里程碑任务，在不同的时间阶段去攻克对应的里程碑任务，出现延期时，还有可以调整的空间。
完成一个项目，并不意味着项目结束，上线以后还有很多维护的工作。包括日志跟踪，bug排查，用户反馈问题跟踪，后续的迭代等等，这时候要去观察他是否主动去做这些工作，这是是否有责任感的体现。
项目结束或者趋于稳定以后，要看他是否会主动总结之前的项目经验，总结哪些地方做的好，哪些地方做的有欠缺，从中得到了什么经验教训，以后应该怎样去规避。能从中得到提升的人才能不断进步，总是犯重复错误的人，也很难承担重要的任务。
一个项目下来，就像将军带着士兵打了一场仗，哪些人成长很快，哪些人比较稳重，哪些人比较激进，哪些人主动性高，哪些人需要定期去督促，这些组成一个团队的合作方式。对于成长较快的人，就要不断给他更高的目标；对于慢工出细活的人，就适合分配一些比较重要核心的产品，这样不容易出错，对于一些动作比较快，虽然容易出问题，但能通过快速迭代去完善，就适合做一些新的产品。
要能够承担上级分配的任务，要有两方面的能力。一方面是自身的能力，这包括业务能力，技术能力，全局观，沟通、规划等能力，另一方面也要有自己的态度，有担当，全力以赴，让自己在别人眼里是一个能托付重任的人。
标签：影响 里程碑 自己 难点 用户 包括 项目经验 比较 方案
原文地址：https://www.cnblogs.com/u5f71/p/fen-pei-gong-zuo-shi-xu-yao-kao-lu-de-wen-ti.html
