About working with customers, development and implementation of software

I read how people fight with users of their software and decided to share experience with the world. I must say right away that my experience is not small - at one time my programs were in great demand and I ate more than one dog for their support. As a result, customers wrote boiling water, and users sabotaged any other software that was launched from above, except mine. As a success story, I’ll give you a not-too-large project for automation of gas stations. There was an order from the gas station to develop the operator's workstation. The task was to work with gas stations, cash registers, print reports for accounting and various authorities and some in-house specifics. Before me they had experience implementing custom software, but the experience was negative - the software was buggy, the operators quietly hated it, most of the reports were made on a piece of paper and a calculator, and the cash register was perceived as some kind of evil demon, who needs to bring vilification and call tech support twice a week. The customer was versed in computers at the level of a very, very average user, he was intimidated and tried to write TK, which came down to describing some buttons on the screen and fonts in reports in the absence of requirements for the logic of work. In short, the customer was afraid that they would make him another shit and tried to wallow in the details in which Nicerta did not understand.

Stage one - find mutual understanding with the customer.

First of all, work was carried out with the customer in order to achieve mutual understanding and stop frantic throwing. It was pure politics and psychology. First I explained to the customer that I was not going to "milk" or "throw" him. That I have some reputation, and I treasure it very much. That the reputation is more expensive for me than money and that I am going to either do the job well, or I won’t take it at all. I showed the customer that I am a professional, that I can be trusted. I also unobtrusively explained to the customer that I understand some issues better than him, and I will do some things as I see fit, but if I make a mistake, I will fix everything for free, even if I have to redo everything. In addition, I led the customer to the idea that it is not necessary to rush to write Tolmuds of TK, but it makes sense to first clarify his needs. What,In short:

1. Personally, I believe that there must necessarily be some small preparatory, non-binding stage. For example, in order to develop tactics of behavior or even be able to abandon the project if there are insurmountable difficulties.
2. Correctly put yourself with the customer and achieve his trust. This is the main thing. Sometimes you can see that it’s better to give up work than to contact a conflicting customer.
3. It is necessary to determine who decides what and with the customer, whom to contact on what issues, etc.
4. It is necessary that the customer understands that money is not the main thing. The main thing is that he be happy. And money is a payment for a good job and his happiness. And that no one is going to deceive him.
5. Agree on the joint development of TK. Moreover, in this case, I write TK, and the customer sets out wishes in a free form and further approves TK. In any case, TK should be consistent. If some parts of TK can cause difficulties, then this must be specified in order to avoid unpleasant surprises in the future.
6. The customer understood that there would be some pressure on my part; I will not realize some openly delusional wishes, and some things I will do as I see fit. In exchange, the customer receives a kind of guarantee - if my decisions are incorrect, they will definitely be corrected.
7. I will have some additional requirements - the ability to communicate with the staff who will operate the program, accounting, the ability to ask a lot of questions, and the ability to have access to the facility during development and the test period. In short, I will need to provide some assistance, but it will more than pay off in the future.

Stage Two - Logistics.

Well, first of all, I asked the customer to express their wildest dreams. What personally would he like from software. Moreover, the customer was sent several times to “think further” until he began to tell clearly about his desires and these stories did not begin to repeat. Several times I threw ideas at him and pointed out the shortcomings of some of the solutions he proposed. As a result, I was convinced that the customer decided on his basic desires. Then I went and talked to the staff several times. I listened to their wishes, expressed my suggestions. I watched how they work now. I looked at the current software. I took an interest in what is not comfortable in the current software. I talked with accounting. I looked at the reports. He asked what was missing in them. Then he talked with all this again with the customer. He learned a lot for himself - it turns outTotal:

