You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Частина 1 "Початок роботи АТ "Прозорро.Продажі" - Видача ключів до тестового середовища

  1. Подання запиту на інтеграцію – Майданчик подає запит на первинну взаємодію через форму на порталі АТ "Прозорро.Продажі"
  2. Укладення договору на інтеграцію – Менеджер по роботі з майданчиками підписує договір про інтеграцію з майданчиком.
  3. Створення каналу Slack – Менеджер по роботі з майданчиками створює канал в Slack, додає розробника та менеджмент майданчика, додає всі необхідні WF для якісної взаємодії з майданчиком та запускає WF "Отримання інтеграційного ключа"
  4. Отримання технічної документації – Менеджер по роботі з майданчиками додає до Slack каналу посилання на технічну документацію (ТЗ процедур Swagger)
  5. Подання запиту на інтеграційний ключ – Майданчик подає запит на отримання ключа до інтеграційного оточення через надання посилання на SD у розпочатому WF "Отримання ключа до оточення для розробки"
  6. Надання інтеграційного ключа – DevOps команда виконує видачу ключів до інтеграційного оточення до всіх напрямків , коментуючи доступ в конфігураційному файлі вручну.
  7. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до інтеграційного оточення.

Частина 2. Розробка майданчиком функціоналу
Частина 3. Акредитація та тестування + Видача ключа до продуктивного оточення

  1. Подання запевнення про намір проходження акредитації:
    1. Майданчик подає запевнення про намір проходження акредитації
    2. Проходить 1-2-1 з менеджером по роботі з майданчиками
    3. Ознайомлення з внутрішньою документацією
  2. Подача документів до МЮ:
    1. Майданчик підготовлює перелік документів для проходження акредитації
    2. Майданчик подає пакет документів до міністерства юстицій (далі МЮ)
    3. МЮ розглядає пакет документів та надає рішення
  3. Подача доументів до АТ "Прозорро.Продажі"комісії:
    1. Надання майданчиком пакету документів з рішенням від МЮ через офіційну пошту(ел. та паперовий варіант)
    2. Перевірка юридичним відділом АТ "Прозорро.Продажі" пакету документів на наявність всього переліку
  4. Розгляд комісією:
    1. Комісія проводить перевірку та рекомендує (або ні) майданчик до роботи в системі АТ"Прозорро.Продажі"
    2. Комісія видає протокол
  5. Створення задачі на акредитацію – Менеджер по роботі з майданчиками створює задачу в системі (для виконання всіх дій по акредитації тощо)
  6. Укладення договору на тестування – Менеджер по роботі з майданчиками підписує договір про тестування з майданчиком.
  7. Оплата тестування – Майданчик оплачує тестування (у разі якщо воно є оплачуваним).
  8. Початок майданчиком WF ""
  9. Перевірка наявності всіх документів для подачі заявки на тестування та тестовий ключ – Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні та наявна сплата за тестування.
  10. Подача заявки на тестування – Майданчик створює заявку посилання в SD отриманому в WF "Взаємодія для тестування функціоналу"+"Видача ключа до тестового оточення". 
  11. Тестування – Проводиться тестування доступу з виданими ключами.
  12. Завершення тестування:
    1. Команда QA надає draft висновка тестування менеджеру по роботі з майданчиками
    2. Якщо тестування успішне Команда QA закриває задачу на тестування в JIRA та інформують Менеджера по роботі з майданчиками.
    3. Якщо тестування не успішне Команда QA не закриває задачу на тестування в JIRA але інформує Менеджера по роботі з майданчиками.
  13. Закриття акта виконаних робіт – Команда по роботі з майданчиками інформує відділ бухгалтерського обліку про завершення робіт.
  14. Укладення договору про використання ЕТС – Менеджер по роботі з майданчиками укладає договір із майданчиком.
  15. Початок майданчиком WF "Отримання продуктивного ключа" – Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Отримання продуктивного ключа".
  16. Перевірка наявності всіх документів для подачі заявки на прод ключі– Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні.
  17. Подання запиту на продуктивний ключ – Майданчик подає запит на отримання ключа до продуктивного оточення через заповнення форми SD у розпочатому WF "Отримання продуктивного ключа"
  18. Перевірка створеного запиту на наявність усіх документів – Менеджер по роботі з майданчиками перевіряє зазначений перелік доступів та підтведжує видачу змінивши виконавця задачі на DevOps команду (П. Кузьменко).
  19. Надання ключів до продуктивного оточення – DevOps команда виконує видачу ключа з доступами зазначеними в задачі, коментуючи доступ в конфігураційному файлі вручну.
  20. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до продуктивного оточення .
  21. Створення заявки на відділ маркетингу  після надходження повідомлення про надання продуктивних ключей майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для додавання логотипу майданчика з порталу та з каталогу.
  22. Оновлення інформації на порталі – Контент менеджер додає логотип майданчика на портал та до каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
  23. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
  24. Оновлення статусу задачі – після виконання всіх дій і домовленостей по основній задачі, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")

