Наверх ▲

Деловая игра “Гибкое управление рисками”

Борис Вольфсон Борис Вольфсон Борис Вольфсон занимается веб-разработкой и разработкой программного обеспечения с 2003 года. Карьеру начал в качестве программиста компании «Систем-Софт» в Оренбурге. С 2008 года – руководитель проектов и руководитель регионального отдела разработки в компании Softline.

Борис Вольфсон: Меня зовут Борис Вольфсон, я руководитель Департамента разработки интернет-проектов компании "Softline". Это я сейчас пытаюсь получить авторитет в ваших глазах, чтобы вы мне доверяли. Под моим руководством работает более 100 человек. Мы, в основном, занимаемся интернет-проектами. У нас распределенная команда в нескольких городах – достаточно стандартный набор для современной IT-компании.

Сегодня я прочту небольшой доклад в виде деловой игры с элементами симуляции управления рисками. Есть среди вас кто-то, кто что-то слышал про риски вообще? Три-четыре человека.

По условиям игры мы разбиваемся на команды по 5-9 человек. Я предлагаю занять еще один стол. Кто вам больше всего не нравится в команде?

Реплика из зала: Это неправильная постановка вопроса. Лучше с другой стороны как-то.

Борис Вольфсон: Кто самое слабое звено? Я просто думаю, что можно еще на три команды разбиться. Нет желания? Окей. Разбились. Все друг на друга смотрят – тяжеловато будет.

Реплика из зала: Мы уже успели сплотиться. Мы уже не хотим.

(Демонстрация слайда).

Борис Вольфсон: Хорошо. Давайте тогда потихонечку перейдем к сути, познакомимся. Кто из вас в той или иной мере занимается ведением проектов? Отлично! Давайте так: а у кого-нибудь были не очень удачные проекты? Вот! А у кого-нибудь был хоть один проект, который был полностью провален? Правда?

Реплика из зала: Да.

Борис Вольфсон: Окей.

Реплика из зала: Я считаю, что это полностью.

Борис Вольфсон: У меня третий вопрос есть. Ты достаточно честен с нами. По своему опыту, по опыту коллег, с которыми я работаю, по опыту конференций, которые приходилось посещать, докладов, которые доводилось слушать, и разговорам в кулуарах, я могу сказать, что обычно есть не очень удачные проекты либо совсем неудачные. Соответственно, управление рисками подразумевает, что мы будем анализировать, оценивать  эти потенциальные неудачи. Возможно, качественно. Если у нас более строгая система по управлению проектами, то даже количественно. Мы также можем пытаться предпринимать какие-то превентивные действия.

Когда я спрашивал о рисках, три человека подняли руки. А у вас есть какой-то список рисков, который, может быть,  называется реестром? Нет? Те же два-три человека. Еще один провокационный вопрос: это такой тайный список менеджера, или он известен всей команде?

Реплики из зала: Известен команде. Известен. Выложен.

Борис Вольфсон: Всей команде известен, да? Хорошо! Когда мы в прошлый раз проводили эту игру, очень многие сообщили, что у них есть список рисков. В итоге, когда мы их порасспрашивали, оказалось, что это какой-то тайный Excel-файл, который лежит у менеджера. Соответственно, про него только один менеджер и знает. 

У кого этот список реально используется? Это означает, что у вас в проекте идет какая-то деятельность по предотвращению этих рисков, по их принятию, и так далее. Идет такая деятельность, или просто есть список?

Реплика из зала: Список есть.

Реплика из зала: Сложно сказать. Нет отдельного процесса, но если написано, то понятно, что надо как-то действовать… У нас существует риск ухода ключевого специалиста из компании. Значит, нужнопотенциально быть готовыми распределить его обязанности между другими сотрудниками. В таком виде.

Борис Вольфсон: Очень-очень хороший пример!

Давайте так еще раз. Поскольку нас не очень много, у нас получается взаимодействие больше в виде тренинга (я еще тренинги периодически веду). Поэтому активно участвуйте, перебивайте, высказывайте свое мнение.

Еще один вопрос по поводу не очень удавшихся проектов. Может кто-то привести пример того, почему проект не удался? Какой риск реализовался, что послужило причиной провала?

Реплика из зала: Очень поверхностные коммуникации.

Борис Вольфсон: Да, с заказчиком. Слабые коммуникации с заказчиком.

Реплика из зала: Отсутствие поддержки руководства и жесткий прессинг по срокам.

Борис Вольфсон: А в чем выражалось отсутствие поддержки руководства? Они не поддерживали ваши оценки?

Реплика из зала: Срок был очень жестко поставлен. У нас есть такой срок – и все, дальше не интересно. А в процессе руководство, скажем так, не уделяло внимания важным вопросам.

Борис Вольфсон: А у этой команды есть какие-то примеры по проектам?

Реплика из зала: У меня был проект, в котором мы выполняли только часть работы, и еще часть выполнялась офисом за рубежом. Эти проекты тоже были за рубежом. Скажем так, были определенные тонкости в согласовании методов решения задач. На этом этапе руководством было принято, на наш взгляд, неправильное решение. К сожалению, из-за этого в проекте возникли серьезные сложности. Не скажу, что это был полный провал, но могло быть намного лучше.

Борис Вольфсон: У нас такой "Клуб анонимных менеджеров проектов". Кто-нибудь еще хочет поделиться своим опытом?

Реплика из зала: Не промониторили технические риски на перспективу развития платформы. Оказалось, что мы делаем под старую платформу, а под новую нет.

Борис Вольфсон:  Все. Кончилось...

Реплика из зала: Тренинг.

