Wake up, and your application is on the main in the App Store

Around us there are enough developers who would like to do their project. Often, these ideas and gather dust in the minds of people for a variety of reasons. The stories of Vadim Smirnov from 2GIS ( zloypakimon ) are about how to implement them. Having spent several weekends in a year, he was able to do five different projects, did not earn millions, but was not disappointed and did not stop working on pet-projects.

The publication is based on Vadim's report on AppConf 2017 .

I work at 2GIS, but I’m not going to talk about the experience I got in the company, but about how we guys are sawing projects.
')


Probably, not everyone knows what pet-projects are. These are projects that are being sawn simply because a person can and wants, for example:

• poke into new technology;
  
• not just engage in engineering, but seriously affect the product or even make your own;
  
• become a millionaire.
  

In general, each has its own reason.



For the year and a half we did about ten projects, of which four applications. Now there is one thing in the App Store, and two of them hit the App featured home page.



One of them is “Shaker”. This application is for bearded alcoholics who sit at the bar and do not know which one to go to next, but the tricky application tells them.



The second application - "Tax". This is an application that helps to find the cheapest taxi vendor among ready-made taxi providers that takes you from point A to point B.
It's very cool to watch your application, for which you have spent just a few days off, under Yandex maps.

What I will tell

I will talk about what I am most often asked about in connection with what we do.

1. About time
   

The most common question I’m asking is: “Dudes, how much time is needed for this, and how do you do it in time?”.

1. About ideas
   

Where do the ideas come from, which ones are suitable for drowning them on weekends, and which ones are not.

1. About the team
   

Why do I say "we", where did the other guys come from? How we got together.

1. About the project
   

In my opinion, this is the most important part. Here I will talk about how to finish the project, how not to leave it halfway, and somehow drag it to the final.



As a result, if the inner uncle Sam asks you: “To cut or not to cut?” And you answer: “Yes”, then I will consider that I did not prepare this for nothing.

Part 1. About time

For me, it sounds like: “How much time do I need to spend on a project so that it will turn out?”, Or “How much time can I estimate a project?”.

When I hear about the assessment, I always remember this uncle. You all know exactly who it is. This is a bobuk .



Once in one of his interviews, I heard how they evaluate projects. I was very hooked on the story that it doesn’t matter how long a month, two, three, year is laid on the project - it always adds two weeks from itself at the end. This is the β constant of Bobuk.

If programmers, for example, were cool off somewhere and did nothing, in two weeks a team of intelligible developers can pick up absolutely any service or project.

For me it was strange: all projects are different, all have different functionality - how can anyone do it in 2 weeks?

I’ll tell you what we did, but before that we’ll see how we measure projects.



It is convenient for us to measure projects in up-to-date days. This is the day when I wake up in the morning, open my laptop, and on this day it does not close anymore. In my physical week, when I have to go to work, and then, on the way home, buy groceries and take a walk with my dog ​​in the evening, there is only one such bad day. I physically can’t find more time for the pet – project.



We have done more than ten such projects with the guys. They are all different in functionality: toys, geo-chat, a service that creates applications itself, without human intervention. But in some ways they are alike.

This is how the author's classification of projects was born. We realized for ourselves that they can be classified according to the degree of readiness.

We are all mobile developers. Everyone knows what it is?


This is a phone, but you still can’t code it.

The first stage of project readiness, which usually reaches us, is a prototype.
A prototype is a thing that performs a single function, while it can simulate it. In any unforeseen scenario, it falls and does not work at all in anyone’s hands except the developer.

An example is our geo-chat. This is an application that:

• Able to run;
  
• 1 person could write one message to one point, and the application pretends that it was read.
  
• Everything!
  

Any such prototype (I will now argue, you can argue with me) can be done in two hard uporotyh days.

This fact confirms a bunch of hackathons, where dudes are just enthusiastic, RedBulle and Doshirak are doing absolutely scary things in general, and they do something.

In principle, it seems that the prototype is all ready. But if you want to finish this prototype to the state when it can be shown to people, give the person and not be afraid that he will press the wrong button and everything will be closed, you need to understand that in fact it is only 20% of the work. These are empirical numbers, plus or minus.


To bring the prototype from the state when it performs one single function, to the state when it performs this function well and can be launched in the Store, you need to spend another 80% of the time.


