Self-organization in web development
The most difficult thing about doing business, which is website development, is the initial organization and formalization of the entire work process. You need to plan your time, budget and, most importantly, the order of communication with the customer, because The latter directly affects both time and budget.
I personally never set myself the goal of becoming a manager. However, being a freelance developer, I was faced with the need to properly manage my time and be able to sell my work.
Further...
Any project begins with a call: either you are looking for a customer, or he is you (preferably the last * -)).
During the first, preliminary conversation, it is important to understand: "Is this our client?" I am usually interested in the cause (if they called me) or possible plans (if I call) the creation of the site. You need to try, at least in part, to understand what the client’s business is, what he sells and what he needs from the site. After all, in fact, all sell something, even if the project is not originally commercial.
')
Next, it is very important to find out the timing and budget. More precisely, not to find out, but to determine, based on the requirements of the site, how much time you will need to create it and what the initial amount will be. All these figures, of course, are very approximate, but they are necessary, because will help orient the client (does he need it) and you will understand the mood of the client (is he ready to go for it).
Often customers have a “fever” when urgently needed, “to do something quickly.” The main thing here is not to get caught, because the reasons for this rush are not always known (because the client is silent about the real reasons) and it may turn out that you will be wasted in an emergency mode.
As a result of a preliminary conversation, the date / time of the first meeting with the customer is determined. The date is determined ahead of time and you and the customer should prepare for the meeting.
From your side, you need to prepare examples and all the necessary documents (for drawing up a contract ) + equipment for demonstration and work (a laptop).
The customer must be obliged to gather all the persons concerned on his part, on whom the decisions taken will depend. In addition, I, as a rule, still ask the customer to pick up examples of sites that he likes, in order to have an idea of ​​his taste and preferences when discussing an order for a design.
Unfortunately, often there are situations when preliminary meetings are repeated. This should be carefully avoided, because often the “pre-game” leads to a dead end.
The main task of this stage is to sort everything out with the client (in the form of the Terms of Reference ) and conclude (and sign) the contract . For this and a number of other reasons, the meeting is desirable to hold on the "territory" of the customer. At the same time, all persons indirectly involved in the work of the customer must be within reach. In addition, the fact that you come yourself can have a customer for you.
You should have a manager and a programmer. Without a programmer, clearly determine the time of work and the budget does not work, because Often there are not typical tasks (for which you do not have a ready-made solution) and you need to determine the time required for their implementation and, accordingly, the cost of work.
Ideally, the manager should be aware of the work of programmers and be "in the subject." In this case, it will be easier to conduct a dialogue. If you are working alone, this is the very option.
You will need to start the dialogue again by ascertaining the tasks of the site, since it often happens that a client has “something new” or he is silent about something. Based on the tasks, the nature of the site (portal, store, promotional site ...) and the structure of its sections are determined. The latter must be determined as clearly as possible.
Naturally, you need to understand that the customer is not initially aware of all sorts of usability there and he has little thought about content optimization. Your task is to “honestly” explain to the customer what is needed and what to do and what is not worth. In general, I try to adhere to the most "honest" conversation in a conversation with the customer. It is clear that it is not necessary to disclose all the features of your "kitchen". However, what is right and what is not and why you should always say. In this case, you need to focus on that you just care about the quality of the product (what the site is) and all your actions are aimed at making it better.
The tasks of the site and its structure are “hammered” into the Terms of Reference .
Further, having a structure before our eyes, it is necessary to clearly define with the customer the functionality of each section, what should be there and in what form (form). This is a very important point, because even such a simple function as news perceives everything in its own way. All the functionality is also important to register in the TK, because if this is not done, it may turn out that the customer “meant something completely different” or “had new ideas”.
The reality is that the majority of customers believe that for the amount you indicated, he buys you, and not the final product. The task of the TOR is to help you correct this erroneous opinion.
If the customer has a “fever” and you need to have time for a certain deadline, you can divide the work into stages and highlight the primary tasks / sections.
It is also advisable to find out if the customer has any specific requirements for hosting. Personally, I prefer not to change the host and place all projects on the same site, because This makes it easier to work with customer support.
In the end, we determine the order of payment and the deadlines for the delivery of work within the project (preferably, in stages) and write everything in the contract . In addition, you must determine who will interact with you directly. This person must have a “signature right”. If you do not do this, then the “lack of responsibility” on the part of the customer may result in you sideways and you will find yourself “guilty” in the end.
The more you will have TK and the contract to it, the less then there will be problems. All the troubles that I had appeared just because of the incompleteness of the TK and the contract . Ideally, at the end of the first stage, you should have a signed contract and a TK.
At the same stage, after determining the TZ, it is desirable to discuss the wishes of the customer about the design. Unfortunately, the “order for design” is difficult to formalize (and it does not make sense), so everything will have to be written down in free form and in the form of sketches-sketches. It is advisable to immediately suppress wishes like “background from logos”, etc. (naturally, explaining why).
Having on hands TZ and the order for design it is possible to start work. In the development process, you can provide intermediate stages of the work: a prototype of the site to clarify the functionality, design layouts for approval, etc. Acceptance of all stages of the work must necessarily endorse a bilateral act of acceptance. I have witnessed more than once how customers jumped and jumped, declaring that he did not sign this - it was not.
The vast majority of developers create websites based on CMS, their own or third-party production. This is convenient because there is a basis and it only needs to be developed. In this case, once developed solutions can be used again saving a lot of time. In addition, for the most part, CMSs use a template system, which makes it possible to work on the software part, regardless of design.
If there is a need to write a new module (or adaptation of an existing one), it is necessary to clearly plan its architecture. For a long time I worked on the CMS and its modules in the “routine” mode, gradually developing and expanding the tasks. As a result, when it became necessary to merge several modules, we had to redo everything in a new way.
Architecture planning is best to start with a TODO per module: what data it should operate on and what should be able to do. For example, at the moment I am writing a blog module and in order not to get confused myself I wrote in the form of a plan what needs to be done. Based on the TODO, a database schema is developed (more precisely, a set of module tables) and how it integrates into the common CMS database, as well as the management and interaction interfaces with the module. The latter is a very important part of the development of the module, because, unlike the code and structure of the database, it is not “hidden from the user”. Therefore, the control interfaces should be understandable to the end user, not the programmer.
Unfortunately, it is not always possible to take all aspects into account in the initial planning of TODO, therefore TODO, the structure of tables and GUI (functional elements of interfaces) may change as the design progresses.
When developing modules and the entire system, two more things need to be taken into account: bug-report and the availability of documentation. I have all the system errors on the main site being carefully logged and sent to my mailbox. If something goes off the log will always help you find the error.
Documentation is a bit more complicated. As it has been repeatedly noted (link), many programmers do not like to write documentation. Especially it concerns documentation for simple users and not mana for other programmers. Unfortunately, this is not going anywhere. Even if you use a ready-made third-party system (Bitrix and others), the documentation will most likely have to be rewritten and adapted for normal people. Documentation will significantly save your time in the future when calls from customers come with questions. If a user fails something, it will always be possible to send him to the necessary page, to the necessary item and find out what is wrong.
The design itself, unfortunately, is difficult to formalize. Therefore, it all depends on your experience and personal preferences in the choice of software and methods of work. However, within the framework of a common project, a number of typical tasks / problems can be identified.
In such a situation, you can offer a ready-made design solution - a template. You can buy it, find it free or use your old stock (if any). In this case, you need to explain to the customer what the template is and how it differs from the “exclusive” design.
At the stage of concluding a contract, it is necessary to clearly define the number of design layouts being developed. If this is not done, then the work of the designer will turn into an endless redoing in an attempt to please the momentary whims of the customer ("Do me something else ..."). If the design is approved, I, as a rule, require the signature on the printout of the layout from the customer.
At the same time, the client can be “calmed down” by the fact that the site works on templates in the future, if the need arises (and if the CMS allows it), the design can be changed. But, for a fee, and under a separate contract (or annex to the current contract).
We show a prototype to the customer. It is desirable to immediately “tie” the design to it, because otherwise, it will be difficult for the customer to understand (and approve) what will work on his website and how.
At this stage, as a rule, adjustments are made to the design, functionality and structure as a whole. The main thing is to make sure that the adjustments do not lead to the development of a new site, completely different from what was indicated at the first stage (and written in the TK). If the customer stands his ground and requires a new “feature” to be added - we arrange the work with a new contract or application to the current one. The main thing in any case not to go on about, because once agreeing then it will be difficult to say no.
We make the latest adjustments and prepare the documentation. In this case, the documentation actually comes from three parts:
The manual should be as “humane” as possible and be structured in the form of structured questions / answers with a detailed, step-by-step description of all necessary actions (preferably also with screenshots).
Because in the end, the site will be accompanied by (most likely) a person on the part of the customer who needs to take care that he does not spoil the design of the site. It is necessary to paint what size the pictures should be, what styles should be used when formatting text, etc.
In fact, this is a guide to transfer the site to another hosting (or restore it from the archive). Most likely the customer, if necessary, to contact you, but it is desirable to give him the opportunity to do everything on their own.
We post everything on the main server. Immediately after the site is published, I usually conduct a series of trainings with a customer representative who will be responsible for his support. Time spent with interest then pays off, because The main part of the questions / problems is solved in the learning process. Training, among other things, is a beta test site, because often the unpredictability of user actions reveals more errors and shortcomings than a targeted search.
Do not forget to remind the customer about paying for your services.
We register the site in search engines and conduct its initial search engine optimization. At this stage, it is not uncommon for new problems with the customer, namely, the requirements on his part to host the site on the first lines of Google and Yandex. The claims mostly sound like “A site that we don’t need to be immediately in Yandez”. Here you need to be patient and calmly explain to the customer how sites get there and that very much depends on his (customer) content and the frequency of its update.
I personally never set myself the goal of becoming a manager. However, being a freelance developer, I was faced with the need to properly manage my time and be able to sell my work.
Further...
0 Stage
Any project begins with a call: either you are looking for a customer, or he is you (preferably the last * -)).
Personally, I'm not looking for customers yet. At the moment I have to work at the institute (I write disser), and therefore there is no possibility to properly organize work for the whole day. In addition, in our city / region there is a large shortage of specialists and we have to do everything ourselves, and therefore, we simply cannot manage a large flow of work. Although, this does not interfere with the work itself, since Clients themselves find me on the recommendations.
During the first, preliminary conversation, it is important to understand: "Is this our client?" I am usually interested in the cause (if they called me) or possible plans (if I call) the creation of the site. You need to try, at least in part, to understand what the client’s business is, what he sells and what he needs from the site. After all, in fact, all sell something, even if the project is not originally commercial.
')
Next, it is very important to find out the timing and budget. More precisely, not to find out, but to determine, based on the requirements of the site, how much time you will need to create it and what the initial amount will be. All these figures, of course, are very approximate, but they are necessary, because will help orient the client (does he need it) and you will understand the mood of the client (is he ready to go for it).
Often customers have a “fever” when urgently needed, “to do something quickly.” The main thing here is not to get caught, because the reasons for this rush are not always known (because the client is silent about the real reasons) and it may turn out that you will be wasted in an emergency mode.
As a result of a preliminary conversation, the date / time of the first meeting with the customer is determined. The date is determined ahead of time and you and the customer should prepare for the meeting.
From your side, you need to prepare examples and all the necessary documents (for drawing up a contract ) + equipment for demonstration and work (a laptop).
I don’t know what the situation is in big cities, but on the “periphery” you need to carry a “laptop with the Internet” by yourself. For such purposes, newfangled eeePC and clones are ideal because they are not annoying to carry with them.
The customer must be obliged to gather all the persons concerned on his part, on whom the decisions taken will depend. In addition, I, as a rule, still ask the customer to pick up examples of sites that he likes, in order to have an idea of ​​his taste and preferences when discussing an order for a design.
Unfortunately, often there are situations when preliminary meetings are repeated. This should be carefully avoided, because often the “pre-game” leads to a dead end.
Stage 1
The main task of this stage is to sort everything out with the client (in the form of the Terms of Reference ) and conclude (and sign) the contract . For this and a number of other reasons, the meeting is desirable to hold on the "territory" of the customer. At the same time, all persons indirectly involved in the work of the customer must be within reach. In addition, the fact that you come yourself can have a customer for you.
You should have a manager and a programmer. Without a programmer, clearly determine the time of work and the budget does not work, because Often there are not typical tasks (for which you do not have a ready-made solution) and you need to determine the time required for their implementation and, accordingly, the cost of work.
Ideally, the manager should be aware of the work of programmers and be "in the subject." In this case, it will be easier to conduct a dialogue. If you are working alone, this is the very option.
You will need to start the dialogue again by ascertaining the tasks of the site, since it often happens that a client has “something new” or he is silent about something. Based on the tasks, the nature of the site (portal, store, promotional site ...) and the structure of its sections are determined. The latter must be determined as clearly as possible.
Naturally, you need to understand that the customer is not initially aware of all sorts of usability there and he has little thought about content optimization. Your task is to “honestly” explain to the customer what is needed and what to do and what is not worth. In general, I try to adhere to the most "honest" conversation in a conversation with the customer. It is clear that it is not necessary to disclose all the features of your "kitchen". However, what is right and what is not and why you should always say. In this case, you need to focus on that you just care about the quality of the product (what the site is) and all your actions are aimed at making it better.
The tasks of the site and its structure are “hammered” into the Terms of Reference .
Further, having a structure before our eyes, it is necessary to clearly define with the customer the functionality of each section, what should be there and in what form (form). This is a very important point, because even such a simple function as news perceives everything in its own way. All the functionality is also important to register in the TK, because if this is not done, it may turn out that the customer “meant something completely different” or “had new ideas”.
The reality is that the majority of customers believe that for the amount you indicated, he buys you, and not the final product. The task of the TOR is to help you correct this erroneous opinion.
If the customer has a “fever” and you need to have time for a certain deadline, you can divide the work into stages and highlight the primary tasks / sections.
It is also advisable to find out if the customer has any specific requirements for hosting. Personally, I prefer not to change the host and place all projects on the same site, because This makes it easier to work with customer support.
In the end, we determine the order of payment and the deadlines for the delivery of work within the project (preferably, in stages) and write everything in the contract . In addition, you must determine who will interact with you directly. This person must have a “signature right”. If you do not do this, then the “lack of responsibility” on the part of the customer may result in you sideways and you will find yourself “guilty” in the end.
The more you will have TK and the contract to it, the less then there will be problems. All the troubles that I had appeared just because of the incompleteness of the TK and the contract . Ideally, at the end of the first stage, you should have a signed contract and a TK.
At the same stage, after determining the TZ, it is desirable to discuss the wishes of the customer about the design. Unfortunately, the “order for design” is difficult to formalize (and it does not make sense), so everything will have to be written down in free form and in the form of sketches-sketches. It is advisable to immediately suppress wishes like “background from logos”, etc. (naturally, explaining why).
Stage 2
Having on hands TZ and the order for design it is possible to start work. In the development process, you can provide intermediate stages of the work: a prototype of the site to clarify the functionality, design layouts for approval, etc. Acceptance of all stages of the work must necessarily endorse a bilateral act of acceptance. I have witnessed more than once how customers jumped and jumped, declaring that he did not sign this - it was not.
Software part of the site
The vast majority of developers create websites based on CMS, their own or third-party production. This is convenient because there is a basis and it only needs to be developed. In this case, once developed solutions can be used again saving a lot of time. In addition, for the most part, CMSs use a template system, which makes it possible to work on the software part, regardless of design.
Personally, I use my CMS, because knowing well its architecture, I know what can be done (and how), and what is not. Although it is the power of habit and in some cases it is possible to better use ready-made third-party solutions.
If there is a need to write a new module (or adaptation of an existing one), it is necessary to clearly plan its architecture. For a long time I worked on the CMS and its modules in the “routine” mode, gradually developing and expanding the tasks. As a result, when it became necessary to merge several modules, we had to redo everything in a new way.
Architecture planning is best to start with a TODO per module: what data it should operate on and what should be able to do. For example, at the moment I am writing a blog module and in order not to get confused myself I wrote in the form of a plan what needs to be done. Based on the TODO, a database schema is developed (more precisely, a set of module tables) and how it integrates into the common CMS database, as well as the management and interaction interfaces with the module. The latter is a very important part of the development of the module, because, unlike the code and structure of the database, it is not “hidden from the user”. Therefore, the control interfaces should be understandable to the end user, not the programmer.
For interface sketches, the <a.
href = " addons.mozilla.org/sq/firefox/addon/8487?lang=en "> Pencil
Unfortunately, it is not always possible to take all aspects into account in the initial planning of TODO, therefore TODO, the structure of tables and GUI (functional elements of interfaces) may change as the design progresses.
When developing modules and the entire system, two more things need to be taken into account: bug-report and the availability of documentation. I have all the system errors on the main site being carefully logged and sent to my mailbox. If something goes off the log will always help you find the error.
It is logical that working on a “live” system is not very correct. For the development of the prototype, as a rule, a local (on your work computer or corporate web server) version of the site is used. Her (or a copy) can be shown to the customer. Only after accepting the work (working version of the site) does it make sense to transfer it to the main server.
Documentation is a bit more complicated. As it has been repeatedly noted (link), many programmers do not like to write documentation. Especially it concerns documentation for simple users and not mana for other programmers. Unfortunately, this is not going anywhere. Even if you use a ready-made third-party system (Bitrix and others), the documentation will most likely have to be rewritten and adapted for normal people. Documentation will significantly save your time in the future when calls from customers come with questions. If a user fails something, it will always be possible to send him to the necessary page, to the necessary item and find out what is wrong.
Of course, you need to take into account that most of the users themselves are too lazy to read the documentation and do everything in accordance with it. I regularly test users (I have such an opportunity, because I teach teacher retraining courses) about how they use the documentation and the results are usually quite funny: the user comes to the 3rd, 4th item, and then it comes in its own way, considering that the remaining items are not important and are written “to the heap”.
Design
The design itself, unfortunately, is difficult to formalize. Therefore, it all depends on your experience and personal preferences in the choice of software and methods of work. However, within the framework of a common project, a number of typical tasks / problems can be identified.
1. If the customer needs to do everything quickly
In such a situation, you can offer a ready-made design solution - a template. You can buy it, find it free or use your old stock (if any). In this case, you need to explain to the customer what the template is and how it differs from the “exclusive” design.
2. Approval of the design by the customer
At the stage of concluding a contract, it is necessary to clearly define the number of design layouts being developed. If this is not done, then the work of the designer will turn into an endless redoing in an attempt to please the momentary whims of the customer ("Do me something else ..."). If the design is approved, I, as a rule, require the signature on the printout of the layout from the customer.
At the same time, the client can be “calmed down” by the fact that the site works on templates in the future, if the need arises (and if the CMS allows it), the design can be changed. But, for a fee, and under a separate contract (or annex to the current contract).
Stage 3
We show a prototype to the customer. It is desirable to immediately “tie” the design to it, because otherwise, it will be difficult for the customer to understand (and approve) what will work on his website and how.
At this stage, as a rule, adjustments are made to the design, functionality and structure as a whole. The main thing is to make sure that the adjustments do not lead to the development of a new site, completely different from what was indicated at the first stage (and written in the TK). If the customer stands his ground and requires a new “feature” to be added - we arrange the work with a new contract or application to the current one. The main thing in any case not to go on about, because once agreeing then it will be difficult to say no.
Stage 4
We make the latest adjustments and prepare the documentation. In this case, the documentation actually comes from three parts:
1. How to use the CMS admin panel
The manual should be as “humane” as possible and be structured in the form of structured questions / answers with a detailed, step-by-step description of all necessary actions (preferably also with screenshots).
2. Manual on the preparation and design of materials for the site
Because in the end, the site will be accompanied by (most likely) a person on the part of the customer who needs to take care that he does not spoil the design of the site. It is necessary to paint what size the pictures should be, what styles should be used when formatting text, etc.
3. Administrator's Guide for Administrator
In fact, this is a guide to transfer the site to another hosting (or restore it from the archive). Most likely the customer, if necessary, to contact you, but it is desirable to give him the opportunity to do everything on their own.
Stage 5
We post everything on the main server. Immediately after the site is published, I usually conduct a series of trainings with a customer representative who will be responsible for his support. Time spent with interest then pays off, because The main part of the questions / problems is solved in the learning process. Training, among other things, is a beta test site, because often the unpredictability of user actions reveals more errors and shortcomings than a targeted search.
Do not forget to remind the customer about paying for your services.
Stage 6
We register the site in search engines and conduct its initial search engine optimization. At this stage, it is not uncommon for new problems with the customer, namely, the requirements on his part to host the site on the first lines of Google and Yandex. The claims mostly sound like “A site that we don’t need to be immediately in Yandez”. Here you need to be patient and calmly explain to the customer how sites get there and that very much depends on his (customer) content and the frequency of its update.
Source: https://habr.com/ru/post/38969/
All Articles