I am an azure customer and i have had very bad experiences with the support so far. The developer support ($25/month) does not help with server outages because they take 8 hours to respond.. and since everyone is in india or some foreign country, that means all i get is an email, so i respond and wait another 8 hours for a response.. theres really know way to get an issue resolved any faster than 2 days it seems.
So my question, what are your personal opinions/experiences of the azure premiere support ($300-$1000/month) vs developer support? Is premiere support American engineers or still from india? Are the engineers more knowledgabe or are they the same as developer support but faster response time? And opinions would be helpful (i have the link to Microsoft's website, i want real info from people who have used it, not sales talk :) )
#kwill stated:
Every time you open a support incident the first communication you
receive from the support engineer will include their normal working
hours along with instructions on how to get support from another
engineer in a time zone that more closely matches yours.
From personal experience I can tell you this:
While this may very well be true, however, the first communication with the support engineer is the tricky part. The last ticket we created, after almost a week we're still waiting on that first communication with a support engineer which had expected response: 4h ; This is with a Gold support account.
I used all service plans (Developer > Premium), not only Azure but also a few Microsoft products (e.g. SharePoint). First of all, I'm not going to criticize Microsoft service supports but most of the paid tickets I raised give me NOT good experience.
Note that Developer support plan aims to help basic troubleshooting. I'm unsure if you are given an experienced engineer (or you are lucky enough) but the first level is support escalation engineer. I have no idea with this role but per my experience, people with this role have no developer background. They have skills in system, network and IT background enough to kind of understand what you encounter, and may answer general questions. In the loop of email also has a few people to monitor the case.
Standard Plan is quite similar to Developer plan. The difference is the support time (24 x 7) because Microsoft engages people from different shifting time zone. The role is still Support Escalation Engineer.
Professional Direct is quite more professional and has experience with the specific Azure service you encounter. This person may come from Premier Field Engineer (PFE) team who understands the service and also have good troubleshooting skills. You are asked as deep as possible so they can drill down to see the root cause.
Premier Support is more to consulting, architecture and code review. If you encounter system or application error when working with Azure, I don't recommend you to pick this plan. Go with Professional Direct plan is enough. Premier Support also has (but rarely) PFE guys engaged. Role engaged mostly is Consultant and Architect (not Cloud Solutions Architect).
My experience (mostly):
I was shared many long articles (from Microsoft Docs for Azure) which even had obsolete information, missing guidance or unclear points without indicating which I should pay attention to. And you know articles from here https://learn.microsoft.com/en-us/azure/ have so many issues (e.g. wrong API version, wrong configuration, invalid class,invalid directive, poor documented SDK sample....)
Developer and Standard Plan would not give much value. Slow response and no consensus (someone handles case then off business hour. Another one takes over and asks what is encountered again). Such a loop resulted waste of time.
Professional Support gives best practices of DOING, or DESIGN, without actually understanding the scenario. Every design has a reason and decision consideration. It's not just giving a documentation then recommend to follow.
Premier Support: it is good but don't really expect something so high. Sometimes your customer asks you to open Premier Support ticket to JUST get confirmation of valid architecture design or coding pattern from Microsoft.
Again, I really love Microsoft and would like to make it better by giving positive feedback.
Kris, the Azure support team is a 24x7 global team with engineers in every region of the world, including the United States. The US based team is the largest team since that is the time of day when the majority of incidents are submitted. All of the support plan options, severities and response times, and email/phone options are available at http://azure.microsoft.com/en-us/support/plans/.
Every time you open a support incident the first communication you receive from the support engineer will include their normal working hours along with instructions on how to get support from another engineer in a time zone that more closely matches yours.
If you ever feel that you are not getting extremely high quality support you can always ask to speak to that engineer's manager, at which time a manager and an escalation engineer will review the incident to make sure you are getting everything you need.
Related
I'm brand new to Dynamics CRM and have been asked to see if this is a viable replacement for the employee tracking software we're using now (AlexSys Team 2 Pro). We're not so much of a sales based company as the tutorials i see for CRM focus on. I know CRM is more for customer relations and sales tracking but i also know it's highly customizable and can do what i need it to do. I need something that keeps track of how many new tasks have been created and how many have been done and to show a graph or a report with the results. I've looked at some PluralSight videos and some windows videos but they all seem to focus on and really push the use of its sales side usability. We do sell our product here (i work at a software development company) but we need something that isn't focused on sales and is usable to management for tracking progress. So for example, lets say im aksed to do 4 things(tasks), I do 2 of those things and am in the process of handling my 3rd. I'm not a sales agent, lets say im a programmer, I need CRM to be able to show my manager that I had 4 new tasks, completed 2, and if possible to show that im in the process of working on the 3rd. AlexSys Team gives you different options for what state the task is in, such as In-Process and Completed but it does poorly when it comes to reporting. Are there any good places to learn how to do that in CRM, we are not using a partner and will not have someone coding this or changing this for us, i will possibly be the one working on that so i need something that can help show me how to customize it without constantly talking about sales. Im off to watch more PluralSight videos but maybe a user here knows of somewhere better to learn from or maybe just a specific PluralSight video i may have missed. Thanks for any input.
Dynamics CRM is as you've discovered very customisable and will almost certainly meet the requirements you've described. Whether it is the correct choice only you can decide.
YouTube is a really good resource for CRM videos, you can also take a look at the CRM 2011 Technical Training Videos on Channel 9 produced when the product was first released. These give a high level overview of CRM 2011 technical capabilities.
You may want to look at the basics of Activities ( in particular Tasks ) and Queues. Make sure you're clear on the usage of Status and Status Reason and how you can customise them. For reporting you can either use the built-in dashboard capabilities or create your own SSRS reports using BIDS that can be hosted within CRM. The process of producing these reports whilst subtlety different will be easily understood by anyone with some some basic SSRS skills.
I'd recommend enlisting the help of a partner in the first instance even if it's to just verify your initial design. The overall cost of their time in relation to the install and running costs of CRM won't be too significant and they may even be able to save you some money.
I'm not sure of a better place for videos, but I can speak to CRM's ability to serve as a rapid application development platform and the areas it excels. It allows you to create new fields and entities (think Database Tables) without touching a database, as well as customize forms, roles, and security with 0 code. You can also sign up for a free months trial online to setup a quick Proof of Concept.
There is so much that it can do, and do quickly, that your company may be better served to seek outside help, resulting in a better product, delivered quicker, with less overall costs than trying to do everything "in-house".
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
I am planning to release a .NET product as Beta in the next couple of weeks. I want to know what points should be considered before releasing a product. I think the following needs to be taken care of:
Professional Icons/Splash and About screens
Obfuscation of assemblies
Sign the assemblies - Strong Name
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
Google AdWords, AdSense and Analytics
Writing blogs etc about the application features
A way to get bug/features from BETA users
Basically the question is how to release an effective BETA and make my product popular?
Obfuscation of assemblies
Only if obfuscation does not decrease the quality and usefulness of (automatic) bug and crash reports.
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
I don't think this is an important point for a BETA. If you can afford it, its a plus. However, it won't make your application more popular. Also, you won't loose potential users if you miss a certificate - whoever downloads and installs your application will not abort just because your stuff is not signed.
But there's another point missing: you need a fancy website. 'fancy' means: it must look professional, fit to your product and lead straight to a download link. The product needs to be easily installable - really easy. Small download size is also a plus in my opinion.
Writing blogs etc about the application features
Increases your google ranking, but needs to be used with care. If you fill hundreds of blogs, everybody will know it's YOU advertising your product. Nobody likes self-advertising. Let your users spread the word for your. A good application in a market niche won't need much advertising ...
Professional Icons/Splash and About screens
Is a good point to make the application look more polished, but the effect on potential users needn't be positive: nobody likes BETAs with awesome splashscreens and icons if they crash all the time.
The question
how to release an effective BETA and make my product popular?
has little to do with all the points you stated.
It is 95% marketing thing than technical.
But I would consider the most important ones for Betas:
Easy way to submit bug-reports/feature request (2 clicks, no more; 1 minute of user's time).
Usability.
Product demos to get started easily.
The first is crucial as it will give you the first feedback on the application.
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 5 years ago.
Improve this question
I'm sure that all of us have had to deal with telecommuters at some point in time, and I'm facing a situation now where my new project will have a "core" group of office workers and some off-site telecommuters. Not wanting to repeat past mistakes, I'd really like to know what ways people have tried in the past to effectively integrate telecommuters in an agile process, namely scrum.
My first fear is that the telecommuters will be the first ones to break the "daily scrum" routine. And, as human nature often goes, once that gets broken, it's hard to resume and get people back on track. Scrum recommends enforcing small, fun "penalties" for people missing or being late to the daily scrum, like donating a few bucks to a jar which would later be used to buy a case of beers for the end-project party or something. This is obviously something that would be difficult to enforce online.
The other big problem with telecommuters is the "out of sight, out of mind" problem. Aside from using webcams/skype/teleconferencing, what other tips do people have for keeping the team as closely knit as possible?
Also, what about dealing with telecommuters from different timezones? At the moment, we're lucky enough not to have this problem, but it's definitely a possibility at some point in the future. How have other teams dealt with this problem?
Instant messaging really helps with the "out of sight, out of mind" issue as their 'Status' (Available, busy, on the bog, etc) is visible to all. Also, by responding to messages they reinforce the idea that they're generally available.
I wouldn't worry about the Scrum meeting issue, joining a meeting via teleconf is often easier than attending in person.
Set the ground rules upfront. Don't be wishy-washy about them.
You've probably eliminated the "I got stuck in traffic" excuse for missing the meeting or whatever when they're working from home (or a satellite site) and so there's no reason to expect less out of them.
Take advantage of technology:
Use IM. We use it here and it is great for 'reaching out and touching' the guy four states away. Make it a requirement to be available via IM.
Use other tools to help break down the barriers. It'll depend on your situation.
If you're having the daily meeting, it should be clear to everyone that you're going to be asking the questions:
What did you accomplish since we
last met?
What are you going to be doing
today?
What's in the way that needs to be
moved?
Just because you can't see Matt in his cube doesn't give me a right to be lazy or unproductive and unresponsive. It's like dealing with my kids - let them know the rules and what is expected, then nobody can claim ignorance.
We have success using this tools:
Assembla for project management (source control, wiki, scrum tool)
Skype for voice communication
Google talk for im
We are team of 3 developers, in 6 time zones range.
I spent a year as the only remote guy on an Agile team. I called into a conference line for the daily scrum, as well as the planning/review meetings. I kept in contact during the day via IM/e-mail/phone.
I think it worked pretty well overall. The biggest constant drawback was not being able to see the physical whiteboard we used to track the scrum. We discussed moving to some sort of online tool to do this, but it never happened.
I was one timezone away, and I just considered it part of the telecommute tradeoff that I would work the hours that the rest of team kept.
As far as penalties for missing SCRUM - to a certain degree you should enforce this loosely, via the beer jar or whatever. But if someone is consistently missing/late required meetings, then their manager needs to address that.
The are a number of techniques that you can use - remember the purpose of colocation is to encourage collaboration and communication. A few things can help out.
If your team is all nearby - think about having core days of when everybody can come into the office. My current team allows working from home on Mondays and Fridays - and everybody comes in the office Tuesday through Thursday
For distributed teams, I have had good success with using Wikis instead of giant sheets of paper on the wall. The nice thing about wikis is that they encorage the team to edit the forms to meet the needs of the team as opposed to adapting to a more formal tool.
Another advantage of having a Wiki is each person can have their own page to share pictures about their vacations and hobbies - this makes remote people more real.
When you have a distributed team, I want to second the use of Instant Messaging that includes a status (Available, Away (grabbing a cub of coffee), Busy (in a meeting)) - these can include notes if people switch between working at home and at the office.
Webcams are inexpensive and valuable tool
Invest in a decent speaker phone (we like Polycom phones) for your group conference calls
Use tools like LiveMeeting to promote remote pair programming
A technique for doing stand ups over the phone is to have the person talking say the name of someone else in the group who has not gone yet - this keeps everyone paying attention.
For iteration (sprint) planning meetings - follow up with meeting minutes or a communication plan to make sure that everyone is on the same page. Not being colocated means a tad more documentation and intentionality on communicating.
Good luck
SCRUM and many other agile methods really do depend on physical proximity - it is hard to integrate telecommuters into any development process where integration happens frequently, but these particular processes are especially hostile to disembodied developers.
You will have to adapt the processes to the situation at hand. Video conferencing using webcams is actually very usable, and in fact yo might want to experiment with having their webcam on all the time in their cubicle/work area so people can just walk up and ask a question as they would with any other coworker.
But at the end of the day, you simply have to expect things to go differently for them - they aren't going to be able to fully participate in many processes if you are an agile shop.
-Adam
Make sure they attend the daily standup via webcam; as you said that's the first mis-step down a slippery slope. We try to have all meetings done with a RoundTable as well which really helps.
I've been doing this for two months (working in Canada with the core team in Dublin) and so far everything has been going really well.
See Scott Hanselman's writeup on his first year working remotely at Microsoft - definitely some good tips there. One Year Later.
Instead of a beer jar, the privilege of telecommuting itself could be part of the bargain for participation when required. If the team is not responsible enough to telecommute properly than they probably shouldn't be. More fun penalties for occasional tardiness could be to use a funny avatar to represent the person that is missing from the meeting.
Other methods of keeping people closely knit is using collaboration tools such as Wikis and project tracking tools such as Basecamp or FogBugz.
For differing timezones, early meetings will need to occur based on the furthest west time zone, unless one is on the opposite side of the world, which is a bigger problem. Then it will probably be based on who is in charge.
We have been able to manage daily scrums in our environment even with distributed teams over the phone.
It helps to use software such as Rally and Basecamp to manage the process.
One place I worked used Asterisk instead of a normal phone system. It worked well because when you are working from home, you simply log on, people can call your direct line number, outsiders don't need to know. Even though phone call cost are relativity trivial these days, having a 'always on' connection encourages more communication. The sound quality is better too.
For telecommuters/distributed teams, I recommend getting a decent phone - most desk phones lose the ability for folks on the other end to hear folks who are multiple feet away from the phone during a standup.
When you do your demos of working code for stakeholders at the end of the iteration, use webex or livemeeting or something to share the desktop and a camera to show the speaker so that your distributed participants can see what's going on. (Even better would be to ask your telecommuters to attend during iteration boundaries to participate in person).
I recommend getting folks together for a few weeks at the beginning of the project during the inception/kickoff phase so folks can build interpersonal relationships. It's amazing how helpful the face-to-face interaction up front can be to build a foundation for teamwork.
Use a distributed card wall. I like Mingle (http://mingle.thoughtworks.com), but I haven't used other tools, so can't comment on them.
For retrospectives, it's useful to have a proxy in the room using IM to communicate with your distributed team members... so that any comments the distributed folks have can be written onto a piece of paper (or post-it, or however you do yours).
As for your fears of "out of site, out of mind", my preference for things like this is to not create solutions for problems that have not yet materialized. If you find that your team is becoming disconnected (prime discussion points for retrospectives), then you can facilitate a team discussion on how to deal with any issues that arise. Again - the team should help identify the problem and the solution rather than having a manager or scrum master dictate solutions. Start with an assumption of trust.
Distribute Scrum requires good preparation. It is not just about the tool.
We supported many rollouts in distributed environment and there was one fundamental point - people.
The most efficient is to start with ALL people in one location. They have to meet in person so they can know each other as persons, not just someone virtual on the other side of the world. As I used to say - team members need to smell each other.
For release planning meet at one location, if possible. Change locations so you visit all of them, to have a context and understanding of culture, habits, persons. For sprint planning use video meetings, screen sharing etc. It is not necessary to travel (it would be too often).
Clear roles and team(s) organization must be established. You have to have Product Owner and Scrum Masters. You should consider if you do not want to get PO & SM as close to the team as possible. Definitely you have to get them into face 2 face meetings (it is about face, not a location) every day.
Definition of done, if agreed by the team, helps to have the same understanding what Done means. In distributed environment is a must.
You will need a good communication tools for daily stand-ups . We found usable to use Skype or Office communicator for dailies. We use audio AND chat. Especially in international environment chat allows you to understand people. Keep communication channel open after daily so team members can discuss what is necessary outside of daily report.
And, the most important, is to do regular retrospectives with all team members in all locations. Do not forget to implement ideas coming from retrospective. Teams in other locations will need a local support who will help them to implement ideas.
I work on a team of 5. We to facilitate our telecommute workplace we use:
Asana - Project and Task management
Google Talk + Your favorite IM
client (I used Pidgin)
RingCentral - VOIP Telephone
Gmail - asynchronous communication (i.e. email)
Dropbox - file transfer and
backup
Team Viewer - Screen Sharing, Training, and Presentations
Even with these tools it is easy to fall short on your process so it is important to establish some best practices for your team based on your dynamic. For example, we have two chief practices:
Communicate Often - because we are not in the same location when communicating it is easy to forget that you are working on a team. For our team, we update our tasks in Asana with comments describing ideas, obstacles, and task completeness. When immediate assistance or feedback is needed, don't wait, seek assistance via IM or email if (the person is offline).
Lean on the side of over communication - This pertains more to Asana comments and emails. However, in general we found it is better to give more information than is needed (within bounds).
My company is planning to start a forum for our software product which the clients can refer for general FAQ's, problems etc.
Right now we are planning to have:-
User manuals.
Best practices for different section's of the application
Frequently faced problems.
Forum where user can discuss issues with development team.
Any other ideas?
Edit:-
We have RSS and E-mail notification subscription to the forum.
Forum where user can discuss issues
with development team.
I don't know if this is a euphemism for "issue tracker" but if not, make sure you include a way for people to submit bug/feature/enhancement reports and track them to completion. Nothing is worse than not being able to submit a bug report or being able to submit a bug report but only into a black hole.
Communication is key.
If you add an issue tracker as suggested by Kevin, your list seems pretty ok to me.
I'd also suggest that you do not start out with too many different services that require interaction from your side (e.g. your developers) at first - I've seen (too) many good initiatives die simply because nobody in the company had enough time e.g. for regular answering of the forum questions.
In your case, I guess "best practices", "frequent problems" and the forum will all consume regular time from your dev team if you want to keep them alive and up-to-date, especially in the beginning. So I would not add more services at the beginning but make sure to get these right (and you can always add more services later on if you find that the users need them :-).
You.
Show that you care about your customers.
Many useful tips at Creating passionate users blog.