At work I have designed a few products from end to end (frontend, backend, machine learning systems, associated microservices, etc.) and with that is always a discrete list of features, user stories, etc. Perhaps the documentation could be higher quality, but what I deliver to my team is essentially a checklist of tasks to be done in order to get the product to a "completed" state.
However, I'm starting to believe that stakeholders are not reading these documents because I will have meetings with the junior engineers later where the work that was assigned to them falls short of what was documented (maybe implements 75% of the features, or uses a substandard implementation of a feature), or sometimes they have a completely different understanding of the product (completely reversed workflows, missing features).
I would understand if, at the initial planning meeting, we reworked the scope of the project based on time and labor requirements, but after presenting my designs, everyone agrees to what is in the document, and then I later find that someone (usually someone who signs my paychecks) has been communicating something less-than or not-equal to the agreed upon design.
How do you manage to keep everyone's understanding of the requirements consistent over time? I could just force everyone to read the entire document, but the junior engineers don't necessarily need to have a model of the entire product in their head at all times if their concern is doing a really good job on their particular component.
However, I'm starting to believe that stakeholders are not reading these documents because I will have meetings with the junior engineers later where the work that was assigned to them falls short of what was documented (maybe implements 75% of the features, or uses a substandard implementation of a feature), or sometimes they have a completely different understanding of the product (completely reversed workflows, missing features).
I would understand if, at the initial planning meeting, we reworked the scope of the project based on time and labor requirements, but after presenting my designs, everyone agrees to what is in the document, and then I later find that someone (usually someone who signs my paychecks) has been communicating something less-than or not-equal to the agreed upon design.
How do you manage to keep everyone's understanding of the requirements consistent over time? I could just force everyone to read the entire document, but the junior engineers don't necessarily need to have a model of the entire product in their head at all times if their concern is doing a really good job on their particular component.