离职后 重写的软件 侵权_重写软件产品，请先阅读

离职后 重写的软件 侵权

So you just received the 10th customer complaint over the same issue you thought was fixed three weeks ago.

因此，您刚刚收到了您第三周就解决的同一问题的第十次客户投诉。

Your heart has been racing for what feels like months straight, and you can’t even glance at the customer support log without a freight train of anxiety hitting you.

您的心一直在竞相竞相追逐数月之久，如果没有一班焦虑的货运火车袭击您，您甚至无法浏览客户支持日志。

You know your software product is buggy. It seems like your developers are producing more bugs than features, and they insist that the software is just too much of a mess to work with.

您知道您的软件产品有故障。 看来您的开发人员产生的bug多于功能，并且他们坚持认为该软件太混乱了，无法使用。

You’ve come to the very hard decision that a total rewrite is necessary in order for your product, and your sanity, to survive…

您已经做出了非常艰难的决定，即必须进行完全重写才能使您的产品和理智得以生存……

But wait! There are different ways to approach a rewrite that doesn’t necessarily entail throwing away the original product. Below are a few suggested questions to ask yourself and actions to take.

可是等等！ 有多种方法可以进行重写，而不必重写原始产品。 下面是一些建议的问题，供您问自己和采取的行动。

问自己，为什么需要重写？ (Ask Yourself, Why is this Rewrite Necessary?)

You really need a rock solid answer to this. If you can’t articulate this to yourself or a colleague, you aren’t ready to invest in a rebuild of your product.

您确实需要对此做出坚定的回答。 如果您无法向自己或同事阐明这一点，那么您就不准备投资进行产品重建。

It’s easy for the frustrations of customers and complaints from your development team pressure you into blowing up a product and starting new, but it’s important to know the cost / benefit of doing a rewrite before jumping in.

对于客户的不满和开发团队的抱怨来说，这很容易使您不得不炸毁产品并开始开发新产品，但是在跳入之前了解重写的成本/收益很重要。

Write down on paper the justification of the rewrite so when you inevitably think “is this really necessary?”, you have a clear reminder of why you’re doing it.

在纸上写下重写的理由，因此当您不可避免地认为“这真的有必要吗？”时，您会清楚地知道为什么要这样做。

To help you ballpark whether or not a rewrite is necessary, here some common signs it’s time to scrap and rebuild:

为了帮助您确定是否有必要进行重写，以下是一些常见的迹象，是时候应该进行废弃和重建：

• Small changes result in unexpected bugs in seemingly unrelated places
  细微的变化会在看似无关的地方导致意外的错误
• Your development team is often hesitant and / or pushes back on feature work you send their way
  您的开发团队经常会犹豫和/或推迟您按原样发送的功能工作
• You want your product to move in a new direction that it wasn’t design or engineered for
  您希望产品朝着非设计或工程化的新方向发展
• It takes significantly more time and money to onboard developers than it should
  机上开发人员所花费的时间和金钱大大超过了应有的时间
• Simple bug fixes take far too long to complete
  简单的错误修复需要很长时间才能完成

缩小重写的MVP(Narrow Down the MVP of Your Rewrite)

Approach the re-development of your software product as if you’re aiming to build another MVP.

好像您打算构建另一个MVP一样，进行软件产品的重新开发。

The challenge of re-writing a product is that (usually) you aren’t introducing anything new, you are trying to get back to where your 1.0 product is feature wise.

重写产品的挑战是(通常)您不会引入任何新内容，而是试图回到功能明智的1.0产品的位置。

For example, while working on the new web banking platform at Synchrony Financial, it was decided that rather than completely rebuild every feature of the legacy platform on launch day, we simply linked to old parts of the platform for non-mission-critical features.

例如，在Synchrony Financial开发新的Web银行平台时，我们决定与其在发布之日完全重建旧平台的每个功能，不如将其旧版链接到非关键任务功能。

We omitted the ability to create new banking accounts, since the signup flow was a significant undertaking. Instead we focused on existing customers and their ability to manage their accounts. Editing your profile was delegated to the legacy platform, as well as requesting paper checks, and other things people generally don’t spend much time on.

由于注册流程是一项艰巨的任务，因此我们省略了创建新银行帐户的功能。 相反，我们专注于现有客户及其管理帐户的能力。 编辑个人资料的工作委托给了旧平台，并要求进行纸质检查，而其他事情通常不会花很多时间。

While the end result isn’t a picture perfect experience, for the most critical user paths, it works great. This saved months of development time, and most importantly, saved dollars.

