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

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

Месяц: Январь, 2021

О задаче-гамаке

Вы наверняка замечали, что в программах для рисования календарных планов есть несколько видов связей, хотя почти всегда используется End-to-Start. Да, в правильно спланированных проектах таких связей должно быть большинство.

Также должен сказать, что существует четыре вида задач:

  • Атомарная задача
  • Агрегационная задача
  • Веха
  • Гамак

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

Вот четыре задачи, связанные End-to-Start, в рамках которых проводятся некие работы:

А теперь представьте, что существует работа, которая должна проводиться всё время, пока проводятся задачи 2 и 3. Например, если в рамках этих задач проводятся работы по проведению публичного мероприятия, нам нужно дополнительной задачей обеспечить охрану и эта охрана должна работать ровно столько, сколько продолжаются мероприятия. Эту работу обязательно нужно включить в план, так как она требует трудовых ресурсов (время охранников).

Это делается так:

Задача-гамак

Задача 2 соединяется с задачей-гамаком связью Start-to-Start, задача 3 — связью End-to-End. Главное — не забудьте стереть у задачи-гамака оценку, иначе она будет отображаться неправильно.

Вот для таких случаев разработчики прожектовского софта и запасли для нас экзотические типы связей. Для скриншотов использовал Merlin Project.

О договорённостях задним числом

«Эксперт — это человек, который совершил все возможные ошибки в очень узкой специальности.»

—  Нильс Хенрик Давид Бор

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

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

Я провёл вводную встречу с заказчиком и начал проработку требований, параллельно с подготовкой дизайна, получив некое представление о том, что нужно сделать в MVP. И тут начались проблемы. Заказчицы буквально каждый день стали накидывать к MVP дополнительные функции, видимо, боясь, что Большой Босс, который всё это финансирует, обозлится, если увидит в MVP мало функций. Мои ответы, что в MVP должна быть одна-две функции, решающие ключевую пользовательскую проблему и что дополнительные функции в оговорённые сроки мы сделать просто не успеем, их не устраивали. «Мы договаривались с Мишей, что всё это будет в MVP» и точка. Никаких «оценим и сделаем в следующей итерации» и всё.

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

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

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

Теперь самое важное. Как нужно было вести себя, чтобы из этой ситуации вылезти. Ситуации, когда скоуп проекта не определён, допускать нельзя. Окажись я в таком положении сейчас, действовал бы так. В первые же дни собрал встречу с заказчицей и своим гендиром, как бы он ни был занят, и заставил проговорить, что обязательно должно быть в первой итерации, потом оценил эти работы с командой заново, потом составил документ и подписал вместе с договором.

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

Базовые приоритеты заказчика

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

Типовые вопросы на собеседовании на аналитика и ответы на них.

Собеседование на аналитика

Ранее я писал, какие вопросы задают на собеседовании на project manager-а. Вот вопросы и ответы для бизнес-аналитика.

Какой основной инструмент бизнес-аналитика?

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

Какие знаете методологии разработки?

Классический проектный подход (PMI), скрам, канбан. В принципе, этого достаточно.

Какие бывают требования?

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

Также можно рассказать про уровни требований:

  • бизнес-правила,
  • бизнес-требования,
  • пользовательские требования,
  • требования к продукту.

Также можно рассказать про типы требований:

  • ограничения,
  • требования к графическим интерфейсам,
  • требования к данным.

Какими свойствами обладают хорошие требования?

  • завершённость,
  • последовательность,
  • правильность,
  • абстрактность,
  • осуществимость,
  • измеримость,
  • необходимость,
  • прослеживаемость,
  • однозначность.

Какие существуют методы сбора требований?

  • интервью,
  • анкетирование-опрос,
  • фокус-группа,
  • семинар,
  • мозговой штурм,
  • совещание,
  • ролевая игра,
  • обсервация,
  • моделирование процессов,
  • прототипирование,
  • анализ вариантов использования,
  • анализ интерфейсов.

Как строится процесс работы с требованиями?

Требования нужно:

  • собрать,
  • задокументировать,
  • проанализировать,
  • управлять ими.
(далее…)

Тактика вопросов для интервью с заказчиком

Интервью по сбору требований

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

Заказчик — необязательно главное лицо в компании, это может быть эксперт в предметной области или кто-то из ключевых пользователей. Заранее договоритесь о том, сколько времени займёт интервью. Я бы не рекомендовал проводить встречи длиннее 45 минут, на более длинных встречах собеседники устают и теряют фокус. Также при назначении встречи прикрепите адженду. Возможно, ответы на некоторые вопросы потребуют от заказчика подготовки.

По-хорошему, кто-то из вашего руководства (как правило, это спонсор проекта) должен заранее провести с вами бриф, рассказав краткую вводную по проекту, но может быть такое, что вы отправитесь на встречу вслепую. В таком случае, нужно задать вопросы:

  • Чем занимается компания?
  • Кто будет пользоваться решением, которые мы хотим разработать?

Далее следуют три вопроса, которые дадут вам 90 % информации о проекте. Это вопросы:

  • Какую бизнес-проблему нужно решить?
  • Как эта проблема решается сейчас?
  • Что не устраивает в текущем решении?

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

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

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

Имеет смысл спросить, у кого ещё можно пособирать требования. В идеале это один представитель каждого пользовательского профиля. Например, если системой будут пользоваться менеджеры и продавцы, надо бы опросить одного менеджера и одного продавца.

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