Владимир Бычко об управлении проектами

запихиваем проекты в треугольники

Месяц: Август, 2014

Конспектирование при помощи ментальной карты

Конспект занятия клуба agile практиков

Ещё не раз и не два я напишу о ментальных картах. Это универсальный инструмент.

Конспектируем лекцию/совещание/что угодно при помощи ментальной карты.

Плюсы:
Читать потом в сто раз проще, чем линейный конспект.

Минусы:
Показывать это другим малополезно, если только карта не чертилась совместно.
В бумажном виде это выглядит страшновато, нужно тратить время на перенос в майндменеджер.

==============
В качестве примера приведён конспект занятия клуба Agile-практиков. Тема, как видите — заказная разработка по скраму.

  1. Лучше всего использовать большой лист. А4 недостаточно — посмотрите, как приходится мельчить.
  2. Обязательно нужно рисовать картинки — они вызывают нужные образы быстрее, чем текстовые надписи.
  3. Очень важно рисовать разными цветами, эта схема в ч/б, потому что не было под рукой цветных ручек.

Большие доработки

Большая работа — большие риски

— Как съесть слона, используя только нож и вилку?
— По кусочку.

Проведение больших доработок качественно отличается от мелких. Заказчик хочет здоровенный и очень сложный кусок функционала (будем называть его продуктом). Как не облажаться?

Если собрать требования ко всему продукту, сформулировать техзадание, потратить массу времени на реализацию, при сдаче выяснится, что заказчик хотел совершенно не это и нужно потратить ещё столько же времени на переделку. Разработчик и аналитик теряют впустую много времени, очевидный риск.

Если собрать требования ко всему продукту, сформулировать техзадание, разбить функционал на законченные куски, относительно быстро сделать и сдать первый, при сдаче выяснится, что требования к остальным кускам продукта существенно меняются. Это нормально — заказчик, увидев фрагмент продукта сразу начинает воспринимать его совсем иначе по сравнению с тем, что ранее было у него лишь в голове. Аналитик потратил впустую много времени, очевидный риск.
 
 
Избежать этих ключевых ошибок возможно, если использовать при написании требований вариацию на тему «метода прогрессивного джипега».

Давайте разберём контрольный пример.

Бизнес-проблема: «Для того, чтобы более эффективно продвигать и продавать наш товар (одуванчиковый лимонад), мы хотим онлайн-каталог».

Результат предварительного сбора требований:

На сайте должны быть разделы:

  1. Главная страница
  2. О компании
  3. Каталог
  4. Оплата и доставка
  5. Контакты

Ключевой момент — заказчику не понадобится оформление заказа с сайта. Только онлайн-каталог и форма отправки заявки.
 
 
Хорошо. Составляем крупноуровневый план работ:

  1. Разработать и согласовать концепт дизайна контентных страниц.
  2. Изготовить Главную страницу.
  3. Изготовить Каталог.
  4. Изготовить прочие контентные страницы.

 
 
В ходе первой итерации мы будем делать концепт дизайна, а затем — Главную страницу.

Ключевой момент — на первом этапе детализируем только требования к дизайну и главной странице. Остальные пункты плана для нас как бы в тумане. Мы знаем их состав и очень примерно — какими они должны быть. Пока не нужно об этом думать — после того, как сдадим Главную страницу, желания заказчика могут смениться на диаметрально противоположные.

Итак, на первом этапе готовим для согласования документ, содержащий:

  1. Детализированные требования к дизайну: корпоративные цвета, количество колонок, общий вид вёрстки блоков, шрифты, стиль иллюстраций.
  2. Детализированные требования к главной странице (обязательно с wireframes), состав блоков, назначение каждого блока, порядок следования и проч.

 
 
Для остальных кусков функционала пишем требования на уровне возможностей: «Каталог позволяет просматривать карточки товаров с возможностью фильтрации, карточки содержат описания товаров и форму обратной связи». Такой детализации пока вполне достаточно.

Есть ли риски в данном случае? Увы, есть. После сдачи первой итерации требования могут измениться настолько принципиально, что результат первой итерации придётся переделать полностью. К сожалению, с этим можно бороться только уменьшением количества требований на итерацию до минимально возможного. Правда, в этом случае возрастают расходы на тестирование (короче итерации — больше регрессионных тестов в единицу времени).