Борис Вольфсон: Села батарейка, кончился тренинг. Мы уже поговорили, уже привели примеры рисков. Даже были произнесены слова "технический риск", "организационный риск" – уже в голове есть какая-то систематизация.

(Демонстрация слайда).

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

Обычно вред проекту наносится по двум критериям: по срокам (тут уже было тоже озвучено) либо по бюджету. Если вы сильно ориентированы на рынок, скажем, – это, прежде всего, бюджетные риски. Если у вас, например, in-house разработка (у нас большинство проектов к ней относится), то, соответственно, для нас самое главное – соблюдать сроки. 

Соответственно, я рассказываю не просто про управление рисками, а про управление рисками при использовании гибких методологий. Кто-то работает по гибким методологиям, применяет Scrum? А остальные?

Реплика из зала: Знакомы. Другие тоже применяем.

Борис Вольфсон: Знакомы. А вы что используете в своей деятельности? Если не Scrum, что – RUP?

Реплика из зала: Посередине.

Борис Вольфсон: Что-то посередине. Как это назвать? Code&Fix? Cowboy coding? Как вы сами можете определить?

Реплика из зала: Начали с RUP, а потом стали применять то, что осталось.

Борис Вольфсон: То есть вы какой-то кусочек из RUP взяли. Хорошо!

Реплика из зала: Agile RUP получается

Борис Вольфсон: Agile RUP. RUP – он такой адаптируемый процесс.

Реплика из зала: Он сам по себе может быть очень гибким. Он сам на основе гибкой методологии.

 Борис Вольфсон: Он может быть и совсем Agile, а может быть совсем "пиши отчеты".

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

У меня несколько слайдов болтологии, а потом начинается что-то интересное.

(Демонстрация слайда).

На риски можно реагировать двумя способами: реактивно и превентивно. В своем подходе, в своих проектах лучше всего действовать превентивно. Надо на самом раннем этапе выявлять риски. Желательно при запуске проекта, когда идет обсуждение концепции, миссии проекта (в зависимости от того, как у вас поставлено проектное управление), содержания проекта, делать либо иерархическую структуру работ, если у вас что-то более классическое, либо bot mode, если вы используете Scrum. 

Соответственно, на данном этапе полезно собрать всю команду. Либо, если у вас очень большой проект и это дорого (собрать всю команду) – ядро команды, основных членов из продуктовой части и тех, кто занимается разработкой, провести такую риск-сессию. Проще говоря, сесть и подумать, какие могут быть проблемы.

Мыв течение доклада-тренинга попробуем это сделать. На основе того, что вы выявите в ходе этой риск-сессии, можно будет выработать список мер, которые помогут нам эти риски в дальнейшем минимизировать.

Здесь были приведены примеры. Если вы видите, что у вас есть какие-то проблемы, например, с ведущим разработчиком, вам надо подстраховаться на случай его ухода или болезни. Что еще хочется сказать? Никогда не надо делать больше, чем надо. В гибких методологиях есть два принципа: KISS и YAGNI. Кто-то слышал эти аббревиатуры? KISS – это…

Реплика из зала: Keep it simple, stupid.

Борис Вольфсон: Да. Я по-русски скажу, чтобы не было иностранных ругательств: "сохранять вещи максимально простыми". Не придумывайте лишнего, думайте, что вам реально нужно сегодня. Если мы говорим о рисках (риск – это всегда будущее время), мы стараемся не заглядывать на несколько лет вперед, но оценивать какую-то ближайшую перспективу.

Второй принцип (он схож с первым) – YAGNI. Эта аббревиатура расшифровывается как "вам, возможно, это не понадобится". Опять то же самое: перед тем, как вы выработаете пакет каких-то мер (эти меры чего-то стоят), подумайте, стоит ли тратить на них ваш бюджет в том или ином виде.

Про визуализацию рисков я уже сказал. У нас не обнаружилось таких людей, которые прячут свой Excel-файл, doc-файл. Это самый примитивный вариант. Знания нужно распространять.

Если у вас большая распределенная команда, можно выполнять периодическую рассылку писем. Можно этот файл с рисками или сами риски записать в Wiki, куда все заглядывают.

Внутри Scrum есть очень хорошая практика (поскольку Scrum не все знают, я буду еще и про Scrum говорить) – ретроспектива. Ретроспектива – это мероприятие, которое проводится по завершению спринта. На ретроспективе команда обсуждает, какие в этом спринте были проблемы и что было сделано хорошо, а также вырабатывает меры по дальнейшему улучшению. Scrum-команды, которые управляют рисками, могут обсуждать, какие риски у них могут быть, на каждом спринте, каждые 2-4  недели.

Самый хороший вариант для небольшой команды, находящейся в одном помещении – просто взять и сделать отдельную доску с рисками. У нас один проект так риск-сессию проводил – очень удобно. У вас есть комната, все видят, какие существуют риски, все знают, над какими рисками надо работать. При всей кажущейся простоте, это один из самых эффективных методов визуализации рисков и работе с ними.

Реплика из зала: Радиатор.

Борис Вольфсон: Радиатор. Да. Те, кто часто читает Agile-блоги, и так далее, знают, что обычно используется такой термин, как "радиатор". "Информационный радиатор" – то, что греет. 

У вас в вашей работе есть "информационные холодильники" – это, например, система управления задачами. Если вы положите туда задачу, про нее в итоге могут вообще забыть. У кого-нибудь есть штук 100 багов, которые где-то лежат, позабытые всеми? Руки поднимают не все, но некоторые улыбаются, я вижу – я это тоже за "да" принимаю. Есть соответственно "информационные радиаторы", которые, наоборот, выкачивают эту информацию. Мы упомянули один из видов такого "информационного радиатора", "информационной батарейки".

