90%做维护，10%做开发，这正常吗？
jopen 12年前
<blockquote> <p>译注：这篇译文来自 <a href="/misc/goto?guid=4958346312333162247" rel="nofollow" target="_blank">Stack Exchange</a> 上的一个提问，在许多开发者中都产生了共鸣。很多时候，作为程序员的我们，在日常工作中并没有很多时间用在编写代码上，而是不断的在维护某个年代久远的系 统，不断的 bug fix，维护的项目会越来越多。如果我们希望能改进已有的代码，对系统做下重构，有时候并不能得到公司的支持。提问者声称自己的报酬非常低，但却在做整个 开发团队级别的工作，这到底正常吗？难道所有的开发者都是这样的？以下两个回复获得了大多数开发者的认同，想学习下如何同公司高层沟通的技巧吗？</p> </blockquote> <p> TiredProgrammer 6 月 12 日：</p> <p> 我在一家中等规模的公司里做 Web 开发。刚开始的时候，我的任务是对一个已有的应用做扩展（这个项目的代码很糟糕，是由多个程序员花了好几年时间开发的，他们用不同的方法处理相同的任务，而且基本上没什么结构可言）。</p> <p> 当我成功的按照需求完成了对应用的扩展后，公司让我全职负责对这个应用的维护工作。这当然没问题，或许只有我是这么想的。但是公司却禁止我去改进已有的代码，只让我集中精力解决 bug——如果有 bug 报告的话。</p> <p> 从那时起，我又陆续接手了 3 个类似这样的项目，现在我都得一起维护。之后，我又被委任了 4 个项目——这次可以从头开始创建整个应用，当然了，这些新开发的项目我也得去维护。</p> <p> 现在，我快被每日不断的用户邮件给搞疯了，我所负责维护的每一个应用都是这样。公司希望我能直接处理这些邮件中提到的问题，同时又丢给我 2 个新项目（这之后已经有 5 个项目在排队等着了）。杯具的是，对于我自己编写的代码，我还没有收到任何 bug 报告，只是偶尔会有那么一些脑残要求希望彻底颠覆原来的需求。</p> <p> 无论如何，这正常吗？在我看来，我一个人做的工作顶得上一整个开发团队了。我最初预想的可不是这样的啊，我是白痴吗？我猜这个帖子可能会引起网上的大论战，但请告诉我，并不是每一个开发者都遇到了我这种情况。<strong>P.S. </strong><strong>我的薪水几乎和超市的收银员一样多，如果不比他们低的话。</strong>（亮点…）</p> <p style="text-align:center;"><a title="Developer" rel="lightbox[22735]"><img title="Developer" alt="90%做维护，10%做开发，这正常吗？" src="https://simg.open-open.com/show/3234c450098c16d292e2da61148ee9a2.jpg" width="425" height="282" /></a></p> <p> acattle 最后编辑于 6 月 13 日：</p> <p> 我在实习的时候也发现有很多时间都花在解 bug 上了。你必须意识到作为初级程序员，你没法获得更有挑战性的工作，你得从没人愿意干的脏活累活干起。这当然是不幸的，但这条规律适用于所有的工作。</p> <p> 另外，你得认识到一点，对于公司来说，能正常工作的代码远比清晰的代码更重要。从你所在的公司的角度来看，修改已有的代码库是在浪费金钱，你不 过是在重做已有的东西，而且还可能会带来更多潜在的错误。通常这种类型的公司都不是计算机/软件公司，因此高层都缺乏足够的技术背景来理解你要做的这种大 改动的意义。也就是说，如果你所在的公司是技术型公司，由懂技术的人来管理，他们能够理解好的代码所带来的价值的话，你可能还会有更多的余地，尽管有时候 你还是需要选择一下战场（毕竟，生意的主要目的还是为了赚钱）。</p> <p> 那就是说，丢下你现在的工作而期望得到更有意义的工作是不合理的。同样令人遗憾的是，你不得不同时处理由各个不同的项目经理针对各个项目提出的要求。</p> <p> 作为一名程序员，事实就是比起你自己从头写起代码的时间，你要花费更多的时间在维护和修改其他人的代码上。如果这对你来说难以接受，也许你应该 只把开发当成一项爱好，然后选择别的行业谋生。如果你对维护代码没有什么异议，但感觉工作并没有使自己发挥出全部的功效，或者觉得自己快被工作榨干了，那 么你需要同你的经理好好探讨一下你的工作模式。如果你面临的问题比这个更严重，或者如果你感觉经理并不知道如何有效的根据你的技能来管理你的工作，那么考 虑换个新公司应该是个好主意。根据你提到的低工资，跳槽可能是你现在最好的选择。</p> <p> Péter Török最后编辑于 6 月 13 日：</p> <p> 看起来似乎是管理层在任务优先级的选择和工作量的管理上出了问题。你应该同你的经理谈谈，让他们知道你的工作已经过载了，如果每个人都跑过来烦 你，让你完成他们马上想达成的要求，这样你就无法继续有效的工作了。那样会让你从一个任务跳到另一个任务，浪费了大量的时间在切换思维上。对于高效率的软 件开发工作来说，你应该只全身心投入到一项任务中去。有越多的中断和干扰，你就要花越多的时间在环境切换上。有研究显示，大约 15 分钟的时间能让你进入专注的状态，此时你的思维是最有效率的。如果你每 15 分钟被中断一次，你永远也无法专注下去，这对你和公司都是很大的浪费。</p> <p> <strong>因此你应该试着和你的经理沟通，达成一个更加合理的工作模式。</strong>这应该包括<strong>对任务进行优先级划分，并在某种程度上提前进行规划</strong>。所有的用户需求都应该按照优先级的顺序记录在列表上。并且，<strong>优先级不应该由需求的发起者来指定</strong>（自 然地，大家都会认为自己的需求是世界上最重要的），也不能由你自己来定，而应该由某个拥有足够多的商业知识以及对你维护的一系列产品有着全局认识的人来指 定（产品经理）。理想情况下，所有的需求请求都应该被录入到问题追踪系统如 Jira 或者 Mantis 上，或者至少给产品经理发送邮件，而不是直接发给你。应该由他/她去负责处理 “为什么我的需求还没有完成？”这样的用户抱怨，而让你集中精力在开发工作上。如果这种情况难以实现的话，当你在处理新的需求时，你至少要和经理沟通协商 出一段时间，这段时间内你不能被打扰，只负责开发工作。</p> <p> 如果上面的做法可行，下一步就应该是提前做好规划。比如，估计一下完成最高优先级的任务需要多少时间，然后将你的时间划分为各个“冲刺阶段”， 每个阶段可能是 1 周或好几周时间，为你的下一个冲刺阶段安排满足够多的任务。你可能还希望保留一段时间以应对紧急的需求，但其余的都可以提前规划好。你也可能更希望将不同 项目的工作划分到不同的时间点上，比如，项目A就安排在周 1 解决，周 2 到周 3 是项目B，周 4 上午可以做项目C，下午就可以做项目D等等，以此进一步的减少任务间的切换。按照这种方式，你对于未来 1 周或几周的工作任务就有了大致粗略的了解。此外，这也为你的客户提供了一个路线图：他们可以了解到他们的请求何时可以得到解决。这里你可能不会想对你的经 理提到“敏捷”这个词——这基本上就是敏捷开发，但有些人并不清楚敏捷开发到底是什么，他们就是一味地反对。</p> <p> 尽管你现在的职位看起来报酬很低，可是<strong>你维护的项目越多，你就越有资本来沟通协商</strong>。对于公司来说，招一个新 人进来给他培训，再让他维护所有这些项目需要花费相当长的时间（时间就是金钱）。你可以正当的指出你的代码比原有的部分要好的多，所以从公司的方面来说， 他们没法轻易的以同样的价钱雇到一个合适的候选者来完成同样的工作。更不用说如果他们不改善工作条件的话，他们雇到的下一个家伙很快也会像你一样受够了就 退出不干了。<strong>试着让公司懂得让你快乐的留在公司对公司是最有益的</strong>。这会给你一些资本来和公司协商以上的情况，并要求加薪。</p> <p> 你究竟有多少谈判的资本——这是个大问题。管理层可能会也可能不会对你的请求有足够的尊重。但如果你把握的够好的话，你就有机会。如果他们拒 绝，你总是可以再去寻找更好的工作。这种情况对于每个职场菜鸟来说并不相同，虽然（很悲催的）你的经历是相当典型的。但是确实总是有更好的工作地点在那等 着。工作场所的好坏同地理位置的关系联系并不大，但给我的感觉是，在欧洲北部你可以获得的机会比平均水平要高一些。因此，在你完全受够之前，<strong>如果你无法显著改善现在的工作条件，你应该马上开始寻找新的工作机会</strong>。骑驴找马总是很好的，所以你不要因为需要用钱就立即接受第一份 offer。最终你总会找到一个更好的去处的。</p> <p> 英文原文：<a href="/misc/goto?guid=4958346312333162247" rel="nofollow" target="_blank">StackExchange</a> 编译：<a href="/misc/goto?guid=4958185140659301754">伯乐</a>在线— <a href="/misc/goto?guid=4958346314623169538">陈舸</a></p>