不,不是字面意思。相反,您是否有任何繁文缛节的恐怖故事影响了您生产优质软件的能力?我不是在谈论像这个问题这样的一般人力资源或系统管理政策,而是直接针对开发过程的政策,例如糟糕的源代码控制政策、测试程序或错误跟踪过程。
拜托,没有诸如缩进与空格或支撑样式之类的圣战,而是令人讨厌的官僚主义的例子,例如传说中的 TPS 报告。
这与我有些相关,因为我一直在审查我的团队的开发过程,并且我希望看到(作为上下文)您必须处理的一些最糟糕的过程。结构化的政策或流程何时会走得太远?
我确实为我工作的其中一个系统提交了 TPS 报告:http: //tps.tmccom.com/
是的,我非常清楚该网站的过时和非标准化程度。
作为承包商,我经常不得不提交三份单独的时间和费用报告。
我们用于开发票的官方报告。
我们特定于项目的细粒度报告。它必须与总发票报告相匹配。而且,项目经理可以在发票数字前两周使用它。
出客户的活动报告。这些也必须与总发票相匹配。客户的会计人员需要这个来确认我们的发票。等等,我不是也创建了发票吗?
我们不要忘记需要两个状态报告(我们的和客户的)。
不,但几年前我为阿拉巴马州编写了大部分 MLI(强制性责任保险)系统......
系统生成的每个报告都是 TPS 报告 :)
例如每月交易 TPS 报告、每日交易量 TPS 报告等。
最有趣的是,该州有人打电话给我们询问 TPS 报告 :) 我认为他们从来没有弄清楚为什么他们被称为 TPS 报告。
在过去的几年里,我们必须填写一张由一线主管签署的请假单,以便请病假或休假。
最近,我们获得了访问一个精美的 Web 应用程序的权限。它允许工人请求休假,并允许主管批准休假。它汇总到我们的时间表中,是我们工资系统的基础。
尽管在推出新的请假系统方面取得了巨大成功,但我们的办公室经理仍然要求我们提交纸质请假单,除了在线提交。
办公室经理花了几个月的时间才意识到新系统提供的监督与手动系统一样多。
在一家大型旧计算机公司的前一份工作中,我们有一个 CRT 流程。我不会说这是一个非常糟糕的想法,因为该软件产品涉及高可用性计算,因此非常规避风险。但这有时很烦人,并且肯定会减慢开发速度。
基本上,该系统是在让 3 个人对您的代码进行同行评审后,您填写了 CRT 表单(在某些时候我将其转换为 Web 应用程序)。
CRT(变更请求团队)每周会审查所有请求数次,并与管理层、团队负责人和相关编码人员讨论,以确保所有环节都已通过:所有编写的测试......适当的人已经审查它... QA 通知了新的测试...等。
值得庆幸的是,Web 应用程序版本得到了很好的接受,并且非常详细且超出顶部的旧手动表单已被删除。至少从我们的组织...
我目前必须在三个独立的实用程序中概述我的时间:
我以高水平输入我的时间(咨询时间 vs. 假期 vs. 假期 vs. 生病等),为期一周,显示每天的工作时间。这是为客户计费的。
客户有一个他们刚刚推出的时间跟踪系统,我们必须在请求级别输入我们的时间。与客户相关的事情(会议、培训等)的管理时间有它自己的通用存储桶。不可计费的项目有另一个。这个为期一个月,显示每周的小时数。
我的公司还有一个时间跟踪工具,详细说明我们在一周内所做的一切。时间以一刻钟为单位进行跟踪,并且粒度非常细。即“对于请求 12345,我花了 0.25 小时编写估算,0.50 小时编写需求文档,0.50 小时编码文件 x。” 在我们将任何内容发送给客户以供批准之前(早在任何内容被编码之前),还必须将估算值输入系统并有效锁定(瀑布 FTL!)。
我们也有一个非常严格的同行评审过程。我们发送给客户的任何官方文件(需求文档、变更请求、代码等)都必须先经过同行评审。客户还有一个变更控制委员会,该委员会每周开会一次,以批准将安装到生产中的任何东西。
我曾经向一些大学朋友解释过我的工作有多少过程和偏执。到最后,我发现假设情况(在非紧急、非生产支持情况下),在考虑了所有过程之后,在现有报告中添加单个字段的估计值,在 ABSOLUTE MINIMUM 上花费了 3 个小时,这基本上是在现有的 select 语句中添加一个字段(或者类似的东西,因为我们使用了一个不使用 SQL 进行 DB 查询的工具)。此外,由于对此的估计是如此之小(因为三个小时仅代表每个所需项目所需的最少 0.25 小时,加上生产变更控制会议的半小时),我需要让我的团队领导先签字,因为我
*叹*
我想今天的吐槽就够了。