5

I'm a junior web developer at my first company. We have a business analyst that communicates with the sales team and developers. The business analyst is responsible in creating specifications for the feature request.

My question is, should I just follow the business analyst's perspective of the feature request even though it might be complicated or difficult to implement in my side as a developer? I'm thinking if i just lack knowledge and experience or is there a times that you do not follow BA's perspective because as a developer, we know that it is not feasible.

Improve this question
2
  • Another issue to consider about any requirement before writing any code is if it is testable. If you have a QA team have one of them look over the requirements. Even invite them to the meetings. If you don't, congrats, you programmers are QA. Invite a second programmer to the meetings and have them think about how they'd test your code against these requirements. Untestable requirements deserve a second look.
    – candied_orange
    Commented Jul 22, 2021 at 16:59
  • BA's make requirements based on what customers/stakeholders want. In my experience sometimes it is impossible to implement some requirements or sometimes they are mutually exclusive. The BA isn't an expert on how computers work so they can't know - you need to be part of the conversation so make sure you communicate to the BA what can be done and what can't so they can go back to the stakeholders and negotiate something that works.
    – Jerry Jeremiah
    Commented Mar 7, 2022 at 1:30

5 Answers 5

Reset to default
8

You probably shouldn't just be following the business analyst's perspective.

From a technical perspective, they probably don't have as much insight as you regarding the feasibility or difficulty of implementing a given requirement based on the system's current state. They (and the stakeholders they are representing) probably don't want to spend an infinite amount of time and money on developing the system, so providing reasonable estimates of effort, identifying potential risks, and even offering alternative technical solutions is well within what I would expect the developers to do.

Beyond just the feasibility of what is stated, it's also important to look at the broader context. Do any of the requirements conflict with what is currently in the system? Are there requirements that may be missing, perhaps based on your knowledge and experience? If so, be sure to raise these early so that they can be resolved. Depending on what they are, the stakeholders may need to be involved in deconflicting the requirements, which can take time.

This could be difficult as a junior web developer. I wouldn't necessarily expect someone at a junior level to do these types of things. I would, however, expect an effort to learn, though. Engaging with the business analyst to learn more about the stakeholders, their needs, and the context of the system would be a good step. Working with senior developers on decomposing, analyzing, and refining requirements would also be a good step. These skills can't be fully learned by reading and must be practiced, preferably with oversight and feedback from more experienced developers.

Improve this answer
1
  • thank you for the wonderful insights @Thomas Owens. It gave me an idea how to handle and what actions needs to be done. I'll try my best to communicate with my senior devs and BA.
    – Pocoyo
    Commented Jul 21, 2021 at 18:23
11

I'm also not sure whether this is the right place, but it's certainly a common situation that you encounter as a software engineer.

The key is communication. Don't view this as a one way street where requirements flow from the BA to devs. If something isn't clear or seems to be too difficult or even impossible, TALK! Talk to the BA, talk to your colleagues, talk to your manager. Don't just complain that you were given an impossible task, but work on clarifying the requirements, possibly suggesting that they need to be changed to be conflict free, complete, and possible to implement. Part of your task as a dev is to think about and understand what's required, not simply let the BA do the thinking. It might turn out that you're missing some skills and experience, which would mean an opportunity to learn. It might also be possible that the BA didn't fully understand the business requirement and wrote a confused feature request. The only way to find out is to talk.

Improve this answer
7
  • Thank you for sharing your thoughts @Hans-Martin Mosner. I have follow up question. As a dev, do you apply/implement your own ideas beyond what's stated in the specifications? For example, feature request of login form, and the details in the specifictions are: 1) Create login form 2) There should be a input text box for username and password 3) There should be remember me checkbox 4) login/cancel button, forgot password Your own ideas to apply are: 1) Validate login credentials 2) There should be error message 3) Modern user interface login form 4) etc...
    – Pocoyo
    Commented Jul 17, 2021 at 20:57
  • 1
    @Pocoyo: Your ideas are implied from the specifications you were provided. What would be the point of having a login form if you don't use it to authenticate and authorize the user?
    – Robert Harvey
    Commented Jul 17, 2021 at 22:13
  • 3
    @Pocoyo "the key is communication". Float those ideas to your fellow developers and the BA. Don't judge. Just make clear what you're thinking of doing before you do it.
    – candied_orange
    Commented Jul 17, 2021 at 22:58
  • @Pocoyo 1) "Validate login credentials" should be done somewhere, but not necessarily in the code you were asked to write to create the form. 2) An "error message" can be a security risk - e.g. it tells a hacker they have a valid username but the wrong password, which is useful information. 3) "Modern user interface logic form " - if that means "I'm going to create a form that looks completely different from the spec" that is not the way to go - for example your page needs to match the style of all the rest of the UI even if you think the design is "out of date"
    – alephzero
    Commented Jul 18, 2021 at 8:02
  • 1
    Thank you guys for the informative comments. @alephzero got my point. I'm not a sophisticated person so sometimes I need specific details stated. It only stated to create login form but not to implement authentication. It pops in my mind, should I implement the authentication now? But it would take more estimations. This time, I'll communicate with BA and senior dev what would my implementations are versus expectations.
    – Pocoyo
    Commented Jul 21, 2021 at 18:43
