About the importance of words, or a little about the "eternal beta"
Have you ever thought about why the developers of some web resources write the word "beta" in the headers? Many people believe that this is another marketing move of Web 2.0 (along with “lacquered” interface elements, large fonts and RSS support).
I admit honestly, I once thought so myself.
However, the inscription BETA is still more than just an inscription. Creating any web service starts with an idea. A prototype appears behind the idea, and on the basis of the prototype, the project implementation plan itself. If there are several developers (and they are professional enough), then UML diagrams, a site map are drawn, a preliminary HTML layout is created, etc. So it was with us: it seemed that everything was clear and transparent. However, when the alpha was ready, I had quite certain doubts: “ did we really want this as a result? "And most importantly," but will people use it? ".
')
The easiest way to find out the answers is to start the service. In the beta. Actually nothing to lose, and the phrase " We call it" beta "because it's beta than nothin ' " inspired confidence.
And here the most interesting began. The more time passed from the “beta” launch point, the farther and farther my views on service went from the very initial concept / idea.
(And it was only later that I learned about the words of Paul Graham , that three months after the start of development, startups change their direction by 70%, and some even by 100%)
The Internet has changed not only user behavior, it has also changed the approach to development. In order to release a new release, you do not need to do an installer, stamp discs, print printing, pack in boxes and send it all to stores later.
We have the opportunity to make releases at least every day, introducing new features and correcting the mistakes of the old ones. We can constantly monitor user behavior, get feedbacks, and on their basis determine which direction to develop the project. That is why an ordinary user becomes a member of the development team.
After some time, we came to the conclusion that the average cycle time is 2-3 weeks (and sometimes less). Users constantly see some changes on the site and can influence the direction in which the project is developing.
You can’t create an Internet product for half a year now, then test it thoroughly for half a year, and then roll out a release that the market most likely won't need.
As a result, we realized with the help of users that the concept of the project will change quite seriously in the next month and a half. And it is worth saying thanks to all those who are suffering now all the bugs, giving advice, and in fact together with us making a product that people really need.
Without such an approach, making a successful Internet application is extremely difficult.
And finally, I will say that the service in the beta stage is in the concept and in the code. Short iterations also generate an increased percentage of errors (bugs). Automated tests, of course, save the situation, but the human factor also can not be excluded. And some bugs can quite thoroughly undermine the reputation of the service. For example, not so long ago we had a failure in the e-mail notification module, and users received from 20 to 60 letters that were not intended for them.
Do not forget that beta is not alpha at all, and if everything falls and falls off through you once again - this is a banal disrespect to its users.
Errors, of course, happen, but their appearance in users' browsers should be minimized.
(Many people remember bobrdobr.ru and the screenshots that went around the network with its ServletException, although in the end it all ended well: the service grows and develops)
I admit honestly, I once thought so myself.
However, the inscription BETA is still more than just an inscription. Creating any web service starts with an idea. A prototype appears behind the idea, and on the basis of the prototype, the project implementation plan itself. If there are several developers (and they are professional enough), then UML diagrams, a site map are drawn, a preliminary HTML layout is created, etc. So it was with us: it seemed that everything was clear and transparent. However, when the alpha was ready, I had quite certain doubts: “ did we really want this as a result? "And most importantly," but will people use it? ".
')
The easiest way to find out the answers is to start the service. In the beta. Actually nothing to lose, and the phrase " We call it" beta "because it's beta than nothin ' " inspired confidence.
And here the most interesting began. The more time passed from the “beta” launch point, the farther and farther my views on service went from the very initial concept / idea.
(And it was only later that I learned about the words of Paul Graham , that three months after the start of development, startups change their direction by 70%, and some even by 100%)
The Internet has changed not only user behavior, it has also changed the approach to development. In order to release a new release, you do not need to do an installer, stamp discs, print printing, pack in boxes and send it all to stores later.
We have the opportunity to make releases at least every day, introducing new features and correcting the mistakes of the old ones. We can constantly monitor user behavior, get feedbacks, and on their basis determine which direction to develop the project. That is why an ordinary user becomes a member of the development team.
By the way, the inclusion of a “product customer” in a team is one of the main practices of the Scrum development methodology ( Agile development ). If you develop according to Scrum, then the development cycle can be shortened several times (compared to the development of desktop applications).
After some time, we came to the conclusion that the average cycle time is 2-3 weeks (and sometimes less). Users constantly see some changes on the site and can influence the direction in which the project is developing.
You can’t create an Internet product for half a year now, then test it thoroughly for half a year, and then roll out a release that the market most likely won't need.
As a result, we realized with the help of users that the concept of the project will change quite seriously in the next month and a half. And it is worth saying thanks to all those who are suffering now all the bugs, giving advice, and in fact together with us making a product that people really need.
Without such an approach, making a successful Internet application is extremely difficult.
And finally, I will say that the service in the beta stage is in the concept and in the code. Short iterations also generate an increased percentage of errors (bugs). Automated tests, of course, save the situation, but the human factor also can not be excluded. And some bugs can quite thoroughly undermine the reputation of the service. For example, not so long ago we had a failure in the e-mail notification module, and users received from 20 to 60 letters that were not intended for them.
Do not forget that beta is not alpha at all, and if everything falls and falls off through you once again - this is a banal disrespect to its users.
Errors, of course, happen, but their appearance in users' browsers should be minimized.
(Many people remember bobrdobr.ru and the screenshots that went around the network with its ServletException, although in the end it all ended well: the service grows and develops)
Source: https://habr.com/ru/post/11952/
All Articles