3 ms·

> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing re

> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.

afpx 2y ago
Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.
- throwaway14356 2y ago
  would it be possible to just work on writing everything down and use all the time it takes? I imagine the complicated part would grow wordy enough to stick out like a sore thumb. Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to) (disclaimer: I know nothing, im just reading the comments.)
  - zerkten 2y ago
    What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc. You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently. Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality. As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help. When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.
Too 2y ago
These experts may also be hesitant to change. It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs. On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".
- carlmr 2y ago
  For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.
BurningFrog 2y ago
Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team. You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work. Costly, but I don't trust any other way.
- zerkten 2y ago
  I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided. What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM. Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis. Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.

afpx 2y ago

Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.

throwaway14356 2y ago
would it be possible to just work on writing everything down and use all the time it takes? I imagine the complicated part would grow wordy enough to stick out like a sore thumb. Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to) (disclaimer: I know nothing, im just reading the comments.)
- zerkten 2y ago
  What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc. You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently. Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality. As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help. When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.

Too 2y ago

These experts may also be hesitant to change. It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs. On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".

carlmr 2y ago
For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.

BurningFrog 2y ago

Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team. You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work. Costly, but I don't trust any other way.

zerkten 2y ago
I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided. What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM. Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis. Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.