Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
DotSln1467yUser feel much more safe with the software if they know what they are doing.
Imagine you couldn't ride a bicycle and you have to learn it. Would you rather watch videos and read instructions or would you like to have bicycle lessons with some who knows exactly what to do and how to help you with the mistakes YOU make? -
@DotSln true, but the thing is, this would mean that the 3 devs working on it (me and my 2 juniors) would have to teach ~40-50 people how to use the program...
So that's quite some valuable time we could have spend on adding in more features that we (management + big boss) want and tackling bugs that we encounter. -
DotSln1467y@FinlayDaG33k
True. As return you'll get a pleased customer and user who trust you and your future projects. I suppose you even will get less support issues and configuration failures.
I don't know which type of sw we are talking about but in the company where I work (developing standard sw for medical context) we have employees called "Project Manager" which handle projects with customers and not the "internal sw-projects" themselves. -
@DotSln It's an internal website that we use as dashboard for our "students" (one calls them clients, other call them students) where they can see the internal news (like an important employee being sick or the company being closed on a specific day etc. etc.) and some other stuff.
I've made a lot of stuff for internal use already (tho everything was made on my own, not in a team) and rarely have bug-related complaints except some functionality they wish to see.
We already do our best to label everything as clear as possible.
We do not have specific people training others to use the software, the Devs do everything:
gathering ideas, designing everything, building the thing, testing (also security testing - which often goes horrible since I'm the only one in the company who knows a bit about pentesting), training (if applicable) and deploying (to either FTP by manual D&D or as of recently thanks to me, a Docker Container through a CI/CD pipeline) -
Nhil1647y@FinlayDaG33k you could train a few users as 'Power Users' and get them to teach the rest, any details the users dont know come to the power users and then the power users come to you of they dont know. I don't see sharing the training responsibility as an issue.
-
@Nhil While that does sound like an obvious choice, this is kinda hindered by the fact that there are some language barriers within the company, which is not made easier by the fact that a lot of people have a hard time understanding what others say already (and some just are lazy and don't care) :\
Was wondering what kind of workflow you use.
My team is currently a big unorganized chaos...
Our manager wants us to take the form of:
Feature idea -> Design -> Build -> Test -> Train (explain to users how to use it) -> Deploy
The `Train` step is something rather odd to me, as that would mean teaching every single employee how to use the product we're making.
Wouldn't it just be better to skip the `train` section (and maybe use some kind of wiki?) and try to make everything as clearly labeled and obvious as possible?
question