(Демонстрация слайда).

Соответственно, существуют определенные этапы работы с рисками (мы сегодня некоторые из них тоже попробуем). На первом этапе это выявление рисков. Оно осуществляется либо в виде риск-сессии, либо в виде мозгового штурма. Есть последние тенденции – использовать для этого инновационные игры. Это для тех, кому интересно так делать, для тех, кто любит именно такую игровую форму. Самое смешное, что топ-менеджеры крупных компаний очень хорошо играют в такие игры.

Реплика из зала: Нюка Холдмана игры?

Борис Вольфсон: Да. "Speed boat", например, самая известная.

Реплика из зала: А также "Product box" там.

Борис Вольфсон: "Product box" тоже. Для рисков очень хорошо использовать игру "Скоростная лодка". Она очень проста: на доску, на стену вешается изображение лодки, и команда начинает стикерами клеить якоря, которые могут  остановить эту лодку. Обычно, чем глубже якорь, тем опаснее риск, тем сильнее этот якорь может лодку зацепить и остановить.

В принципе, методы одни и те же, но у них разная форма. В зависимости от того, какая у вас культура… Если у вас супер креативная компания, можно, соответственно, игру провести. Если у вас все ходят в костюмчиках, можно провести какую-то формальную риск-сессию.

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

После этого мы планируем, как мы на эти риски будем реагировать – составляем список мер и принимаем часть мер в реализацию. Во время исполнения проекта надо обязательно мониторить этот список. Что это означает? Это означает, что вам надо периодически просматривать (если у вас используется итеративная методология, можно по завершении итерации), какие из этих рисков реализовались, пополнять эти риски, может быть, периодически проводить дополнительные риск-сессии. Например, после релизов. Если у меня двухнедельная итерация и ежеквартальный релиз, я могу каждые 6 спринтов такую риск-сессию проводить.

(Демонстрация слайда).

Остановлюсь отдельно на извлечении уроков. По завершении проектов (это очень важная практика) очень желательно куда-то складывать те риски, которые у вас реализовались. Здесь есть два варианта. Мы эту терминологию уже использовали: "холодильник", "радиатор". Вы можете сделать (это такой классический корпоративный подход) базу данных рисков реализованных. Вы пишете то, что мы вначале проводили: "У меня случилась вот такая неприятность, из-за этого с моим проектом произошло вот это. А исправить ее можно было…" Надо рассказать про свои ошибки, чтобы на них все могли поучиться.

(Демонстрация слайда).

Я уже упомянул про мозговые штурмы, про риск-сессии. Сразу возникает вопрос: откуда эти риски вообще можно взять? Есть несколько возможных вариантов для помощи. Я здесь выписал категории рисков.

Здесь дана упрощенная категоризация рисков из MSF (фреймворка для управления проектами от Microsoft). Я в конце дам ссылочку, название – можно в Интернете это свободно скачать. Это более легковесный подход, он годится для небольших проектов.

Если у вас проекты большие, у вас более корпоративный подход, можно использовать сценарий рисков от SEI – это Институт программной инженерии.

Реплика из зала: Можете подробнее рассказать?

Борис Вольфсон: Я название дам, можете посмотреть – у них шикарнейший опросник. Но это более тяжеловесный инструмент. Наверное, если вы раздадите команде документ на несколько сотен страниц и скажете: "Давайте, анализируйте риски", – народ не очень этому обрадуется.

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

(Демонстрация слайда).

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

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

Третье – это процессы. Я таким образом сформулирую: чем больше у вас компания, тем четче они должны быть прописаны. Я сейчас объясню свою мысль.

Если вы делаете небольшой стартап, у вас может не быть никаких должностных инструкций, у вас из системы управления проектами может быть буквально одна доска. Но по мере роста вам необходимо эти процессы описывать, стандартизировать, не доводя до полной бюрократии, до маразма.

Соответственно, четвертый вид рисков (он для нас не так актуален, по крайней мере, они не так часто реализуются) – это внешние условия. Самая здесь важная категория – это конкуренты. Если вы работаете на действительно прибыльном рынке, обязательно найдется кто-то, кто захочет покуситься на вашу часть. Мы чуть попозже на них еще посмотрим. 

На структуре риска тоже я подробно останавливаться не буду. Обратите внимание на верхнюю часть схемы. 

(Демонстрация слайда).

Очень важно выявлять первопричины рисков и проблем. Есть стандартные инструменты – тоже кому интересно, посмотрите. Достаточно простые, например, "5 почему".

Реплика из зала: Fishbone-диаграмма.

Борис Вольфсон: Да. Я сейчас расскажу… Самый простой инструмент – это "5 почему". Вы называете проблему, спрашиваете, почему она произошла – человек вам отвечает. Вы спрашиваете, почему произошло еще вот это – и так пять раз, пока не дойдете до корня.

Есть разного рода древовидные подходы. Один из вариантов – fishbone-диаграмма. Есть разного рода причины, и так далее, но это если вам нужен более системный подход. По моему опыту, в 80-90 % случаев, чтобы докопаться до истинной причины, достаточно 5 раз спросить "почему".

(Демонстрация слайда).

Так. Все! Давайте я закончу говорить, голос начинает садиться. Во что мы, собственно, сегодня будем играть?

У нас третья команда не образовалась.

Реплика из зала: А могла бы.

Борис Вольфсон: Я вот тоже думаю, что могла бы. Нет желания занять еще один стол слева? Коллеги, нет?

