Hacker News new | past | comments | ask | show | jobs | submit login

What’s the budget and the value proposition? should be #1. Projects without a clear purpose (happens way more than you might think) are sinking ships you've got to get away from.



I would add "Make sure every stakeholder has the same idea what the project will be". I have seen a lot of projects where once you talk to all stakeholders it becomes pretty clear that there is no shared understanding of what we are trying to achieve. Especially be wary of senior managers injecting their pet ideas.


See also: https://www.youtube.com/watch?v=8fz-AowdiL8 - a 1 hr webinar from the folks behind Microsoft Press' recent Software Requirements books (Seilevel) on how to document these requirements and make sure folks are on the same page.


Actually, I meant to link to https://m.youtube.com/watch?v=eYb53GvnSdQ which in a similar presentation covers a few more of the diagrams in a faster pace.


This 1000 times. I can't tell you how often I've seen this happen. Many times it's at least a factor in failed projects.

Clues this might be happening: senior managers pulling you aside to discuss their ideas for the project. Getting different questions on project updates than the goals you're building towards in scrum. Constantly changing short term goals.


I came here to say something similar.

While one is spending their time on the first points imagining infrastructure (for usage that might one day materialise), the company goes out of business because they failed to solve a problem anyone cared about.


And continually revisit it. When you're knee deep in requirements, corner cases, and industry best practices, you can lose sight of why you were building the damn thing in the first place, and end up with something that doesn't satisfy that need.


Always know what 'DONE' looks like.

Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.


How do you define done? Software is never done. A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.


You're not building "software," you're building something for someone to use. Done is defined by what that person needs to do their work. Done should be defined up front, or at least as far ahead as possible so it's clear.

One of the first questions I ask when probing about the state of a project or task is "how do you know when you're done?" Too often, the answer is a shrug, or a deer in headlights look!


Super important even if you're doing client based work (whether pure custom development or customizations on top of a platform).

Your customers will each have their own individual pet features that they care about but if you don't drive to business value (meaning you just build whatever random shit the client tells your build) then it will be a failure 100% of the time.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: