×Закрыть

Риски на маленьких проектах

Всем привет.

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

Зачем я сюда пишу? Меня интересует с какими рисками вы работали на маленьких проектах. Любые советы и истории касательно рисков. Если вы вводили работу с рисками у себя на фирме, поделитесь опытом как это было.

П.С. Искать подобную тему пробовал. В основном темы 2-3 летней давности, а с тех пор многое изменилось. Думаю данная тема сможет помочь многим начинающим PMам.

Всем спасибо за внимание.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В дополнение к первым двум предложениям от Артем Дукельский я бы еще добавил то что очень многое будет зависеть от методологии разработки будущего проекта и типа договора который будет использоваться под проект.

Я бы выделил следующие риски:
• Бизнес риски. Изменения в конкуренции, изменения спроса товаров и услуг, изменения форм собственности (слияние, поглощение, банкротство). Последние риски оценить конечно сложно, тем более в маленьких проектах это редкость но на практике такое тоже бывало. Самое сложное это разгребать потом бумажную волокиту с документами.

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

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

• Юридические риски. Любые потенциально правовые вопросы, например, нарушение патентных прав, вопросы лицензирования, передачи исходного кода и вспомогательных элементов проекта. Такие моменты чаще всего обсуждаются перед заключением договора а затем выносятся уже в сам договор. Буквально одно слово или предложение не будет правильно воспринято сторонами и даже на мелких проектах будут проблемы. Но в 98% случаев все проходит нормально.

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

В больших компаниях помимо того что стараются максимально прописать риски в договор еще могут вести реестр рисков (иксель документ) в котором обозначают все начальные риски даже если проект будут разрабатывать по agile. В компаниях которые делают мелкие проекты на аутсорс редко стараются таким заморачиваться, так как проектов много и времени для составления такого документа просто нет. Но в любом случае минимально все прописывается в договор.

Один из реальных рисков иметь на проекте ПМ-а который не знает за риски на проектах за работу с рисками в т.ч. понимает их и что-либо вообще как:

а с тех пор многое изменилось

ЗЫ: и таки да это реальный ответ на вопрос ничего трольного чисто бизнес.
ЗЫ: а ну ОК как управлять строится «многоуровневая система двойных бухгалтерий» в которой уровни рисков показываются соотв. уровню «стейкхолдера» в данном контексте конечной ЦА конкретного уровня репортинга рисков равно как и в риски же ж но уже соотв. «двойной бухгалтерии» для этого уровня падает риск «реального уровня понимания данным стейкхолдером» этот риск приходится учитывать и готовиться к его реализации последнее зависит от критичности мнения конкретного «стейкхолдера» с одной стороны и конкретных взаимосвязей на конкретном проекте с другой.
ЗЫ: вторичное следствие «многоуровневости» разрастание менеджерского scope что суть есть отдельный риск всё вместе смело отражается как в коэффициентах на эстимейты так и тщательно записывается по мере необходимости эти эстимейты с этими коэффициентами подтвердить «смотрите тут у нас риск проявлялся он вот так и вот так стоил нам +ххх доп. ресурсов мы учли его вот так и вот так с вероятности +ууу которую ожидаем не выше +ййй при условии выполнения вот таких вот условий» (к) (тм) суть есть это и есть «работа с рисками».
ЗЫ: и таки да реальный отдельный риск и реальная пичать пичаль пичаль когда ПМ такую работу выполнять не может по той или иной причине каждая из которых по-своему отдельный риск.

че это за домыслы ? строится реестр рисков, есть много готовых опросников и шаболонов. потом приорити расставляется и считается польза от вкладываняи денег/ресурсов на риск митигейшн. для мелких рисков никто ничего не делает, для очень крупных (катастрофы) — тоже ничего не делают, это включается в форсмажоры контрактов. для тех рисков которыми можна упралять — они отслеживаются и добаляются новые в каждой стадии проекта. Чаще всего работы выгдялит так — вот тут было СМЕ захалайчено что старая версия софта не будет корретно работать с https, был риск по изменению скопа, по этому поводу заказчику было отправленно письмо и на митинге упоминалось. заказчик подтвердил что https их не интересует. Все риск закрыт. Вот тут был риск что сервер не предет вовремя с таможни, для митигейшн риска фаза деплоймента включает +10% времени, плюс еженедельный митинг с таможенниками. заказчик проинформирован. риск мониторися или уже закрыт. ну и т.д.

А ну ок. (к) (тм)

Для начала нужно определиться, какие проекты вы считаете маленькими?
Это могут быть однотипные лендинги или веб сайты/приложения. Для кого-то проект, занимающий меньше года разработки — маленький. В каждом случае риски разные.

Если говорить в общем, то можно выделить следующие риски

1. Риск непрозрачного скоупа(нет общего пониманию между разработчиками и клиентом за что он платит).
2. Риск неверного скоупа(общего понимания достигли, но проект с данным скоупом может не достигнуть бизнес целей).
3. Финансовые риски(заказчик не платит за работу)
4. Технологические риски(у вас нет опыта с данной технологией и это может вылиться в раздувание сроков и бюджета)
5. Человеческий фактор(сделает ли конкретно эта команда данный продукт)
6. Организационные риски(простой специалистов, затягивание коммуникаций со стороны заказчика)

Есть и другие, их много и они сложно классифицируются.
Еще проблема в том, что рисками легко управлять на бумаги, но сложно — на практике.

Из литературы могу посоветовать Демарко «Вальсируя с медведями». Там конечно не про маленькие проекты, но общую идею поймете.

Кратко и по существу. Поддержу.

Большое спасибо за советы. Про книгу слышал, собиралсья как раз ее прочитать после того как дочитаю «Дедлайн» Демарко.

Гугли по „risk management software development” и „risk management it projects” — для начала, тебе хватит. :)

Риски — это основная работа PM, и соответственно основа квалификации. Если тебе эту тему приходится «искать», тогда о чём эти курсы?

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

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

Подписаться на комментарии