Реплика из зала: Есть.

Борис Вольфсон: Давайте туда еще. Я тут такую "джинсу" компании, в которой я работаю, сделал! У меня фирменные конверты.

Реплика из зала: Еще рано.

Реплика из зала: Можно уже смотреть, потому что очень хочется?

Борис Вольфсон: Три секунды, сейчас. А я два дал, да?

Реплика из зала: Вроде бы.

Борис Вольфсон: Что вы кинули на тот стол?

Реплика из зала: Третий конверт.

Борис Вольфсон: Третий конверт. Хорошо! Я бы просто предложил одному человеку к вам присоединиться. Вдвоем скучно будет.

Реплика из зала: Можно кого-нибудь забрать из другой команды?

Борис Вольфсон: Кто вам больше нравится?

Реплика из зала: Определились.

Борис Вольфсон: Отлично! Давайте распаковывайте, смотрите, что там есть. На большом листке есть вводная тема. Давайте, у меня еще есть комплекты. Еще, наверное, есть комплекты. Условия еще кому надо?

Реплика из зала: Можно нам одно.

Реплика из зала: А есть еще условия?

Борис Вольфсон: Да.

Реплика из зала: Можно посмотреть?

Борис Вольфсон: Есть вводный текст – почитайте. Одинаковый, у всех одинаковый. Тут никакого подвоха нет.

Там описывается социальная сеть. Это первое.

Реплика из зала: Какова задача здесь?

Борис Вольфсон: Сейчас прочитают все, и я расскажу. Так, коллеги! Прочитали? Можно только ничего не заполнять пока, ничего не писать? Давайте отвлечемся.

На большом листке у вас, соответственно, есть описание того проекта, который вы делаете, который мы будем разыгрывать в игре. 

На маленьких листках у вас есть небольшая подсказка – это контрмера против рисков. Это, надеюсь, понятно? Не понятно? Каждая контрмера обычно чего-то стоит. Абсолютно как в жизни. Это либо уменьшение вашего бюджета (вы нанимаете тренера, покупаете новые компьютеры, и так далее), либо замедление работы вашей команды на спринт обычно (ставите новую технологическую платформу, изучаете разработку через тестирование, и так далее). 

Еще есть одна бумажка небольшая – она нужна для заполнения информации по тем спринтам, по которым мы побежим. Мы попробуем 6 спринтов сделать. Я попозже скажу, как механика идет. 

Спринтом (для тех, кто не знает, еще раз повторюсь) называется итерация внутри Scrum. Она жестко определена по количеству дней. Наиболее популярны в России и в Украине двухнедельные итерации, особенно для веб-проектов. Мы общались с представителями крупных компаний… У "Одноклассников" недельные итерации. У тех, кто разрабатывает desktop-систему, месячные итерации бывают, потому что им не надо так часто выпускать релизы.

Первое, что нам надо сделать – выбрать одного человека. Он будет секретарем – он запишет то, что вы обсудите, то, что вы придумаете.

На меня внимание! Надо найти 20 рисков по данному проекту, записать их в виде "условие – последствие". Если у нас уходит главный разработчик – у нас резко снизится скорость, мы не успеем сделать вовремя. В жизни можно абсолютно так же поступать.

Поскольку мы бедны, у нас нет отдельных карточек для этого – листок, списком сделаем. У вас 20 минут на это. На самом деле, если мало, можно чуть-чуть побольше. 

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

(Демонстрация слайда).

Вопросы?

Реплика из зала: Цель текущего упражнения в чем состоит?

Борис Вольфсон: Составить список из 20 рисков.

Реплика из зала: Пока не считая мер и всего остального?

Борис Вольфсон: Да. Просто составить.

Реплика из зала: Эти 20 минут – это однородный промежуток или мы его как-то дробим?

Борис Вольфсон: Не дробим, просто 20 минут. Час, ровно час.

Реплика из зала: Так мы просто делаем мозговой штурм?

Борис Вольфсон: Да, мозговой штурм. Такая риск-сессия.

Если есть вопросы, спрашивайте – я скажу. Желательно, чтобы каждый высказался, чтобы каждый, может быть, взял себе отдельную категорию.

Потом помотрим, что получилось.

Реплика из зала: Кто тут человек, который красивее всех пишет и громче всех говорит?

Реплика из зала: Нет, я хуже всех пишу, поэтому мне же и читать.

Реплика из зала: Все-все-все!

Реплика из зала: Надо было печатать.

Реплика из зала: А сколько у вас, если не секрет?

Реплика из зала: 22. Они там еще придумывают.

Реплика из зала: Нормально! Они все реальные.

Реплика из зала: Зачитывать?

Борис Вольфсон: Да. Давай первые 10 – такие самые. Топ-10 рисков.

Реплика из зала: Самые я не выберу.

Реплика из зала: Мы их не выделим, у нас подряд.

Реплика из зала: Мы их не ранжировали еще.

Реплика из зала: Не ранжировали по категориям.

Борис Вольфсон: Сейчас будет возможность.

Реплика из зала: Один из рисков – потеря интереса у инвестора. Соответственно, может привести к тому, что придется искать нового инвестора – это затяжные сроки, это проблемы с бюджетом.

Уход ключевых сотрудников – соответственно, поиск новых. Время, сроки, бюджет, опять же.

Непроработанное ТЗ приведет к неудачному проекту.

Плохая аналитика с непроработанными бизнес-требованиями приведет к непродаваемому продукту.

Борис Вольфсон: Под ТЗ что подразумевается?

Реплика из зала: Набор требований.

Реплика из зала: Мы совместили набор требований для социальной сети как продукту и как…

