About working with customers, developing and implementing software

I read how people are fighting with users of their software and decided to share their experience with the world. I will say right away that my experience is not small - at one time my programs were in great demand and I ate not one dog to support them. As a result, customers wrote boiling water, and users sabotaged any other software coming down from above, except mine. As a success story, I’ll give you a not too big gas station automation project. There was an order from the gas station for the development of the operator’s automated workplace. The task was to work with gas stations, cash register, print reports for accounting and various bosses and some internal specifics. Before me they had experience in implementing custom software, but the experience was negative - software was buggy, the operators quietly hated it, most of the reports were done on a piece of paper and a calculator, and the cash register was perceived as a kind of evil demon who needed to bring in reproaches and call technical support twice a week. The customer understood computers at the level of a very, very average user, was intimidated and rushed to write TZ, which was reduced to the description of some buttons on the screen and fonts in the reports in the complete absence of requirements for the logic of work. In short, the customer was afraid that they would do the next shit and tried to get bogged down in details in which he did not understand.

Stage one - to find mutual understanding with the customer.

First of all, work was carried out with the customer in order to reach an understanding and stop jerky throwing. It was pure politics and psychology. At first I explained to the customer that I was not going to “milk” or “throw” it. That I have some reputation, and I greatly value it. That reputation for me is worth more than money and that I am going to either do the job well or will not 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 in some issues I understand 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 again. In addition, I led the customer to the idea that he did not need to rush to write out TMRs, but it makes sense to first clarify his needs. That, perhaps, some things will be much better than he expects, and some are completely unnecessary to him, and instead of them we will add the really necessary functionality, but in any case, you should not make rash movements, and we will do the TK together. Shortly speaking:

1. Personally, I think that there must necessarily be some small preparatory or 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 it is clear that it is better to refuse to work than to contact a conflicting customer.
3. It is necessary to determine who and what decides at the customer, who to contact for some questions, etc.
4. It is necessary that the customer understands that money is not the main thing. The main thing is to be happy. And money is a payment for good work and its happiness. And that no one is going to deceive him.
5. Agree on a joint development of TK. Moreover, in this case, I write the TK, and the customer expresses his wishes in a free form and further approves the TZ. In any case, the TOR must be consistent. If some parts of the TK can cause difficulties, then it must be specified to avoid unpleasant surprises in the future.
6. The customer understood that there would be some pressure on my part; I will not implement some frankly delusional wishes, and I will do some things as I see fit. In exchange, the customer receives a kind of guarantee - if the decisions I made are wrong, they will definitely be corrected.
7. I will have some additional requirements - the ability to communicate with the staff who will operate the program, with accounting, the ability to ask many questions and the opportunity to have access to the facility during the development and 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 he personally would like from the software. Moreover, the customer was sent several times to “think further” until he began to clearly speak about his desires and these stories were not repeated. 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 had determined his basic desires. Then I went and talked to the staff several times. I listened to their wishes, expressed my suggestions. Looked at how they work now. I looked at the current software. I wondered what did not suit in the current software. Talked to the accounting department. Looked at the reports. He asked what was missing in them. Then with all of this again talked with the customer. He learned a lot of new things for himself - it turns out, from the point of view of the authorities, the working process looks quite different from the direct implementers. Total:

1. It is imperative that the customer decide what he really wants. Often, the customer initially comes up with thoughts of “green buttons” and “company logos on reports” and finds it difficult to formulate his desires even in general terms. If you do not let him "ripen", then the result may be that he wanted something completely different or did not want anything at all. Moreover, a “mature” customer, as a rule, is more interested in the product and perceives it as something really existing.
2. No need to completely remove the customer from the process of creativity. Sometimes I deliberately leave some time for later at the discretion of the customer, so that he has something to think about and express his weighty opinion. Sometimes this results in strange changes of an almost finished product, but the client is happy.
3. It is necessary to add a personal opinion about the technical process and talk to people who will directly exploit the system. They have very strange wishes, but in the end, this greatly increases productivity and the quality of the system.
4. 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 likes / dislikes competitors. Often, this is of crucial importance for the customer and it is there that lie the true reasons that led him to go for the development of new software.

Stage three - coordination of TZ.

Finally came the stage of direct writing and coordination of TK. The TK itself was set forth in a fairly free style with an absolutely minimal set of technical terms and maximum emphasis on functionality — only the general framework was set for implementation. There were several moments where our opinions differed dramatically from the customer. For some of these moments, we agreed that I would do it as I see fit, and if I were wrong, I would redo it for free. For some, several possible solutions were outlined; The final version will be selected later. And on several points I had to do two options - the customer stubbornly stood his ground, but I already had a very positive experience and I was sure that my option would win. And so it happened - at the demo version stage, the customer was shown mine and its options, and in two of three cases he chose my version and was happy as a child. At stages, the project was divided into the following stages:

