I'm a new developer at a company that has had a very small development team (2-3 people) for a long time. All the current JIRAs are spoken for and there's no backlog. My big boss told me that since the development team is so small, the other employees are used to putting their needs "on hold" and I should go ask them what they want. I don't want to march into their office and demand to know what they want. What's a tactful, productive way to coax ideas out of someone and turn them into a viable project? I'm looking for a good introduction for when I go into their office and the sort of questions I should ask.
Don't just walk into their offices and expect them to bring up a list of issues on the spot. Invite them to a meeting, set up an agenda so they know what to prepare. Hold the meeting, gather ideas, write them up for your boss to prioritize them. Give feedback on what was prioritized to your stakeholders. Then start working.
This situation is a little unsettling, to be honest. Some thoughts:
there's no backlog - Who is responsible for long-term direction of the product? Who are the product's users? What problem does it solve? Is there anyone on the team whose responsibility is determining direction? Why did they hire you if they have no work for you to do?
There likely is an existing unrecorded plan. Find out what the long term direction is, and what they intended you to do upon joining.
Record every idea you come across in JIRA. Don't worry about whether it's short term or long term goal, just get it recorded - from there you can begin prioritizing which items to do in what order.
I've also never seen a project that does not need some of the following:
- Run through typical usages and note down areas that are confusing or complicated. Think of a way to improve the UI or UX here.
- Ask people if they have any known issues or known workarounds, you may be able to make a solution to these.
- Add documentation to the project. If there isn't a guide telling new end users how it works, make one. If there is one, follow the guide as if you're a new user, and make sure it's correct. Tie this into the UX examination.
- Talk to end users or developer and find pain points. Make a solution to them.
- Add more automated testing. Run a coverage tool and identify the least tested area of the code, and the area of the code that is most important to key behaviors of the product. Focus on creating tests there.
- Do you have continuous integration running your automated tests on all changes that get made? Set it up if it doesn't exist.
Whatever you're doing, create tickets for the work and run it by your manager first.