Реплика из зала: Это два риска.

Реплика из зала: Да. Мы объединили.

Реплика из зала: А можно мне "пять копеек вставить"?

Борис Вольфсон: Можно.

Реплика из зала: Обратный риск: проработанное ТЗ запросто приведет к провалу продукта. Хорошо проработанное большое ТЗ точно к провалу приведет.

Реплика из зала: Это да! Но извини, не записали.

Реплика из зала: У нас как бы Scrum. Именно потому и не прорабатывалось в полной мере…

Реплика из зала: У нас аналитика нет в команде.

Борис Вольфсон: Мне очень нравится фраза "как бы Scrum".

Реплика из зала: Но тут написано "как бы Scrum", пардон.

Борис Вольфсон: Как бы Scrum.

Реплика из зала: С недавних пор ведется…

Реплика из зала: Да! С недавних пор, но еще не до конца установился.

Реплика из зала: Следующий риск – не масштабируемая архитектура. Так как проект развивается, будут проблемы с посещением, и так далее.

Борис Вольфсон: Супер!

Реплика из зала: Конфликты в команде, возможно, приведут к проблемам с разработкой и улаживанию проблем.

Заниженные сроки разработки – опять же, риск. Бюджет, сроки, потеря инвестора.

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

Несоответствие средств разработки для дальнейшего масштабирования проекта – будет снижение скорости.

Борис Вольфсон: Окей! Спасибо.

Реплика из зала: И так далее.

Борис Вольфсон: Спасибо. Ребята, у кого-нибудь есть еще какие-то значимые риски, которые не проговорили?

Реплика из зала: У нас точно есть. Просто надо, чтобы я их еще вычитал. Зачитать те, которые не пересекаются?

Борис Вольфсон: Не пересекаются, да. Новые какие-то.

Реплика из зала: Я так и не понял, пересекается или нет то, что не успеем дожить до третьего раунда.

Борис Вольфсон: Потеря инвестора. Да.

Реплика из зала: Второе – конкуренты могут задавить.

Реплики из зала: Да. У нас был такой.

Реплика из зала: Ненадежная доставка – процесс слишком сырой.

Реплика из зала: Доставка чего?

Реплика из зала: Продукта! Чего? 

Реплика из зала: А! У вас другой!

Реплика из зала: Релиза! Чего?

Реплика из зала: У вас как называется проект?

Реплика из зала: У нас "На рыбалке".

Реплика из зала: "На рыбалке". У всех "На рыбалке".

Реплика из зала: Вы же видите как-то. Вы же должны как-то бета-версию свою доводить, чтобы инвесторы видели график работ – что она развивается, что проектне "умер", новые опции появляются.

Реплика из зала: Я не вижу логики.

Реплика из зала: Конечно!

Борис Вольфсон: В этой игре нельзя победить, убедив, что твой риск лучше. Тут по-другому будет.

Реплика из зала: У меня просто инстинкт сразу сработал! Хорошо.

Подрядчик не выполнит обязательств. Опять же, здесь с кадровыми рисками пересекается.

Запрет на рыбалку бесплатную, например. Если слишком режет…

Реплика из зала: А что, у нас больше нет…

Реплика из зала: Часть рисков, связанных с аутсорсером. Один сервер – это вы называли.

Реплика из зала: Например, стоимость…

Реплика из зала: Повышение стоимости аутсорсинговых услуг – это может помешать нам дожить до третьего раунда.

Не хватит аппаратного обеспечения для версий последующих – это у вас было, или у вас архитектура была? Я не помню, что у вас.

Реплика из зала: В списке есть, мы не озвучили.

Реплика из зала: Да. У Тода Тонера нехватка времени на управление требованиями, поскольку у него в голове третий раунд и фандрайзинг.

Вы говорили про безопасность данных, по-моему. Вот! Резервирование данных – это не безопасность.

Реплика из зала: Это, опять же, не озвучили, это было отдельно.

Реплика из зала: Окупаемость недостижима в принципе. Деньги-то идут, но на окупаемость мы, возможно, в принципе не можем выйти.

В принципе, все.

Борис Вольфсон: А у третьей команды есть какие-то риски, которые не назывались еще?

Реплика из зала: Хакнут нашу сеть и дестабилизируют или утащат данные. Это приведет к потере репутации со всеми вытекающими последствиями.

Реплика из зала: Так это же все безопасность.

Реплика из зала: Да, это из безопасности. Вирус на сервере либо на машинах у наших разработчиков. Это затормозит разработку, и так далее.

Реплика из зала: Это же два раза называлось!

Борис Вольфсон: Алекс!

Реплика из зала: Мы разрабатываем на одном сервере, который может исчезнуть, и мы не сможем продолжать разработку какое-то время.

Ошибки хостера в администрировании, потому что он что-то делает – мы можем что-то сделать не так. Репутация и время потеряются.

Отпуск, болезнь любого человека из команды. Конфликты в команде. Опять же, уход сотрудника, и так далее. Хостер передаст куда-то персональные данные – утечка. 

Конкуренты либо преуспеют больше нашего, либо переманят наших сотрудников, либо украдут нашу идею – опять же, мы потеряем время, клиентов, репутацию.

Если у нас в команде плохо поставлен Scrum, мы, опять же, потеряем время и что-то там не доставим.

Все.

Борис Вольфсон: Окей! Спасибо. В жизни какие-то из этих рисков у вас срабатывали? Посмотрите свой список.

Реплика из зала: У меня был стартап в Калифорнии, который не выжил. Там и кризис, конечно, "помог" не дожить до следующего раунда.

