热门标签 | HotTags
当前位置:  开发笔记 > 数据库 > 正文

工作感言:项目时间估算

大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个
      大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来。到了企业之后,实际时间是估算时间的两到三倍也是很正常的事,这还是在需求明确到85%以上的情况下,需求不清的情况下,时间就海了去了。
       项目开始时,客户简单的描述需求,开发方便豪言壮语一个时间(有时这个时间连需求分析都做不完),中间客户改了需求,开发方声称“绝对不是问题”(接项目时要人情、关系之类的,客户改点需求,一般不太好明说要加时间),到了时间了,还差很多没做完(项目组的人赶工都加了好几天的夜班了),给客户演示下,忽悠下客户,然后再说我们再完善一下(一般这时客户也会再提点新需求),如此反复,就不知道要完善到什么时候去了。最后提起这项目,开发方暗骂客户扯蛋,客户暗骂开发方混蛋。
       需求不清的情况下,本人暂时不知道怎么估算时间(不知各位有什么高招,分享下)。但为什么在需求明确到85%以上的时候,我们实际时间还是估算时间的两到三倍,或者更多,这种情况我想扯蛋是出在我们自己身上了,我总结了一下,分为两种:
      1,  自己豪言壮语“害”自己,拿到了一个需求或一个技术难点,看了一下,道:“这个容易,两三天搞定”,“这个系统简单,撑破天一个月”,真的动起手来发现挺难的,搞了N个两三天或撑破了N个天才搞定。
      2,  别人豪言壮语“害”我或整个小组,这个别人通常指市场人员,在软件公司基本是市场跟技术之争,而在国内,因为各种原因往往又是市场占主导,一个项目下来,市场人员感觉一下需要多少时间,技术的就得照办,你跟他说“时间不够”,通常都会回复,“加加班,抓抓紧”,往往按他估算的天数就是按24小时工作也不够(更离谱有的连需求都做不完),再说市场的不懂技术,实际时间往往是他估算的时间三、四倍也不足为奇。你直接跟他说你的估算时间=他估算时间*3,是不是从侧面贬低你上级的智商,他会接受吗?
      
     
       经过了一段时间的痛苦之后,我还是小有点心得了,如下:
       问题1是比较容易解决的,因为改变自己远比要改变别人容易得多,刚开始的时候,我们自己可能会夸海口,随着经验的非富,对自己的时间估算会慢慢地八九不离十,我就是这样的。刚毕业那会,我领到一个任务,看一下就估算个时间(通常很短,为了表现自己,再加上精力比较旺盛),工作时间做不完,就加班做(反正也没什么事),慢慢我也知道具体的任务我大概需要多少小时来做。
 不过刚开始带小组的时候,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间\小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多。后来我就吸取了教训,跟组里的人相处久了,心里也有底了,谁比我强,大概强多少,谁比我弱,弱多少 (最好能量化,单凭感觉靠不住),这样一折算可以把时间算个大概;再把任务跟组员交流一下,基本估算的时间八九不离十。
       问题2就比较麻烦了,上级(非技术人员、市场人员之类)通常估算一个项目的时间少得离谱,说出来吓坏项目组长,我通常把这种情况叫做放卫星。面对上级放卫星,要想办法说服上级采用我们的时间或者让上级接受这个时间(特殊情况),因为上级是非技术人员的话,一般是凭感觉估算时间,所以一般不要试图用自己感觉的时间来证明别人的感觉的时间不对。(为什么你感觉的就对,我的就错,上级肯定不会采纳的,反而会让上级感得你做事不积极,想拖时间,怕苦怕累,对任务讨价还价,前期我也犯了这样的错误,给上级留下了不好的印象),后来我总结了一下,发现说服上级是需要一定的技巧的。
      1,  有理有据,用数据说话。上级凭感觉估算的时间与自己估算的时间有很大差距时,不要很着急地直接说出自己估算的时间(这样容易造成直接的对立,之后的交流会很僵),可以先描述推出时间的依据是什么,依据的数据支持是什么,然后当着上级的面根据这个依据把我们估算的时间给算出来,古语有云:事实胜于雄辩;想必上级会欣然接受的。(毕竟大家都是为了把工作做好)
      

      经历:
      有一个项目(信息系统,需求比较明确),在数据库设计做完之后(120多张表呀),我的上级(市场人员出身),跟我说:“这个简单呀,最多15天就搞定了,你看怎么样?”当时我一听心里就发毛,当时我估算的时间是45天呀(整整差了3倍);我首先表达了我的时间跟他算的有点差距(但没有直接说我的时间),然后列举了前面公司所做的几个信息系统的项目,如下:
