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 3 years ago.
Improve this question
I have worked on a few multi-cultural projects (programming languages are universal, social norms and mores are not) and it's always interesting to see how the team dynamic works cross culturally. I'm not talking about coding differences, I'm talking about basic ground rules for communicating cross culturally at the start of the project. Good team building exercises, using small teams vs large teams, isolating functionality to make all developers feel as if they are contributing, fostering respect, and etc.
In our increasingly multi-cultural industry, what works and what has failed?
I looked into this in some detail a few years ago and came to the following conclusions (in no particular order):
The outsourcing organisations we looked at (all Indian) had a very strong process base. I don't know if this was cultural or just the way they chose to set themselves up (possibly a bit of both) but we felt this was likely to be a real issue.
They were talking about being a five on the Carnegie Melon Maturity Model (Google it but basically that means they've defined and documented everything up to and including what happens when someone farts), we were typically running around a 1 or a 2 (roughly equating to crossing your fingers and hoping for the best).
Our process level was largely driven by our clients who didn't have any interest in signing off specifications (for good reasons and bad), wanted people who understood their business and would fill in the gaps, and wanted to change their minds three times a day. As much as many of these factors infuriated the programmers in the UK we understood that they were never going to change.
This was possibly our biggest concern - we didn't feel we could come up with a process model that would work for all three groups involved (the clients, the UK based IT team and the Indian based outsource team).
So first thing is - work out what your process is and work out whether you honestly think you can make it work for all parties involved. It's easy to say "we're going to do agile" but how are you going to get that to work when one party is 1000 miles away? Alternatively if you want to go a solid waterfall route, is that realistic given your clients?
Second, understand the ingrained cultural differences within your teams.
My experience (and I obviously generalise here) is that programmers from the US and the UK willingly (sometimes too willingly) question authority and assumptions. Ask them to do something dumb and you're likely to find yourself being told that you've asked them to do something dumb in no uncertain terms and they'll then proceed to tell you what you really want.
That's not the norm globally. Many Indian developers I've worked with don't question things in the same way. That's not to say they aren't as bright, they just apply their intelligence to delivering what you've asked for, assuming that you had a good reason for doing so.
You can make a case for either of these being good / bad (I've lost count of the number of times I've heard developers question what they're told and say how things should be despite not understanding the basics of the industry they were working in), but the important thing is that they're different and they'll clash.
So the answer is likely to be that you're going to need to feel out the teams involved and, based on that, pick out ways of working that are comfortable for both of them.
Yes, get video conferencing set up, get each time to visit the other site (it makes a big difference) and where possible get people talking even when it's not strictly needed in the early stages, but most of all make the effort to understand the groups involved and design a dynamic that works for all of them - imposition of one world view on the other won't work.
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 3 years ago.
Improve this question
... and how to prove to management that use-cases can be informal and still useful?
Hi folks,
I came in the middle of a project and found out that there are no use-cases, user-stories, requirements, neither anything similar to a specification. Since the deadlines are short, the current dev team don't want to spend time on such things. I wanted to join that project, but by digging more I found out that the current development adds features just by considering their "wow-effect" and chooses what to add just by using the easiness that the underlying technology provides. I was surprised how they have managed to go so far (more than 4 months) without requirements, but this is what we have now. I believe that the way they have chosen is the most sure one to kill the product which has a good marketing value.
Am I right, and what would you do in a similar circumstances to prove the dev team/management to make use-cases/requirements before moving forward? Thanks in advance, kh.
P.S. Two copies of Cockburn's book are on the bookshelf...
You should give your colleagues the use-case spiel :D Tell them that use-cases are useful as they're:
A way of capturing business processes in a manner which is reasonably comprehensible by all stakeholders. This helps to bridge the gap between programmers, clients and users.
Traceable units of functionality. Use-cases are formed (ideally) in the analysis phase, referenced in the design phase, and can be used as sources for test cases later on.
Quick and easy to write up and useful, even if informal.
If you need more ammunition, you might want to read Use cases - Yesterday, today and tomorrow by none other than Ivar Jacobson.
If your colleagues still can't see the potential usefulness of use cases as a business analysis tool, then they're probably beyond help :P You should remind them that they're developing software to meet other people's needs and solve their problems in the long term, not to ostentatiously impress them in the short term with petty gimmicks. And so a little bit of direction and specification helps. Even if the use-cases themselves don't prove to be that useful, the simple act of coming up with them will force your colleagues to consider the actual underlying purpose of the software.
Ask questions, of both sides. Of development, ask them if they are certain that all of the ways in which they have considered using the application are all of the ways in which the end-users will want to use it; if they say they have, ask for proof. Of management, ask if they've ever used software that does everything they want, but still ends up being hard to use (they will have). These questions will seed the concept that what will be delivered might not be what is desired, on both sides; use that seed of an idea, then, to open up discussions (not documents, not at the start) on how the software will be used, and in what way any differences can be resolved. They'll get around to use-case documents eventually.
I am a product manager by profession, and my first reaction to your post is that ideas can come from anywhere, and if the dev team has decent ideas they should be incorporated into the product.
Having said that, a product can not develop a soul (a simple message) through a string of disconnected ideas that do not serve the ultimate purpose: solving the needs of a target user. And, ultimately it boils down to making the case that time is better spent on requirements/use cases that make sense for the product, while the opportunity cost of not having a clear strategy/end goal will lead to too many chefs and a jaded product message.
The ultimate way to make this message hit home is to involve other stake holders and have development demonstrate their work. Eventually, there will be disagreement and a more formalized (less cowboy) approach will lead to a more refined and simple product.
One of the problems you mention is tight schedule and scope creep induced by the devs themselves. Explain them, that by using use cases you can earn time by dropping features, which will potentially end up on the "never used" pile. With use cases you can find out what are the features customers need and will pay for and by removing unimportant features out of the scope you would have time to implement. Use cases apart from defining the scope also help to identify all the stakeholders, which might help you to focus even better while defining the scope and prevent forgetting about trivial things, which are not so apparent, but are a must if the product should be usable. The third most important thing about use cases is that they allow you to start thinking about corner cases which might be important for the customer before development and therefore you can find out with the customer what would be the ideal solution instead of letting the coder decide on his/her own under pressure of deadline.
Just show them.
Example is not the best way of educating people, it is the only one.
Lead by example focusing on extensions and exceptions. In other words emphasize the failure scenarios because everyone knows how the system should work. The real value of written Use Cases is identifying what should happen when something goes wrong.
That noted, consider you may have to live without written use cases. And, for the environment you describe, a major win is any sort of requirements documentation. Screen comps and/or prototyping are often easier to introduce.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I've been thinking about the on going "revolution" in UI design and metaphors for interacting with the computer via a GUI and I'm suprised that as long as computers have been accessible through GUI's that programmers are still searching for the best way to allow the user to interact with their programs. It seems that most of the work centers around astetics(which I understand are important) but I don't understand why we are still looking for the magic bullet in UI design.
My question is: Why is UI design and components not a solved problem with accepted and understood approaches?
Probably because like most things, design (and tech, in general) are constantly changing, being worked on and revised. To say that one of the most crucial elements in software can be 'solved' would be an understatement and would be constantly changed again. There is no true definition to the 'perfect' GUI, only because you don't know who your users will be (power users versus casual, more input required vs less).
perfection is a moving target
Jacob Nielsen rightfully said about ten years ago that users don't scroll. This isn't true anymore.
Users get trained to user interfaces. Windows 7 doesn't show a system menu icon in the top left corner for many apps (e.g. in explorer), but you can still go there and invoke the system menu. Took me a while to notice the icon was missing for some apps - while using it.
(There are probably much better examples.)
The optimum isn't obvious. Consistency is core in UI, but only deviation from consistency can lead to improvements. You just can't optimize for "most consistent" or "most creative", both will fail.
it's a cross-domain skill. How many people are programmers, designers and neuroscientists? How many CS university courses teach cognitive models and how they apply to user interfaces? How many programmers pondered muscle memory, feedback loops and cognitive load?
UI's are still designed largely by programmers and sometimes fixed by designers after the fact.
effect is hard to measure
Take the Microsoft Office Ribbon: Judging from the responses, it seems to work better for many, yet is harder by orders of magnitude for others. It was a bold step, no doubt, but was it good? Microsoft does run UI tests, and they did it for the ribbons - whether they screwed up the tests, whether office politics won over facts, or wether the backslash was just wasn't forseeable in the data, I don't know. (But I'd seriously like to)
How many shops can afford user tests? Everyone can do hallway usability, but that just ensures you don't suck.
Skimming along the line
There is low pressure for the perfect UI, there is high pressure for a good enough UI. Given the lack of common knowledge and the high cost of improvement, perfect would not be affordable. The "Apple tradeoff" involves a higher price and technical shortcomings. They are pushing the limits (good!) with bold steps (very good!), which captures a notable but not major market segment. Still they are far from perfect.
I think if you ask Henry Ford the same question about designing automobiles you would have gotten an answer that would equally apply to your question today.
And that answer is, we're still in the infancy of human computer interaction design and we don't yet have enough data to design genuinely ideal systems. And, even if we did we don't yet have the ability to manufacture such an ideal system at an affordable price point.
Much like Henry Ford could not have designed the Bugatti Veryon in his day, nor could he have built it if he could design it. Or the Prius for that matter.
No, User interfaces isn't that subjective. Ergonomical matter is a scientific topic.
Think about that :
Today, everybody uses a computer. That was not the case 30 years ago.
Today , everybody uses a glass surface to access data. That was not the case 30 years ago.
Today, you've got several devices to access your data. That was not the case 30 years ago.
Today, data is collected everywhere. That was not the case 30 years ago.
Today, you can even control your data with glasses. That was not the case 30 years ago.
There is no magic bullet. just like nature, we're talking about an evolutive and living ecosystem, in the pure darwinian way.
UI design is to make people who have less knowledge about it but can easily understand the application and use it comfortable. That is core challenge of the UI design. So it evolves just like a robot. There is no end to perfect design. As along it makes the users to use easily then it is a perfect design.
User Interface is a very subjective subject, what might be ideal (graphically pleasing, efficient) for one person or task might not be ideal for another task or even another person doing the same task.
Also, the different platforms on which GUIs are implemented is ever changing and thus needing GUIs to evolve to meet specific platform demands (touch screens, ie. lend themselves towards a completely different user interface, then a mouse based platform, or even something like an ATM)
However, there are classes and books written on the subject, so there is some level of continuity in the area that has been there for quite some time.
User Interface is a very subjective subject, what might be ideal (graphically pleasing, efficient) for one person or task might not be ideal for another task or even another person doing the same task.
Also, the different platforms on which GUIs are implemented is ever changing and thus needing GUIs to evolve to meet specific platform demands (touch screens, ie. lend themselves towards a completely different user interface, than a mouse based platform, or even something like an ATM)
However, there are classes and books written on the subject, so there is some level of continuity in the area that has been there for quite some time.
In short, TECHNOLOGY.
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 3 years ago.
Improve this question
I know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
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 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 3 years ago.
Improve this question
From time to time, there will be student attached to our projects, i would certainly like to assign him/her many things to do so can learn more. But alot of times we are resigned to assigning stuff like documentaiton, updating of ui mockup screens etc. As problem is that is it bit hard to trust the quality of work provided by students and another thing is that they are still young and their enthusiam may not be there.
How do we better utilize them such that they really cut down our workload and also in turns mean learning more stuff which will aid them in their future job opportunies?
I am afraid it might sound disappointing but it is not the best idea to utilise students to cut your organisational unit workload down. Probably, if your goal is cutting workload the best thing is not to take students. Read on to understand why.
Though you haven't specified the level of work-related expertise the students possess, nor did you mention the duration of their attachment, I assume from the tone of your question that their expertise is not sufficient to hit the ground running. It is also reasonable to assume that they are not staying for longer than 2-3 months.
The essential benefits your organisation can extract even given the limited timeframe are:
Notice and grab talented workers before they even get to the job market. Later in their working life they are likely not to be that easily available.
Turn every student into your organisation salesman. Let them tell everyone how good your product is, bring you in contracts in the future or make their peers envy their work experience increasing the pool of good candidates for your company.
Outsiders can help cast a fresh eye on your processes, procedures, product, expose inefficiencies etc.
Learn from them the latest stuff taught at universities.
Boost your time morale: Maslow theory, "esteem needs". Even the most junior member of your team becomes somewhat more senior, since these students have yet to achieve that position.
Cutting down workload means that you'd need to find a set of tasks which is fairly independent, does not require knowledge or skills that the students do not have and needs much of your team's time to transfer. The tasks cannot be strategically important in case they cock it up, not can it be operationally important. Hence you left with some dusty requests for management reports or research and development projects.
Chances are that R&D considered to be more desired work within your organisation and if you give exclusively to students some people feelings are going to get hurt.
How long are the students around for? When we have had students on-site for up to two weeks there was not much other then testing type work we could give them.
If the student has enthusiasm you code do some pair programming through a bug and let them write the unit tests for verifying the fix.
Even if you don't normally do pair programming, I find that with a junior dev it is sometimes productive to have him/her do pair programming with a more experienced developer, for the following reasons:
I wouldn't assign coding tasks to the junior developer alone, because his code would have to be closely reviewed by someone else anyway and quite probably rewritten or changed substantially.
On the other side, how can a junior developer learn if not by programming? So, you want him participating in some way in programming tasks.
You get some of the advantages of pair programming: the most experienced dev is less prone to make silly mistakes (even a very junior programmer can point things like 'hey, you made a typo there') and less likely to goof off checking stackoverflow.com every 10 minutes during the pair programming session.
Of course I also would rotate the junior with several seniors during the day, so they don't feel 'slowed down' or annoyed by the young guy for extended periods of time.
Why not assign one or more engineers as "sheperds" to the student and let them oversee their work or even better pair with them. The student will gain a good understanding of your project and real work and have a known fallback when in trouble and someone who can give provide direction.
The sheperd/mentor gains a fresh perspective, and the joy of teaching.