Предположим, первая итерация прошла удачно. Дизайн понравился, главная страница свёрстана грамотно, замечаний немного или нет вовсе. Наши дальнейшие действия — в первую очередь, актуализация плана. Не устарели ли требования? Если всё нормально, переходим к детализации требований на вторую итерацию, иначе корректируем, пересогласовываем, переоцениваем.
 
 
Резюме:

  1. Разбиваем функционал на блоки.
  2. Составляем общий план.
  3. Детализируем требования только к тому блоку, который пойдёт в работу в ближайшую итерацию, остальные блоки описываем на уровне возможностей.

 
 
Такой подход делает разработку предсказуемой и минимизирует риски.

О картах контрольных проверок

Всё под контролем

Самолёт — слишком сложный аппарат, чтобы подготовить его к полёту по памяти. Некачественная проверка любого узла может привести к катастрофе с гибелью нескольких сотен человек, потере пилотов и самого самолёта. Для исключения подобных ситуаций авиаторы взяли на вооружение карты контрольных проверок.

В США продолжительное время один пациент из пяти тысяч прооперированных умирал из-за ошибки анестезиолога. Внедрение карт контрольных проверок в сочетании со стандартизацией интерфейса оборудования и сглаживанием градиента авторитета (объяснение медсёстрам, что доктор не всемогущ и если они видят ошибку, они обязаны о ней сообщить) привело к снижению смертности до одного пациента на 200-300 тысяч прооперированных (снижение смертности в сорок раз).

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

Автор работает в организации, в которой менеджер продукта выполняет не столько функции специалиста по развитию, сколько именно организационную работу и обеспечивает качество всего итеративного процесса. Выяснилось, что без карты контрольных проверок слишком легко упустить одно из мероприятий и навредить срокам выпуска версии → разозлить заказчиков, ожидающих выпуск функционала к определённой дате.

Был разработан и внедрён протокол планирования итераций, содержащий перечень мероприятий, даты, отметки о выполнении, а также фамилии сотрудников, ответственных за каждый этап. В качестве инструмента был выбран OneNote. К сожалению, протоколы проведённых итераций содержат конфиденциальную информацию, поэтому приведённый пример будет гипотетическим.

Карта контрольных проверок

Таким образом, процесс состоит из:

  1. планирования работ
  2. написания требований к доработкам
  3. демо требований
  4. старта разработки
  5. кодфриза разработки
  6. регрессионного тестирования
  7. съёмки ролика о новом функционале
  8. передачи билда на поддержку.

 
 
Каждый из этапов состоит из группы действий, которые нужно не забыть провести. Некоторые действия (такие, как «Бэклог оформлен в TFS») являются сложными и сами состоят из групп действий, описанных в протоколах нижнего уровня.

Ответственный в данном случае — сотрудник, имеющий полномочия о принятии решения об успешном прохождении этапа. Как видно из примера, за все действия до кодфриза отвечает менеджер продукта Бычко, за выход на кодфриз — тимлид Ригельман, организацию и проведение регрессионного тестирования — глава QA Бунг и, наконец, за съёмки ролика и передачу на поддержку — глава управления продуктом Гольдштейн.

Ниже данной таблицы в протоколе располагается детализированная информация о проведении каждого из этапов. Расшаривание через OneDrive и соответствующие права доступа позволяют ответственным лицам «расписаться» о проведении этапа.

Благодаря внедрению данного протокола практически исключается пропуск любого из шагов, кроме того, все лица, желающие наблюдать за ходом итерации (CIO, глава проектного офиса, глава управления продуктом), могут это сделать, взглянув на протокол через интерфейс веб версии OneNote (или подключив блокнот в десктопной версии приложения).

Несколько старых вещей

Сегодня не очень хочется писать, поэтому будет фотопост. Я приехал на несколько дней на историческую родину, в город Мамоново и сфотографировал несколько старых вещей.

О потоках

Я ушёл в поток.

Люди, ставшие менеджерами, сталкиваются с проблемой — если возникает ситуация, когда нужно лично сделать что-нибудь «руками» (написать требования, сделать презентацию), это оказывается практически невозможным — постоянно отвлекают.

К сожалению, единственное решение в данном случае — «красный флажок» и уход в автономное плаванье на несколько часов, иначе поток не создашь. Секрет в том, что не нужно стесняться использовать эту возможность.

У разных организаций разная специфика, однако опыт показывает, что есть лишь одна причина срочно отрывать менеджера — неожиданно всплывший у клиента грозный дефект ПО, который мешает ему работать. Всё остальное может потерпеть несколько часов.

По теме. Интересный пост Людвига Быстроновского о том, как всё успевать.

Матрица компетенций

В ходе практики мне приходилось сталкиваться с ситуациями, когда в какой-то из частей предметной области хорошо разбирается только один специалист, который ушёл в отпуск или вообще, уволился. Если заранее не предусмотреть такую ситуацию, будут простои.

