The production of happiness by industrial methods
My article will present a larger collection of life stories and some conclusions from them. The main problem that worries me now is how to make sure that both customers and developers were satisfied, and the profit was good and karma. I do not have a specific final recipe, there are several negative examples and intended goals that I want to share.
I have been developing since 2003 (mostly web applications), before that, for 4 years I taught in OmSU the basics of programming for the 1st year of the Faculty of Mathematics. At the moment I have the 3rd year as a co-owner of my own small outsourcing company. I will talk exclusively about my experience for two reasons: I managed to visit three different types of companies that I can compare, and I think that the retelling of someone’s experience does not give a complete picture.
Maybe for someone I will look like this:
At the end of 2003, on the one hand, I realized that I really lacked real development practice, since one teaching and learning tasks do not give a full picture of the life of the industry, on the other, the question of earnings rose to its full height. The problem of the isolation of programming teachers from life is known to all firsthand. This is one of the reasons for the opinion that is constantly exaggerated among programmers that studying at a university is absolutely useless and you just have to go and start working. I can talk on this topic for a long time, so now I’ll just say: I disagree with this opinion, and leave the discussion for later. I decided that I had to go, gain experience in practice and then return to the university already possessing a certain amount of knowledge in order to bridge the gap between academic education and industry needs.
This was expressed in the fact that since 2009 I have been reading in OmSU a special course for 3-5 year students called “Modern Software Development Practices”, where I teach them in practice many of the skills that are required in real work and which are not enough for fresh graduates when they are looking for their first job. In particular, these are: teamwork, development processes, tools (version control systems, automated assemblies, task trackers, continuous integration). A lot of attention is paid to writing high-quality code, sensible documentation and logging, unit testing, etc. As part of the course, students perform a team project for 2-3 people, using various web frameworks in Java, Python and Ruby, which we also compare with each other along the way.
So, in 2003, I quit Omsk State University and got a job in the software development department of a fairly successful company engaged in the design of oil and gas pipelines, where I was engaged in the automation of internal work.
At that time in Omsk, it was one of the largest taxpayers. In addition - there were 2 large software development departments for internal automation. One of them even developed software for an external customer, Transneft. There, I learned what internal staff policy is and how it all collapses with the transfer of control to people who did not create a company, but simply invested in a ready-made company, having received a controlling stake. Reading much later the book “The Human Factor” by Di Marco and Lister, I laughed through tears when they described a similar situation where completely demotivated people quit, and those who have not yet quit are sitting and thinking: “Everyone has already left, only I I'm still an idiot, I'll go, I'll quit, too, and burn with a blue flame. ”
In 2009, against the backdrop of the departure of a huge number of excellent design professionals and surveyors — the basis of the company — I received an offer to work in an emerging outsourcing company, which at that time consisted of less than 10 people.
I was the 3rd developer to go there. I was immediately alarmed that there were only 3 developers, but on the staff, not counting the general director, there is a lawyer, a marketer, a personnel officer, an accountant and a project manager. Unfortunately, the sad history of this office in the end turned out to be quite a bit connected with a similar distribution of posts throughout its existence.
The most anecdotal was hiring a resource manager, when profitability was already on the verge of a foul, which pestered everyone every day with countless questions, what we do and we could not use the half hour that we suddenly formed to help the guys on another project . I think, programmers do not need to explain what this led to. To explain to the management that these measures are meaningless, we did not succeed then.
Nevertheless, it was here that I got a very interesting experience in communicating with foreign customers and also thanks to my friend Michael Podgursky ( hambrauzer kmmbvnr ) - who kindly allowed me to use my profile slogan as the topic of the report - significantly expanded the range of technologies that I don’t know deep I have a very good idea in order to assess the applicability of one or another approach to solving the problems set by customers.
In 2010, our notorious company, far beyond Omsk, collapsed and was declared bankrupt, the customers we worked with at that time were very discouraged by this state of affairs and asked the developers who worked with them to continue without an office. So, several freelancers were born in Omsk, including my current small company started with this order, which we worked on until the end of 2011.
In parallel with the organization of my own company, I got a job in one of the largest outsourcing companies now not only in Russia, but also in Europe.
It was everything: large customers, fairly high salaries by Omsk standards, full social package. On that project, where I worked, - peace and quiet, no hard work for you, no overtime. On the contrary - often I had to figure out what to do. The situation is best illustrated by the following picture:
')
The paradox is that there really is a fairly large number of very good programmers. One of them, which was our timlid, in my opinion the best of those with whom I had to work ever. And they do not leave, they just find what to do besides the main work. For example, they give a lot of valuable advice to beginners who constantly refer to them.
However, I got a rather boring project, about which the story below, I saw less and less from my work there, and it became more and more difficult to combine the management of the company and my own hired labor. Therefore, in January 2011, I finally decided to quit and finally do only my own company.
There is not much of us in the company, we don’t have - except for me and Ivan Nemytchenko ( habrayumer nem ) - no managers, an accountant at an outsourcing, no personnel officers and resource managers. In this, of course, there are pros and cons, but for now we live like this. Ivan and I are still writing code, designing web applications architecture, conducting internships, managing projects as managers, and communicating with customers. It looks like this (there were no pictures with a lot of tools, which is a pity):
Sometimes even like this:
Apart from the fact that I managed to get an idea of ​​different types of custom development, I took part in start-up parties, Ivan and I worked through several of our ideas, tried to start a couple of startups - not yet too successfully for obvious reasons - besides creating the actual code, all this is also to promote and attract users, for which we currently do not have the resources.
The team and I regularly attend various IT conferences in Moscow, Novosibirsk, Yekaterinburg, and Samara. And recently, I began to be tormented by one question that I constantly want to ask the speaker, who talks about general approaches to the development process, about some use of a combination of technologies, etc. etc .: “Okay, this is all great, and what problem of the customer did you solve with that?”.
Maxim Tkachuk, a speaker from codefest-2012, finished off with his report “Hard rock design” codefest.ru/program/2012-03/hard-rock-design . It is a pity that his report was declared to the PM + HR section and not all the developers who were there, but mostly managers and designers, came to listen to him. And he talked about that - from his bell tower, of course - that the designer should take part in the whole process of working on the project, starting from the initial collection of requirements, take a proactive stance, deeply understand the purpose of the product being developed and the audience of users (consumers). He spoke very emotionally, it was felt that the problem had been won through and constantly had to deal with designers who did not understand this. And I was sitting in the hall and mentally changing the word “designer” to “developer”, “tester”, etc.
Actually, the very problem that was finally formulated for me only recently sounds like this: the majority of the team members do not want to delve into the problems of customers and users, and the management and customers do not consider it necessary to inform the team about many aspects of the problem being solved, considering it optional.
Symptoms of a problem are:
● the customer believes that the team is not obliged to know about some problems involving users, funding, ongoing presentations, etc., the team’s job is to write code, and about other business people should have a headache about business issues;
â—Ź at the beginning of negotiations on a project, the customer is more interested in having formal certificates like CMMI, than meeting with real team members, often prefers to communicate only with the manager and analysts;
● the developers say: “I just want to write code, give me a clear task and I’ll do it. About the customer’s problems, let the analyst and the manager have a headache ”(“ telepaths on vacation ”);
â—Ź the team acts according to the principle: we do exactly what we have been asked for, we will be paid, and then it does not concern us;
â—Ź managers consider developers to be separated from life by creatures who need to be entertained and motivated somehow, since their main job is mortal boredom and special measures are needed to keep them from soured;
â—Ź the developers themselves consider most of the work as boredom to be mortal, and to preserve motivation, they engage in third-party open-source projects and small startups aimed not only at earning money, but at getting a breather from the routine;
â—Ź project development is accompanied by a ton of documents, but most ordinary employees are not able to describe typical users of the product and have never seen them;
â—Ź communication between any representatives of different roles resembles a battlefield;
â—Ź a representative of any role can immediately tell what exactly he is dissatisfied with in the work of the manager and representative of any other role in the team;
â—Ź first of all, each member of the team can formulate someone else's responsibility and only then call his own;
â—Ź The first and main task of any team member is to cover one place with a skillet by overestimating and discarding responsibility for failure to others.
Implications for the team (long term):
â—Ź motivation is reduced to a critical point, no one seeks to make a task as best as possible;
● any decisions are made on the principle “just not to fly”;
â—Ź in severe cases, decision-making is accompanied by several stages of signing the papers;
● no initiative to improve the code, architecture, internal processes is welcomed; in most cases, the initiator receives the question “do you need the most?”;
â—Ź at the earliest opportunity, the most promising team members change the project;
â—Ź monetary and career becomes the only motivation; for a long enough period, the team can gather the most mercantile opportunists or those who are not interested in anything but a stable salary and the opportunity to go home at 18:00.
Implications for internal management:
â—Ź special measures are needed to control the implementation of tasks;
â—Ź over the long term, the most enterprising leave the team, those who remain are no longer taking out;
â—Ź Responsibility for meeting deadlines rests primarily with the manager, the only reason to motivate the team is to prevent a breakdown with the carrot and stick.
Implications for customer management:
â—Ź the customer repeatedly overpays for excessive periods and staff turnover;
â—Ź the quality of the product is excellent only for the papers, in fact, the code and architecture can be terrible, therefore the customer overpays for the unsatisfactory quality;
â—Ź if users are a wide circle of people voluntarily choosing a product, their number may be reduced for the reasons set out below.
Implications for end users:
â—Ź there is no direct contact with the performers and the ability to quickly give feedback;
â—Ź needs are not fully met, most often users have to be specially trained to use the product, since it is far from their standard yuskeys;
â—Ź the order and deadlines for completing tasks for adding new functionality does not meet the needs of users.
To illustrate the above, I will talk about some of the projects that I had to work on as a developer or manager.
So, the company engaged in the design of trunk pipelines. The software development department was given the task to write a small program for the environmental department. Initial data:
A little more about the department:
Written its own library of 2D graphics, in 3D plans (in the courtyard already OpenGL and all that). It has its own clever data storage structure - a combination of a linked list and a direct access structure, i.e. array. A very low-level approach is used for access, there is no abstraction at all, continuous address arithmetic, not only in giblets, but also at the API level. Your grid is written, which receives an address in the memory at the input and takes all its data using address calculations relative to this beginning. A shift somewhere inside in 1 byte destroys everything. The most epic is its name: “myGrid”.
The young fighter is to me, they propose to use all this as components of a future program on the Builder, which will replace the current zoo of Excel calculations. Customers - aunties from 45 and above (chiefs) and girls about 25 (ordinary performers) - think exclusively in the categories of calculations, which they perceive as unrelated parts and, from their point of view, development is incremental - the calculations are repeated one by one and take approximately same time.
For about a month, I honestly did everything on the Builder, the data entered through the mega-grid got into the mega-structure in memory, which, when saved to disk, was simply thrown off as is in a binary file and then rose when reading from a file into memory as is. But I rebelled. She stated to the head of the department that the task frankly implies the use of a database - especially considering the required multi-user mode. Another month of fighting and I got permission. Just going to create a corporate information system (EIS) on Java + Oracle and I got the opportunity to make the system as part of this EIS.
The more I immersed myself in the task, the more I understood that the calculations were not only interconnected, so the data for them, for the most part, is either in various regulatory and reference books, or comes from employees of other departments. There was an understanding of what kind of system environmentalists really need, and it was a little like what they described. I stuck out in their department, asked questions that went far beyond the calculations I was given, and as a result I gradually penetrated into the mechanics of the work of the entire institute.
I did what they really needed, much more than what they asked for, but it took much longer than expected at the beginning. Half a year for the first version with the base calculation for the rest, and 2.5 years to complete. During this time, I was almost fired for the lack of a visible result in the first 1-2 months (I don’t remember exactly) and the relationship with the head of the department and the then director of IT, who was not from programmers, but from design engineers, was significantly damaged.
Then I began to hammer down the bosses' thresholds, trying to start the process of automating and building a model of the entire process of research and design, because at that time, as I imagined, I was practically the only person who purposefully studied the work of all departments of the institute in terms of input and output data at the level of the digital model of the project. There was also a KIS department, but they were more interested in the types of text documents, and the drawings were viewed as ordinary binary files. For me, the main one was the model, and all the drawings and text documents are just reports that can be built at any time, having a model.
As a result, this global system did not appear for a bunch of reasons of a bureaucratic and economic nature, and I quit. By the way - piecewise automation of this process is available in other design institutes, and one of the IT companies earns from a commercial product that covered at the time of my last knowledge about it (2010) 60 percent of what I imagined in 2006. There are some more products covering survey work (geodesy, geology, etc.) that use the model inside, and drawings in AutoCAD format are received as a report. But they, unfortunately, do not have a continuation in the design of the pipeline.
Let's return to the task. It seems that everything was done correctly - users received a product that satisfied their needs even more than they could expect. But. They got it much later than they wanted. How did this turn out for them? Large losses of time on the routine and as a result - overtime work for an extra year.
What mistakes were made:
1. Collect requirements by interviewing superiors and examining Excel files.
2. The choice of a little-studied development technology at that time, which delayed the appearance of the first version.
3. Attempt to make the first version of the system immediately mega-universal.
The global cause of all these mistakes was that I was too carried away with my goals, forgetting about the goals of the customer. I wanted to make a good and universal system, at the same time studying new technologies for me. And the customer just wanted to reduce the time to complete the calculations and go home on time.
What a perfect spherical developer should have done in a vacuum:
1. To start with the study of the business domain by fully immersing in the work of the department for some time in order to study all the processes from the inside up to the implementation of the basic functions of an ordinary employee of the department independently.
2. Within a week, a maximum of two, write several macros in Visual Basic, which would ensure the use of the results of some calculations as source data for others, as well as digitize the most frequently used reference books in Excel, which would accelerate the work by about a third.
3. Having a partially happy customer nearby, quietly develop a real system, already understanding all the yuskeys and main risks, which would speed up the development process also by no less than a third.
At first glance, the example does not fit into the above problem and symptoms. At second glance, it is. Since there has been a developer who is very motivated to study the customer’s problems and attempts to solve them in the best possible way (not counting the initial error with macros, more precisely, with their absence). The problem is that everyone else who was around was completely unmotivated to improve the overall situation in the company. The question is whether I really need the most I heard regularly. And at one point, patience is exhausted.
What are the conclusions from this whole story?
1. Users need to know in person. And not only the manager and business analysts, but the whole team.
2. In the process of creating functional and interface requirements, the entire team should participate to the maximum.
The presence of these conditions will give the team the opportunity to show creativity, and a personal acquaintance with the users and their tasks will allow them to solve these problems in the best possible way. When a user is abstract and impersonal, no one puts a soul into a product for him.
But what to do in cases where there is no access to the real user?You can have a rubber user. Joke, of course. To do this, invented a special practice to develop portraits of users. The team creates a real portrait of a person, with a name, age, profession, even habits, as well as fears that may arise when using the product, and what benefits this product can bring to them. There are game moments, jokes, internal memes. Practice shows quite well at AgileCamp training from Scrumtrek.
On the topic of acquaintance with users and studying their specific needs, I can name two more cases. Just recently, we were sitting in the office of the customer and had the opportunity to communicate with live users of the future system. And the girl interface designer repeated the phrase several times: “Oh, well, how cool it is that you can talk to users like this! Usually, you do not know who it is and how exactly they will end up using the product. ”
Actually, the thing was that while we were communicating with the customer’s management, they offered to make a super-universal analytical system that would allow to show charts and summary data on any imaginable sections and something like a great Excel, in which users now work with tables charts. It so happened that we flew to Moscow and gathered together to discuss the actually finalized demands and sign the contract. There were 2 problems: on our part, the lack of a clear understanding of the timeline, since a certain universal thing is more difficult to assess, the requirements are more vague, and from the side of the team that develops the user interface - the feeling that such a universal interface will not be necessary and incomprehensible to most users.
From the very beginning we were going to offer to invite end users and stand with them at the blackboard with stickers and markers, conduct story-mapping (again, refer to AgileCamp from Scrumtrek). Although it did not work out, but nevertheless we invited users and talked to each of them, trying to understand what his main yaskeys and expectations were from using the system. The result of this was that the super-universality of the shallows and got some clear yuskeys, which closed 80% of the most important functionality. All this will allow much faster release of a working prototype that will already benefit the business.
A similar story happened quite recently with another of our customers. He is a good programmer who has become a technical director from some point. Therefore, he set us in fact not a business problem, but offered specific architectural solutions. I tried to get us again, again, a super-universal and super-modular system that does everything. It was not possible to pull out any specific cases from it properly, and we also did not provide end users.
Half a year ago he was in Omsk and we spent half a day composing Lean canvas and doing Story-mapping. As a result, we chose a certain case for the first prototype and everything seemed to be going almost perfectly for the first few iterations. However, at some point, an unexpected demand suddenly arrived, about which there was not even a hint of story-mapping, to create some reference books: organizations, geolocations, etc. The team did not wonder why, and the customer did not consider it necessary to clarify. And after another 2 weeks, it suddenly became clear that the customer had an urgent, important event on hand that he needs a product to prepare for. He wanted to put the users in advance to fill the system with data in order to be in time, but since he had not warned about this in advance, the system was not ready for the users to work precisely for the specific needs that they needed at the moment.
What are the conclusions from these two stories:
1. It is necessary not only to know your users by sight, but also to get information from them about the most important options for using the system, which cover 80% of their needs and should be implemented first.
2. It is better to limit the influence of technical management on the part of the customer as much as possible;insist on communicating with people from the business and end users to better understand the goals of creating the product.
3. It is necessary to ask the customer questions regarding the timing of the scheduled demonstrations or other important events, since he may not think about it himself. It is important to understand that sometimes the date of occurrence of an event when the product will be used for display must be preceded by a week or two for alpha testing by end users.
Immediately after the design institute, I worked in a small outsourcing company, which was stupidly bankrupt afterwards, in which one of the first tasks we had with the manager jointly zafakapili. The system consisted of two parts: recording a video stream from surveillance cameras with streaming in two modes - online and in recording - and a web admin to configure camera settings, systems for storing recorded video and all sorts of event notifications.
The manager knew that we have one big technical risk - recording and streaming video. There were serious concerns that in a month the developer would not have time to study the formats of the main cameras and write something digestible to demonstrate to the customer the possibility of recording a video stream. Therefore, he hoped that I would quickly rivet the admin panel, which could blur the eyes of the customer, he would be fascinated by comments and wishes and forget about the video for a while, which would give the second developer time for maneuver.
However, all these considerations were only in the head of the manager. The developers saw the deadline - 3 months - and did not particularly worry. With the customer personally, we almost did not communicate, the manager was engaged in it. Before us, the information was already conveyed in the form of orders, with which we argued and in some places we did it in our own way, delaying the deadlines set by the manager. We certainly would have met the general term (plus or minus, of course). But we didn’t have any working system in the promised month, since both I and the second developer pursued my goals, not caring too much about the customer - for us he was just a nickname in Skype and email. Therefore, I have chosen to develop a new framework for me to kill two birds with one stone. The manager didn’t stop this business, although he suspected that I wouldn’t be able to meet the deadline with the study.
As a result, the authority of the manager and the company was, in general, strongly shaken in the customer's eyes, interruptions in communication began, the first money tranche was deposited.
It could be said that the problem is the lack of a proper development process. That would be saying scrum and happiness would come. However, the matter here is still not in the process itself or its absence - we had iterations with the described procedure with any acceptance criteria - the fact is that we did not solve the customer problem all together. I definitely didn’t have a headache about the profits that were not received by the customer due to the deadline shift.
Considering the previous experience with environmentalists, I would absolutely like to penetrate and start thinking in the direction in which I would like not even the manager, but the customer, because the manager was still more interested in covering the filet with the pan than launching the prototype to test and perhaps even commercial use with disabilities. But - he did not file properly, but I did not show enough curiosity. The new framework with its technical features at that time interested me much more. His choice, too, was unsuccessful in the end, the study took an inadmissibly long amount of time. For this task, you could choose one of the dynamic languages ​​and a framework such as Django or Rails.
What are the conclusions from this story?
1. The team should be aware of all the risks and problems of the customer’s business (why should he launch it on these dates, exactly what functionality will suit him for the prototype).
2. The team should be aware of the motives of their own company (how important the project is for reputation, portfolio or financial well-being).
3. When discussing and choosing technical solutions, technical management should first of all be guided by business problems, and developers should explain that it is inhumane to practice with new frameworks on customers. That developers nevertheless did not lose interest in learning new, it is necessary to give some opportunities to apply new technologies, but on their internal projects or to give time for open source development.
This will lead to the fact that developers are no longer able to frankly ignore both the customer and manager, because they will feel to some extent in the same boat with both, knowing how much the project’s success will affect them as well. The project in the portfolio is a reason for pride, not to mention the possible improvement in the financial situation of the company and the specific developer.
Two weeks before the bankruptcy of a small outsourcer, I went to work in a branch of a large outsourcing company.
I got there interesting. I came for an interview just out of curiosity, in order to test my skills for compliance with the needs of a highly respected company in the city. And the interviewer completely fascinated me. We very nicely talked to him about various technical issues and I realized that he is very cool, he can learn a lot from him. He, as it turned out, also appreciated me highly enough that headhunters began to actively lure. The final decision was influenced by the fact that my interviewer would be the team leader of the development team that I had to enter.
I honestly warned the branch manager and manager that I have my own small team, which I will be doing in parallel, I received consent and began to join the team. A project team of 45 people, of whom less than a third of the developers surprised me a little. At the same time, there were significantly more testers, several dedicated analysts, each team has its own leader and over all - an architect, a project manager and a program manager.
The project turned out to be a long-lived. He existed for 30 years in Fortran, then in 2000-2001 he was rewritten, making a web project in Java + Oracle. At the same time, the appearance of the interface was fully preserved. Not so much because users are accustomed to it, but because no developer fully understood the essence of the system and what all these data entry screens mean. During the existence of the project in the company, more than 100 developers have changed on it, how many testers and analysts I do not know. As a result, there was not a single person in the team I got into who fully understood the system. Even analysts, who cheerfully poured me with incomprehensible terms, could not answer most questions about the goals and needs of users.
All this led to the fact that the development was carried out by the method of imposing patches. The system documents created by analysts and testers often did not correspond to the current state of the code, because not every developer had the patience to read them and execute everything written there. In some cases, the customer and the development team had two different pictures of the same functionality.
It was on this project that I observed most of the symptoms voiced by me above. My desire to understand the business domain was puzzling. After all, it is much easier to perform a small task, without delving into what supposedly does not concern her. But I was worried that the system in terms of usability was the worst example I have ever seen. The time for user training to work with it was enormous. The user had to keep in mind a huge number of permissible values ​​of parameters and their combinations, because the system did not give out any prompts and even validation of a huge form often gave out simply “Error!”, Overloading the page with clearing all the entered data, after which the unfortunate user had to enter All over again.
At the same time, mostly the people who worked on the project were technically very competent, versed in a huge amount of subtleties of used and related technologies. However, in the eyes of many, I saw anguish. The company, which brought together almost the best developers of the city, very strangely disposed of these resources. There were projects where a small development team and literally 1-2 testers worked overtime in continuous mode while we often wandered from corner to corner, not knowing what to do when the code went into testing, and the next iteration had not yet begun. But program managers at their meetings with all their strength kept their people, not giving them to those who were in dire need, because they understood that they might not be given back to them, even if it was necessary. Very many developers, sitting inside the company,earned on freelancing, spending on it the bulk of the work day.
The result was the departure of several rather initiative employees, who eventually took leading positions in the dynamically developing companies of the city or left it. They were ready to implement their ideas inside the previous company, but these initiatives were ignored by the management, because at a high level of management, the problems of the end users and even the internal problems of the development team are no longer visible.
For myself, I made the following conclusions, which in this case are largely controversial, since there will be a huge number of people who feel completely comfortable in a large hierarchically constructed structure:
1. In such a structure, a mass of people who prefer not to take responsibility and value “stability” become critical. This leads to the fact that in those rare moments when it is required to quickly and quickly storm a new project with drafts of bare heads, no one is ready for such an activity. Therefore, projects such as boring and long-playing come to such companies as those that are already under development.
2. If projects of a different type still leak out, everything seems to be fun and interesting at first. Most often, the developers there are newcomers or passionaries who have escaped from other projects. However, the neighborhood of half-asleep teams from other projects that are constantly going to chat in the corridors or to cook in the kitchen, or those who are obviously left working time very quickly makes you wonder - why should I actually work hard for wear when a lot of people get paid for which has a lot of free time. This reduces motivation rather quickly. Then people start to keep only salary and prospects for promotion. However, many people end up going to startups, small but fun teams or freelancing.
3. The proportion of happiness per head of the programmer population in small teams that do not have several levels of the management hierarchy is much higher. Personally, I like these commands much more. Being among people with burning eyes is much nicer. Therefore, I would not recommend to combine the mentioned types of teams and projects within one company.
4. The speed of reaction to the wishes of the customer in small teams is higher, which increases the level of customer happiness. Not every customer is ready to take a risk and hire a small but proud outsourcer. However, those for our happiness are.
Formula of
For me and my partner, it consists of the following components:
• Developing a product that is designed primarily to help users solve some very important problem, and making a profit is a side effect - just such a useful service cannot but become popular. Ideally, the product should be so interesting that they want to be engaged even for free in their free time. Therefore, the opportunity to work on it for money is real happiness for the team. Ideally, the product is your own.
• Small, but very high level skill team, in which there are simply no extra people. Everyone is an enthusiast and evangelist, in addition to his main work, he is actively engaged in self-development, maintains an educational blog, contributes to an interesting open source project, or makes his own.
• The team delves into the business of the customer or the problems of the end users to the extent that they are able to speak with them in the same language and view the product in terms of business value, adapting all the processes and technical solutions to the needs of the business / users.
• The customer is so adequate that he trusts the team in the selection of technical and process decisions, allowing her to decide how to meet the needs of the business within the designated budget.
• A large number of routine operations such as deployment and testing of diverse tests are automated so that the team has enough time to work on really interesting and complex things that require the application of the brain.
• The team has time to test the hypotheses ondogsprototyping and debriefing at the end of each development stage, sharing the experience of successful and unsuccessful decisions with other teams both inside and outside the company - for example, at conferences. If there is an opportunity to conduct parallel development of several solutions with the possibility of comparative analysis and the choice of the most successful in the end - this is generally a fairy tale.
A good selection in the style “Thank you, cap!”. Actually, for us this is still some kind of ideal, to which we are striving with all our might. In no case do I claim here the ultimate truth. There are a lot of successful companies in terms of profits, in which there is none of the points mentioned. Or stubs from one or two of them. But I want to emphasize that I am not talking about profit maximization, but completely about other things. This is a very philosophical moment. The money itself is not really needed. A bag of money on a desert island is useless. A person needs a feeling of happiness, which is given not by money as such.
Actually, the purpose of my speech at conferences and this article is to discuss with my colleagues the aspect of interaction between business and the development team, the urgency of the problem of misunderstanding and mistrust in this interaction. Therefore, first of all, I am ready to ask readers a question - is it relevant for you about what I said? Is there a desire to discuss these topics in more detail?
The question is not idle.We are going to hold a conference based on several other principles than the conferences we have attended the last couple of years. In particular: dump.it in Yekaterinburg, codefest in Novosibirsk, devconf in Moscow, agiledays and agilecamp. The conference is scheduled for September 29th.
The idea is to break the reports into sections not by specializations in the team: developers, testers, designers, managers, and not according to the technologies used. I would like to unite people into sections according to the types of business tasks, having considered specific cases in each section on each section. People working in enterprises, banks and other large companies are not interested in listening to those whose customers are start-ups with a limited budget, who need to quickly produce a prototype to get a round of investment or to test the hypothesis and measure KPI. I would like people to share among themselves the approaches to the organization of development processes and the choice of technical solutions, based on the needs of the problem being solved.
Thanks to everyone who took the time to read. I will be glad to any tricky questions and advice on the topic raised.
I have been developing since 2003 (mostly web applications), before that, for 4 years I taught in OmSU the basics of programming for the 1st year of the Faculty of Mathematics. At the moment I have the 3rd year as a co-owner of my own small outsourcing company. I will talk exclusively about my experience for two reasons: I managed to visit three different types of companies that I can compare, and I think that the retelling of someone’s experience does not give a complete picture.
Maybe for someone I will look like this:
About work experience
At the end of 2003, on the one hand, I realized that I really lacked real development practice, since one teaching and learning tasks do not give a full picture of the life of the industry, on the other, the question of earnings rose to its full height. The problem of the isolation of programming teachers from life is known to all firsthand. This is one of the reasons for the opinion that is constantly exaggerated among programmers that studying at a university is absolutely useless and you just have to go and start working. I can talk on this topic for a long time, so now I’ll just say: I disagree with this opinion, and leave the discussion for later. I decided that I had to go, gain experience in practice and then return to the university already possessing a certain amount of knowledge in order to bridge the gap between academic education and industry needs.
This was expressed in the fact that since 2009 I have been reading in OmSU a special course for 3-5 year students called “Modern Software Development Practices”, where I teach them in practice many of the skills that are required in real work and which are not enough for fresh graduates when they are looking for their first job. In particular, these are: teamwork, development processes, tools (version control systems, automated assemblies, task trackers, continuous integration). A lot of attention is paid to writing high-quality code, sensible documentation and logging, unit testing, etc. As part of the course, students perform a team project for 2-3 people, using various web frameworks in Java, Python and Ruby, which we also compare with each other along the way.
So, in 2003, I quit Omsk State University and got a job in the software development department of a fairly successful company engaged in the design of oil and gas pipelines, where I was engaged in the automation of internal work.
At that time in Omsk, it was one of the largest taxpayers. In addition - there were 2 large software development departments for internal automation. One of them even developed software for an external customer, Transneft. There, I learned what internal staff policy is and how it all collapses with the transfer of control to people who did not create a company, but simply invested in a ready-made company, having received a controlling stake. Reading much later the book “The Human Factor” by Di Marco and Lister, I laughed through tears when they described a similar situation where completely demotivated people quit, and those who have not yet quit are sitting and thinking: “Everyone has already left, only I I'm still an idiot, I'll go, I'll quit, too, and burn with a blue flame. ”
In 2009, against the backdrop of the departure of a huge number of excellent design professionals and surveyors — the basis of the company — I received an offer to work in an emerging outsourcing company, which at that time consisted of less than 10 people.
I was the 3rd developer to go there. I was immediately alarmed that there were only 3 developers, but on the staff, not counting the general director, there is a lawyer, a marketer, a personnel officer, an accountant and a project manager. Unfortunately, the sad history of this office in the end turned out to be quite a bit connected with a similar distribution of posts throughout its existence.
The most anecdotal was hiring a resource manager, when profitability was already on the verge of a foul, which pestered everyone every day with countless questions, what we do and we could not use the half hour that we suddenly formed to help the guys on another project . I think, programmers do not need to explain what this led to. To explain to the management that these measures are meaningless, we did not succeed then.
Nevertheless, it was here that I got a very interesting experience in communicating with foreign customers and also thanks to my friend Michael Podgursky ( hambrauzer kmmbvnr ) - who kindly allowed me to use my profile slogan as the topic of the report - significantly expanded the range of technologies that I don’t know deep I have a very good idea in order to assess the applicability of one or another approach to solving the problems set by customers.
In 2010, our notorious company, far beyond Omsk, collapsed and was declared bankrupt, the customers we worked with at that time were very discouraged by this state of affairs and asked the developers who worked with them to continue without an office. So, several freelancers were born in Omsk, including my current small company started with this order, which we worked on until the end of 2011.
In parallel with the organization of my own company, I got a job in one of the largest outsourcing companies now not only in Russia, but also in Europe.
It was everything: large customers, fairly high salaries by Omsk standards, full social package. On that project, where I worked, - peace and quiet, no hard work for you, no overtime. On the contrary - often I had to figure out what to do. The situation is best illustrated by the following picture:
')
The paradox is that there really is a fairly large number of very good programmers. One of them, which was our timlid, in my opinion the best of those with whom I had to work ever. And they do not leave, they just find what to do besides the main work. For example, they give a lot of valuable advice to beginners who constantly refer to them.
However, I got a rather boring project, about which the story below, I saw less and less from my work there, and it became more and more difficult to combine the management of the company and my own hired labor. Therefore, in January 2011, I finally decided to quit and finally do only my own company.
There is not much of us in the company, we don’t have - except for me and Ivan Nemytchenko ( habrayumer nem ) - no managers, an accountant at an outsourcing, no personnel officers and resource managers. In this, of course, there are pros and cons, but for now we live like this. Ivan and I are still writing code, designing web applications architecture, conducting internships, managing projects as managers, and communicating with customers. It looks like this (there were no pictures with a lot of tools, which is a pity):
Sometimes even like this:
Apart from the fact that I managed to get an idea of ​​different types of custom development, I took part in start-up parties, Ivan and I worked through several of our ideas, tried to start a couple of startups - not yet too successfully for obvious reasons - besides creating the actual code, all this is also to promote and attract users, for which we currently do not have the resources.
About the problem
The team and I regularly attend various IT conferences in Moscow, Novosibirsk, Yekaterinburg, and Samara. And recently, I began to be tormented by one question that I constantly want to ask the speaker, who talks about general approaches to the development process, about some use of a combination of technologies, etc. etc .: “Okay, this is all great, and what problem of the customer did you solve with that?”.
Maxim Tkachuk, a speaker from codefest-2012, finished off with his report “Hard rock design” codefest.ru/program/2012-03/hard-rock-design . It is a pity that his report was declared to the PM + HR section and not all the developers who were there, but mostly managers and designers, came to listen to him. And he talked about that - from his bell tower, of course - that the designer should take part in the whole process of working on the project, starting from the initial collection of requirements, take a proactive stance, deeply understand the purpose of the product being developed and the audience of users (consumers). He spoke very emotionally, it was felt that the problem had been won through and constantly had to deal with designers who did not understand this. And I was sitting in the hall and mentally changing the word “designer” to “developer”, “tester”, etc.
Actually, the very problem that was finally formulated for me only recently sounds like this: the majority of the team members do not want to delve into the problems of customers and users, and the management and customers do not consider it necessary to inform the team about many aspects of the problem being solved, considering it optional.
Symptoms of a problem are:
● the customer believes that the team is not obliged to know about some problems involving users, funding, ongoing presentations, etc., the team’s job is to write code, and about other business people should have a headache about business issues;
â—Ź at the beginning of negotiations on a project, the customer is more interested in having formal certificates like CMMI, than meeting with real team members, often prefers to communicate only with the manager and analysts;
● the developers say: “I just want to write code, give me a clear task and I’ll do it. About the customer’s problems, let the analyst and the manager have a headache ”(“ telepaths on vacation ”);
â—Ź the team acts according to the principle: we do exactly what we have been asked for, we will be paid, and then it does not concern us;
â—Ź managers consider developers to be separated from life by creatures who need to be entertained and motivated somehow, since their main job is mortal boredom and special measures are needed to keep them from soured;
â—Ź the developers themselves consider most of the work as boredom to be mortal, and to preserve motivation, they engage in third-party open-source projects and small startups aimed not only at earning money, but at getting a breather from the routine;
â—Ź project development is accompanied by a ton of documents, but most ordinary employees are not able to describe typical users of the product and have never seen them;
â—Ź communication between any representatives of different roles resembles a battlefield;
â—Ź a representative of any role can immediately tell what exactly he is dissatisfied with in the work of the manager and representative of any other role in the team;
â—Ź first of all, each member of the team can formulate someone else's responsibility and only then call his own;
â—Ź The first and main task of any team member is to cover one place with a skillet by overestimating and discarding responsibility for failure to others.
Implications for the team (long term):
â—Ź motivation is reduced to a critical point, no one seeks to make a task as best as possible;
● any decisions are made on the principle “just not to fly”;
â—Ź in severe cases, decision-making is accompanied by several stages of signing the papers;
● no initiative to improve the code, architecture, internal processes is welcomed; in most cases, the initiator receives the question “do you need the most?”;
â—Ź at the earliest opportunity, the most promising team members change the project;
â—Ź monetary and career becomes the only motivation; for a long enough period, the team can gather the most mercantile opportunists or those who are not interested in anything but a stable salary and the opportunity to go home at 18:00.
Implications for internal management:
â—Ź special measures are needed to control the implementation of tasks;
â—Ź over the long term, the most enterprising leave the team, those who remain are no longer taking out;
â—Ź Responsibility for meeting deadlines rests primarily with the manager, the only reason to motivate the team is to prevent a breakdown with the carrot and stick.
Implications for customer management:
â—Ź the customer repeatedly overpays for excessive periods and staff turnover;
â—Ź the quality of the product is excellent only for the papers, in fact, the code and architecture can be terrible, therefore the customer overpays for the unsatisfactory quality;
â—Ź if users are a wide circle of people voluntarily choosing a product, their number may be reduced for the reasons set out below.
Implications for end users:
â—Ź there is no direct contact with the performers and the ability to quickly give feedback;
â—Ź needs are not fully met, most often users have to be specially trained to use the product, since it is far from their standard yuskeys;
â—Ź the order and deadlines for completing tasks for adding new functionality does not meet the needs of users.
Stories from life
To illustrate the above, I will talk about some of the projects that I had to work on as a developer or manager.
So, the company engaged in the design of trunk pipelines. The software development department was given the task to write a small program for the environmental department. Initial data:
- o a department where everyone writes desktop applications to automate design and exploration work at Borland C ++ Builder;
- o a newbie who has just settled down and is able to write desktop applications that are not too complex;
- o Department of Ecology, which performs calculations of emissions of pollutants during construction works using a set of Excel tables.
A little more about the department:
Written its own library of 2D graphics, in 3D plans (in the courtyard already OpenGL and all that). It has its own clever data storage structure - a combination of a linked list and a direct access structure, i.e. array. A very low-level approach is used for access, there is no abstraction at all, continuous address arithmetic, not only in giblets, but also at the API level. Your grid is written, which receives an address in the memory at the input and takes all its data using address calculations relative to this beginning. A shift somewhere inside in 1 byte destroys everything. The most epic is its name: “myGrid”.
The young fighter is to me, they propose to use all this as components of a future program on the Builder, which will replace the current zoo of Excel calculations. Customers - aunties from 45 and above (chiefs) and girls about 25 (ordinary performers) - think exclusively in the categories of calculations, which they perceive as unrelated parts and, from their point of view, development is incremental - the calculations are repeated one by one and take approximately same time.
For about a month, I honestly did everything on the Builder, the data entered through the mega-grid got into the mega-structure in memory, which, when saved to disk, was simply thrown off as is in a binary file and then rose when reading from a file into memory as is. But I rebelled. She stated to the head of the department that the task frankly implies the use of a database - especially considering the required multi-user mode. Another month of fighting and I got permission. Just going to create a corporate information system (EIS) on Java + Oracle and I got the opportunity to make the system as part of this EIS.
The more I immersed myself in the task, the more I understood that the calculations were not only interconnected, so the data for them, for the most part, is either in various regulatory and reference books, or comes from employees of other departments. There was an understanding of what kind of system environmentalists really need, and it was a little like what they described. I stuck out in their department, asked questions that went far beyond the calculations I was given, and as a result I gradually penetrated into the mechanics of the work of the entire institute.
I did what they really needed, much more than what they asked for, but it took much longer than expected at the beginning. Half a year for the first version with the base calculation for the rest, and 2.5 years to complete. During this time, I was almost fired for the lack of a visible result in the first 1-2 months (I don’t remember exactly) and the relationship with the head of the department and the then director of IT, who was not from programmers, but from design engineers, was significantly damaged.
Then I began to hammer down the bosses' thresholds, trying to start the process of automating and building a model of the entire process of research and design, because at that time, as I imagined, I was practically the only person who purposefully studied the work of all departments of the institute in terms of input and output data at the level of the digital model of the project. There was also a KIS department, but they were more interested in the types of text documents, and the drawings were viewed as ordinary binary files. For me, the main one was the model, and all the drawings and text documents are just reports that can be built at any time, having a model.
As a result, this global system did not appear for a bunch of reasons of a bureaucratic and economic nature, and I quit. By the way - piecewise automation of this process is available in other design institutes, and one of the IT companies earns from a commercial product that covered at the time of my last knowledge about it (2010) 60 percent of what I imagined in 2006. There are some more products covering survey work (geodesy, geology, etc.) that use the model inside, and drawings in AutoCAD format are received as a report. But they, unfortunately, do not have a continuation in the design of the pipeline.
Let's return to the task. It seems that everything was done correctly - users received a product that satisfied their needs even more than they could expect. But. They got it much later than they wanted. How did this turn out for them? Large losses of time on the routine and as a result - overtime work for an extra year.
What mistakes were made:
1. Collect requirements by interviewing superiors and examining Excel files.
2. The choice of a little-studied development technology at that time, which delayed the appearance of the first version.
3. Attempt to make the first version of the system immediately mega-universal.
The global cause of all these mistakes was that I was too carried away with my goals, forgetting about the goals of the customer. I wanted to make a good and universal system, at the same time studying new technologies for me. And the customer just wanted to reduce the time to complete the calculations and go home on time.
What a perfect spherical developer should have done in a vacuum:
1. To start with the study of the business domain by fully immersing in the work of the department for some time in order to study all the processes from the inside up to the implementation of the basic functions of an ordinary employee of the department independently.
2. Within a week, a maximum of two, write several macros in Visual Basic, which would ensure the use of the results of some calculations as source data for others, as well as digitize the most frequently used reference books in Excel, which would accelerate the work by about a third.
3. Having a partially happy customer nearby, quietly develop a real system, already understanding all the yuskeys and main risks, which would speed up the development process also by no less than a third.
At first glance, the example does not fit into the above problem and symptoms. At second glance, it is. Since there has been a developer who is very motivated to study the customer’s problems and attempts to solve them in the best possible way (not counting the initial error with macros, more precisely, with their absence). The problem is that everyone else who was around was completely unmotivated to improve the overall situation in the company. The question is whether I really need the most I heard regularly. And at one point, patience is exhausted.
What are the conclusions from this whole story?
1. Users need to know in person. And not only the manager and business analysts, but the whole team.
2. In the process of creating functional and interface requirements, the entire team should participate to the maximum.
The presence of these conditions will give the team the opportunity to show creativity, and a personal acquaintance with the users and their tasks will allow them to solve these problems in the best possible way. When a user is abstract and impersonal, no one puts a soul into a product for him.
But what to do in cases where there is no access to the real user?
On the topic of acquaintance with users and studying their specific needs, I can name two more cases. Just recently, we were sitting in the office of the customer and had the opportunity to communicate with live users of the future system. And the girl interface designer repeated the phrase several times: “Oh, well, how cool it is that you can talk to users like this! Usually, you do not know who it is and how exactly they will end up using the product. ”
Actually, the thing was that while we were communicating with the customer’s management, they offered to make a super-universal analytical system that would allow to show charts and summary data on any imaginable sections and something like a great Excel, in which users now work with tables charts. It so happened that we flew to Moscow and gathered together to discuss the actually finalized demands and sign the contract. There were 2 problems: on our part, the lack of a clear understanding of the timeline, since a certain universal thing is more difficult to assess, the requirements are more vague, and from the side of the team that develops the user interface - the feeling that such a universal interface will not be necessary and incomprehensible to most users.
From the very beginning we were going to offer to invite end users and stand with them at the blackboard with stickers and markers, conduct story-mapping (again, refer to AgileCamp from Scrumtrek). Although it did not work out, but nevertheless we invited users and talked to each of them, trying to understand what his main yaskeys and expectations were from using the system. The result of this was that the super-universality of the shallows and got some clear yuskeys, which closed 80% of the most important functionality. All this will allow much faster release of a working prototype that will already benefit the business.
A similar story happened quite recently with another of our customers. He is a good programmer who has become a technical director from some point. Therefore, he set us in fact not a business problem, but offered specific architectural solutions. I tried to get us again, again, a super-universal and super-modular system that does everything. It was not possible to pull out any specific cases from it properly, and we also did not provide end users.
Half a year ago he was in Omsk and we spent half a day composing Lean canvas and doing Story-mapping. As a result, we chose a certain case for the first prototype and everything seemed to be going almost perfectly for the first few iterations. However, at some point, an unexpected demand suddenly arrived, about which there was not even a hint of story-mapping, to create some reference books: organizations, geolocations, etc. The team did not wonder why, and the customer did not consider it necessary to clarify. And after another 2 weeks, it suddenly became clear that the customer had an urgent, important event on hand that he needs a product to prepare for. He wanted to put the users in advance to fill the system with data in order to be in time, but since he had not warned about this in advance, the system was not ready for the users to work precisely for the specific needs that they needed at the moment.
What are the conclusions from these two stories:
1. It is necessary not only to know your users by sight, but also to get information from them about the most important options for using the system, which cover 80% of their needs and should be implemented first.
2. It is better to limit the influence of technical management on the part of the customer as much as possible;insist on communicating with people from the business and end users to better understand the goals of creating the product.
3. It is necessary to ask the customer questions regarding the timing of the scheduled demonstrations or other important events, since he may not think about it himself. It is important to understand that sometimes the date of occurrence of an event when the product will be used for display must be preceded by a week or two for alpha testing by end users.
Immediately after the design institute, I worked in a small outsourcing company, which was stupidly bankrupt afterwards, in which one of the first tasks we had with the manager jointly zafakapili. The system consisted of two parts: recording a video stream from surveillance cameras with streaming in two modes - online and in recording - and a web admin to configure camera settings, systems for storing recorded video and all sorts of event notifications.
The manager knew that we have one big technical risk - recording and streaming video. There were serious concerns that in a month the developer would not have time to study the formats of the main cameras and write something digestible to demonstrate to the customer the possibility of recording a video stream. Therefore, he hoped that I would quickly rivet the admin panel, which could blur the eyes of the customer, he would be fascinated by comments and wishes and forget about the video for a while, which would give the second developer time for maneuver.
However, all these considerations were only in the head of the manager. The developers saw the deadline - 3 months - and did not particularly worry. With the customer personally, we almost did not communicate, the manager was engaged in it. Before us, the information was already conveyed in the form of orders, with which we argued and in some places we did it in our own way, delaying the deadlines set by the manager. We certainly would have met the general term (plus or minus, of course). But we didn’t have any working system in the promised month, since both I and the second developer pursued my goals, not caring too much about the customer - for us he was just a nickname in Skype and email. Therefore, I have chosen to develop a new framework for me to kill two birds with one stone. The manager didn’t stop this business, although he suspected that I wouldn’t be able to meet the deadline with the study.
As a result, the authority of the manager and the company was, in general, strongly shaken in the customer's eyes, interruptions in communication began, the first money tranche was deposited.
It could be said that the problem is the lack of a proper development process. That would be saying scrum and happiness would come. However, the matter here is still not in the process itself or its absence - we had iterations with the described procedure with any acceptance criteria - the fact is that we did not solve the customer problem all together. I definitely didn’t have a headache about the profits that were not received by the customer due to the deadline shift.
Considering the previous experience with environmentalists, I would absolutely like to penetrate and start thinking in the direction in which I would like not even the manager, but the customer, because the manager was still more interested in covering the filet with the pan than launching the prototype to test and perhaps even commercial use with disabilities. But - he did not file properly, but I did not show enough curiosity. The new framework with its technical features at that time interested me much more. His choice, too, was unsuccessful in the end, the study took an inadmissibly long amount of time. For this task, you could choose one of the dynamic languages ​​and a framework such as Django or Rails.
What are the conclusions from this story?
1. The team should be aware of all the risks and problems of the customer’s business (why should he launch it on these dates, exactly what functionality will suit him for the prototype).
2. The team should be aware of the motives of their own company (how important the project is for reputation, portfolio or financial well-being).
3. When discussing and choosing technical solutions, technical management should first of all be guided by business problems, and developers should explain that it is inhumane to practice with new frameworks on customers. That developers nevertheless did not lose interest in learning new, it is necessary to give some opportunities to apply new technologies, but on their internal projects or to give time for open source development.
This will lead to the fact that developers are no longer able to frankly ignore both the customer and manager, because they will feel to some extent in the same boat with both, knowing how much the project’s success will affect them as well. The project in the portfolio is a reason for pride, not to mention the possible improvement in the financial situation of the company and the specific developer.
Two weeks before the bankruptcy of a small outsourcer, I went to work in a branch of a large outsourcing company.
I got there interesting. I came for an interview just out of curiosity, in order to test my skills for compliance with the needs of a highly respected company in the city. And the interviewer completely fascinated me. We very nicely talked to him about various technical issues and I realized that he is very cool, he can learn a lot from him. He, as it turned out, also appreciated me highly enough that headhunters began to actively lure. The final decision was influenced by the fact that my interviewer would be the team leader of the development team that I had to enter.
I honestly warned the branch manager and manager that I have my own small team, which I will be doing in parallel, I received consent and began to join the team. A project team of 45 people, of whom less than a third of the developers surprised me a little. At the same time, there were significantly more testers, several dedicated analysts, each team has its own leader and over all - an architect, a project manager and a program manager.
The project turned out to be a long-lived. He existed for 30 years in Fortran, then in 2000-2001 he was rewritten, making a web project in Java + Oracle. At the same time, the appearance of the interface was fully preserved. Not so much because users are accustomed to it, but because no developer fully understood the essence of the system and what all these data entry screens mean. During the existence of the project in the company, more than 100 developers have changed on it, how many testers and analysts I do not know. As a result, there was not a single person in the team I got into who fully understood the system. Even analysts, who cheerfully poured me with incomprehensible terms, could not answer most questions about the goals and needs of users.
All this led to the fact that the development was carried out by the method of imposing patches. The system documents created by analysts and testers often did not correspond to the current state of the code, because not every developer had the patience to read them and execute everything written there. In some cases, the customer and the development team had two different pictures of the same functionality.
It was on this project that I observed most of the symptoms voiced by me above. My desire to understand the business domain was puzzling. After all, it is much easier to perform a small task, without delving into what supposedly does not concern her. But I was worried that the system in terms of usability was the worst example I have ever seen. The time for user training to work with it was enormous. The user had to keep in mind a huge number of permissible values ​​of parameters and their combinations, because the system did not give out any prompts and even validation of a huge form often gave out simply “Error!”, Overloading the page with clearing all the entered data, after which the unfortunate user had to enter All over again.
At the same time, mostly the people who worked on the project were technically very competent, versed in a huge amount of subtleties of used and related technologies. However, in the eyes of many, I saw anguish. The company, which brought together almost the best developers of the city, very strangely disposed of these resources. There were projects where a small development team and literally 1-2 testers worked overtime in continuous mode while we often wandered from corner to corner, not knowing what to do when the code went into testing, and the next iteration had not yet begun. But program managers at their meetings with all their strength kept their people, not giving them to those who were in dire need, because they understood that they might not be given back to them, even if it was necessary. Very many developers, sitting inside the company,earned on freelancing, spending on it the bulk of the work day.
The result was the departure of several rather initiative employees, who eventually took leading positions in the dynamically developing companies of the city or left it. They were ready to implement their ideas inside the previous company, but these initiatives were ignored by the management, because at a high level of management, the problems of the end users and even the internal problems of the development team are no longer visible.
For myself, I made the following conclusions, which in this case are largely controversial, since there will be a huge number of people who feel completely comfortable in a large hierarchically constructed structure:
1. In such a structure, a mass of people who prefer not to take responsibility and value “stability” become critical. This leads to the fact that in those rare moments when it is required to quickly and quickly storm a new project with drafts of bare heads, no one is ready for such an activity. Therefore, projects such as boring and long-playing come to such companies as those that are already under development.
2. If projects of a different type still leak out, everything seems to be fun and interesting at first. Most often, the developers there are newcomers or passionaries who have escaped from other projects. However, the neighborhood of half-asleep teams from other projects that are constantly going to chat in the corridors or to cook in the kitchen, or those who are obviously left working time very quickly makes you wonder - why should I actually work hard for wear when a lot of people get paid for which has a lot of free time. This reduces motivation rather quickly. Then people start to keep only salary and prospects for promotion. However, many people end up going to startups, small but fun teams or freelancing.
3. The proportion of happiness per head of the programmer population in small teams that do not have several levels of the management hierarchy is much higher. Personally, I like these commands much more. Being among people with burning eyes is much nicer. Therefore, I would not recommend to combine the mentioned types of teams and projects within one company.
4. The speed of reaction to the wishes of the customer in small teams is higher, which increases the level of customer happiness. Not every customer is ready to take a risk and hire a small but proud outsourcer. However, those for our happiness are.
Formula of love happiness
For me and my partner, it consists of the following components:
• Developing a product that is designed primarily to help users solve some very important problem, and making a profit is a side effect - just such a useful service cannot but become popular. Ideally, the product should be so interesting that they want to be engaged even for free in their free time. Therefore, the opportunity to work on it for money is real happiness for the team. Ideally, the product is your own.
• Small, but very high level skill team, in which there are simply no extra people. Everyone is an enthusiast and evangelist, in addition to his main work, he is actively engaged in self-development, maintains an educational blog, contributes to an interesting open source project, or makes his own.
• The team delves into the business of the customer or the problems of the end users to the extent that they are able to speak with them in the same language and view the product in terms of business value, adapting all the processes and technical solutions to the needs of the business / users.
• The customer is so adequate that he trusts the team in the selection of technical and process decisions, allowing her to decide how to meet the needs of the business within the designated budget.
• A large number of routine operations such as deployment and testing of diverse tests are automated so that the team has enough time to work on really interesting and complex things that require the application of the brain.
• The team has time to test the hypotheses on
A good selection in the style “Thank you, cap!”. Actually, for us this is still some kind of ideal, to which we are striving with all our might. In no case do I claim here the ultimate truth. There are a lot of successful companies in terms of profits, in which there is none of the points mentioned. Or stubs from one or two of them. But I want to emphasize that I am not talking about profit maximization, but completely about other things. This is a very philosophical moment. The money itself is not really needed. A bag of money on a desert island is useless. A person needs a feeling of happiness, which is given not by money as such.
Actually, the purpose of my speech at conferences and this article is to discuss with my colleagues the aspect of interaction between business and the development team, the urgency of the problem of misunderstanding and mistrust in this interaction. Therefore, first of all, I am ready to ask readers a question - is it relevant for you about what I said? Is there a desire to discuss these topics in more detail?
The question is not idle.We are going to hold a conference based on several other principles than the conferences we have attended the last couple of years. In particular: dump.it in Yekaterinburg, codefest in Novosibirsk, devconf in Moscow, agiledays and agilecamp. The conference is scheduled for September 29th.
The idea is to break the reports into sections not by specializations in the team: developers, testers, designers, managers, and not according to the technologies used. I would like to unite people into sections according to the types of business tasks, having considered specific cases in each section on each section. People working in enterprises, banks and other large companies are not interested in listening to those whose customers are start-ups with a limited budget, who need to quickly produce a prototype to get a round of investment or to test the hypothesis and measure KPI. I would like people to share among themselves the approaches to the organization of development processes and the choice of technical solutions, based on the needs of the problem being solved.
Thanks to everyone who took the time to read. I will be glad to any tricky questions and advice on the topic raised.
Source: https://habr.com/ru/post/149985/
All Articles