Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Do you use a formal event to get people talking in your IT department? Like a monthly meetup in a social place, a internal wiki/chat space or just a regular "information market" with some presentations about technology or projects made by your staff for your staff? Do you invite Sales people to participate or is it a closed event for programmers only?
How do you get people to participate in these events? Do you allow them to spent work time on knowledge transfer? Or do you understand it as an integral part of the work time?
I wonder how to monitor the progress of knowledge transfer itself. How do you spot critical one-person spots of failure in your projects? There are several methods to avoid it, like staff swapping or the "fifo" attempt on bug fixing.
Note: Ok, this is a very very noisy question and I hope to fix it after a few comments. Sorry for the mixup.
edit: My personal experience is that there is a very high barrier for people to start contributing. It looks like they won't put in the (minimal) extra time to edit our wiki, or spend the hour in the afternoon to talk about technology topics with the developing staff. It's like people don't like our wiki, our document management system or the meeting. Maybe it's because it's all free-to-use and not forced by the management. But I don't like to force people into it - but is it the right way?
One example: Our wiki holds pages about projects, telling who worked on it to get a first contact in case of questions. But nobody besides a colleague and me is creating this pages...
Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?
The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.
This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge-base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.
I think all of the above. But you're forgetting the most important way.
The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.
I think it depends on the knowledge you are trying to transfer. I've found the following:
Technical Knowledge: "How to guide" with screenshots and a short demo - similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.
Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.
Soft Skills (people skills): social meetings/outings/informal events etc.
Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.
Mauro
At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co-worker.
One word: Lunch
You should encourage people about things that you want them to do. You should "feed the animal". Look at stackoverflow; what do you think about badges? Why do you think this wonderful things exist? Thanks to ego, there is nothing you can't get it done. Give them badges, real badges, wearable badges. They will wear with happiness, they will do with happiness.
Btw, yes, I am a boss :)
Although i am still a student, when i did work experience 12 months ago, the all IT departments from within the corporation (I was 'working' for large corporation which own several mines in the area) would have a daily telephone conference, where each employee would say what they had been doing etc, and then talk about something new they had discovered and any other interesting tid-bits.
Couple ways I have seen so far:
Wiki is suitable for internal knowledge, for example environment, project specific topics.
Open doors policy
Encourage asking questions.
Voluntary presentations. Find out who have special knowledge and make it easy and attractive to set up a short presentation about it.
Project post mortem documents. A wrap up meeting moderated by someone outside project team held after project is finished or terminated.
Compulsory presentations.
Project presentation when they go live. Technologies used etc.
In case someone is sent to conference, he should have a presentation about new technology he saw.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently got promoted to be the Project Manager/Supervisor. What do you think the leadership style a managerial role in Programming Dev't should have?
What's your style?
Hands-off, servant leadership, unofficial or "tribal" leadership over traditional management, seem to be all the rage these days.
Basically getting out of the way and allowing the team to get their job done seems to make sense to me, but it all depends on the culture.
I would say an effective manager would already have a style, and know how he wants to work, whereas a less effective manager would probably learn from other senior managers and simply emulate "however things get done around here". Actually in a lot of places the latter is the only choice.
If you have the freedom to do things the way you want, I would probably prefer to borrow ideas from the agile/lean camp than the more traditional PMI/Prince2/PMBOK camp, but it all depends really.
The job of a manager is to get out of the way and let the developers do their jobs. If they encounter an obstacle it is your task to remove the obstacle.
I do not believe to simple management guidelines. In an ideal world, the job of a software manager would be to just provide food, computers, electricity and salaries, but we are hardly in an ideal world.
In a way, being a manager is a highway to frustration. There are few opportunities for a direct contribution to the project, you spend most of the time on planning, meetings, writing reports, and proposing future projects. In a nutshell, you have the responsibilities, while they have the joy of building things. In order to avoid quitting the job due to lack of fun, one needs to find a proper motivation which would justify the troubles.
Now, different people are motivated by different things. Some people like to participate in group efforts, some like the achievement in building things which can't be built by a lone enterpreneur, some like the power, some like the money. I think that a management style should be tailored to the intrinsic motivations of all of the involved parties. For example, it is useless to try to motivate your coworkers with money if they are primarily interested in building cool things (and vice versa).
A key competence in managing people is being able to address conflicts as early as possible. The conflicts range from trivial (X keeps committing buggy code to the repository) to critical (we need to hurry up in order to hit a deadline). I think it is very important to be able to express such concerns frankly and clearly, regardless of the managements style. Thus, at the end of day, oral communication capacities would be at least equally important as the management style.
I dont think it matters alot what style you choose. When leadership is "broken" it usualy is due to more basic things not done right.
Consistency: stick to your style unless you are sure it doesnt work out.
Honesty: Might seem obvious but when "fooling arround" too much with carrot and stick it can get out of control
Respect: Tech-Guys have all different characters but grasping what they value is easy - being passionate about technology and using it in professional way will open hearts. Waveing about your iphone showing off fancy looking but technologicaly trivial apps might result in the opposite ;)
Lead by example: You techs do extra hours? You do extra hours too!
Motivation: You dont need a jungle camp every 3 weeks but you can still help everyone to feel better about seeing each other more often than the family. Implement a friday afternoon beer-session if that is acceptable (be strickt about times though, no drinking before 6pm for exmaple). Show interest in what people are working on even if you are not part of operations. When working on abstract subjects people can have a hard time to put into relation what value they add to the company and to the team. When "in the jum" programmers particularily can become like lone astronauts - Having a broader understanding about your business you will need to remind people about the mission (though thats PM tasks mostly, but no PM is perfect too)).
In the end you are good leader when your team says "WE did it!"
There are plenty of methods with catchy names, but in general I prefer the management style to be lightweight and encourage communication.
I suspect a lot of us have had the experience of having to spend more time filling out forms than actually developing. Than is both frustrating and unnecessary. Controls are important, but a new form is not the solution to every managerial problem.
As far as communication goes, many managers seem to believe that it will work if everyone reports up to them and then they send the collected information back down. That can really lead to disaster. The team needs to communicate with each other well and often.
Finally, I'd like to throw in that as tempting as it is to take a new resource for a project and get them developing as quick as possible, I think it will always work out better in the long run to hold off and get them properly trained and oriented to the project.
My style is a combination of Attilla the Hun, Napoleon Bonaparte and Nelson Mandela. Whatever you do, don't try to adopt my style.
More seriously, to be a good leader you have to develop your own style and you have to integrate that into the culture of the organisation you work in. So, the answer to your question must start with asking yourself some penetrating questions and giving honest answers to them. You must also take some time to understand the traits of the individuals in your team and figure out what makes them tick and how to motivate them as individuals. What works with one may not work with another.
And, while I'm writing, I'll direct a passing kick at the respondents who suggest that it is a manager's job to get out of the way and let the team work: it's the manager's job to manage, you have people you work for who have certain expectations of you and you have to pay attention to them as well as to the losers on your team.
I write 'losers' because you have just been promoted and they haven't. Sure, you have to lead them to great achievement but you won't do that by keeping out of their way, you'll do it by leading them in the right direction, with the right mix of carrot and stick. Oh, and don't let them know that you think they are losers, it will upset them.
First of all; if you try to adopt a "style" that's not your own, you will most likely fail. You basically just have to be yourself! (That's probably why you got promoted in the first place) That said, there are some theorems to embrace, one beeing "you can always be a better leader" ;) I guess that's part of why you posted this question. My advise is to support your co-workers, and remember that it's your job to make them as good as possible. Try to keep yourself on top of all that happens within the project and encourage communication within the team. Agile style development helps with that. Also, try to put yourself in your co-workers shoes and try to imagine what they expect and want from you. Best of luck
There is no one "style" that you can or indeed should focus on. The reality is that you are now a people manager and people are all different. You need to learn to recognize the differences in the people you are managing and respond accordingly. This is a technical role, so if you have some technical understanding then this will assist with gaining respect of the team.
Some people need to be told what/how, some people need a gentle prod and some need full ownership of a task. Learning to spot the differences is where you need to apply yourself.
Typically people fall into 4 distinct camps with different names depending on the management course of the day :)
Beginner, highly motivated, not much experience, needs a more directive approach
Learner, more capable, but may be experiencing frustration, needs coaching
Performer, very capable but may lack confidence, needs supporting in their approach
Achiever, capable and committed, needs delegation of tasks
Management 3.0 Leading Agile Developers, Developing Agile Leaders by Jurgen is a book dedicated to answering this questions. http://www.management30.com/. His home page is here http://www.jurgenappelo.com/
In his book and class, he refers to Martie, the Management 3.0 model. It is composed of
Energize People
Empower Teams
Align Constraints
Develop Competence
Grow Structure
Improve Everything
An excellent introductory presentation can be found here: http://www.slideshare.net/jurgenappelo/what-is-agile-management
Jurgen's two key takeaways.
A software team is a self-organizing system. Support it, don't obstruct it.
Agile managers work the system around the team, not the people in the team.
Enjoy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am a first time intern at a large corporation and I created a GUI tool that lets my coworkers visualize the log file that their product produces. The tool, known as MRI, is nearing completion and I face a conflict.
One party, (Two ambitious Indian guys that live in California) want me to adapt MRI to a new format and to display much more detailed information. The current version of MRI is built around the idiosyncrasies of the 20 year old log file format. In my opinion it is a bad idea to attempt to grow a more powerful, more universal tool out of a less powerful and idiosyncratic one (Better to start from scratch; something I probably don't have time to do).
The other party is composed of several marketing types and my father. They are drooling over the shiny new GUI that I slapped on top of their crazy old log file, and every one of them wants some feature that would help them with their day to day work.
Whom should I please? I just want to code. Which path will lead to less dumb conflicts like this?
Sounds like you are getting your first taste of the world of a manager! I'm doing exactly the same thing 10 years later, with a much bigger budget and head count. So it never really ends.
I love the answer about doing some time estimates for each requested addition, and then sitting down all parties and working on a negotiation that gets the greatest degree of satisfication. I'm betting that since you are an intern, and many of the people you mention have seniority, that they will be able sort out amongst themselves who has the biggest stake and most power in the situation. But if not, don't hesitate to act as moderator -- after all, this is your project.
Other things to think about:
Types of stake holders:
Customers - the person who controls the budget is often the most powerful of stakeholders, after all, they control your ability to do the work by controlling your funding. For an internal tool, this is probably an internal stakeholder, but it may be someone from a non-engineering group, if this tool is for a non-engineering purpose.
Users - in the long run, users often make or break a tool. They definitely determine the tool's longetivity. It's not unusual, though, for users to lack advocates. And in a big internal project, it's entirely possible that users are not the customers.
Technical Management - particularly when you are an intern and when you are working on an internal project, technical management is the group that's most important for you (as an individual) to please. They may have their own stake in the feature set, as they may be looking for a certain feature path for the product that fits a long term technological end game. Ideally, they should be on your side, and helping to figure out the best feature set.
In a big company, hopefully these roles are really well defined. Probably with an org chart. But not necessarily. And in a group that's used to working together, they may not make it really clear to a new comer exactly what the official roles are. As the guy doing the work, you're job should be to accurately and honestly tell them your best guess on what effort it will take to get the feature done. And to be open to ideas for making it cheaper/easier.
Negotiation:
The best negotiation advice I've ever gotten was "A good negotiation is one where everyone thinks they won". Sadly, the frequent outcome is that everyone feels equally screwed. The trick between every stakeholder leaving happy and every stakeholder feeling beaten down is to see the big picture and be innovative about getting everyone's needs met. In the end, no one really cares how you do it, if you can make their jobs easier, they will be happy. So finding features that serves everyone well can be the key to resolving the conflict.
Being able to do this well will really make a positive impact on your bosses. This is an extremely rare skill, and this type of finesse does get noticed.
Not having it does not mark you as a pariah, however, not many engineers enjoy negotiation. And it's never worth making every engineer be good at it. It's far better to find an engineering manager who is good at negotiating and to let them be the "speaker for the geeks", so the rest of the engineers can do their work in peace. :)
Sit the two parties down in the same room. Show them a list of the features each has asked for and how long you think each will take. Then explain that all of it is possible but all of it takes time, and ask them to come to agreement on what they would like when. Note down what is agreed and mail it to everyone afterwards so there is a record. Don't forget to pad your estimates to allow for testing and debugging time.
Alternatively, work out who the person directly responsible for managing you is, implement what they tell you (feeding back estimates of how long each thing will take) and tell anyone else who asks you to implement anything to go talk to that person to get it on your schedule; then doing the above management work becomes their problem.
Explain, if doing one of the above does not cause the matter does not resolve itself, that the Californians' features would require a refactor, and if you are going to do that you would rather hold off implementing any features for the other party until that is complete since doing the same work twice is wasteful.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have been in the IT industry for 10 years now but have worked in "traditionally" managed project teams (both well managed and badly managed ones).
I have heard of the "new" scrum or XP type of project management and yearned to be part of one (as s/w folks we always like anything new I guess) but have not got an opportunity.
My question is this - what are your experiences in moving to the "new" way - was it significantly better or worse or not any different? Has there been any project success rate improvement when using XP way of development or it is same as any well managed traditional projects?
This should not be a political question but just your experiences as you have moved to the new world or experienced at least once and back.
Thanks in advance
Before I ever heard of XP, I had a really good manager (Mike) at an early job I had. He was used to managing engineers and transitioned to managing software. After a few bad working experiences I looked back at his style versus typical project management I had before and after working with him.
Met with everyone at least once a day but gave us space to work
Used a whiteboard with two columns, people working and what they are working on anyone could look at that board and see if something had been done or was being done
Had everyone cross-train. I learned rcs and then cvs there and how to use make files
Ran productive "post mortum" when a task was completed. He would ask question like "would it have helped if X?" or "next time, can we try to..."
Kept everyone working on short tasks and managed our time so we always working on something but never had a ton of stuff piled up
Mike did everything on paper. He would keep notebooks and index cards with him. He insisted that anything asked of him by management be converted into manageable tasks, often written on note cards. He refused to have anyone work on anything that couldn't be clearly explained or had a clear objective. He would ask the VPs "what do you mean by faster?" "What kinds of metrics are the reports meant to show?" "Why should this be a priority?" He seemed to have near infinite patience in writing out what needed to be done and what was meant by "done"
When I first read the XP book, I was amazed by how much was familiar as "the way Mike worked"
It seems that Agile is just about implementing a set of best practices and evaluating how they work in your environment. When they don't work, change them. When they do work, stick to them.
I think the real problem with traditional project management is that more often than not, it doesn't really exist. I'm amazed by how many shops claim to use RUP or Code Complete or even Agile and don't actually have anything recognizable as project management. Sure, there are meetings. And people called project managers. But ask a simple question like "what has been done on project X" or "what is left to do on project Y" and no one has an answer. They have to dig though emails or point to a comically inaccurate MS project file.
If a person claimed to be on a diet and couldn't answer questions on what they were eating or how they were exercising; would you accept that they were really on a diet?
You take your old baggage with you when you go. Meaning that any project management bad practices you had before will still linger.
However, I will say that things improved greatly when we began to close the loop between us and the customer. Greater and more frequent feedback and prototyping with the customer means far fewer moments of the customer saying, "This is not what I wanted."
I've used (a slightly modified) Scrum before at work and here are my thoughts:
The daily meetings and burn-down provided motivation to make progress on tasks.
Our manager could talk to colleagues across the pond and show them "this is what we're working on this month."
You knew exactly what tasks you needed to get done, and had already estimated the time required to complete.
When priorities changed (new tasks, important bugs added), there was a well-defined process to handle adding them to the sprint or simply pushing them to the backlog.
These are lovely answers, but I think everyone's confusing project management with development/design methodologies.
I'm on a team that started Scrum a few months ago and we seem to be getting things done faster and with much less "waste" (projects that are scrapped). Just my observations from our small team (4 devs).
I've found the overall move to Agile/XP practices very positive, in many ways it front loads quality into the project/development process. You'll need buy-in from management and from the team to really see success...a few suggestions:
trial any change with a small project (2-3 people)
understand what areas your current team can most improve (quality? productivity? time-to-market?) and incorporate a few Agile/XP/Scrum (what ever) processes in...don't incorporate them all in at the same time and understand which processes address which issues prior to any change
if possible - track those areas you're looking to change and compare to another project running at the same time (the mere focus of improving something often is enough to improve it ,there's a study/term for this, but I forget what it is)
sometimes you'll see a dip in performance as you begin a new process, this is part of the learning curve
never assume that a good change today will remain a good change tomorrow, always review your project areas and be ready to change any process at any time
no change remains good forever, just like refactoring code, refactor your processes
ensure you get buy in from the team and management, you can't force success
I like some of the things the agile approaches do, but I also value some of the things traditional approaches do.
Both can work, as can a mixture of the two, which is what I find works best for my team now. I have implemented incremental development and it really helps us; iterative development is a little harder and we're still working on that. However, we have a variety of constituents, and many of our stakeholders (and PMs) prefer traditional artifacts and milestones. So we have to keep finding the right balance.
I have also found that even more important than the methodology is the people implementing it. Good people find a way to do good work and get things done regardless of the methodology, although certainly the methodology can have effects on efficiency (and morale :) ). Poorly aligned resources, however, can use the finest methodology and find ways to deliver poor results.
For developers, the great lessons of XP & Co. are shorter release cycles, and a more evolutionary approach - in the sense that change of requirements is accepted as a natural part of any project. Also, Customers suggest solutions, but designers and developers need to understand the problems.
Lessons for managers: Developers are not exchangable spec-to-code-converters, their individual strengths and weaknesses can make a productivity difference of 10 or more for a given topic. Knowledge and experience are the most valuable skills in your team, and developers can teach each oterh. Managers need not understand what developers do in order to enforce desired results.
XP & Co. are usually mixing solutions to these with the problem to make a company change. The heroic XP consultant singlehandledly saving a doomed, delayed and derailed project acts as large part as a buffer between development and management. But if you are looking at what to learn, you have to separate these aspects.
What I learnt in the recent years is that bugs aren't a personality fault, and that the sky doesn't fall when specs change. I've learnt that while design errors are still the most expensive to make, there isn't a single "perfect" design. Instead of getting one thing right we need to implement safeguards that of all the many details none goes wrong - and I've learnt to use the leeway between "right" and "not wrong" to our advantage.
My experience has been that I prefer to use Scrum over traditional approaches as it hasn't happened often that requirements could stay unchanged for the length of a project where usually projects seem to run at least 6 months to my current one that is over a year.
There can also be the case where there isn't any project management and everyone just scrambles to "make it work" so having some formal structure is good over nothing. There is something to the question of how well does the team come together and egos rarely appear as it isn't someone's code but rather the code of the team and there is a kind of group think where while each person has their view, no one tries to make everyone else see things that way.
At times it seems to me that some Scrum and Agile approaches I've used end up being like rapids instead of a big waterfall. What I mean is that the cycle of gather requirements - Analyse and Design - Implement - Test - Deploy and get updated requirements seems to be repeated over and over so that what comes out in the end would be extremely hard to state at the beginning of the project unless the project sponsor could give very detailed requirements that would never change.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.
I believe that the following techniques are extremely useful to improve the information flow within the developers team:
XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
"web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.
Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
I'll add a few more
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish
Socialization and common goal always encourages exchanege of information.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How do you show your clients/employers that you understood their requirements?
What do you recommend to use? Use-Case diagrams? Flow-Charts? Data-Flow-Diagrams? Decision Trees?
I'm not really asking for a very detailed answer. Just something simple to help me communicate with the person who wrote the requirements and to see if both of you are on the same page.
I usually put together a PowerPoint deck fairly early in a project, giving a high-level overview of the project, along with some architectural diagrams (the simpler the better) and screen mockups/wireframes. Then I have a "kick-off" meeting for requirements review, and talk through the business problem and proposed solution.
I simply explain the requirements back in my own language, supplying my assumptions and adding in limitations.
The requirement may be "Button turns green when clicked"
I would ask "Ok, so when the user clicks on the button, the background color of the button turns green, but the text stays the same color?"
Basically prompting the person giving the requirements to explain how THEY envision it working.
My role has a lot of requirements gathering. The best way I find is a two pronged approach, talk through a PowerPoint presentation keeping it all simple and high level, and showing a Proof of Concept or a mock up. Walking and talking the customer through will see them responding with many "what if's" such as "Can I chance the colour?" this gives everyone a broad idea of what they are getting. If you can get something the users can touch and play with that works really well at uncovering the hidden what if.
Then, back this high level up with really detailed low level requirements. Spell out the dotted "i" and crossed "t". Get the users to read through and sign them before anything more than the POC is done. Generally word with a lot of screenshots works well.
Unless the users can bring you UML's and data flow charts, don't use them in anything the customer sees or signs. If it is signed by the customer and you had to regigg the back end to meet a "what if" you have to totally get everything resigned.
The final thing is to ensure that the customers can talk to you in their own words about their requirements and spell out what they are getting. One way to do this is to sit in on any middle management sell to higher management.
Don't try and bamboozle the customer, if they want something changed at the last minute, explain what the cost will be, in time and money, and ask them if this totally required. Doing this, will often stop people making trivial changes, and force them to think about why they want the change.
Requirements are getting what the customer needs from what they say they want.
Edit-
To the point about showing screenshots early- this sometimes requires a good PM to let the customer know the time scales and where everything is at. If the PM helps to set some decent time frames and expectations, the customers won't get excited. The good thing of POC and screenshots is people get an image of what it could be like and can often work that inside their minds.
If you want to avoid screenshots do a wire-frame look or use a whiteboard and 20 mins of drawing. Just remember to save the whiteboard as a photo before you whipe it.
Whiteboarding (and the good old OHP) can be a godsend to requirements gathering- developing a good clear style of drawing concepts can save hours in workshops.
Flow charts tend to confuse some non-technical people (ie clients), as well as data flow diagrams. Use Cases are good and understandable, as well as Business Requirement and Technical Requirement documentation, possible some sort of rough wireframe sketches.
It really depends wich requirements you're talking about.
Functionnal requirements? Maybe that UML is the rigth tool for. But I would prefer a test o test specifications
GUI requirements? Nothing beats a paper and a pencil.
Security requirements? By describing the limits of your security, you avoid unexpected deceptions.
Reliability requirements? Both testing mechannism, and software/hardware backup/recovery plan.
Other requirements: depends of your client.
But anyway, keep in mind, and explain to the client that requirement WILL change during the development phase and that it will always be a discussion and a compromise between cost and functionnality. Being honnest give more confidence to your customer.
I think that the best way to show that you really understand the client idea is to build prototypes.
By the way I was present in the last edition of the Requirements Engineering conference and in one of the workshops (MERE), Siemens was showing and interesting software based on composing a video of the client idea (it was for projects not limited to software) just to ensure that all the requirements are fully understood.
Any way, the thing is that some times a creative way to show them is better. Don't limit yourself to the standard diagrams.
I have had good experiences with creating a simple vocabulary, with terms from the domain and their meanings and relationships, and then go through it and make sure everybody agrees on everything.
Writing and discussing the vocabulary forces you to think, rather than just thinking that "we'll figure that out later".
It's no silver bullet, of course, and should be used along with other means such as a functional requirements specification and possibly a prototype.