Система отдела внутренних приложений
Команда, разрабатывающая внутренние инструменты и приложения для компании — от запроса отдела до принятия сотрудниками и замера эффекта.
Полный цикл создания внутреннего инструмента: запрос, анализ, разработка, тестирование и запуск, затем принятие и замер реального эффекта.
Без банковской карты — ваш проект будет готов с полной системой за минуту
Так выглядит доска системы, которую вы получите: колонки рабочего процесса и стартовые карточки с первыми шагами
Как устроена работа в этой системе?
Потребности отделов поступают карточкой в «Запрос», объясняющей проблему, а не готовое решение: какой процесс буксует, кто от него страдает и сколько времени он стоит. Карточка переходит в «Анализ», где аналитик садится с отделом-заказчиком, фактически понимает процесс и записывает требования и критерии приёмки на карточке. После утверждения — в «Разработку», где разработчики работают над ней поэтапными поставками, затем в «Тестирование», где её испытывают пользователи из самого отдела-заказчика и их замечания фиксируются, далее в «Запуск» при готовности для всех сотрудников. Путь не кончается запуском: карточка переходит в «Принятие» для отслеживания использования сотрудниками и их обучения, затем в «Замер» для документирования фактического эффекта на процесс, ради которого она строилась.
Чат — для ежедневной координации разработчиков и срочных вопросов по требованиям с отделами-заказчиками. Форум документирует инженерные решения, обсуждения крупных требований и пострелизные ревизии — чтобы проектные выборы и их обоснования оставались понятными присоединившимся к команде позже и одни и те же обсуждения не повторялись.
Директор по приложениям принимает запросы, ранжирует их приоритеты и утверждает вход в «Разработку»; аналитик сопровождает карточку от «Анализа» до принятия «Тестирования» с отделом-заказчиком; разработчики исполняют и обрабатывают замечания. Результаты «Замера» возвращаются директору по приложениям для решения: развивать инструмент второй фазой, оставить как есть или официально остановить, если им не пользуются.
Кто за что отвечает?
Операционные роли в этой системе и зона ответственности каждой в ежедневной работе — назначьте их команде как есть или адаптируйте под себя.
Директор по внутренним приложениям
Принимает запросы отделов и ранжирует их приоритеты, утверждает переход из «Анализа» в «Разработку» и из «Тестирования» в «Запуск».
Бизнес-аналитик
Анализирует потребность отдела-заказчика и записывает требования и критерии приёмки на карточке, сопровождает тестирование с пользователями до их принятия.
Разработчики
Строят приложения на карточках «Разработки» и обрабатывают замечания «Тестирования», документируют инженерные решения на форуме в момент их принятия.
Координатор принятия и обучения
Ведёт знакомство сотрудников с инструментом после запуска и их обучение, собирает показатели использования в «Принятии» и «Замере».
Что подготовлено для вас с первого дня?
Модули системы
- Задачи — Канбан-доска с колонками рабочего процесса и карточками исполнения
- Чат — Быстрый канал ежедневной координации команды
- Форум — Задокументированные обсуждения в упорядоченных разделах — решения и знания не теряются
Разделы форума (4)
- Инженерные решенияФиксация выборов архитектуры и утверждённых инструментов построения внутренних приложений с их обоснованиями — ориентир для того, кто будет работать с кодом позже.
- Требования и обсуждения отделовОбстоятельные диалоги с отделами-заказчиками о крупных требованиях до их превращения в официальный анализ.
- Пострелизные ревизииЧто удалось и что споткнулось в каждом запуске — задокументированные уроки для будущих проектов.
- Идеи и улучшенияПредложения новых внутренних инструментов или улучшений действующих — от команды и из замечаний пользователей.
«Правила работы в этой системе» — Закреплено на форуме
1. Никакой разработки до утверждённого анализа: карточка не входит в «Разработку» без письменных требований и критериев приёмки. 2. Заказчик из отдела участвует в тестировании — никакого запуска без его принятия. 3. Инженерные решения фиксируются на форуме в момент их принятия, а не после. 4. Запуск не считается завершённым без задокументированных фазы принятия и замера эффекта. 5. Инструмент, которым не пользуются, официально останавливается задокументированным решением вместо того, чтобы чахнуть.
Похожие системы
Готовы? До вашего первого проекта — две минуты
Создайте бесплатное рабочее пространство сейчас и пригласите команду до конца дня.