For 1.5 years I’ve been assisting in the maintenance and enhancement of software that was built by a consultancy almost 3 years ago. No one on my team was part of the initial design, build, and launch. The documentation for the software is lacking and there is no one who I can go to to get confident feedback on how features should work.<p>Part of me want to leave the job cause it seems like a hopeless situation, but the pay is great. I want to turn the project around but that seems impossible cause there doesn’t appear to be a “true north”.<p>What can I do?
I've been in a similar situation. I think you're thinking about this in the wrong way. You want someone else to tell you what to do or how things should work, yet no one on your project knows (and they probably don't care either). You can use this to your advantage.<p>You should trace how major features or specific functionality actually works according to what the code does (trace all paths and weird edge cases and bug scenarios), then present that this is how 'x' actually works, and if the customer wants to do 'y' here is what we have to do to make it work. You have to take initiative to do deep dives without someone telling you what to do or hand holding.<p>Then when your PM or manager discusses adding new features you'll know what scenarios can break or need to be re-tested. Everyone else will have no clue and then they'll naturally start asking and looking to you for handling and leading maintenance and new features.
You sound like you’re in a tough spot! You’ve got a lot of responsibility on your shoulders and no one to turn to for advice.<p>There are some things that you can do to get yourself out of this situation, though. First, it sounds like you need to get more involved with the project. If there isn’t anyone on your team who was part of the original design or build (and even if there is), then it’s up to you to familiarize yourself with the codebase so that you can make more informed decisions about how features should work. You can do this by reading through some of the code, visiting any related documentation (if it exists), and asking questions whenever they pop up.<p>Second, you should consider reaching out to other people who have experience working on similar projects. You could ask them if they would be willing to sit down with you and go over some things—this will help them understand what kind of work you do, which may make them more willing to help out in the future if they know what an asset they have on their hands!<p>Finally, try thinking about what kind of product roadmap would be most valuable for your company right now? What do they want from this software?
If you want feedback about how some features should work, pick how they should work yourself, and make them work that way, then release.<p>Nothing will give people opinions faster about how it should work than playing with something that works somehow now.