paul78 said: Yeah - BSA's are probably the closest title and role if there's an expectation that the role understands the product and is more closely aligned to the tech/product team. But if it's closer to someone that is mostly just taking notes and interviewing SMEs, then that's a tech writer, imo.
DatabaseHead said: Thanks for your expertise, appreciate it. Agreed just taking artifacts and flipping them into diagrams is a tech writer, no question about it. This is more in the weeds. With that said I am not comfortable calling them either.... For example they will need to understand the objectives of the API's what is getting updated etc. Same with EDI, which documents do what and when... 850, PO, 945 Ack. Etc....
paul78 said: DatabaseHead said: Thanks for your expertise, appreciate it. Agreed just taking artifacts and flipping them into diagrams is a tech writer, no question about it. This is more in the weeds. With that said I am not comfortable calling them either.... For example they will need to understand the objectives of the API's what is getting updated etc. Same with EDI, which documents do what and when... 850, PO, 945 Ack. Etc.... Perhaps it's industry specific. But what you describe does sound exactly like a bsa to me. In the past, I had bsa's tied to engineers/architects on the agile teams. The ba's would develop the business and product requirements and the bsa's would work with the architects or lead engineers to create the functional specs. paul78 said: Yeah - BSA's are probably the closest title and role if there's an expectation that the role understands the product and is more closely aligned to the tech/product team. But if it's closer to someone that is mostly just taking notes and interviewing SMEs, then that's a tech writer, imo.
paul78 said: DatabaseHead said: Thanks for your expertise, appreciate it. Agreed just taking artifacts and flipping them into diagrams is a tech writer, no question about it. This is more in the weeds. With that said I am not comfortable calling them either.... For example they will need to understand the objectives of the API's what is getting updated etc. Same with EDI, which documents do what and when... 850, PO, 945 Ack. Etc.... Perhaps it's industry specific. But what you describe does sound exactly like a bsa to me. In the past, I had bsa's tied to engineers/architects on the agile teams. The ba's would develop the business and product requirements and the bsa's would work with the architects or lead engineers to create the functional specs.