Online Store Timey Handytime
Not so long ago, we launched a new online store for fans of online games.
Our employee valvet wrote an article about the development process - we give his story below.
Hello!
I want to bring to your attention the project Handytime - online store of game timecodes. I would be glad if you, after reading the post, visit the site and express your opinion.
There was a lot of text: I wanted to tell in more detail about the development process, so that it would be interesting for my colleagues.
')
At the moment, Handytime allows you to purchase timecodes and keys for game currency.
At present, there are not so many differences from other online gaming stores:
The store was launched recently, and we still cannot boast a wide range and a long list of payment systems, but still ahead.
Work on the project began even before the gathering of the team: it turned out that its future members began to be interested in online commerce. As we all work in the gaming industry, naturally, the main attention was paid to the main representatives of the gaming market.
Each of us made his own opinion on the state of affairs, after which we, in fact, gathered into the team. We are:
To begin with, we decided to create a “global” action plan. Looking ahead, I’ll say that we got excited with the “globality”.
In the plan, we identified the following main points:
This is not the whole list, I have highlighted only the most standard topics. And each item was described in the document in great detail. Making such a plan is a really good idea for people who are new to creating a new product for the first time, but you need to be careful about this. We encountered the following problems:
Somewhere a month later, it was decided to stop suffering with scabs and go to action. We fixed the document in its current state, took as a basis its key elements and proceeded to the creation of a prototype.
But first - another rake.
I want to talk about our choice of store engine. I did not find an article in which I saw an example of a situation that is 100% applicable to us, therefore I will briefly describe myself.
So there were circumstances that we didn’t have a choice between writing a store from scratch and a ready-made cms - the last one was needed. And we made a major mistake in this business: we simply compared the functionality of cms based on the words of the developers. We didn’t think that from the functionality available in cms it would be useful to us, we didn’t search for reviews.
As a result, a really good ShopA-Script engine from WebAsyst was chosen.
The problem is that, like the vast majority of engines, Shop-Script is focused on a full-fledged online store with retail delivery and is not so “expandable”, because of what we have:
Things seem to be obvious, but in fact rarely anyone thinks about it.
In the work on the prototype, we used the now popular Scrum methodology, in which the head of the main direction of the company helped us. Despite the well-known dislike of most programmers for this methodology (at least according to the experience of our company), Scrum bore fruit: the prototype was completed in about a month and satisfied the wishes of the management.
At this stage, it is difficult to identify any features or errors, except for two:
Actually, the main work has begun. We approached her with losses: one of the programmers fell off, having switched to another direction.
Established by the management of the period of work was a month and a little.
In fact, it turned out four.
At the "military council" we decided that the programmer should not deviate from the well-proven Scrum. I worked on the principle “it was necessary yesterday.”
I will not describe the numerous errors that have occurred at this stage - too many of them. I want to tell only about two main ones that influenced the development time:
With deadlines, everything is prosaic: when developing a general work plan, the task was to fit into the month, so we discarded the minor tasks, naively believing that they would be solved in the course of work.
Plus, our misunderstanding with the programmer backdropped: I didn’t fully detail the requirements for the tasks, and the programmer implemented these gaps at his own discretion. As a result, it was necessary to spend time on the review and reworking of seemingly ready features.
The design studio turned out to be a very instructive situation for me personally. They have already done several orders for our company, so I considered them as good friends in advance and communicated with them accordingly. Work went productively only after changing the style of work from friendly to formal.
I want to immediately say that we liked and like the end result of their work now. Just now I understand that in business, relying on friendship is not worth it in the first place.
Actually, as a result, we got a working store in its current form (at the end of the article there are screenshots in which I tried to demonstrate the current functionality).
We did not have time to rejoice at the launch of the store, as the harsh reality put us in place - we realized that work was just beginning. We left Scrum: the fact is that the current style of work does not require such precise planning as during the initial development, so we came to Kanban.
From the immediate tasks we have:
Thank you for reading.
Finally - the promised screenshots (clickable).
Our employee valvet wrote an article about the development process - we give his story below.
Hello!
I want to bring to your attention the project Handytime - online store of game timecodes. I would be glad if you, after reading the post, visit the site and express your opinion.
There was a lot of text: I wanted to tell in more detail about the development process, so that it would be interesting for my colleagues.
')
Briefly about the store
At the moment, Handytime allows you to purchase timecodes and keys for game currency.
At present, there are not so many differences from other online gaming stores:
- quick purchase (ordering takes place within one page);
- Ordering does not require registration (it will be implemented later).
The store was launched recently, and we still cannot boast a wide range and a long list of payment systems, but still ahead.
Getting started aka planning
Work on the project began even before the gathering of the team: it turned out that its future members began to be interested in online commerce. As we all work in the gaming industry, naturally, the main attention was paid to the main representatives of the gaming market.
Each of us made his own opinion on the state of affairs, after which we, in fact, gathered into the team. We are:
- I as a project manager (contracts, paperwork and other bureaucracy, as well as kicking coders);
- two web programmers.
To begin with, we decided to create a “global” action plan. Looking ahead, I’ll say that we got excited with the “globality”.
In the plan, we identified the following main points:
- objective of the project;
- the target audience;
- USP and main features;
- main functionality;
- planned payment systems;
- planned advertising;
- stages of development.
This is not the whole list, I have highlighted only the most standard topics. And each item was described in the document in great detail. Making such a plan is a really good idea for people who are new to creating a new product for the first time, but you need to be careful about this. We encountered the following problems:
- failure to understand what to do “dream shop” is stupid (although we should have understood this, because there are a lot of similar game examples);
- work with the plan turned into an endless discussion.
Somewhere a month later, it was decided to stop suffering with scabs and go to action. We fixed the document in its current state, took as a basis its key elements and proceeded to the creation of a prototype.
But first - another rake.
CMS
I want to talk about our choice of store engine. I did not find an article in which I saw an example of a situation that is 100% applicable to us, therefore I will briefly describe myself.
So there were circumstances that we didn’t have a choice between writing a store from scratch and a ready-made cms - the last one was needed. And we made a major mistake in this business: we simply compared the functionality of cms based on the words of the developers. We didn’t think that from the functionality available in cms it would be useful to us, we didn’t search for reviews.
As a result, a really good ShopA-Script engine from WebAsyst was chosen.
The problem is that, like the vast majority of engines, Shop-Script is focused on a full-fledged online store with retail delivery and is not so “expandable”, because of what we have:
- redundancy of the functional and, as a result, an extra code;
- increase in time spent adding new functionality.
Things seem to be obvious, but in fact rarely anyone thinks about it.
Prototype
In the work on the prototype, we used the now popular Scrum methodology, in which the head of the main direction of the company helped us. Despite the well-known dislike of most programmers for this methodology (at least according to the experience of our company), Scrum bore fruit: the prototype was completed in about a month and satisfied the wishes of the management.
At this stage, it is difficult to identify any features or errors, except for two:
- although the product and I shared the same vision with the team, we saw the implementation of specific features differently, which resulted in many problems in the future;
- my lack of leadership experience, which also affected in the future.
Development
Actually, the main work has begun. We approached her with losses: one of the programmers fell off, having switched to another direction.
Established by the management of the period of work was a month and a little.
In fact, it turned out four.
At the "military council" we decided that the programmer should not deviate from the well-proven Scrum. I worked on the principle “it was necessary yesterday.”
I will not describe the numerous errors that have occurred at this stage - too many of them. I want to tell only about two main ones that influenced the development time:
- Incorrectly set deadlines
- error when working with a design studio.
With deadlines, everything is prosaic: when developing a general work plan, the task was to fit into the month, so we discarded the minor tasks, naively believing that they would be solved in the course of work.
Plus, our misunderstanding with the programmer backdropped: I didn’t fully detail the requirements for the tasks, and the programmer implemented these gaps at his own discretion. As a result, it was necessary to spend time on the review and reworking of seemingly ready features.
The design studio turned out to be a very instructive situation for me personally. They have already done several orders for our company, so I considered them as good friends in advance and communicated with them accordingly. Work went productively only after changing the style of work from friendly to formal.
I want to immediately say that we liked and like the end result of their work now. Just now I understand that in business, relying on friendship is not worth it in the first place.
Total
Actually, as a result, we got a working store in its current form (at the end of the article there are screenshots in which I tried to demonstrate the current functionality).
We did not have time to rejoice at the launch of the store, as the harsh reality put us in place - we realized that work was just beginning. We left Scrum: the fact is that the current style of work does not require such precise planning as during the initial development, so we came to Kanban.
From the immediate tasks we have:
- implementation of key features;
- user engagement;
- receiving feedback from customers and improving the store in accordance with them;
- increase the catalog and number of payment systems.
Thank you for reading.
Finally - the promised screenshots (clickable).
Home page
Home page with selected product
News page
Contacts
FAQ / Feedback
Terms of use
Source: https://habr.com/ru/post/106433/
All Articles