Pull to refresh

Comments 18

Прекрасно. Спасибо за хорошие примеры.
Мне понравилось. Но вот скажите, что делать в подобной ситуации:
фрилансеру или маленькой фирме нужны новые проекты. Они хотят делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ. Чтобы минимизировать риски невыполнения проекта или несоответствия тому, что напридумывал заказчик.
И тут приходит один, второй, пятый заказчик и все говорят, почесав затылок:
— Хочу, сайт, чтобы деньги зарабатывать, ну, например, партнёкру для веб-мастеров
— Не вопрос. Давайте ТЗ — отвечаете ему вы
-Вот, пожалуйста, — выдает он ссылку.
А в ссылке сумбур типа «конпки квадартные, можно логиниться, вебмастера размещают ссылки, а вы им деньги». Да к тому же таких партнёрок вы не делали ещё, нюансов не знаете
— Не, так не пойдёт. Это не ТЗ. Здесь ни чего не ясно и нужно разбираться: бизнес-модель изучить, юз-кейсы составить, над архитектурой подумать (хотя бы самой простой).
— Да что тут непонятно. Там же всё просто!
А потом ещё выясняется, что у него на все про всё есть 600$, а нет, то он к другому Васе пойдёт, который ему напел про 200$ за сайт с админкой.

И тут сидишь ты и думаешь… ну ведь я же качество ему предлагаю! Он доволен будет в итоге. Ведь я и так 10 баксов в час прошу всего…

А поезд ту-туууу. И что делать — не понятно. А ведь каждый 2ой проект, который я видел на фрилансе примерно так и выглядит: нет ТЗ, денег тоже почти нет, а вот требований к качеству и срокам — хоть отбавляй.

«Не вопрос. Давайте ТЗ» — вот тут косяк. Проектировать надо самому, задавая правильные вопросы.
О да, знакомо. Только Вася ему не сделает качество, которое он хочет. И в итоге он будет недоволен. Хотя, если Вася умный мужик, то он сделает то, что может и убедит, что именно это и нужно было :). А потом будет выманивать по баксу за каждый дополнительный чих.

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

И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».

А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
Дело в том, что ваш клиент интуитивно чувствует (или уже проходил и знает), что подробное ТЗ — это та бумажка, в которую вы будете тыкать его носом, когда вы возьмете его $600 и сделаете совсем не то, что ему на самом деле надо.

Клиент знает, что вероятность получить «не то» одинакова — что за $200, что за $600.

Поэтому клиент, идет к Васе за $200. Когда Вася сделает «не то», клиент дает ему еще $200 и просит переделать. А потом еще $200. В итоге за свои $600 он получает «более или менее то».
Тема хорошая. Только, как и большинство материалов по этой теме, статья получилась какая-то наукообразная. Нет ощущения, что советы испробованы на практике. Я ни разу не видел, чтобы кто-то управлял рисками в IT-компаниях на регулярной основе. Хотя готов поверить, что где-то это происходит.

Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.

Заранее благодарен.
Хочется верить, что автор топика практик, который делает все то, что тут написано.
Так и рассказал бы об этом.

А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.

Например, я хотел бы услышать такие реальные истории
  • «Мы практикуем формальное управление рисками (с реестром, оценками и т.п.). А если бы мы этого не сделали, то реально могли бы прошляпить вот этот риск» (типа, просто так, интуитивно, без реестра — ну точно бы прошляпили)
  • «Пришел риск, а у нас был план. А если бы не было плана — пришел бы песец»

> А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.

Лишнее напоминание никак не повредит. Тем более, что несмотря на то что всё 100 раз пережёвано (как вы говорите), многие (если верить автору) всё-равно управляют рисками только на бумаге, но никак не на деле.

>Например, я хотел бы услышать такие реальные истории
Я б тоже предпочёл реальные истории, хотя бы в виде примеров. Надеюсь что такие будут в продолжении. =)
Управление рисками — не самоцель, это инструмент для про-активных действий, для предотвращения возможных проблем, вместо тушния пожаров. Это инструмент коммуникации с руководством компании и клиентом.
В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
Обязательно поделюсь результатами.
Отлично написано! В продолжение хотелось бы увидеть краткую сводку по итогу.
Мне кажется, в большинстве проектов (по крайней мере, имеющих отношение к Хабру) единственный «риск», которым имеет смысл управлять — это изменение scope. Вот все силы и бросают на разборки с постоянно меняющимся скоупом. А на риски не забивают, просто с ними никто не возится формально.
Повторюсь, это лишь гипотеза :)
Меня тоже смущает всеобщее убеждение, что к Хабру имеют отношение только веб-проекты. Как же быть внедрятелям АСУ с бюджетами проектов от миллиона зелени? Куда сливать мысли и где делиться опытом? Пафосные «корпоративные» форумы — тоска зеленая и бесконечная фаллометрия. Мы же тоже люди и тоже хотим живого общения! :)
UFO landed and left these words here
UFO landed and left these words here
Уловил следующие темы:
1. Думать заранее.
Получается не всегда, а в реальности вообще никогда. Контракт приносят с мутным ТЗ и еще более мутными ожиданиями. Это не область контроля ПМ, да и вообще сфера банно-винных отношений. В госсекторе уж точно. Так что риск все равно придется заносить.
2. План управления рисками.
Ну план на то и план, что должен содержать мероприятия, ответственных, сроки и критерии достижения. Сами же писали про SMART.
3. Ранжирование и оценка рисков.
Если вы знакомы с теми книжками, которые перечисляли (а поводов сомневаться у меня нет), то там про ранжирование все очень хорошо написано. Продолжить мысль и понять количество рисков, которыми можно практически управлять несложно. Если бы большинство корпоративных андроидов не действовало по принципу «смотрю в книгу — вижу фигу», то мир вокруг был бы гораздо лучше.

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

Довелось поучаствовать в вытягивании одного высокобюджетного проекта при помощи 7-ми ключей IBM с участием консультантов. Могу сказать, что когда действует настоящий профи, все получается и кажется, что все элементарно. Не забывайте об этом признаке мастерства — простота и банальность. Но простота, о которой никто до сих пор не подозревал.
Спасибо за статью! Продолжайте писать, у вас хорошо получается. =)

По духу, ваша статья очень напомнила отличную книгу «Вальсируя с медведями». Собственно, это лучшая книга по управлению рисками в IT, которую я читал.
Only those users with full accounts are able to leave comments. Log in, please.