Quick action list after Lviv IT Arena 2014

4 Oct

After the conference is over and I still remember the books/materials I should be reading soon, I’d better list them here

In terms of prioritizing the list, I think it would be as follows:

  • UML in 24h (Joseph Schmuller)
  • The mythical man month
  • The writer’s journey

then the rest


Useful Links for a Business Analyst

15 Apr

Alright, it has been a long time since I’ve posted anything.

I am going to frequently update this post with useful links


7 Apr

Plans for 2013

16 Mar

Big plans for 2013:

  • become eligible for CCBA examination with 3750 hours of real project experience and take the actual examination
  • complete three technical coursera courses (system design and need to define two more). I also need to make sure I complete Introduction to Databases this March and pass
  • take a soft skills course – communication related
  • Not really BA related but very important
  • get a driver’s license
  • put together the Eleks band thing this summer


Discovering people

1 Feb

As I’ve just found out, one of the chief developers in the project I work on, is quite into philosophy and even writes philosophy comics. Need to bookmark this link for future reference. This finding only makes me more certain that to be a comic, the person needs to have a highly-developed left brain hemisphere. Best jokes have impeccable logic behind them even though I love absurd jokes more. But the reason I do so is because absurd jokes appear to have a broken logic behind them and I just love things that are crooked and broken

Wizard of OZ prototyping

12 Jan

Reviewing the video lectures in HCI course published by Stanford professors on Coursera, I’ve learnt about the Wizard of OZ technique. The idea is that something is being shown as a functionality/feature while in reality it’s being handled/done by a Wizard behind the scene.

More information can be found here

In reality we have been using this technique very often, especially during demos. The idea is to code/implement a limited set of scenarios and demonstrate them only without a demonstration of anything not functional. The key difference is that, in the lecture the professor mentions it’s best to tell the truth and inform about the gaps at the end of the experiment but in reality this is something we don’t do.

The lecturer also compares low-fidelity vs high-fidelity prototypes. The point is to use low-fidelity at the start of the project to attract criticism and comments and eventually target to a highly usable and attractive product. Users are more reluctant to criticize or voice their concerns about flaws when something is done nicely even though it’s buggy or half-cooked

Why do we need to use assurance?

2 Dec

As said by the professor during the “Think again” course on Coursera, we use assurance just because we have limited time. So basically, sometimes it’s necessary to cut the crap and put the foot down before spending a ridiculous amount of time investigating all of the possible scenarios.

Very good point and another missing part in my BA repertoire