A better trick I discovered when I used to work in an environment closer to this was to always give the person requesting help some trivial but sincerely related task to do before you can help them, e.g. "can you just write down all the steps in the process before you get stuck, it will help me solve the problem", or "Hmm... I'm not quit getting the issue, can you draw me a diagram and then get back to me". This acts as a great filter for people that are just helpless versus people that really need help. And if anyone complains to the boss that you aren't helping, you can say "oh well did you do task X? that's really all I need from you to get started"
One day I had an epiphany. I realized as I was programming at my computer that nobody had a freaking clue what I was actually working on. If someone asks how their low-priority project is going, I just say that I'm still working on it. They have no way of knowing if I'm actually working on it right now. In the real world, saying "no" a lot will get you enemies. It's much more diplomatic to only work on some low-priority project an hour or two a day (you don't have to tell them your are only spending an hour or two a day), or say you'll get to their project immediately after you finish this thing your are working on (which can be a small component of your large important project). It's important to know how to say "no", but in practice it is important to minimize the number of times you say "no".
Then you either demand dedicated "anti-office hours" or you tell them that it's not feasible that project B will get done with the way things have been recently. They're not technical, and all they can do is take your word on when you think you can finish it. They're not going to pick up on the caveats you've laced in your estimate. Also, you should let them know ahead of time that things are slipping instead of them finding it "behind schedule" on their own.
Honestly, don't take this as an insult, but it just doesn't sound like you're the right person for the position. If you have trouble pushing back when you need to, then you should find a spot where there is someone pushing back for you.
I agree with you that I'm not the right person. I was brought in to change the culture so we do everything faster(you can imagine the speed at a company with couple offshore devs and half dozen onshore people working on product).
I've, err we, have mostly failed.I can go on about why but at the end, I think we all share the blame and evaluate parts we could have personally done better and apply it next time round.
One of the big realizations for me is that they need someone older and more confident. I'm in my mid 20s and once founded a startup that got 30x the traffic but even months in, the boss would be unsure if I was a good programmer. We tried everything from emailing my code samples to his CTO friends to code reviews by other devs(all of which gave positive feedback) but I feel he could never totally shake that doubt. I called him out on it finally(basically if you can't tell after 8 months if I can program you should let me go). I've been programming since 12 but the lingering doubts actually started making me question my own abilities at which point I decided I need to move.
I found keeping a timesheet helped me there. When it came to "it is getting to the point where X is not going to be ready on time, and I've got personal things on this week so I really can't work significant overtime", and the question came back "well, what have you been doing for the last week", I could give them a full list of "2 hours helping X with Y", "an hour doing Z", "four hours on that high priority fix client C that no one else was willing to touch" and so forth. Don't play the blame game and point out that person X was being thick on an occasion or otherwise dwell on who is interrupting your key work, just lay it out as matter-of-fact as you can: "This is where my time is being used".
Make damn sure though that people understand a short interruption "for a quick meeting" when you are at the time "powering through" stuff sometimes kills as much as a full hour of development time if you are working on something complex as it can completely break your train of thought (especially if you are tired due to recent overtime!), or worse if you are coordinating with other people and/or are working on something timing sensitive (so the interruption might mean a key coordination point is delayed).
If you can show what the demands on your time are, a good manager will try rearrange things so that you are interrupted less often. Sometimes simply merging those small interruptions into a scheduled period or two each day is enough to make all the difference to your mid/long term work: problems that didn't really need you magically go away (as the person who was going to interrupt you does that 30 seconds of extra thinking/research that was needed to give them the clue) and the others "interrupt" you a few times a day rather than several times over an hours or two.
"So I know your project is important but projectX is still our #1 priority so to the extent Jenny needs you please prioritize her work"