328 karma · joined August 31, 2013
1. Project description. Plain simple explanation what your project does, etc. You might think it's an obvious and redundant thing. But it's not. It does help you to nail the project, define critical points and set all the team members with the same vision in mind. It should be 1/2 of the page.
2. User path. Describe how user finds you, sign up, start using it, what gets out of your project, why returns, and why be proud to tell others about it. If you build a marketplace/platform - build these stories for all types of users you have. This one is super important. It helps you to define bottlenecks, interface elements, user behavior, strong/week points, etc. It also can help you to describe your project to your potential users, so you could check if they are cool about using it. You might find you need to pivot without writing a line of code.
3. UI - describe it in the list form with several levels. It will help you to understand the real complexity of what you are building and delete unnecessary things.
4. Features list. You know how to do that already.
5. Tech specs. I guess you know how to do that too if this is not your first project.
6. Draw the UI on a paper. It will help the designer, and you will see some obvious things you should delete/add.
Medium - we use gdocs. Mind maps work well too because you can present the user path in a visual format and play with it changing pages/actions.
It sounds a lot, but man it saves so much time and resources down the road. If you need more advice - ping me at alexey(at)devteam.space - happy to help, good luck!
#1. You need to have a PM for remote devs, on their side. Or decide who is the PM out of these remote devs. This person will be your trustworthy manager. If something goes not right, you talk to him/her first. Ask him to provide all the honest and bold feedback from himself and all the other remote devs if something happens.
#2. Request daily short updates from every developer. Just 2-4 lines of text about what have been done during the day. Explain to them that you will not actually reply to these updates. It's just to keep everything transparent. So, they write - you only read. Rarely reply with some questions.
#3. Set the goals on projects you work on with them, request deadlines, you can set it in sprints. It's like mini OKRs (google it if you don't know what is it). It helps them to be accountant and spend their working hours wisely.
#4. Have at least one 30 min call per week with all the remote devs to chat about what you are doing and motivate them with some good news. So they would feel they actually get paid not just for the code, but they make a difference for your company and for your clients. Share with them what you personally have done during the week. All people want to work with even better people, so it should be clear for them that you are awesome. They will respect you more. Basically, treat them as your usual team members.
#5. Use some reporting tools. At DevTeamSpace we have this kind of dashboard - http://i.imgur.com/F6Q3COn.png . Maybe it would be helpful for you too.
In fact, so many companies struggle to manage remote dev teams. If you need any help - ping me at alexey(at)devteam.space.