Борис Вольфсон: Это к внешним условиям как раз относится. А у вас что-то из этого было? Что-то новое "всплыло"?

Реплика из зала: У меня были кадровые неприятности и серверные тоже.

Борис Вольфсон: Кадровые проблемы, да? А у третьей команды?

Реплика из зала: Кадровые – да. Я думаю, у многих из нас.

Реплика из зала: Аутсорсер участвовал.

 Борис Вольфсон: Я сразу свое вспомнил! Согласен полностью.

У нас есть список рисков. Уже говорили, что не распределены риски по приоритетам, они никак не оценены. Что надо сделать? Нам надо теперь эти риски приоритезировать.

Если брать "тяжелый" менеджмент, там есть специальные количественные математические модели. Я крайне рекомендую посмотреть (по-моему, у Максима Дорофеева есть презентация на эту тему), как такие модели могут применяться, какие обманные вещи они могут в себе таить при всей их кажущейся мощности, математичности. Вы можете быть уверены, что у вас есть сумма денег, которую вам надо на этот риск заложить, и все равно вы можете очень сильно "пролететь".

Я более простую модель предлагаю использовать. У риска всего два параметра. У риска есть вероятность – это раз. Мы будем просто обозначать параметр числами от одного до трех: один, два, три.

Реплика из зала: Где здесь один, два, три чисто?

Борис Вольфсон: Чисто один, два, три. Я сейчас даже презентацию покажу – они у меня там цветами обозначены.

Первый параметр – вероятность. Второй параметр – соответственно, ущерб.

Реплика из зала: Impact, если по-английски?

Борис Вольфсон: Impact, да. То, насколько этот риск может "зарубить" ваш проект.

Если вы рассматриваете (давайте возьмем пример кадрового риска) просто уход одного из сотрудников, у вас команда большая, у него вероятность 2 можно поставить. Если у вас проект год идет, наверное, кто-то у вас сменится. Влияние на проект будет минимальным – 1. Разработчик ушел, но у вас разработчики более-менее кросс-функциональны – тогда не сильный ущерб будет.

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

Соответственно, чтобы посчитать рейтинг риска, нужно просто вероятность умножить на ущерб.

Реплика из зала: Так у нас ущерб тоже один, два, три получается?

Борис Вольфсон: Тоже один, два, три получается. Видите, это максимально просто сделано! В итоге у нас для каждого риска будет число от 1 до 9.

Вот то, о чем я рассказывал.

 (Демонстрация слайда).

Таким образом, наши риски, условно говоря, можно разделить на три категории. Есть "красные" риски (от 6 до 9) – с ними надо работать в первую очередь. У вас этот список должен быть визуализирован. В них надо вкладывать деньги, время вашей команды.

"Зеленые" риски (3-4, которые идут по диагонали) тоже надо "держать на карандаше", но они не столь критичны.

Еще есть "синие" риски. Что касается "синих" рисков (особенно со знаком 1), тут, скорее, надо подумать, стоит ли на них вообще обращать внимание, стоит ли вообще их держать в списке. Они могут просто загромождать его и не давать вам сфокусироваться на важных - "красных".

Но надо понимать, что это просто модель. "Синие" риски тоже иногда могут срабатывать.

Давайте на риски в плане аппаратного обеспечения посмотрим. У вас сервер стоит в новом хорошем дата-центре. Посчитайте, сколько вам будет стоить час или минута простоя этого сервера, и не проще ли на эти деньги купить какое-то резервное оборудование. Например, в другом дата-центре либо в этом дата-центре но с каким-то аплинком другим. Понятно, да? На эти риски тоже можно иногда посмотреть.

Мы с вами, прежде всего, сосредоточимся на "красных" рисках. Давайте для каждого риска оценим вероятность и угрозу. Поскольку нет карточек, просто пишем произведение возле каждого риска. Два умножить на три равняется шесть – шесть как-то обводим, чтобы показать, что это важное число.

Я уже говорил, что в IT риски обычно реализуются в виде ущерба. Либо денежного ущерба, либо ущерба по скорости – в зависимости от того, что вам важнее, какой у вас тип разработки.

Мы в нашей игре будем штрафоваться по деньгам. Если вы обратили внимание, у вас есть небольшая бумажка, где указан бюджет в 60000$ – это бюджет на ваш релиз, на ваш стартап. А также есть story points. Кто не знает, что такое story points? Все в курсе, да? 

Реплика из зала: Со всей команды снимаются?

Реплика из зала: Кстати, да. Тут вопрос есть. Story points отбираются у всей команды, получается?

Борис Вольфсон: Да! Смотрите. Давайте, я кратко очень расскажу про story points – у нас по Scrum-методологии не все работают. Это относительная единица измерения. Такие (более старые, что ли) названия, которые в классическом менеджменте используются – functional points (функциональные точки). Это просто некий объем функционала.

Как он измеряется? Очень просто. Мы даем команде сколько-то задач на первые несколько спринтов, оцениваем их выполнение и смотрим, на сколько этих story points команда сделала задач. Если она сделала на 6 – значит, скорость команды 6 story points, и за 6 спринтов она сделает примерно 36 story points. Очень простая схема, но, как ни странно, она обычно дает очень точные результаты, в отличие от прямого прогнозирования в человеко-часах, человеко-днях.

Давайте. У вас есть 15 минут. Я думаю, даже быстрее управимся. 20 рисков надо проранжировать. Обсудите. Здесь я предлагаю использовать не мозговой штурм, когда мы все подряд записываем, а консенсус. По каждому риску достигните консенсуса, оценивая его вероятность и ущерб, который он нанесет. 