项目A,3人,60天,140张数据库表,平均每人每天处理0.8张表
项目B,5人,30天,110张数据库表,平均每人每天处理0.7张表
。。。。
 然后我跟他说:现在我们效率提高了,再加上项目紧,我们会加下班,大概算每人每天处理1张表吧,小组共3人,也要45天这样呀。最后我还笑着跟他开了个玩笑:我们组每天24小时工作,一直干15天,都有点勉强呀!(当时在座的都笑了)。当时上级思考了一下,然后就采用了我的45天的计划。
      
      
      2,  把任务分配到组员,再请上级到小组中交流,依靠群众的力量说服上级,反过来每个组员都当着上级承诺了开发时间,对他自己也是一种鞭笞、激励,有利于按时完成任务。小组组长单独跟上级说,他官大一级压死人,再说自己心里也有点怕怕吧。把他请到小组里来,人多了自然胆也壮了,将每个人的开发任务给他看,每个人说说对自己任务的看法,难度怎么样,要多久才能完成(参照第一条,有理有据,用数据说话),注意控制气氛,尽量以聊天的形式,不要搞僵气氛,最后由自己进行一个总结,把总的时间明确化,这时上级面对群众的力量,一般也会同意你的估算时间。
      特殊的情况,假如上级就是要按他估算的时间来(原因可能有很多,他就认为他的是对的,客户摧得紧等等),实在无法说服上级完全采用自己估算的时间,能多加几天是几天,但是在心里一定要有个完成项目的估算时间,哪怕这个时间是上级指定的10倍(这个时间最好是比较可靠的,有依据),我始终认为一个项目完成的时间是多少就是多少,不为因为上级硬压一个很短的时间就真的是这个时间了(我发现加班做不了多少事,不知道大家的感觉怎么?),很多时候,上级宁可你最后延长或拖N倍于他的估算时间,也不采纳你的N-X倍比较可靠的时间(有点无奈)。假如你心里没底的话,会做到很郁闷(因为每次延时,整组人都会觉得很累,可能是因为一鼓作气,再而衰, 三而竭;延时越多,整组人会越疲倦);遇到这种情况,可以暗地按自己计划走,不停地延时到自己估算的时间就OK了(这是针对那种放卫星的估算时间,差距不大的时间赶赶工就可以,要积极地工作,呵呵)
       最后来个估算时间的总结: 有理有据地估算时间,说服上级采用这个时间。遇到放卫星式的项目时间,自己心里要有底,不可盲从。
