Accounting for Changes
Sara works as a product manager for a piece of accounting software for a large, international company. As a product manager, Sara interacts with their internal customers- the accounting team- and Bradley is the one she always bumps heads with.
Bradley's idea of a change request is to send a screenshot, with no context, and a short message, like "please fix", "please advise", or "this is wrong". It would take weeks of emails and, if they were lucky, a single phone call, for Sara's team to figure out what needs to be fixed, because Bradley is "too busy" to provide any more information.
One day, Bradley sent a screenshot of their value added taxation subsystem, saying, "This is wrong. Please fix." The email was much longer, of course, but the rest of the email was Bradley's signature block, which included a long list of titles, certifications, a few "inspirational" quotes, and his full name.
Sara replied. "Hi Brad," her email began- she had once called him "Bradley" which triggered his longest email to date, a screed about proper forms of address. "Thanks for notifying us about a possible issue. Can you help me figure out what's wrong? In your screen shot, I see SKU numbers, tax information, and shipping details."
Bradley's reply was brief. "Yes."
Sara sighed and picked up her phone. She called Bradley's firm, which landed her with an assistant, who tracked down another person, who asked another who got Bradley to confirm that the issue is that, in some cases, the Value Added Tax isn't using the right rate, as in some situations multiple rates have to be applied at the same time.
It was a big update to their VAT rules. Sara managed to talk to some SMEs at her company to refine the requirements, contacted development, and got the modifications built in the next sprint.
"Hi, Bradley," Sara started her next email. "Thank you for bringing the VAT issue to our attention. Based on your description, we have implemented an update. We've pushed it to the User Acceptance Testing environment. After you sign off that the changes are correct, we will deploy it into production. Let me know if there are any issues with the update." The email included links to the UAT process document, the UAT test plan template, and all the other details that they always provided to guide the UAT process.
A week later, Bradley sent an email. "It works." That was weird, as Bradley almost never signed off until he had pushed in a few unrelated changes. Still, she had the sign off. She attached the email to the ticket and once the changes were pushed to production, she closed the ticket.
A few days later, the entire accounting team goes into a meltdown and starts filing support request after support request. One user submitted ten by himself- and that user was the CFO. This turns into a tense meeting between the CFO, Bradley, Sara, and Sara's boss.
"How did this change get released to production?"
Sara pulled up the ticket. She showed the screenshots, referenced the specs, showed the development and QA test plans, and finally, the email from Bradley, declaring the software ready to go.
The CFO turned to Bradley.
"Oh," Bradley said, "we weren't able to actually test it. We didn't have access to our test environment at all last week."
"What?" Sara asked. "Why did you sign off on the change if you weren't able to test it!?"
"Well, we needed it to go live on Monday."
After that, a new round of requirements gathering happened, and Sara's team was able to implement them. Bradley wasn't involved, and while he still works at the same company, he's been shifting around from position to position, trying to find the best fit"
[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.