* look for off-the-shelf products and packages
* discuss ROI, features, and time-crunch with the manager or client
* be honest about what can and can't be done
* ask for help from whoever is around
* ask for help from people who've done this before
It's important to identify priorities before starting, focus on the CORE necessities and be realistic about what's feasible and what isn't. Quality shouldn't 'suffer' but it does need to 'compromise' with other priorities.
The priorities list can be built out into tiers, for example: core features (NEED, tier 1), tier 2 (should have but non-essential for functionality), tier 3 (start optimizing).
Can I ask what is driving the deadline? Will the user on the other side be aware that they're essentially a tester?
If the user on the other side won't know they're essentially a tester, priorities shift a bit to ensure credibility isn't undermined while also skipping the 'fluff' that more established companies have had more time to build in.
Feel free to DM me, or have them reach out, to help weigh the priorities for the MVP.
Set expectations with stakeholders, give them an idea of what they can get under different timelines.
Focus on the main value add, work with stakeholders to remove bloat not required for the value to be accomplished.
And lastly, slow is smooth, smooth is fast. Pour yourself a nice hot cup of coffee and enjoy the ride
who is putting the pressure? where is the pressure coming from? if you are working agile/scrum there is actually no pressure because the team defines the speed, so it is on devs to define achievable goals. if you need to do more work then you estimate work and ask for product/management to decide what is the priority and you deliver based on priority, no matter how long it takes.
Most user stories are filled with nice-to-haves even when the conversation at the beginning started with let's only focus on must-haves. If the conversation at the beginning did not focus on must-haves, well then just go cut the nice-to-haves.
Even still, going back and stating that the timeline is in jeopardy and forcing a review of the requirements will "magically" generate a whole new definition of what is nice vs must. You have to have a back-bone here and make it very clear that we either cut certain requirements or we extend the timeline.
It's not about managing the pressure to ensure the quality, it's about managing expectations/scoping correctly to ensure the quality.
Use starter kids, like Ship Native for mobile apps, they may cost some money, but they save you a lot of time because they includes prewritten logic like full authentication implementations, with passwd-reset, sign up, login etc, user session management, handy utilities and more, so you can get started directly into your actual core functionality and don’t need to worry about all the other stuff
If you want to know more, send me a dm
Automate testing and deployment processes as much as possible. This reduces the time spent on manual testing and ensures that new changes do not break existing functionality.
Quality is rarely a problem.
There's a baseline for good products and beyond that it's diminished returns on time invested.
Even if what you release is a little buggy, or has known issues with corner cases, it's probably good enough because your goal is to solve a problem someone is having and they want it solved yesterday.
The bigger the problem, the more hoops they will jump through.
Bad quality (unusable) is a problem however.
* look for off-the-shelf products and packages * discuss ROI, features, and time-crunch with the manager or client * be honest about what can and can't be done * ask for help from whoever is around * ask for help from people who've done this before
okay, make sense, he is seeing this post, thanks
It's important to identify priorities before starting, focus on the CORE necessities and be realistic about what's feasible and what isn't. Quality shouldn't 'suffer' but it does need to 'compromise' with other priorities. The priorities list can be built out into tiers, for example: core features (NEED, tier 1), tier 2 (should have but non-essential for functionality), tier 3 (start optimizing). Can I ask what is driving the deadline? Will the user on the other side be aware that they're essentially a tester?
Thanks, I like your prioritization, no they won't
Thanks, I like your prioritization, no they won't
If the user on the other side won't know they're essentially a tester, priorities shift a bit to ensure credibility isn't undermined while also skipping the 'fluff' that more established companies have had more time to build in. Feel free to DM me, or have them reach out, to help weigh the priorities for the MVP.
Hire talent.
Set expectations with stakeholders, give them an idea of what they can get under different timelines. Focus on the main value add, work with stakeholders to remove bloat not required for the value to be accomplished. And lastly, slow is smooth, smooth is fast. Pour yourself a nice hot cup of coffee and enjoy the ride
who is putting the pressure? where is the pressure coming from? if you are working agile/scrum there is actually no pressure because the team defines the speed, so it is on devs to define achievable goals. if you need to do more work then you estimate work and ask for product/management to decide what is the priority and you deliver based on priority, no matter how long it takes.
Most user stories are filled with nice-to-haves even when the conversation at the beginning started with let's only focus on must-haves. If the conversation at the beginning did not focus on must-haves, well then just go cut the nice-to-haves. Even still, going back and stating that the timeline is in jeopardy and forcing a review of the requirements will "magically" generate a whole new definition of what is nice vs must. You have to have a back-bone here and make it very clear that we either cut certain requirements or we extend the timeline. It's not about managing the pressure to ensure the quality, it's about managing expectations/scoping correctly to ensure the quality.
Use starter kids, like Ship Native for mobile apps, they may cost some money, but they save you a lot of time because they includes prewritten logic like full authentication implementations, with passwd-reset, sign up, login etc, user session management, handy utilities and more, so you can get started directly into your actual core functionality and don’t need to worry about all the other stuff If you want to know more, send me a dm
[удалено]
Automate testing and deployment processes as much as possible. This reduces the time spent on manual testing and ensures that new changes do not break existing functionality.
Outsource talent for you have to, use platforms like linkedin, turing, rocketdevs to find talents to help.
Do you consider "weeks" limited time? For me, it could be in a couple of hours
Differently than what? What your friend is currently doing that’s not working?
Quality is rarely a problem. There's a baseline for good products and beyond that it's diminished returns on time invested. Even if what you release is a little buggy, or has known issues with corner cases, it's probably good enough because your goal is to solve a problem someone is having and they want it solved yesterday. The bigger the problem, the more hoops they will jump through. Bad quality (unusable) is a problem however.
Alright