October 20, 2014 at 13:20Tools and methodology of project management on the example of startup pivot
In a previous article, we told the story of our startup, examining three key components: “Idea,” “Implementation,” and “Sales.” Due to the large volume of the article, the issue of implementation formally did not have enough space to describe. We will correct this in this publication.
Team management begins with planning and design. There are dozens, if not hundreds, of project management methodologies: from “ReadMe Development” to cumbersome, but for all occasions PMBOK . As programmers sometimes invent bicycles, so project managers can sin by this. If with the methodology we could allow ourselves some liberties, then the tool was already selected without “bicycle building” ...
Pivot (from the English - to spin, turn around its axis) in the context of a startup is a rejection of the current business model, software product and restart of all work on a new concept. Explanation of why this happens, why it happened in our country is beyond the scope of this article. I will only explain 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-based document editor;
Megaplan - tracking tasks not related to code development;
Redmine + GIT - bugs and tasks related to code development + version control;
Kayako - a service for collecting feedback, bug reporting;
Such a combination is good when there are several projects in development, several customers, etc. (Redmine), many employees and tasks not related to working on the code (Megaplan), many users, and accordingly many: support, feedback, bug reports (Kayako).
“Link Two”
Google Docs - electronic document management and cloud-based document editor;
Megaplan - tracking tasks not related to code development + CRM system;
BitBucket instead of Redmine + GIT;
Yandex.Mail for a domain - for collecting 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), and there is still little feedback support, so there is enough configured web interface from mail (Yandex.pdd).
“Link Three”
Google Docs - as a cloud editor;
TrackStudio + GIT - task tracker, both by code and others + electronic document management;
Yandex.Mail for a domain - for collecting feedback, bug reporting.
This bunch is the most correct, it allows you to work on tasks in one system both by code and everything else. Unfortunately, the main tool in this bundle requires a lot of resources for tuning-doping (TrackStudio); on feedback support, just like in the “second bundle”, Yandex.pdd is enough.
These bundles were selected for different working conditions. Google Docs is always used: we just love it - it's a nice, fast and convenient cloud-based document editor.
Under our conditions: one project, we need to work both on the code and on the promotion, there are no users at all yet, a lot of support-feedback is not expected, they suggested the choice of a second or third “bundle”. The “third link” (based on TrackStudio) disappeared after a short thought - there was neither time nor resources to set up and 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 lack of opportunities to try new things, they relied on the experience of a project manager to communicate with a couple of dozens of other project management systems (SOFs) both specialized for software development and a wide range of applications: from Teamer to BugZill.
Why did we start by choosing tools and not planning?
Because the “second bundle” consists of two inflexible 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. Having chosen the tools, and knowing their limitations, you can proceed to the next stage - planning.
It will seem to someone that the situation when the tool dictates a methodology, and not a turnover, is very bad. In our opinion, if restrictions do not adversely affect productivity (for example, excessive bureaucracy), then you can come to terms with them.
General tasks are set in Megaplan, we will use its terminology. The starting point in the hierarchy of the task manager Megaplan - “Milestones”. A milestone is a section of a 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 boils down to creating milestones. Consider them as an example of our situation (we remake one project into another, prepare its promotion, for all 30 days, from September 5 to October 5).
Milestone # 1. “Preparatory phase”, completed by September 10:
- Selected and configured tools, local servers;
- The course of work is planned;
- The tasks are set and distributed;
- Drafted TOR for all tasks.
Milestone # 2. “Basic work”, completed by September 15:
— Произведен рефакторинг кода проекта (ускорит реализацию будущих задач);
— Подготовлены серверы и учетные записи, домены для продакшна;
— Разработан и собран ключевой контент для продвижения (по правилу «Бритвы Оккама»: 20% “ключевого” контента дадут 80% трафика);
Веха #3. “Первый наглядный результат”, закончено к 20 сентября:
— Рефакторинг редактора (перенесен в iframe, что позволит быстро реализовать “демо-режим”);
— Произведен редизайн GUI;
— “Запущены” блог проекта, сообщества в социальных сетях.
Веха #4. “Первый публичный результат”, закончено к 25 сентября:
— Добавлена форма приема платежей;
— Реализован демо-режим;
— На демо-режиме запущен промо-сайт с 90-100% запланированного контента;
- Version 0.0.11 is fixed in production;
- Community in the social. networks and a blog on the site are filled with first posts.
Milestone # 5. “Prepared project promotion”, completed by September 30:
- A blog was launched on Habrahabr;
- Implemented minor features and improvements;
- Passed moderation and connected billing system;
- Version 0.0.17 is fixed in production;
- According to the publication plan, posting in social services continues. network and blog site.
Final Milestone # 6. “The first promotion of the project”, completed by October 10:
- All the functionality conceived for the alpha version has been implemented;
- The release of version R0.1 Alpha-1 is approved for production;
- The first article was published in a blog on Habrahabr;
Scheduled Milestones # 7-X. “Creation of the community of the project”, completed by October 30:
- 3-5 articles were published in the blog on Habrahabr;
- Prepare and publish blog posts on the site, in the social community. networks;
- There is a collection and analysis of feedback, general correspondence with users who are interested in the project;
- Other promotion is planned and carried out according to the marketing concept;
- Hot fixes are made;
- The amounts of funds raised are analyzed, correlated with the possibilities for further development of projects.
We’ll finish the work on Milestones on this, further planning should continue, relying on the feedback received, and while it’s not there, it’s better to work on getting it.
Let me remind you: the first Milestones were planned based on“Marketing concept” . Our team consists of 4 people, several years working together on different projects. Similar to those set in Milestones for the Alpha version of Ahoba (; the tasks we already implemented in other projects. Therefore, when compiling the Milestones, the project manager already knew who and how would solve the tasks. This process took place informally, based on the past experience, empirical assessment and analytical forecasting.
You can write a book about these informal thought processes, about the history of their occurrence, sample trials, learning from mistakes, etc. You get a sort of “PMBOK Lite for Brain”. However, at the moment there is not just a book, but also a concept drawn up on paper: everything is 70% in PM’s head, and only the remaining 30% is in his personal abstract crib. Perhaps someday, and from these developments will turn out, albeit 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 who will implement them. One could immediately proceed to the next stage - setting formal tasks - but to simplify subsequent control over execution, it is worth using another tool - the hierarchical structure of the project.
A hierarchy is needed to compose / group tasks. Tasks have two main distinguishing characteristics: functional content and artist. You can design a hierarchy of tasks either by their functional grouping, or with reference to a specific executor. These are formal approaches. They simplify management, make it more transparent, but introduce a lot of excessive bureaucracy, which, in turn, reduces overall productivity. In many situations, you can sacrifice productivity for the sake of management, and this is justified, because gives 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 contractor, somewhere with reference to the functional content:
0. Design
1. Development of the project
2. Promotion of the project
2.1. Ahoba website and blog (;
2.2. Promotion in social networks
2.3. Promotion on Habrahabr
3. Development of design and media content
This structure will allow the performer not to be distracted by other people's tasks, although they are in the context of his work, which will also provide more I realize quickly.
When working on the compilation and formulation of formal tasks, all the shortcomings of the selected bunch of tools come up ...
The general principle-sequence through which most tasks in our projects go can be described as follows:
Different people with different roles work on the task at different stages: PM develops the concept of the task; business analyst, technical writer compose TK; the designer draws a layout; PM passes TK 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 ToR and the Layout, then as a QA specialist closes the task.
And this is the easiest option ... There are situations when it is impossible to determine how to implement the task. Then the programmer can connect to the task already at the design stage (for example: several interface prototypes can be implemented so that the usability expert evaluates each option and makes the final one in the implementation chain).
As a result, we have about 5 typical models of task life cycles and a couple of dozen “atypical” models.
Flexible task tracking tools, such as TrackStudio, are good because they allow you to formally configure management for any model of the task life cycle. This is both their advantage and their disadvantage. As mentioned above, when there are no resources for the initial setup, you cannot use this system. Taking the boxed Megaplan and BitBucket, we realized that formally setting them up for our life cycles would not work. 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 the “Megaplan + BitBucket” bundle? Firstly, specific features related to the code (item 1. “Development” from the hierarchical structure defined earlier) are entered into BitBucket, and the tasks of preparing materials for the implementation of features (TK + Layout + Test \ Demo data) - in Megaplan tracker.
The algorithm is approximately the following:
We put the task for the business analyst in Megaplan: “ Develop TK ” - with a link-note “ Put the finished TK into task X for the designer ”. To the designer, also in Megaplan, we set the task “ Develop a Layout for TK ” with the same reference notes: “ Later, the TK will be put into the task by a business analyst, ready to put the Layout into task Y in BitBucket" The programmer and tester work only in BitBucket, operating with a change in the status of tasks.
In the interface of these SOUPs there are no unification of the stages of work on 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 the tools do not do it automatically), a situation may arise when, for example, a programmer is idle for weeks waiting for formal descriptions for features. This I observed at the last place of work. As a result, the lead developer quit, arguing his dismissal as a monologue in the spirit: “I’m bored, because I don’t have work, 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 decided, like us, to use the “Second Link”, needs to understand and consider these risks when working in such project management systems.
Our team is 4 people. Each is engaged in several design work. As a project manager, I needed to finish this project management as soon as possible and start working as a business analyst / technical writer, SEO specialist, marketer and copywriter. I did not want to return to PM’s work, and there was no way.
It is necessary to formulate and distribute all the tasks, linking them together with links, appointing contractors and defining quality criteria. At a time, organize the work process so that it goes its 30 days according to the developed plan, when all team members as executors would move from one completed task to the next, without wasting time on the simple and the periphery. This is solved by compiling a work table with the subsequent formulation of tasks on it in trackers:
Table: “Work on the implementation and promotion of the Ahoba project (; ver. Alpha-1”
, etc., about 50 tasks in total.
It was possible to formulate specific tasks for the goals from Milestones. Some goals are described by one task, others are divided into several. from Milestones allowed us to arrange the deadlines, focusing on the logical sequence of work. According to pre-established project roles, the executives responsible for certain tasks were appointed. The tasks themselves, of course, do not consist of only the headers listed in the table. Most of them They were supplemented with descriptions, explanations, links to project documentation in Google Docs, checklists with steps or execution algorithms ...
Separately, it is worth noting parallelization at an early stage. While the PM is working on tasks, the team has nothing to do. To avoid downtime, PM’s work begins with the formulation of tasks that do not require detailed technical specifications or analytics: the programmer begins 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 at work, and the project manager is calmly working on fifty tasks, having planned out the team’s activities for the next 30 days.
This ends the project management, and only occasionally has to come back to it: track the status of tasks, adjust deadlines and Milestones, if necessary.
Tasks are formulated and set, deadlines and performers are defined, but in order to achieve your goals without a hitch, you must follow a number of formal rules:
Based on these rules, tools and methodology, project management was implemented during the creation and promotion of Ahoba startup (; at the “Alpha-1” stage. The goals and conditions that we had were dictated by them.
Kirill,
project manager Online tool for Design SketchBuilder
Temporary 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 “ReadMe Development” to cumbersome, but for all occasions PMBOK . As programmers sometimes invent bicycles, so project managers can sin by this. If with the methodology we could allow ourselves some liberties, then the tool was already selected without “bicycle building” ...
What is a startup pivot?
Pivot (from the English - to spin, turn around its axis) in the context of a startup is a rejection of the current business model, software product and restart of all work on a new concept. Explanation of why this happens, why it happened in our country is beyond the scope of this article. I will only explain what in our case meant “pivot”:
- limited resources - 4 people for all work;
- strictly defined dates - 30 calendar days;
- the need to fulfill 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;
- Development task: from an ancestor product v2.3 make a descendant product v0.1 alpha-1. The main changes relate to the processing of architecture for multi-design, adding new types of final documents, removing unnecessary functions, redesigning in accordance with the tastes of the new CA, creating a “demo mode” of work;
- Financial and marketing task: to release a product as soon as possible and attract an audience to it, having analyzed the reaction to it. Based on the analysis, draw up a plan for further development. With the additional finances received, accelerate the development of new functionality;
- Designing began with the creation of a marketing concept document in which the main ideas and theses were formulated: what work needs to be done to realize the tasks;
- The composition of the team and the responsibilities that they perform:
“Programmer” - front-end / back-end development, system administration;
“Tester” - software testing, writing bug reports, SMM and content management, analysis and processing of feedback;
“Designer” - development of the appearance and mechanics of the GUI, creation and preparation of media content;
“Project manager” - analytics, design, planning, management (project, marketing, financial, etc.), development of technical documentation, text content, SEO. - A limitation is a requirement from our mentor investors: 30 days to remake the 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-based document editor;
Megaplan - tracking tasks not related to code development;
Redmine + GIT - bugs and tasks related to code development + version control;
Kayako - a service for collecting feedback, bug reporting;
Such a combination is good when there are several projects in development, several customers, etc. (Redmine), many employees and tasks not related to working on the code (Megaplan), many users, and accordingly many: support, feedback, bug reports (Kayako).
“Link Two”
Google Docs - electronic document management and cloud-based document editor;
Megaplan - tracking tasks not related to code development + CRM system;
BitBucket instead of Redmine + GIT;
Yandex.Mail for a domain - for collecting 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), and there is still little feedback support, so there is enough configured web interface from mail (Yandex.pdd).
“Link Three”
Google Docs - as a cloud editor;
TrackStudio + GIT - task tracker, both by code and others + electronic document management;
Yandex.Mail for a domain - for collecting feedback, bug reporting.
This bunch is the most correct, it allows you to work on tasks in one system both by code and everything else. Unfortunately, the main tool in this bundle requires a lot of resources for tuning-doping (TrackStudio); on feedback support, just like in the “second bundle”, Yandex.pdd is enough.
These bundles were selected for different working conditions. Google Docs is always used: we just love it - it's a nice, fast and convenient cloud-based document editor.
Under our conditions: one project, we need to work both on the code and on the promotion, there are no users at all yet, a lot of support-feedback is not expected, they suggested the choice of a second or third “bundle”. The “third link” (based on TrackStudio) disappeared after a short thought - there was neither time nor resources to set up and 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 lack of opportunities to try new things, they relied on the experience of a project manager to communicate with a couple of dozens of other project management systems (SOFs) both specialized for software development and a wide range of applications: from Teamer to BugZill.
Planning
Why did we start by choosing tools and not planning?
Because the “second bundle” consists of two inflexible 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. Having chosen the tools, and knowing their limitations, you can proceed to the next stage - planning.
It will seem to someone that the situation when the tool dictates a methodology, and not a turnover, is very bad. In our opinion, if restrictions do not adversely affect productivity (for example, excessive bureaucracy), then you can come to terms with them.
General tasks are set in Megaplan, we will use its terminology. The starting point in the hierarchy of the task manager Megaplan - “Milestones”. A milestone is a section of a 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 boils down to creating milestones. Consider them as an example of our situation (we remake one project into another, prepare its promotion, for all 30 days, from September 5 to October 5).
Milestone # 1. “Preparatory phase”, completed by September 10:
- Selected and configured tools, local servers;
- The course of work is planned;
- The tasks are set and distributed;
- Drafted TOR for all tasks.
Milestone # 2. “Basic work”, completed by September 15:
— Произведен рефакторинг кода проекта (ускорит реализацию будущих задач);
— Подготовлены серверы и учетные записи, домены для продакшна;
— Разработан и собран ключевой контент для продвижения (по правилу «Бритвы Оккама»: 20% “ключевого” контента дадут 80% трафика);
Веха #3. “Первый наглядный результат”, закончено к 20 сентября:
— Рефакторинг редактора (перенесен в iframe, что позволит быстро реализовать “демо-режим”);
— Произведен редизайн GUI;
— “Запущены” блог проекта, сообщества в социальных сетях.
Веха #4. “Первый публичный результат”, закончено к 25 сентября:
— Добавлена форма приема платежей;
— Реализован демо-режим;
— На демо-режиме запущен промо-сайт с 90-100% запланированного контента;
- Version 0.0.11 is fixed in production;
- Community in the social. networks and a blog on the site are filled with first posts.
Milestone # 5. “Prepared project promotion”, completed by September 30:
- A blog was launched on Habrahabr;
- Implemented minor features and improvements;
- Passed moderation and connected billing system;
- Version 0.0.17 is fixed in production;
- According to the publication plan, posting in social services continues. network and blog site.
Final Milestone # 6. “The first promotion of the project”, completed by October 10:
- All the functionality conceived for the alpha version has been implemented;
- The release of version R0.1 Alpha-1 is approved for production;
- The first article was published in a blog on Habrahabr;
Scheduled Milestones # 7-X. “Creation of the community of the project”, completed by October 30:
- 3-5 articles were published in the blog on Habrahabr;
- Prepare and publish blog posts on the site, in the social community. networks;
- There is a collection and analysis of feedback, general correspondence with users who are interested in the project;
- Other promotion is planned and carried out according to the marketing concept;
- Hot fixes are made;
- The amounts of funds raised are analyzed, correlated with the possibilities for further development of projects.
We’ll finish the work on Milestones on this, further planning should continue, relying on the feedback received, and while it’s not there, it’s better to work on getting it.
Let me remind you: the first Milestones were planned based on“Marketing concept” . Our team consists of 4 people, several years working together on different projects. Similar to those set in Milestones for the Alpha version of Ahoba (; the tasks we already implemented in other projects. Therefore, when compiling the Milestones, the project manager already knew who and how would solve the tasks. This process took place informally, based on the past experience, empirical assessment and analytical forecasting.
You can write a book about these informal thought processes, about the history of their occurrence, sample trials, learning from mistakes, etc. You get a sort of “PMBOK Lite for Brain”. However, at the moment there is not just a book, but also a concept drawn up on paper: everything is 70% in PM’s head, and only the remaining 30% is in his personal abstract crib. Perhaps someday, and from these developments will turn out, albeit 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?”.
Development of the project structure
So, we have Milestones, there is a team of 4 people who will implement them. One could immediately proceed to the next stage - setting formal tasks - but to simplify subsequent control over execution, it is worth using another tool - the hierarchical structure of the project.
A hierarchy is needed to compose / group tasks. Tasks have two main distinguishing characteristics: functional content and artist. You can design a hierarchy of tasks either by their functional grouping, or with reference to a specific executor. These are formal approaches. They simplify management, make it more transparent, but introduce a lot of excessive bureaucracy, which, in turn, reduces overall productivity. In many situations, you can sacrifice productivity for the sake of management, and this is justified, because gives 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 contractor, somewhere with reference to the functional content:
0. Design
1. Development of the project
2. Promotion of the project
2.1. Ahoba website and blog (;
2.2. Promotion in social networks
2.3. Promotion on Habrahabr
3. Development of design and media content
This structure will allow the performer not to be distracted by other people's tasks, although they are in the context of his work, which will also provide more I realize quickly.
Setting goals
When working on the compilation and formulation of formal tasks, all the shortcomings of the selected bunch of tools come up ...
The general principle-sequence through which most tasks in our projects go can be described as follows:
A brief concept of the task → Development of detailed TOR → Creation of test / demo content → Creation of GUI layouts for TK → Formulation of a formal task for implementation in the task tracker (TK + Layout) → Implementation → Testing → Bugfix (if necessary) → Closing the task.
Different people with different roles work on the task at different stages: PM develops the concept of the task; business analyst, technical writer compose TK; the designer draws a layout; PM passes TK 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 ToR and the Layout, then as a QA specialist closes the task.
And this is the easiest option ... There are situations when it is impossible to determine how to implement the task. Then the programmer can connect to the task already at the design stage (for example: several interface prototypes can be implemented so that the usability expert evaluates each option and makes the final one in the implementation chain).
As a result, we have about 5 typical models of task life cycles and a couple of dozen “atypical” models.
Flexible task tracking tools, such as TrackStudio, are good because they allow you to formally configure management for any model of the task life cycle. This is both their advantage and their disadvantage. As mentioned above, when there are no resources for the initial setup, you cannot use this system. Taking the boxed Megaplan and BitBucket, we realized that formally setting them up for our life cycles would not work. 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 the “Megaplan + BitBucket” bundle? Firstly, specific features related to the code (item 1. “Development” from the hierarchical structure defined earlier) are entered into BitBucket, and the tasks of preparing materials for the implementation of features (TK + Layout + Test \ Demo data) - in Megaplan tracker.
The algorithm is approximately the following:
We put the task for the business analyst in Megaplan: “ Develop TK ” - with a link-note “ Put the finished TK into task X for the designer ”. To the designer, also in Megaplan, we set the task “ Develop a Layout for TK ” with the same reference notes: “ Later, the TK will be put into the task by a business analyst, ready to put the Layout into task Y in BitBucket" The programmer and tester work only in BitBucket, operating with a change in the status of tasks.
In the interface of these SOUPs there are no unification of the stages of work on 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 the tools do not do it automatically), a situation may arise when, for example, a programmer is idle for weeks waiting for formal descriptions for features. This I observed at the last place of work. As a result, the lead developer quit, arguing his dismissal as a monologue in the spirit: “I’m bored, because I don’t have work, 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 decided, like us, to use the “Second Link”, needs to understand and consider these risks when working in such project management systems.
Our team is 4 people. Each is engaged in several design work. As a project manager, I needed to finish this project management as soon as possible and start working as a business analyst / technical writer, SEO specialist, marketer and copywriter. I did not want to return to PM’s work, and there was no way.
It is necessary to formulate and distribute all the tasks, linking them together with links, appointing contractors and defining quality criteria. At a time, organize the work process so that it goes its 30 days according to the developed plan, when all team members as executors would move from one completed task to the next, without wasting time on the simple and the periphery. This is solved by compiling a work table with the subsequent formulation of tasks on it in trackers:
Table: “Work on the implementation and promotion of the Ahoba project (; ver. Alpha-1”
, etc., about 50 tasks in total.
It was possible to formulate specific tasks for the goals from Milestones. Some goals are described by one task, others are divided into several. from Milestones allowed us to arrange the deadlines, focusing on the logical sequence of work. According to pre-established project roles, the executives responsible for certain tasks were appointed. The tasks themselves, of course, do not consist of only the headers listed in the table. Most of them They were supplemented with descriptions, explanations, links to project documentation in Google Docs, checklists with steps or execution algorithms ...
Separately, it is worth noting parallelization at an early stage. While the PM is working on tasks, the team has nothing to do. To avoid downtime, PM’s work begins with the formulation of tasks that do not require detailed technical specifications or analytics: the programmer begins 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 at work, and the project manager is calmly working on fifty tasks, having planned out the team’s activities for the next 30 days.
This ends the project management, and only occasionally has to come back to it: track the status of tasks, adjust deadlines and Milestones, if necessary.
Formal rules for setting and completing tasks
Tasks are formulated and set, deadlines and performers are defined, but in order to achieve your goals without a hitch, you must follow a number of formal rules:
- Any idea, suggestion, wish, etc. pass through PM'a, 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 fixed in project management systems. Associated with the code - in BitBecket, all others - in the Megaplan;
- For each task, a responsible person must be assigned and a deadline defined;
- The task should have a complete, formal, unambiguous description. If the contractor is not sure of the meaning of the task, he is obliged to check it with the task director before its implementation. The director, if necessary, supplements the description;
- The order of the tasks is according to their deadlines. If the tasks have the same deadline, the executor chooses in what order to implement them;
- Statuses when working on tasks (set automatically and manually) and the reaction to them in Megaplan:
- “New task” - you need to familiarize yourself with the essence and conditions of the task, agree on the execution of your other tasks and the new one.
- “Accepted for execution” - the person responsible for the task knows about it, if free, works on its implementation.
- “Conditionally completed” - the status is set manually, after the contractor has finished work on the task, fulfilled all the conditions described in it. (For example, by condition: posted the finished Layout in a related task for developing a GUI).
- “Completed” - is set manually after the task provider has checked the quality of its execution;
- Statuses when working on tasks, service information in headers (set only manually) and reaction to them when working in BitBucket:
- The task must have a type specified. Type “task” - set for tasks related to adding new or changing current functionality; type “bug” - for the tasks of fixing errors, bugs.
- Because in BitBucket there is no entity “version” or “release”, for each task, service information of the “RX” type is added at the beginning of its header, where “R” is the label indicating the release, and “X” is the release number. An example of a label is “R0.1”. The task is transferred from release to release by changing the service label in the task header.
- A task is added without a status if it does not contain any data (for example, the layout of the new GUI), and the description should contain a note (for example: “ Later the designer will lay out the layout, details in the task - link_to_task_by_development_mock ”).
- The task is set to the “new” status, which means that all the descriptions on it are ready, and the programmer can start working on it;
- The task is set to the status “resolved” when the programmer finishes work on the task and sends changes to the test server. This status means that the tester can begin testing the task.
- If errors are found in the completed task and they can be corrected as part of 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 to “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) for binding commits in the git repository to a specific task; b) to obtain the version number of the current release.
Based on these rules, tools and methodology, project management was implemented during the creation and promotion of Ahoba startup (; at the “Alpha-1” stage. The goals and conditions that we had were dictated by them.
Kirill,
project manager Online tool for Design SketchBuilder
Temporary from the account of our programmer Anton (@skrutty)