Борис Вольфсон: Коллеги с Excel!

Реплика из зала: Мы пока заняты.

Реплика из зала: У нас пока 16.

Реплика из зала: А что, все уже?

Реплика из зала: Нет! 15.

Борис Вольфсон: Давайте, добивайте, только потихонечку. Я вам расскажу механику самой игры. Мы за 25 минут должны прогнать 5 спринтов.

(Демонстрация слайда).

Выберите человека, который хорошо пишет и считает.

Борис Вольфсон: Обратите внимание вот на такую бумажку, которая у вас есть. Это вообще делает в Scrum человек с ролью Product Owner, он подобные вещи считает. По каждому спринту есть определенная статистика. У вас есть, во-первых, бюджет – 60000$. 

За каждый спринт у вас будет отниматься определенная сумма, которую вы тратите на разработку и которую вы тратите на использование одного или нескольких мероприятий по предотвращению рисков. Вы закончили? Механика тут достаточно интересная. Вы можете сыграть одну или несколько из тех карточек, которые у вас есть. Обратите внимание. Да-да-да! 

Второе, что у вас есть – это количество оставшихся story points. Если вам слово "story point" бьет по уху, считайте 42 задачи. Задачи у вас одинаковые. А также количество сделанных story points. У вас здесь в конце должно быть 42, 0 и сумма должна быть положительной. 

Какая команда выигрывает? Та, которая первая сделает все story points. Команда, которая не успевает сделать эти 42 story points, проигрывает. Команда, которая расходует все деньги, проигрывает. Похоже на жизнь? Похоже!

Реплика из зала: Мы занимаемся только предотвращением рисков?

Борис Вольфсон: Да! Да! На меня сейчас смотрим! У меня еще есть пара слайдиков, которые это все объясняют. Так что особо волноваться не стоит.

(Демонстрация слайда).

Ребята, не гадайте. Мы первую итерацию очень медленно прогоним, минут 7, наверное, потратим.

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

Реплика из зала: Можно вопрос?

Борис Вольфсон: Да.

Реплика из зала: 42 story points – это скорость на все 6 спринтов?

Борис Вольфсон: Это объем общего. 42 задачи - это все story points.

Реплика из зала: Я понял. Теперь понятно.

Борис Вольфсон: Я рекомендую в первую итерацию сыграть одну-две карточки и посмотреть, что будет.

Реплика из зала: Только не совсем понятно, зачем нам 6 спринтов. Нам можно на все как на блок ориентироваться.

Борис Вольфсон: Зачем вам нужны 6 спринтов? Чтобы вы могли свои действия как-то скорректировать.

Реплика из зала: Я понял!

Борис Вольфсон: Посмотрите. Выберите одну карточку, сыграйте, посмотрите, что будет.

Реплика из зала: То есть у нас нет лимита карточек, грубо говоря.

Борис Вольфсон: Нет.

Реплика из зала: Почему? У нас здесь карточек больше чем на 10 story points.

Борис Вольфсон: Все выбрали одну-две карточки на первую итерацию? Нет?

Борис Вольфсон: Коллеги! Все выбрали одну-две карточки? Выберите в своей команде…

Реплика из зала: А как записывать?

Борис Вольфсон: Ничего не надо записывать. Выберите в своей команде самого счастливого человека.

Реплика из зала: Хорошо. Выбрали.

Борис Вольфсон: Ко мне идет счастливый человек. Смотрите. Так, чтобы народ тоже видел.

У меня есть вот такая колода рисков. Здесь есть одинаковые риски. Причем чем риск вероятнее (специальную комиссию собрали), тем чаще этот риск в этой колоде встречается. Тут есть одинаковые карточки. Вы каждую итерацию из колоды будете брать по одному риску. Смелее! Один! Я предлагаю в микрофон зачитать.

Реплика из зала: Регрессионная спираль смерти.

Ваши тестировщики не успевают протестировать всю функциональность предыдущих спринтов. Скорость команды падает на 2 story points. Наличие программы обучения снижает скорость команды на 1 story point.

Борис Вольфсон: По этому риску есть вопросы? Смотрите, что вам надо сделать. Вам надо скорость команды убавить. Вы не сыграли карточку, связанную с программой обучения для тестировщиков?

Реплика из зала: Нет.

Борис Вольфсон: Не сыграли. Значит, записывайте этот риск. У вас, смотрите…

Реплика из зала: Я понял! Это реальные риски, которые сейчас сработают.

Борис Вольфсон: Да-да-да! Смотрите! Это такая игра, она по функционалу похожа на "Business games", если кто-то играл, и "Манчкин" (мне почему-то сказали про него).

Смотрите, они за этот спринтделают уже не 10 story points, а, соответственно, 8.

Реплика из зала: Но только за этот?

Борис Вольфсон: Да, только за этот.

Реплика из зала: То есть в дополнение к тем карточкам, которые мы выбрали из этих, у нас еще вот это накладывается?

Борис Вольфсон: Да. Читай следующее.

Реплика из зала: А подвести может?

Борис Вольфсон: Ребята! Послушайте, какие риски бывают.

Реплика из зала: У вас фактор: один из членов команды попадает под автобус. Скорость команды падает на 2 story points до принятия нового человека. При наличии кадрового резерва риск нейтрализуется – карточка кадрового резерва играется заново. При хороших условиях труда и проведенном мероприятии по тимбилдингу риск нейтрализуется.

Борис Вольфсон: Что надо сделать, понятно? Скорость уменьшается на 2, причем постоянно, а не на спринт. Они делают теперь не 10 story points, не 10 задач закрывают, а 8. Понятно?

