Project management tools and methodology on the example of a startup pivot
In the previous article we told the story of our startup, having considered three key components: “Idea”, “Implementation” and “Sales”. Due to the large volume of the article, the issue of implementation did not formally describe the place. We will fix this in this publication.
Team management begins with planning and design. There are dozens, if not hundreds, of project management methodologies: from “Development on ReadMe” to cumbersome, but for all occasions PMBOK . As programmers, happens, invent bicycles, and project managers can sin by it. If with the methodology we could afford some liberties, then the tool was chosen without “cycling” ...
')
Pivot (from English - spinning around, turning around its axis) in the context of a startup is a rejection of the current business model, software product and the restart of all work on a new concept. The explanation of why this is happening, why it happened this way is beyond the scope of this article. Let me explain just what in our case meant “pivot”:
Our team has experience working with three “bundles” of project management tools:
“Bundle One”
Google Docs - electronic document management and cloud document editor;
Megaplan - tracking tasks not related to code development;
Redmine + GIT - bugs and tasks related to code development + version control;
Kayako - service for collecting feedback, bug reporting;
Such a bundle is good when there are several projects in development, several customers, etc. (Redmine), a lot of employees and tasks not related to the work on the code (Megaplan), a lot of users, and accordingly a lot: support, feedback, bug reports (Kayako).
“Bundle Two”
Google Docs - electronic document management and cloud document editor;
Megaplan - tracking of tasks not related to code development + CRM-system;
BitBucket instead of Redmine + GIT;
Yandex.Mail for domain - to collect feedback, bug-reporting.
The “second bundle” is suitable when the project is one, and it is relatively simple (BitBucket); at the same time, there is a lot of work that is not related to the code (Megaplan), but there is little feedback support, so there is enough of a customized web interface from mail (Yandex.pdd).
“Bundle Three”
Google Docs - as a cloud editor;
TrackStudio + GIT - task tracker, both by code and other + electronic document flow;
Yandex.Mail for domain - to collect feedback, bug-reporting.
This bundle is the most correct, it allows in one system to work on tasks both by code and for everything else. Unfortunately, the main tool in this bundle requires a lot of resources for setting-finishing (TrackStudio); feedback feedback, as in the “second bundle”, is enough for Yandex.pdd,
These bundles were selected under different working conditions. Google Docs is always used: we just love it - it's a pleasant, fast and convenient cloud-based document editor.
Under our conditions: one project, it is necessary to work both on the code and on promotion, there are no users at all yet, many feedback support is not foreseen, they assumed the choice of the second or third “bundle”. The “third bundle” (based on TrackStudio), after a short reflection, disappeared - there was neither the time nor the resources to customize-bring this tool to a new project. We decided to use the “Second bundle” with tools that worked out of the box (BitBucket, Megaplan).
The option to try something new was not considered for the same reason that they refused to use the “Third bundle”. There was no time for experiments, it was necessary to start working. Given the inability to try new things, they relied on the experience of the project manager for communicating with a couple of dozen other project management systems (EMS), both specialized for software development and a wide range of applications: from Teamer to BugZill.
Why did we start by choosing tools, not planning?
Because the “second bundle” consists of two non-flexible services: BitBacket and Megaplan. They do not have the ability to customize them for any processes, so you have to build a project management methodology in terms and limitations of these tools. Choosing the tools, and knowing their limitations, you can proceed to the next stage - planning.
It will seem to someone that the situation when the instrument dictates the methodology and not vice versa is very bad. In our opinion, if restrictions do not adversely affect productivity (for example, excessive bureaucracy), then you can put up with them.
Common tasks are set in Megaplan, we will use its terminology. The starting point in the hierarchy of Megaplan's task manager is Milestones. Milestone - a cut of the project at a certain time, it can still be described as a set of goals that need to be achieved by a specific time. Planning comes down to creating milestones. Let's consider them on the example of our situation (we are reworking one project into another, we are preparing its promotion, for all 30 days, from September 5 to October 5).
Milestone # 1. “Preparatory stage”, completed by September 10:
- Selected and configured tools, local servers;
- Planned work flow;
- Set and distributed tasks;
- Compiled TK for all tasks.
Milestone # 2. “Basic work”, completed by September 15:
- The refactoring of the project code (accelerated the implementation of future tasks);
- Prepared servers and accounts, domains for production;
- Developed and assembled key content for promotion (according to the “Occam's Razor” rule: 20% of “key” content will give 80% of traffic);
Milestone # 3. “First visual result”, completed by September 20:
- Editor refactoring (transferred to the iframe, which allows you to quickly implement the "demo mode");
- Produced GUI redesign;
- “Launched” blog of the project, community in social networks.
Milestone # 4. “First public result”, completed by September 25:
- Added payment acceptance form;
- Implemented demo mode;
- On the demo mode, a promotional site is launched with 90-100% of the planned content;
- Version 0.0.11 is delayed in production;
- Communities in social. Networks and blog site are filled with the first posts.
Milestone # 5. “Project promotion prepared”, completed by September 30:
- Started a blog on Habrahabr;
- Implemented minor features and improvements;
- Moderation completed and billing system connected;
- Version 0.0.17 is delayed in production;
- According to the publication plan, the posting in the social. network and blog site.
Final Milestone # 6. “First promotion of the project”, completed by October 10:
- Implemented all conceived on the alpha version of the functional;
- Release of version R0.1 Alpha-1 is delayed in production;
- The first article published in the blog on Habrahabr;
Scheduled Landmarks # 7-X. “Creating a community project”, completed by October 30:
- Published 3-5 articles to the blog on Habrahabr;
- Prepared and published posts in the blog on the site, in the community of soc. networks;
- There is a collection and analysis of feedback, general correspondence with users who are interested in the project;
- Planned and carried out work on other promotion according to the marketing concept;
- Hot fixes are produced;
- Analyzed the amount of collected funds, correlated with the possibilities for the further development of projects.
We’ll finish the work on the Milestones; further planning should continue, relying on the feedback received, but for now it’s not, it’s better to work on getting it.
Let me remind you: the first Milestones were planned based on the “marketing concept” . Our team consists of 4 people, several years working together on different projects. Similar to those set in the Milestones for the Alpha-version of Ahoba (; the tasks we have already implemented in other projects. Therefore, making Milestones, the project manager already imagined who and how will solve the tasks. This process occurred informally, based on the past experience, empirical evaluation and analytical forecasting.
You can write a book about these informal thinking processes, about the history of their occurrence, sample options, learning from mistakes, etc. It turns out a sort of “PMBOK Lite for Brain”. However, at the moment there is not just a book, but also a paper-based concept: everything is 70% in the head of PM, and only the remaining 30% is in his personal crib-theses. Perhaps sometime from these developments it will turn out, even if not a book, but a worthy article for Habrahabr for sure. Now we just note what has been done, without going into the question “How?”.
So, we have Milestones, there is a team of 4 people that will implement them. It would be possible to go directly to the next stage — setting formal tasks — but to simplify subsequent control over execution, another tool should be used — the hierarchical structure of the project.
Hierarchy is needed to group / group tasks. Tasks have two main distinguishing characteristics: functional content and the performer. You can design a hierarchy of tasks either by their functional grouping, or with reference to a specific performer. These are formal approaches. They simplify management, make it more transparent, but add a lot to excessive bureaucracy, which, in turn, reduces overall productivity. In many situations, you can sacrifice performance for the sake of management, and this is justified, because yields its fruits in the form of predictability and high quality. We needed the result as soon as possible, so we could move away from the formal structure in order to simplify and speed up the work. However, in any other situation, I would be against such a structure.
Thus, our tasks are grouped somewhere with reference to the performer, somewhere with reference to the functional content:
0. Design
1. Development of the project
2. Project promotion
2.1. Ahoba website and blog (;
2.2. Promotion in social. networks
2.3. Promotion on Habrahabr
3. Design and media content development
Such a structure will allow the performer not to be distracted by related tasks of others, although they are in the context of his work, which will also ensure a faster implementation.
When working on the compilation and formulation of formal problems, all the shortcomings of the chosen bunch of tools emerge ...
The general principle is the sequence through which most of the tasks in our projects pass can be described as follows:
Different people with different roles work on the task at different stages: the PM develops the concept of the task; business analyst, technical writer make up TK; designer draws a layout; PM transfers TZ and Layout to the programmer; the programmer implements the task, passes it for testing; the tester checks the implementation and, if everything is in order, corresponds to the specification and to the layout, then as a QA-specialist it closes the task.
And this is the easiest option ... There are situations where it is impossible to determine how exactly to implement the task. Then the programmer can connect to the task at the design stage (for example: several interface prototypes can be implemented, so that the usability expert evaluates each option and inserts the final one into the implementation chain).
As a result, we have about 5 typical models of task life cycles and a couple of dozen more “atypical” ones.
Flexible tools for tracking tasks, such as TrackStudio, are good because they allow you to formally customize management for any task life cycle model. This is their dignity and their disadvantage. As mentioned above, when there are no resources for initial setup, this system will not work. Taking boxed Megaplan and BitBucket, we understood that it would not work out to formally set them up for our life cycles of task implementation. Therefore, the further story a la “many-many crutches” about the informal use of these services.
How to implement our task life cycle model in “Megaplan + BitBucket”? First, the specific features associated with the code (p.1. “Development” of the hierarchical structure defined earlier) are entered into BitBucket, and the tasks for preparing materials for implementing features (TK + Layout + Test / Demo data) are in Megaplan tracker.
Algorithm like this:
We put in the Megaplan a task for a business analyst: “ Develop TK ” - with a reference-note “ Putting TK into a task X for a designer ”. The designer, also in Megaplan, is assigned the task “ Develop a Layout for TK ” with the same reference notes: “ Later, the TOR will put the task in the task of a business analyst, ready to lay out the Layout in task Y in BitBucket ”. The programmer and the tester work only in BitBucket'e, in terms of changing the status of tasks.
In the interface of these SOUPs there is no unification of the stages of work on the tasks. With inept project management, this can lead to negative consequences. From personal experience: if you do not manually coordinate the distribution of work (and automated tools do not), a situation may arise when, for example, the programmer is idle for weeks waiting for formal descriptions for features. This I watched at the last place of work. As a result, the lead developer quit, arguing his dismissal in a monologue in the spirit: “I’m bored because I don’t have a job, but I want to write code”. This is a good example of how inappropriate tools, or their informal use, can demoralize team members. Everyone who has decided, like us, to use the “Second bundle”, needs to understand and take into account these risks when working in such project management systems.
Our team is 4 people. Each is engaged in several design work. I, as a project manager, had to quickly finish with this very project management and get to work as a business analyst / technical writer, SEO specialist, marketer and copywriter. I didn’t want to go back to the work of PMM, and there was no possibility.
It is necessary to formulate and distribute all the tasks, linking them among themselves by references, appointing the executors and determining the quality criteria. To organize the process of work at a time so that it goes on its 30 days according to a worked out plan, when all the team members as performers would move from one completed task to the next, without losing time on the simple and peripheral. This is solved by compiling a table of works with the subsequent formulation of tasks for it in trackers:
Table: “Works on the implementation and promotion of the project Ahoba (; ver. Alpha-1”
Etc., only about 50 tasks.
According to the targets from Milestones, it turned out to formulate specific tasks. Some goals are described by one task, others are divided into several. Deadlines from Milestones allowed to place deadlines, focusing on the logical sequence of work. According to the previously established project roles, the performers responsible for certain tasks were assigned. The tasks themselves, of course, do not consist of merely the headings indicated in the table. Most of them were supplemented with descriptions, explanations, links to project documentation in Google Docs, checklists with steps or algorithms for execution ...
Separately, it is worth noting the parallelization at an early stage. While the PM is working on the tasks, the team has nothing to do. To avoid idle time, the work of PM starts with setting tasks that do not require detailed TK or analytics: The programmer starts by removing unnecessary functionality; The designer draws the logo of the project; SMM-manager selects content for posts on topics defined in the concept. Everything is in business, and the project manager is quietly working on fifty tasks, having planned the team’s activities for the next 30 days.
This is where project management ends, and only occasionally you have to go back to it: track task statuses, adjust deadlines and Milestones, if necessary.
Tasks are formulated and set, deadlines and performers are defined, but in order to achieve goals without a hitch, you must follow a number of formal rules:
On these rules, tools and methodologies, project management was implemented when creating and promoting the startup Ahoba (; at the “Alpha-1” stage. The goals and conditions that we had were dictated by them.
Kirill,
Project Manager Online tool for Design SketchBuilder
Temporarily from the account of our programmer Anton (@skrutty)
Team management begins with planning and design. There are dozens, if not hundreds, of project management methodologies: from “Development on ReadMe” to cumbersome, but for all occasions PMBOK . As programmers, happens, invent bicycles, and project managers can sin by it. If with the methodology we could afford some liberties, then the tool was chosen without “cycling” ...
')
What is a “pivot” startup
Pivot (from English - spinning around, turning around its axis) in the context of a startup is a rejection of the current business model, software product and the restart of all work on a new concept. The explanation of why this is happening, why it happened this way is beyond the scope of this article. Let me explain just what in our case meant “pivot”:
- limited resources - 4 people for all jobs;
- fixed deadlines - 30 calendar days;
- the need to accomplish the task: “get the first income from the product”.
More about the starting point
- The project does not start with “0” - the ancestor software product was version 2.3, had a good architecture after refactoring, with captured and fixed bugs;
- The task of development: from an ancestor product v2.3 to make a descendant product v0.1 alpha-1. The main changes relate to processing the architecture for multi-design, adding new types of final documents, removing unnecessary functions, redesigning in accordance with the tastes of Central Asia, creating a “demo mode” of work;
- Financial and marketing task: to launch a product as soon as possible and attract an audience to it, having analyzed the reaction to it. According to the analysis to make a plan for further development. From the received additional finance to speed up the development of a new functional;
- The design began with the creation of a marketing concept document , in which the main ideas and theses were formulated: what kind of work should be done to accomplish the tasks;
- The composition of the team and the duties they perform:
“Programmer” - front-end \ backend development, system administration;
“Tester” - software testing, writing bug reports, SMM and content management, feedback analysis and processing;
“Designer” - development of appearance and mechanics of GUI, creation and preparation of media content;
“Project Manager” - analytics, design, planning, management (project, marketing, financial, etc.), development of technical documentation, text content, SEO. - Restriction is a requirement from our investor mentors: in 30 days to remake a product, prepare materials and work on promotion.
Project Management Tools
Our team has experience working with three “bundles” of project management tools:
“Bundle One”
Google Docs - electronic document management and cloud document editor;
Megaplan - tracking tasks not related to code development;
Redmine + GIT - bugs and tasks related to code development + version control;
Kayako - service for collecting feedback, bug reporting;
Such a bundle is good when there are several projects in development, several customers, etc. (Redmine), a lot of employees and tasks not related to the work on the code (Megaplan), a lot of users, and accordingly a lot: support, feedback, bug reports (Kayako).
“Bundle Two”
Google Docs - electronic document management and cloud document editor;
Megaplan - tracking of tasks not related to code development + CRM-system;
BitBucket instead of Redmine + GIT;
Yandex.Mail for domain - to collect feedback, bug-reporting.
The “second bundle” is suitable when the project is one, and it is relatively simple (BitBucket); at the same time, there is a lot of work that is not related to the code (Megaplan), but there is little feedback support, so there is enough of a customized web interface from mail (Yandex.pdd).
“Bundle Three”
Google Docs - as a cloud editor;
TrackStudio + GIT - task tracker, both by code and other + electronic document flow;
Yandex.Mail for domain - to collect feedback, bug-reporting.
This bundle is the most correct, it allows in one system to work on tasks both by code and for everything else. Unfortunately, the main tool in this bundle requires a lot of resources for setting-finishing (TrackStudio); feedback feedback, as in the “second bundle”, is enough for Yandex.pdd,
These bundles were selected under different working conditions. Google Docs is always used: we just love it - it's a pleasant, fast and convenient cloud-based document editor.
Under our conditions: one project, it is necessary to work both on the code and on promotion, there are no users at all yet, many feedback support is not foreseen, they assumed the choice of the second or third “bundle”. The “third bundle” (based on TrackStudio), after a short reflection, disappeared - there was neither the time nor the resources to customize-bring this tool to a new project. We decided to use the “Second bundle” with tools that worked out of the box (BitBucket, Megaplan).
The option to try something new was not considered for the same reason that they refused to use the “Third bundle”. There was no time for experiments, it was necessary to start working. Given the inability to try new things, they relied on the experience of the project manager for communicating with a couple of dozen other project management systems (EMS), both specialized for software development and a wide range of applications: from Teamer to BugZill.
Planning
Why did we start by choosing tools, not planning?
Because the “second bundle” consists of two non-flexible services: BitBacket and Megaplan. They do not have the ability to customize them for any processes, so you have to build a project management methodology in terms and limitations of these tools. Choosing the tools, and knowing their limitations, you can proceed to the next stage - planning.
It will seem to someone that the situation when the instrument dictates the methodology and not vice versa is very bad. In our opinion, if restrictions do not adversely affect productivity (for example, excessive bureaucracy), then you can put up with them.
Common tasks are set in Megaplan, we will use its terminology. The starting point in the hierarchy of Megaplan's task manager is Milestones. Milestone - a cut of the project at a certain time, it can still be described as a set of goals that need to be achieved by a specific time. Planning comes down to creating milestones. Let's consider them on the example of our situation (we are reworking one project into another, we are preparing its promotion, for all 30 days, from September 5 to October 5).
Milestone # 1. “Preparatory stage”, completed by September 10:
- Selected and configured tools, local servers;
- Planned work flow;
- Set and distributed tasks;
- Compiled TK for all tasks.
Milestone # 2. “Basic work”, completed by September 15:
- The refactoring of the project code (accelerated the implementation of future tasks);
- Prepared servers and accounts, domains for production;
- Developed and assembled key content for promotion (according to the “Occam's Razor” rule: 20% of “key” content will give 80% of traffic);
Milestone # 3. “First visual result”, completed by September 20:
- Editor refactoring (transferred to the iframe, which allows you to quickly implement the "demo mode");
- Produced GUI redesign;
- “Launched” blog of the project, community in social networks.
Milestone # 4. “First public result”, completed by September 25:
- Added payment acceptance form;
- Implemented demo mode;
- On the demo mode, a promotional site is launched with 90-100% of the planned content;
- Version 0.0.11 is delayed in production;
- Communities in social. Networks and blog site are filled with the first posts.
Milestone # 5. “Project promotion prepared”, completed by September 30:
- Started a blog on Habrahabr;
- Implemented minor features and improvements;
- Moderation completed and billing system connected;
- Version 0.0.17 is delayed in production;
- According to the publication plan, the posting in the social. network and blog site.
Final Milestone # 6. “First promotion of the project”, completed by October 10:
- Implemented all conceived on the alpha version of the functional;
- Release of version R0.1 Alpha-1 is delayed in production;
- The first article published in the blog on Habrahabr;
Scheduled Landmarks # 7-X. “Creating a community project”, completed by October 30:
- Published 3-5 articles to the blog on Habrahabr;
- Prepared and published posts in the blog on the site, in the community of soc. networks;
- There is a collection and analysis of feedback, general correspondence with users who are interested in the project;
- Planned and carried out work on other promotion according to the marketing concept;
- Hot fixes are produced;
- Analyzed the amount of collected funds, correlated with the possibilities for the further development of projects.
We’ll finish the work on the Milestones; further planning should continue, relying on the feedback received, but for now it’s not, it’s better to work on getting it.
Let me remind you: the first Milestones were planned based on the “marketing concept” . Our team consists of 4 people, several years working together on different projects. Similar to those set in the Milestones for the Alpha-version of Ahoba (; the tasks we have already implemented in other projects. Therefore, making Milestones, the project manager already imagined who and how will solve the tasks. This process occurred informally, based on the past experience, empirical evaluation and analytical forecasting.
You can write a book about these informal thinking processes, about the history of their occurrence, sample options, learning from mistakes, etc. It turns out a sort of “PMBOK Lite for Brain”. However, at the moment there is not just a book, but also a paper-based concept: everything is 70% in the head of PM, and only the remaining 30% is in his personal crib-theses. Perhaps sometime from these developments it will turn out, even if not a book, but a worthy article for Habrahabr for sure. Now we just note what has been done, without going into the question “How?”.
Study project structure
So, we have Milestones, there is a team of 4 people that will implement them. It would be possible to go directly to the next stage — setting formal tasks — but to simplify subsequent control over execution, another tool should be used — the hierarchical structure of the project.
Hierarchy is needed to group / group tasks. Tasks have two main distinguishing characteristics: functional content and the performer. You can design a hierarchy of tasks either by their functional grouping, or with reference to a specific performer. These are formal approaches. They simplify management, make it more transparent, but add a lot to excessive bureaucracy, which, in turn, reduces overall productivity. In many situations, you can sacrifice performance for the sake of management, and this is justified, because yields its fruits in the form of predictability and high quality. We needed the result as soon as possible, so we could move away from the formal structure in order to simplify and speed up the work. However, in any other situation, I would be against such a structure.
Thus, our tasks are grouped somewhere with reference to the performer, somewhere with reference to the functional content:
0. Design
1. Development of the project
2. Project promotion
2.1. Ahoba website and blog (;
2.2. Promotion in social. networks
2.3. Promotion on Habrahabr
3. Design and media content development
Such a structure will allow the performer not to be distracted by related tasks of others, although they are in the context of his work, which will also ensure a faster implementation.
Setting goals
When working on the compilation and formulation of formal problems, all the shortcomings of the chosen bunch of tools emerge ...
The general principle is the sequence through which most of the tasks in our projects pass can be described as follows:
Brief concept of the task → Development of detailed TK → Creating test / demo content → Creating GUI layouts for TK → Setting a formal task for implementation in a task tracker (TK + Layout) → Implementation → Testing → Bugfix (if needed) → Closing a task.
Different people with different roles work on the task at different stages: the PM develops the concept of the task; business analyst, technical writer make up TK; designer draws a layout; PM transfers TZ and Layout to the programmer; the programmer implements the task, passes it for testing; the tester checks the implementation and, if everything is in order, corresponds to the specification and to the layout, then as a QA-specialist it closes the task.
And this is the easiest option ... There are situations where it is impossible to determine how exactly to implement the task. Then the programmer can connect to the task at the design stage (for example: several interface prototypes can be implemented, so that the usability expert evaluates each option and inserts the final one into the implementation chain).
As a result, we have about 5 typical models of task life cycles and a couple of dozen more “atypical” ones.
Flexible tools for tracking tasks, such as TrackStudio, are good because they allow you to formally customize management for any task life cycle model. This is their dignity and their disadvantage. As mentioned above, when there are no resources for initial setup, this system will not work. Taking boxed Megaplan and BitBucket, we understood that it would not work out to formally set them up for our life cycles of task implementation. Therefore, the further story a la “many-many crutches” about the informal use of these services.
How to implement our task life cycle model in “Megaplan + BitBucket”? First, the specific features associated with the code (p.1. “Development” of the hierarchical structure defined earlier) are entered into BitBucket, and the tasks for preparing materials for implementing features (TK + Layout + Test / Demo data) are in Megaplan tracker.
Algorithm like this:
We put in the Megaplan a task for a business analyst: “ Develop TK ” - with a reference-note “ Putting TK into a task X for a designer ”. The designer, also in Megaplan, is assigned the task “ Develop a Layout for TK ” with the same reference notes: “ Later, the TOR will put the task in the task of a business analyst, ready to lay out the Layout in task Y in BitBucket ”. The programmer and the tester work only in BitBucket'e, in terms of changing the status of tasks.
In the interface of these SOUPs there is no unification of the stages of work on the tasks. With inept project management, this can lead to negative consequences. From personal experience: if you do not manually coordinate the distribution of work (and automated tools do not), a situation may arise when, for example, the programmer is idle for weeks waiting for formal descriptions for features. This I watched at the last place of work. As a result, the lead developer quit, arguing his dismissal in a monologue in the spirit: “I’m bored because I don’t have a job, but I want to write code”. This is a good example of how inappropriate tools, or their informal use, can demoralize team members. Everyone who has decided, like us, to use the “Second bundle”, needs to understand and take into account these risks when working in such project management systems.
Our team is 4 people. Each is engaged in several design work. I, as a project manager, had to quickly finish with this very project management and get to work as a business analyst / technical writer, SEO specialist, marketer and copywriter. I didn’t want to go back to the work of PMM, and there was no possibility.
It is necessary to formulate and distribute all the tasks, linking them among themselves by references, appointing the executors and determining the quality criteria. To organize the process of work at a time so that it goes on its 30 days according to a worked out plan, when all the team members as performers would move from one completed task to the next, without losing time on the simple and peripheral. This is solved by compiling a table of works with the subsequent formulation of tasks for it in trackers:
Table: “Works on the implementation and promotion of the project Ahoba (; ver. Alpha-1”
Etc., only about 50 tasks.
According to the targets from Milestones, it turned out to formulate specific tasks. Some goals are described by one task, others are divided into several. Deadlines from Milestones allowed to place deadlines, focusing on the logical sequence of work. According to the previously established project roles, the performers responsible for certain tasks were assigned. The tasks themselves, of course, do not consist of merely the headings indicated in the table. Most of them were supplemented with descriptions, explanations, links to project documentation in Google Docs, checklists with steps or algorithms for execution ...
Separately, it is worth noting the parallelization at an early stage. While the PM is working on the tasks, the team has nothing to do. To avoid idle time, the work of PM starts with setting tasks that do not require detailed TK or analytics: The programmer starts by removing unnecessary functionality; The designer draws the logo of the project; SMM-manager selects content for posts on topics defined in the concept. Everything is in business, and the project manager is quietly working on fifty tasks, having planned the team’s activities for the next 30 days.
This is where project management ends, and only occasionally you have to go back to it: track task statuses, adjust deadlines and Milestones, if necessary.
Formal rules of setting and performing tasks
Tasks are formulated and set, deadlines and performers are defined, but in order to achieve goals without a hitch, you must follow a number of formal rules:
- Any idea, suggestion, wish, etc. pass through the PM, because he is responsible for the overall work and life cycles of individual tasks, defining and introducing everything new according to the current situation;
- All tasks are recorded in project management systems. Associated with the code - in BitBecket'e, all others - in Megaplan;
- For each task, a responsible person must be assigned and a deadline set;
- The task must have a complete, formal, unambiguous description. If the performer is not sure about the meaning of the task, he is obliged to clarify it with the task director before performing it. The producer, if necessary, complements the description;
- The order of the tasks - according to their deadlines. If the tasks have the same deadline, the performer chooses in what sequence to implement them;
- Status at work on tasks (set automatically and manually) and the reaction to them in Megaplan:
- “New task” - it is necessary to get acquainted with the essence and conditions of the task, to coordinate the order of performing its other tasks and the new one.
- “Accepted for execution” - the person responsible for the task knows about it, if he is free, works on its implementation.
- “Conditionally completed” - the status is set manually, after the executor has finished work on the task, has fulfilled all the conditions described in it. (For example, by the condition: laid out the ready Layout in the related task of developing GUI).
- “Completed” - set manually after the task provider has checked the quality of its execution;
- Status when working on tasks, service information in the headers (set only manually) and the reaction to them when working in BitBucket'e:
- The task must specify a type. The “task” type is set for tasks related to adding a new or changing the current functionality; “bug” type - for problems of correction of errors, shortcomings.
- Since In BitBucket, there is no “version” or “release” entity, for each task, at the beginning of its header, service information such as “RX” is added, where “R” is the label indicating the release, and “X” is the release number. An example of a label is “R0.1”. Transferring tasks from release to release is carried out by changing the service mark in the task header.
- A task is added without a status if there is no data in it (for example, the layout of a new GUI), while there should be a note in the description (for example: “ Later the designer will lay out the layout, the details in the task are link_to_task_to_develop_macket ”).
- The task is assigned the status of “new”, which means that all the descriptions for it are ready, and the programmer can start working on it;
- The task is assigned the status “resolved” when the programmer finishes the task and deploys changes to the test server. This status means that the tester can start testing the task.
- If errors are found in the completed task and can be corrected within the current task, the tester sets the status to “invalid”. This means that the programmer needs to correct the defects found. After editing, the programmer again sets the status “resolved”.
- After the current task is implemented without errors, or errors are placed in a separate task with the “bug” type, the task is assigned the status of “closed”.
- Each task is automatically assigned a unique ID. It is necessary for two things: a) to bind commits in a git repository to a specific task; b) to get the version number of the current release.
On these rules, tools and methodologies, project management was implemented when creating and promoting the startup Ahoba (; at the “Alpha-1” stage. The goals and conditions that we had were dictated by them.
Kirill,
Project Manager Online tool for Design SketchBuilder
Temporarily from the account of our programmer Anton (@skrutty)
Source: https://habr.com/ru/post/240919/
All Articles