Mixing
Handy role title for someone managing the development and requirements processes [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
We need to recruit someone who has experience in software development processes, i.e., from requirements management to delivery and maintenance (but not operations and systems administration), maybe an experienced developer. Additionally, the way we collect and manage requirements, together with the business departments, needs to be redesigned and implemented as to support the pursued (new) development approach, which may be done successfully by a good business analyst or the like. Naturally, we see this in the hands of the same one person, and we only have the budget for one new employment. Important note: the position is not linked to a particular team or project, since we rather see it as a staff position, with few (if any) "subordinates". Also, no software architecture(s) shall be covered.
For the former aspect, role titles such as "development coordinator" have already been proposed; for the latter, we currently have "requirements manager". But we need one role title that describes both aspects.
recruitment
asked Mar 30 '15 at 12:10
André
62
closed as off-topic by Thomas Owens, David K, gnat, IDrinkandIKnowThings, Chris E Mar 30 '15 at 14:30
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – David K, gnat, IDrinkandIKnowThings, Chris E
suggest improvements |Â
up vote
0
down vote
favorite
We need to recruit someone who has experience in software development processes, i.e., from requirements management to delivery and maintenance (but not operations and systems administration), maybe an experienced developer. Additionally, the way we collect and manage requirements, together with the business departments, needs to be redesigned and implemented as to support the pursued (new) development approach, which may be done successfully by a good business analyst or the like. Naturally, we see this in the hands of the same one person, and we only have the budget for one new employment. Important note: the position is not linked to a particular team or project, since we rather see it as a staff position, with few (if any) "subordinates". Also, no software architecture(s) shall be covered.
For the former aspect, role titles such as "development coordinator" have already been proposed; for the latter, we currently have "requirements manager". But we need one role title that describes both aspects.
recruitment
asked Mar 30 '15 at 12:10
André
62
closed as off-topic by Thomas Owens, David K, gnat, IDrinkandIKnowThings, Chris E Mar 30 '15 at 14:30
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – David K, gnat, IDrinkandIKnowThings, Chris E
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
We need to recruit someone who has experience in software development processes, i.e., from requirements management to delivery and maintenance (but not operations and systems administration), maybe an experienced developer. Additionally, the way we collect and manage requirements, together with the business departments, needs to be redesigned and implemented as to support the pursued (new) development approach, which may be done successfully by a good business analyst or the like. Naturally, we see this in the hands of the same one person, and we only have the budget for one new employment. Important note: the position is not linked to a particular team or project, since we rather see it as a staff position, with few (if any) "subordinates". Also, no software architecture(s) shall be covered.
For the former aspect, role titles such as "development coordinator" have already been proposed; for the latter, we currently have "requirements manager". But we need one role title that describes both aspects.
recruitment
asked Mar 30 '15 at 12:10
André
62
We need to recruit someone who has experience in software development processes, i.e., from requirements management to delivery and maintenance (but not operations and systems administration), maybe an experienced developer. Additionally, the way we collect and manage requirements, together with the business departments, needs to be redesigned and implemented as to support the pursued (new) development approach, which may be done successfully by a good business analyst or the like. Naturally, we see this in the hands of the same one person, and we only have the budget for one new employment. Important note: the position is not linked to a particular team or project, since we rather see it as a staff position, with few (if any) "subordinates". Also, no software architecture(s) shall be covered.
For the former aspect, role titles such as "development coordinator" have already been proposed; for the latter, we currently have "requirements manager". But we need one role title that describes both aspects.
recruitment
asked Mar 30 '15 at 12:10
André
62
asked Mar 30 '15 at 12:10
André
62
asked Mar 30 '15 at 12:10
André
62
asked Mar 30 '15 at 12:10
André
62
62
closed as off-topic by Thomas Owens, David K, gnat, IDrinkandIKnowThings, Chris E Mar 30 '15 at 14:30
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – David K, gnat, IDrinkandIKnowThings, Chris E
closed as off-topic by Thomas Owens, David K, gnat, IDrinkandIKnowThings, Chris E Mar 30 '15 at 14:30
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – David K, gnat, IDrinkandIKnowThings, Chris E
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54
suggest improvements |Â
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
I believe that the best starting point for you would be software engineer. What you describe is someone who has knowledge of or exposure to nearly all aspects of software engineering, but particularly what is referred to in the Wikipedia article as requirements engineering, software engineering management, software engineering process, and software engineering tools and methods. It sounds like you're particularly interested in someone with expertise in business process improvement or process management, but with particular expertise in the software field.
I'm a little concerned, though, when you say that you aren't interested in covering software architectures. Enterprise Architecture is not just the technical architecture and design of software systems, but also how teams form around the work. If you wanted to enable something like product line engineering, that would likely be not only process changes, but also organizational changes to support it. A role that you describe would have to be involved across all software development activities.
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
I believe that the best starting point for you would be software engineer. What you describe is someone who has knowledge of or exposure to nearly all aspects of software engineering, but particularly what is referred to in the Wikipedia article as requirements engineering, software engineering management, software engineering process, and software engineering tools and methods. It sounds like you're particularly interested in someone with expertise in business process improvement or process management, but with particular expertise in the software field.
I'm a little concerned, though, when you say that you aren't interested in covering software architectures. Enterprise Architecture is not just the technical architecture and design of software systems, but also how teams form around the work. If you wanted to enable something like product line engineering, that would likely be not only process changes, but also organizational changes to support it. A role that you describe would have to be involved across all software development activities.
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
 |Â
show 1 more comment
up vote
0
down vote
accepted
I believe that the best starting point for you would be software engineer. What you describe is someone who has knowledge of or exposure to nearly all aspects of software engineering, but particularly what is referred to in the Wikipedia article as requirements engineering, software engineering management, software engineering process, and software engineering tools and methods. It sounds like you're particularly interested in someone with expertise in business process improvement or process management, but with particular expertise in the software field.
I'm a little concerned, though, when you say that you aren't interested in covering software architectures. Enterprise Architecture is not just the technical architecture and design of software systems, but also how teams form around the work. If you wanted to enable something like product line engineering, that would likely be not only process changes, but also organizational changes to support it. A role that you describe would have to be involved across all software development activities.
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
 |Â
show 1 more comment
up vote
0
down vote
accepted
up vote
0
down vote
accepted
I believe that the best starting point for you would be software engineer. What you describe is someone who has knowledge of or exposure to nearly all aspects of software engineering, but particularly what is referred to in the Wikipedia article as requirements engineering, software engineering management, software engineering process, and software engineering tools and methods. It sounds like you're particularly interested in someone with expertise in business process improvement or process management, but with particular expertise in the software field.
I'm a little concerned, though, when you say that you aren't interested in covering software architectures. Enterprise Architecture is not just the technical architecture and design of software systems, but also how teams form around the work. If you wanted to enable something like product line engineering, that would likely be not only process changes, but also organizational changes to support it. A role that you describe would have to be involved across all software development activities.
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
I believe that the best starting point for you would be software engineer. What you describe is someone who has knowledge of or exposure to nearly all aspects of software engineering, but particularly what is referred to in the Wikipedia article as requirements engineering, software engineering management, software engineering process, and software engineering tools and methods. It sounds like you're particularly interested in someone with expertise in business process improvement or process management, but with particular expertise in the software field.
I'm a little concerned, though, when you say that you aren't interested in covering software architectures. Enterprise Architecture is not just the technical architecture and design of software systems, but also how teams form around the work. If you wanted to enable something like product line engineering, that would likely be not only process changes, but also organizational changes to support it. A role that you describe would have to be involved across all software development activities.
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
answered Mar 30 '15 at 12:29
Thomas Owens
13.4k45368
13.4k45368
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
 |Â
show 1 more comment
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
Enterprise Architecture sounds promising. We want to avoid a "technical" role title because we already have a couple of skilled people, and we need them to accept this person as someone who supports them and their work process, instead of opposing à la "so this guy is going to tell us how to do our work". It's really also a "bridge" between the "IT guys" / software team on the one hand, and the business people on the other.
– André
Mar 30 '15 at 13:04
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
@André In that case, I'd focus on business process improvement, with experience in software development. There are a lot of buzzwords and keywords floating around: Capability Maturity Model Integration (CMMI), Lean Software Development, Six Sigma for Software, Rational Unified Process, Scrum, Disciplined Agile Delivery, Crystal, Enterprise Unified Process, Team Software Process...the list goes on. What you do want to avoid, though, is someone pushing a particular model or methodology without understanding your business and the operating environment. Very rarely does one fit out of the box.
– Thomas Owens
Mar 30 '15 at 13:09
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
Very interesting - maybe we should call the role "Software development process manager" - and the methods and models you propose may serve as good "inspiration" or even (formal) base. Thanks!
– André
Mar 30 '15 at 13:30
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
@André I would be careful with the word "manager". That, to some, would imply that they have direct reports (that is, they are a manager). Although they are managing a process, it's not explicitly false, but it could be misleading. If this group grows, however, the leader would likely be a "manager" and the other people would likely be "process improvement engineers" or "process improvement specialists".
– Thomas Owens
Mar 30 '15 at 13:33
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
That's also true. I begin to feel we should use a rather short term, not using "manager", and really describe the tasks explicitly, as suggested before. "Architect" sounds a bit too "academic" to me, in the sense that they don't focus on something that actually works in "real life". Please don't get me wrong. As opposed, I do like the "engineer" term, which sounds like "hands-on" work. With "processes", it seems to be used more in the manufacturing domain. "Software engineer" is what you said in the first place :-)
– André
Mar 30 '15 at 13:43
 |Â
show 1 more comment
Look up "business analyst" on linkedin. See from a sample of the profiles listed there if "business analyst" fits your description. Given the inherent vagueness of "business analyst", you will have to provide a job description anyway.
– Vietnhi Phuvan
Mar 30 '15 at 12:20
BA's don't tend to have great Dev skills from my experience, not because they can't but because those development skills aren't always in alignment with what BAs do on a daily basis. Business Analysists tend to go offsite to meet clients a lot etc. You want a developer who is primarily a developer. If they're a BA as well, unless they are very experienced, one of those sides will suffer. OP doesn't want to touch architecture, but that's what they're asking for. They want a solutions architect.
– James
Mar 30 '15 at 13:13
Thank you - how much focus would a solutions architect put on the "how" part of requirements analysis? Although I'm usually cautious with the word "architect", I like it more in combination with "solution". Sounds like "we get something done". And really, we need to do something about the methodology of the "touch points" of business and development: how to know what software (change) is needed, and how to deliver results. I know this is quite comprehensive.
– André
Mar 30 '15 at 13:54