Для небольшого отдела это не является проблемой, но если речь о целом департаменте разработки со множеством команд, легко что-либо упустить.

Решением является составление и поддержание в актуальном состоянии матрицы компетенций.

Шаг № 1

Выделить критичные части предметной области.

Шаг № 2

Выявить уровень навыков сотрудников.

Шаг № 3

Обработать риски.

В первую очередь нужно понять, какие именно компетенции критичны для процесса разработки.

Для контрольного примера возьмём семь компетенций:

  1. Отчёты RS
  2. Отчёты на базе сводных таблиц
  3. Обмен данными
  4. C Sharp
  5. Веб сервисы
  6. Оптимизация
  7. Архитектура

В строчной части матрицы будут фамилии разработчиков, в столбцах — компетенции, а на пересечении — уровень владения, где:

  • нуль — не владеет.
  • единица — обучается.
  • двойка — владеет на приемлемом уровне
  • тройка — владеет на высоком уровне, способен преподавать

 

Отчёты RS

Отчёты сводные

Обмен данными

C Sharp

Веб сервисы

Оптимизация

Архитектура

Митчелл

2

2

1

0

0

1

0

Хойт

1

1

0

2

1

2

0

Абу Бакр

3

3

2

1

0

3

1

Примус

0

0

0

3

0

2

1

Батье

2

2

3

0

1

1

3

ИТОГ

8

8

6

6

2

9

5

 

Из таблицы можно сделать следующие выводы:

  1. У нас нет никаких проблем с реализацией отчётов.
  2. С обменом данными также всё в порядке. Господина Батье вполне может подменять мистер Бакр.
  3. Относительно C Sharp также нет проблем, функции дублированы.
  4. Мы толком не можем делать веб-сервисы, есть лишь два ученика. По всей видимости, специалист был, но он уволился, а предыдущий менеджер матриц компетенций строить не умел.
  5. С оптимизацией всё в полном порядке.
  6. Полноценным архитектором является только господин Батье, есть два ученика, но подменить его они не могут.

 

Управленческие решения:

  1. Направить Батье и Хойта на обучение разработке веб-сервисов.
  2. Попросить Батье поднять навки Примуса и Бакра в архитектуре.
  3. Особенно чутко наблюдать замотивированность господина Батье.

После этого останется лишь держать матрицу компетенций в актуальном состоянии и простоев из-за отсутствия ключевого сотрудника больше не будет.

О рекрутинге

При найме человека на позицию исполнителя, следует отталкиваться от трёх ключевых параметров:

