走路与项目管理

本文通过上下班走路的经历,类比项目管理。指出项目启动和中期易懈怠,收尾时问题爆发,需加班赶工。强调项目初期应详细分析需求、合理设计,减少资源浪费,后期弥补浪费困难。还提到项目通常难提前很多完成,估算偏差大会致浪费。

   每天上下班都要走不少的路,却是最近几天才体会出走路与项目管理之间的联系。

    因为基本能确定上班花在路上的时间,所以每天几乎都是掐着点儿从家里出发。可是在刚出门走去地铁站的时候,因为觉得还早,所以挺悠哉的像散步一样走过去。可是下了地铁往往都8点10好几,有时是11、2分,有时就是17、8分了,从地铁站到公司也要10来分钟,就只好紧赶慢赶,甚至跑步前进了。就算这样也未必就能及时赶到公司,上次的迟到就是一个明证了。

    项目管理也会出现同样的情形。通常在项目启动时,大家都知道我们有“大量的”时间,虽然可能这段时间相对于真实进度而言可能还是很紧张甚至是不够的,可是大家看着数量“巨大”的时间资源摆在面前,很容易产生一种“还早呢”的懈怠感。于是在项目初期产生拖拉、分析设计不深入等问题也不足为奇。同样,在项目中期虽然会感觉到一定的压力,但仍会感觉有一定的“缓冲时间”在,有时也会产生“唉,这个问题我知道,等我有空了就马上解决”或是“我知道这里应该重新设计,可是我们还有时间,等过一会儿我有空了一定会好好设计的”这种想法/做法。然而当进行到项目收尾阶段,大家才会发现时间不够用,前面没解决的问题全都拖到这个阶段,各种各样的毛病、问题和用户反馈像火山一样爆发,大家拼命加班加点,把所有精力都投入到Debug工作中,把那些“修饰性”的设计工作抛到了下一版,所有的团队成员都为了准时提交可用的软件这个唯一目标而努力奋斗。最终也许可以准时提交(如果足够幸运的话),但再拖延个三四周甚至几个月也并不是什么罕见的事。

    为什么会这样呢?这是因为,在项目的启动阶段(开始走路时),我们拥有全部可调动的资源,同时我们的时间还没有开始浪费在不相关的地方,所以在这个时候我们最容易也最有可能减少我们的浪费。就像走路时你完全可以在前半段稍稍提高你的速度,不必奔跑,就可以省下大概10多分钟的时间,而这些时间足够让你悠闲的从地铁站走到公司而不会迟到。同样在项目开始时你可以通过对需求进行详细而深入的分析,对系统进行全面的考虑而给出尽量合理的设计,在发现时间和资源浪费的同时纠正这些错误而提高开发速度,同时减轻资源(包括时间)的浪费。在前期的这些投入将使你在项目后期得到10倍甚至100倍的收益,因为你无法收回已浪费的时间和资源,但可以通过努力工作而减少尚未产生的浪费

    而在项目后期,绝大部分的时间和资源都已经被使用,尽管你知道很多被浪费了,你也没有办法再去收回;而同时你可以调动用来进行“补偿”的资源也大大减少,之前由于懒惰、懈怠、草率造成的问题也都开始显现,所以你在这时焦头烂额,疲于奔命,但往往还是不得不面对你无法兑现你当初的承诺的悲惨结局。因为无论如何努力,人的能力是有限的,就像如果地铁站与公司的距离是一个人拼命狂奔也需要15分钟的话,你在只剩10分钟的情况下无论如何努力也是要迟到的,因为你不能期望着你能比世界短跑冠军跑得还快。

    所以尽管在项目初期和项目收尾时浪费的10分钟看起来是一样的,但它们带来的影响是完全不同的,而没有认识到这个差别有时会产生非常严重的后果

    顺便说一句,同走路一样,通常不能期望项目相对于估算日期提前很多完成。因为当进入到项目后期,每个人都能够肯定项目不会拖延,肯定能够按时交付的时候,不能够指望他们还会拼命的去提前发布日期;相反,他们的通常做法是保持原来的进度甚至稍稍懈怠一些,因为“反正不可能迟到,为何不看着报纸走去公司?”。
    所以如果项目比估算日期提前很多完成,那只有一种情况:估算本身偏离了实际情况太多,就如同早上上班出来的太早,尽管你走得很慢,可还是很早到了公司一样。但要注意的是,尽管比预算提前了很多,但浪费也会更多——因为预算过于宽松,紧迫感会随之降低。

