Проблемы

Get Started. It's Free
or sign up with your email address
Проблемы by Mind Map: Проблемы

1. Ресурс (Дима Ч., Лена, Дима П.)

1.1. Нет back-лога

1.2. Нет понимания по 3ЛТП

1.2.1. Разделить команды 3ЛП и Развития

1.3. Битва за ресурсы

1.3.1. Формировать команды по принципу всех необходимых ролей и формировать их в одной локации. Состав команды - РП, Архитектор (ведущий аналитик), Аналитик, UI,, Тимлид, бэк, фронт, тестировщик.

1.4. Отсутствие ресурсов

1.4.1. При заявлении дефицита, он должен соответствовать плановым затратам, этого как раз будет хватать с учетом рисков

1.5. Развитие — по остаточному принципу

1.5.1. Планирование проходит с приоритетом 3ЛП, нужно изменить последовательность при планировании

1.6. Ресурс на оперативное решение проблем

1.6.1. Типы проблем

1.6.1.1. Инциденты 3ЛП

1.6.1.2. Проблемы со средой разработки

1.6.1.3. Срочные хотелки заказчика вне плана

1.6.1.3.1. Менять с текущими задачами а не дополнять скоуп

1.6.2. Как выделять ресурс

1.6.2.1. Выделенная команда devs+test c ротацией раз в 1-2 месяца

1.6.2.2. По 1 "дежурному" на неделю от каждой команды

1.7. Отсутствие архитекторов

1.7.1. Ввести роль младшего Архитектора

1.7.2. Добавить должностей ведущего Аналитика, который будет выполнять Архитектора по функциональной части

2. Процесс (Таня, Ника, Игорь)

2.1. Отсутствие описанных процессов

2.2. Необоснованные приоритеты

2.3. Ролевые игры

2.4. Нет единой точки входа

2.4.1. Точка входа в рамках Change Management

2.4.2. Точка входа для Заказчика по Проекту

2.5. Документирование

2.6. Отсутствие "вычесывание" BackLog'a

3. Команда (Кристина, Дима А., Никита)

3.1. Слабые компетенции + UXUI знают больше, чем аналитики

3.1.1. Составить список компетенций. Раз в неделю выбирать компетенцию или тему одной из компетенций и проводить часовое обучение всех желающих.

3.1.2. Описать детальные требования к работе аналитика (глубина погружения, схемы, взаимодействие с разработчиками).

3.1.3. Определить круг лиц, обязательных для участия в собеседованиях.

3.1.4. Больше ответственности за качество и сроки (сейчас над всеми аналитиками 1 человек, без которого часть аналитиков не могут назвать сроки или самостоятельно оценить качество своей работы перед отправкой заказчику).

3.1.5. Разработать вопросы к ежеквартальным тестам для аналитиков, РП и UXUI. Вопросы держать в строгом секрете. Открыто предоставлять информацию, где можно найти обучающие материалы. Результаты тестирования влияют на премию. Вгрузить в Олю Бобылеву, Смирнова.

3.1.6. Создать систематизированную единую базу знаний по ЕПГУ и смежным системам. На данный момент носителями конкретных знаний по тем или иным частям являются конкретные люди и знания передаются из уст в уста

3.2. Нет процессов работы команд

3.2.1. Создать рабочую группу (все РП команд, Смирнов, Меркулова, представитель UXUI и представитель аналитики) и 2-3 встречи прийти к консенсусу и описать процесс. Очная явка на встречи обязательна.

3.3. Тикеты без описания по 3ЛТП

3.3.1. Не брать тикеты в работу, если не понятно описание и не тратить время на еженедельном планировании на выяснение постановки

3.3.2. Сформулировать и описать в Confluence правила (шаблон) постановки задачи. Тикеты без описания не беруться в работу и должны вовращаться на постановщику.

3.4. Регламент встреч

3.4.1. Всегда отвечать на приглашение статусом (Принять, Отклонить, Возможно).

3.4.2. Планировать встречи заранее (минимум за день) при этом смотреть загруженность приглашённых. Транслировать через корп коммуникации на всех сотрудников компании

3.4.3. Заранее оповещать инициатора встречи о невозможности присутствовать. Уважайте себя и других.

3.4.4. Заранее оповещать инициатора встречи о невозможности присутствовать. Уважайте себя и других.

3.4.5. Встречи с заказчиком планировать исходя из календаря. Не игнорировать внутренние встречи. Понятно, что всегда есть исключения. Нужно обосновывать, почему вы не смогли запланировать встречу с заказчиком чуть позже внутренней встречи, которая была заблаговременно запланирована и принята вами.

3.4.6. Обязательно протоколирование каждой встречи в Confluence

3.4.7. Всегда писать повестку встречи

3.5. KPI правила

4. Сроки (Илья, Егор)

4.1. Без SLA — срыв сроков

4.2. Не выдерживаются сроки релизации

4.3. Нет контракта

4.4. Уведомление сотрудника о просроченных задачах почтой

5. Планирование проекта (Костя, Егор)

5.1. Нет ответственного за результат

5.1.1. Жесткое закрепление разработчиков за определенным фронтом работ

5.1.2. Сейчас ответственный за результат - РП. Но не всегда проблема срыва сроков в некорректном планировании. Если оставлять только инструмент эскалаций, то ничего хорошего из этого не получится. Нужно иметь рычаги управления внутри команды

5.1.3. Нужно создать классификатор причин срыва сроков. По большинству причин есть конкретный ответственный. Как наказывать конкретного ответственного решать должен РП и тимлид

5.1.3.1. Некорректное планирование - ответственный РП,РК

5.1.3.2. Превышение первоначальной оценки разработчиком - ответственный разработчик

5.1.3.3. Слишком много затраченного времени на багфиксинг ответственный разработчик

5.1.3.4. Ошибки при выводе функционала на среду

5.1.3.5. Отсутствие описания требований к реализации (или неполное. некорректное) - ответственный аналитик

5.1.3.6. Legacy код

5.1.3.7. Ошибки настроек DEV & UAT серверов

5.1.3.8. Человеческий фактор (выбывание сотрудника на время\насовсем

5.1.3.9. Внеплановые задачи в итерации

5.2. Сквозной план-график

5.2.1. Решить эту проблему кроме как ведением общего плана проектов не получится. НО это огромные трудозатраты + все просят всегда планы в excel

5.2.2. Планы по конкретному направлению все равно нужны. В комплексном плане сложно показать декомпозицию задач по тестированию и разработке. Рассмотреть возможность интеграции jira и ms project

5.2.3. Рассылка вех-проекта а также связанных задач с другими проектами на всех РП и руководителей еженедельно

5.3. Отсутствие планов у начальников отделов

5.3.1. В случае с project server данная проблема становится неактуальной

5.3.2. Если что-то другое, то передача планов в руководителей отделов проходит каждые 2 недели по мере актуализации плана

5.4. Нет тикетов в работе

6. Формальный трек (Лена, Игорь)

6.1. Документирование

6.2. Протоколирование