How to start and end Web-projects
Good all the time of day!
After the success of our previous publication, we thought for a long time who to ask to write the next article - who will be those who will have to argue over popularity with the article about sex. The choice fell on the technical director of 404Group Roman Druzyagin, who will tell about the launch of the project from the point of view of "technicals".
“About the“ start-ups ”, their beginning, development and ending was not written except that only a very lazy person, this topic is relevant and popular. Projects appear and disappear in dozens every day, which clearly allows you to see services like Kickstarter. Paying tribute to fashion, I want to share some experience and a look at the “start-ups” market, formed as a result of many years of activity in launching and growing Internet projects within our company. Many of these projects were waiting for a sad outcome, and, often at the very start.
The material presented in this essay does not pretend to the title of truth, but it reflects well the real situation in the average “start-up” and typical problems that arise in it. Since I am a representative of the technical profession, my view will be exactly from the position of “technicals”. What is usually done correctly and incorrectly, and what results for a project can this result in?
The 404 Group Company and its founders have been investing in Web projects for a good ten years. In 70% of cases, the idea is thought up inside by representatives of the “ruling elite” and is launched into development. The remaining 30 percent comes from promising products that we invite to cooperate with us in the organization. No matter which of the two paths the project is within the walls of the company, then the game is played on an equal footing.
The project has a team (“techies” and “managers”) headed by one or two managers who are fully responsible for the goals set for the project. In exchange, the company offers the team all of its resources: financial investments in amounts specified by key participants, office facilities with cookies and attachments, operational support (financiers, lawyers, secretaries, HR and other specialists), technical competencies (experienced engineers, DBA, system administrators ) and other facilities that the company has for the project.
Which path of development the project will take and whether it will be successful is already dependent on its team. Over the years of practice, it was possible to identify several typical scenarios for the development of a particular product. With experience, we have learned, as far as possible, to adjust the course of the project if we see that it has entered a “slippery slope”. And some do not take at all under the wing of the company as obviously losing “black holes”, in which money and other resources will only flow away.
Scenario number 1 , the most promising: the project focuses on the result, adheres to the philosophy of “ship fast & often” or, to put it in a more familiar language, “x ** k and in production” . Proponents of this approach seek to bring a working product to the market as quickly as possible, begin to actively develop and improve it, based on feedback from consumers. The project rarely uses specific methodologies or development methods. Developers are hired with an acceptable level of competence, and work on “features” occurs on the principle of the sudden formulation of “immediate” tasks, which it is desirable to do by yesterday. Such a model is as viable as possible, since it is most likely to provide an opportunity for the founders to demonstrate real growth and development carried out with their money. The key problem of such a scenario is insufficient attention to the quality of the product, which can lead to serious risks that threaten the project as a whole.
')
Scenario number 2 : the project focuses on quality. Such projects are made by programmers who get tired of being a hired performer and want to try to make something of their own. A noble start, but a specialist, who is very often tired of constant struggle with “bugs” and routine, takes an extremely dangerous decision for the project to take everything into account and plan ahead. A lot of time is devoted to the right architecture, and not enough time to work through the commercial component, namely, how the project will make money.
In web projects, it’s almost impossible to take everything into account. In an effort to solve this problem, the team does not notice the complete waste of investor money, and the project is ingloriously killed. Years of experience suggest that a creatively-minded manager is able to come up with a task that is so perpendicular to the current state of architecture that it will take weeks or even months to rework. It is clear that in practice it is necessary to resort to less pleasant methods and sacrifice quality for the sake of speed.
Scenario number 3 : the project focuses on what is not clear. Such projects are often stillborn at the start. The people who invented it, in their heads there is an incomprehensible porridge of technological and commercial ideas, which is not built into something concrete. Grandiose strategic plans are being built, a large “face-sheet” is drawn. As you develop this list is freely adjusted, supplemented and expanded. If the pace of development still manages to catch up and overtake the rate of generation of new ideas before the team runs out of money, then the combined “share” turns out to be completely unsuitable: the functional elements are not consistent and do not fit together with each other into a single user experience; Usability - at zero; with all the visible wealth of opportunities, the user does not understand what to do, and how it all will benefit him. As a result, when the project comes to the finish line, it becomes clear that you cannot launch the product in this form.
A couple of examples from practice, not to be unfounded.
What is the recipe for a successful project? It is not difficult to guess that the product developing under the first scenario has the highest probability of becoming successful. Nevertheless, in order not to gain a commercially successful, but technologically insolvent project, you need to accept some compromises that both the technical department staff and commerce representatives are willing to follow.
Why are there no examples of a technically successful project in this article? Such in nature is extremely rare. If a product really works and earns money, it will always have problems: a large number of urgent tasks, lack of working hands to solve them, crookedly programmed modules and a strong desire of programmers to rewrite everything from scratch, daily bugs that have been waiting for months for their turn, denial of service , crises of a commercial nature, requiring a quick-quick cut in half a day. All this team will have to rake every day, and at the same time somehow have time to develop the product.
After the success of our previous publication, we thought for a long time who to ask to write the next article - who will be those who will have to argue over popularity with the article about sex. The choice fell on the technical director of 404Group Roman Druzyagin, who will tell about the launch of the project from the point of view of "technicals".
“About the“ start-ups ”, their beginning, development and ending was not written except that only a very lazy person, this topic is relevant and popular. Projects appear and disappear in dozens every day, which clearly allows you to see services like Kickstarter. Paying tribute to fashion, I want to share some experience and a look at the “start-ups” market, formed as a result of many years of activity in launching and growing Internet projects within our company. Many of these projects were waiting for a sad outcome, and, often at the very start.
The material presented in this essay does not pretend to the title of truth, but it reflects well the real situation in the average “start-up” and typical problems that arise in it. Since I am a representative of the technical profession, my view will be exactly from the position of “technicals”. What is usually done correctly and incorrectly, and what results for a project can this result in?
Instead of lyrical digression
The 404 Group Company and its founders have been investing in Web projects for a good ten years. In 70% of cases, the idea is thought up inside by representatives of the “ruling elite” and is launched into development. The remaining 30 percent comes from promising products that we invite to cooperate with us in the organization. No matter which of the two paths the project is within the walls of the company, then the game is played on an equal footing.
The project has a team (“techies” and “managers”) headed by one or two managers who are fully responsible for the goals set for the project. In exchange, the company offers the team all of its resources: financial investments in amounts specified by key participants, office facilities with cookies and attachments, operational support (financiers, lawyers, secretaries, HR and other specialists), technical competencies (experienced engineers, DBA, system administrators ) and other facilities that the company has for the project.
Which path of development the project will take and whether it will be successful is already dependent on its team. Over the years of practice, it was possible to identify several typical scenarios for the development of a particular product. With experience, we have learned, as far as possible, to adjust the course of the project if we see that it has entered a “slippery slope”. And some do not take at all under the wing of the company as obviously losing “black holes”, in which money and other resources will only flow away.
Three typical development scenarios “start-up”
Scenario number 1 , the most promising: the project focuses on the result, adheres to the philosophy of “ship fast & often” or, to put it in a more familiar language, “x ** k and in production” . Proponents of this approach seek to bring a working product to the market as quickly as possible, begin to actively develop and improve it, based on feedback from consumers. The project rarely uses specific methodologies or development methods. Developers are hired with an acceptable level of competence, and work on “features” occurs on the principle of the sudden formulation of “immediate” tasks, which it is desirable to do by yesterday. Such a model is as viable as possible, since it is most likely to provide an opportunity for the founders to demonstrate real growth and development carried out with their money. The key problem of such a scenario is insufficient attention to the quality of the product, which can lead to serious risks that threaten the project as a whole.
')
Scenario number 2 : the project focuses on quality. Such projects are made by programmers who get tired of being a hired performer and want to try to make something of their own. A noble start, but a specialist, who is very often tired of constant struggle with “bugs” and routine, takes an extremely dangerous decision for the project to take everything into account and plan ahead. A lot of time is devoted to the right architecture, and not enough time to work through the commercial component, namely, how the project will make money.
In web projects, it’s almost impossible to take everything into account. In an effort to solve this problem, the team does not notice the complete waste of investor money, and the project is ingloriously killed. Years of experience suggest that a creatively-minded manager is able to come up with a task that is so perpendicular to the current state of architecture that it will take weeks or even months to rework. It is clear that in practice it is necessary to resort to less pleasant methods and sacrifice quality for the sake of speed.
Scenario number 3 : the project focuses on what is not clear. Such projects are often stillborn at the start. The people who invented it, in their heads there is an incomprehensible porridge of technological and commercial ideas, which is not built into something concrete. Grandiose strategic plans are being built, a large “face-sheet” is drawn. As you develop this list is freely adjusted, supplemented and expanded. If the pace of development still manages to catch up and overtake the rate of generation of new ideas before the team runs out of money, then the combined “share” turns out to be completely unsuitable: the functional elements are not consistent and do not fit together with each other into a single user experience; Usability - at zero; with all the visible wealth of opportunities, the user does not understand what to do, and how it all will benefit him. As a result, when the project comes to the finish line, it becomes clear that you cannot launch the product in this form.
A couple of examples from practice, not to be unfounded.
- Example â„–1: a large advertising network
It was an honest and good attempt to make a successful product, which at the same time would be technologically high-quality and free from the problems encountered in other projects of the company that had achieved commercial success. At the start, we hired several highly qualified engineers, bought many servers, invented architecture, more than half a year sawed and prepared for the start.
In practice, we got a serious over-engineering, which obliged the team to support a complex multi-tier architecture on almost every task. This became especially critical at that moment when we realized that the pace of the decision in such conditions was unacceptable, and we simply could not keep up with our competitors. With them, in the system assembled “on the knee”, the integration of a partner takes half a day, we have half a week, at best. The race was lost, the project was closed. - Example number 2: a small but proud social network
At the start: the desire to do something big and bright. Due to the specifics of the monetization methods are not identified specifically. Hired the most courageous and brave samurai, compiled a global “feature list”. In practice: confusion and vacillation, the “personalist” grows, the architecture of the project exists exclusively in the head of the architect, any questions are answered that “everything is very difficult”, months go by, from real indicators the registration hardly works.
After six months of such work, the staff was dispersed, normal engineers from the experts of the parent company were involved, the system was designed in 2-3 weeks and assembled in a few months on the frozen “feature developer”. These “features” are needed or not, no one thinks anymore, it is important to collect and show the founders are extremely dissatisfied. The output is a product that is not coordinated and filled with functions that are loosely connected with each other, which is disastrous for a social network. Another 3 months is spent on re-designing the UI, modifications and edits. The project is released, it works, but the “exhaust” is zero due to a poorly developed commercial strategy. The result: the project is frozen.
What is the recipe for a successful project? It is not difficult to guess that the product developing under the first scenario has the highest probability of becoming successful. Nevertheless, in order not to gain a commercially successful, but technologically insolvent project, you need to accept some compromises that both the technical department staff and commerce representatives are willing to follow.
- Compromise number 1: the choice and operation of technology
First of all, it does not matter what technologies (programming languages, DBMS, application server, Web server, etc.) and methodologies you use. You need to choose cost-effective solutions. Something popular and traditional (PHP, MySQL / PostgreSQL) provides the possibility of hiring from a wide pool of candidates at reasonable prices. Of course, you can write your application on Erlang, but then you will be tormented to look for an adequate specialist who does not ask for exorbitant money.
Secondly, it is very important to exploit the selected technologies and methodologies systematically. Do not be lazy to make rules and guidelines for writing and structuring code, design comments. Enter the practice of code review and force your programmers to systematically withstand these requirements. The success of the project lies not in the correct architecture (which, anyway, at some point will become wrong), but in the systemic nature of its support by the team. When all programmers write code in the same style, the cost of understanding the programmer in the essence of the problem, written by another developer, is greatly reduced, which generally increases the efficiency of the technical department at times. Do not neglect the rules and regulations, they are almost the most important aspect of the development process.
And never-never listen to the excuses that programmers cannot write neat code at a fast pace. This is an absurd statement and a sign of laziness or incompetence. Stylistic design and coding culture is a trained skill, with good programmers present at the level of muscle memory. Train your programmers and let them relax. - Compromise number 2: the rejection of universality
The next inalienable compromise is the conscious refusal to make a universal architecture. As one of my colleagues said, it was never possible to catch the moment when another project moves from the state of “immediately do everything right” to the state of “initially everything was done wrong”. It is inevitable, and you will come across this. Accept the fact that your project will have non-optimal solutions and “crutches”.
Think, paradoxically as it may seem, the rules for implementing such solutions, document them. As a rule, it is with such solutions that the most critical logic for business is implemented. The availability of such documentation is many times more valuable than beautiful comments in the code that are automatically converted by some tool into a beautiful HTML page with documentation on class methods. No one ever reads them. And, since it is almost impossible to maintain 100% documentation in an intensively developing project, immediately direct the efforts of your programmers and demand to describe the problems that really require it. - Compromise number 3: security concerns
Practice shows that even the most experienced programmers often have very superficial ideas about the security of a Web product. What are the typical vectors for attacks and how can an attacker exploit them? How to protect them? How to work with the database to avoid the loss or theft of information? The developer may not know the answers to these questions or not give them enough attention, because the programmer’s key aspect of the work is the code.
In fact, the most important resource of any Internet project is data. The technical department does not think about them, because the code is the core of the system, and the representatives of commerce do not think because they have limited technical competences and have a headache for other reasons. Understanding and awareness of the importance of data appears at a time when the resource is under attack from competitors, as in the sad joke about admins who have not yet made backups and are already doing them.
Make sure that your team has at least one person (highly desirable as a technical leader), who will inform the entire team, develop the necessary practices for writing secure code, control their system maintenance, and establish the correct backup and data recovery procedure. I have repeatedly watched successful projects that were “hacked” with extremely trivial vulnerabilities. Purposeful auditing of completely different products revealed similar problems: lack of filtering of input parameters, unprotected forms for loading images, etc. These are all trivial nonsense that can be prevented only by consciously paying attention to the issue of security.
Remember, data is more important than code! You can write a new code, and lost data is not so easy to collect.
Summing up
Why are there no examples of a technically successful project in this article? Such in nature is extremely rare. If a product really works and earns money, it will always have problems: a large number of urgent tasks, lack of working hands to solve them, crookedly programmed modules and a strong desire of programmers to rewrite everything from scratch, daily bugs that have been waiting for months for their turn, denial of service , crises of a commercial nature, requiring a quick-quick cut in half a day. All this team will have to rake every day, and at the same time somehow have time to develop the product.
Source: https://habr.com/ru/post/292266/
All Articles