1

Plans for any system under development will tend to change over time. This happens as understanding changes and increases on both sides (developer and "customer", or analyst in your case) over time. The fact is that due to the inherent complexities of software development, neither of you is likely to know exactly what the end product will look like. In my personal experience, the end product is often significantly "slimmed down" compared to the initial idea. If it can still delivers the most important things the end users want, and is considered a success.

I'm sure the analyst will have a handful of ideas and perhaps a grand long-term vision for what you are building, but he won't have all the details, and he'll likely lack at least some technical understanding, not only of the potential difficulties, but also of the possibilities ahead.

In addition to coding then, your job is two-fold:

  1. To try to understand the business as well as you can - not just the abstract spec from the analyst, but also what the end user actually wants and needs. For this, I'd actually try to talk to one or more end users if possible; even a 5-10 minute conversation can clarify a lot, and perhaps simplify some of the requirements.
  2. To convey back to the analyst (and perhaps the end users) which options they have, and how they compare. If you can help them understand the cost (or the alternative cost) of each option, then you can help them make better, more informed decisions. If you're lucky, perhaps you can find things that can be dropped or modified slightly to made development faster and easier. If you can identify simple improvement opportunities as well, then even better.

If you think the analyst is misunderstanding something, or making decisions that are resulting in an suboptimal use of time and resources, then try to find a way to share your thoughts. Try to be constructively though - avoid stepping on too many toes. How? Provide positive alternatives: Instead of just saying "I don`t think this is going to work", try to go more along the lines of: "I'm not entirely certain that this is the best approach. Have you considered any other options? How about either X or Y?"

Nudging someone along like this can be a delicate balancing act, especially if pride is involved, and it may feel as if it has little to do with programming. If you want your work as a developer to continue to feel positive and meaningful however, it's important to be able to tackle such things.

In the end, it's all about developing a sense of responsibility and ownership both to the process and to the product you're building. Any good business analyst should appreciate this, and welcome your feedback and input - so long as it is provided in a professional and respectful manner.

Improve this answer
0

Every requirement has a value: Happier end users, more sales, etc. The business analyst should understand the value. Every requirement also has a cost: The cost of the developer delivering the requirement. The developer should understand the cost.

A requirement should have higher value than cost. But the business analyst likely doesn't understand the cost or doesn't understand it well. You get overall the best results if the analyst doesn't reject requirements because he overestimates the cost, and the developer gives feedback about the cost. A requirement might have three parts A, B and C, where C produces the least value. And the developer figures out that C actually has the highest cost. With that feedback the requirement can be changed to dropping C.

So communication is important. Also from analyst to developer: The developer will be less motivated to do work that they believe produces low value, so things work better if they are told why the value of a feature is much higher than they believed.

And you have situations where as a developer you know that implementing any one of five features has a high cost, but if one is implemented, suddenly the cost of the other four is much lower. So the reasonable choice, which the analyst might not know, would be to implement either none of the features or all five.

Communication is the key here. What would be quite bad, both for the company and for your career, is if you just decided not to implement a requirement because you think it is too costly. You talk to the business analyst, and several things can happen that are better: 1. The business analyst tells you that the cost of a requirement might be very high, but the value is also very high, and it should be implemented. 2. Between you and the business analyst you find modified requirements that produce almost the same value, but are much cheaper. 3. The business analyst realises that the requirement is not cost effective, and removes it - and removes other requirements that lose their value if that one requirement isn't there.

Improve this answer
0

There's a lot that goes in to development projects.

  • client requests
  • ideation
  • low fi design mocks
  • revising low fi design mocks
  • high fi mocks
  • architecture
  • frontend
  • backend
  • QA testing, functional testing, e2e testing

Depending on the size of your company, you may or may not have people to fill these roles. There may be people wearing multiple hats. BA's in my experience are largely responsible for requirements. Sometimes, they'll take on PM roles as well.

Regardless of experience, I think most everyone appreciates questions, comments, and creative ideas. If you know that something may be problematic, speak up and say something. Especially now, where it's commonplace for people to work remotely and often times hide behind their screens. Meeting participation goes a long way. My suggestion is, whatever relative Q&A you have, put it out there. It certainly can't hurt, and I doubt anyone, especially the BA would shame you for offering developer insight.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.