The history of one feature or why hakaton programmer

Hello everyone, I am a programmer and a timlid in a company developing corporate software. Recently, the theme of hackathons has intensified in Habré. Appear posts, for example, from the company Rambler - Hakaton as a source of improvement in the life of the company . I'll insert my five kopecks.

Often, communicating with a wide range of developers, I noticed that among programmers there is a widespread opinion that hackathons and other similar events are useless. Many believe that this is a waste of time and therefore should not even try.

I'll tell you my story and maybe it will convince you otherwise.
')
In June of this year, a new version of the product we are developing has been published. One of the most notable chips was the desktop with graphic widgets. Widgets showed statistics about work in the system and looked clear and modern. Fidbek from users was positive: they learned about themselves and their subordinates what they had not noticed before.

But this feature could not be. To see the whole story from idea to release, you need to go back in time.

As we did not want to participate in the hackathon

About a year ago, on the internal blog, the news came out that in two weeks the first hackathon in the history of the company will take place. You can choose any topic, find like-minded people and realize it from Friday evening to Sunday.

At first I was not very impressed with this idea. Of course, I read a lot about the fact that hackathons are interesting, fun and useful, but the prospect of spending two days off at the office was not pleasing.

There was enough work then, we started the first sprint of the next release. It was obvious that coding two days off after an intense work week, and then still smoothly starting the next one, would be difficult physically and morally. It was also not clear what can be taken as a topic. I wanted to choose something that would be interesting to realize and at the same time, so that the result did not go into the void.

The first problem was solved by itself - apparently the other participants were also embarrassed by the proposed format, and made changes to the hackathon plan. For example, on Monday they were allowed to come in the afternoon. As practice has shown, all participants exercised the right to rest.

The second problem was more difficult. I am interested in the topic of working with data: this task remains relevant, it is possible to implement cool features in it, although they still had to be invented.

I will make a small remark: shortly before that I discovered one popular series of football simulators and they always paid special attention to analytics. Studying the statistics, you can decide which player to buy, what tactics to choose for the match. In this case, you can always dig deeper and fall from general statistics to the details of specific matches.

The goal is simple: to give food for analysis, to understand where the problems lie and what are the points of improvement.


And what if you lay the analogy with a football simulator on the real world? In the ECM systems, people work, we can collect statistics on them. Now they are more like a black box: everyone remembers, but is extremely reluctant to give out something for analysis. And in visual terms, you can peep some of the developments in the same simulator.

At first glance, there are not so many data: we know what tasks were assigned to a person and whether he knew how to complete them in time. But what if you try to collect metrics "upper" level and give the opportunity to get to the source data. It should be interesting both in terms of results and in terms of development. Why not?

Well, there is an idea, great! It remains to find a team.

This, oddly enough, was the easiest part. I was lucky that Sasha ( @MonkAlex ), an easy-to-climb programmer, and an analyst Vladimir, an experienced but still ready for any action, are working with me. We discuss the details, decide where to start and in what format we work. We invent a name - "Monitoring and Analysis".


Go…

How we did not win the hackathon

Hackathon began on Friday evening with a general meeting of the participants, the teams briefly told what they would do and ran around the cabinets.

They decided to work flexibly, the main and only criterion was to do something working by the end of the hackathon. First of all we drew a map of features. Then we noted the priority [0], without which there is no point in going to the demonstration at all - in our case it was the start page with a set of widgets. Then they figured out what we would do if time was left (in the end, half of this was done, and half were presented as potential paths of development). And they began to "cut."



They spent about an hour searching for ready-made components, and deployed a test infrastructure in parallel.

Started with the "donut" performing discipline . They made it in pairs with Sasha - it was easier to delve into the new topic. At the same time they threw a "skeleton" for the rest of the widgets. A form with a single widget that works on more or less real data was ready in three hours.

Then they went their separate ways and threw the rest of the widgets on the start page, screwed up the schedule and generally improved the interface. The minimum task was completed, it could already be shown. That was the end of the first day.

On Sunday, at 16:00, the presentation had already begun, and therefore in the morning they clearly decided that we would finish the presentation. We stopped at the fact that it is important to have time to make an interactive transition from the home page widgets to their details. An hour before the deadline, they decided to “freeze” the code and drove the main scenarios a couple of times, noting that it was better not to press everything to work.

The presentation was made by Vladimir - he is an analyst, he has more experience in conducting seminars and seminars. In addition, he had time to prepare for it. Almost all the time was occupied by live demonstrations and answers to questions. Despite the very short development time and lack of testing, nothing fell and it turned out to show everything that was done.



In addition to us, out of 7 participating teams, only two managed to bring the idea to a working prototype. As a result, all three teams became winners, and we got an honorable second place.

We gave in to the guys who made an incoming message analyzer with the transformation into elements of the ToDo list. Objectively, they had a more serious technological stack, a larger team (7 people) and the idea was perhaps more interesting.

How a feature grows from an idea

