Comments 18
Прекрасно. Спасибо за хорошие примеры.
+1
Мне понравилось. Но вот скажите, что делать в подобной ситуации:
фрилансеру или маленькой фирме нужны новые проекты. Они хотят делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ. Чтобы минимизировать риски невыполнения проекта или несоответствия тому, что напридумывал заказчик.
И тут приходит один, второй, пятый заказчик и все говорят, почесав затылок:
— Хочу, сайт, чтобы деньги зарабатывать, ну, например, партнёкру для веб-мастеров
— Не вопрос. Давайте ТЗ — отвечаете ему вы
-Вот, пожалуйста, — выдает он ссылку.
А в ссылке сумбур типа «конпки квадартные, можно логиниться, вебмастера размещают ссылки, а вы им деньги». Да к тому же таких партнёрок вы не делали ещё, нюансов не знаете
— Не, так не пойдёт. Это не ТЗ. Здесь ни чего не ясно и нужно разбираться: бизнес-модель изучить, юз-кейсы составить, над архитектурой подумать (хотя бы самой простой).
— Да что тут непонятно. Там же всё просто!
А потом ещё выясняется, что у него на все про всё есть 600$, а нет, то он к другому Васе пойдёт, который ему напел про 200$ за сайт с админкой.
И тут сидишь ты и думаешь… ну ведь я же качество ему предлагаю! Он доволен будет в итоге. Ведь я и так 10 баксов в час прошу всего…
А поезд ту-туууу. И что делать — не понятно. А ведь каждый 2ой проект, который я видел на фрилансе примерно так и выглядит: нет ТЗ, денег тоже почти нет, а вот требований к качеству и срокам — хоть отбавляй.
фрилансеру или маленькой фирме нужны новые проекты. Они хотят делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ. Чтобы минимизировать риски невыполнения проекта или несоответствия тому, что напридумывал заказчик.
И тут приходит один, второй, пятый заказчик и все говорят, почесав затылок:
— Хочу, сайт, чтобы деньги зарабатывать, ну, например, партнёкру для веб-мастеров
— Не вопрос. Давайте ТЗ — отвечаете ему вы
-Вот, пожалуйста, — выдает он ссылку.
А в ссылке сумбур типа «конпки квадартные, можно логиниться, вебмастера размещают ссылки, а вы им деньги». Да к тому же таких партнёрок вы не делали ещё, нюансов не знаете
— Не, так не пойдёт. Это не ТЗ. Здесь ни чего не ясно и нужно разбираться: бизнес-модель изучить, юз-кейсы составить, над архитектурой подумать (хотя бы самой простой).
— Да что тут непонятно. Там же всё просто!
А потом ещё выясняется, что у него на все про всё есть 600$, а нет, то он к другому Васе пойдёт, который ему напел про 200$ за сайт с админкой.
И тут сидишь ты и думаешь… ну ведь я же качество ему предлагаю! Он доволен будет в итоге. Ведь я и так 10 баксов в час прошу всего…
А поезд ту-туууу. И что делать — не понятно. А ведь каждый 2ой проект, который я видел на фрилансе примерно так и выглядит: нет ТЗ, денег тоже почти нет, а вот требований к качеству и срокам — хоть отбавляй.
0
«Не вопрос. Давайте ТЗ» — вот тут косяк. Проектировать надо самому, задавая правильные вопросы.
+2
О да, знакомо. Только Вася ему не сделает качество, которое он хочет. И в итоге он будет недоволен. Хотя, если Вася умный мужик, то он сделает то, что может и убедит, что именно это и нужно было :). А потом будет выманивать по баксу за каждый дополнительный чих.
Не уверена, что мой совет попадет в цель, но все же: попробуйте выявить наиболее, принципиально важные требования к будущему продукту, чтобы быстро и грязно (но с «заглушками», чтобы потом если что доделывать) сделать ту функциональность, которая сейчас этому заказчику жизненно важна. Не нужно думать над уровнями сложности пароля, поддержки кучи платежных систем и пр.
Выявить ту самую болевую точку сложно, но можно. (Можно у него попросить пример партнерки которая ему нравится и узнать чем именно она ему нравится).
И так потихоньку, по запчастям (возможно, потом окажется, что у него есть сотня-другая баксов, которые он сначала не был готов выкладывать) доводить его до полного удовлетворения.
И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».
А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
Не уверена, что мой совет попадет в цель, но все же: попробуйте выявить наиболее, принципиально важные требования к будущему продукту, чтобы быстро и грязно (но с «заглушками», чтобы потом если что доделывать) сделать ту функциональность, которая сейчас этому заказчику жизненно важна. Не нужно думать над уровнями сложности пароля, поддержки кучи платежных систем и пр.
Выявить ту самую болевую точку сложно, но можно. (Можно у него попросить пример партнерки которая ему нравится и узнать чем именно она ему нравится).
И так потихоньку, по запчастям (возможно, потом окажется, что у него есть сотня-другая баксов, которые он сначала не был готов выкладывать) доводить его до полного удовлетворения.
И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».
А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
+6
Дело в том, что ваш клиент интуитивно чувствует (или уже проходил и знает), что подробное ТЗ — это та бумажка, в которую вы будете тыкать его носом, когда вы возьмете его $600 и сделаете совсем не то, что ему на самом деле надо.
Клиент знает, что вероятность получить «не то» одинакова — что за $200, что за $600.
Поэтому клиент, идет к Васе за $200. Когда Вася сделает «не то», клиент дает ему еще $200 и просит переделать. А потом еще $200. В итоге за свои $600 он получает «более или менее то».
Клиент знает, что вероятность получить «не то» одинакова — что за $200, что за $600.
Поэтому клиент, идет к Васе за $200. Когда Вася сделает «не то», клиент дает ему еще $200 и просит переделать. А потом еще $200. В итоге за свои $600 он получает «более или менее то».
0
Тема хорошая. Только, как и большинство материалов по этой теме, статья получилась какая-то наукообразная. Нет ощущения, что советы испробованы на практике. Я ни разу не видел, чтобы кто-то управлял рисками в IT-компаниях на регулярной основе. Хотя готов поверить, что где-то это происходит.
Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.
Заранее благодарен.
Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.
Заранее благодарен.
0
Хочется верить, что автор топика практик, который делает все то, что тут написано.
Так и рассказал бы об этом.
А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.
Например, я хотел бы услышать такие реальные истории
Так и рассказал бы об этом.
А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.
Например, я хотел бы услышать такие реальные истории
- «Мы практикуем формальное управление рисками (с реестром, оценками и т.п.). А если бы мы этого не сделали, то реально могли бы прошляпить вот этот риск» (типа, просто так, интуитивно, без реестра — ну точно бы прошляпили)
- «Пришел риск, а у нас был план. А если бы не было плана — пришел бы песец»
+1
> А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.
Лишнее напоминание никак не повредит. Тем более, что несмотря на то что всё 100 раз пережёвано (как вы говорите), многие (если верить автору) всё-равно управляют рисками только на бумаге, но никак не на деле.
>Например, я хотел бы услышать такие реальные истории
Я б тоже предпочёл реальные истории, хотя бы в виде примеров. Надеюсь что такие будут в продолжении. =)
Лишнее напоминание никак не повредит. Тем более, что несмотря на то что всё 100 раз пережёвано (как вы говорите), многие (если верить автору) всё-равно управляют рисками только на бумаге, но никак не на деле.
>Например, я хотел бы услышать такие реальные истории
Я б тоже предпочёл реальные истории, хотя бы в виде примеров. Надеюсь что такие будут в продолжении. =)
0
Управление рисками — не самоцель, это инструмент для про-активных действий, для предотвращения возможных проблем, вместо тушния пожаров. Это инструмент коммуникации с руководством компании и клиентом.
В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
Обязательно поделюсь результатами.
В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
Обязательно поделюсь результатами.
0
Отлично написано! В продолжение хотелось бы увидеть краткую сводку по итогу.
0
Мне кажется, в большинстве проектов (по крайней мере, имеющих отношение к Хабру) единственный «риск», которым имеет смысл управлять — это изменение scope. Вот все силы и бросают на разборки с постоянно меняющимся скоупом. А на риски не забивают, просто с ними никто не возится формально.
Повторюсь, это лишь гипотеза :)
Повторюсь, это лишь гипотеза :)
+1
Меня тоже смущает всеобщее убеждение, что к Хабру имеют отношение только веб-проекты. Как же быть внедрятелям АСУ с бюджетами проектов от миллиона зелени? Куда сливать мысли и где делиться опытом? Пафосные «корпоративные» форумы — тоска зеленая и бесконечная фаллометрия. Мы же тоже люди и тоже хотим живого общения! :)
0
UFO just landed and posted this here
Уловил следующие темы:
1. Думать заранее.
Получается не всегда, а в реальности вообще никогда. Контракт приносят с мутным ТЗ и еще более мутными ожиданиями. Это не область контроля ПМ, да и вообще сфера банно-винных отношений. В госсекторе уж точно. Так что риск все равно придется заносить.
2. План управления рисками.
Ну план на то и план, что должен содержать мероприятия, ответственных, сроки и критерии достижения. Сами же писали про SMART.
3. Ранжирование и оценка рисков.
Если вы знакомы с теми книжками, которые перечисляли (а поводов сомневаться у меня нет), то там про ранжирование все очень хорошо написано. Продолжить мысль и понять количество рисков, которыми можно практически управлять несложно. Если бы большинство корпоративных андроидов не действовало по принципу «смотрю в книгу — вижу фигу», то мир вокруг был бы гораздо лучше.
Что же до комментаторов, сомневающихся в практическом применении всего перечисленного, то отвечу за себя. Применимо все. Практически риск менеджмент выглядит очень просто. Вся перечисленная наука спрятана под кат, а до исполнителя доводится только перечень мероприятий. Короткий, как правило.
Довелось поучаствовать в вытягивании одного высокобюджетного проекта при помощи 7-ми ключей IBM с участием консультантов. Могу сказать, что когда действует настоящий профи, все получается и кажется, что все элементарно. Не забывайте об этом признаке мастерства — простота и банальность. Но простота, о которой никто до сих пор не подозревал.
1. Думать заранее.
Получается не всегда, а в реальности вообще никогда. Контракт приносят с мутным ТЗ и еще более мутными ожиданиями. Это не область контроля ПМ, да и вообще сфера банно-винных отношений. В госсекторе уж точно. Так что риск все равно придется заносить.
2. План управления рисками.
Ну план на то и план, что должен содержать мероприятия, ответственных, сроки и критерии достижения. Сами же писали про SMART.
3. Ранжирование и оценка рисков.
Если вы знакомы с теми книжками, которые перечисляли (а поводов сомневаться у меня нет), то там про ранжирование все очень хорошо написано. Продолжить мысль и понять количество рисков, которыми можно практически управлять несложно. Если бы большинство корпоративных андроидов не действовало по принципу «смотрю в книгу — вижу фигу», то мир вокруг был бы гораздо лучше.
Что же до комментаторов, сомневающихся в практическом применении всего перечисленного, то отвечу за себя. Применимо все. Практически риск менеджмент выглядит очень просто. Вся перечисленная наука спрятана под кат, а до исполнителя доводится только перечень мероприятий. Короткий, как правило.
Довелось поучаствовать в вытягивании одного высокобюджетного проекта при помощи 7-ми ключей IBM с участием консультантов. Могу сказать, что когда действует настоящий профи, все получается и кажется, что все элементарно. Не забывайте об этом признаке мастерства — простота и банальность. Но простота, о которой никто до сих пор не подозревал.
0
Спасибо за статью! Продолжайте писать, у вас хорошо получается. =)
По духу, ваша статья очень напомнила отличную книгу «Вальсируя с медведями». Собственно, это лучшая книга по управлению рисками в IT, которую я читал.
По духу, ваша статья очень напомнила отличную книгу «Вальсируя с медведями». Собственно, это лучшая книга по управлению рисками в IT, которую я читал.
0
Sign up to leave a comment.
Risk Management: предотвращение проблем vs. ведение регистра рисков