
Questions to Ask at the Start of a New Software Project - philk10
https://spin.atomicobject.com/2020/01/24/new-software-project-questions/#.XirzpDhIdlE.hackernews
======
duxup
For me as a noob working on a SaaS product that gets pretty highly customized
I usually try to tease out as much as possible what will need to be modular /
customer customizable.

I never get it 100% right but I want to avoid as much customer one off code in
the product as possible so I don't have to go out and dig it out and make it
modular later. When I get it right it really reduces the amount of time
setting up a new customer.

------
splittingTimes
In addition to those described in the article, i have following question on my
list:

# Risk

* What are the platform constraints?

* What are the performance constraints?

* Get clarity to what is an acceptable upper bound.

* Would it be acceptable if it took a week to calculate or 20 minutes to open the application?

* Does it need to happen in 30 seconds or 5 milliseconds or 100 microseconds?

* Can you demonstrate a failure?

* What happens when you go off script?

* Most of the complexity is in handling those off-script behaviors. If that’s not being handled well, the project is definitely not “nearly done”.

# Definition of done

* How does the “Definition of Done” look like? Ideally from whole project down to single stories.

* How would you verify that this is working correctly?

* What is the success criteria of this product?

* What does “good” look like?

* What will make it a worthwhile endeavor?

* What are other pain points and blockers?

# Costs

## Opportunity costs

* Is this the most valuable thing we can be doing?

* Is an 80% solution good enough for your needs?

* Is this work really where your team can add unique value?

Other question one might ask to get a feel for the lost opportunities:

* Which parts of the current system are hard to use?

* Which manual process stops the customer to do more creative, value-adding work?

* What changes would improve operational inefficiencies and save money from the bottom line?

* What evidence can you show that this will solve the problem?

* Provide a simulation or prototype or fake (but statistically relevant) data which can demonstrate the solution is at least plausible.

## What connects to this?

* Things with a more complex network of dependencies will be more costly to develop and maintain.

* What systems will depend on this?

* What systems will this depend on? Enumerate all the dependencies. Other systems, libraries, users, protocols, everything

## What’s Plan B if this doesn’t work?

* What are you going to do when we’re up against a deadline, this solution isn’t working as expected, everything is broken, and we still have to ship?

* Get an answer to that, then do that first. Then you can talk about how you can make it better.

* What would be the earliest point you can know whether the system has any value to you? What is the smallest step that would give us the most benefit? How will we do this?

* If we could keep only half the features what would they be?

* What if we take one dev away from this project?

* The 80/50 Rule:

If you’re not 80% done by the time you’ve used 50% of your resources, you are
behind. When something doesn’t pass this test, it’s time to evaluate what
needs to change:

* Does this project need to stop?

* Do other projects need to move? “I can make up the time” is not a realistic response.

# Maintenance cost

* How long will the system survive?

* When will this system be scheduled for replacement?

* During what period will you be making no changes to the system except for critical bug fixes?

* What are the prerequisites for using the solution?

* What must continue to be true?

* What do users need to know?

* What does the data need to look like?

~~~
preommr
uh.... sorry but that's now how we do things anymore.

Please submit this as a medium article with unnecessary and unrelated images
or as a corporate blog post so that you can improve your seo ranking.

------
Multiplayer
Highly recommend Shape Up by the basecamp team:

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

It's free. It's good.

------
supernova87a
The article doesn't say _who_ should be asking these questions. I hate to say
it, but sometimes "ordinary" software programmers (the most dangerous are the
kind with just a little experience but not enough to know that they don't
know) will start to feel that they should be asking these questions of the
people asking them to build something. It's a good sentiment, but often
(especially when there are sales/competitive/pre-emptive/other factors) at
play, they're straying a little into "too big for your britches" territory and
should just build what they're asked to. Leave the questioning to the
engineers who both know how to build it in their sleep, and understand why
it's needed...

~~~
Supermancho
These are product-centric questions.

> What business risks or blockers exist?

Thats not a question that's readily available to developers, nor is it
relevant until the project comes up in planning.

~~~
waynesonfire
why not? developers are a key part of a business and shape it. they should
certainly be paying attention to managements initiatives and what risks or
blockers these may present to the project at hand. this would encourage
alignment and clarification.

------
kashug
I'd like to add: Why does it have to be a project? For me atleast "project"
usually implies too much upfront planning and not beeing very lean.

~~~
Demiurge
"too much upfront planning" is one thing I've never experienced before.
perhaps, you mean wrongful planning or indecision?

~~~
tilolebo
Not the GP, but long term plans are at best inaccurate, worst case completely
wrong. Plus, you spent all this time planning instead of
implementing/discovering.

~~~
kingisaac
Both mindsets are necessary, and it's also possible to go too far in both
directions. I've been on teams that took planning to an absurd end, which
resulted in obsolete plans as soon as implementation started. I've also been
on teams which went around in circles because they didn't have any direction
and their implementation/discovery wasn't focused on a clear goal.

Long term plans are only inaccurate or wrong if they're over reaching. Plans,
like every other part of a project, have to be able to change and grow
throughout implementation. It's not long-term planning that is the issue, it's
the stagnation of overbearing plans.

~~~
janee
> Long term plans are only inaccurate or wrong if they're over reaching.

True, but for me the real problem is actually identifying that ideal amount of
planning for some project.

It's easy in hindsight to say something was over reaching or not enough
planning was done, but not always that simple prior to starting a project.

Ideal planning vigor and scope seems super context sensitive to me and even
with experience I often feel I get it wrong.

~~~
kingisaac
There's no such thing as perfection, only the pursuit of perfection.

Hindsight is a crucial part of making sure you don't make the same mistakes.
Don't worry, you'll have plenty of opportunities to make brand new mistakes.

------
that_jojo
Oh, hey, Atomic Object! Just wanted to say it's neat to see you guys on here,
and, if you're from the AA office, hello from just the other side of 23.