下载方式:https://pan.quark.cn/s/a4b39357ea24 布线问题(分支限界算法)是计算机科学和电子工程领域中一个广为人知的议题,它主要探讨如何在印刷电路板上定位两个节点间最短的连接路径。 在这一议题中,电路板被构建为一个包含 n×m 个方格的矩阵,每个方格能够被界定为可通行或不可通行,其核心任务是定位从初始点到最终点的最短路径。 分支限界算法是处理布线问题的一种常用策略。 该算法回溯法有相似之处,但存在差异,分支限界法仅需获取满足约束条件的一个最优路径,并按照广度优先或最小成本优先的原则来探索解空间树。 树 T 被构建为子集树或排列树,在探索过程中,每个节点仅被赋予一次成为扩展节点的机会,且会一次性生成其全部子节点。 针对布线问题的解决,队列式分支限界法可以被采用。 从起始位置 a 出发,将其设定为首个扩展节点,并将该扩展节点相邻且可通行的方格加入至活跃节点队列中,将这些方格标记为 1,即从起始方格 a 到这些方格的距离为 1。 随后,从活跃节点队列中提取队首节点作为下一个扩展节点,并将当前扩展节点相邻且未标记的方格标记为 2,随后将这些方格存入活跃节点队列。 这一过程将持续进行,直至算法探测到目标方格 b 或活跃节点队列为空。 在实现上述算法时,必须定义一个类 Position 来表征电路板上方格的位置,其成员 row 和 col 分别指示方格所在的行和列。 在方格位置上,布线能够沿右、下、左、上四个方向展开。 这四个方向的移动分别被记为 0、1、2、3。 下述表格中,offset[i].row 和 offset[i].col(i=0,1,2,3)分别提供了沿这四个方向前进 1 步相对于当前方格的相对位移。 在 Java 编程语言中,可以使用二维数组...
源码来自:https://pan.quark.cn/s/a4b39357ea24 在VC++开发过程中,对话框(CDialog)作为典型的用户界面组件,承担着用户进行信息交互的重要角色。 在VS2008SP1的开发环境中,常常需要满足为对话框配置个性化背景图片的需求,以此来优化用户的操作体验。 本案例将系统性地阐述在CDialog框架下如何达成这一功能。 首先,需要在资源设计工具中构建一个新的对话框资源。 具体操作是在Visual Studio平台中,进入资源视图(Resource View)界面,定位到对话框(Dialog)分支,通过右键选择“插入对话框”(Insert Dialog)选项。 完成对话框内控件的布局设计后,对对话框资源进行保存。 随后,将着手进行背景图片的载入工作。 通常有两种主要的技术路径:1. **运用位图控件(CStatic)**:在对话框界面中嵌入一个CStatic控件,并将其属性设置为BST_OWNERDRAW,从而具备自主控制绘制过程的权限。 在对话框的类定义中,需要重写OnPaint()函数,负责调用图片资源并借助CDC对象将其渲染到对话框表面。 此外,必须合理处理WM_CTLCOLORSTATIC消息,确保背景图片的展示不会受到其他界面元素的干扰。 ```cppvoid CMyDialog::OnPaint(){ CPaintDC dc(this); // 生成设备上下文对象 CBitmap bitmap; bitmap.LoadBitmap(IDC_BITMAP_BACKGROUND); // 获取背景图片资源 CDC memDC; memDC.CreateCompatibleDC(&dc); CBitmap* pOldBitmap = m...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值