В ситуації коли по технічним причинам не працюють WF (програмний збій, тощо) заявки для виконання команд необхідно створювати. 

  1. Отримання інтеграційного ключа
  2. Отримання тестового ключа 
  3. Отримання продуктивного ключа
  4. Тестування майданчика
  5. Тестування окремого функціоналу

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

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

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

  1. Подання запевнення про намір проходження акредитації:
    1. Майданчик подає запевнення про намір проходження акредитації
    2. Проходить 1-2-1 з менеджером по роботі з майданчиками
    3. Ознайомлення з внутрішньою документацією (Положення про тестування, тощо)
  2. Подача документів до МЮ:
    1. Майданчик підготовлює перелік документів для проходження акредитації визначений пунктом 22 Постанови КМУ №865
    2. Майданчик подає пакет документів до міністерства юстицій (далі МЮ) на адресу: 01001 м.Київ, вул.Городецького, 13.
    3. МЮ розглядає пакет документів та надає рішення
  3. Подача доументів до АТ "Прозорро.Продажі"комісії:
    1. Надання майданчиком пакету документів з рішенням від МЮ через офіційну пошту(ел. та паперовий варіант + скан-копїії):
      1. паперовий варіант + скан копії  - отримувач АТ «Прозорро.Продажі»: 01601, м.Київ, вул.Бульварно-Кудрявська 22; скан-копії: ел. адреса info@prozorro.sale;;
      2. ел. варіант - адреса  info@prozorro.sale з темою «Документи для проходження тестування» підписавши КЕП.)
    2. Перевірка юридичним відділом АТ "Прозорро.Продажі" пакету документів на наявність всього переліку
  4. Розгляд комісією:
    1. Комісія проводить перевірку та рекомендує (або ні) майданчик до роботи в системі АТ"Прозорро.Продажі"
    2. Комісія видає протокол та публікує відповідний витяг із протоколу за результатами розгляду на порталі.
  5. Створення задачі на акредитацію – Менеджер по роботі з майданчиками створює задачу в системі (для виконання всіх дій по акредитації тощо)
  6. Укладення договору на тестування – Менеджер по роботі з майданчиками підписує договір про тестування з майданчиком та надає рахунок на тестування. *Розмір плати за тестування визначається пунктом 24 Порядку та пунктом 8 Порядку відбору операторів.
  7. Оплата тестування – Майданчик оплачує тестування.
  8. Початок майданчиком WF "Взаємодія для тестування функціоналу" – Майданчик починає WF через Slack
  9. Перевірка наявності всіх документів для подачі заявки на тестування та тестовий ключ – Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні та наявна сплата за тестування.
  10. Cтворення аккаунту майданчика в Jira та GitLab - Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні та наявна сплата за тестування.
  11. Подача заявки на тестування – Майданчик створює заявку посилання в SD отриманому в WF "Взаємодія для тестування функціоналу"+"Видача ключа до тестового оточення". 
  12. Перевірка створеного запиту на наявність усіх документів – Менеджер по роботі з майданчиками перевіряє зазначений перелік на тестування та підтведжує видачу змінивши виконавця задачі "Взаємодія для тестування функціоналу" на QA команду (Т. Бондарчук) та задачі "Видача ключа до тестового оточення" на на DevOps команду (П. Кузьменко).
  13. Надання тестового ключа – DevOps команда виконує видачу ключів до тестового оточення до всіх напрямків , коментуючи доступ в конфігураційному файлі вручну. (Практично - Перевипуск інтеграційного)
  14. Тестування – Проводиться тестування доступу з виданими ключами.
  15. Завершення тестування:
    1. Якщо тестування успішне Команда QA закриває задачу на тестування в JIRA та інформують Менеджера по роботі з майданчиками.
      1. Команда QA надає draft висновку тестування менеджеру по роботі з майданчиками
      2. Менеджер по роботі з майданчиками дозаповнює юридичну інформацію про майданчик у висновку
      3. Начальник відділу ІТ підписує висновок про тестування або профільний член правління 
    2. Якщо тестування не успішне Команда QA не закриває задачу на тестування в JIRA але інформує Менеджера по роботі з майданчиками.
      1. Менеджер по роботі з майданчиками:
        1. Формує та надсилає майданчику висновок про непроходжкення тестування
        2. Формає наказ про не проходження тестування
      2. Бухгалтерія формує Акт виконаних робіт
  16. Закриття акта виконаних робіт – Команда по роботі з майданчиками інформує відділ бухгалтерського обліку про завершення робіт.
  17. Укладення договору про використання ЕТС – Менеджер по роботі з майданчиками укладає договір із майданчиком.
  18. Початок майданчиком WF "Отримання продуктивного ключа" – Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Отримання продуктивного ключа".
  19. Перевірка наявності всіх документів для подачі заявки на прод ключі– Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні.
  20. Подання запиту на продуктивний ключ – Майданчик подає запит на отримання ключа до продуктивного оточення через заповнення форми SD у розпочатому WF "Отримання продуктивного ключа"
  21. Перевірка створеного запиту на наявність усіх документів – Менеджер по роботі з майданчиками перевіряє зазначений перелік доступів та підтведжує видачу змінивши виконавця задачі на DevOps команду (П. Кузьменко).
  22. Надання ключів до продуктивного оточення – DevOps команда виконує видачу ключа з доступами зазначеними в задачі, коментуючи доступ в конфігураційному файлі вручну.
  23. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика приходить повідомлення про видачу ключів майданчику до продуктивного оточення .
  24. Створення заявки на відділ маркетингу – після надходження повідомлення про надання продуктивних ключей майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для додавання логотипу майданчика на портал та до каталогу та в "Перелік авторизованих електронних майданчиків всіх напрямків ЕТС “Prozorro.Продажі” ЦБД2 - оновлена".
  25. Оновлення інформації на порталі – Контент менеджер додає логотип майданчика на портал та до каталогу та в "Перелік авторизованих електронних майданчиків всіх напрямків ЕТС “Prozorro.Продажі” ЦБД2 - оновлена" і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
  26. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
  27. Оновлення статусу задачі – після виконання всіх дій і домовленостей по основній задачі, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")


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

  1. В разі якщо додатковий функціонал включає розробку нових/додаткових напрямків, тоді майданчку необхідно пройти цикл отримання Акредитації на них (Описано в частині 3 даного файлу)

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

  1. Початок майданчиком WF "Взаємодія для тестування функціоналу" – Майданчик починає WF через Slack
  2. Визначення майданчиком типу тестуввання – Майданчик обирає який тип тестування майданчику необхідний
    1. Обрано тип "Тестування нової напрямку/процедури" +вказується напрямок/процедура
      1. Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні та майданчиком пройдено новий цикл акредитації.
      2. Майданчик створює заявку посилання в SD в WF "Взаємодія для тестування функціоналу"
      3. Менеджер по роботі з майданчиками перевіряє зазначений перелік на тестування та підтведжує видачу змінивши виконавця задачі на QA команду (Т. Бондарчук)
      4. Тестування зазначеного функціоналу
      5. Команда QA закриває задачу на тестування в Jira після чого в канал майданчика приходить повідомлення про завершення тестування
      6. Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Розширення продуктивного ключа"
    2. Обрано тип "Тестування функціоналу відповівдно до задачі"
      1. Майданчик створює заявку посилання в SD в WF "Взаємодія для тестування функціоналу"
      2. Тестування зазначеного функціоналу
      3. Команда QA закриває задачу на тестування в Jira після чого в канал майданчика приходить повідомлення про завершення тестування

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

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

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

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

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


  • No labels