Encourage or Dissourage petty questions

ssingla

In context of Microsoft Dynamics Navision version => 3.7

MIBUSO is fast becoming a sure shot solution for all the product related technical/functional issue. Congratulations to all the members and admins.

I am observing a trend that a lot of new users are posting their queries on the forum without actually trying to solve the issue themselves. For me the 3 keys to success are :
1) Hard Work
2) Hard Work
3) Hard Work

I observed the rule no. 16 of the forum which is as follow :

#16: Don't post any programming questions like i.e. "what is RUNMODAL for" or "What does :: mean" if you never read the "Application Designers Guide" or never tried to press F1 in the C/AL Symbol Menu.

The same applies to basic functionalities of Navision which can be understood by using the excellent "help" of the product.

Looking into this should the basic questions asked by the freshers without putting their head into the problem should be encouraged or discouraged?

David_Cox

This is really a personal choice, If people answer then more questions will be posted.

I tend to look at the question, how much Information is given, from this you can see if the poster has tried to resolve the problem, then make a judgement on posting an answer.

But there are two ways to post an answer, one is to give the solution, the better is to enpower the poster to find the soulution, I often post an answer rather than pointing the poster to a sample of the code, but that one of my failings.

So when a poster asks "what does :: mean", then the correct answer is look at the help, and not to post the Help text in the forum, as the user is no more likely to use the help text in future.
When a user ask's "here's a sample of my code what am I doing wrong", then correcting the code or giving an example is correct.
If a user ask's "how can I do this", then using you knowledge of Navision you could point someone to an example of the code, not all functions have help, look for DIV or MOD, in this case if the poster said "I have a calculated number what is the syntax I can use for DIV and MOD", you could say look at report 1401 Check for an example, as the Help shows nothing!

The thing I find funny is that once a correct solution has been posted, quite often there are new posts saying the same or posting bad advice, posted because there is nothing else to Answer, I do not post answers like "Yes just do what Kiri Said that is the correct way to do this", or "I agree with Johns answer", these answers just take up space!

I find that I am answering questions to the intermediate level, only on CAL Code, that is my strength, so I am only repaying the help I got when I started 10 years ago when the only forum was NOLUG and I was asking the questions.

DenSter

everybody should ask the questions that they want to ask. You have to learn how to use mibuso. You'll find out soon enough that some types of questions don't get very elaborate answers. When you've asked 10 questions to which you get short 'read the adg!' answers, you will hopefully stop and think 'hm maybe I should read the adg...'. Some of our most frequent posters and biggest contributors started out with very silly questions.

Alex_Chow

Everyone started out as a newbie. This can be forgiven.

However, if the newbie's question is generally rude or demanding, then it's worthy of just ignoring them. I mean posting like:
"I need answer now"
"Why hasn't anyone replied yet?"
"This is urgent, help me"

DenSter

All I want to say about that is to please consider that some of the people here do not speak English as well as other people, and can sometimes not understand the nuances of the language. Also there can be very big cultural differences.

For instance 'dear <name>' might sound a bit over the top for us and too familiar (sometimes I even take it as condescending) but translated directly from another language that might be a perfectly acceptable way to address someone in business. If someone says 'I NEED ANSWER NOW' we might take it as 'easy dude I will answer you when I am damn well ready to do so, in my own time', when it might just as well have been a post by someone who is desperate for an answer and feels they are in too deep.

Savatage

Also, not everyone is a developer and they never get to see the product cd and PDF's. In fact many probably don't know that the PDF's exist that's why you always see posts about books/manuals/etc.
So sometimes a mention does help.

Also I love those "Need Help Urgents" especially when they could have easily Searched the forum and found the answer without having to wait for a response.

David_Singleton

Savatage wrote:

..Also I love those "Need Help Urgents" especially when they could have easily Searched the forum and found the answer without having to wait for a response.

=D> =D> =D> =D> =D> =D> =D>

But as to the actual question posted, then I think that so long as the question is sensible in terms of the person asking it, and its not rude, and it contains sufficient information, then yes there is nothing wrong with trivial questions.

In the Beginning when I had to struggle with using a German Version of Navision (back before they translated it into English), and had no help, I had to struggle and hunt and work just to solve the most simple of issues. I think though that it would be just stupid for me to say "Well I had to learn the hard way, so should you".

Please don't deter users from asking what may be considered as Trivial questions, but do discourage them from asking questions that just don't make any sense.

ssingla

Please don't deter users from asking what may be considered as Trivial questions, but do discourage them from asking questions that just don't make any sense.

=D> =D>

Point taken.

Thanks all for participating =D>

Miklos_Hollender

