The transport process is not incidental and you should definitely not be updating roles in your downstream environments.
Doing this causes numerous negative consequences when you need to make future updates to user access or go through SAP upgrades. If you are not aware of direct changes made to PRD and QAS environments for your users then you are invalidating any testing that went into the creation of the role. You are also more likely to break user access if you update a role in DEV to transport it through and thus over-write a change you are someone else made in PRD.
SAP has gone to great lengths to detail why you should not do this, as well as to release notes to the Security public at large on how to restrict your roles appropriately in PRD and QAS so that you cannot update a role in those environments thus ensuring com pliancy for you and your Security team in PRD.
@Anja: The previous suggestion of creating a separate role for PRD/QAS/DEV with the relevant Sys ID or Client/Domain restrictions is a good one.
If your end users require this access for direct calls to other systems once in PRD but these need to be validated during testing in the QAS environment you could always just create your PRD ready role with the required variants which would be assigned to those users and for your DEV and QAS environments a "Project Level" role that opens up the access of that and other items as needed to ensure testing goes smoothly and which can be assigned as needed in those environments.