|
Excellent! The two questions are critical and I am also questioning myself about that!
Your first question had already been in my mind, when I wrote down the first sentence about this "ridiculous case".
I am playing a consultant-like role in the company. They can ask me any type of questions if they want to and I will try to answer them or help them to find the answers. I don't participate in their development or sales, yet I have joint some of their meetings and knew part of their history. Last year, one manager had already realized something wrong in their company, and this year more and more managers had the same feelings. However, they were not very sure about the root cause of the problems. Previously few people had even consulted me about product innovation strategies, since things appeared to go well--sales were decent, customers were increasing, new products were developed, until this year, the economy was recessing, problems emerged with financial reports.
In order to address the root of the problems, I suggested them to write down every problems they were facing and join the results together, so they could have a more complete vista about the whole picture. Problems were enumerated, and we got the following facts:
1. Requirements came from three sources: sales representatives, the product consultant or representative of the development department, and finally the general manager.
2. Requirements were recorded in the development department.
3. It was the development department and the general manager who decided whether a requirement would be implemented, usually, prioritized by the amount of money in the orders.
4. Requirements came from product consultant of the development department were not evaluated by the sales department.
5. About ten products were developing or had been developed, yet only two of them were sold by the sales department.
6. The sales department had no idea about what were on the development schedule or had been developed.
7. Sales department manager or members were seldom invited to join any meetings held during development, except those being sold; developers occasionally join weekly meetings in the sales department.
8. Whether a product had become "mature for market rollout" was determined by the development teams. No product was handed to the sales department yet.
9. Development department had employed their own sales representatives to contact "customers that were unreachable by the sales department".
10. The revenue generated from the development department and their sales representatives were even not enough to pay their salary. Yet the number of the members had almost doubled in one year.
11. It was reckoned that less than 20 percent of development force was used to develop products sold by the sales department.
12. On every managers' meeting, when the sales manager reported problems of a system, the development department seldom voluntarily offered their help, instead, similar systems were purchased as substitutions to the one developed by the development department; the reports presented by the development department had seldom mentioned metrics about feature usage statistics, customer satisfaction, customer activity, despite my suggestions to do so--nevertheless, they did collect usage data and respond to customer feedbacks.
13. Developers and deployment engineers could deduct a percentage from the revenue as their rewards, however, nothing would happen to them if the products were not sold as well as expected.
Some facts/limitations about the company:
1. A small one with less than 100 employers, with limited capital
2. Salary level of the development department is above average in this city, but far below larger cities in our country
3. Developers have received less education than those in larger cities
4. In the market segment of this city, about 50% customers are served by one product/service
5. The sales department and the customer service department contact more than 90% customers and users
Some suggestions I'd given to their general manager before:
1. Focus development force to limited products, do not spread your teams too flat--the development manager also suggested that previously
2. Segment customers and investigate them; Find out common requirements of each segment
3. The goal of customer contact not only include signing the contract, but also finding out the underlying business logic
4. Build your product roadmap with the knowledge gain from the above approaches
5. Evaluate market size and average customer affordability before entrance
6. Keep good watch for your cash flow
7. Show me the above info when you decide to invest more on the project
After the investigations and talks, I guessed I should not sit there waiting for their questions, since not all of them were used to ask, but offer to help them.
modified 21-Aug-23 9:26am.
|
|
|
|
|
Well, great. Thank you for further explanation.
You know, if I had a chance to play your role in this case, I would be afraid the most of one thing: scaring them to death with my criticism... to say the least.
—SASergey A Kryukov
|
|
|
|
|
Thank you for the enlightenment.
I have not ever thought of that
Most of them have been so miserable about their previous failure, but also longing for the consulting company, which is expected to clean up their minds, tell them the ways to solve their problems. The general manager is also my friend. I, frankly speaking, will feel much better for myself, if the consulting company can very well fix their problems for sure. I don't have to be sleepless for their problems any more. However, I hope the final solution can come from themselves, by helping them think more logically and find out the root cause of their status quo, without spending extra money on the fee which could push their company deeper into debt. As a bonus, they can think better about their problems and their customers' problems in the future, promoting their products even better.
Some employees expressed their worries when they heard of the "news":
1. They had no idea what would happen to them, but did feel somewhat panic.
2. Some of them ever had experienced unsuccessful consulting that sank their previous companies so badly, almost to bankruptcy.
3. Some of them might begin to look for another job if "optimization" comes to them.
4. Some managers expected persons outside of the company could help them sort out the problems better, yet some others had so little faith in outsiders.
5. Domestic economy will go worse in the upcoming years. It is not very wise to spend a lot money on things with uncertain payoff.
A manager talked to me in private, remarking that their general manager was so easily driven by "gold apples", or even "golden apples", for several times. With the "golden apples" in his mind, optimism had been maximized, and always consequently led to money loss. That manager tried to warn him about that privately, but failed without any surprise. "You are the only hope now." said the manager.
|
|
|
|
|
I guess, it must be not bad to feel like “the only hope”, but the situation you've described looks pretty depressing.
Not having “to be sleepless” is not a bad thing.
However, I feel like I would try to sort out things, at least for sheer interest and experience. You know, I feel pretty healthy about the episodes of insomnia or overly excited state of mind. To me, the free schedule and general peace of mind easily beat such minor problems.
Some more about my worry, “scaring them to death” and related concerns:
Hippocrates said: Primum non nocere
(First do no harm)
Pretty important, isn't it?
—SASergey A Kryukov
modified 21-Aug-23 14:05pm.
|
|
|
|
|
Thank you for your encouragement.
They eventually decided to hire the consulting company to help them and the general manager assured that they were backed by his money. Fortunately, my payment would not be affected either.
One more manager had realized that they need to study more and began to question other managers to imagine what they would be, if they could keep studying for a month, in their instant messaging group.
As for the "sleepless" symptom, in the view of Traditional Chinese Medicine (TCM), it can be unhealthy, combined with some other situations. I will try to fix it.
TCM is now an argumentative topic in China. It can not be verified by modern science or statistics. However, according to reports and experiences of COVID-19 patients in Wuhan in year 2020 and some of my relatives in year 2022, it seemed to prove that TCM could help them conquer the virus easier and prevent long-COVID dramatically.
modified 4-Sep-23 21:51pm.
|
|
|
|
|
wmjordan wrote: Thank you for your encouragement. … Fortunately, my payment would not be affected either.
Ha-ha, you live a funny life.
wmjordan wrote: …sleepless symptom, in the view of Traditional Chinese Medicine (TCM)…
By the way, I've used TCM by prescription occasionally, as our family uses some help from a Chinese therapist. However, nothing related to sleep — if you take it correctly, it cannot harm your health. I recently had some episodes due to new exciting developments on Solution structures. I'm in an active Code Project authoring phase right now.
Please take a look at this
GitHub repository
The code is complete, and I plan two big articles, but the topics are shown in the short repository description.
You may find it strategically important. The idea is: Microsoft focuses on pleasing the starters, and that is a perfectly reasonable approach from the marketing standpoint, but the default Visual Studio templates are not only unsuitable for multi-project fully-fledged solutions but are simply unacceptable. But I provide an easy fix.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Actually I paid little attention to the VS solution structures previously.
I'll be looking forward to your articles.
|
|
|
|
|
Not paying attention? Let's say a simple thing: you have a solution of 20 projects. What do you do to assign a version and attributes like Product? Every time, visit every project and paste the values from the clipboard. If some of the projects should be targeted essentially to net7.0, and some to net7.0-windows, what would you do? How do you know what files should go to revision control and what not? I'm just curious, to get an idea on what people think...
Thank you.
—SASergey A Kryukov
|
|
|
|
|
I do have a solution with many projects. But those projects were not added to the solution at a time.
I developed one project, then another project, then more when it is required.
Version numbers and the "year" in the CopyrightAttribute are automatically generated and incremented with an extension in VS (in teamwork, this can also be automated or done by the one who is responsible for release). Attributes like ProductAttribute are added once and left alone afterwards. So to the project targets.
All those things are created one by one and seldom change.
Compared to the time spent on developing and debugging, the above stuff is nothing.
"Revision control", or "version control" your meant?
If it is "version control", all our code files and markdown documentations are in version control.
|
|
|
|
|
I don't think you understand important things. As to revision control, I found that a good number of authors tend to put trash under revision control. Some even don't know exactly which files are source files and which files are intermediate and not the author's files. One problem with Microsoft is that the default project and solution templates don't isolate them.
(I was talking about Revision Control Systems — this is the most widely accepted terminology.)
The reasoning based on “compared to the time spent” or “all those things are created one by one and seldom change” is extremely destructive. As if things were measured by time spent. How this time can be related to importance? How about the Pareto distribution? It resembles the complaints of engineers about the “uselessness” of all those mathematical uniqueness quantification and existential quantification theorems. Honestly…
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Oh, trash files.
Obj, dist folders had been uploaded to our SVN server years ago, when our developers were almost newbies to it at the time. Having seen that, I told them to always ignore some intermediate folders.
Nowadays we have various .gitignore files. We check our modifications before pushing changes to the Git server. I checked our Git server just now and I was satisfied with the absence of trash files.
What's the importance then?
|
|
|
|
|
The problem is not .gitignore, but the fact that non-source files and source files are mixed up from the very beginning. This is a big defect of Microsoft build in general, more exactly, of the default settings, but MSBuild is a powerful and generally a very good system, so this defect can be easily compensated. However, offering bad defaults is a problem. I think I do understand the reason: from the standpoint of marketing, it makes the most sense to create a product, that can build multiple-project solutions right away — to please the beginners. However, the way it is done is very questionable: they create separate bin and obj directories (per project), and at the end also copy partial outputs all one common output. As a result, a mess of different directories is created: 1) real source code, 2) intermediate files, 3) output. The purpose of different files and directories is not well documented.
Even though it is fine at first, for creation and support of any serious project this situation is simply unacceptable. Fortunately, it is easy to improve, just with one file.
Another thing hard to leave with is how people do versioning. A version is always a result of a decision, otherwise, the policy would defeat the purpose of versions. I can see how people revisit individual *proj files and change them. Same goes when a product name and other metadata properties are changed. In programming, this is called anti-pattern (magic word, magic number anti-pattern), so why it is tolerated in the solution environments? I know why: because some people think that there are no important details... And — back to the entire discussion we had recently — because of the trend to follow established “procedures“, no matter how bad.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Yes, the mixed files and folders are really a problem. I tend to place output files from various projects into shared folders, if the containing solution has many projects.
However, it is still not a big deal compared with the real world problems we need to solve.
If there is a tool to migrate those output/supporting/intermediate folders and files into a separated place away from the source code and documentation, that will be better.
|
|
|
|
|
This is not a problem with the correct approach: Directory.Build.props at the solution level defines all you need. On deeper levels, it can be overridden. For example, the target framework could be, for example, net5.0 for some projects and net5.0-windows for others. It is impossible to place some attributes in other project files because it is too late, but Directory.Build.props is read early. In particular, the only way to redirect the intermediate output base path in any other place without using Directory.Build.props , because otherwise the intermediate directories will already be created per project, it happens before MSBuild handles any project file, that is changing it would be too late. And so on…
Again, you can find an example in the root of /code of the GitHub repository.
Again, let me reiterate: I consider speculations like “…still not a big deal compared…” as one of the most destructive attitudes. Can you guess why?
Thank you.
—SASergey A Kryukov
|
|
|
|
|
We have not been bothered by this problem then.
Our solutions have not yet been so complicated.
|
|
|
|
|
wmjordan wrote: Our solutions have not yet been so complicated.
How do you know? Every solution with more than one project is already too complicated to pay for Microsoft's sloppiness. By not addressing this problem, you already pay more compared with the case when you address it properly. The minimal thing to do is to add a single file with corrected properties. Otherwise, led by the standard project templates 1) violate the D.R.Y. principle, 2) follow the the anti-pattern “magic word”. Repeated work is only for robots, conceptual understanding — for humans.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
We did spend some time on dealing with project properties and some other stuff within a solution.
However, it did not take us quite a lot of time, and it did not require us to think about it too hard.
It did not affect the performance of our products either.
Even though your new solution could potentially save us some time, it would not add up to too much, since we don't have so many solutions. And many developers in my company do not use VS or C# at all.
We have many solutions which contain just one project or two projects for each as well. The default solution structure provided by VS does not bring too much trouble to us.
Benefit = ((Efforts & time spent in old approach) - (Efforts & time spent in new approach)) * (number of solutions)
The time spent on this discussion about solution structure might be even longer than what we have spent onto adjusting things in existing projects.
It is just like getting into our car. A car may has "keyless entry system"--just open the door and get into the car, with the key in our pocket; another car has no such keyless access, we need to push a button on the car key, then we can open the door and get into the car. "Keyless entry" is great. But without that, it is not so bad for me. Hmm, of course, for some people, "Keyless entry" is a must have for them.
EDIT: Someone noticed that the battery in a "Keyless entry" car key runs shorter than those without that feature. Please think about whether there is any side effect of your solution as well.
|
|
|
|
|
I understand. You list valid aspects to evaluate, only the final result is incorrect. Whatever…
The attitudes can be different, and I have a pretty low tolerance for sloppiness in the fundamentals.
Also, note one difference: the person who actually spent some time was me and not you, and it makes the levels of awareness not symmetric.
—SASergey A Kryukov
|
|
|
|
|
You are the one who will spend the time. I am the one who has taught my team members once and left things along. I spend little time on VS solution or project stuff now.
If we adapt your solution, we will also have to learn about it. Learning takes time too. Since we are Chinese, not all developers in my team are good at English either, so it is more difficult for us. Teaching them takes time too. If something not works in the solution, we have to turn to you and wait for you to fix it. If the fix is not in time, we will be in a mess. More time will lose. Since our solution and projects are usually simple, the benefit will be trivial. Our gain is not guaranteed, but there is no doubt that we have to spend some extra time on it.
I shall express my worry to you, my friend.
It it not the first time that we develop something hoping that the thing can help our users, but turns out to do little or even no help actually when it is delivered to the end users. I am also an open-source developer and have spent quite some time on some freeware programs, which are used by some users around the world. From their feedback, I am not surprised to find that not all features are used by the users, some people like feature A, some like B, some like A and C, etc. Of course, I myself use all features in the thing, otherwise I won't develop it. The features that are useful for me might not be the same useful for others. I can't say they are not smart or they are wrong. They just work like that.
Anyway, the users also spend their time on my freeware. Some of them took a lot of time testing and giving me valuable feedback too. No matter how much they love my freeware, there are always some features that they don't use.
Since this discussion is not related to this article, it may not be appropriate to write too long. You have my mail box, you can always email me.
modified 8-Sep-23 3:23am.
|
|
|
|
|
Sorry, it is not convincing.
Thank you for expressing your worries, though.
You see, you sound like you perceive my news as propaganda. No, it is not. You try to judge on things you simply have little to no information about, that's the only problem. No one urges you to learn about things, but combining having no awareness with judgment seems a bit weird. And I can repeat, the entire idea of saving time on learning is destructive.
However, by the way, there is a real bomb coming up: XAML-based localization with satellite assemblies. It's been a really big and ugly unsolved problem. If I'm not much mistaken.
I agree on the place for the discussion.
—SASergey A Kryukov
|
|
|
|
|
Sergey Alexandrovich Kryukov wrote: A developer on our site shouts at imaginary engineers on the customer's side: “Who is that idiot who requested that?!” However, after the request was “satisfied”, it was pretty obvious that an engineer on the customer side would shout: “Who is that idiot who wrote that trash and pushed it to me?!”
Having read this once again, I've like to add two more stories about customer requirements.
A customer demanded an extra feature X within a contract. Somehow the sales department agreed to give it for free, maybe taking account for the contract. The development department confirmed the requirement with a prototype and afterwards implemented that feature after some weeks. When the customer got his customization, he realized that he did not need that feature very much actually, after those several weeks. Although the money was still paid despite of that. However, it was a waste.
Another small company A signed a contract with a small company B to upgrade their business operating system. Their business operation manager in A was assigned to list their requirements and the development department wrote them down and attached the requirement specification with the contract. Both sides spent quite a few time to discuss about the implementation and appeared to have gain mutual understanding. The development was started. Several weeks later. The original business manager was replaced by another guy, who was new to that company and insisted that he would not accept the system without a different implementation to the same functionalities in the contract! The development manager thought that guy was completely irrational. The general manager in A somehow was convinced by the new manager and things got stuck.
I did not care to dig out the underlying motivations of those undesirable behaviors at the time when I was told those stories.
In the second story, people in company B felt extremely frustrated. They could sue company A literally. But they would get not so much except wasting more time in the suit and losing the customer forever--the revenue of the contract would almost be halved after paying the attorney fee. They planned to surrender to the new manager, do what he said and eventually say good bye to him after delivery.
modified 12-Aug-23 21:52pm.
|
|
|
|
|
Ha-ha…
Well, first of all… it looks like a law of nature: customer does not know their requirements. They simply cannot know it, they don't have enough information, experience, or predictive skills. Of course, I don't mean simple and trivial cases. Likewise, the designer of a product cannot know the customers and their work well enough. Frankly, I would advise people to work at the customer's company for a good period of time, if it could be possible. I also cannot delve into the right ways to overcome it. Flexibility, iterations, consultations, a lot of things… and all cases are different.
I only want to say that the attempts to ignore this law of nature only make things worse. Or the lack of understanding, that this problem is quite natural. It is very naive to picture the linear requirements => implementation process.
I was somewhat surprised by your explanation of the Chinese business when salespeople take a paternalistic position relative to customers. This is opposite to the modern Western attitude, which looks submissive.
Look just at the myth “Customer is always right”. Yes, this is a myth. At the same time, everyone can see that many successful companies lead the customers and don't even listen to them enough.
Sometimes, I tell a joke (only partially a joke) that successful companies actively distribute the myth “Customer is always right” in order to eliminate competitors.
Also, it's very good to understand the etymology of the word “client”. It comes from the Roman “cliens”. It means a free person (not a slave) who depends on a patron, typically exploited by a patron. Furthermore, it is related to the practice of vote buying. Shouldn't it ring a bell?
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Sergey Alexandrovich Kryukov wrote: it looks like a law of nature: customer does not know their requirements
The reasons for unsatisfying implementation could be misalignment of both sides in the requirements communication phase.
I used to have a quite successful experience about turning requirements into implementations. At the time, I was at the customer side. I knew the workflow of the business very well, including all related data, possible branches and I could even expect the volume of concurrent requests. I was not the end-users, but managers of them. I had knowledge about their skills. Thus I drew prototypes of the interfaces with HTML pages and discussed the requirements with the vendors. The prototypes and requirement specifications had some flaws. The vendors addressed the flaws and asked several questions about them on phone. All trivia was also settled in the implementation phase. Everything were almost done via phone calls and emails, without any face to face moment. The workflow ran smoothly after the system was online.
I also had a not so successful collaboration with the above vendors. I did the same procedure alike the above. However, their programmers were still working with WebLogic and their front-end could not very well implement the user interface.
Years later, I met with some customers who had studied products from several software system vendors and compared them thoroughly. Having know which functions were useful to them, which were missing, which were useless, they could describe both their requirements and desired implementations very well. The development would be much easier at that time.
To sum up the above, a favorite successful implementation might include:
1. Understanding of business workflows and logic
2. Visual prototype demonstrating related data and procedure that reflects the above understanding
3. Essential technical skills to implement the idea
4. Feedback from users after the presence of prototype
During small talks with the developers and business representatives in the previous two stories, I discovered that the could not very well state the logic behind the workflows. A very common reply could be "the customer said so". Unfortunately, some customers even had vague ideas about their own business logic.
Sergey Alexandrovich Kryukov wrote: I was somewhat surprised by your explanation of the Chinese business when salespeople take a paternalistic position relative to customers. This is opposite to the modern Western attitude, which looks submissive.
It might be my fault of expression . Our business representatives are usually playing the "children" role, not the "parent" or "expert" role. Both Eastern and Western are submissive.
|
|
|
|
|
I don't know how I managed to invert your note on the salespeople's attitude relative to their customers. At least at this point, I won't perceive the Chinese ways as so mysterious. Thank you for correcting me.
…some customers even had vague ideas about their own business logic. You see, my point is: this is not a peculiar factor. They have a vague logic not because they neglect something, but because certain established settings limit them. Let's put it this way: when people make a contract for the development of some business software by an external company, the goals should include new or upgraded business logic, something improved. Improving business logic, still imaginary at the inception phase, requires predictive thinking. This is not a simple thing. Moreover, with time spent on their routine work, people tend to lose understanding of the business's ultimate goals and focus on their established procedures. This factor can even cause certain resistance.
Thank you.
—SASergey A Kryukov
|
|
|
|
|
Sergey Alexandrovich Kryukov wrote: They have a vague logic not because they neglect something, but because certain established settings limit them...with time spent on their routine work, people tend to lose understanding of the business's ultimate goals and focus on their established procedures
Very well said!
I should remember this!
|
|
|
|
|