Actually I wouldn't discourage petty questions as not everybody is in a favourable situation. I mean a favourable situation is where there is an actual NSC and that NSC has at least one experienced person who can help the others and the project schedule is realistic and requirements are sane etc. etc. Sometimes there is no NSC at all. Sometimes everybody at the NSC is a complete newbie (and they underestimate the project days sometimes by almost a full order of magnitude - my first project was sold for 60 days and we worked 400). And sometimes there are clients, who, well, don't have much grasp on reality. So sometimes people are in deep trouble. And it's also understandable if in this case there is a sense of urgency and even demanding.

But urgency and demanding is very often a sign that there is not just one technical problem but the whole project is badly scheduled, planned and manned and heading for a spectacular disaster. And I think in this case technical advices just lengthen the suffering. I think there are unwinnable battles when one must withdraw, and maybe regroup and attack again or maybe just give it up. For example, there are often questions about Manufacturing when it sounds as if the project is close to it's end or even it's already live, and the client is something like a beer brewery or sewing shop or something like that. That's a sure sign that an instant withdraw is necessary, because NAV Mfg. wasn't designed for that. If you are experienced in Navision Mfg. and C/AL then probably you can customize it for such an industry to a basic level in 50 days and two months. If you are not, it's 250 days and maybe more than a year when everything including reports is done and accepted. So in this cases you really shouldn't try to add small technical advices because it will just lengthen the suffering. Advice to stop the project right at that second, migrate back to the legacy system if it's already live, and reschedule the project by months. That's the only thing that will help.

What was the result of that first project of mine? I lost 10kg of weight, worked 14-15 hours for months and got close to a nervous breakdown from stress, frustration and anxiety/anger. OK I learned a lot but did it worth it? And for them it still resulted in something quite clumsy to use and it will probably ever stay this way because they are absolutely unwilling to spend more money and nobody will work 100-150 days for them for free which would be needed to properly redesign all the cr*p I made there. Really, it would have been better for everybody to call it a failure, stop the project, and restart it after a major rethinking.

Be careful to not give technical advice in those cases when it would just lengthen the agony projects already doomed.

Alex_Chow

David Singleton wrote:

...but do discourage them from asking questions that just don't make any sense.

It'll save on some hard drive space as well.

ssingla

Miklos Hollender wrote

Be careful to not give technical advice in those cases when it would just lengthen the agony projects already doomed.

:shock:

Well doing this will mean that as soon as something major goes wrong in the project , leave the project, replan and redo. I guess a lot of times you can actually save the projects putting the right person with right knowledge & experience. We can not leave the hope if some disaster happens.
Try try till you succeed.

Joseph_Abou_Nader

ssingla wrote:

Miklos Hollender wrote

Be careful to not give technical advice in those cases when it would just lengthen the agony projects already doomed.

:shock:
I guess a lot of times you can actually save the projects putting the right person with right knowledge & experience.
Try try till you succeed.

Putting the right person with the right knowledge & experience is the problem we are facing in implementations...especially that the clients don't want to pay for getting the right one...so what to do in this case...???

David_Singleton

I have been working with Navision for a long time, and most of that work has been fixing up other peoples mistakes. Last year I decided that I want to try and help people do it right from the start so that they don't have to fix things up later. It costs a lot lot more to fix something than to just not break it in the first place.

Thus helping someone with what may seem like a trivial issue, is much better than having that person go off on their own and do it wrong.

Of course the best solution is to have properly trained implementors, and to have all new implementor mentored in their first implementations. The customer of course should not be paying for this mentoring, the Partner should be amortizing this as a training cost. This is one of the reasons that consulting services in this industry are quite high. If you don't have experienced Navision personnel on staff, then use freelancers to fill the gap, by far this is your cheapest solution.

The point is that you are not doing your customer any favors by cutting corners in the implementation phase. But in fact most problems arise when there is too much development done in the beginning, because the implementation team did not have enough knowledge of what is already in the base product and how that could be best used by the customer.

Miklos_Hollender

you can actually save the projects putting the right person with right knowledge & experience

That's true but I think that happens quite rarely. I only saw a project team change when somebody quitted.

David_Singleton

Odd, I have seen a lot of cases of the project team changing. Of course I have also seen a lot of cases of the whole NSC changing, but that is another story.

ara3n

It happens from time to time in our company. It usually has to do with scheduling and availability.

Miklos_Hollender

Well, when there are people with different levels of experience available it might change, but on the other hand, if there is at least one person of enough experience around then the project cannot be really blown badly, because he will object to the really bad decisions. I'm speaking about the projects when there is a newly starting NSC with everybody being a beginner.

David_Singleton

Miklos Hollender wrote:

...because he will object to the really bad decisions. ...

Right :whistle:

Miklos_Hollender

Y'mean David that the evolution of a Navision consultant is something like

1 month: Innocent Lamb
3 months: Surprised Lamb
6 months: Vacuum Cleaner (or Sacrifice Lamb)
12 months: Zombie
2 years: Slave
4 years: Mr. Fix-It
.
.
.
10 years: Pain In The Backside or in other words: Mr-Dont-Do-That-That-Way?