Частина 5. Розробка майданчиком додаткового функціоналу

Частина 6. Тестування розширеного функціоналу

Частина 7. Розширення дозволів на продуктивне оточення

  1. Подання запиту на ключ – Майданчик подає запит на розширення ключа до продуктивного оточення через WF "Розширення дозволів на Прод оточення".
  2. Перевірка створеного запиту на наявність всіх документів Менеджер по роботі з майданчиками підтверджує проходження тестування та наявність договорів за протестованим функціоналом з майданчиком змінивши виконавця задачі на DevOps команду (П. Кузьменко).
  3. Розширення дозволів ключа до продуктивного оточення – DevOps команда виконує розширення дозволів ключа відповідно до зазначених задачі, коментуючи доступ в конфігураційному файлі вручну.
  4. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до продуктивного оточення .

Частина 8. Блокування майданчиків на всіх ототченнях / Обмеження дозволів 

  1. Офіційний лист/виявлення порушення – Якщо майданчик ініціює вихід , подається офіційний лист про розірвання договору (на основі завершення співпраці чи фінансових причин). Якщо ж є порушення, то питання ініціюється з нашого боку.
  2. Створення завдання – Менеджер по роботі з майданчиками створює задачу в системі та тегає Тараса Бондарчука (приклад: SBM-1046 Аутентификация для просмотра подробных данных проблемы ) для подальшого виконання.
  3. Юридична перевірка – Юридичний відділ проводить перевірку обґрунтованості вимоги та підтверджує її.
  4. Офіційне підтвердження – Наказ про припинення/обмеження доступу (видається юридичним відділом або менеджером по роботі з майданчиками); у разі власного бажання – розірвання договору.
  5. Інформування бухгалтерії – Бухгалтерія інформується про припинення доступу майданчику.
  6. Оцінка на наявність активних об'єктів – Визначає подальший шлях чи це блокування чи обмеження ключів
  7. Якщо всі взаємодії завершено - відбувається блокування ключів
    1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
    2. Виконання блокування – DevOps команда виконує блокування, коментуючи доступ в конфігураційному файлі вручну.
    3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про блокування доступу майданчику.
    4. Створення заявки на відділ маркетингу  після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
    5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
    6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
    7. Оновлення статусу задачі на юр відділ – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done").
  8. Якщо присутні обмеження, які не дозволяють повне блокування ключів - відбувається обмеження дозволів 
    1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
    2. Виконання блокування – DevOps команда виконує обмеження доступів ключа згідно задачі, коментуючи доступ в конфігураційному файлі вручну.
    3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про обмеження доступу майданчику.
    4. Створення заявки на відділ маркетингу  після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
    5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
    6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
    7. Оновлення статусу задачі на юр відділ – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")

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

  • No labels