Hi, Habr! My name is Maxim Pavlov, I am a student of Technopark. In this article I want to convey the ideas that I learned from the development of educational projects by a team of novice programmers. After each project, I try to assess what I have learned from it. Many articles about project management in large and small companies have been written. Reading them on Habré, I always try on the ideas expressed there, on our team. But still, the training team has a very important specificity.

1. Motivation. The whole team is based only on motivation and full confidence. In companies, people keep for many reasons: money, the authority of the manager, the interest of the project, the significance of the work being done. None of these reasons, except for the interestingness of the project, will not keep a person in the training team.
2. Study The main pain of all training teams is studying at the university. For some, it is more difficult, for someone easier. Someone more interesting, someone more boring. But, unfortunately, as part of working on a project in the Technopark, one often hears the key phrases “curc burns”, “RK tomorrow”, “I have a lab”.

These items contribute their specificity to the management of the training project. I have not seen a single article about working in student groups, so I want to share my experience.

Ideas

There are guys who all think about what to write. After the story of Picaba (link to our first post about the application to Picaba below), I realized how important it is to be a permanent member of a large community. For example, on the same Picaba, different life hacks appear every day. In the same place we got the idea of ​​our application. The second plus is that the community will be ready for your service. And people will know why he is, if you are writing an application on the topic of a post that has gathered enough “pluses” from the community.

Where to begin?

Following the results of three semesters, I can say that the most successful scheme for learning a new technology / language was a two-stage scheme. First, a large and complex project is written (unfortunately, it is not completed from the first approach or it does not end at all), the second step is a small and simple project. In two of my two cases, he was successful. Our first “big” project with our server part and Monga was written throughout the semester. And I'm sure we will finish it.
')

Team did

If you are lucky the same way as me, and on average each team member writes about the same code, then never resort to motivation or excuses from the category of "well, I wrote more tests than you." Of course, this does not apply to cases in which you write a project within a month, while the others “are about to catch up.” Several cases have helped me realize that all the work within the team was done by a team, and not by an individual. On the one hand, it does not allow selfishness to develop, but on the other, you know that even if you suddenly fall ill or you have to leave immediately, the team continues to write. Try to watch this video. We liked. :)

3 persons

I know and respect people who work well together, but, in my understanding, these are brilliant super-people. My article is for ordinary people like me.

I was convinced that 3 people were an ideal. I found my two people according to my favorite principle: by results. With them for the first time I came close to understanding the concept of "Dream Team". They had an almost finished game, both made quite good toys (by the standards of our semester) on the Front-End course, both got excellent marks on the database. At that time, I could attribute to my merits only a Java game completed in a two-week ruble game in the trawl and a joystick for a small plane on the frontend. Why 3? Everyone (seriously, everyone) had a moment when he, due to circumstances depending or not dependent on him, disconnected from the development. But the team continued to work.

How comfortable?

In any product there are tasks that need to be solved very much, but which are not at all related to development. A lot of time was saved by our designer Pasha and the generator of ideas Igor. Who knows how much we would spend on disputes where it is better to place elements, what would be so interesting to add to the application, search for arguments, resentment, if there were not these two people. Therefore, I decided for myself that all decisions related to usability and design should be made by one person, and new non-standard features should be thought up by another. And both should not be involved in writing code. In addition, the idea of ​​another of our applications, which is still awaiting its finest hour, belongs entirely to Igor. If everything, as we believe in the design abilities of a human designer and the ideas of a human generator, there will be no conflicts and offenses due to rejected ideas and decisions made not in your favor. If you do not have a familiar designer, remember which of your friends finished the artwork, look at his works and assign him as the chief designer. Let him decide what and where to place, how and what should function. This step will allow you to spend time only on development. If in the end the project will take off, and the design will not suit you - throw off and order the design from another designer. :)

Motivation

Sometimes motivation is really not enough. I have a couple of ways of motivation, proven in battle.

1. Friends. Tell about it in colors to the maximum number of friends. When all your friends know that you are writing an application, they will not allow you to merge, because they will be skeptical to ask: “well, how is the application? Already laid out? ”When a lot of people know, there is no longer a chance to merge.
2. Competitors. After reading one great book, I realized that competitors are needed, because they give you the motivation to make your product even better. In our case, on the fourth day of development, an odd job appeared without normal design and functionality. We were sure that we had a normal design and a couple of killer features that weren't in that application. For example, viewing the profile Vkontakte right inside the application and adding to bookmarks (Wishlist). Well, and most importantly, we needed at least one complete project in the portfolio. So the competitor only strengthened us and made us write faster. The main principle I adopted is that you don’t have to despair if you have competitors. If your product is cooler, then you will definitely crowd out a product that came earlier, but, in fact, worse.

Todo-list

This item refers rather to what we did not have, but really lacked. Now I understand how important it is to determine the list of features before the first calculation and the first announcement. Without such a list, both of these items can be postponed indefinitely. It so happened that the first laid out version of the application was buggy. Recommendation - tell your friends whom you have previously told about the project, about what you have done. The more people know about it, the better. The stream of bug reports and wishes will provide additional motivation and help determine the list of features that should be fixed to the announcement. And by myself I will say, a clumsy application on Google Play is in itself a good motivator.

What's next?

You wrote the application, laid out, it somehow works, sometimes falls. What to do next? Develop new features or hone to perfection already ready? Our unequivocal answer to this ambiguous question - what you like, do it! "There is no hard labor" and not a huge company. Doing what you like, you do it much better than something you don’t like. And about the poorly working current functionality: at one point the critical mass of the code that needs to be refactored is typed. And there is a man whom it got the most. And again he will be motivated to do his job well, because you cannot live like this anymore.

Timing

Once at the department IU6, a manager from a company, who could not be called, spoke on the course on production management. He talked about his method for estimating the project timeline based on the ideas of the developers. “Usually the developer is wrong on the unit of measurement. That is, if he says he will do it in 3 days, it means ± 1 day. ” So it happened. At the beginning of the project, I expected that the three of us would do it no more than in a week. We did this exactly 2 weeks. Day to day. So from now on, we will evaluate our work. I would be glad if you share your experience with timing estimates.

PS See what we have already done, you can follow this link . The first announcement on picaboo on this link . We will be very happy to download, good estimates, suggestions and comments.