A! Hack Summer - Alfa-Bank hackathon August 5 and 6, 2017
Hello, Habr! On August 5th and 6th we will be holding an external summer hackathon “A! Hack Summer” .
If you are interested in such things as Artificial Intelligence, Machine Learning, AR / VR, Data Science, you know how to work with them and thought to do something your own or know how to make a product for the bank’s customers on this basis, go to Deworkacy ( Moscow, Bersenevskaya emb. 6 p. 3 ) August 5 and 6.
And about why we all do this, will tell Vladimir Urbansky, head of Alpha Laboratory.
The first hackathon we did in November 2013, then the word "Hackathon" itself was not yet in use, and it seemed ridiculous to many. In the banking environment, there was practically no hackathon culture that we can observe now.
We have this story was an element of creating a model of the laboratory. Usually, banks and large organizations had business and product experts who write requirements, give them to analysts, they write functional requirements and give them to developers, developers essentially already implement the product according to documents, not fully understanding the specific tasks.
In the lab we wanted to change this. We made cross-functional teams, where the product works together with the team - with developers and analysts, developers understand the goals and objectives facing the business. And if they themselves understand these tasks, they can bring the business much more benefit.
Indeed, in the modern world, developers are essentially a kind of production unit. As a leader, I can’t do many things with my hands, I can’t create a product - I can organize someone, but I can’t code it myself, although I used to program a bit. And the developer can create a product that will even be monetized. And the likelihood that he will create a good product, if he understands the goals and objectives of the organization, will be much higher if you give him freedom of action.
Most of the time, developers are busy defining a product owner for them in the backlog. But at the same time, they have their own ideas, and if you give them even a short period of time to go and cut down what they really want, it can give a very interesting result.
For us, it was such a cultural story from the point of view of giving people a certain sense of freedom, energetically recharging a breath of air, the ability to gash something interesting. What they wanted to do, and not just what the product owners decided to do.
Therefore, we began to make hackathons. There was originally no goal to make products that earn millions of dollars, this is a story about people and culture, so that some ideas do not just remain at the level of ideas, but find implementation. For example, I do not really believe in idea banks, in standard idea management in organizations. Such approaches work in some cases when a person sees some kind of problem, but it is completely outside the zone of its influence. Then he can pass it on to someone, and the person in charge of this area may implement it. But this does not always work.
It is much more effective, in my opinion, when a person is not just gushing with ideas, but when he is ready to fit in with this idea and do something. At least with minimal implementation. People are ready to fight for their ideas, but not for strangers.
We did a post-analysis of the first hackathons, it turned out that a lot of things were realized in one form or another, just not always in the form of the original idea that was. Some of these products were then closed. One of the first products was an activity account, when we connected banking with fitness bracelets. It was cool and resonant, got its audience, but it was quite niche. We did not want to develop this further, did not see global prospects, so we decided not to blur the focus.
We made internal hackathons, that’s the difference. From the internal hackathons, we expected, on the one hand, a slightly greater result from the point of view of the product, because the participating teams are more mature and understand what we are working with, on the other hand, a large hackathon result is such an energy reload that gives strength to the teams.
In this regard, for internal hackathons, we did not have hard metrics by which we would evaluate success. Of course, we were always happy if some kind of completion of the hackathon came to a fight, and we tried very hard to make up the solutions we came up with.
Some of the solutions were very premature, for example, we had a solution at a hackathon, where a refrigerator ordered products in an online store, communicating with a client in a chat room using a bot. On an industrial scale, this is not yet ready to be done, but the solution itself was very interesting.
In order for the team to work out at the hackathon, it must catch fire with an idea, and already at this stage a minimal evaluation of this idea takes place. If the idea is bad - a person simply cannot draw people into a team, people will say, "I do not believe and I will not go to do it."
The hackathon , which will be held on August 5 and 6, is external.
The goal of the hackathon is to find ideas and people who can realize them.
We are interested in ideas and offers of services that will improve the lives of our customers. If we find any ideas interesting for our customers, that’s good. But if you have an idea + a team ready to do this with the bank - it is much more interesting.
But we are also interested in people, maybe the idea itself will not catch us, but we will want to work with these people. Venture capital firms often invest in teams rather than ideas. Therefore, we are also looking for people.
The first hackathon we did in November 2013, then the word "Hackathon" itself was not yet in use, and it seemed ridiculous to many. In the banking environment, there was practically no hackathon culture that we can observe now. We have this story was an element of creating a model of the laboratory. Usually, banks and large organizations had business and product experts who write requirements, give them to analysts, they write functional requirements and give them to developers, developers essentially already implement the product according to documents, not fully understanding the specific tasks.
In the lab we wanted to change this. We made cross-functional teams, where the product works together with the team - with developers and analysts, developers understand the goals and objectives facing the business. And if they themselves understand these tasks, they can bring the business much more benefit.
Indeed, in the modern world, developers are essentially a kind of production unit. As a leader, I can’t do many things with my hands, I can’t create a product - I can organize someone, but I can’t code it myself, although I used to program a bit. And the developer can create a product that will even be monetized. And the likelihood that he will create a good product, if he understands the goals and objectives of the organization, will be much higher if you give him freedom of action.
Most of the time, developers are busy defining a product owner for them in the backlog. But at the same time, they have their own ideas, and if you give them even a short period of time to go and cut down what they really want, it can give a very interesting result.
For us, it was such a cultural story from the point of view of giving people a certain sense of freedom, energetically recharging a breath of air, the ability to gash something interesting. What they wanted to do, and not just what the product owners decided to do.
Therefore, we began to make hackathons. There was originally no goal to make products that earn millions of dollars, this is a story about people and culture, so that some ideas do not just remain at the level of ideas, but find implementation. For example, I do not really believe in idea banks, in standard idea management in organizations. Such approaches work in some cases when a person sees some kind of problem, but it is completely outside the zone of its influence. Then he can pass it on to someone, and the person in charge of this area may implement it. But this does not always work.
It is much more effective, in my opinion, when a person is not just gushing with ideas, but when he is ready to fit in with this idea and do something. At least with minimal implementation. People are ready to fight for their ideas, but not for strangers.
We did a post-analysis of the first hackathons, it turned out that a lot of things were realized in one form or another, just not always in the form of the original idea that was. Some of these products were then closed. One of the first products was an activity account, when we connected banking with fitness bracelets. It was cool and resonant, got its audience, but it was quite niche. We did not want to develop this further, did not see global prospects, so we decided not to blur the focus.
Hackathon Success Criteria
We made internal hackathons, that’s the difference. From the internal hackathons, we expected, on the one hand, a slightly greater result from the point of view of the product, because the participating teams are more mature and understand what we are working with, on the other hand, a large hackathon result is such an energy reload that gives strength to the teams.
In this regard, for internal hackathons, we did not have hard metrics by which we would evaluate success. Of course, we were always happy if some kind of completion of the hackathon came to a fight, and we tried very hard to make up the solutions we came up with.
Some of the solutions were very premature, for example, we had a solution at a hackathon, where a refrigerator ordered products in an online store, communicating with a client in a chat room using a bot. On an industrial scale, this is not yet ready to be done, but the solution itself was very interesting.
Evaluation of ideas
In order for the team to work out at the hackathon, it must catch fire with an idea, and already at this stage a minimal evaluation of this idea takes place. If the idea is bad - a person simply cannot draw people into a team, people will say, "I do not believe and I will not go to do it."
The hackathon , which will be held on August 5 and 6, is external.
The goal of the hackathon is to find ideas and people who can realize them.
We are interested in ideas and offers of services that will improve the lives of our customers. If we find any ideas interesting for our customers, that’s good. But if you have an idea + a team ready to do this with the bank - it is much more interesting.
But we are also interested in people, maybe the idea itself will not catch us, but we will want to work with these people. Venture capital firms often invest in teams rather than ideas. Therefore, we are also looking for people.
