Category: Slava Moisieiev

 Date

27 дек. 2022 г.– 30 дек. 2022 г.

 Participants

• Slava Moisieiev (Unlicensed)

 Discussion topics

 Date

19 дек. 2022 г. – 23 дек. 2022 г.

 Participants

• Slava Moisieiev (Unlicensed)

 Goals

Create Business Flows in order for correct work of the PM department

 Discussion topics

 Overview

Code Review is an important process of the development cycle. In order to make sure that the code is clean and correct it must be reviewed by the teamleads

  Flow


• The code review process is an absolute must in regards to the development process. 

• It must be done separately for the FE and BE part. 

• FE code review should start with the home page. 

• FE pages with increased complexity should also be sent for code review.

• As for the BE part, it should be done each 25% of the finalised project (for small ones) and each epic for big projects. This part is defined with the Team lead – the exact percentage

• It should be done before the QA part. There is no need for the second circle of code review for the Epic/ task if there is something wrong in the QA part, unless discussed.

• A request for a repeated code review can be sent by PM if he considers it necessary or there is a suspicion that something may go wrong.

 Overview

Planning of the project is an important part of management. It is a requirement before starting the project in order to understand when it is started, processed and finished. It helps to plan the resources, project execution and testing.

Flow

• When there is a ready to go scope, all of the tasks and epics must be entered into Jira and added estimation time.

• If the resources are already known, it is important to assign tasks to each member of the team

• Afterwards it is important to make a planning with all the further sprints and divide the tasks into them. 

• There will be also major tasks within each projects, that will be on a daily basis (communication) and at the beginning of the project (environment creation)

• Schedule daily meetings with the team in the calendar via zoom and create a space in Confluence for notes

 Tips and tricks


• If the project is small (2-3 months), it might be better to work with 1 week sprints and show a demo once in 2 sprints

• If the project is medium or big (3 months and beyond), it is better to work with 2 week sprints and have a demo with the customer each sprint

• Planning for medium and big projects must be done with the whole team (or at least with the teamleads)

 Overview

Estimation of a project is not always an easy process. It requires a full understanding of the incoming information, perseverance on what is being estimated.

 Estimation Flow

• When the first time the customer contacts the sales manager with all incoming information, the sales manager will have the new template for estimation already. Sales Manager is required to fill in the brief and the stakeholder register.

• PMO assigns a PM based on the requirements for the estimate, along with the developer(s) and QA for the estimation (sometimes, the PM will choose the developer(s) himself)

• The incoming documentation must be read by the PM, developers and QA

• There will be a new template for estimation that will be shared with the customer.

• The estimation must be based upon the incoming documentation from the customer. 

• The primal Estimation should be High Level, based on epics or main functions. 

• The Team Register should be filled in by the PM

• All the epics and main functions are to be entered by the PM and the developers estimating.

• After the customer agrees on the proposal, the estimation should be decomposed into tasks and be more detailed.

• Based on the total tasks hours, it is to be counted and added the time required for communication, planning, environment etc. For communication for daily meetings – 15 min per team member for each day. For planning it is approximately 1 hour per sprint (depending on the size of the project), for the environment – 8-16 hours depending on the dev.

 Tips and tricks


• If there is not enough incoming information, risks should be considered as well.

• In case of risks, the presumptions should be also written along with the percentage of the risk

• Risks can be added in percentage and discussed with the PMO.

 Overview

Communication with the customer is one of the main aspects of a successful project. It is very important for the communication to be agile, straight to the point and on a truthful basis. Since we are professionals, there will be implemented certain flows in order to make this process more correct from a professional point of view.

Communication flow

• All communications with the customer must take place in slack and via email (call meetings must be taken in zoom so there would  be a possibility to record it)

• After each call with the customer, there should be an email follow up with the bullet points discussed (template will be prepared and linked here)

• Since we are aiming for less documents to be and all in one place, there will be a document implemented( will be linked here), where all of the main info aspects of the projects remain, such as – primal estimation, communication map with the stakeholder, list of developers, change request/bugs document, questions and answers.

• Of course the project passport will remain in Jira, however this document will be shared with the customer.

