Система відділу внутрішніх застосунків
Команда, що розробляє внутрішні інструменти та застосунки для компанії — від запиту підрозділу до впровадження працівниками та вимірювання ефекту.
Повний цикл створення внутрішнього інструменту: запит, аналіз, розробка, тестування, запуск, а потім впровадження та вимірювання реального ефекту.
Без банківської картки — ваш проєкт буде готовий із повною системою за хвилину
Так виглядатиме дошка системи, яку ви отримаєте: колонки робочого процесу та стартові картки з першими кроками
Як рухається робота в цій системі?
Потреби підрозділів надходять карткою в «Запит», що пояснює проблему, а не готове рішення: який процес буксує, хто від нього страждає і скільки часу це коштує. Картка переходить до «Аналізу», де аналітик сидить із підрозділом-заявником, фактично розуміє процес і записує вимоги та критерії приймання на картці. Після затвердження вона переходить до «Розробки», і розробники працюють над нею етапними поставками; далі — «Тестування», де її випробовують користувачі з самого підрозділу-заявника, а їхні зауваження записуються; потім — «Запуск», коли вона готова для всіх працівників. Подорож не закінчується запуском: картка переходить до «Впровадження» для відстеження використання працівниками інструменту та їх навчання; потім — до «Вимірювання» для документування його фактичного ефекту на процес, для якого його створено.
Чат — для щоденної координації розробників та термінових запитань щодо вимог із підрозділами-заявниками. Форум документує інженерні рішення, обговорення великих вимог та післязапускові перегляди, щоб проєктувальні вибори та їхні обґрунтування лишалися зрозумілими для тих, хто приєднається до команди пізніше, і ті самі обговорення не повторювалися щоразу.
Керівник застосунків приймає запити, впорядковує їхні пріоритети та затверджує їх вхід до «Розробки»; аналітик супроводжує картку від «Аналізу» до приймання «Тестування» з підрозділом-заявником; розробники виконують та опрацьовують зауваження. Результати «Вимірювання» повертаються до керівника застосунків, щоб він вирішив: розвивати інструмент другою фазою, лишити як є чи офіційно зупинити, якщо його не використовують.
Хто за що відповідає?
Операційні ролі в цій системі та відповідальність кожної в щоденній роботі — призначте їх команді як є або адаптуйте під себе.
Керівник внутрішніх застосунків
Приймає запити підрозділів та впорядковує їхні пріоритети, затверджує перехід від «Аналізу» до «Розробки» та від «Тестування» до «Запуску».
Бізнес-аналітик
Аналізує потребу підрозділу-заявника та записує вимоги й критерії приймання на картці, а також супроводжує тестування з користувачами аж до їх приймання.
Розробники
Створюють застосунки на картках «Розробки» та опрацьовують зауваження «Тестування», а також документують інженерні рішення на Форумі в момент їх ухвалення.
Координатор впровадження та навчання
Очолює знайомство працівників з інструментом після запуску та їх навчання, а також збирає показники використання у «Впровадженні» та «Вимірюванні».
Що підготовлено для вас із першого дня?
Модулі системи
- Завдання — Канбан-дошка з колонками робочого процесу та картками виконання
- Чат — Швидкий канал щоденної координації команди
- Форум — Задокументовані обговорення в упорядкованих розділах — рішення та знання не губляться
Розділи форуму (4)
- Інженерні рішенняДокументування архітектурних виборів та затверджених інструментів у створенні внутрішніх застосунків і їхніх обґрунтувань — довідник для того, хто працюватиме з кодом пізніше.
- Вимоги та обговорення з підрозділамиПоглиблені діалоги з підрозділами-заявниками щодо великих вимог до їх перетворення на офіційний аналіз.
- Післязапускові переглядиЩо вдалося, а що зазнало труднощів у кожному запуску — задокументовані уроки для майбутніх проєктів.
- Ідеї та покращенняПропозиції нових внутрішніх інструментів чи покращень чинних від команди та з зауважень користувачів.
«Правила роботи в цій системі» — Закріплено на форумі
1. Жодної розробки до затвердженого аналізу: картка не входить у «Розробку» без письмових вимог і критеріїв приймання. 2. Заявник із підрозділу бере участь у тестуванні — жодного запуску без його приймання. 3. Інженерні рішення документуються на Форумі в момент їх ухвалення, а не після. 4. Запуск не вважається завершеним без задокументованої фази впровадження та вимірювання ефекту. 5. Інструмент, що не використовується, офіційно зупиняється задокументованим рішенням замість того, щоб лишати його сохнути.
Схожі системи
Готові? Ваш перший проєкт — за дві хвилини
Створіть безкоштовний робочий простір зараз і запросіть команду до кінця дня.