![WHO ARE MY
DEVELOPERS?
IN SHORT PEOPLE WHO TRY THERE BEST TO ACHIEVE
YOUR VISION, AS LONG AS THEY UNDERSTAND IT PROPERLY
Whether you’re hiring someone local, offshoring or [God help you] using
a freelancer site, the most common story behind your developer is that
she/he is a well-intentioned, average to kinda-good developer who will
try to achieve the best outcome possible as she/he understands it. Most
freelancers will be either not very good at project management, or feel is
not part of their job description, and thus, they will tend to focus on their
development work to the exclusion of crucial things like updating you on
key milestones in development, or asking important questions they have
about your project.
Because their incentives are very different to yours, it can follow that they
are preoccupied with doing things as fast as possible and exactly as you
requested, while you are thinking about why a user would do things in a
particular way and how can their experience be optimized. Therefore,
when unforeseen challenges arise, they can choose a solution that is
close to “what the client asked for” while you would, if asked, choose a
solution that is more coherent with your vision for the user experience.
And generally speaking, the average developer won’t stop developing to
ask you about these things when they come up.
The solution to this, is a well organised project management system that
slightly forces developers to get out of their routine, report back to you
and ask important questions. Read on…](https://image.slidesharecdn.com/binarymangowhitepaper-191223185253/85/Managing-Developers-for-Non-Techies-4-320.jpg)
Managing Developers for Non-Techies
- 1. PROJECT MANAGEMENT FOR NON TECHIES J A C O B O K O E N I G
- 2. PROJECT MANAGEMENT FOR NON TECHIES J A C O B O K O E N I G
- 3. THE MOST IMPORTANT THING WHY PROJECT MANAGEMENT MAKES ALL THE DIFFERENCE If you’re a non-technical entrepreneur, and are thinking of hiring developers directly to develop an early version of your idea, stop and read. This is for you! In the ideal world, you have enough funding to hire a proper CTO, and a project manager with experience to convey your expecta- tions, create daily and weekly reports on production, and structure a well organised plan with budgets and timelines for the develop- ment of your app. But if you’re here, one might assume, it's precise- ly because you don’t have a product yet, and therefore no funding. Competent CTO’s, you’ll understand if you’ve been looking around for a bit, shy away from equity-only deals, and so it comes full circle - No funding, no CTO, no product, no funding (ad infinitum). How then, do you use your resources to create something with which to start gaining traction with early investors (such as family and friends, and pre-seed investors) and maybe even a few clients? If you’re brave (or desperate) enough, you hire developers directly and face a huge challenge: How to convey your vision properly, so that developers know exactly what to quote, how to estimate development times, and how do you ensure they don’t disappear for three months only to come back to you with a product that is not at all close to what you asked for in the first place. Read on...
- 4. WHO ARE MY DEVELOPERS? IN SHORT PEOPLE WHO TRY THERE BEST TO ACHIEVE YOUR VISION, AS LONG AS THEY UNDERSTAND IT PROPERLY Whether you’re hiring someone local, offshoring or [God help you] using a freelancer site, the most common story behind your developer is that she/he is a well-intentioned, average to kinda-good developer who will try to achieve the best outcome possible as she/he understands it. Most freelancers will be either not very good at project management, or feel is not part of their job description, and thus, they will tend to focus on their development work to the exclusion of crucial things like updating you on key milestones in development, or asking important questions they have about your project. Because their incentives are very different to yours, it can follow that they are preoccupied with doing things as fast as possible and exactly as you requested, while you are thinking about why a user would do things in a particular way and how can their experience be optimized. Therefore, when unforeseen challenges arise, they can choose a solution that is close to “what the client asked for” while you would, if asked, choose a solution that is more coherent with your vision for the user experience. And generally speaking, the average developer won’t stop developing to ask you about these things when they come up. The solution to this, is a well organised project management system that slightly forces developers to get out of their routine, report back to you and ask important questions. Read on…
- 5. THE SYSTEM OVERVIEW WHAT WE REVIEW ON THIS DOCUMENT BEFORE YOU START TASK ASSIGNMENTREPORTING What you need before you start. The best tool for Project Management Beginners Owning the project Sprints Daily and Weekly Meetings How create detailed tasks, acceptance criteria, and assigned developers. Prioritisation Moving tasks and project forward
- 7. BEFORE YOU START The full design of the app before development, since it’s much easier to make changes in design than in developemn. If you can’t procure design in time, then: A rough draft of the screens with a workable flow of how they interact with each other should be good enough. Often developers will quote on the general scope of a project without enough information about the project. It’s in your best interest to avoid miscommunication by having as much clarity as possible on how the project should look and feel like at the end of the job. Really good things to have are: HAVING ENOUGH RESOURCES TO GET AN ACCURATE QUOTE User stories Some things are not clear in design, but important nonetheless. In those cases, user stories come in as a full explanation of the app from the perspective of the different type of users. Two examples of user stories are: “As a guest user, I would like to see the latest news in my home to explore the app without signing up” or “As an admin, I would like to be able to change how many posts each type of user sees in their feed to make sure they are never over- loaded with content.
- 8. PLANNING YOUR PROJECT USING TRELLO Trello is a project management tool that uses the Kanban methodology to sched- ule tasks into cards that can be placed into custom columns to organise and tackle them in order. It is incredibly easy to use, and it allows for as much flexibili- ty as you need while you become more proficient in project management. In the following pages, I will show you how to adapt trello to an app development project. It would be great if you took a couple of minutes to sign up and get familiar with the interface. SIGN UP and get familiar with the interface.
- 9. SOME OF TRELLO'S MAIN COMPONENTS Columns: Trello's main category component which contains the tasks cards Cards: The main representative of a functionality or main task. It includes details in the form of the following components: Description: The main component of each card. It should contain an overview of the functionality in its card. Checklists: A simple to-do inside of cards, best used for acceptance criteria that define when a functionality can be deemed complete. Labels: Tags to categorize your cards beyond the main column category. Activity and Comments: A component that allows you to separate conversations about each specific functionality. Labels LABELS Current Sprint Upcoming Sprint Future Sprint (Date TBD) Create a new label Enable color blind friendly mode Search Labels.... Labels Checklist Description Columns Activity & Comments Due Date Cards Onboarding Anonymous User flow Forgot Password doesn’t work Log In Flow Jul 28 1/44 Register Flow Jul 28 1/44 Jul 28 Log In Flow Jul 28 1/44
- 10. TASK ASSIGNMENT
- 11. CREATING A DETAILED PLAN IN TRELLO This is the core of this document. We will discuss in a simplified manner, how a lot of project management professionals plan their project, and create details for each task.
- 12. COLUMNS, CARDS AND ACCEPTANCE CRITERIA On a given app development project, there are three main hierarchical components to keep in mind: Columns represent the main modules or sections of your app like Login, Onboarding, Newsfeed, Profile, etc. Cards represent each functionality inside the module or column. Things like filtering con- tent by date, name and tag, or ability to search are examples of functionalities that could be inside of the newsfeed module. Lastly, acceptance criteria are important de- tails about those functionalities without which tasks are not complete. For example, you might consider curcial that the pass- word has at least one uppercase letter in the login form, or that news older than a week should not be initially loaded. These are ex- amples of acceptance criteria and should go on a checklist inside of each card Share my Concept Design Jul 28
- 13. The way you will create cards in Trello fol- lows the following format: Columns, from left to right, represent how the user flows through the app, for example: Logs in first, then goes to the feed, then creates a post, etc.. Cards are stacked from top to bottom based on their priority. If a developer can take only one, he will take the one on the top of any column he happens to be work- ing with. For milestones, you would normally draw a line that zigzags over and under the cards creating sections that represent mile- stones. (Since trello doesn’t draw lines, we use colored labels). A good rule of thumb is to create three milestones representing the absolute basic things you app need to operate (on top - Orange), important functionalities (in the middle - Purple), and nice-to-haves (at the bottom - Red). PRIORITIES USER FLOW MILESTONE
- 14. MOVING THE PROJECT FORWARD To move the project forward, the main thing to do is to assign all tasks to a developer, or allow developers to assign them to them- selves and mark the deadline and progress of each one. Although not precisely part of the Kanban methodology, my team likes to reserve four columns at the beginning of the board to move cards as they progress through the flow: TO DO, IN PROGRESS, QA, DONE. As the team starts working on each task, they will move cards all the way to QA or DONE (depending on who’s doing the check ups), after which it is your job to confirm they are done and mark them complete. Often, developers will give you a staging site or app from where to test these tasks.
- 15. REPORTING
- 16. MAKING SURE THE PROJECT IS ON RIGHT TRACK To do this, we establish a series of meetings around weekly sprints of work that fits as many tasks as can be optimally achieved. Reports then, are given by the team on a daily, weekly, and milestone basis.
- 17. REPORTING Reporting is probably the most important part, but the one that is most often neglected as everybody gets deeper into their work. That is why we make a point of scheduling in the diary three main types of meetings. Daily Meeting The purpose of this meeting is for each developer to talk about what they did the previous day, what they will do the day after, and what resources or answer they need to proceed. To be able to keep the team engaged with daily meetings, it is very important that these don’t last more than 15 minutes. A good rule some people apply is to have them while standing, if you get tired, that means the meeting has been too long. Weekly Meeting Although this comes from a different methodology that is beyond the scope of this document (SCRUM), we like to divide work into weekly sprints and have a meeting at the end of each, beginning of the next. This is a much more in-depth meeting in which functionalities are discussed with the team to make sure everyone is on the same page before development. Tasks are also assigned during this meet- ing considering that all resources and prerequisite tasks needed for each are available. Milestone Meeting After each milestone a presenta- tion should be arranged by your developers to go through the whole user flow and ensure that what was developed is in line with what was asked for (based on the design, and instructions). 1 2 3
- 18. WRAPPING UP Project Management is not easy, and my intention is not to oversimplify the complexities of the job or make it sound redundant. If possible, you should hire a professional to handle the work. However, the stage in which most early startups find them- selves makes it very hard to hire before you have achieved some sort of traction, and therefore, entrepreneurs have to do a lot of the work themselves. This document is meant to give you a basic understanding of what is most important and allow you to work your way into the stage where you can hire appropriate product professionals. I would love to hear your thoughts, comments and success stories after reading this. If you have any questions, feel free to reach out to talk them over. Best of luck with your startup, we’re eager to see how you make an impact! hello@binarymango.com +44 7305765518 www.binarymango.com