The first step I would take is to document a couple of processes that everyone can agree to abide by. What it sounds like you are doing is attempting to put lipstick on a pig by trying to overlay a chaotic work environment with a few titles.
The first step is to have a formal way of documenting work to be done and work that has been done. Once you have more formal documentation then it is easier to discuss the work, to estimate the work, and to prioritize the work. With more formal documentation as to current status then when changes come in, it is easier to discuss the impact of changes in work load as well as to have a better feel as to what is possible or not. In some cases new work requests can be bundled with existing work requests or work in progress.
As you build up a better sense of what you are doing and reviewing the history to see how well your estimates are holding up against the reality of doing the work, you will get better at scheduling work as well as getting better at estimating the effort for changes. And the non-technical people will get a better idea as to effort required and impact of changes.
Two tools are a first step. First a source code and document repository is needed in order to track changes to the source code and deliverables you are working on. Secondly a task and defect tracker is needed to track work in progress and to document and organize work needing to be done such as change requests and defects.
There are a number of open source products that will do both of these. The most preferable way would be to go with a hosted system as there are a number of companies providing these services and facilities and they are fairly inexpensive.
The nice thing about these is that a dashboard is pretty much a standard product offering allowing for transparency about schedules and deliverables.
Once your team has the tools in place to organize your work and your team is comfortable with these tools, using them successfully, you can then move into the more managerial and cultural aspects of your work.
I suspect that part of the problem you face is that the non-technical people within your organization do not understand or have an appreciation for the effort and time required for development. I would expect that they are used to a chaotic, multi-tasking environment with constant interruptions and changes in direction. However this doesn't work with development which requires concentration and time on task without interruption.
Your team is small enough that you do not need the kind of formal titles you are describing. You do need a few formal processes that everyone buys into and agrees to but you don't really need formal titles. And I suspect that the fewer processes and less managerial effort required for those processes the better.
Your main problem is the chaotic environment and that is a culturally and education and training problem.