blocks|key|212930|text|作为一名承包商，我经常不得不提交三份独立的时间和费用报告。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212931|212932|我们用于开票的官方报表。|ordered-list-item|212933|我们特定于项目的细粒度报表。它必须与汇总发票报告相匹配。而且，项目经理可以在发票上的数字前两周获得。|212934|输出客户的活动报告。这些也必须与总发票相匹配。THe客户的会计人员需要这个来确认我们的发票。等等，发票不也是我开的吗？|212935|212936|我们不要忘记需要两个状态报告(我们的和客户)。|212937|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

As a contractor, I've often had to file three separate time and expense reports.

<ol>
<li>Our official report used for invoicing.</li>
<li>Our project-specific fine-grained report. It has to match the aggregate invoicing report. And, it's available to project managers two weeks before the numbers from the invoices.</li>
<li>Out customer's activity reports. These have to match the aggregate invoicing also. THe customer's accounting folks need this to confirm our invoices. Wait, didn't I create the invoices, also? </li>
</ol>

Let's not forget the need for two status reports (ours and the customers.)

blocks|key|3430456|text|从字面上讲，我为我工作的一个系统归档TPS报告：http://tps.tmccom.com/。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3430457|是的，我非常清楚这个网站是多么的过时和不规范。|3430458|entityMap|0|LINK|mutability|MUTABLE|url|http://tps.tmccom.com/^0|O|M|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I quite literally file TPS reports for one of the systems where I work: <a href="http://tps.tmccom.com/" rel="nofollow noreferrer">http://tps.tmccom.com/</a>

And yes, I am very much aware of how outdated and non-standardized the site is.

blocks|key|4278309|text|不，但几年前，我为阿拉巴马州撰写了MLI+(强制性责任保险)系统的大部分内容……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4278310|系统生成的每个报告都是TPS报告:)|4278311|例如月度交易TPS报告、每日成交量TPS报告等。|4278312|最有趣的是，州里的人会打电话给我们，询问TPS报告:)我认为他们从来没有想过为什么他们会被称为TPS报告。|4278313|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

No, but a few years ago I wrote the bulk of the MLI (Mandatory Liability Insurance) system for the State of Alabama...

Every report that the system generated was a TPS report :)

E.g. The Monthly Transaction TPS Report, The Daily Volume TPS report etc.

It was most amusing when someone from the State would call us up asking about the TPS reports :) I don't think they ever figured out why they were called TPS reports.

blocks|key|3430518|text|在过去的几年里，我们必须填写一张由一线主管签名的请假条，以便请病假或休假。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3430519|最近，我们获得了访问一个花哨的web应用程序的权限。它允许员工申请休假，并允许主管批准休假。它记录在我们的考勤表中，是我们工资系统的基础。|3430520|尽管在推出新的请假系统方面取得了巨大的成功，但我们的办公室经理仍然要求我们除了在线提交纸质请假条外，还需要提交纸质请假条。|3430521|办公室经理花了几个月的时间才意识到新系统提供的监督与人工系统一样多。|3430522|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

For the last several years we had to fill out a leave slip, signed by our first line supervisor, in order to take sick time or vacation. 

Recently we were given access to a fancy web-application. It allows workers to request leave and allows supervisors to approve leave. It rolls up into our time sheet and it's the basis of our payroll system.

Despite tremendous success in rolling out the new leave request system, our office manager still required us to submit the paper leave slip, in addition to doing it on-line. 

It took months before the office manager realized the new system provided just as much oversight as the manual system.

blocks|key|973922|text|在以前的一家大型老计算机公司工作时，我们有一个CRT过程。我不会说这是一个完全糟糕的想法，因为该软件产品涉及高可用性计算，因此非常厌恶风险。但它有时很烦人，肯定会减慢开发速度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973923|基本上，系统是，在3个人对你的代码进行同行评审后，你填写了一份CRT表单(在某种程度上，我将其转换为web应用程序)。|973924|CRT+(变更请求团队)每周会审查几次所有的请求，并与管理层、团队领导和程序员进行讨论，以确保所有的障碍都已通过:所有编写的测试……合适的人已经看过了.QA通知了新的测试...等。|973925|谢天谢地，web应用程序版本得到了很好的接受，旧的手册表单被丢弃了，这是非常详细和夸张的。至少在我们的组织里。|973926|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

At a previous job at a large old computer company we had a CRT process. I wouldn't say it was a completely awful over the top idea since the software product involved high-availability computing and was thus very risk averse. But it was annoying at times and certainly slowed down development.

Basically, the system was, after having your code peer reviewed by 3 people, you filled out a CRT form (which at some point I converted to a web application).

The CRT (Change Request Team) would review all the requests a few times a week and discuss with management, team leads and the coder in question to ensure all the hoops had been jumped through: All the tests written... appropriate people had reviewed it... QA informed of new tests... etc.

Thankfully the web application version was well accepted and the old manual form, which was really detailed and over the top, was dropped. At least from our organization...