Реплика из зала: Понятно, но сложно.

Реплика из зала: Условия. Какие там дополнительные условия? Если проводится...

Реплика из зала: Тимбилдинг или хорошие условия труда, наличие кадрового резерва.

Реплика из зала: Если сделано именно в этом спринте?

Борис Вольфсон: Вообще если сделано.

Реплика из зала: В следующем спринте мы можем же сделать и, соответственно,…

Борис Вольфсон: Да-да-да!

Реплика из зала: Перфекционизм. Команда пишет только идеальный код. Скорость в текущем спринте уменьшается на 2. Риск нейтрализуется в случае наличия программы обучения. При проведенном мероприятии по тимбилдингу или наличии тренинга по инженерной практике скорость в текущем спринте уменьшается только на 1 story point.

Это только на текущий спринт?

Борис Вольфсон: Да! Только на текущий спринт. Там написано "на текущий спринт".

Ребята! Рассчитывайте первый спринт. Что надо посчитать? Ребята, обновляем таблицу еще раз. Сколько story points сделала каждая команда, понятно?

Реплика из зала: Как-то оно запутано.

Реплика из зала: Понятно.

Борис Вольфсон: Вам теперь надо посчитать. За первый спринт у вас на маркетинговые исследования потрачено 2 story points и на архитектуру 1 story point – всего 3. Команда делает 10. Из них мы 3 потратили – остается 7.

Реплика из зала: Минус еще 2 у нас.

Борис Вольфсон: Да. У вас увеличивается еще на два. 5 story points вы сделали. 42 – 5 = 37.

Реплика из зала: А одновременно две меры можно принять за ход?

Борис Вольфсон: Хоть все.

Реплика из зала: Хоть все?

Борис Вольфсон: Да! Сейчас, три секунды. По мерам. Можете играть произвольное количество, но в предыдущей игре две команды проиграли, потому что делали слишком много.

Реплика из зала: А сколько мы денег тратим?

Борис Вольфсон: Сейчас. Три секунды, пожалуйста.

Реплика из зала: Информация неполная.

Реплика из зала: Информацию подскажите, пожалуйста.

Борис Вольфсон: Сейчас, три секунды.

Реплика из зала: Если мы использовали какую-то карточку, это действует до конца игры?

Борис Вольфсон: Да.

Реплика из зала: А вот эти 60000$ – они входят…

Борис Вольфсон: По деньгам давайте договоримся: у нас команда стоит 9000$ за спринт.

Реплика из зала: То есть фонд туда входит?

Борис Вольфсон: 9000$ за спринт, ребята. 9000$ за спринт.

Реплика из зала: Они каждый спринт действуют?

Борис Вольфсон: Нет, не каждый. Один раз она сыграна, один раз вычли – действует все время.

Реплика из зала: Понятно. Деньги повторно не вычитаются.

Борис Вольфсон: Не вычитаются. Коллеги! Счастливых людей ко мне. Карточки рисков возвращайте, пожалуйста, чтобы баланс Вселенной не нарушить.

Реплика из зала: А вот скорость у нас падает на все итерации?

Реплика из зала: Только на одну.

Борис Вольфсон: На одну. Так, ребята! Счастливые люди, возвращайте мне, пожалуйста, риски. Команды думают, какие еще есть желание сыграть карточки. Ориентируйтесь на риски.

Реплика из зала: Мне уйти?

Борис Вольфсон: Нет-нет-нет, не уходи.

Реплика из зала: У нас команда – один человек.

Борис Вольфсон: Возвращайте, пожалуйста, риски. Читать не надо. Одну! Это второй спринт. Все, читать не надо, идите на места. Все то же самое.

Реплика из зала: На месте читать?

Борис Вольфсон: Коллеги, делайте расчет по второй итерации и ко мне подходите. Ребята, вторую итерацию рассчитываем и подходим за рисками. Ребята, подходите. Нам надо успеть, чтобы хотя бы до конца дожить. Коллеги, вы последние.

Борис Вольфсон: Давайте мы потихоньку закончим. У меня последний слайд остался. Давайте мы громко озвучим результаты команд.

Реплика из зала: 5 story points, 9000$.

Борис Вольфсон: 9000$ осталось, все сделали и? 

Реплика из зала: 5 story points.

Реплика из зала: 6 story points, 2000$ осталось – все сделали.

Борис Вольфсон: А ребята вечером доигрывать будут.

Реплика из зала: Мы все уже, доиграли. Мы уложились с запасом.

Борис Вольфсон: Какие у вас результаты?

Реплика из зала: Мы доиграли все. У нас осталось 3000$, и мы перевыполнили на 4 story points.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Илья Космодемьянский

Илья Космодемьянский

CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2.

Илья Космодемьянский говорит о резервном копировании (Backup) и восстановлении (Recovery) в самых разных системах.

Сергей Рыжиков

Сергей Рыжиков

Генеральный директор компании "1С-Битрикс"

Сергей Рыжиков ("1С-Битрикс") дает ответ на вопрос, применима ли теория мемов к эволюции CMS-систем, и выдвигает прогноз на ближайшие 5 лет.

Петр Зайцев

Петр Зайцев

Пётр Зайцев окончил МГУ им. М.В. Ломоносова, и ещё в студенческие годы являлся техническим директором проекта SpyLOG, сервиса статистики для веб-сайтов. В начале 2000-х Пётр стал сотрудником MySQL AB и возглавил группу оптимизации производительности (High Performance Group) внутри компании.

Петр Зайцев (Percona Inc) делится своим опытом оптимизации производительности с помощью архитектуры InnoDB.