But if you can still find two days in a row - just sit down at the weekend with the guys, lock yourself up on Saturday and Sunday and make a prototype, then it will never work for eight days in a row. So, this all transforms into eight weeks.

It turns out that in two days any prototypist can be washed down, but in order to bring it to a state where it can be shown to people and started in the Store, you need to spend another two months.
If you want to do something really cool from this, for example, add layers, statistics, emoticons, plus signs, minusics to the geo-chat, then it seems that, in principle, the first 90% of the work in the prototype has already been done. And in order to bring the prototype to this state, it is necessary to spend another second 90% of the work.



The saddest thing is that ideas usually come to mind just in the form of these Nokii. When I come up with some kind of another idea, I immediately see how cool it will work and with some trinkets. But in fact it turns out to be unrealizable in the framework of the project, which was being drunk with the guys on the weekend, including because it takes a lot of time. In any case, you have to downgrade the idea to the state of the prototype.

The prototype has a couple of properties:

• He can be dumb.
  

You came up with some idea, in my head she’s really cool. We sawed a toy - a geo-dependent game, we just urgently wanted to play it, as it sounded in our head. Did - sucks, just garbage.

I wanted to grieve at this moment, but in fact it's cool, because we spent only two days on the development.

• The second joke is that the prototype is sometimes the most appropriate form of the existence of the project. That is, there is nothing more to be done - the prototype works great like that.
  

For example, I can tell you about our project “Music Bot”. The idea is this. We are all mobile developers, we sit in a fairly large room, in one corner of which there are speakers. Everyone wants to listen to music, but to turn it on, you need to go to the speakers, take Jack, stick it into the laptop and start playback.



All cool and good, except for one person who does not like the song. He wants to change it. Then another person does not like the song, the fifth person does not like the volume, etc.
I wanted to think of something, so that each person could influence what is playing in the columns, and that it was cheap, because they would not give us money for it.

We all chat in Slack - this is now the norm. Since we are mobile developers, naturally, we have test devices that we connected to the speakers. Obviously, the next thing you can do is to write a bot who can be commanded from Slack. He enters into some music service and includes music. That is, the problem is solved.

It was all really done in two days. Naturally, we immediately thought: “Damn, this is what all the teams in the world need. We will now make a start-up, we will connect new providers, dragging the muzlo from there and from there, we will do authorization. ”

But you do not need to do this at all. The solution in the form of a prototype in this case is the most adequately set task.

If you go back to the MVP state, when we can show people our idea in the App Store, then it turns out that we spent first two days on the prototype, then we improved it in another eight days, it turned out to be ten - that equals two weeks of Bobuk himself. On this, our equation came together.



What is the result?

• Any prototype can be made in two days.
  
• To bring the prototype to the state when it can be shown to people, given to the masses, it is necessary to spend another two months within the framework of the pet-project, when we do this at the weekend.
  
• It is better not to take on something more until the prototype is ready, because there is almost a 100% chance that it will not reach the end.
  

Part 2. About ideas

Now let's talk about ideas that are implemented or not implemented in such projects.
This is the hardest part, because there will be a schedule. He is heavy. This is the dependence of motivation on time.

What do you think, how does motivation depend on time in such a project?

According to my feelings, on the one hand, the schedule is very sad, because, like something started, and everything has already ended. On the other hand, it seems that any prototype, in general, any of the craziest ideas can be done simply with bare enthusiasm, when we are gathered with the guys and everything is cool.



But if the idea is very, very like - it is generally fiery, it comes in to everyone, and you urgently want to implement it, then it’s not a fact that you have enough motivation to finish it to the state when the project can be shown to people.



So it was with our geo-chat. It is called "Nazabore". In my opinion, geo-chat is the most popular startup idea that never shoots at anyone. We were shocked at the very opportunity to write anything anywhere. You can write: “I am good, you are bad” - other people will read, you will be overdosed.

I'll tell you briefly how this thing worked (and works) with us.


There are points on the map - these are messages. They can be like-dyslaykat. Inside, they are somehow re-sorted. You can write a new message. It binds either to a point that has already been created, or a new one is created for it. If the point is new, then you can choose some kind of fixture.

Then we parted and added another layer, pulled up interesting places from 2GIS for Novosibirsk - just for fun.

It seemed to us that it would fantastically shoot and conquer the world right now - today or even yesterday. But no. First of all, because we simply lacked the motivation to complete it. It was very difficult and hard. A little later, tell you why, and what we did with it.

