×Закрыть

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

Всем привет.

В данный момент работаю в небольшой компании 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, и соответственно основа квалификации. Если тебе эту тему приходится «искать», тогда о чём эти курсы?

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

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

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