1. Coordination of TK (in fact, it is almost over).
2. I am writing a technological layout of the program and testing it. Because the program had to work with iron, then it was necessary to check some solutions in place with access to the live iron.
3. I am writing a mockup of the program with basic functionality, showing it to the customer and testing it on hardware and on staff. According to the results, we are finally determined with unclear points of TK.
4. I give the first trial version, and we put it on test operation. The version will have the basic functionality, but I will refine some things and complete the exploitation campaign. At the same time I accept wishes in the framework of the TK. 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 finishing touches.
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 balance of the money during this period in exchange for the 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. Exact terms prescribed only for 5 and 6 stages. For the fourth stage prescribed a maximum period. Naturally, I have indicated the planned dates for all stages (with a considerable margin). Total:

1. The form of presentation of TZ is not so important, the main thing is to specify the main functionality and controversial points. Moreover, the controversial points are, in fact, that which is why TK must be made.
2. Once again controversial moments and potential difficulties. Even if they are negotiated orally, this will further make it possible to quickly find a common language in case of unforeseen problems.
3. Deadlines should be laid with a margin and indicate exactly what changes are possible at each stage.

Any notes on how to make a product popular:

In the project itself, I focused on ergonomics and resiliency. The basic rule is that with this program a person should work for days without 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 the ranks and regalia. Then let him sit for the program of another person and let her sit and work. And if something is inconvenient for him, then rule, regardless of any considerations of common sense. There should not be any excuses, like “it was conceived wrong” or “it does not fit into the concept”. Controls can be duplicated five times if they are used frequently. They may be in the most unexpected places, if the user expects to see them there. All fonts should be such that after a day of stubborn stare at the monitor they can still be seen. Even if it is not kosher - as many fonts and their sizes as needed. And once again - no bright colors. Watch until it recovers. And when she does, edit, so as not to rock. Then give the end user, sit down and sit for 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 in his workplace. You will immediately see where you want to edit. If a 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 made it possible not to be distracted from the screen and not to throw the mouse. In some places, it was necessary to duplicate the functions in a most non-trivial way - the user felt that if "poke this icon here, then something should happen." specified time or should pop up a reminder. If the user is often sealed somewhere, there should be an opportunity to correct the situation. If the user writes something on a piece of paper when 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, an icon and an inscription. Better yet, ask how he thinks it should work. That's when everyone likes everything, you can lick the design. But then again, double-check everything for ergonomics. And so that nothing can be spoiled. It is fundamentally. The user should not be able to spoil anything. It is useless to write instructions. It is necessary to recheck everything ten times in the program, display warnings and dialogues, and so that in each dialogue the answer by default is set to a safe position. The program should work without service for years. Reports should be such that any fool can understand them. If necessary, duplicate the numbers and columns in the tables. Duplicate tables. Print explanations and notes if strange results are issued. In short, the interface in the working software should go from the user, then from the process and only then from the author’s thoughts and ideas and design. If users write boiling water from the program interface, they will be ready for all and competitors there will be no chance, no matter what functionality and at what price they would offer. If the customer feels that his dreams are being fulfilled, he will always be ready to meet.

One more note about the instructions.

As life experience shows, deployed help in the program is practically useless. More help simple available instructions for each form. But even with this no one will ever use. You need to make tooltips and status lines. You need to write a few 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 "question-answer". And the most accessible and understandable language. In these manuscripts to contribute all the questions that are asked more than one or two times during the implementation phase. Separately make instructions with secret knowledge for advanced users. Users will pray for these pieces of paper. You need to start the implementation by training one or two of the most intelligent users. Then they need to be involved in the process - as experience shows, users are much faster and easier to teach each other than they can be taught from the side. It’s necessary to think about those who will support this system. For all kinds of administrators you need to write a clear instruction. You need to write in the calculation that there will be a person who understands computers, but who is absolutely and categorically lazy to delve into anything. This man was kicked out of a chair, perhaps even on a day off, and with the wording "the program does not work as it used to be," was thrown into the embrasure. It is necessary that he quickly found in the instructions of his problem and how to solve it. Let the solutions be not optimal, the main thing is that they can be easily repeated without digging into the giblets of the program. The optimal style of presentation is a small introduction to the structure of the system, in case you still have to dig into the guts. Then a list of possible difficulties in the form of "If-then" and a section describing some of the rare official operations. It is advisable to pre-make scripts or programs for archiving / unzipping / restoring and other administration. Sabotage by technical support is a terrible thing. And here, if tech support is on your side, then it saves a lot of nerves and time. In short, everything should be accessible and understandable and designed for a person who performs some simple everyday activities, not much delving into the secret meaning of what is happening. Everything must be duplicated in paper form and in place. 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 in terms of performance, 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 payment from the customer and post-warranty support, but this is a separate topic. Update :