Our other application - for alcoholics - is also about motivation. This application (inside Big Data, tricky algorithms) prompts the user to the next bar that he likes.





Initially, I didn’t like the idea at all, because I’m a bad alcoholic and bar-hopping is not at all interesting for me.

The design of the application was made by the 2GIS team, it is cool, strange. Very simple mechanics: the user is in the bar, shakes the phone and the application tells him the next bar, where he really likes it, he will also build the route.

We took a bunch of 2GIS data, built ontological links, and each next bar is actually chosen from the preferences of users who sat in the previous bar. That is, he suggests real bars that people like. It turned out cool stuff. In the end, if you fell and did not reach, you can also call Uber from the application.

We made a prototypist, he worked barely. Send him to the bars, drank the first investment, even me. Understood that the idea is cool. We looked at what competitors are - they are completely absent. We looked at whether it could somehow be implemented, modified.

In general, the ready-made prototype showed, firstly, the coolness of the idea, and secondly, it somehow began to be pumped over, to conduct a competitive analysis. This motivation was enough to make the finished product, which is now in the Store.



In principle, even now, if there are any tasks on this project, it’s not dumb for anyone to do anything - as always, when the idea is super-fire.

So it was with Taksa - the idea belongs to the 2GIS product team. They just came and offered us something to do for your favorite company. Since they are the product team and they are paid to generate cool ideas, they generated one. The idea was originally cool. In Moscow, the application also works.

This is a super simple, stupid application - I don’t know why nobody has done it before us: we choose the starting and ending point. The application shows all the taxi providers and prices for each of them - such a taxi aggregator.

We did it, we liked it. Plus, the guys themselves, on their own, conducted a competitive analysis, graphics, and more.

In general, a specific idea constantly gave us a reason to continue to pursue this application, and our motivation grew.



When the application got into featured, our motivation jumped in such a way that we immediately immediately wanted to do something, choose Gelendvagen bundles, for example.



What can you get out of all this bravado?

• Motivation is always enough for any prototype, no matter how crazy it may be. If he likes a little bit, the fact that you can file down the prototype.
  
• It’s not a fact that if the idea is just fiery, but you didn’t subject it to any doubt or competitive analysis, you’re motivated enough to release a ready-made application, even at the prototype level, but so that people can use it.
  
• If you work on the idea, somehow knead it, try to do a competitive analysis, then there is enough motivation to continue doing it to the point where the project can be shown to people.
  
• If the idea is fiery, initially, and to do it, then it can be sawed to infinity.
  

Part 3. About the team

It is no secret that the time of such applications as the archaic Tetris has already passed.


Most likely, now you need to do modern projects that look different.



One can glue down such a thing, but it will take a lot of time. Most likely, when she’s cut it down, it will no longer be needed, or you will die trying to finish it.
The way out is obvious - you need to find yourself a boy band.



But better, for example, such.



Because you have to really fight - with your own laziness, with prejudices, with the opinions of colleagues and relatives, who will say: “Dude, why are you doing this at all? You get a normal salary at work, and you do it just for free! Come on, go to the beach! ”- and so on.

But how to find these guys?

The solution is also simple. We can trace the pattern of how people join our small team. Just on the example of “Dachshund” - he, as it seems to me, is more speaking.



The guys came to us and said: “Dudes, we have an idea - you are doing something - make an application! You are iOS developers! ” We just had two iOS developers, and we joined each other.

And there must be a backend, and the iOS application is just a front end! We realized and made the whole backend just in the front end. Our application went to some APIs, did something there, pulled it out, counted it itself, did absolutely everything, including the search for a passage - all sorts of pieces. But you can’t do without a backend anyway, because it’s necessary that the data get into the application. Ok, we put JSON in Dropbox, but in fact we got the finished application.
In fact, the user doesn’t care what technologies are used there. He enters a point, and the application should show how to get him for 100 rubles. And that's all.

We went and showed everyone - check it out, guys, what are we doing, cool? Our backendant, who was also looking at it all, just came up and said: "Dude, let me do it to you normally." So he joined the team. Now guys come to us in the same way.

I also want to say about Hackathon. I love them very much, but not for the fact that there is a potentially cool guy to be found there. It seems, in fact, it is not very real. Rather, because there you can check in an extreme situation, first of all, yourself, well, and the guys with whom you saw projects. Hackathon is such an extreme thing, where all the good things come out of people, and you can appreciate what the man is capable of.