推荐阅读
  • 在Java分层设计模式中,典型的三层架构(3-tier application)将业务应用细分为表现层(UI)、业务逻辑层(BLL)和数据访问层(DAL)。这种分层结构不仅有助于提高代码的可维护性和可扩展性,还能有效分离关注点,使各层职责更加明确。通过合理的设计和实现,三层架构能够显著提升系统的整体性能和稳定性。 ... [详细]
  • 数据库多表联合查询:内连接与外连接详解
    在数据库的多表查询中,内连接和外连接是两种常用的技术手段。内连接用于检索多个表中相互匹配的记录,即只有当两个表中的记录满足特定的连接条件时,这些记录才会被包含在查询结果中。相比之下,外连接则不仅返回匹配的记录,还可以选择性地返回不匹配的记录,具体取决于左外连接、右外连接或全外连接的选择。本文将详细解析这两种连接方式的使用场景及其语法结构,帮助读者更好地理解和应用多表查询技术。 ... [详细]
  • 初探性能优化:入门指南与实践技巧
    在编程领域,常有“尚未精通编码便急于优化”的声音。为了从性能优化的角度提升代码质量,本文将带领读者初步探索性能优化的基本概念与实践技巧。即使程序看似运行良好,数据处理效率仍有待提高,通过系统学习性能优化,能够帮助开发者编写更加高效、稳定的代码。文章不仅介绍了性能优化的基础知识,还提供了实用的调优方法和工具,帮助读者在实际项目中应用这些技术。 ... [详细]
  • 作为软件工程专业的学生,我深知课堂上教师讲解速度之快,很多时候需要课后自行消化和巩固。因此,撰写这篇Java Web开发入门教程,旨在帮助初学者更好地理解和掌握基础知识。通过详细记录学习过程,希望能为更多像我一样在基础方面还有待提升的学员提供有益的参考。 ... [详细]
  • ButterKnife 是一款用于 Android 开发的注解库,主要用于简化视图和事件绑定。本文详细介绍了 ButterKnife 的基础用法,包括如何通过注解实现字段和方法的绑定,以及在实际项目中的应用示例。此外,文章还提到了截至 2016 年 4 月 29 日,ButterKnife 的最新版本为 8.0.1,为开发者提供了最新的功能和性能优化。 ... [详细]
  • 在重新安装Ubuntu并配置Django和PyCharm后,忘记测试MySQL连接,导致在后续配置过程中遇到错误:ERROR 2003 (HY000) - 无法连接到本地服务器 ‘127.0.0.1’ (111)。本文将详细介绍该错误的原因及解决步骤,帮助用户快速恢复MySQL服务的正常运行。我们将从检查网络配置、验证MySQL服务状态、配置防火墙规则等方面入手,提供全面的故障排除指南。 ... [详细]
  • 本文详细介绍了使用 Python 进行 MySQL 和 Redis 数据库操作的实战技巧。首先,针对 MySQL 数据库,通过 `pymysql` 模块展示了如何连接和操作数据库,包括建立连接、执行查询和更新等常见操作。接着,文章深入探讨了 Redis 的基本命令和高级功能,如键值存储、列表操作和事务处理。此外,还提供了多个实际案例,帮助读者更好地理解和应用这些技术。 ... [详细]
  • 本文详细探讨了在ASP.NET环境中通过加密数据库连接字符串来提升数据安全性的方法。加密技术不仅能够有效防止敏感信息泄露,还能增强应用程序的整体安全性。文中介绍了多种加密手段及其实施步骤,帮助开发者在日常开发过程中更好地保护数据库连接信息,确保数据传输的安全可靠。 ... [详细]
  • 使用SQL命令创建数据库及其语句解析
    使用 `CREATE DATABASE` 命令可以创建一个新的数据库,并指定其名称。该 SQL 语句用于初始化数据库结构,执行后将生成一个新的数据库实例,用于存储相关的数据对象和表。在本例中,通过执行 `CREATE DATABASE 课程管理1`,系统将创建一个名为“课程管理1”的数据库,以便后续的数据管理和操作。 ... [详细]
  • REST与RPC:选择哪种API架构风格?
    在探讨REST与RPC这两种API架构风格的选择时,本文首先介绍了RPC(远程过程调用)的概念。RPC允许客户端通过网络调用远程服务器上的函数或方法,从而实现分布式系统的功能调用。相比之下,REST(Representational State Transfer)则基于资源的交互模型,通过HTTP协议进行数据传输和操作。本文将详细分析两种架构风格的特点、适用场景及其优缺点,帮助开发者根据具体需求做出合适的选择。 ... [详细]
  • 如何精通编程语言:全面指南与实用技巧
    如何精通编程语言:全面指南与实用技巧 ... [详细]
  • 在众多市场调研公司中,如何选择一家值得信赖的合作伙伴至关重要。基于我在市场调查行业近二十年的经验,我将推荐几家国内知名的市场调研机构,供您参考:1. 开元研究——专注于零售报刊发行研究、媒体广告价值评估及网络营销分析等领域,以其专业性和准确性赢得了广泛认可。 ... [详细]
  • 在 CentOS 6.5 系统上部署 VNC 服务器的详细步骤与配置指南
    在 CentOS 6.5 系统上部署 VNC 服务器时,首先需要确认 VNC 服务是否已安装。通常情况下,VNC 服务默认未安装。可以通过运行特定的查询命令来检查其安装状态。如果查询结果为空,则表明 VNC 服务尚未安装,需进行手动安装。此外,建议在安装前确保系统的软件包管理器已更新至最新版本,以避免兼容性问题。 ... [详细]
  • POJ3669题目解析:基于广度优先搜索的详细解答
    POJ3669(http://poj.org/problem?id=3669)是一道典型的广度优先搜索(BFS)问题。由于陨石的降落具有时间属性,导致地图状态会随时间动态变化。因此,可以利用结构体来记录每个陨石的降落时间和位置,从而有效地进行状态更新和路径搜索。 ... [详细]
  • MySQL 8.0 MGR 自动化部署与配置:DBA 和开源工具的高效解决方案
    MySQL 8.0 MGR 自动化部署与配置:DBA 和开源工具的高效解决方案 ... [详细]
author-avatar
lyglpp
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有