Reply to: Analyst skills/technologies

[LondonManc]

They want you back at the ranch

Not my fault that my prototypes are better than the other team's end product.

[MrMarkyMark]

With BI it's usually make one and shove it live

"But the numbers haven't been tested, it was just for look and feel"
"And it looks and feels good - get it promoted to live!"

They want you back at the ranch

[LondonManc]

I suppose prototypes are a part of waterfall and classic methodologies anyway, but in Agile the "make one to throw away" idea is replaced with continuous refactoring. All those little details you get even in a prototype are valuable. Unless your prototype is "I knocked this up in VBA+Excel during lunch".

With BI it's usually make one and shove it live

"But the numbers haven't been tested, it was just for look and feel"
"And it looks and feels good - get it promoted to live!"

[d000hg]

I suppose prototypes are a part of waterfall and classic methodologies anyway, but in Agile the "make one to throw away" idea is replaced with continuous refactoring. All those little details you get even in a prototype are valuable. Unless your prototype is "I knocked this up in VBA+Excel during lunch".

[MrMarkyMark]

I think this is a big strength of Agile, they get the chance to say "what the hell is that? That's not what we wanted, it needs to do..." very early on rather than when you deliver it for testing

The value of being able to be hands-on with some crappy prototype is invaluable, you get requirements creep caught as part of the initial requirements.

Very much a necessity to prototype where I am.

Costly "mistakes" can be made otherwise.

[d000hg]

I think this is a big strength of Agile, they get the chance to say "what the hell is that? That's not what we wanted, it needs to do..." very early on rather than when you deliver it for testing

The value of being able to be hands-on with some crappy prototype is invaluable, you get requirements creep caught as part of the initial requirements.

[MrMarkyMark]

Or don't know how to communicate the requirement properly. A fresh business analyst won't have the experience to dig behind the requirement to drag out the details.

You know I told you about the guy nick named at current client co.

We called him the "walking requirement" as I , amongst others, would usually rushing after him scribbling fiercely notebook in hand

[LondonManc]

Even the people who know what they want often don't really know what they want. This stuff is really hard to do well.

Or don't know how to communicate the requirement properly. A fresh business analyst won't have the experience to dig behind the requirement to drag out the details.

[MrMarkyMark]

Even the people who know what they want often don't really know what they want. This stuff is really hard to do well.

Very true

Good analysis is a real skill and I'm not talking about what is usually trotted out.

[d000hg]

I'd say that the real problem lies with the analysts failing to conduct business interviews with the correct staff in that scenario.

Even the people who know what they want often don't really know what they want. This stuff is really hard to do well.

[MrMarkyMark]

They the bodgit and scarper bob they brought in on a much cheapness rate to "fix" it has created SQL Server tables starting with numbers and spaces galore in table names because that's what they were like in Access.

[LondonManc]

They the bodgit and scarper bob they brought in on a much cheapness rate to "fix" it has created SQL Server tables starting with numbers and spaces galore in table names because that's what they were like in Access.

[MrMarkyMark]

Access? It will be 45 separate interconnected Excel spreadsheets created by John who left in the last lot of voluntary redundancies 3 months before you arrived.

I exaggerate slightly there but only very slightly....

Not in IB Matey. The SQL Server in the cupboard is true, it even had a sticker on it saying "Please do not switch off - Live system"

The solution of choice often involves a multitude of Access databases, often linked together, complete with macros, then using Excel for the presentation.
Obviously, these take a long time to run, or fail to run at all, as the users "like" to join multiple fact tables directly

The only saving grace is the regulator takes a dim view of such arrangements, thus giving me many months of paid work "converting" them to an acceptable regulatory reporting platform.

In addition it seems that, on the quiet, the users are creating plenty of other naughty things thus insuring plenty of future work to come.

[eek]

Agreed.

Obviously, as an experienced analyst who has worked his way up, you ignore that completely and speak to the people on the ground.

They will tell you about all the user supported "live" SQL servers (the box is in the cupboard, Mate) and all the access databases that support the real live systems, that senior management haven't got a feckin' Scooby about.

Access? It will be 45 separate interconnected Excel spreadsheets created by John who left in the last lot of voluntary redundancies 3 months before you arrived.

I exaggerate slightly there but only very slightly....

[MrMarkyMark]

Often the 'analyst' is guided to speaking to senior members of staff as they 'know the answers' and they are not encouraged or even allowed to speak to staff at the grass roots level.

But yes horses for courses is always the best approach.

Agreed.

Obviously, as an experienced analyst who has worked his way up, you ignore that completely and speak to the people on the ground.

They will tell you about all the user supported "live" SQL servers (the box is in the cupboard, Mate) and all the access databases that support the real live systems, that senior management haven't got a feckin' Scooby about.