How can a person establish a good meeting with his staff on a project? its for software engineering?

Answer 1

An excellent guide to the problems software engineering projects are prone to is a series of articles about the "case of the killer robot". It is a fictional account of a malfunctioning industrial robot. A software glitch resulted in a worker's accidental death, and the origin of the error is traced to its source and then examined as it evolves.

As reguards group dynamics, what stuck me was the personality of the main programmer. He was essentially a "loner" and although a very good software engineer, his vanity seriously impared his ability to deal effectively with peer review. I have experienced this in my own career in fact. I made the mistake of criticising the system administrator's database program. I wasn't invited to any more computer meetings, but I was assigned to rewrite the software anyhow. Now the department is trying to implement a LIMS system and as usual, a few pointed questions has gotten me isolated once again. My supervisor began taking his chief chemist along to computer meetings. This fellow knew nothing about programming, but was a far better "yes" man than I was. I suppose it's only a matter of time before some LIMS programmer has to sit down with me and discuss things. This will most likley be a member of the LIMS team itself which is contracted to set the system up, for it is quite clear by now it will not be someone inside the department. If this seems ridiculous it is. Perhaps a suitable explanation might be that I am a government employee.

Answer 2

Make sure that you prepare and pass out an agenda for what you want the meeting to accomplish, to everyone attending, and make sure that you stick to the agenda.

Make sure that you maintain control of the meeting.

Make sure that everyone that has something to contribute gets a chance to speak.

Keep a record of what is discussed, and after the meeting type up a set of minutes and distribute them to all attendees.

Answer 3

Rule a million: All application exists (or a minimum of *would desire to* exist) so as to remedy a situation of a few variety. Microsoft be conscious is there to remedy the subject of modifying records and making them particularly. Notepad is there to remedy the subject of rapidly modifying small records. This of course means that a application challenge that has gotten off beam of its situation is doomed to fail - and positively, a important reason for challenge failure is changing the standards in mid-flight. yet another implication is that the layout must be completed by using somebody who easily is familiar with the subject. as a consequence, your ultimate guess is for the gang to think of of a few situation they actually understand, and write application to remedy it.