If you see in the morning that the team looks like this and the project is ready, then most likely everything will work out.

• Even if there is no competence in the backend, in the front end, in something else, we just do the maximum where we know how to do it, and the minimum - where we don’t know.
  

In principle, even when I was doing “Music Bot”, I had no idea how to write under the backend, but I figured out CoffeeScript in two hours and somehow did everything.

• Second, we make a prototypist and walk, show it.
  

Everyone thinks that you are a braggart (or well done), but in reality you are looking for yourself dudes. Someone will see him and offer his help simply because he liked the idea: "It seems that something is ready, let's help."

• Hackathon is a really cool test, where in combat conditions you can check whether you are working with the guys or not.
  

Part 4. About projects

The most important part is how it turns out (or fails) to bring the projects to the end.
This black box is also my project. I sawed him a long time ago. This is a thing for musicians that turns the pitshifter into an arpeggiator, whatever that means.



There was really a lot of work there: you had to invent it, solder it, dilute the board, understand what kind of microcontroller you need, program it, make some device, write a website, a MacOS application that somehow fills in the presets, and even sell all this tops.

That is, the work is different, there is a lot of it, but I just devoted time to it every day, and it ended. That is, I invested the time that was needed to make it all, and the project ended.
In order to gash a project with one helmet, you just need to do it every day - and either you really die because there is not enough time, or the project is over.

This is cool because you can do anything.

The team is a little different.

For example, this is the architecture of the service that we are doing now.



You can try to calculate how many roles there are:

• Backend;
  
• Web;
  
• iOS;
  
• Android;
  
• Build node
  

That is, you need at least four to five people to gash such a thing.

If at least one says: "Dude, I, probably, everything", then the whole project may be in question. My soul hurts most of all, as if some of the dudes had fallen down.

Small note about responsibility
When you saw a project alone, you yourself are responsible for the time you devote to it. This is absolutely obvious.
But what happens if there are several people in the project who dedicate time to him?



It seems that the responsibility is divided into all. But in fact, no, because you invited dudes, and the responsibility on you is maximum. Not only for their time, but also for the time they have dedicated.



That is, I now feel much more responsibility for myself than the guys who help me to do these projects, although everyone has equal shares.

Let's go back to the motivation chart.



What can be done if, for example, the project of sensations lies somewhere far to the right? You can try to either work on the motivation so that it goes off into the distance and into infinity, or pull on yourself. That is, make the project run faster than necessary.

That is, in fact, you need to learn how to manage time (project execution speed) and motivation.

Then there will be super-obvious things, I will quickly tell about them. We have not done this before, and nothing has worked out. Now they began to do, and everything works out.

If these colorful men -



will want to do this project -



The first and most obvious thing to do is to cut a project, so that each has its own small tasks.



Then you need to set the priority of each task so that they have the numbers:



After build these numbers in order of execution. Then each person will have a queue of tasks that he will do.



In fact, it is necessary for each team member to know what he should do at each moment in time, and for him to understand that it is necessary for the project to end.

To do this, we use Google docks. Since we are sawing pet projects, this is not a working atmosphere, and it is not clear when the dude will be engaged in coding.

For example, a person had a free hour, but you need to understand that he must very quickly get into context. To do this, we have Google docks, where all tasks are prioritized. The person simply opens the Google dock, follows the link, the TK opens, and each team member always understands what he needs to do.

In development, this is actually super-obvious things. Without them, nothing worked, they must be done.

It is also very important that the red man does only the red puzzles. We have a backendor should not think about design, front-end - about backend tasks. If there are any questions that are not related to the direct professional examination of people in the team, I take them away.
I try to do this so that the dudes do only their core tasks, I take away non-core tasks for myself and try to do something because I’ll do it better than they will waste their time. In this way, project time can be reduced.

These things are simple, but nothing works without them.

Since I have the most responsibility, I:

• I always initiate decomposition, evaluation and prioritization, so that every person at any time understands what he needs to do;
  
• I write TK. Since time is fragmented by weeks, a lot of time for the guys is spent on entering the context. Trying to remember - what did you do there? And so - everything is written in TZ beautifully;
  
• taking away all non-core tasks.
  

This is probably the minimum stack of tasks that I can do to reduce the time for the project.



