软件开发在追踪上的难题
一般在企业内部要开始一个软件开发的项目有很多时候是老板忽然灵机一动地问说：“我们来开发一个某某软件，你觉得需要多久？” 有经验的人听到这个问题时就知道这是考验专业能力与职场敏感度的时刻，因为这是一个两难的问题。在好傻好天真的时期会想：“天啊！软件要做到什么程度、有多少人参与、要给多少资源都还没确定，就要押完成日？” 会有这样的想法不意外，就像是要盖一个房子，连要盖几层都不确定、设计图都还没画，更别提建材和工人都还没有着落的情况下就要问何时入住，回答得出来才有鬼！
但在老板面前为了展现专业与工作经验、彰显自己存在的价值，那就只好照之前类似软件开发的经验抓个时程，再加上安全缓冲的时间做为答案。只是对于这种答案老板大多第一个反射的回答是：“怎么会要这么久？不能在某月某日前上线吗？” 哇！专业的光环当场缺角，于是就要开始搬出一大堆的说词来证明自己不是漫天要价，同时心里咒骂着：“是你说要给个时间的，倒底是真心地想要征询专业意见？还是要猜你心里的理想日期？”
打滚了一阵子，不再好傻好天真后被问到同样的问题，开始学会先用感觉抓出时程再打个折当做答案。只不过一旦日期落入老板的理想日期或更早，老板则是会见猎心喜地说：“这个日期是你自己说的哦，那就照这样订了！” 结果就是挖了一个大坑并且自己往下跳！所以吃过亏的人才会知道老板这简单的问句是一个深奥又富含职场哲理的问题，而最后还得因五斗米而折腰，为了要讨好老板明知是陷阱也得含泪跳下去。
刚才的情境还只是前菜，等到软件开始建构了，老板就改成三不五时来问说：“目前进度如何？” 又是一个容易动辄得咎的问题，因为老板其实想要问的是：“何时可以上线？有没有可能提早？” 不要说软件开发项目是个保证会延期的项目类型了，就连很多的大型工程项目不也是一延再延？但这却是个众所皆知而不能说的秘密！“不知道”更是绝对不能被接受的答案，所以要如何“知道”是一个管理上很重要的课题。毕竟就算老板不问，身为管理者心理也要有个谱，才不会事到临头了才惊觉大事不妙。
想要掌握软件开发项目的进度，有一个前提非常重要，其实不只是软件开发项目，任何的项目都是。有接触过 PMP (Project Management Professional) 的人应该都知道，所谓的监控已经是整个项目管理过程中比较后期的工作流程。在进入到监控之前要先进行规划、安排，最基本的得要先设定好项目的 Scope，不然就像一开始说的连要盖几层楼都不清楚，跟瞎子摸象一般，就算知道现在盖好了多少层也无法确定何时可以入住。
在东、西方文化的差异下，西方比较讲求按部就班，东方文化就偏重实事求是，所以像 PMP 这样的知识体系大多都是来自于西方，而要将这样的管理精神套用在我们的工作环境之中也很容易迫于氛围只剩下半套。所以在软件开发项目通常就只会有执行及监控这种有产值的流程出现，Scope？是啥？能吃吗？想当然尔，开发的工作都只能在有个大概轮廓的状态下进行，细节的部份则是边做边确认，想要掌握进度更是如同雾里看花。
这是最糟的情况吗？不是！经常变动才是开发工作上的大挑战，绝大部份的软件开发项目不太可能会有需求冻结这种事。就像房子盖好了底下的二、三层，老板看了觉得似乎加个几层会更好，金口一开瞬间四层就变八层。但八层的房子要设计的耐重和四层楼明显地不一样，在赶工的情况下大多是设计得够用就好，一旦要加楼层整个结构、甚至地基都要打掉重来。但如果要拿房子的例子和老板解释这样变动带来的冲击，老板才没空听你扯什么房子的问题，又不是要你弄得脏兮兮、挥汗如雨的，不是只要坐在电脑前面打打字、剪剪贴贴就可以收工了，能花多少时间？这种情况之下怎么可能会有准确的进度资讯？
在管理软件开发项目上还有另一个棘手的问题，如果真的是照着 PMP 的规范走，这类型的项目要界定所谓的 Scope，大致上就是在进行需求分析的工作，或许还夹杂着一部份的系统分析在其中。就整个软件开发的流程来看，这部份的工作所占的比重并不低，甚至有很多规模不大的系统在分析完之后就没剩多少工作项目，如此说来理论上这部份应该也要被列入追踪的范围内。这时就会形成了一个鸡生蛋、蛋生鸡的矛盾情境：这些工作就是要弄清楚开发的范围，如果要把这些工作列入管理但范围还没有确定，所以得先完成这些工作... 结论就是想要顺利完成一个软件开发项目，就只能尽人事听天命了！
时程估算的准确度
好吧，关关难过、关关过，排除万难把工作项目都开出来，甚至搞了一整个 WBS 就一切顺利吗？软件开发的工作特性与一般的项目最大的不同是不确定性很高，每一个工作项目都像拓荒一样是一种从无到有新的经验。因为每次都是要把不同的工作知识转换成可运作的源代码，程序要怎么写和数据的特性有很大的关连。再以盖房子做比喻，开发不同的软件并不像是重复地盖砖墙的房子般，因为同样都是砌砖的施工手法，经验是确定的。比较像是每次盖房子时使用的是新建材，所以在盖的同时都要不断地摸索建材施作的特性，而很容易出现技术上的瓶颈。
每一个开发人员的素质不同，需要摸索的时间就会不一样，再加上遇到技术瓶颈时解决问题能力的高低，不太可能套用一致性的法则，这也增加时程上的变数、直接牵动着工作进度的快慢。所以要估算软件开发的工时是一项复杂度、不确定性都很高的工作。软件工程里有提到一些艰深难懂的估算公式，但通常需要取得很多的参数，老实说一点都不实用、在实作上也没有太大的意义，因为算出来也不保证百分之一百精确。
那倒底要怎么估才好？这个嘛... 站在技术人员的立场真心地觉得不要估最好，估了也只是求心安的，就像生小孩的预产期一样，源代码时候到了自然就会生出来，催也没用，押了日期没写完还不是得延，何苦来哉啊！但是这种说法大概也只有写过程序的苦主才能够认同，有时候还满羡慕所谓的艺术家，同样是不确定性很高的工作，大家都可以认同创作需要时间也不用给时间表，但明明程序的用途是比艺术家的成果还具有实用价值，大家却选择盛赞艺术家然后压榨工程师。
至于怎么估，基本的原则是：如果想要精确一点，当然工作项目单位愈小愈好。要估算一个函式多久可以完成，一定是比估算一整个软件的时程来得贴近现况，但相对的要花的时间也比较多。同时有能力切到以函式为单位做工作项目，剩下要做的事打概也只有打字，每个工作项目得到的数字也许都是以分钟为单位。这样的管理方式真的有意义吗？老板会希望等了大半年后才知道接下来的工作只要二周的时间吗？所以不是说了，不要估最好！
Burndown Chart 在管理上的问题
只不过，怎么估并不是这篇文章的重点，这篇文章主要是想说明怎么追踪。面对这类型的问题，业界还是有发展出一些简单的方法，有听过、参与过 Scurm 的人应该会想到 Burndown Chart。这是一个好工具、简单明了，可以很快速地让所有项目参与的人或是有利益相关的人了解目前项目的状态，不管懂不懂 Scurm。基本上在制作 Burndown Chart 的时候，不见得要把每一项工作都精算出对应的工时，只要评估好工作项目的规模大小，以 Story Point 的相对数值来表达即可，这会大幅地减少计算工时所需投入的成本。
Burndown Chart 是用还剩下多少工作做为基准，在团队工作产值没有大变化的情况下，绘制出一条由 Y 轴某一点出发向下延伸的斜线一直到和 X 轴交会，交会的点即为完工的日期。在现实中当然不可能会有这么理想的情况，所以实际的曲线应该是呈现锯齿状并且和那条理想的斜线交缠着，项目人员借此来判断是否能及时在指定的日期前完成工作。
凡事有利就有弊，Burndown Chart 的呈现比较偏向项目或团队整体的资讯。在遇到进度不如预期的时候，不太容易从 Burndown Chart 中界定问题的责任归属。当然会来从事开发工作的人绝大部份都是单纯、善良的，在跟团队成员讨论进度时把图表亮出来，该谁需要改进的都自己心理有数并且能够负起责任。但总会遇到少数几个刁钻又具有心机的人，这时通常会需要有个明确的数据来让管理上的对应措施有个底。尤其是身为上头还有高层、被夹在中间的管理者，当情况开始失去掌握时，也可做为向上寻求协助的其中一项依据。否则一旦让不好的行为在团队中引起破窗效应、对工作氛围造成影响，所产生的后果就会变得很难收拾。
除此之外，在一般企业里大多都是数个开发案同时进行，团队中可能根本就没有一个人是专职在自己手上的项目里，同一个开发人员会需要负责多个系统，有时还要再加上既有的系统维护。在有的软件要开发新的功能、有的软件要进行维护、有的软件要除错的情况之下，如果只针对单一个开发项目来看，同一位工程师的产值可能就会有大有小，不太可能维持一定的量。就算有心想要帮开发人员排除时程上不利的因素、保持产值的稳定，势必要考量到各系统在上头的重视程度、使用对象的重要性、时程的紧迫程度，更麻烦的是会牵涉到各系统负责人之间抢人的政治角力，结果不如预期乃是兵家常事。排除不了，进度的延迟就成了开发人员的非战之罪，管理者就没有立场去做苛责，毕竟这是管理者的责任。只是如果像之前提到的，成员中出现少数不属于善良的那一种类型，利用游走各系统来掩饰进度问题，以 Burndown Chart 所提供的资讯在管理上也是无从判别的。
使用 EVM 追踪进度
能够身处在教科书的理想环境与团队的组合中做管理毕竟是可遇而不可求，面对这种现实的情况还是要有一套有效的管理方式，在 PMP 中有提供一个进度追踪的方法叫 EVM (Earned Value Management) 可以提供一些辅助。但在这篇文章里使用的是简化过的 EVM，主要是取几个 EVM 中提到的数据来做为管理上的参考。用最白话的方式来说明 EVM 就是用预期要投入多少成本做为基准，比较实际获得的价值与目前预计进度、累计投入的成本间的差异。其中目前预计进度为 Planed Value 简称 PV、目前累计投入的成本为 Actual Cost 简称 AC、与实际获得的价值为 Earned Value 简称 EV。
举个例子来说，假设今天有一个项目要铺设一条一百公尺的道路，工程预计进行五天，总投入的金额预估是十万元，相当于这条道路完工之后价值十万元。平均来看每一天照计划完成工作应获得相当于二万元的价值，或者每完成一公尺就会产生一千元的价值。当工程进行到第三天，如果完成超过六十公尺代表进度超前、反之则为进度落后。这时如果完成六十公尺的道路但投入的金额少于六万代表绩效超前、反之则为绩效落后。
套用在软件开发项目上，由于在软件开发的项目中很多时候不太容易计算出完成的功能值多少钱、每一行的源代码代表多少钱，对企业内部的软件来说更是如此。所以在这里就可以用一小时来代表一块钱，看币值是要设定成一人民币、一美元、一欧元还是一个单位的比特币，总之就是一单位金钱的价值，而先前的计算模式可以改为以时间单位来统计数据。
所以在实作软件开发项目的 EVM 时，假设一个功能预计投入 40 个小时、在五天之内完成。当开发工作进行到第三天时，如果完成进度大于 60% 则代表进度超前、反之则为进度落后。而当完成的进度是 60% 但投入的时数小于 24 小时代表绩效超前，反之则为绩效落后。这里用百分比来做为统计 EV 的模式是在经验法则上所得出比较直觉、一致、符合人性的做法，回报进度的人不需要了解什么是 EVM，只要记录今天花多少时间开发、完成多少百分比。而百分比则可以依照预计要完成多少源代码、区块、函式、功能等等的基准来和完成的部份比对以估计进度的百分比，在这样的评估方法之下成员之间不太容易有很大的差异出现，获得的进度数据比较平均、比较成员间进度差异时会比较客观。
在上述的数值中，PV 是累计到目前为止预计投入的时数、AC 则为累计到目前为止已经投入的时数、EV 则是 PV 的总数乘上进度的百分比。为什么 PV 是用预计投入的时数加总，而不是和 EV 一样使用百分比是有原因的。之前提到过每一个成员产值在单一的项目中不见得是个定值，碍于现实，在进行时程排定作业时有可能这个成员今天只抢到三小时、明天五小时，所以每天排定的预计投入时数都不一样，如此使用百分比这种平均法来计算会和实际的情况有落差。
使用 EVM 在管理上的重点
有人可能会想问如果成员浮报进度资讯有办法即时发觉吗？的确，也许是文化使然，总是会有一些人喜欢便宜行事。像是会觉得评估进度百分比很麻烦，所以固定在工作一开始就只设定一个固定的进度值，例如：50% 或 30%，等工作完成后再回报为 100%。或者是有好大喜功的心态，所有开始进行的工作都设定为 100%。这时可以由 EV 值的变化中发现，此时一开始 EV 数值会先出现不合理的拉高，但接下来却一直没有变化。而另外一种常见的情况是投入时数漏报、浮报，这种情况可以由 AC 与 PV 的差距异常地大来判别。最难察觉的是回报的数据是在配合计算规则下所“设计”出来的，这时数据会呈现梦幻般完美的状态，稍一不注意则可能要到截止日才发现进度不如预期，不过这时有配合 Code Review 还是可以看出一些端倪。
这套收集数据的模式有一个优点是每一个工作项目可以是独立的观察基准，也可以依据情境将不同的工作项目集中观察。可以是以整个项目为集中的单位、可以是以 Product Backlog 为集中的单位、可以是以 Sprint Backlog 为集中的单位、也可以是以某一个开发人员所负责的工作为集中的单位。尤其是最后一项观察基准，对于角色是属于 Functional Manager 的人来说是一个很好用的工具。在以人为单位所产出的 EVM 资讯可以获得二项重要的情报，一是透过时程安排的情况来了解在多重项目交互之下是否有负荷超载的情况，并且可以精细到每一天。第二项情报是在将清单中所有工作项目数据合并之后，可以得到单一开发人员的综合进度数据，同时不会因为实际执行工作的顺序与 PV 设定不同而有差异。可以有效地降低项目之间的界线，避免因项目间资讯不通透而无法反映个人进度上的问题。
同样的优点也可以展现在以项目为单位的观察基准，在进行开发项目时，很多时候是多个工作项目同时开始，而开发人员并不需要受限于原本设定好的工作执行顺序，只要依照实际工作的情况回报数据即可。假设原本排定 B 工作要接在 A 工作之后才开始，而今天上工后同时进行 A、B 二项工作一共花了六小时。此时，进度百分比可以明确地分别依工作项目产出的状态计算出来，不会有什么问题。而投入的时数则可以视情况，如果有精确到记录每一项工作投入的时间最好，如果没有，都合并记录在特定一项工作项目也行。在这样的情况下，也许单一的工作项目在数据上会呈现失真的状态，但拉高层次来看时却不会有差别，因为数字加总过后会消弭掉工作项目之间的界线。
如果要硬性要求开发人员必须照着设定好的工作执行顺序按步就班完成工作，最大的问题是可能会造成开发的工作无法进行，或是要花更多的时间在来回修正工作项目间不同步的源代码。如此一来，在回报数据上也许不会有项目归属的争议，但却阻碍了开发工作且失去了管理的意义。所以这个手法在实作时其实没有必要执着在 PV 的设定结果，这只是一个收集数据的参考基准，重点应放在投入的时数与完成的进度。
这套方法还有另一个弹性是在需求有异动、要调整某一项工作项目的预估投入时数时，也只要在适合的时间点补上差异的时数即可，不用特意重新调整过去 PV 的状态，也不会影响成员回报的模式，所统计到的数据可以在过去的资讯基础上持续地演进。时程会不断的变化就让他变化吧，反正重点是要随时掌握目前的进度情况。
当然，天下没有白吃的午餐，这套追踪的方法可以比 Burndown Chart 提供更多的资讯，是因为在输入数据时要投入更多的功夫。如果想要以天为观察的单位，在安排时程的时候就必须要为每一天设定好 PV 值，相对地在情况有变动时数据的调整工作也会变得比较繁琐。用拉大时间间距的方式，改为以周、月为单位虽然可以有效减少数据维护的频率，同时也会降低数据反映问题的敏感度，这取决于每个团队的管理需求。
把 EVM 的信息视觉化
只是盯着数字看可能还不够直观，依据 EVM 的公式可以得到二项数据 SPI 及 CPI，分别是 EV 与 PV 及 EV 与 AC 的比值，把 SPI 与 CPI 做成图表就如同以下所示：
图上所示范的曲线代表不同时间点数据的位置所连接起来的结果，红色星形为最早的时间点。图中两轴交会的点并不是原点，而是座标 (1, 1)，或许可以称为理想点吧！原点在图上左下角的位置。这样绘制的原因是因为 SPI 及 CPI 都是二个数值的相除结果，大于一代表超出预期，小于一代表不如预期。所以当二个数值所形成的座标落在图上两轴交会处，代表目前投入的工时与产值是符合原本规划的时程，也就是说理想化的情况之下所有的点应该都集中在同一点，不过理想归理想，如果一切都这么完美就不需要管理人员了。
透过这二个数据呈现的图形可以直观地了解目前项目进度的状态、并随着时间的演进呈现出进度的趋势，范例的图上四个象限都分别用文字标示出所代表的意义。SPI 是用来看已完成的进度有没有依照计划进行，如果小于一会落在 Y 轴的左方、大于一则是会出现在 Y 轴的右方。CPI 是用来代表投入的时数是否有获得对等的价值，如果小于一会落在 X 轴的下方、大于一则是会出现在 X 轴的上方。最接近理想的情况应该是像上图所示范的，所有的落点都绕着理想点打转。
所以当点都落在第一象限上就是值得欣慰，而落在第三象限上就是待改进吗？其实并不尽然，会影响 SPI 与 CPI 的数值不单单只有人的产值，PV 值估算的精确程度、投入工时的方式都有很大的影响。比如说，SPI 大于一有可能是因为 PV 值在估算时过于宽松，原本二个小时的工作估到四小时，所以照计划投入了一小时反而得到了四小时一半也就是二小时的价值。或者也有可能是人员爆肝、加班赶工所换来的假象，而类似的情况也会反映在 CPI 的结果上。
透过这样一个图表在管理时要关注的问题，不外是观察团队中成员基本的个人工作效率与负载问题、是不是遇到技术瓶颈以致进度迟滞不前、还是因外在或个人的因素导致工作无法顺利开展。在使用这个图表进行管理时，不用太在意点所落下的位置，应该要像 Burndown Chart 的概念一般，只要确认有维持产值的稳定就是一个可以接受的情况。就如同打靶时所形成的弹着点，弹着点的集中度要比有多少颗落在中心区域要来得重要。弹着点集中代表射手是稳定的，很有可能只是枪枝没有进行归零，反之则是各种因素都有可能，反而不容易进行调校。同时还要透过每一个点之间的关系来观察移动的趋势，如果开始朝着第一象限以外的区域移就应考虑着手找出原因并改善。所以当所有的点都落在第三象限时，不一定是表示目前进度的情况很糟，如果能让后续落下的点不会一直朝着原点的方向移动，就可以预测得出系统完成的日期，但日期是不是符合老板的期望就又是另外一件事了。
避免落入管理上的盲点
诚然，判读图表的方法很重要，如何判读图表却不是一个绝对值。所谓的管理是要找到一、二个合用的工具，并且在心中设定一把尺为做为使用工具时的衡量准则，这个准则是要依据现况来做调整。因为每一个项目都是独特的，项目外在的因素、团队的成员、工作时的气氛，都不会有一模一样的情况出现。教科书上的理论永远不可能完美地实现在工作的场合里，硬是要把理论套用在管理上有的时候只会适得其反。
像是如果拿着上面 EVM 的图表当令箭，强制一定要让回报的数据所形成的点都落在之前说的理想点上，可以想见团队在工作时的感觉一定是非常的斯巴达，最后搞得成员怨声载道，而管理的人也会因为紧迫盯人变得工作量大增，结果是让所有人都工作得不开心。
管理的情况就像全职猎人漫画中，杰在贪婪之岛中为了要得到一坪的海岸线与关主磊札用排球对打的时想出来的接球组合：
中间的奇犽是管理阶层，夹在老板 (杰) 与团队 (西索) 之间，老板要负责承接来自外界的压力并创造机会，团队则要负责把握住机会。管理者看起来没做什么，但其实位在最关键的位置，在中间的管理者要如何分配力道、协调二边，只有站在中间的人才最清楚，也是管理者展现修为的时刻。在面对情况要怎么因应是管理者必须审慎以对的，一旦稍有差池就有可能像漫画剧情中所叙，整个团队会因受到外力冲击而溃散。
结语
所以，每一个人在面对管理上的情况要如何拿捏，还真得没有人能够说得准。因为处理的结果好与坏，在现实中就是结果论，成王败寇没什么好说的。在这篇文章中，只是把个人过去的工作心得整理出来，让大家做个参考，也许可以对同样是管理者的人有所启发，找到适合自己的工具、建立起心中的那把尺。