blocks|key|973946|text|目前，我必须在三个不同的实用程序中概述我的时间：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973947|973948|我输入了一个高级别的时间(咨询时间vs.假期vs.休假vs.病假等)，显示了每周每天的工作时间。这个是给客户端计费的，|unordered-list-item|973949|客户端有一个他们刚刚推出的时间跟踪系统，我们必须在请求级别输入时间。与客户相关的事务(会议、培训等)的管理时间有自己的通用存储区。非计费项目还有另一个。这个是一个月的时间，显示每周的小时数。|973950|我的公司也有一个时间跟踪工具，详细记录我们在给定的一周内做的所有事情。时间是在一刻钟跟踪的，并且是非常细粒度的。即“对于request+12345，我花了0.25小时写一份预估，0.50小时写一份需求文档，0.50小时编码文件x。”在我们将任何东西发送给客户审批之前(在任何东西被编码之前很久)，还必须将预估输入系统，并有效地锁定(瀑布FTL!)。|973951|973952|我们也有一个非常严格的同行评审过程。我们发送给客户的任何正式文件(需求文档、变更请求、代码等)都必须首先经过同行审查。客户还有一个变更控制委员会，该委员会每周召开一次会议，批准将安装到生产中的任何内容。|973953|我曾经向一些大学的朋友解释过，我的工作到底有多少过程和偏执。到本文结束时，我已经计算出假设的情况(在非紧急、非生产支持的情况下)，在考虑了所有过程之后，向现有报告中添加单个字段的估计值至少需要三个小时，基本上是向现有的select语句中添加单个字段(或者类似于我们使用不使用SQL进行数据库查询的工具)。此外，由于对此的估计将非常小(因为这三个小时只代表每个必需项目的最小0.25小时，加上生产变更控制会议的半个小时)，我需要首先让我的团队领导签署它，因为我将与我们的估计工具所说的我应该用来更改代码的东西背道而驰(该工具主要基于LOC)。|973954|*叹息*|973955|我想今天的咆哮已经够多了。|973956|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Y|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

I currently have to outline my time in three separate utilities:

<ul>
<li>I enter my time at a high level (consulting time vs. holiday vs. vacation vs. sick, etc) for a period one week, showing hours worked per day on each. This one is for billing the client.</li>
<li>The client has a time tracking system that they just rolled out in which we have to enter our time at the request level. Admin time for client-related things (meetings, training, etc) has it's own general purpose bucket. Non-billable items have another. This one is for a period of one month, showing hours per week.</li>
<li>My company also has a time tracking tool, detailing everything we did in a given week. Time is tracked on the quarter hour, and is extremely fine grained. i.e. "For request 12345, I spent 0.25 hours writing an estimate, 0.50 hours writing a requirements document, 0.50 hours coding file x." Estimates also have to be entered into the system, and effectively locked down (Waterfall FTL!), before we send anything to the client for approval (long before anything is coded).</li>
</ul>

We also have a very strict peer review process. Anything official that we send to the client (requirements documents, change requests, code, etc) have to be peer reviewed first. The client also has a Change Control Board which meets once a week to approve anything that will be installed into production.

I once explained to some friends from college exactly how much process and paranoia surrounded my work. By the end of it, I'd figured out that the hypothetical situation where (in a non-emergency, non-production support situation), the estimate for adding a single field to an existing report, after all the process was taken into account, was three hours at the ABSOLUTE MINIMUM for what would essentially be adding a single field to an existing select statement (or something similar as we use a tool which doesn't use SQL for DB queries). Additionally, since the estimate for this would be so small (since that three hours represents ONLY the required 0.25 hour minimum for each required item, plus half an hour for the production change control meeting), I'd need to get my team lead to sign off on it first, since I'd be going so far against what our estimating tool says it should take me to change the code (this tool is largely based on LOC). 

*sigh* 

I think that's enough ranting for today.

No, not <a href="http://en.wikipedia.org/wiki/TPS_report" rel="nofollow noreferrer">literally</a>. Rather, do you have any red tape horror stories of policies that affected your ability to produce quality software? I'm not talking about general human resources or systems administration policies like <a href="https://stackoverflow.com/questions/195285/what-stupid-policies-affecting-developers-has-your-company-introduced">this question</a>, but policies that were directly targeted at the development process, such as bad source control policies, testing procedures, or bug tracking processes.

Please, no holy wars such as indents vs. spaces or bracing styles, but rather examples of loathsome bureaucracy, like the TPS reports of <a href="http://chrisglass.com/journal/downloads/TPSreport.pdf" rel="nofollow noreferrer">legend</a>.

This is somewhat relevant to me as I've been reviewing my group's development process, and I'd like to see (for context) some of the worst processes that you've had to deal with. When does a structured policy or process go too far?

Have you ever had to file "TPS reports"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

不，不是。相反，您是否有任何影响您生产高质量软件的能力的政策的官样文章和恐怖故事？我指的不是像这样的一般人力资源或系统管理策略，而是直接针对开发过程的策略，例如糟糕的源代码控制策略、测试过程或错误跟踪过程。请不要圣战，比如缩进、空格或支撑样式，而是令人讨厌的官僚作风的例子，比如的TPS报告。这在某种程度上与我有关，因为我一直在审查我的团队的开发过程，我想看看(作为背景)你必须处理的一些最糟糕的过程

问你有没有提交过"TPS报告“？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你有没有提交过"TPS报告“？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问你有没有提交过"TPS报告“？
EN