尽管最终结果并非完美的图片体验，但对于最关键的用户路径而言，它的效果很好。 这节省了数月的开发时间，最重要的是，节省了资金。

探索增量重写 (Explore an Incremental Rewrite)

Rather than blow up your product entirely, figure out whether or not you can gradually replace existing components of your software, and do incremental releases. Often times you don’t need to start from zero!

而不是完全破坏您的产品，要弄清楚您是否可以逐步替换软件的现有组件并进行增量发行。 通常，您不需要从零开始！

This isn’t always possible, as the nature of a spaghetti code system is that components are so tightly dependent on one another that it makes it extremely difficult to update any individual component.

这并非总是可能的，因为意大利面条代码系统的本质是组件之间非常紧密地相互依赖，以致于很难更新任何单个组件。

Your development team will know best whether or not this is a possible path, but an incremental rewrite can allow stability to reach your customers much faster than a waterfall style rewrite.

您的开发团队将最清楚地知道这是否可行，但是增量式重写可以比瀑布式重写更快地达到客户。

购买损坏的东西… (Buy What’s Broken…)

Are there pieces of your software that can simply be bought as a SaaS or PaaS product?

您是否有一些软件可以简单地作为SaaS或PaaS产品购买？

It’s 2020, and software is cheaper than ever. Especially software that helps you build software! There might be a piece of your product that can be “outsourced” to a vendor.

现在是2020年，软件比以往任何时候都便宜。 特别是可以帮助您构建软件的软件！ 您的产品可能有一部分可以“外包”给供应商。

Perhaps you have a custom built CMS, or maybe you decided to use open source software because it was free rather than pay a subscription for something premium.

也许您有一个定制的CMS，或者您决定使用开源软件，因为它是免费的，而不是付费订阅。

User authentication causing problems? Find an authentication as a service provider.

用户身份验证引起问题吗？ 查找作为服务提供商的身份验证。

Nobody likes to increase their monthly bills, but if a $50 / month subscription saves you $5,000 and 140 development hours, it’s a no brainer.

没有人喜欢增加他们的每月账单，但是如果每月50美元的订阅可以为您节省5,000美元和140个开发小时，那是不费吹灰之力的。

减少开发时间 (Reduce Development Time)

It’s not uncommon for developers to re-invent the wheel for common problems. When going through with a rewrite, you need to find any areas you can save time and money in.

对于常见问题，开发人员重新发明轮子的情况并不少见。 进行重写时，您需要找到可以节省时间和金钱的任何区域。

If you aren’t very technical, this may seem like mumbo jumbo, but if your development team is solid, they should already be thinking about this stuff.

如果您不是很熟练，那么这可能看起来像个庞然大物，但是如果您的开发团队很扎实，他们应该已经在考虑这些东西。

If you have a lot of complex forms in your UI, seek a solid form library.

如果您的UI中有很多复杂的表单，请寻求一个可靠的表单库。

Rather than build custom UI components, use a library like Material UI or Semantic UI and change the styling.

与其构建自定义UI组件，不如使用Material UI或Semantic UI之类的库并更改样式。

Don’t have the resources to manage a database and API? It’s 2020 dude! Serverless tech is mainstream. See if something like Firebase firestore + authentication + functions fits your needs and save yourself a ton of time.

没有资源来管理数据库和API？ 这是2020老兄！ 无服务器技术是主流。 查看诸如Firebase firestore +身份验证+功能之类的东西是否满足您的需求，并节省大量时间。

The point is, buy / use other software to ease the development of your own. Try to stick to well supported technologies, otherwise it can be just as bad as rolling out your own solution.

关键是，购买/使用其他软件可以简化您自己的开发。 尝试坚持使用受支持的技术，否则可能与推出自己的解决方案一样糟糕。

Aside from the time & money you will save on development, you will also save a ton of time finding & onboarding developers (if you’re fortunate enough to be able to bring on more devs).

除了节省时间和金钱，您还可以节省开发时间，还可以节省大量时间来寻找和入职开发人员(如果您有幸能够招募更多开发人员)。

重建前获取专家意见 (Get an Expert Opinion Before Rebuilding)

Maybe you don’t have an in house development team. Perhaps your product was built by an offshore team you hired on Upwork, and now you have one or two developers around to maintain it.

也许您没有内部开发团队。 也许您的产品是由您在Upwork上雇用的离岸团队开发的，现在您有一个或两个开发人员来维护它。

Sometimes you just don’t trust your developers to evaluate the necessity of a rewrite of your product.

