Во-первых извините, очень долго не появлялся, занимался сдачей экзамена PMP, что и выполнил успешно.
Теперь же перейдем от лирики к практике.
После того как вы утвердили задачи, определили сроки, составить беклог и итерацию особых проблем не представит. Проблемы начнутся тогда, когда вам придется начать управлять изменениями.
Изменения это неотъемлемая часть любого процесса, а разработки тем более. Не надо бояться и шарахаться от изменений, изменения это всегда хорошо, значит проект жив, развивается и уточняет требования к результатам своей работы. Важно, научиться управлять изменениями а не избегать изменения.
1 — Ищем изменения
Да, вы не ослышались. Изменения нужно искать, искать активно, во время работы. Причина этого банальна, Заказчику лень работать с вами в операционном порядке, но Заказчику будет абсолютно не лень «жевать» вам моск на момент сдачи работы и подписания Актов приема передачи. Поэтому, ваша главная задача, как менеджера, это проактивно искать изменения.
Что же входит в это понятие?
1.1 — Определяйте области и задачи, которые наиболее интенсивно вовлекают заказчика. План коммуникаций.
Чтобы вам никто не говорил из возможных гуру или не гуру ИТ, в конечном итоге всегда прав заказчик. Именно он платит вам деньги, создает вам репутацию и участвует в вашем развитии более, чем кто-бы то не было еще. Поэтому вам важно понимать кто у вас заказчик. Если ваш заказчик человек с поверхностными знаниями, то когда вы составите список «задач важных для заказчика» туда попадет что-то вроде:
- Интерфейс, формы, форматно-логический контроль
- Общий дизайн
- Процесс работы
- Сопроводительная документация
- Этапы развития проекта, сроки сдачи проекта в пилотную, опытную эксплуатацию
- Обучение
- Объяснение принципов работы, почему, то как мы делаем продукт, это на данный момент лучший подход
- Высоко-уровневая схема продукта
- Список решаемых бизнес задач
Думаю вам в целом понятно? Вы заранее, до того, как на вас посыплется вал вопросов и замечаний определяете, что вы должно коммуницировать Заказчику.
Далее вы должны определить Кому в компании Заказчика это нужно, с какой периодичностью и в какой форме. Все это вы можете назвать умным термином «План коммуникаций» и утвердить его с Заказчиком. Сделайте это. Сделайте это заранее. И тогда отношение к вам заказчика будет совсем другим, нежели к еще одной ИТ компании. Расскажите Заказчику правила игры, до того как он их нарушит.
Форм отчетов может много разных, для одних сотрудников Заказчика, других. Важно, чтобы вы понимали, это нужно, это обязательно нужно, без этого проект существовать не может, иначе это будет очередной долгострой. И не важно Заказчик внутренний или внешний.
Желательно использовать какой либо онлайн инструмент типа Confluence от Атлассиана с функцией мыльных уведомлений, но тогда вы обязаны Заказчика этой системе обучить.
1.2 — Определяйте области и задачи, которые должен отрабатывать тимлид.
Все верно, внутренние изменения должны утверждаться Тимлидом, и в зависимости от их важности вами. В любом проекте, любой сложности, всегда должен быть один ответственный человек за изменения. Если он не утвердил какое либо изменение, срока, денег, объема работ, то тот, кто выполнил это изменение, если оно полезно, должен просто отработать потраченное на него время во внерабочее время, если не полезное, должен его откатить и восполнить потерянное время.
1.3 — Встречи.
На встречах не обсуждайте статус работы. Не надо. Не обсуждайте. Не тратьте свое и время команды. Не будьте занудой. Собрать статус проекта, если вы его правильно спланировали вам поможет Жира и иже с ней. Не надо собирать встречи для встречи. Когда вы собрали встречу, планерка ли, собрание, определяйте о чем вы будет говорить. Самая лучшая тема для встреча? Где у нас риски в проекте, и что мы можем чтобы их не было или они были меньше. На общих встречах обсуждать статус проекта это просто глупо.
Именно на встречах вы поймете где в вашем проекте, у вас есть области, которые требуют особого внимания. И там вы можете найти те изменения, что должны быть отработаны.
2 — Управляем изменениями
Создайте План изменений. Опишите там, кто, как, когда, через какие инструменты, запрашивает, утверждает и внедряет изменения. Назначайте ответственного за любое изменение проекта. Все в целом, календарный план, требования, приложения к договору и тд и тп называется Конфигурацией проекта. Считайте Конфигурации вашей библиотекой управляющих документов.
Матрица ответственности
Создайте такой план который также скажет, кто, когда, через какие инструменты должен быть уведомлен о каких изменениях и ждать ли от него ответа. Есть такой прекрасный английский инструмент, который определяет кем, является человек, в любом процессе, задачи. Роли человека, вовлеченного в задачу делятся следующим способом:
1) R — Report to — кому отчитываться (в прямом смысле слова) по задаче, проекту и тд.
2) A — Accountable — кто ответственен
3) С — Condult to — с кем можно консультироваться
4) I — Inform — кого просто информировать.
По английски данная методика называется RACI, по русски можно назвать ее «Доки проекта», от русского слова «Дока», как бы специалист во всем:
1) Держать в курсе кого
2) Ответственный кто
3) Консультироваться с кем
4) Информировать кого
Затем вы строите что-то типа матрицы:
Изменения в сроки задачи по верстке
| Сотрудник | Д | О | К | И |
|---|---|---|---|---|
| Пронин Павел | Х | Х | Х | |
| Схронов Андронт | Х |
При этом помним, ответственный всегда один. На сегодня, я пока закончу, продолжение в дальнейших статьях.
Предыдущие статьи:
Жизнь управленца, кадр 1, не надейтесь на понимание
Жизнь управленца, кадр 2, жесткая воля
Жизнь управленца, кадр 3, коммуникации
Жизнь управленца, кадр 4, Планирование — Постановка задачи
Жизнь управленца, кадр 4-1, Планирование — Разбор задач
Автор: undry
