PM + Dev cooperation document

Комунікація в команді

• Уся команда має ставити реакції на повідомлення в загальних чатах і приватних повідомленнях, щоб позначити, що ви побачили повідомлення.

• Обговорення проектних питань мають відбуватися у каналі проекту, аби залучені члени команди були в курсі апдейтів.

• Якщо обговорення задачі було довгий час назад (тиждень і більше) та по тому ж питанню є апдейти або нові прохання до розробника, РМ має створити нове повідомлення в каналі, щоб нові деталі не загубилися, до якого має бути доданий лінк на попередній тред.

• Якщо РМ пише розробнику в особисті повідомлення стосовно задачі, то до повідомлення має бути прикріплений лінк на задачу.

• Команда має бути відкритою до комунікації з РМ, та спілкування щодо задач має бути доведеним до кінця: коли задача або зроблена, або визначені подальші кроки стосовно вирішення питання.

• Комунікація по проблемних питаннях проєкту чи питаннях по задачі повинна бути чіткою та зрозумілою, апдейти/репорти по задчах донесені структуровано, щоб РМ міг передати технічно зрозумілий фідбек клієнту.

• Усі члени команди мають ставитися із розумінням пріоритетів, встановлених РМ. Поважаємо та розуміємо пріоритети, встановлені РМ.

Апдейти по задачах

• При передачі сторінки на Code Review, потрібно описати виконані дії та додати лінки до відповідних сторінок та merge request (в гілку stage) в задачу в Jira:
  FE — на фронтову сторінку,
  BE — на кінцеву сторінку на стейдж/прод.

• Репорти по задачах мають бути оформлені чітко та лаконічно, з урахуванням пояснення причини виникнення проблеми та підібраного рішення, аби колегам було зрозуміло, що саме було виконано, а РМ міг передати зрозумілий клієнту апдейт/фідбек.

• Формуючи репорт по задачах, розробник має вказувати, чому задача була виконана тим чи іншим чином. Наприклад, клієнт попросив виконати задачу якимось чином, попри те, що розробник пропонував інший підхід. У такому випадку, це треба зазначити у репорті окремим пунктом.

• При виконанні задачі необхідно змінювати статус завдання: якщо воно завершено розробником, то воно не залишається без дії, а переходить у статус "Ready for QA", змінюючи Assignee на QA.

Труднощі з задачею

• Якщо оцінка по задачі занижена, слід повідомити РМ про це завчасно.

• Команда має відкрито спілкуватися з РМ та не соромитися звертатися до Тім-ліда у разі проблем із завданням.

Робочі години та days-off

• Уся команда повинна бути присутньою у робочий час та старатися відповідати на повідомлення швидко. У випадку, якщо зараз зайняті, слід коротко відписати на кшталт: “я зайнятий, зможу обговорити через …”

• Якщо член команди не зможе працювати у певний проміжок часу, слід попередити Тім Ліда про це завчасно та додати часову рамку, коли зможе повернутися до роботи.
  В свою чергу, Тім Лід має передати цю інформацію у каналі РМО.

• Слід трекати час на задачі у реальному часі через TimeDoctor, коли над ними працюємо. Повинно бути затрекано 8 годин за день.
  Якщо розробник не використовує трекінг в TD, то час має логуватись вручну до кінця робочого дня.

• Коли йдемо на перерву чи обід, оновлюємо статус в Slack та вказуємо час, коли повернемося у текстовому полі.

• Якщо потрібно взяти вихідний або відпустку, обовʼязково має бути створений відповідний запит в Hurma. Тоді колеги, що взаємодіють з даним розробником на різних проєктах, мають поставити позитивну/негативну реакцію на цей запит в Hurma (відповідно до того, наскільки сильно людина потрібна на проєкті саме в ці дати), а фінальне затвердження вихідного/відпустки проставляє РМО.

• Коли беремо вихідний або відпустку, оновлюємо статус в Slack на vacation та вказуємо перший робочий день після відпустки у текстовому полі.