有时，您只是不信任开发人员来评估重写产品的必要性。

Or maybe you don’t feel like you have enough information to come to this decision yourself.

或者，也许您觉得自己没有足够的信息来自己做出此决定。

In this case it’s a good idea to invest in a consultant who can spend time to understand your product, your customers, and your current position.

在这种情况下，最好投资顾问，他们可以花时间了解您的产品，您的客户和您的当前职位。

If you happen to have a web product, I can definitely help you determine whether or not it’s time to rebuild your product, as well as recommend any better alternatives.

如果您碰巧有一个Web产品，我绝对可以帮助您确定是否应该重建您的产品，并推荐其他更好的选择。

了解哪里出了问题 (Understand What Went Wrong)

If you and your development team can’t pin down exactly what is wrong with your current product, then you aren’t ready to rebuild it.

如果您和您的开发团队无法确切确定当前产品的问题所在，那么您就不准备重建它。

A rewrite doesn’t mean throwing the old code out the window and blindly starting new.

重写并不意味着将旧代码丢到窗外并盲目地启动新代码。

The old product bundle of lessons learned, and a rewrite should come after you have understood all the lessons it had to teach.

在您了解了所有旧课程之后，应该将旧的产品课程吸取教训，并进行重写。

了解成本 (Understand The Costs)

If you are rebuilding your product, then you should understand by now that there is no substitute for quality.

如果您要重建产品，那么您现在应该了解，质量无可替代。

However, this quality will likely come at a higher cost than the development of your legacy product (not always the case).

但是，这种质量的成本可能会比传统产品的开发成本高(并非总是如此)。

It’s important not to commit to a rewrite while prioritizing cost savings over the quality of your product.

重要的是，不要在保证成本优先于产品质量的同时进行重写。

Bad developers at a low rate will cost you far more money than good developers at a high rate.

低利率的不良开发人员比高利率的良好开发人员要花更多的钱。

That being said, good developers on a shoe string budget aren’t magicians either.

话虽这么说，但预算有限的优秀开发人员也不是魔术师。

Make sure you have the resources to sustain a realistic timeline with a scope up work that will set you up for success, not a second failure.

确保您有足够的资源来维持切实可行的时间表，并进行范围扩大的工作，这将使您成功，而不是第二次失败。

Speaking of scope…

说到范围...

明确定义范围 (Clearly Define the Scope)

Once you get past the dread of having to rebuild your software, what awaits is a world of endless possibilities.

一旦您摆脱了必须重建软件的恐惧，等待的就是无穷无尽的世界。

The famous “if you could start over, what would you do differently?” question becomes a reality for you.

著名的“如果你能重新开始，你会做些什么？” 问题对您来说成为现实。

You will want to implement all of the amazing ideas you have that you couldn’t execute before.

您将要实现以前无法执行的所有奇妙想法。

Don’t do it. As sad as it is, try to keep a little bit of that dread around, because it will keep you level headed enough to humble the scope of your rewrite.

不要这样尽管很难过，但请尽量避免这种恐惧，因为这会使您保持足够的头脑，以至于无法覆盖重写的范围。

Often times a bad product is the result of too many ideas executed on too few resources. The last thing you want is for your 2.0 to work as poorly or worse than your 1.0.

通常，劣质产品是在太多资源上执行过多创意的结果。 您想要的最后一件事是使您的2.0的性能低于或低于您的1.0。

As I mentioned in the first point, if you approach rewriting your software as you would an MVP, you will likely steer clear of this issue.

正如我在第一点中提到的，如果您像MVP一样重写软件，则可能会避免此问题。

结论 (Conclusion)

If you are in the position where you are debating a rebuild of your software product, I hope the above points have given you plenty to think about!

如果您正在讨论重新设计软件产品的职位，希望以上几点能给您带来很多思考！

It’s rarely a cause for celebration when you come to the conclusion that rebuilding your software is necessary, but if done correctly, the end result can take your business to heights not previously possible.

当您得出结论认为必须重建软件时，很少会为此感到高兴，但是如果正确完成，最终结果会使您的业务达到前所未有的高度。

If you have a web based product, and need a software engineer who can help you analyze, plan, and / or execute a rewrite, I’d love to help you out.

如果您有基于Web的产品，并且需要可以帮助您分析，计划和/或执行重写的软件工程师，我将很乐意为您提供帮助。

翻译自: https://medium.com/swlh/rewriting-your-software-product-read-this-first-4311dcf82ed1

离职后 重写的软件 侵权