189 8069 5689
这篇文章主要讲解了“怎么评估开发任务的工时更合理”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么评估开发任务的工时更合理”吧！
成都创新互联公司专注于城步企业网站建设,响应式网站设计,商城建设。城步网站建设公司,为城步等地区提供建站服务。全流程定制网站开发，专业设计，全程项目跟踪，成都创新互联公司专业和态度为您提供的服务
在敏捷开发过程中，注重的是快速迭代，通过小步快跑，尽快向用户交付可用的产品，不断提升用户体验，赢得用户的认可和满足业务发展的需求。
当产品经理提出一个需求后，作为需求方，例如市场部、运营部或客户，都是希望这个需求能尽快上线，并且期望能知道预期可以上线的时间节点，以便安排下一步工作计划。
而需求的上线时间，往回倒推，需要参与此需求的开发人员进行评估后，才能给出相对准确的时间排期。最后，就是把抽象的需求拆解成每个技术人员可以在指定时间内完成的一个个小任务。当评估好任务工时后，项目经理或技术负责人，才能把整个需求的时间节点和项目里程碑整理出来，再反馈给需求方。
这样，从需求到任务，从工时评估再回到项目排期，就形成了一个正向良好的反馈机制，不仅能明确职责分工，还能提升团队的协作效率。敏捷开发起来，更接地气，更有效率。
但关于工时评估，在实际情况中会存在一些矛盾。
一方面是，作为产品人员，通常会觉得这个需求很简单，不就是改几行代码吗？几分钟就能搞定了。另一方面，作为不太懂技术的老板，往往不知道技术人员评估的工作量是不是太高了？
此外，作为技术人员本身而言，评估工时也是一件很有挑战的事情。
为什么呢？根据多年的项目经验总结，我觉得主要有两个因素。不确定性和任务场景。
不确定性，是指需求和未来的不确定性。有可能是需求本身是模糊或不够完善，没有很详细表明或通过文档形式注明具体需要改动的页面、功能、逻辑、规则和流程，也有可能是产品人员通过不断沟通后已非常熟悉需求本身，但对于第一次接触该需求的技术则会非常陌生。即使需求本身已经非常明确也有详细需求文档，出于业务系统的复杂性和关联性，改了这个流程有可能会影响到其他流程，进而又要修改其他模块，工作量就多了。简单来说，技术人员或者其他人员，很难一开始就能判断改了这个需求，会不会对其他的功能模块有牵连和影响。就好比如，下象棋，很难一开头就能预测接下来成千上万的不同的结局。
任务场景，是指对于同一个需求，上下文场景环境不同，也会有很大的差异。例如开发一个登录功能，对于实习生和高级开发工程师，或者对于刚入职和已经入职几年的员工，难度是不同的，评估的工时也不同。同样还是开发一个登录功能，做一个全新的登录功能，和在现有系统修改或升级已有功能，又是不一样的。因为现有系统的修改，是有历史包袱的，不仅要非常了解原有的业务逻辑，还有可能需要对历史的数据进行额外的加工处理。如果是新系统，还要进行基础架构的搭建。除此之外，还要看是否需要和外部第三方进行对接。如果该登录功能是需要接入微信登录，或者LDAP登录，或SSO登录，还需要熟悉外部的接入流程，沟通和调试起来也是一件很耗时间成本的事情。最后，还要看当前负责开发的技术人员，还有没其他需求和任务在身。小结来说，任务场景要考虑需求以外的环境因素，包括但不限于技术人员本身的专业能力和工作年限、已经安排的需求和任务、对外沟通。
怎么评估工时，取决于我们将怎么做这个需求。
曾经在我的分享PPT中，我建议不要把时间只放成开发和调试上，而是要更合理地安排自己的时间，除了编码开发，还要针对所负责的需求，积极进行多方沟通和确认，还要学会写文档、进行UML建模、做单元测试、顺便小步重构。
一般来说，一个需求做下来，需要的工作主要有：编写代码、开会、前后端联调、写文档、测试改BUG、技术调研。明确我们将要做哪些事情，结合自己所在的任务场景，那么评估任务工时，就会很清晰。
根据你接收到的需求，结合现有的代码仓库和代码模块，先熟悉现有的系统、业务逻辑，以及新的需求后，就可以开始梳理本次需求的功能需求矩阵。功能需求矩阵是指，把需求功能点，和对应能看得到的界面链接或具体的接口链接关联起来，同时把核心的技术实现方式进行标注，例如后端添加了什么新的数据库字段。最后，别忘了加多一列备注，再仔细考虑是否还有遗忘的地方以及不确定的因素。你整理得越细致，你的工时评估就越精准，工作效率就越高。
例如：
需求 | APP客户端 | H5移动端 | PC网页版 | 底层技术实现 | 备注 |
新增手机号快速登录 | 新增API接口：手机号验证码登录接口 | 新增API接口：手机号验证码登录接口 | 修改原有的登录页面： | 使用SSO实现单点登录 |
|
|
|
|
|
|
|
|
|
|
|
|
|
有了这些分析和前期准备，并且通过功能需求矩阵，如果能再配套提供技术开发文档、UML，那么你的任务评估就会更有理有据，也能让大家非常清楚你的工作情况。自然就能让更多人认可你的工时评估了。
经过十年的互联项目开发后，我发现，那些任务拆分越细的程序员，他们的工作效率就越高。因为他们能把抽象的任务评估成一个个容易被执行、可量化和可控制的任务单元，然后执行。
执行过程中，注意是执行过程中，不是执行后，及时给出反馈。当需求不明确时，他们会找需求方进行确认和沟通；当接口或界面做好时，他们会主动找相应的技术人员进行技术联调；当功能完成开发后，他们会进行自测、code review和代码重构；当发现问题时，他们及时做出响应；当测试通过后，他们会提前做好上线准备和清单确认；当发布上线后，他们会在上线半小时内对线上进行确认并通知产品经理“此需求已上线，请及时验收。”
反馈真的很重要。
这样，经过不断地迭代，完成一个又一个的开发任务，攻克一个又一个的难题和挑战，你就会发现，原来前面一直在爬坡，突然间你会发现，原来自己离骨灰级的技术大牛的距离已经不久了。
越努力，越幸运！
前面已经分享了个人如何评估任务工时，以及如何快速开发。接下来，再来探讨下团队如何高效协作开发。作为一个团队，配合得越紧凑，整体效率会越高，士气也会更旺盛。
一个项目，做下来，有几个明显的特点：时间周期长、参与人员多、信息庞杂。如果安排不当，很难让参与在其中的每个技术人员发挥更大的价值。
以下实践值得参考：
周一做计划、周五做总结；
需求有响应、项目有进度。
1、周一做计划
每周一，是很多例会召开的一天，也是每周新的一天。在这一天，如果能把上周的工作情况和这周的目标再系统性梳理一番，分配落实到每个人身上，再让每个技术人员评估好开发任务，做好计划，就会形成整体团队这一周的工作排期。
例如，在YesDev的工作排期中，下面是我们团队这一周的工作计划。曾经在某企业任职时，每周要汇总团队的工作情况和任务工时，我都很痛苦，因为要手动汇总团队近10人的工时，但有了这里的工作排期，可以直接导出Excel，一下子就可以发给老板查看了。你好我好大家好！^_^
YesDev还有个很好的工具，就是当你在指派任务时，可以快速看到他的工作饱和度。
2、周五做总结
周五下班前，通过周报的形式，让团队的每个人把这一周的工作情况，完成的任务以及下周的计划，汇报上来，不仅是对每个人的总结和提升，也是整个团队向上汇报的重要通道。要让自己的工作看得见，让团队的成就看得见。更重要的是，每周一封邮件，一年下来大概是50多封邮件。这一年是怎么突破的，回顾这些邮件，你会清晰发现我们走过了哪些路，跨越了哪些重要的里程碑。不仅能回顾过去，不能展望未来。认真做事的态度，必然会取得更骄人的成果！
在YesDev中，对于周报，有一个很大的创新功能，就是可以根据每个人的工作情况，自动生成每个人的工作周报，大大节省了编写邮件的时间。保存后还可以直接发给团队或你的上级。
3、需求有响应
当产品经理提出需求后，负责需求的技术人员会及时收到邮件通知。当需求被完成后，产品经理也能及时收到相关的邮件通知。如果你既不是产品经理也不是技术人员，若对此需求感兴趣，可以关注此需求。那么你也能及时收到需求的最新动态通知。
例如这样的邮件通知：
4、项目有进度
首先，对项目进行任务评估后，会得到任务列表。这部分，需要技术人员自己进行评估。
评估完成后，将可以自动得到：项目排期表和项目燃尽图。
项目排期表会把重要的负责人、时间节点和项目里程碑自动生成出来，方便项目经理或技术负责人进行项目管理和团队协作。
项目排期是静态的、是理论的。而项目燃尽图则是实际的执行情况。这就好比如你设置了一个目标，今天下班后要跑5公里，预计30分钟跑完。可能最终情况是，你只跑了3公里，并且花了1小时。因为实在跑不动了。
感谢各位的阅读，以上就是“怎么评估开发任务的工时更合理”的内容了，经过本文的学习后，相信大家对怎么评估开发任务的工时更合理这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！