A small Huge addition at the request of workers.

   I did not specifically go into the details of the project, since the text was already quite large, yes, and these details are beyond the scope of the indicated topic.  But here in the comments and inbox people need details.  In order to observe at least some consistency and consistency of the text, I decided to add a small addition and issue it in the form of a response to the comment of the user “belnetmon” - I hope he will not mind.

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

    This is not an "opera day" - this is quite a successful freelancing experience.
    About the fact that covered the project - there was the task of automation of gas stations.  As I mentioned at the beginning of the text - the management of gas stations, working with the cash register, issuing a variety of reports.  Logically, this is working with the cash register (cash management), selling fuel with its specificity, working with payment cards (personal and bank), selling related products, accounting for fuel, exporting data to accounting, etc.  All of this was superimposed by the specifics of fuel trading - a lot of options and methods of payment, a lot of potential emergency situations, work shifts, contradictory requirements of our legislation, etc.  In fact, after the introduction of the program, the only thing people worked with at the gas station, and this imposed very strict requirements on ergonomics - the operator had to look at the screen for 24 hours and repeat the same operations thousands of times a day.

    What about fuzzy initial requirements.  The situation was not quite like that.  I repeat - at that time there was already a great 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 templates.  The customer came due to the fact that everything on the market was either not convenient or did not have the necessary functionality.  In the course of working with the customer, he was shown new approaches and opportunities - as a result, he realized that there is an opportunity not only to make a clone of someone else's product with small changes, but a new full-fledged system.
 And it seems to me that many readers have some misunderstanding about the "sketched frame", "Do not like it - I will redo everything for free."  I repeat - the customer thought the stereotypes and patterns that have developed as a result of the operation of unsuccessful systems.  If everything suited him, he would not have applied for the development of a new product.
   Actually there were three options.  The first is to immediately do what the customer asked for 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 had exchanged a flea mark - he got what he had, but with some changes.  Most likely, this would leave him an unpleasant aftertaste and discourage the desire to cooperate further.  And, especially, he would not recommend the developer to his colleagues.  The second option is to put pressure on the customer and with foaming at the mouth to prove how clever I am and how foolish he is.  I hope everyone understands that this is a dead-end path - the customer is working in this business and if he has not collapsed yet, then he understands something about it.  Therefore, the third way was chosen - to offer the customer a “zero option” and take responsibility for themselves.  The risk was minimal since, I repeat, there was already a significant positive experience in this industry.  It was from here that “sketched frame” appeared, “I don’t like it - I’ll redo it for free”.  Only an example can convince the customer.  This example is the "sketched frame."  And “I will redo everything for free” - this is a guarantee for the customer that he will not be a victim of the developer’s ambitions.  If someone knows what other ways there are to persuade a client, I will listen to them with pleasure, since in no way do I claim to be absolute truth, or even originality.

   Now about the "customized development for one specific customer."  First of all, it was freelancing.  If someone needs a typical system, he buys it from large and fat producers, and does not turn to a freelancer.  Freelancers are turned to when they need a specific product.  So this, by definition, should have been “work for one particular customer”.  And secondly, I certainly 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, to maintain the uniqueness then it is not easy.  But for this money is paid.  The alternative is to enter the path of direct competition with typical systems and large manufacturers, and this is suicide for small developers.  It's like that, with a shout of "Hurray!" To rush alone with 1C to compete - no chance.  In short, freelancing relies on individual work with the customer and unique offers.

   And a little more technical.  This project (like most others) was written under Windows on Delphi.  Since this language allows you to develop interactive applications with minimal time costs.  C ++ - difficulties with visualization, harder to maintain projects, harder to debug.  .NET at that time was something with incomprehensible perspectives (and time has shown that the rejection of .NET was the right decision).  Java at that time was too slow and "miserable."  At the moment I would write that program in Delphi or Java (depending on customer requirements).  As a database server, this was used by Firebird, since it best of all ensures the maintenance of data integrity (when the structure is described correctly and transactions are used correctly).  After about five years of continuous operation without maintenance, the office computer without UPS (moreover, the computer was often turned off simply by turning off the power filter!) No integrity breach was found in the database.  Honestly, even at the moment I cannot imagine what other free products are capable of such a feat.

_{A small addition: looking for a job - remote, regular, part-time or full-time, including all kinds of start-ups. Vast experience in the automation of everything and everyone, in the management and development of projects. Controllers, hardware, automation, automated workplaces, etc.}