10 rules for business analyst

Introduction

I worked for 1.5 years in a large, large company that deals with wholesale and retail supplies of oil and gas equipment (turnover of about 30kkk rubles). Inside, a management system (developed on 1C) is implemented, which includes several configurations for several bookkeeping, warehouses, etc. About 2k users working on the system daily.

The whole system is supported and developed by a team of analysts. During this time, we have developed rules that, in my opinion, will help all analysts (business, requirements) and managers, support staff and even a few developers in the large enterprise segment.

1. Analytics feet are fed

This rule came up with my colleague. If you are in the same building with users and key customers, then they need to visit and talk with them. Since not everyone is able to clearly and clearly express their thoughts in writing, sometimes one 15 minute conversation can replace three-day correspondence.

Ignoring this rule will lead to long mail correspondence and endless formalization of tasks.
')

2. Draw

Drawing business process diagrams and sketches of the interface will allow you to understand the problem for you and it is easy to explain your vision to the user. Beautiful schemes of business processes make a huge impression on the customer management. Personally, I used the EPC notation with arbitrary additives (simple enough to understand and quite clearly).

Ignoring this rule will make your work boring and will cause you to spend much more time understanding the task and explaining it.

3. Simplify (or do not complicate)

Analysts and business analysts tend to complicate tasks more often than they would like. Regularly it negatively affects the result. I believe that it is necessary to solve problems as simply as possible.

Somewhere after a year of work, I realized that I had to think according to the following algorithm:

a) come up with a simple solution;
b) trying to figure out why not suitable;
c) we complicate a little;
d) trying to figure out why not suitable;
e) we complicate a little;
etc. until the solution is optimal.

Ignoring this rule will lead to the creation of bicycles and unnecessarily complex decisions that no one will use.

4. Interview all future users and all participants in the process.

The vision is subjective, so try to find out the opinions of all who are affected by the future refinement, even those who will be affected contiguously. In practice, there is always an active user who bends his line, but it may be wrong, since he does not know all the pitfalls and activities of other departments as well as his own.

Ignoring this rule will lead to the fact that the decision will not suit everyone, and will satisfy only one user with whom you work.

5. Get to the bottom of the problem.

Users constantly ask for some buttons on the forms, some filters on the lists and do not like to explain why. But having found out the answer to the question “Why?” You can come up with a completely different solution that will probably work better and more efficiently.

Ignoring this rule will lead to the fact that the decision will be incomplete or will not meet all the requirements of the task.

6. Solve global problems

For example, you are asked to make a document to include a department in the process of working in your ERP system. Based on this requirement, you should set the global task “Automation of the department of plan-economic department” and clarify related requirements, but also get to the bottom of the essence, according to rule 5. This will help to immediately develop a solution that will cause fewer improvements in the future.

Ignoring this rule will result in problems not being solved.

7. User aims for success (result)

It is a very common misconception that the user or customer does not understand what they need and have little interest in the result. The myth came from the fact that they regularly savor the little things and there most drag on the development. In fact, all users and customers want results. Do not forget about it!

Ignoring this rule will lead to the development of conflicts.

8. Make universal decisions (do not automate automated)

A huge number of activities are automated. There are enough universal solutions for trading, doing tasks, accounting, etc. But each next customer believes that it is his company that does not work like everyone else and the processes do not like everyone else. Sometimes this is true, but in most cases the easy change of processes to classical ones will save the client a lot of money, and you have a lot of nerves.

Ignoring this rule will lead to unnecessary waste of resources.

9. The performer must understand what he is doing.

Analysts are often too lazy to explain to the developers the essence of the problem, and those are too lazy to listen and understand. It is necessary that the developer understands what he is doing and why, and not just "add a button that ...". This will allow the developer to make an informed decision, and sometimes give wise advice to the analyst.

Ignoring this rule will lead to bad decisions in terms of development.

10. Avoid ambiguity

Break the task down to such details so that the vision of the result is unique for you, for key users and for developers. This is not always possible, but striving for it is necessary.

Ignoring this rule will result in solving non-responsive tasks.

Recommended literature:
1. " Development of requirements for software ", 2004. Karl Wigs
2. " Principles of working with software requirements. A unified approach ", Dean Leffingwell, Don Wiedrig