Conducting customer research for the internal project might be tricky. First, one is tempted to think that actual research is not needed. Shouldn't you know it in and out already? Aren't the expectation clearly communicated? Isn't that you are solving your own problem? To the same extent, all the above is true. But due to the human and organization nature, one can end up building something unuseful or broken, just assuming that the information loopback is not needed.
So where is the point? All the data sources are available. There is no barrier nor procedure that blocks you from obtaining data. You are encouraged to collect it regularly. So why it fails so often?
One time check
Unless you make it a habit to collect the feedback in a repeatable way you may end up with the assumption that you know where are you heading. You do the check once, looks good. What can be wrong? Automate the feedback process, and keep on looking at data on a regular basis. You will not get as much data (number of internals is far less than external consumers) but this shouldn't be neglected. That leads to the next point...
Not representative data
Let's assume you are working on an internal library. There may be several different groups using it. One may like the direction you have chosen, others don't. Obviously, sometimes the goal is not to cheer everybody. But if one simply closes eyes on the feedback that doesn't fit his vision, it's fair to just communicate it clearly. They may find an alternative. If we want them to be our users we should treat them with respect. Acknowledge the requests and try to address them. This may end up in a hard discussion. And this is where the last point occurs...
Personal bias
This can't be totally eliminated in the environment that people might and tend to know each other well. If you ask for non-anonymous feedback you may expect that part of your data will be useless. It's like asking your mom if your idea for the multimillion business is brilliant. In most cases, it's a waste of time. Give your users the comfort of saying critical things on your work. This is the fastest way to make it better.
IT Management Research
What can you do to make IT project go smoother? Is there any scientific research backing your guts feelings? Can you verify common sense approaches or the latest trends using scientific methods? Is it in deed working?
To think or not to think...
Thinking requires time. Although this is obvious I seldom got an answer: "I need more time to decide. Let me think."
It should be the default option unless one spent some time before a question actually thinking about the given option.
- What do you think about option A? Is it better than option B?
- Yes, the one will work.
In many cases, this is merely the gut feeling we have. In order to make a judged statement, a mental model needs to be created. One needs to decide what factors are important, how they relate to each other, and how they impact the result. The next step is to collect the data. Only after that data analysis needs to be made. At the moment the answer: I think option A works better makes sense.
Think!
PS. It is better to ask your customers what factors are important for them. It is even better to ask what similar decision they made in the past and how do they see it now. What would they change?
It should be the default option unless one spent some time before a question actually thinking about the given option.
- What do you think about option A? Is it better than option B?
- Yes, the one will work.
In many cases, this is merely the gut feeling we have. In order to make a judged statement, a mental model needs to be created. One needs to decide what factors are important, how they relate to each other, and how they impact the result. The next step is to collect the data. Only after that data analysis needs to be made. At the moment the answer: I think option A works better makes sense.
Think!
PS. It is better to ask your customers what factors are important for them. It is even better to ask what similar decision they made in the past and how do they see it now. What would they change?
What is considered to be a decent GIT comment?
Software code or another form of a document is considered to be a result of the creative work of software developers. However, in many agile methodologies documentation is assumed to be overwhelming overhead. Programmers are to write code, one can assume. And that is true to some extent. It is claimed that the best code documentation is a suite of tests that passes automatically on each build. This actually, is also a code.
Despite the fact, even the most orthodox software developers put a few lines of unstructured text into the product. Comments are inserted into the code to explain the logic behind the proposed solution. What the code is doing could be understood by analyzing the structure. Comments are essential to learning why the given code is written:
/*
* This variable is used privately to keep track of whether or not
* reboot_type is still set to its default value (i.e., reboot= hasn't
* been set on the command line). This is needed so that we can
* suppress DMI scanning for reboot quirks. Without it, it's
* impossible to override a faulty reboot quirk without recompiling.
*/
int reboot_default = 1;
source: kernel/reboot.c (Linux repository)
The same could be applied to the comments inserted into the repository as a part of the committing process. Although the structure of the comment is important it must provide meaningful information to the reader.
In GIT each commit is described within the commit message. There are many hints and golden rules created to help create the messages more useful. Most of the guidelines are addressing the issues of the text structure (indentation, white spaces). The quality of the content is way harder to be enclosed in the set of hints. Commit message is well described and illustrated in the original GIT source code documentation:
[[meaningful-message]]
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, i.e. what is wrong
with the current code without the change.
. justifies the way the change solves the problem, i.e. why the result with the change is better.
. alternate solutions considered but discarded, if any.
source: Documentation/SubmittingPatches (GIT repository)
In other words, the message is to describe what and why instead of how the solution is provided. It explains the context of the change that has been put into the source code. Checking the compliance of the message with the formatting rules can be automated. Humans used to perform a checking if the message is meaningful in the process of the commit integration.
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://www.theserverside.com/video/Follow-these-git-commit-message-guidelines
https://who-t.blogspot.com/2009/12/on-commit-messages.html
Subscribe to:
Comments (Atom)
Research in your own nest
Conducting customer research for the internal project might be tricky. First, one is tempted to think that actual research is not needed. Sh...
-
Thinking requires time. Although this is obvious I seldom got an answer: "I need more time to decide. Let me think." It should ...
-
Software code or another form of a document is considered to be a result of the creative work of software developers. However, in many agi...
-
Conducting customer research for the internal project might be tricky. First, one is tempted to think that actual research is not needed. Sh...