3

WHEN:
...when the analyst decides whether a feature is too complex to implement or not.

So you don't get the requirements because he thinks it's too complex.

So you develop something that has nothing to do with requirements. Actually much more complex.

And after that, one week before deployment, the customer actually show you and the analyst that what you did is fucking useless.
It was much easier, or at least completely different.

Comments
  • 0
    Why do you need to develop something that was blocked internally in your company for being to complex? Or did I get this wrong? 🤔
  • 1
    @jthm it's blocked internally by a nontechnical somebody who "thinks" is too complex. On the other side he promotes "easy" things that are not (in the last moment because they are "easy")
    . In both cases, in the end they are not what the customer want
  • 1
    If it's "too complex" then the analyst didn't do their job. Don't want to be too harsh on analysts, but most of them don't analyse. Most tech people don't analyse. An important part of analysis is breaking a complex topic down into simpler steps.
  • 0
    Then you/your team should find a way to get the client requirements directly
  • 0
    @jthm yes indeed, I called the client, I discussed and negotiated with him the requirements, I asked him to explain them to our analyst, so finally (unknowingly) our analyst called me and explained to me the (my) requirements.

    Puke.
Add Comment