I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I think the toughest time that's been had by my teams (i.e. the account management people, but it's a trickle-down economy) is with large client companies who have multiple stakeholding teams internally and have difficulty presenting a single point of contact.
If you can manage to funnel everything through one product owner, it's generally ok unless they get overwhelmed themselves, but if it's more of a free-for-all-Jira-access affair then I've seen more time wasted on conflicting requirements than anything else. One team will make a bug report for something having changed, but that was at the request of another team and so on. If they don't talk amongst themselves, eventually everyone blames the development team and confidence in your company gets damaged.
Obviously it's nicer not to be in this situation at all, but I try to manage it by being really explicit in my ticket comments, and by stating every assumption I've made and linking to conflicting tickets as soon as I notice them.
Managing expectations for user testing is also really difficult at early stages of development:
Me: this is an unfinished product, please remember that we're only demonstrating the social feed functionality today Client: understood. Could we make the blog page a different colour? Me: Again... Client: Oh, ok, sure. Second client (walking into room later): I don't like the font in the footer. What can we do about that? And why is our company called Lorem Ipsum?
It's all about making sure that everyone's on the same page, and that's a massive challenge in itself because all these stakeholders are busy people in their own right and only interested in the bit that their team is going to interact with. It's happened with the bigger clients everywhere I've worked :/
Well, one of the first things I've learned when demoing to PM and stakeholders is to make things as close to original purpose as possible. One of my first demos had lorem ipsum placeholders, but they were so confused with that that I gave up and my team lead had to explain to them what's that about.
So, no lorem ipsum, because it takes more time to explain to them what is lorem ipsum than to populate the page with authentic data. Also, use the chosen font (if any) and color palette that's been decided for that part of the app.
That's comforting that it's not just me ... it's been feeling a little 'wild west' and like any kind of control I had while merrily building all the components has now completely gone.
I've been letting in one person from each team and have had some really good feedback, but hadn't even considered the Jira flood that will inevitably be coming my way when I let them all in. I've been so focused on just getting to the finish line. I've been keeping everyone informed but haven't got any pushback or huge feature requests yet. I wonder if that is just around the corner.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the toughest time that's been had by my teams (i.e. the account management people, but it's a trickle-down economy) is with large client companies who have multiple stakeholding teams internally and have difficulty presenting a single point of contact.
If you can manage to funnel everything through one product owner, it's generally ok unless they get overwhelmed themselves, but if it's more of a free-for-all-Jira-access affair then I've seen more time wasted on conflicting requirements than anything else. One team will make a bug report for something having changed, but that was at the request of another team and so on. If they don't talk amongst themselves, eventually everyone blames the development team and confidence in your company gets damaged.
Obviously it's nicer not to be in this situation at all, but I try to manage it by being really explicit in my ticket comments, and by stating every assumption I've made and linking to conflicting tickets as soon as I notice them.
Managing expectations for user testing is also really difficult at early stages of development:
Me: this is an unfinished product, please remember that we're only demonstrating the social feed functionality today
Client: understood. Could we make the blog page a different colour?
Me: Again...
Client: Oh, ok, sure.
Second client (walking into room later): I don't like the font in the footer. What can we do about that? And why is our company called Lorem Ipsum?
It's all about making sure that everyone's on the same page, and that's a massive challenge in itself because all these stakeholders are busy people in their own right and only interested in the bit that their team is going to interact with. It's happened with the bigger clients everywhere I've worked :/
Well, one of the first things I've learned when demoing to PM and stakeholders is to make things as close to original purpose as possible. One of my first demos had lorem ipsum placeholders, but they were so confused with that that I gave up and my team lead had to explain to them what's that about.
So, no lorem ipsum, because it takes more time to explain to them what is lorem ipsum than to populate the page with authentic data. Also, use the chosen font (if any) and color palette that's been decided for that part of the app.
That's comforting that it's not just me ... it's been feeling a little 'wild west' and like any kind of control I had while merrily building all the components has now completely gone.
I've been letting in one person from each team and have had some really good feedback, but hadn't even considered the Jira flood that will inevitably be coming my way when I let them all in. I've been so focused on just getting to the finish line. I've been keeping everyone informed but haven't got any pushback or huge feature requests yet. I wonder if that is just around the corner.