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 struggle with finding a good medium on communication. In our jobs, it seems like it's very easy to get lost in code and lose track of time. It also seems kind of ridiculous to send out updates for every tiny task. Even though I am working very hard on getting things done, in a company that has very active communication between other branches, it tends to look bad for me when I'm not constantly updating my status. However, if I'm working on a 3-4 hour project, I'm not going to update management for every single line of code that I output.
Broad I know, depends on the people, company, etc, but what would be a good general rule of thumb for effective communication?
You need to understand why managers need your communication. I have run development teams in the past, and I am currently a coding grunt, so I have seen both sides of the communication.
Managers usually don't have time to be intimately involved in your coding, mainly because they often also have to deal with other coders in your group, testers, senior management, product mangers, customers, human resources, etc.
Your manager has committed to deliver software, and has entrusted you with delivering some of it. Because (s)he does not have time to deal with you, (s)he needs to trust you. (S)he trusts you to focus on your work and deliver the software. If you mess up, (s)he will get hurt too.
The purpose of communication is to demonstrate knowledge of purpuse, to show focus, and to demonstrate results. Here are major forms of communication.
A high-level design communicates that you know what you were entrusted to deliver. It doesn't have to be fancy. I am comfortable with rough sketches of a good data model, detailed key use-cases, and interfaces to 3rd party software.
A development plan shows plausibly that you understand the steps required to deliver. I find that delivering working use-cases is best whether I'm a manager or a coder because it is an unambiguous way to independently verify completion of useful work.
Regular status updates are good because they demonstrate focus. As a manager, I don't care if you have worked on this or that. I care about what you have delivered. From a developer's point of view, a good time to deliver a status report is when you commit code to source code control. Of course, you need good comments to show that you are delivering according to the plan. It is also a natural time to deliver because it represents an end to a "flow" or a period of being "in the zone".
Flagging roadblocks is important because it demonstrates both knowledge of purpose and focus. A good manager will help you resolve these, but (s)he has to know about them.
Dealing with bugs is a particularly sensitive time, because a bug represents a breakdown of trust because, in your manger's mind, you didn't deliver what you said you would. Being extra-communicative here is very important.
Over time, good communication will build up good trust, and ultimately it is the quality and quantity of your work that will determine your trust.
For that 3-4 hour project, you must make status updates when you start it, when you finish it, and on any code-commits you do in the middle (but if you don't, that's fine too).
Agile methodology says you should have 2 week cycles on code development. I think the same is true on communication on big projects. I try to have a major communication every 2 weeks. That includes the status I have on all of my projects and everything. This can be in the form of an email, phone call, or face to face. The only reason to communicate more often than that in my opinion is if you have run into a road block and need your managers help to overcome it or if you are working on a project or task that they need feedback on when completed. In general this keeps unneeded communication to a minimum.
Another approach is to go see your manager directly and ask them what type of communication they want and how often. In general good managers only want updates when there are major issues or on a weekly/monthly interval. You need to discuss with them what is enough to keep them in the loop but not waste your or their time.
This is an interesting question as it high-lights the verbal capacity of a programmer who ends up getting all-consumed in the process of coding that everything else seems "irrelevant", been there, done that with disastrous consequences!
DO NOT BE AFRAID TO SPEAK UP....
If there's something that is bothering you when you code...try talk to them in simplistic terms, ultimately, management do not want to know the intracies of pointer manipulation, TCP/IP stack, control re-freshes upon WM_PAINT, mapping network drive dynamically to obtain some data....you get the drift....
Speak clearly and concisely, be abstract....instead of saying something in wrt to say...pointer manipulation and seg-faulting, just say "There's some issue with the internals of the code that is causing it to misbehave, I'll estimate an n time to remedy this and get it documented and mark the issue resolved asap" where n is a quantity of time, be it minutes/hours/days/weeks or even worse months/years....
If you follow that pattern, that's what management wants to hear, if they hear the proactive approach, that is where you gain rapport and trust, and the level of trust will deepen. There is of course a 'slight hitch' with that...the management might end up piling on a load of trust which equates to responsibility for your coding....be careful there...do not flatter yourself in thinking "Gosh, they like me" at the same time burdening you with "responsibility" of the code....there's a fine balance between communicating and what they want to hear...by the way, I absolutely hate the concept of kissing one's ass in order to get ahead...DON'T!!!!
The moral and bottom line, (my being deaf and finding communication extremely frustrating and made to feel as if I'm put down or not being listened to, it's hard to deal with that because I could easily mis-interpret or mis-understand what's been said, that's my experience of it) speak clearly and do not be afraid to speak out no matter how big or small a coding challenge is or if the challenge is insurmountable and after all, that requires team effort. Share it with the team. I would be wary if nothing is shared and each in the team are in isolation and nothing being said...that's fishy....
Ultimately, lots of communication is good, but if you're in the zone (and believe me, I know how hard it is to come out of the zone once you're in it) find other ways to communicate without losing flow.
Communication can take many forms. If you've got a list of features and can check them off in some way, communication can be as simple as firing off an email for every feature. If you have an issue tracking system, communication can be as simple as updating the issue when you fix/implement it.
To update business stakeholders on your progress? I do this weekly.
To find out from business stakeholders more details about what I need? Several times a week, sometimes several times a day, always either scheduled or impromptu over instant messenger.
To talk to a project manager? As often as it takes to make me more efficient.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can any one help me out to clear my doubts i am trying to implement an SIP application, I already have sip server setup and i have the username and password of my sip account.
Now I tried using PJSIP & SIPHON but somehow failed with lots of errors.
Then I tried with LinPhone and it worked fine.
Then copied the files from LinPhone project into my project and still working on it. (What else should I copy in my project to get going - i have copied the apple-darwin include & lib folder in my application)
I want to use G711(Both A and u) codec in the application and I can't find any header file's for that, please can any one suggest me how should I use G711 codec with the LinPhone Library in my Application?
Also can any one tell me that how many days it takes to cover up the SIP application without video functionality in it? (Audio Calls with GSM,Speex,G711 Codec's - only)
How many days will and Expert & Medium Level Developer will take to make app like this without any prior knowledge of any SIP app? (Any Rough idea according to you.)
Is there any other good open source library available to use easily to make an app like this?
Or any kind of a tutorial available? (Documentation of LinPhone is not upto the mark).
Am i going in the right direction?
Word of warning
This may sound like I'm trying to disuade you from persuing this endevor. Far from it, SIP is a fun protocol to work with (eventually) and it's very rewarding to see it all come together. You will enjoy a great deal of satisfaction at having gotten such a beast to work, and I wish you the best of luck in shaping it to your will! However, be prepared: SIP is a frustrating beast to work with.
The following timeline is based on my own experience, though I've shortened timelines somewhat due to there being two of you. Our dev cycle lasted nearly a year, but I was both the lead, and only programmer on the project, and that time includes all the work done on the UI, requirements coordination, planning, documentation, etc.
Week 1 & 2
SIP is a complex specification, with many extensions and peculiarities, especially relating to firewalls, forwarding, branching and joining. I would recommend you start looking up RFCs, and simply devote a good amount of time to reading the signalling specs, and any extensions you will need for your application, including at a minimum, the base specification, the SDP specification, and the ICE protocol specification.
That should occupy about a week if you're doing it right, and full time. For week 2, consider which extension specifications you'll need (presence indications, preconditions, conferencing, GRUU, etc) and spend the time to read those as well. Drill each other on them, it's a lot of information, and it's relatively complex in terms of how they all inter-relate to each other.
Break out the protocol analysers (Wireshark, etc) and see what the apps you have are doing on the wire. Having read the specs, you'll now be in a good position to understand why various SIP products have difficulty playing nice with each other, and, an idea of how to start working on your own app.
Week 3-6
Even with a decent toolkit, you will spend the better part of a month getting SIP to reliably do what you want it to in communicating signalling information, and writing the required infrastructure to respond to SIP signals. There are a crazy number of edge cases, and every pitfall you can imagine in concurrent processing is now magnified by the fact that you have three independent agents, some of whom will have very high latency, unreliable network connections, all trying to co-ordinate regarding the same transaction.
Don't take shortcuts, code, test, code more, look for faults and edge cases, and keep going. The RFCs help A LOT in understanding the problems you will run into, but some of it just has to be trudged through.
Week 7 & 8
Depending on the requirements for your application, just establishing the underlying connection between end-user agents will rightly occupy most of your effort to create a reliable product. You will, between the two of you, likely spend the next couple of weeks getting this part to work for the first time, and likely uncountable hours diagnosing edge conditions throughout the rest of the dev cycle of the app. Remember that there are edge cases here which require a media proxy, and a no-win edge case where the user is so badly firewalled that nothing can be done. Don't forget to handle them.
Week 9-11
At this point, your phones should (fairly) reliably connect to each other, depending on your experience and network knowledge, over fairly strict firewalls as well. The preconditions spec is very useful for decreasing perceived delay here, as you can hold off on ringing until the network layer has already connected. My experience will not inform the next layer (protocol) very well, as with Java, the media encoding and decoding was handed to me on a silver platter, aside from quicktime, which I had to do myself. I would chalk up a week or two for getting the protocols working nicely, and communicating protocol information reliably via SDP, but this may be a very optimistic estimate on my part.
Add another week if you've never worked with RTP/RTCP before, as while they're not complex per-say, properly responding to the feedback you get from RTCP can be challenging, and is somewhat of a dark art, though quite critical to ensuring optimal network utilisation and media quality.
Week 12+
Likely, at this point, you'll realise that one or another SIP product you want to be able to connect with, doesn't like your implementation, sometimes for reasons utterly inexplicable. If you need to support finicky products, you will spend the next few weeks to a month diagnosing why. If your product is proprietary, you probably don't care about this step, but it's also a way of double checking how badly you're mangling the spec. (We all do, so don't assume the test product you're using is correct either! Always double check!)
Additional
Bear in mind, the above is mainly intended as an estimate of how long it will take to get a well-written SIP/SDP/ICE based solution functioning, not the app using such infrastructure. UX is king in the iOS world, so make sure your app is compelling, and spend a LOT of time getting it right.
Even if
you use a library to make the coding easier, learn the underlying protocol! It will benefit you tremendously to understand why things work the way they do, and why the SIP universe is full of so many broken products.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Lately I have seen our development team getting dangerously close to the 'second system syndrome' type ideas while we are planning the next version of our product. While I'm all for making improvements and undoing some of the mistakes of our past, I would hate to see us stuck in an endless loop of rewriting and never launching anything.
Is there a good design / development method that lends itself to building a better version 2.0 while avoiding second system scenarios?
I have experience the second system syndrome from both sides as a customer/sponsor and part of a development team.
A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software "flexible". In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic "item" object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as "flexibility" overshadows the effort to a point that the resulting software doesn't work.
A balanced practical consideration of usability, performance, scalability, features, maintainability, and flexibility goals can bring the team back to earth. "It would be great if..." should be prohibited from the vocabulary of the team. The Scrum backlog is a good tool and the team should be heard saying often... "Let's backlog that...we don't need that for version 2."
"I would hate to see us stuck in an endless loop of rewriting and never launching anything."
Which is why people use Scrum.
Define a backlog of things to build.
Prioritize, so that things which lead to a release are first. Things which should be fixed are second.
Execute sprints to get to the release. Execute a release sprint.
Get someone who has written at least three systems to lead the project.
Try to focus on short delivery cycles, i.e. force yourself to deliver something tangible and useful to the users every few weeks or month. Prioritise the tasks based on their value to the customer. This way you always have a usable, functional application with satisfied users, while under the hood you can refactor the architecture in small steps if you wish (and if you can justify the need for it - that is, towards management / the customers, not just teammates!).
It helps a lot if you have a stable build process with a good suite of automatic (unit / integration) tests.
Agile development methods like Scrum do this, and they are warmly recommended. But of course it is not always easy or even possible to adapt such a method in your team. Even if you can't, you can still take elements of it and apply it to your project's benefit (maybe without even mentioning the words "agile" or "Scrum" publicly ;-)
Make sure you document the requirements as well as possible. While obviously you need to also manage what gets into the requirements to avoid over-designing, having a fixed scope helps prevent developers from running off with ideas or gold-plating what needs to be done and it helps keep management or clients from introducing scope creep. Define all requirements and how scope changes will be addressed.
I'm all for short development cycles (make sure you're writing tests) and agile methodology, but neither of those is a shield against second syndrome system. In some ways it's easier to keep adding on feature after feature if you're working in short sprints without stopping to look at the overall picture. Use agile practices to build the simplest thing that works, then keep adding your other requirements as simply as possible. Remember YAGNI, because when you build a system a second time, that's when you're most likely to build something you're sure you'll need at some point, something that will make the system "extensible" so there never has to be a third build. It's the best of intentions, but the road to hell and all that.
You can't get close to second system syndrome. Either you're in it, or you're away from it. You'll know when you're in it, but only after wasting a lot of resources.
Tips are: know about it (so basically we got that covered already). It's invaluable information to know what a "second system" is, and even more to have some experience with that. I think we all have some experience with that, hopefully benign.
That knowledge will often make you think twice and you'll find a solution without venturing into second-system limbo.
PS: Also know how to use your current system, that includes, maybe documented solutions, and other documentation.
Focusing on the system architecture should help e.g.
Having documented interfaces which support "loose coupling" between sub-systems
Having documented design decisions (avoid re-hashing previously beaten paths)
Hence, without going for an all out swap, the current system can be "upgraded" with more appropriate interfaces to help future growth.
Another good way to focus: assign a $$$ figure to each feature and prioritize accordingly ;-)
Anyhow, just my 2cents
I up-voted S. Lott's answer and would like to add some more suggestions:
Deliver a working product to your customer as frequently as possible. Iterations lasting between a few weeks and 2 months are ideal. Agile methodologies, such as Scrum, lend themselves well to this.
Use FogBugz for feature and bug tracking. Its features are very practical for agile projects. FogBugz allows easy prioritization according to releases and priorities. If your team enters their estimated levels of effort for each task, you can also use this to calculate reasonable ship dates.
Prioritize which features you will develop according to the 80/20 rule (20 percent of the features will be used 80 percent of the time) and the most bang for the buck. This helps keep the system as simple as possible, helps prevent feature bloat, and saves development and testing time.
Give similar thought to both new features and bugs when you determine the priority of an issue. One point of the Joel Test is "Do you fix bugs before writing new code?". In most shops this doesn't happen, but do not make debugging the system an afterthought. Also, keep a working copy of the old system to compare against when bugs are found on the new system.
Also factor in the level of effort required to maintain, and if necessary rewrite, existing code. If you have not already done this, give the team some time to code review whole files that they find troublesome to change. If the system's code was difficult to maintain the first time, this will only get worse and cause your team to spend more time on new features down the road.
It can never be avoided at its entirety. But being cautious could alleviate the problem.
You should formulate some thumb rule based on the vital parameters (scarcest resource) that define the success of the system. For example, reducing potential number of bugs might directly decrease operational cost (potential service calls to support center). But this might not be the case in every other systems. Another example, scarce use of CPU, memory and other resources might be beneficial in some cases but there could be environments where they could be available in abundant.
So simply to avoid "temptations", identify the scarcest resource (time, effort, money$ etc) and consider implementing only those that exceed threshold value.[f(s1,s2...) > threshold]
Despite the iterative development, I would emphasize on how technical debts are handled.
Links that are related to this:
Tech Debts: Effort Vs Time
Tech Debt Quadrant
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
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 5 years ago.
Improve this question
I have a challenge I need some input on.
I am currently recruiting programmers for a new development department. I am looking for people that are brilliant at their work – so brilliant that they might “lack” some other things that I normally would require them to have (e.g. speaking Norwegian and (to be honest) – social skills in order to be able to meet the customer (I’ve worked with several of them before :) )).
My issue is in regards to communication between the client (customer) and the development team.
Background: We have a strategy of becoming our customers extended development department over the next two years. E.g. they consider us as their own department just sitting somewhere else. While we are on our way towards this target, we will have to make money on smaller projects. The work is there, so I am not afraid that we will not manage to stay alive.
But – we all know that good communication with the customer is one of the key elements on providing the customer with what they actually want (we are scrumming by the way) instead of something else. How do I manage to do this with people that do not speak the language, or again, does not even have the skills to communicate with the customer (you all know someone very bright that is going into deep technical issues with a customer that hardly knows the difference between Firefox & Opera)?
I have landed on a solution where I will be the interface towards the customer, the customer will join in on planning sessions, etc., and where the team will still do the demo. But in regards to continuous communication (daily) between the dev team and the customer, I will be the one doing the comms.
I know that this is not the optimal solution – being a middle man a lot of information can disappear between the customer, me and the team. Have anyone been in a similar situation?
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
new developers to understand the customer faster
see the possible problems that may arise
your developers would contribute to the wiki since they have a tangible documentation where everyone can see how much they have contributed to the customer.
make the customer feel as if he is part of the development process
since the wiki is, by effect, a collaboration document, a common language will appear between everyone. It might not be the same as speaking your customer's language, but it will be a combination of your customer's and developer's language.
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.
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
What would be the disadvantages (if any) of automating business process for a Enterprise/organization?
Loosing discretionary error checking, i.e. numbers that look out of line;
Potentially, knowledge of how a process is operated could be lost if it is automated but not documented. More often than not, manual processes are passed on;
Accountability for the process becomes muddled.
You lose some flexibility on unplanned situations. On a manual process, you can often "work around" the process when there is something you did not expect, but with automated processes, you cannot.
The money you need to spend to automate it.
Would depend upon the process, but the classic situation where automation fails is when the automated system decides badly or masks a problem.
Another might be where it becomes a maintenance issue. Humans adapt pretty well to fluctuations in the process flow, typically automated systems don't.
Again, its a fairly vague question so it is hard for me to talk specifics. Do you have a particular process you want to automate?
It's always difficult to find a right tool for it.
You may end up ordering a custom tool and it's risky. However an off-the-shelf tool might be as difficult to implement.
It's very difficult to capture the business process right. Sometimes it's quite convoluted - especially in a big and old organisation. You may end up having 80% of cases automated and the other 20% being impossible to do at all
It's an investment for which a ROI should be calculated carefully. Sometimes you are better off just not doing anything at all.
Saying that I was involved in the projects where the automation of the business process allowed 1 person to do the work of a small department and that department was able to spend their time on significantly increasing the company revenue
Automation is set of tools and procedures to make things work more effectively,
but there might be problems:
If user support is automatic (and non-relevant), customers might start to feel that you don't care about them. Some people want personal support instead of automated replies.
If there are problems that are not covered by set of features in the system and data gets missing because of it.
If there isn't anyone to check frequently that system is still working in right way.
If automated system haven't been tested enough and errors cause big losses (financially or in reputation).
If something else goes wrong (and there isn't anyone to fix it).
Make sure that you have enough people to maintain and support your system so if automation fails, your business wouldn't fail with it. There are many examples of failures in automation of business processes so plan your projects well before attempting to do things. Think of possible (and impossible) ways of how automation might fail and make enough of error checking to make sure that things go right way even in case of errors (in input data, processing of information or at some another level of system).
Sometimes it is better to do things manually while in other situations automation is way to go.
Automating a business process just for the sake of automation is a fools errand. And is likely to cost your business A LOT (in every way you can imagine - financial impact, business disruption, new technical issues, morale, etc...).
Without care, automating a business process can:
cost lots of money (without necessarilly the possibility of making it back somehow)
take a long time to implement (use of resources that would be better used elsewhere)
make the proces more brittle (loss of flexibility / adaptibility)
uncover issues with the current process that are minor and blow them out of proportion
create errors if something in the process is overlooked
demoralize your staff
Based on my experience, assuming the business process has been design well and implemented correctly, here are the disadvantages with BPM automated business processes:
Changes to the business process will required changes to the BPM solution.
Making changes to the business process is harder because you have historical data that you need to migrate or it forces you to use a sub-optimal work around instead.
The business process can be affected by the maintenance of the BPM platform.
The business process can be lost in the system due to BPM engine error requiring developer support.
The costs?
Loss of staff -automation can work so well that you will need fewer workers.
Loss of poor quality output - automation can provide berg predictable results.
Lack of 9-5 work - automation software Dan run anytime you set it to. I have built routines that run every three hours and have been running for years.
Loss of unhappy customers - quality and benefits go up when automation is done correctly. I created an automated Email routine that alerted our employees exactly the amount of money we placed in their bank account on pay day. This was easy to do since I had just automated the creation of the text file needed to upload to our back to pay them already had the needed numbers.
You get the idea. Automation done right costs lots up front..... but pays for itself in savings and increased benefit over a short amount of time!