[ultimate_heading main_heading=»Подход» alignment=»center» spacer=»no_spacer» spacer_position=»top» spacer_img_width=»48″ line_style=»solid» line_height=»1″ line_color=»#333333″ icon_type=»selector» icon_size=»32″ icon_style=»none» icon_color_border=»#333333″ icon_border_size=»1″ icon_border_radius=»500″ icon_border_spacing=»50″ img_width=»48″ line_icon_fixer=»10″ main_heading_margin=»margin-bottom:10px;»]

Предопределяет результат.

[ultimate_heading main_heading=»Знания» alignment=»center» spacer=»no_spacer» spacer_position=»top» spacer_img_width=»48″ line_style=»solid» line_height=»1″ line_color=»#333333″ icon_type=»selector» icon_size=»32″ icon_style=»none» icon_color_border=»#333333″ icon_border_size=»1″ icon_border_radius=»500″ icon_border_spacing=»50″ img_width=»48″ line_icon_fixer=»10″ main_heading_margin=»margin-bottom:10px;»]

Ускоряют производство.

[ultimate_heading main_heading=»Опыт» alignment=»center» spacer=»no_spacer» spacer_position=»top» spacer_img_width=»48″ line_style=»solid» line_height=»1″ line_color=»#333333″ icon_type=»selector» icon_size=»32″ icon_style=»none» icon_color_border=»#333333″ icon_border_size=»1″ icon_border_radius=»500″ icon_border_spacing=»50″ img_width=»48″ line_icon_fixer=»10″ main_heading_margin=»margin-bottom:10px;»]

Минимизирует ошибки.

Именно в таком порядке.

Подход определяет всё. Фактические знания уменьшают время исполнения задачи. Опыт позволяет избежать ошибок.

Допустимо сравнивать кандидатов по первым двум параметрам.

Кандидат № 1

  • Внимателен к деталям.
  • Ответственен.
  • Умеет общаться и сглаживать конфликты.
  • Не хватает конкретных знаний (к примеру, ранее работал в «соседней» предметной области).

Кандидат № 2

  • Конфликтен.
  • Склонен к срыву сроков.
  • Игнорирует отдельные поручения.
  • Высокое самомнение.
  • Отличные знания предметной области и продукта.

В данном контексте корректный выбор — первый кандидат. Конкретные знания замечательно приобретаются в ходе практики (есть мнение, что единственный способ вырасти — браться за задания, для исполнения которых не хватает знаний), выправить же подход почти невозможно.

Если же подход у обоих кандидатов хорош, а уровень знаний примерно одинаков, следует обратить внимание на опыт. Человек с бóльшим опытом будет совершать меньше ошибок.

Внимание! Данный метод применим лишь к исполнителям. К руководителям предъявляются другие требования, об этом поговорим в будущих постах.

Трест, который лопнул

Trust_by_artiswolf

Между полисменом и трестом нет ничего общего. То, что я сказал, — это эпиграмма… ось… или, так сказать, квинтэссенция… А значит она, что трест и похож и не похож на яйцо. Когда хочешь раскокать яйцо, бьешь его снаружи.

Слушать

О гибких методологиях

be flexible

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

Когда вышли все возможные сроки, она солгала, что находится в больнице, так как попала в ДТП, все альбомы готовы, но она пока физически недоступна. Режиссёр попросил свою знакомую связаться с этой художницей и попытаться сделать заказ. Волшебным образом художница оказалась доступна, здорова и готова к сотрудничеству.

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

Я бы организовал работы так.

Входные условия:

  1. Большое задание — нарисовать шесть альбомов рисунков.
  2. Ограниченный бюджет, не позволяющий обратиться к более ответственному художнику.
  3. Ограниченные сроки — в эти шесть альбомов упирается важный этап съёмок фильма.

 
 
Риски:

  1. Художник имеет особенность периодически проваливать сроки.
  2. Провал данной задачи означает провал важного этапа съёмок фильма.

 
 
Основной план:

  1. Разбил задание на шесть небольших задач — нарисовать первый альбом, второй, третий, так дальше.
  2. Для удобства визуализировал задачу в виде доски trello или экселевского роадмапа.
  3. Поручил художнику исполнить первый альбом. Срок неделя, риски минимальные.
  4. Предложил инструмент, позволяющий оценить качество исполнения без необходимости встречаться лично. Например — Яндекс Диск. Нет ничего сложного в том, чтобы отсканировать рисунок и выложить в облако.
  5. Установил срок для каждого рисунка с контрольной точкой — просрочка на x дней означает автоматическое прекращение сотрудничества.
  6. Установил правило: художник нарисовал рисунок — немедленно выложил в Яндекс Диск.
  7. Никакой предоплаты. Художник заканчивает первый альбом — встречаемся лично, художник передаёт бумажную версию альбома, получает деньги.
  8. Установил дедлайн для сдачи первого альбома (вторая контрольная точка).
  9. После сдачи первого альбома поручил реализацию второго альбома по тем же правилам.

Можно добавить дополнительные мотивирующие фишки. Например, за пять альбомов художник получает лишь 40 % от полной суммы, а за шестой — оставшиеся 60 %.

Вот такой роадмап может получиться:

 
 
Резервный план:

  1. Нашёл второго художника, пусть и более дорогого и достиг с ним предварительной договорённости.
  2. Если первый художник нарушает правила на любом этапе (автоматически теряя время и гонорар), заказ переходит ко второму.
  3. Заложил риск в бюджет. Либо изыскал дополнительные средства (это лучше, чем полностью провалить съёмки фильма), либо «пофлексил» задачу — реализовать не шесть, а, предположим, четыре альбома за исходную сумму.

 
 
Таким образом, мы имеем гибкий план, сводящий риски к минимуму. Самой большой ошибкой было дать сразу большой заказ, не установив контрольных точек.

Искренне жаль, что люди искусства пренебрегают методами, давно апробированными профессиональными менеджерами.

О жёлтом человечке.

under_construction

В интернете конца девяностых и начале двухтысячных большая часть сайтов вместо контента содержала человечка с лопатой на жёлтом фоне.

В 2014 году единственно верный подход таков:

Если на сайте незаполнен раздел — не нужно отображать ссылку на него. Если для карточки товара нет фотографии — не нужно её отображать, переместите карточку в черновики. Если поиск не работает — не нужно отображать строку поиска.

Потому что отсутствие услуги — меньшее зло, по сравнению с некачественно оказываемой услугой.