Peter Fomichev
Замечу, что почти все это указывается в стандарте PMBoK - ему лет почти столько же, сколько мне :) Дело, наверное, не в том что теории устарели - а как их подают.
Но, рад если мои мысли показались вам полезными.
Ну так и есть, web основной, но есть чуть-чуть мобилок тоже, хотя это не очень актуально для нас.
И все же я хотел написать материал, пункты из которого можно взять as is и сразу применить где угодно, где есть проблемы. Поэтому намеренно ушел от концентрации на узких моментах, типичных для разработки, но и ее не оставил за бортом. Я считаю, что если бы была задача делать какой-нибудь физический проект, пункты были бы примерно такие же, просто разработчики стали бы инженерами, там, или техниками :)
Слушай, хороший момент - но, нет. Связано с тем, что никакой речи о выходе за пределы дедлайна в рекламе быть не может в принципе - разговор о переносе сроков даже вести бесполезно. Это связано с тем, что на эту дату фиксируется еще множество других элементов, намного более дорогих, чем сама разработка. Дополнительные денежные затраты у нас исключены по иной причине.
Но методология тут действительно имеет место быть: можно для любого риска прописать не абстрактный урон, а более конкретную информацию. Например, дополнительное время на разработку, и как следствие - финансы. Вот уже и можно и множество таймингов построить с учетом всех рисков.
Что до конкретных формул расчета и урона, и финансово-временных затрат - я указал, что сам ими не пользуюсь, но я готов душу поставить, что они существуют. Возможно, даже сам стандарт PMBoK описывает их - не проверял давно, прости.
Другой вопрос, что стоит на кону и надо ли так сильно заморачиваться. Реклама - дело скоротечное, там всегда надо двигаться очень быстро, иногда жертвуя чем-то. Долгий проект, который стоит дорого, пожалуй, потребует более осмысленного подхода.
Привет.
1. Ну да :)
2. Степень урона нужна для понимания, что более важно, что менее важно. Предположим, что у нас есть всего три риска:
- Риск того, что дизайнер не успеет сдать в срок и мы не сможем вовремя начать фронт. Назначим ему значение урона 400 из 1000, а вероятность 3 из 5 (не лучший у нас дизайнер, раздолбай)
- Риск того, что внешняя платформа поменяет какие-нибудь методы API и что-то нам запретит из нужного. Вероятность 1 из 5, а урон 900 из 1000, проект вообще не случится без этого.
- И еще один риск того, что нам не поставят вовремя контент для шеров. Урон не страшный - всего 100 из 1000, а вероятность пусть будет 4 из 5.
В этой оценке мы понимаем, что внешняя платформа это конечно хорошо, она вроде как нам запарывает проект, но шанс этого не высок. Можно прописать план, что будем делать, если вдруг - и будем ждать. А вот дизайн, который сместит нам весь фронт - это серьезно, здесь надо внимательно следить.
Да, в общем и целом это нужно для сортировки и понимания, куда направить фокус внимания на разных временных участках разработки. На примере с тремя рисками можно держать все в голове. Но если у нас проект имеет 40-50 рисков, 3-5 разных подрядчиков, кучу людей - это все становится актуальным, потому что голова одна - а проблем очень много.
Привет!
Не передумал, но пока не получается написать ее хорошо. А публиковать то, что мне заведомо не нравится я не хочу :)