• The change requests will be estimated one by one and added by the customer along with the description. After confirmation from the customer  – we will take it into work (this sprint or the next)

• All important decisions must be traced in an email. It is a 100% must. All agreed new changes/new requests with the hours especially. They are also to be added to the Project space as an update.

• All change requests from the customer are to be informed to the team.

• All calls must be in the calendar scheduled with all of the required participants

• Never have a customer wait. Provide updates to this or that task before the customer asks you. Make sure that if you promise update within a specific period of time, provide it. Even if the task is still in progress.

• Whenever the customer writes a message, and there is no time to reply, add the eyes sign – this will mean that you have seen the message and will reply within a couple of hours.
  Always reply to the customer`s message within a small period of time (1-2 hours max, better immediately) – in this case the customer will see that the message has been received

• if the sprint is one week, a report must be sent to the customer – worked tasks and hours(hours are optionally). If the sprint is 2 weeks, then such report is to be sent once in 2 weeks after sprint ends.

• Every two weeks, on Friday`s, a report with updates should be sent to the customer. What was worked, what issues happened along the way (optional), what are the plans for the next two weeks.
  It should be done via email only.

 Tips and tricks


Here are some tips

• Never promise a customer something that you are not 100% sure of

• If there is something urgent required by the customer, and you are not sure if it is possible, or need a tip, always check with your PMO

• Always take responsibility for any action or any promise you give to the customer.

• RECOMMENDATION: Do your best to become friends with the customer, it will help a lot in the Future

• Be always proactive, update the customer every hour for an urgent task if it is even in progress still.

 Overview

Communication is one of the most important parts of any development process. It is the process that requires incredible soft skills in order to do the job correctly. In development there are certain rituals and best practices that are required. Such will be listed below.

 Communication Rituals


Here will be listed all the required Internal Rituals in regards to communication

Daily Stand Up Meetings

• All projects must have stand up meetings on a daily basis where all developers must be.

• The Daily meeting for each project must take not more than 15 minutes

• All Stand up Meetings must be scheduled in the Calendar with all of the participants on a daily basis

• All the stand up meetings must be noted in confluence with the Daily Standup meeting template

  

  Only titles of the table should be changed:
  Priorities – What was done?
  Progress – What is planned to be done?
  Problems – Blockers

• The notes must be taken in every confluence space of the project on a daily basis

• If you see that a lot of your developers are one multiple projects, you can combine the standup, but notes are to be added to each project separately.

• Use Zoom in order to record a meeting if you feel it is required

• Make sure that everything is being told straight to the point, in order to “not waste time on water”

• If somebody does not have an opportunity to join, the developer must write down the status in the slack channel, which will be added by the Project Manager to the confluence page

• Each project, even if a small one, should have a channel in slack with all the developers added in order for quick communication

• There will be 1:1 on a weekly basis with PMO

 Date

12 дек. 2022 г. – 16 дек. 2022 г.

 Participants

• Slava Moisieiev (Unlicensed)

 Discussion topics

 Conclusions

• Over the past couple of weeks, I had a possibility to dive into the projects. I have made certain conclusions of what has to be fixed:

• 1. Company is loosing certain income, because of incorrect flow of receiving change requests or additional small fixes.
• 2. Communication flow between the customer and the Project manager is to be improved. All is done within the chat space, without any follow ups via emails, etc.
• 3. There are no stand ups in the team. And no tracking of daily changes. The new flow will change that. Starts from January.
• 4. Transfer knowledge of one project from another pm to another should be done via ready to go flow that has been prepared by Sophia. Starts from January
• 5. Testing – as i see, the developers do not (or do not always) test themselves on what they have done within this or another task. This is also to change
• 6. As the projects are not very big, they are to be planned also easily, divided into sprints, etc. This I do not see in Jira. It is also a flow to be changed.

 Date

6 дек. 2022 г.– 9 дек. 2022 г.

 Participants

• Slava Moisieiev (Unlicensed)

 Discussion topics

 Action items

 Decisions

Create meeting note

Incomplete tasks from meetings

Decisions from meetings

All meeting notes