Probably the most important question - the question of motivation - how do you get the dudes to code? They are doing it at work from morning till night, and here you say: "Let's do it, you will do the same thing as at work, but you won't be paid?" This is strange.

What can be done with this?

• The first recipe is to offer a stake in the company.
  

But this is a complete garbage, it does not work, because there is no company, the idea is zero, the company is zero, everything is zero. You offer a percentage of zero, dude looks at you: "Cool, yes ... come on, come tomorrow."

What works? And we return to the geo-chat, which was built for us for a long time (I judge only by myself, but it seems that in our team this thing works).
When you participate in a project, but you don’t want to do anything at all in it simply because you don’t feel like it, the only thing that can move me to work without even paying attention to money, probably, if something is in the project going on. That is, there are always some kind of pushes, the guys are going, they are making some cool inclinations. The project really does not stand still, and I really want to join him in this case.

When we were doing geo-chat, the most important thing I’d probably done in this project was to just constantly wiggle the dudes: “Hey guys, let's get together, do something, do it, do this and that,” and wrote the code which can do.

It seems that it worked, and we finished the whole story.

• In fact, you just need not sit on the ground, generate movement in the project.
  

Plus, there are still such funny things. Since there are no commodity-money relations, there are no direct levers of pressure - there is nothing at all but human relations with the guys, very funny stories arise. They, it would seem, do not belong to the project at all, but influence its implementation.

• Human factor.
  

Examples

One of our engineering guys lives in a country house - big, beautiful, cool. He is going to work on the weekend all week long with a project - he is just waiting for Saturday, when he can open a laptop and code. But it is snowing on Friday, and everyone understands what the dude does on Saturday - he opens his eyes and sees a falling white wall, grabs a shovel, waves it for 6 hours on the street, returns home and does not engage in the project. He is engaged in drinking tea, watching TV shows and doesn’t want to do anything at all on this day.

What are we doing in this situation? If it's snowing on Friday, then we are going to Glory in the morning on Saturday. We come, we take shovels, we cheerfully help the guy to scatter snow.Everyone gets a charge of cheerfulness, it turns out spontaneous teambuilding. Then everyone sits down and saws the project.

This story, it would seem, generally does not directly affect the working relationship, but it works. We need to understand approximately what kind of plan the problems might be for the guys in the team and how they can be helped in this.

The second story. An abstract team of guys-developers went to the abstract Hakaton from abstract Novosibirsk to abstract Moscow. One of the developers began to firmly steal the second developer - there were very funny jokes, just awesome. But now we don’t have a great front-endder.

What can be learned from this? What you need to try to follow the atmosphere of mutual understanding within the team. For such a stupid reason that one was laughing at another, a man left the project. I will try in my life to never allow this to happen.

What I'm trying to do now is just to discharge all the negatives to me so that these jokes are directed in my direction. From me it will not lose, but the guys are nice.

findings

What can be pulled out of this?

• Most importantly, I consider the initiative and the generation of movement in the project.
  
• The second is the collection of core tasks.
  

It is important to do so that the children do not need to do anything except their work. There is a small piece of work in which they are professionals and from which they derive pleasure. Everyone makes their own piece and understands that the project is over, they participate in it and get satisfaction.

• Friendly relationships are very important.
  

At the same time, I am sure that they should be honest, because dishonesty is immediately redeemed, people are not fools. I sincerely love the dudes with whom I develop, I want them to have everything fucking awake, and I try to help them in any of their endeavors.



Finally, “ Just one more thing ... ”, as Colombo said.



Perhaps you have a question - where do I get the strength from myself in order to walk, look, look after dudes. I have not thought about it before. In fact, it seems you can answer like that.

When a project comes up in my head, I already see how it will be, how it will be cool to use it, how it will be superbly. At the start, it gives an awesome impulse to the initiative to try to do it.

Then I, too, like all people burn out, but I feel wildly sorry for the time that I have already spent on it, and I already want to finish it. On this fuel, I try to bring it to the final.
I wish you all cool teams and fun.

---

For those who did not have enough details, we offer the replies of the speaker to questions from the audience.

We also opened free access to videos of all reports from Apps Conf 2017 . We hope that you will find there a lot of useful and interesting information.

And those who are willing to share experiences or interesting cases in the field of mobile development, we invite you to become speakers at our May RIT ++ conference festival. Applications for the program committee can be left here .