Ten Industry Terms to Communicate Faster and Better With Your Web Agency
I am here to help you learn one critical skill: speaking the same language as your Web Agency. Of course, once you hire someone to create your website or web/mobile app, it is up to them to communicate clearly and precisely what they will do for you.
On the other hand, this is like going to Mexico for the first time. Yes, they might speak your language. But order un chupito de tequila anejo, amigo, and they will know what you want. When you know your way around an industry, you know your way around an industry.
You might have worked with technical people in the past, and you might have developed digital products before. You probably already know many of the terms on my list. What you might not know are their not-so-obvious implications. Not to mention some of the words we think we know often mean different things in different industries.
1. DEADLINE
A deadline is a deadline, and we all know what it means. “If I don’t do it by Friday, I’m dead”. While deadline doesn’t have any specific different meaning than the usual case, here’s what we need to clarify.
Deadlines in IT are usually much more volatile than in any other industry. A worker on the factory floor can tell you precisely how many nails his machine can spit out in one hour. In our industry, it’s like every single nail is a different size. At least twice a year, a client wants bolts and hammers, and you rewire to make bolts and hammers. In two years, trends will change, and everyone will probably use chewing gum to hold things together. That’s where the volatility comes from. We’re (proudly) not a pixel factory.
If the agency tells you they have their internal deadline on a set date, that doesn’t mean you will launch the product the day after. The internal deadline means the end of the development stage. It does not include testing and all the other activities.
Be very careful about deadlines being set very early in the development cycle. Things can shift under your feet at the beginning of projects for many causes. There is only so much we can tarot and palm read,ing and horoscope. We often need a few days to a week to work on it, and then we will know precisely how your project feels.
2. SERVER
A server is primarily a computer connected to a network that other devices can access. There are multiple server architectures in place for the development of a project:
- Local
The local server is usually the PC the developer works on. On smaller projects, they build the application or website locally. Once they have a working project, they will usually deploy it to the next agreed-upon step (sometimes that’s testing or QA, but it largely depends on the project size).
- Development
Development servers are external servers we use for bigger projects. They allow multiple developers to work on the same project. In some cases, we make the development server available to the client to give status updates and get feedback. Web products in this stage are often incomplete and buggy since no testing has been done on the code yet.
- Staging
We use staging servers for fine-tuning and testing. Our clients can give access to the project to some trusted users for testing and feedback. It is usually more stable and less buggy than the development server.
- Production
Congratulations on your last checkpoint! This is the live server that your users access. After passing the Q&A and client feedback, the product moves from staging to production. This server is usually more robust and secure and is optimized for speed and performance.
3. DONE
Contracts make quite a big deal about the so-called “definition of done”. What does it mean we are done with a project?
When we first started, I struggled with “done” for quite a bit. My CTO, Andrei, would tell me he’s done with a feature on Friday, and this is precisely what I’d tell my client. “We’re done on Friday”. Andrei’s definition of done was “launched on the development server”. This meant an often buggy product with no content that didn’t go through testing and QA. The client’s definition of done was that we could open the champagne. Clients are never happy to hear we have to screw the cork back into the bottle.
A better question is: ”When can we launch this new feature?”
4. ARCHITECTURE
- Information Architecture
Information architecture is the process from which content position and distribution are set. It allows your users to easily understand and navigate your website’s or apps’ content.
- Server Architecture
Server architecture refers to choosing what servers you need to buy/lease and which component of your digital product goes on what server and with what software.
- Lego Architecture
Lego architecture refers to the charming transformer Andrew built in the break room out of legos last Christmas. It winks and waves at people.
5. PROJECT MANAGER
The Project Manager ensures communication between the client and the development team is flawless. He makes sure to deliver status updates and track the project’s timeline and the changes in the product development cycle.
6. DEVELOPER
The developer writes the code and builds the application. He translates what the UI/UX team built into live interfaces on the front end and the logic that the client and product owner planned into features in the back end.
7. PRODUCT OWNER
The Product Owner (not to be confused with the Project Manager) writes part of the product’s specifications. He usually handles task prioritization to deliver a logical, complete, and valuable product. He must ensure that the product’s features align with the stakeholders’ expectations and bring value to the user.
8. SPRINT
In Agile product development, a sprint is a set period during which specific work must be completed and made ready for review. Those usually are planned in one or two-week increments.
9. BRIEFING
A brief is an initial document the client or his product owner must make to describe the project’s scope. It should include a summary of the following: user target, features, interfaces, and deadline.
10. BUGS vs. TASKS
We have a green button that should take you to the order page. If the button doesn’t work, it’s a bug. If you want the button to be blue instead of the green you suggested before, it’s a change request. If you apply this analogy to every little detail on your site, you will no longer confuse those two.
Bonus: CHANGE REQUEST
A change request represents a change of thought, an additional feature, or any other activities that require development time that weren’t planned at the beginning of the project. Those usually delay the initial timeline and are charged as extras by the development team.
WHY IS THIS IMPORTANT?
“A rose by any other name…”.
Call it “brief” or call it “boss, we need to know what the requirements are and a damn good idea about the plan”. Call him Project Manager, or better yet, call him Alex. This article is not really about the industry’s slang. An outsider from the industry certainly needs us to speak clearly, and our job is to make ourselves understood.
This article is more about our work process. You might have noticed by now these are not buzzwords. These are communication shortcuts to assign tasks and make plans. Done means “this is our pipeline, and here’s my role in it”. We translate change requests into hours and contractual obligations. When we say brief, we hear “talking to the client and understanding the needs, then making a plan”. We define our terms, we plan, and we have structure.
We have a damn fine job!
If you want our input on your digital products, feel free to book a free strategy call with Adi, Neo Vision’s CEO.
👉 Make sure to check out our Digital Arbiters Facebook Group https://www.facebook.com/groups/digitalarbiters
📞 Schedule A Call: https://calendly.com/neovision/neo-vision-strategy-call
🐦Reach out and check our work: https://neovision.dev
BLOG ➜ https://neovision.dev/blog/
TWITTER ➜ https://twitter.com/neovisiondev
FACEBOOK ➜ https://www.facebook.com/NeoVisionDev
LINKEDIN ➜ www.linkedin.com/in/adi-niculescu
LINKEDIN GROUP ➜ https://www.linkedin.com/groups/12527…
SUBSCRIBE ➜ https://bit.ly/3aIVdOA