Это видео недоступно.
Сожалеем об этом.
How Do You Gather User Requirements? How Do You Perform UAT?
HTML-код
- Опубликовано: 16 авг 2024
- How do I get good user requirements? How do I ensure that they are comprehensive? Then, how do I get them to sign off on user acceptance testing (UAT)? These are the questions we are going to answer in today's episode of Dev Questions.
Website: iamtimcorey.com/
Ask Your Question: suggestions.ia...
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimc...
Hey Tim, thanks for answering my question! I'm in Disney right now on vaction with my family but had to take a minute to watch the video and to say thanks!
You are welcome. Thanks for the suggestion. Enjoy your vacation.
This series is amazing. Real world practice.
Thanks!
Great video Tim. I call requirements "the definition of done". Its not always an easy for often introvert developers to pin busy users down into committing to what done really looks like. But if the user doesn't know they will never sign of UAT. My other top tip is to mock up UI and reports in excel using actual data. Yes its up front work but makes development and UAT a breeze.
Thanks for sharing.
So true... validating 100% what I try to get sales and management to undertand lots of love for this
Thanks!
Thank you Tim Corey for content! ♥️
You are welcome.
Thank you very much Tim... My ongoing project needed that badly!
You are welcome.
Hi Tim ! Here's a question/suggestion for this serie : "How do you deal with project evolution?". Here's an example : you launch a brand new project in production. Some times later, you come with news ideas and new functionalities and even new projects. But, instead of coding these you implement them into the existing project, because there is already lot of code working for that in it. But... making so will completly broke things such project name or dependencies... how to deal with that ? as you cannot think about things you have not imagine yet...?
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Always easy to understand, best explanation. Very thanks for this useful content.
You are welcome.
Hi Tim and thanks for the amazing podcast. I've noticed that the audio on the audio-only version have started to clip in the last episodes. It's totally different from watching on RUclips.
Thanks for the heads up. I'll check it out and see what is up.
Great question and great response! Thank you.
You are welcome.
Thanks for the video Tim!
You are welcome.
Hi Tim, I'd really love an introduction in Sockets and NetworkStreams from you!
I'm personally stuck at quite a couple of things and I'd love an explanation from you between a client and a server.
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Thanks for the video Tim! Is it usual for developers to gather requirements rather than business analysts?
First, yes it is. Most small and some medium-sized organizations have developers gather requirements as well. But second, even if a business analyst gathers the requirements for you, you are still responsible for validating, verifying, and expanding upon them. If a BA says that they want an MVC app to do X, and you know that a Razor Pages app would serve them better, you should say something. If they say that they want to capture sensitive data, it is your responsibility to talk about the security and safety of that data. The list goes on.
I found from past jobs that the end user of the app is usually the developer (which the purpose of developing it is to make that persons like easier).
That's a very unusual job. I've never worked for a company that paid me to be a developer to build apps for myself or other developers. We did that, but it was on the side as a way to make us better at our primary jobs.
@@IAmTimCorey Originally, I was not even paid as a developer. However, I became a developer to help me do better at my job. Both of my jobs was that way. The second job, I already know development. The original job was to answer ermails but i assumed i could create a complete app to help me and i did that.
Those aren't development jobs, though. You are doing development and you are a developer, but the jobs themselves aren't development jobs. Doing development work to make your job easier doesn't make the job a development job. A development job is one where you are hired to be a developer. Being hired to answer emails and then using development to make your life easier is great, but the job is still answering emails. Writing software to make that process better is definitely a great trait and one that can help you transition to a full developer job. However, you do miss out on a few experiences vital to being a full-time developer.
@@IAmTimCorey Just curious what experiences i miss out on. In that case, then I never had any real development experience. The only disappointing thing is when I run out of work. For the first job, because of my development skills, eventually, they did not need me anymore. Unfortunately, my experiences is always running out of work which i hate.
Being hired for a development job means you will experience the following things (or most of them if you are not in a great environment and they don't do them all): assigned development tasks (not just projects you pick), development deadlines (not just "when I'm done" deadlines), requirements gathering from non-developers, producing content that satisfies non-developers (which can be REALLY tricky), long-term support of your software (bug fixing code running in production where downtime means lost money), working on an application that is hundreds of thousands of lines of code (at least) and 5-15 years old (fixing bugs and adding features at the same time), working with other developers on the same system, walking an application through Dev, QA, Testing, and Production, working on code that is old or in a language that is not your preference, and working with a boss who knows what to expect from a developer and who pushes you to be better. There are a lot of skills that you learn through being a developer on a team. Some you can practice outside of that environment, but there are a lot that come only through being in that environment.
I run into these problems all too often. Schedule already compressed by two months because the customer took forever to review the CR and approve a PO? Guess what? They're also going to bring only department heads who don't use the solution to the JAD sessions. Only on the third meeting attempt three weeks later will they have the right people. I guess we'll have to tell them the scheduled just slipped by three we.. haha, just kidding. This has to release alongside another vendor's deployment and they won't let us delay.
Time to talk UAT. "We can't have the end users pointing to a test system. They have jobs to do!" Instead we do "solution reviews" where we build out test scenarios and walk through them with the big wigs who don't know the system to get approval. Eventually we deploy to production and hope the users don't hate the experience that was approved in both design document and solution review by their superiors.
It's also amazing how often we have project kickoff calls with a customer and they expect things that are explicitly called out as not included in the SOW.
Customer: What? You're only pulling data from System X? We thought we'd also get data from System Y.
Me: No. Item A.13 under the assumptions section reads "The solution will retrieve data from System X. Other systems are not included as part of this project."
Maybe showing this video to management will help. These issues are costing everyone.
So many places have "scope creep" because they give you requirements but then want to keep adding to them afterwards. I dealt with that at one company and the project manager there had my back and told them to open a new ticket. At one company I had a project go through DEV, TEST, UAT, and then into PROD. Then after our monthly production deployment that owner of the ticket (same person that UAT'd it) was not happy with it!!!! WTF? People are idiots :)
It can be frustrating. Just remember that users often have a picture in their head of what will happen, but don't know how to explain that clearly. So they compare the system against that mental picture rather than against what they said. You just need to point that out. That's why you need to work so hard at the beginning to get their "real" requirements out on paper.
@@IAmTimCorey Now I work freelance under my LLC. I will normally draw up a mockup of the way it should look and flow chart of functionality of how they should work. If they sign off great on my quote GREAT!. If they add something other than original specs I get back to them and figure out the cost "extra" and give them a new quote.
Keren bang
I am not sure what that means.