1. It is imperative that the customer decides what he really wants. Often, the customer initially comes with thoughts “about green buttons” and “company logo on reports” and finds it difficult to formulate his desires even in general terms. If you do not let him "mature", then the result may be that he wanted something completely different or did not want anything at all. Moreover, a “matured” customer, as a rule, is more interested in the product and perceives it already as something really existing.
2. No need to completely remove the customer from the creative process. Sometimes I deliberately leave some point for later at the discretion of the customer so that he has something to think about and express his strong opinion. Sometimes this translates into strange changes in an almost finished product, but the client is happy.
3. Be sure to add a personal opinion about the process and talk with people who will directly operate the system. They have very strange wishes, but of course this greatly increases labor productivity and the quality of the system.
4. To coordinate the opinion of the authorities (customer) and those who will operate the system. Often there are conflicts of interest and if they are not resolved in advance, then you can run into sabotage.
5. Be sure to find out what you like / dislike in the existing software. And what do competitors like / dislike. Often, this is what is crucial for the customer, and it is there that the true reasons lie, forcing him to go on the development of new software.

Stage Three - Coordination of TOR.

Finally, the stage of direct writing and approval of the ToR has come. TK itself was presented in a fairly free style with an absolutely minimal set of technical terms and maximum emphasis on functionality - only a common framework was established regarding the implementation. There were several points where our opinions with the customer diverged dramatically. For some of these points, we agreed that I will do as I see fit, and if I turn out to be wrong, I will redo it for free. For some, several possible solutions were outlined; the final version will be selected later. And for several points I had to make two options - the customer stubbornly stood his ground, but I already had extremely positive experience and I was sure that my option would win.

1. Harmonization of TK (actually, it’s almost over).
2. I am writing a technological layout of the program and testing it. Because Since the program had to work with hardware, it was necessary to check some solutions in place with access to live hardware.
3. I write a mock program with the basic functionality, show it to the customer and test it on hardware and on staff. Based on the results, we are finally determined with obscure points of TK.
4. I give the first trial version, and we put it to test operation. The version will have the basic functionality, but some things I will modify and finish the operation campaign. At the same time I accept the wishes within the framework of the ToR. This stage was fixed for a maximum period with the goal of how to protect yourself from the superfluous wishes of the customer and the customer from eternal completions.
5. I give the final version, and implement it. During this period, I still accept some wishes. Also a strict time limit. The customer pays the remainder of the money during this period in exchange for a distribution.
6. Warranty period - I only correct errors, but do not change the functionality.

Since the amount was fixed, only the maximum duration of the project was limited. The exact dates were prescribed only for stages 5 and 6. For the fourth stage, the maximum term was prescribed. Naturally, I indicated the planned dates for all stages (with a significant margin). Total:

1. The presentation of TK is not so important, the main thing is to stipulate the main functionality and controversial issues. Moreover, controversial issues are, in fact, that is why TK needs to be done.
2. Once again controversial points and potential difficulties. Even if you stipulate them verbally, in the future it will allow you to quickly find a common language in case of unforeseen problems.
3. Timing should be laid with a margin and indicate exactly what changes are possible at each stage.

Any kind of notes on how to make a product popular:

In the project itself, I focused on ergonomics and fault tolerance. The basic rule is that with this program a person should work for days without experiencing inconvenience. The interface should be licked perfectly. No bright colors, no extra beauty. No show off. No beautiful fonts - Arial is our choice. People with this program will work from morning to evening for years. The author himself must work with his program until he begins to feel sick. You need to stare at your interface for days, and perform the same actions hundreds of times. And if something starts to unnerve, then rule, regardless of ranks and regalia. Then let another person sit down for the program; let him sit and work with her. And if something is uncomfortable for him, then to rule, regardless of any common sense considerations. There should be no excuses like "it was not intended to be" or "it does not fit into the concept." Controls can be duplicated five times if they are often used. They can be in the most unexpected places, if the user expects to see them there. All fonts should be such that after a day of persistent staring at the monitor they can still be seen. Even if it’s not kosher, there are as many fonts and their sizes as you need. And again - no bright colors. Watch until it cradles. And when it crashes, edit so as not to cradle. Then give the end user, sit next to and sit a couple of working days. If the program is focused on continuous active work, then sit for a week - see how it works in the morning, afternoon and evening, how shifts change, how users teach each other. Then the network itself and work for the user at his workplace. You will immediately see where you need to edit. If the user somewhere frantically clicks the mouse and throws the mouse five times and grabs the keyboard, then edit immediately. In some places, I had to make my own on-screen keyboard - this allowed us not to be distracted from the screen and not to throw the mouse. In some places it was necessary to duplicate functions in the most non-trivial way - it seemed to the user that if “poke this icon here, then something should happen.” If the user can forget to press the button and the button must be pressed, then the button must be pressed through the specified time or should pop up a reminder. If the user is often sealed somewhere, then there should be an opportunity to correct the situation. If the user writes something on a piece of paper while working with the program, then you need to give him the opportunity to take notes directly in the program, even if it is ten times stupid and not beautiful. If the user forgets why the button is needed, then there should be a tooltip, icon and inscription. Better yet, ask how it, in his opinion, should work. Now, when everyone likes everything, then you can lick the design. But then again, check everything again for ergonomics. And so that nothing could be spoiled. It is fundamentally. The user in no way should be able to spoil something. It is useless to write instructions. You need to double-check everything in the program ten times, display warnings and dialogs, and so that in each dialogue the default answer is set to a safe position. The program should work without maintenance for years. The reports should be such so that any fool could figure them out. If necessary, duplicate the numbers and columns in the tables. Duplicate tables. Print explanations and notes if strange results are produced. In short, the interface in the working software should go from the user, then from those processes and only then from the thoughts and considerations of the author and design. If users write boiling water from the program interface, they will be ready competitors will have no chance at all, no matter what functionality and at what price they would not offer. If the customer feels that his dreams are fulfilled, then he will always be ready to meet them.

