How we managed the training project

    Hello, Habr! My name is Maxim Pavlov, I am a student at Technopark. In this article I want to convey ideas that I have learned from the development of educational projects by a team of novice programmers. After each project, I try to evaluate what’s new I learned from it. Many articles have been written about project management in large and small companies. 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 built only on motivation and full confidence. In companies, people hold on for many reasons: money, the authority of the leader, the interestingness 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’s more complicated, for someone it’s easier. Someone more interesting, someone more boring. But, unfortunately, in the framework of work on a project in the Technopark, one often hears the key phrases “kursach is on fire”, “RK tomorrow”, “I have a lab”.

    These items contribute 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.


    There are guys who all think about what to write. After the Picabu story (link to our first post on the Picabu app below), I realized how important it is to be a permanent member of a large community. For example, on the same Picabu different lifehacks appear every day. There 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 gained enough “pluses” from the community.

    Where to begin?

    Based on 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 call or does not finish at all), the second step is a small and simple project. In two cases out of two, it turned out to be successful for me. Our first “big” project with its server part and monga we wrote throughout the semester. And I'm sure we will finish it.

    Team made

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

    3 persons

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

    In my own skin I was convinced that 3 people are an ideal. I found my two people according to my favorite principle: according to the results. For the first time with them I came to understand the concept of “Dream Team”. They had an almost finished game, both made good toys (by the standards of our semester) in the Front-End course, both received excellent marks on the database. At that time, I could only attribute my merit to a game completed at the forefront in two weeks at the Java rate and a joystick for the airplane at the front end. Why 3? Each (seriously, each) had a moment when, due to circumstances depending on him or not, he was disconnected from development. But the team continued to work.

    Which is more convenient?

    In any product there are tasks that really need to be solved, but which are completely unrelated to development. Our designer Pasha and the generator of ideas Igor saved us a lot of time. Who knows how much we would spend on disputes where it’s better to put elements in order to add such interesting things 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 ​​our other application, which is still waiting for its finest hour, belongs entirely to Igor. If everyone, as we believe in the design abilities of a human designer and the ideas of a human generator, there will be no conflict and resentment because of rejected ideas and solutions, accepted not in your favor. If you don’t have a designer friend, remember which of your friends graduated from the painting, look at his work and designate 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 takes off, and the design doesn’t suit you, discard it and order the design from another designer. :)


    Sometimes the motivation is really not enough. I have a couple of methods of motivation tested in battle.
    1. Friends. Tell about this in paints to the maximum number of friends. When all your friends know that you are writing an application, they will not let you merge, because they will be skeptical asking: “Well, how is the application? Already laid out? ”When many people know, there is no longer the opportunity to merge.
    2. Competitors. After reading one wonderful 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 article appeared without a normal design and functionality. We were sure that we had a normal design and a couple of killer features that were not in that application. For example, viewing a Vkontakte profile right inside the application and adding to bookmarks (Wishlist). Well, and most importantly, we needed at least one completed project in the portfolio. So the competitor only strengthened us and made us write faster. The main principle that I made is not to despair if you have competitors. If your product is cooler, then you will definitely supersede the product that came earlier, but, in fact, worse.


    This item refers more to what we did not have, but it was very lacking. Now I realized how important it is to define a list of features before the first calculation and the first announcement. Without such a list, both of these items can be delayed indefinitely. It so happened that the first uploaded version of the application was buggy. Recommendation - tell your friends to whom you previously talked about the project, that you gave it all. The more people find out, the better. A stream of bug reports and suggestions will provide additional motivation and help determine a list of features that need to be fixed for the announcement. And on my own I’ll say that the clumsy application on Google Play is a good motivator in itself.

    What's next?

    You wrote an application, posted it, it somehow works, sometimes it crashes. What to do next? To develop new features or to perfect already finished to perfection? Our unequivocal answer to this controversial question is what you like, then do it! “There is no hard labor” and not a huge company. By doing what you like, you do it much better than what you don’t really like. And about the poorly working current functionality: at one point a critical mass of code will be typed, which must be refactored. And there will be a man whom it has got most of all. And again, he will be motivated to do his job well, because you cannot live on like this.

    The timing

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

    PS To see what we have already done, please follow this link . The first picabu announcement at this link . We will be very glad to downloads, good ratings, suggestions and comments.

    Also popular now: