How to do the projects necessary to people, or why startups do not fly up
Today, using practical examples, we will examine two myths in project management, including the development of startups:
1. The fact that the best and only way to make a successful startup is to make one that solves tasks that are familiar to the creator in everyday life.
2. The fact that there is an autonomy of business, when the project can be brought to a certain point and nothing else to be done, and then it will simply bring money on the machine.
We will also touch upon the myth of “bad programmers” who do tasks not on time, do non-working projects, or spend time on Habr, and find out that the person who manages the development is responsible for most of the problems.
')
Let's start with the first myth. I am not going to dispute this statement, but I want to expand it. We can say that the best and only way to make a successful startup is to do it that solves the problems of users whose needs were well understood by the creator .
That is, it is not at all necessary to be in finance, chemistry or domestic animals all the time to make a successful startup in each of these areas. You need to be able to dive into the chosen sphere and see the project through the eyes of the end user.
This approach provides a much wider circle for selecting initial ideas. The only thing you need to master is logic, and to be able to write algorithms, as Potapenko says, at the level of the 8th class, where there are two elements - the conditional operator and the cycle.
By the way, Sergey Galitsky speaks about the importance of logic (who does not know - the billionaire created the Magnit retail network from scratch) in the Business Secrets program, and we will touch on this topic. In general, I note that I like the statements of Fritz Morgen, who did not divide people into logicians and intuits, but suggested that among literate people, logic and intuition work consistently, in one cycle, replacing each other.
Actually, the right approaches are the same everywhere, and the same Dmitry Potapenko says that he is always studying his consumer very carefully, trying to feel what is needed and what products the buyer will choose first.
You can fix the error, just thinking on time
Now - a practical example. It is said that the sooner an error is detected, the lower the cost of eliminating it, and the difference between the fix in the interface prototype and the release can be thousands of copies up to 1000 times (in absolute terms - millions of dollars). But what is often forgotten is that an error can be detected not only at the stage of prototyping (interface design), but even earlier - at the stage of thinking .
Suppose we are designing Yandex. You are a programmer and supervise programmers. A plan for the next two weeks is being discussed. Programmers are infected with the idea of ​​making a cool advanced search, with a query language, with AND / OR logic, with parentheses, with asterisks, and so on. And estimated at two weeks mechanism. If you look at the project as a programmer, you will happily agree with the arguments of your colleagues, and you yourself will be happy to take part in the development.
However, if you imagine yourself in the shoes of your familiar blonde girl who doesn’t petrite on computers anymore than solitaire, the decision will be different. Using other search engines, especially foreign ones, for a couple of days, and looking “with the eyes of a blonde” at the results and entering simple and stupid queries, you will get a special experience. Experience that tells you what kind of functionality you really need. The first thing you will notice is that bourgeois systems, as a rule, do not understand Russian morphology. The second is that you like it when the necessary results turn out to be the first, and it really pisses me off when you need to go to the fifth page behind the necessary site. You will also understand that you have never gone into an advanced search, because when you open it, a large page is loaded, and your friend is frightened at the sight of a form with ten elements and frantically presses "back."
It seems, she again fell into the advanced search
There is something about acting when you start to believe in that. you are blonde and immersed in her role. The better the dive, the more accurately you will be able to see how it will behave on your project and predict its actions, just by watching yourself when solving a particular task.
Now back to the iteration planning. Now you know that advanced search will be two weeks of wasted time. In direct money terms - 10 * N * S (i), where N is the number of programmers, S (i) is the salary of each person per working day. For example, for three programmers with a day costing $ 100 it will be 10x3x100 = $ 3000, that is, about 100,000 rubles! And if you still have competitors who will make a competitive advantage in these two weeks, then the losses will be incomparably greater.
At the same time, you already know what is important for the search engine. First, it is the relevance of the results - the closer they are to the user's request, the better. Secondly, this is an understanding of the query as accurately as possible - and Russian morphology, and typical typos, etc.
Thus, immersion into the skin of your user gives you:
1. Accurate understanding of important tasks in the current moment
2. As a result, the ability to cut off unnecessary functionality is still at the level of thinking - if it does not solve the user's tasks, it can be safely cut off.
At the same time, we do not consider the question of determining who your user is - this is beyond the scope of the article, and, by the way, my beloved Potapenko says the same thing - in 90% of the question “who is your customer?” The answer is “woman 30 to 50 ”, that is complete bullshit - that is, the buyer is not exactly defined.
I think you already understood that most startups do not take off because they simply make functionality that nobody needs, and just lose money and time. At the same time, the few who do the really necessary functionality take off. Often this happens through the use of a particular case of the first principle - people just do what they rummage about and solve the problems they know.
Now about the so-called bad programmers who delay deadlines, do unnecessary tasks, do non-working projects, and so on. I am convinced - it's just a myth. For the most part, programmers, if they do their work, are very smart, responsible people who are always involved in what they are doing, are given to the task with a soul and always try to be on time.
But why everywhere do we hear these accusations against us? Yes, because there are not only few good managers in Russia - in general, they do not think so. Namely, the work of the programmer depends on the project manager. Let us examine all the problems consistently.
The first is that the programmer is not interested. This can be either in the case when a person is engaged in not his own business (he came from webmasters, works stupidly for money, and so on), and he doesn't give a shit about everything, just to get paid. But it is a rarity. The second is that the manager does not waste time engaging the programmer, does not show him that in the project is interesting, how important is what is being done. Does not give feedback from users. Most often, he simply gives TK and says - do it the way I said, and that's it. At the same time, if you explain the project to the programmer from the user's point of view, show what tasty and important things are done, share the received gratitude with him - even just send the log from ICQ to “what a cool section was done!” From the user - the programmer begins to feel his active role in the project, and works much better. You just need to share the truth and understand the importance of involvement.
The second is non-working functionality. The same thing - if the manager explained to the programmer, taught him to look from the user's point of view, highlighted important points, told logic - the programmer would check how everything works, and in 90% of cases it would not be necessary to test. According to McConnell, motivated and unmotivated programmers differ in speed up to ten times.
The importance of accurate reporting to other project participants cannot be underestimated.
Another point - the formulation of the problem. I teach my project managers to set the tasks point by point, so that the programmer can easily understand the task. Criterion one - after reading the task, the programmer should have no questions. At all. At the same time, I strive to define the problem statement at least into two points - abstraction and implementation (the principle of the inversion of dependencies rules and here). For example, there is a task to make a table with filters, and a layout is given. First you need to write the logic of the work, without reference to the visual part. The algorithm in words, the input data and the output, consider the boundary values, give an example of how the algorithm works on live, combat data (that is, what is the input, and what the output should be). Then - describe the layout specification, which element performs what function and how it is related to others.
In fact, you need to describe the task in the programmer’s language, and the closer you are to technical to the technical one, the easier it will be for you. The ideal option is UML diagrams (such as sequence diagrams) that can be easily drawn by hand and quickly scanned (the scanner costs $ 100 and pays off in the first week, saving you hours of talking per month - 90% of the information is transmitted visually and only about 9-10% - aurally).
In this case, the algorithm I understand is not the implementation already, but how it should work. Implementation options remain at the choice of the programmer.
Further, unrealistic terms. This is also easily solved at the level of thinking. Before you get the idea to set a task, you need to ask yourself, ask a few questions:
1. Can this not be done? How much can you put off thinking, working out this problem (I call the transformation of thought into an exact statement for the programmer)?
2. How can this be done easier?
3. What are the alternative solutions to the issue (up to administrative)?
If the choice is made, you need to work with the programmer. First, discuss the problem with your voice, ask for time. Suppose in the case of a table with filters you heard - 23 hours, but you need to do a task for 4 hours. You have three filters - drop-down lists by country, resort and date, and the table displays entries. Ask the programmer to paint the stages of the task, give half an hour to think, get a list:
- glossary of resorts, countries at the base level with admin panel - 8 hours
- calendar for date selection - 1 hour
- sorting in the table - 4 hours
- selection from the database and output from the table - 2 hours
- paging - 4 hours
- Filter by date, country, resort - 4 hours
When asking guiding questions about an incomprehensible item, remembering about really important functionality, and also wondering how tasks on live data will look like, say the following steps
1. Since there will be no more than 100 entries, paging is not needed.
2. Since there will be filters and records a bit, sortings (which the programmer will easily include in the list himself) are not needed.
3. Since in reality there will be two countries, there are less than 10 resorts, and in most cases you need to look at the recordings yesterday - speak to start directly with the hardcode (array in the code) of the country and resorts and yesterday, without a calendar
4. Knowing that the programmer is 100% optimistic on average, tell him that the most important thing is to simply output the data from the database as a simple table, which you can jot on yourself for 5 minutes on the bare HTML (save time, attach the layout later) and give 2 hours. As a result, in 4 hours he will do what you need.
5. Assure him that time will be given for refactoring.
And in this way - with each task, until you get 80-90% of what you need. Then you switch to another programmer and another task, and give the current one a refactor. Here, everything benefits: first, you very quickly perform several iterations on live data, and you get the final look and logic of the system, and the programmer - he will not write for a long time what you have to redo (after all, you haven’t done micro-iteration to understand how to properly), and govnokodom (sometimes you need to push the quick option, show the benefits) will make a couple of iterations, get a very accurate version of the problem, and can otrefaktorit, having already an exact understanding of how everything is arranged.
Over time, programmers will be wiser and more experienced, and depending on the stage of the task (developing a new functionality, or starting a project) will choose a strategy - quick rush with govnokodom and micro-iteration + refactoring, or immediately clarifying requirements and exact implementation (if there is no place to go, dopilka project)
All of the above is, of course, micromanagement, but it allows you to make releases every day in the early stages of the project and 80-90% accurate functionality. If you know the approach that allows you to act better in the first stage, please describe it in the comments.
Now about the second myth. The fact is that any living entity moves, evolves. This means that any project has competitors. And if you left the project intact - while you are on the same project, others move forward. This includes your users, who are starting to use the functionality in a different way than you intended. And if you do not intervene in time - often you need to redo everything first.
Sometimes the project pants are no longer in size
An example - let's say you have a project management system based on Mantis. There is just a main project, and a subproject. You once laid such a hierarchy and did not change it. Years go by. People will add to the subprojects when the number of projects grows dramatically, already other entities already - new sections will be added there, over which development is underway. Perhaps, as a project, some category of the type “Client sites” will be added. And as a result, when you get to the problem, you will find that you have a lot of entities in the structure from a simple tree: category, project, section, connection with the client, connection with a specific department, and so on. That is, the structure has not changed, while live data - the basis of any project - has evolved and outgrown its framework.
That is why it is so important to always check everything on living data, and constantly monitor the project, how it develops, predict the direction of change and scale / remake the structure and logic to the current state.
1. The most important thing is to think correctly. To be able to look at the project through the eyes of your user and thereby understand the really important tasks, and how these tasks need to be done. Startups do not take off because they make the wrong functionality, not needed by anyone, and lose time and money.
2. 90% of problems in projects are errors due to incorrect management.
3. Proper motivation, involvement of the programmer, well-developed task setting and close work with the programmer according to a certain methodology allow speeding up to 10 times and doing the required functionality by 80-90% just in time, while allowing time for refactoring for the programmer
4. Any project needs to be developed to make it live.
I wish you good luck and offer to share your experience in the comments.
Crosspost in my LJ
1. The fact that the best and only way to make a successful startup is to make one that solves tasks that are familiar to the creator in everyday life.
2. The fact that there is an autonomy of business, when the project can be brought to a certain point and nothing else to be done, and then it will simply bring money on the machine.
We will also touch upon the myth of “bad programmers” who do tasks not on time, do non-working projects, or spend time on Habr, and find out that the person who manages the development is responsible for most of the problems.
')
1. How important it is to see the project through the user's eyes
Let's start with the first myth. I am not going to dispute this statement, but I want to expand it. We can say that the best and only way to make a successful startup is to do it that solves the problems of users whose needs were well understood by the creator .
That is, it is not at all necessary to be in finance, chemistry or domestic animals all the time to make a successful startup in each of these areas. You need to be able to dive into the chosen sphere and see the project through the eyes of the end user.
This approach provides a much wider circle for selecting initial ideas. The only thing you need to master is logic, and to be able to write algorithms, as Potapenko says, at the level of the 8th class, where there are two elements - the conditional operator and the cycle.
By the way, Sergey Galitsky speaks about the importance of logic (who does not know - the billionaire created the Magnit retail network from scratch) in the Business Secrets program, and we will touch on this topic. In general, I note that I like the statements of Fritz Morgen, who did not divide people into logicians and intuits, but suggested that among literate people, logic and intuition work consistently, in one cycle, replacing each other.
Actually, the right approaches are the same everywhere, and the same Dmitry Potapenko says that he is always studying his consumer very carefully, trying to feel what is needed and what products the buyer will choose first.
You can fix the error, just thinking on time
Now - a practical example. It is said that the sooner an error is detected, the lower the cost of eliminating it, and the difference between the fix in the interface prototype and the release can be thousands of copies up to 1000 times (in absolute terms - millions of dollars). But what is often forgotten is that an error can be detected not only at the stage of prototyping (interface design), but even earlier - at the stage of thinking .
Suppose we are designing Yandex. You are a programmer and supervise programmers. A plan for the next two weeks is being discussed. Programmers are infected with the idea of ​​making a cool advanced search, with a query language, with AND / OR logic, with parentheses, with asterisks, and so on. And estimated at two weeks mechanism. If you look at the project as a programmer, you will happily agree with the arguments of your colleagues, and you yourself will be happy to take part in the development.
However, if you imagine yourself in the shoes of your familiar blonde girl who doesn’t petrite on computers anymore than solitaire, the decision will be different. Using other search engines, especially foreign ones, for a couple of days, and looking “with the eyes of a blonde” at the results and entering simple and stupid queries, you will get a special experience. Experience that tells you what kind of functionality you really need. The first thing you will notice is that bourgeois systems, as a rule, do not understand Russian morphology. The second is that you like it when the necessary results turn out to be the first, and it really pisses me off when you need to go to the fifth page behind the necessary site. You will also understand that you have never gone into an advanced search, because when you open it, a large page is loaded, and your friend is frightened at the sight of a form with ten elements and frantically presses "back."
It seems, she again fell into the advanced search
There is something about acting when you start to believe in that. you are blonde and immersed in her role. The better the dive, the more accurately you will be able to see how it will behave on your project and predict its actions, just by watching yourself when solving a particular task.
Now back to the iteration planning. Now you know that advanced search will be two weeks of wasted time. In direct money terms - 10 * N * S (i), where N is the number of programmers, S (i) is the salary of each person per working day. For example, for three programmers with a day costing $ 100 it will be 10x3x100 = $ 3000, that is, about 100,000 rubles! And if you still have competitors who will make a competitive advantage in these two weeks, then the losses will be incomparably greater.
At the same time, you already know what is important for the search engine. First, it is the relevance of the results - the closer they are to the user's request, the better. Secondly, this is an understanding of the query as accurately as possible - and Russian morphology, and typical typos, etc.
Thus, immersion into the skin of your user gives you:
1. Accurate understanding of important tasks in the current moment
2. As a result, the ability to cut off unnecessary functionality is still at the level of thinking - if it does not solve the user's tasks, it can be safely cut off.
At the same time, we do not consider the question of determining who your user is - this is beyond the scope of the article, and, by the way, my beloved Potapenko says the same thing - in 90% of the question “who is your customer?” The answer is “woman 30 to 50 ”, that is complete bullshit - that is, the buyer is not exactly defined.
I think you already understood that most startups do not take off because they simply make functionality that nobody needs, and just lose money and time. At the same time, the few who do the really necessary functionality take off. Often this happens through the use of a particular case of the first principle - people just do what they rummage about and solve the problems they know.
2. How to communicate with programmers correctly
Now about the so-called bad programmers who delay deadlines, do unnecessary tasks, do non-working projects, and so on. I am convinced - it's just a myth. For the most part, programmers, if they do their work, are very smart, responsible people who are always involved in what they are doing, are given to the task with a soul and always try to be on time.
But why everywhere do we hear these accusations against us? Yes, because there are not only few good managers in Russia - in general, they do not think so. Namely, the work of the programmer depends on the project manager. Let us examine all the problems consistently.
The first is that the programmer is not interested. This can be either in the case when a person is engaged in not his own business (he came from webmasters, works stupidly for money, and so on), and he doesn't give a shit about everything, just to get paid. But it is a rarity. The second is that the manager does not waste time engaging the programmer, does not show him that in the project is interesting, how important is what is being done. Does not give feedback from users. Most often, he simply gives TK and says - do it the way I said, and that's it. At the same time, if you explain the project to the programmer from the user's point of view, show what tasty and important things are done, share the received gratitude with him - even just send the log from ICQ to “what a cool section was done!” From the user - the programmer begins to feel his active role in the project, and works much better. You just need to share the truth and understand the importance of involvement.
The second is non-working functionality. The same thing - if the manager explained to the programmer, taught him to look from the user's point of view, highlighted important points, told logic - the programmer would check how everything works, and in 90% of cases it would not be necessary to test. According to McConnell, motivated and unmotivated programmers differ in speed up to ten times.
The importance of accurate reporting to other project participants cannot be underestimated.
Another point - the formulation of the problem. I teach my project managers to set the tasks point by point, so that the programmer can easily understand the task. Criterion one - after reading the task, the programmer should have no questions. At all. At the same time, I strive to define the problem statement at least into two points - abstraction and implementation (the principle of the inversion of dependencies rules and here). For example, there is a task to make a table with filters, and a layout is given. First you need to write the logic of the work, without reference to the visual part. The algorithm in words, the input data and the output, consider the boundary values, give an example of how the algorithm works on live, combat data (that is, what is the input, and what the output should be). Then - describe the layout specification, which element performs what function and how it is related to others.
In fact, you need to describe the task in the programmer’s language, and the closer you are to technical to the technical one, the easier it will be for you. The ideal option is UML diagrams (such as sequence diagrams) that can be easily drawn by hand and quickly scanned (the scanner costs $ 100 and pays off in the first week, saving you hours of talking per month - 90% of the information is transmitted visually and only about 9-10% - aurally).
In this case, the algorithm I understand is not the implementation already, but how it should work. Implementation options remain at the choice of the programmer.
Further, unrealistic terms. This is also easily solved at the level of thinking. Before you get the idea to set a task, you need to ask yourself, ask a few questions:
1. Can this not be done? How much can you put off thinking, working out this problem (I call the transformation of thought into an exact statement for the programmer)?
2. How can this be done easier?
3. What are the alternative solutions to the issue (up to administrative)?
If the choice is made, you need to work with the programmer. First, discuss the problem with your voice, ask for time. Suppose in the case of a table with filters you heard - 23 hours, but you need to do a task for 4 hours. You have three filters - drop-down lists by country, resort and date, and the table displays entries. Ask the programmer to paint the stages of the task, give half an hour to think, get a list:
- glossary of resorts, countries at the base level with admin panel - 8 hours
- calendar for date selection - 1 hour
- sorting in the table - 4 hours
- selection from the database and output from the table - 2 hours
- paging - 4 hours
- Filter by date, country, resort - 4 hours
When asking guiding questions about an incomprehensible item, remembering about really important functionality, and also wondering how tasks on live data will look like, say the following steps
1. Since there will be no more than 100 entries, paging is not needed.
2. Since there will be filters and records a bit, sortings (which the programmer will easily include in the list himself) are not needed.
3. Since in reality there will be two countries, there are less than 10 resorts, and in most cases you need to look at the recordings yesterday - speak to start directly with the hardcode (array in the code) of the country and resorts and yesterday, without a calendar
4. Knowing that the programmer is 100% optimistic on average, tell him that the most important thing is to simply output the data from the database as a simple table, which you can jot on yourself for 5 minutes on the bare HTML (save time, attach the layout later) and give 2 hours. As a result, in 4 hours he will do what you need.
5. Assure him that time will be given for refactoring.
And in this way - with each task, until you get 80-90% of what you need. Then you switch to another programmer and another task, and give the current one a refactor. Here, everything benefits: first, you very quickly perform several iterations on live data, and you get the final look and logic of the system, and the programmer - he will not write for a long time what you have to redo (after all, you haven’t done micro-iteration to understand how to properly), and govnokodom (sometimes you need to push the quick option, show the benefits) will make a couple of iterations, get a very accurate version of the problem, and can otrefaktorit, having already an exact understanding of how everything is arranged.
Over time, programmers will be wiser and more experienced, and depending on the stage of the task (developing a new functionality, or starting a project) will choose a strategy - quick rush with govnokodom and micro-iteration + refactoring, or immediately clarifying requirements and exact implementation (if there is no place to go, dopilka project)
All of the above is, of course, micromanagement, but it allows you to make releases every day in the early stages of the project and 80-90% accurate functionality. If you know the approach that allows you to act better in the first stage, please describe it in the comments.
3. Why any project needs to be constantly developed
Now about the second myth. The fact is that any living entity moves, evolves. This means that any project has competitors. And if you left the project intact - while you are on the same project, others move forward. This includes your users, who are starting to use the functionality in a different way than you intended. And if you do not intervene in time - often you need to redo everything first.
Sometimes the project pants are no longer in size
An example - let's say you have a project management system based on Mantis. There is just a main project, and a subproject. You once laid such a hierarchy and did not change it. Years go by. People will add to the subprojects when the number of projects grows dramatically, already other entities already - new sections will be added there, over which development is underway. Perhaps, as a project, some category of the type “Client sites” will be added. And as a result, when you get to the problem, you will find that you have a lot of entities in the structure from a simple tree: category, project, section, connection with the client, connection with a specific department, and so on. That is, the structure has not changed, while live data - the basis of any project - has evolved and outgrown its framework.
That is why it is so important to always check everything on living data, and constantly monitor the project, how it develops, predict the direction of change and scale / remake the structure and logic to the current state.
Summing up
1. The most important thing is to think correctly. To be able to look at the project through the eyes of your user and thereby understand the really important tasks, and how these tasks need to be done. Startups do not take off because they make the wrong functionality, not needed by anyone, and lose time and money.
2. 90% of problems in projects are errors due to incorrect management.
3. Proper motivation, involvement of the programmer, well-developed task setting and close work with the programmer according to a certain methodology allow speeding up to 10 times and doing the required functionality by 80-90% just in time, while allowing time for refactoring for the programmer
4. Any project needs to be developed to make it live.
I wish you good luck and offer to share your experience in the comments.
Crosspost in my LJ
Source: https://habr.com/ru/post/126988/
All Articles