One more note about the instructions.

As life experience shows, a detailed help in a program is practically useless. The simple, accessible instructions for each form help more. But even this will never be used by anyone. You need to do tooltips and status bars. It is necessary to write several instructions for each category of users for the main cases. And be sure to print. Put / stick on the workplace. It is desirable in the form of a “question and answer”. And the most accessible and understandable language. To enter into these manuscripts all the questions that are asked more than one or two times at the implementation stage. Separately make instructions with secret knowledge for advanced users. Users will pray for these pieces of paper. To begin the implementation you need to train one or two of the most intelligent users. Then they need to be involved in the process - as experience shows, users train each other much faster and easier than they can be trained from the side. You must definitely think about those who will support this system. For all kinds of administrators, you need to write understandable instructions. You need to write in the expectation that a person who understands computers, but who is absolutely and categorically lazy to delve into something, will read. This man was kicked up from his chair, possibly even on the weekend, and with the wording “the program does not work as before,” they threw him into the embrasure. It is necessary that he quickly find in the instructions his problem and ways to solve it. Let the decisions be not optimal, the main thing is that they can be easily repeated without digging into the giblets of the program. The optimal presentation style is a small introduction to the structure of the system, in case you still have to dig into giblets. Then a list of possible difficulties in the form of an “If-Then” and a section describing some rare official operations. It is advisable to make scripts or programs for archiving / unzipping / restoring and other administration in advance. Sabotage from technical support is a terrible thing. Well, if technical support is on your side, it greatly saves nerves and time. In short, everything should be accessible and understandable and designed for a person who performs some simple everyday actions without much understanding of the secret meaning of what is happening. Everything should be duplicated in paper form and be available locally. Users are great at teaching each other. Technical support should not scold the product, otherwise it will ruin it. In conclusion, I want to say that from the point of view of execution, this approach has proven itself well and has been successfully tested on several large projects. Difficulties arose with the organization of work, in some cases - knocking out payments from the customer and after-sales support, but this is a separate issue.Update :

Small Huge addition at the request of the workers.

  I deliberately did not go into the details of the project, since the text was already quite large, and the details are beyond the scope of this topic. But here in the comments and inbox, people require details. In order to maintain at least some coherence and consistency of the text, I decided to add a small addendum and place it in the form of a response to the comment of the user “belnetmon” - I hope he will not mind.

