Geekly Articles each Day
📜 ⬆️ ⬇️

How, to whom and why go to consulting? Personal experience on the example of Big Data

Today I will talk about how IT consulting works on the example of Big Data, share my personal experience, how I got into this field, and case studies from practice, and also give advice on who and why it is worth trying myself in consulting.


I graduated from the Faculty of Mathematics of Kharkiv National University named after V.N. Karazina, got into DataArt on the position of Java Trainee and worked there for the next 6 years. My career has developed rapidly due to the fact that love has come together to solve complex puzzles, my innate desire to learn, constantly find something new for myself and a team of mega-professionals. Once I was attracted to an internal IoT project, where we, along with other enthusiasts, understood how to connect sensors to a microcontroller, where to store (and most importantly, whether?) This huge amount of data, how to process it later, how to track it in real time system state, predict breakdowns, where and how to host it all, etc. So we very quickly came to the questions and challenges of BigData.


This gave a strong impetus to my development and allowed me to work in 15+ IoT and BigData projects, regularly participate in pre-sales, speak at conferences and with educational courses. My position during this time has changed from Senior Developer to Big Data Architect. At first it was interesting, but over time it turned into a routine for me. In most cases I went to the project, the first month or two was very active, I adjusted the processes, communicated with the client and thought through the architecture, and after that I became the same person. lead, PM, business analyst and many more by whom)) After six months it all turned into an endless groundhog day.

Therefore, in search of new experience and new challenges, I moved to SoftServe. After almost a year, I can share my experience and vision of how things work here.

First, let's look at how the consulting process works. After all, most of the IT people involved in the project, when there is already a contract, a budget, a manager, and it is relatively clear what, when and which team to do. Few people wonder how new projects get into the company in principle and what happens to it at the initial stage.


In fact, in the life of each project can be identified such phases:



Discovery phase - this is the very consulting for which we are all gathered here. As soon as a contract is signed, someone from the consulting group goes to the client. Ideally, he is joined by a business analyst with a UX designer (I would advise those interested in methodology to read about Design Thinking, an approach that I have already experienced in my own practice more than once). In an ideal ideal, there is also an engagement manager, who takes care of all the questions of the organization of the process, and a narrow-profile specialist.



At the exit, this group provides the client with a document that contains:



If everything is going well and the client signs the next phase, then the architect for some time (most often part-time) works on this project. Until the process is established, the workload is clear, and the client is satisfied. If everyone here is satisfied and wants to continue to cooperate, then follow Proof of Concept (PoC), Minimum Viable Product (MVP) and further Implementation and Support.


It would seem that this whole process is clear, structured and understandable. But in practice, things are not so simple. Let's look at possible scenarios.

Here comes to us a potential customer. The sales team holds the first calls / rallies to understand what kind of problem they need to be solved, and turns to more specialized specialists. If the project requires knowledge of the Big Data Stack, then a potential client comes to my group.
')
The next step is to understand the level of complexity of the task and determine which experts are needed. There are several options.

The client does not know what he wants


Most often this happens in large and adult enterprise companies that understand that they are losing money, but do not understand why. Or they understand, but they do not at all imagine how to fix it.


From my experience I can say that often in such a situation, you need to first solve the problems of business, and only then technologies. You need to be prepared for the fact that it is not easy and there may be interested people who try to draw you into their political games.
For example, one of the CTOs with whom I was lucky to be familiar, once led me to a strategic rally to discuss the purchase of a license for one popular product. The official reason for my appearance was just an acquaintance. The board of directors was delighted with the upcoming deal and sang the praises of his future partners. Being an honest and thinking person, I asked a few more substantive questions about how they are going to integrate. There was no answer, and the deal was canceled. Coming out of the meeting room, I asked the CTO if I didn’t overreach the stick with my questions and whether it was worth it at all to go into all this. To which the "secret cardinal" replied: "Everything is super, I brought you there for this and led him."

How to avoid it? No, this is consulting. You have to be ready for this, in which you personally help me with knowledge of psychology, more experienced colleagues and personal experience, of course.

The client has a vision of the final product, but he needs our expertise to make sure that he is right.


Probably the most profitable option in terms of time-consuming. Much less effort will be spent on finding a problem, it will be much more productive to communicate with the customer, for whom your opinion is still authoritative.


However, there are pitfalls. For one of our clients in the financial field, the Discovery phase was designed for 4 weeks, 2 weeks for onsite and offsite. The client for 2 weeks onsayta did not say a word that he already has his own vision of architecture. There was a discussion of some conceptual things, but never a conversation about the technology stack. And in the middle of the 4th week of the project, when we had already gained a ton of material, collected the main requirements, and reflected the basic requirements in the final decision, during the presentation of the architecture, the client begins to resent and say that we did not hear it. It turned out that our task was not so much to come up with something new as to guess what was already in our head’s main stakeholder’s head. Thanks to my big boss who was on that call and quickly figured out which way the wind was blowing. A couple of keywords and the client are satisfied again, and for the remaining days we completely change the concept, re-reflect all the requirements and risks, but in the architecture agreed with the client.

How to avoid it? To validate, validate and validate your decisions again with the client, the sooner and more often the better. It is better to repeat several times in parts what everyone already understood than to show the final architecture for the first time after 4 weeks. And this concerns not only the architecture, but also the approach to Discovery as a whole.

The client has a very accurate and detailed vision of the product, all he needs from you is execution


On the one hand it is convenient. No need to find out the requirements, mess with the documentation, go to the client, in the end. Take it and do it. But often this does not work. From the first days it becomes clear that the client’s vision is far from ideal, since far from all the risks and requirements are taken into account, the estimates are clearly underestimated, and it is extremely difficult to convey this idea, because the client is firmly confident in his decision.


How to behave in this situation? My opinion - you need to initially assess the profitability of the project in relation to the resources of the team that need to be spent on it. After all, such projects do not always bring a lot of profit, and it takes a lot of energy to spend on it. If we still decide to take on this commitment, I try to convey to the client the idea that we, as experienced consultants who have implemented many projects, are trying to use our experience to find the most rational solution to his problem, and not just blindly implement the proposed idea. I also understand that a mandatory part of our work is to warn him of all possible risks and, if necessary, give a recommendation on how to avoid them. That is, you need to earn credibility and to ensure that the client starts to listen to you.

You should always be able to listen and hear both the client and the colleagues in the project. After all, the challenges we face are often non-technical.

Summarizing, I can say that consulting is for those who are not sitting still and are not afraid to try something new. If you have been working on the same project for the first year, the work has bored you, but the fear of changing something does not rest - try to take on a little more responsibility. Pay for the educational course, think up and offer optimization to the client, convey to it its value, sell it. Grasp something new, step out of your comfort zone. Remember that bad experience does not happen and even failure brings a lesson in itself, which means it makes us better. If the experiment is successful, then the fear will disappear and you will be filled with pride and the desire to move on, to do even better and more. At this moment you can safely come to us!

Source: https://habr.com/ru/post/447426/

More articles:


All Articles