Through a vote within the company, a prize of professional sympathies was won, which was given to the guys who took the 3rd place. Everyone was once again praised for participating, and that was the end of the hackathon. We returned to designing the features of the release and did not recall the hackathon for a couple of months.

But at the end of September, the movement began again in this topic. It became clear that we are ahead of the release schedule and it seems like we have a few weeks of reserve left. At the same time, before the development is completed, it will be risky to do something absolutely big, but to really bring the prototype from the hackathon to mind.

A little later, in the first decade of October, an internal conference was held to generate ideas for the development of the company's products, which included competitors, and it was noticeable that they had similar solutions. This convinced us and the management of the potential attractiveness of the feature and gave us confidence in the correctness of the chosen path.

And as a result, at the end of October, we completed work on the main features of the release and got time to bring the solution to mind, with the proviso that if we do not have time to finish the release, it simply will not come out.

We started with the design:

• They threw out the “Analysis of approval” feature, since they wouldn’t have had time to finish it in time.
• Removed too much from the main page.
• Worked out the pages with details.
• We decided that the 5 busiest employees were few and doubled their number.

And we finally managed. In fact, I can say that the final implementation cost about 10 times more than the prototype.

It looked like the main page:


And so the detail on the people and the timeline:


The feature entered the product and started using it. Not very active, but we initially understood that in this form this thing is not massive and its target audience is a few people in the company.

But the main thing - from it was already a business effect. Even on such a small sample there were problems: those who did not complete the tasks; there were processes hanging for a very long time and the busiest employees.

It would seem a simple thing, but nevertheless with it you can track a lot of trends. In order to convey this to users and for the purpose of public relations of a new topic, and to clarify what it is and why they wrote the article Development of interactive EDS tools for analyzing the performance of employees .

Fidbek as a whole was positive, but the feature did not become massive and there was a feeling of incompleteness.

How the feature lives and develops

At this very time, a new version was being planned. And one of its main themes was the desktop of the system user as an entry point.

Our team has been designing and developing. The goal was to combine desktop and widgets for operational work and widgets with system statistics. And everyone is interested in their own statistics. For example, the head of a company needs to see the full picture, and the head of a department is important only for his subordinates.

In addition, "Monitoring and Analysis" opened in a separate window and it was not easy to find it. Therefore, it was divided into separate widgets. They were brought to the desktop with customized views of the roles, which in turn were calculated from the position of the employee and the access rights granted to him. As a result, all the data needed by a particular person were in the most prominent place of the system and were shown after the client was started.


For most, this is more than enough. “Monitoring and analysis” came in handy for detailing; we made it open by clicking on widgets. In addition, having received feedback, we finalized it: we added printing, quick search, and an operating mode for the top manager “from divisions”. As a result, in the final version, the start page looks like this:


In this form, it came out in the new version. Today, judging by the statistics, we can say that the feature has found its users. Monitoring the use of the example of a combat stand with 200 users shows that every day more than 20 users launch “Monitoring and Analysis” and more than 100 times a day desktop widgets are used to navigate to detailed data.

Among other things, it was useful to us, as a vendor. When introducing ECM systems, sabotage is often found among those who oppose the new. Now it is very easy to find them by a low percentage of tasks completed on time.

Why you should participate in the hackathon

In conclusion, I want to share the conclusions that I made for myself this year:

1. You should definitely participate in the hackathon
You can realize your idea. You can have a good time with interesting people. You will have a chance to show yourself and see others. Of course, purely mathematically, your chances of winning are small, but a hackathon is just the case when participation is more important than victory.

2. Do not be shy about your ideas.
Most successful products and companies are not unique in nature and often were not pioneers. Successful them made the right approach to business and the desire to do something truly useful for their customers. The idea may not be new, but if you are interested in it, then you should try to interest others. In addition, hackathon is a great format for receiving feedback, after which you will understand whether it is worth developing this idea or not.

3. Hackathon is a great way to get the message across to management.
As a rule, decisions about how to develop the product takes leadership. But customers and product owners also need help choosing features. Within the limits of limited resources, you always want to choose features that are as useful as possible both for users and for a company-developer. It is not easy to convince someone that you are right in words, but when you show a really working prototype, your chances greatly increase.

4. Solutions from the hackathon can be successfully integrated into real products
Yes, it will take time, which is not commensurate with how much you have done on the hackathon, and as a result only a general direction will remain from your prototype, but it is possible nevertheless.

5. Be prepared to develop your idea.
If you have an idea for a hackathon, better consider its potential development. Perhaps after a while it turns out that the initial idea is not enough and I want more. Or you will understand that in this form nobody needs it. Do not be lazy to put yourself in the user's place and understand what will be most convenient and useful and what you should strive for ideally.

Instead of conclusion

Just a month ago, we again took part in the hackathon, this time we managed to assemble a bigger team and make a working prototype of the data aggregation service from various open sources and integrate it for existing tasks.



The feature caused a positive feedback from the management and maybe it will also someday be fully implemented in the product.

For myself, I firmly decided that if they offered to take part in the hackathon again, I would definitely agree. What do you think about this?