“Belnetmon: The post essentially describes the next Operden as a class of tasks. By the way, it is interesting that the product was covered by automation? what area of ​​activity? Judging by the text, iterative product development is described with essentially fuzzy initial requirements. "Sketched the frame", "Do not like it - I will remake everything for free." In real life, this is very rarely the case. The second feature that comes through is that we are talking about custom development for one specific customer. Without any generalization, such an experience approach is not replicated to other customers, where the report will also depend on the phase of the moon. “He wants - we’ll make another column here.” That is, it turns out even at the level of the same reports, uniqueness, which, when replicated to other customers, will be very difficult to maintain. ”

   This is not a “feather” - this is a very successful freelance experience.
   As for what covered the project, the task was to automate the gas station. As I mentioned at the beginning of the text - the management of gas stations, work with the cash register, the issuance of a variety of reports. Logically - this is working with the cashier (maintaining the cashier), selling fuel with its specifics, working with payment cards (own and bank cards), selling related products, accounting for fuel, exporting data to bookkeeping, etc. All of this was superimposed by the specifics of the fuel trade - a lot of options and payment methods, many potential emergency situations, work shifts, conflicting requirements of our legislation, etc. In fact, after the introduction of the program, the only thing people worked at the gas station, and this imposed very strict requirements on ergonomics, was that the operator had to look at the screen 24 hours and repeat the same operations thousands of times a day.
   About the fuzzy initial requirements. The situation was not quite like that. I repeat - at that time there was already a lot of experience in the development and implementation of various automation systems. The customer also had extensive experience in operating various programs and equipment, but he thought in patterns. The customer came due to the fact that everything on the market was either not convenient or did not have the functionality he needed. In the course of working with the customer, he was shown new approaches and opportunities - as a result, he realized that it was possible not just to make a clone of someone else's product with minor changes, but a new complete system.
And it seems to me that many readers have some misunderstanding about "Sketched the frame", "Do not like it - I will remake everything for free." I repeat - the customer thought with stereotypes and patterns that developed as a result of operating unsuccessful systems. If everything suited him, then he would not have asked for the development of a new product.
  Actually there were three options. The first is to immediately do what the customer requested and get another clone. However, I am not very sure that the client would be satisfied. Most likely, at the implementation stage, he would understand that he exchanged an awl for soap - he got the same that he had, but with some changes. Most likely, this would leave him an unpleasant aftertaste and discourage the desire to cooperate further. And, even more so, he would not recommend the developer to his colleagues. The second option is to put pressure on the customer and prove with foam at the mouth how smart I am and how stupid he is. I hope everyone understands that this is a dead end - the customer is working in this business and since he has not yet gone broke, then he understands something in it. Therefore, the third way was chosen - to offer the customer a “zero option” and take responsibility. In this case, the risk was minimal since, I repeat, already had significant positive experience in this industry. It was from here that the “sketched frame” appeared, “I won’t like it - I’ll remake everything for free.” Only an example can convince a customer. This example is the "sketched frame." And “redo everything for free” is a guarantee for the customer that he will not be a victim of the ambitions of the developer. If someone knows what else there are ways to convince the client, I will listen to them with pleasure, since in no way I claim either absolute truth or even originality.
  Now about "custom development for one specific customer." First of all, it was freelance. If someone needs a typical system, he buys it from large and fat manufacturers, and does not turn to a freelancer. A freelancer is contacted when a specific product is needed. So this, by definition, was supposed to be "work for one specific customer." And secondly, of course, I had blanks, ready-made modules and a lot of developments from previous projects. And the results of the described project were repeatedly used in the future. Yes, maintaining uniqueness is then not easy. But they pay money for it. An alternative is to enter the path of direct competition with typical systems and large manufacturers, and this is suicide for small developers. It’s the same as rushing to compete alone with 1C with a cry of “Hurray!” - no chance.
  And a little more on the technical side. This project (like most others) was written under Windows on Delphi. Since this language allows you to develop interactive applications with minimal time. C ++ - difficulties with visualization, it is more difficult to support projects, more difficult to debug. .NET at that time was something with obscure prospects (and time has shown that abandoning .NET was the right decision). Java at that time was too slow and "wretched". At the moment, I would write that program in Delphi or Java (depending on customer requirements). This was used as the database server by Firebird, since it best ensures the maintenance of data integrity (with the correct description of the structure and the correct use of transactions). After about five years of continuous operation without maintenance on an office computer without a UPS (moreover, the computer was often turned off simply by turning off the surge protector!), No integrity violations were found in the database. Honestly, even at the moment I can’t imagine which of the other free products are capable of such a feat.

_{A small addition: I am looking for work - remote, regular, part-time or full-time, including all kinds of startups. Huge experience in the automation of everything and everything, in the management and development of projects. Controllers, hardware, automation, workstations, etc.}