Небольшая заметка про то, как оценивать риски при разработке продукта.
Я обожаю искать аналогии с несмежными областями, и как раз по этой теме лучшим ресурсом оказалась методичка от National Patient Safety Agency по оценке рисков для здоровья пациента. Вы можете почитать оригинал по ссылке на английском языке здесь:
http://www.nrls.npsa.nhs.uk/EasySiteWeb/getresource.axd?AssetID=60138&type=full&servicetype=Attachment
Поделюсь с вами краткой выжимкой.
Для оценки рисков надо ответить на несколько простых вопросов:
1. Что может пойти не так?
Чтобы оценить риски, нужно сначала их идентифицировать и четко описать. “Вдохновиться” можно прошлым опытом; обсуждением со стейкхолдерами; примерами из других проектов. Важно понимать, не только “что” может пойти не так, но и “почему”.
2. На кого/ на что это может повлиять? (кто/что попадет под удар?)
Здесь важно понять не только примерное число пользователей, которые могут пострадать от изменений, но и выявить группу пользователей, которые окажутся наиболее чувствительны к изменениям.
3. Насколько ужасны могут быть последствия?
4. Какова вероятность, что это случится?
5. Нужно ли что-то предпринять?
6. Кто будет ответственен за предотвращение/ решение ситуации, если она произойдет?
Посмотрите на следующую картинку - это пример матрицы, которую можно составить по параметрам Последствия/Вероятность того, что это случится.
Мы не в силах предусмотреть все, и даже при грамотной оценке рисков все равно что-то может пойти не так. Поэтому не пытайтесь "закрыть" каждую мелочь, лучше сосредоточьтесь на том, что действительно может нанести вред.
Некоторые ситуации можно предотвратить - например, если вы отрываете какую-то фунуциональность, заранее подумать о пиар-поддержке и миграции пользовательских данных. Некоторые ситуации нам неподвластны - например, болезнь разработчика. Тут мы ничего сделать не можем, но не лишним будет вспомнить про это при планировании и утверждении сроков.
Когда работаешь с одним продуктом на протяжении долгого времени, многие риски можешь оценивать сходу и довольно точно. Поэтому я составляю чеклисты для разных стадий разработки: о чем надо подумать и о чем не забыть. Подробнее про суперсилу чеклистов можно почитать в Checklist Manifesto, но если вкратце - обязательно делайте и составляйте. Экономит кучу времени, спасает от роковых ошибок ;)
Я обожаю искать аналогии с несмежными областями, и как раз по этой теме лучшим ресурсом оказалась методичка от National Patient Safety Agency по оценке рисков для здоровья пациента. Вы можете почитать оригинал по ссылке на английском языке здесь:
http://www.nrls.npsa.nhs.uk/EasySiteWeb/getresource.axd?AssetID=60138&type=full&servicetype=Attachment
Поделюсь с вами краткой выжимкой.
Для оценки рисков надо ответить на несколько простых вопросов:
1. Что может пойти не так?
Чтобы оценить риски, нужно сначала их идентифицировать и четко описать. “Вдохновиться” можно прошлым опытом; обсуждением со стейкхолдерами; примерами из других проектов. Важно понимать, не только “что” может пойти не так, но и “почему”.
2. На кого/ на что это может повлиять? (кто/что попадет под удар?)
Здесь важно понять не только примерное число пользователей, которые могут пострадать от изменений, но и выявить группу пользователей, которые окажутся наиболее чувствительны к изменениям.
3. Насколько ужасны могут быть последствия?
4. Какова вероятность, что это случится?
5. Нужно ли что-то предпринять?
6. Кто будет ответственен за предотвращение/ решение ситуации, если она произойдет?
Посмотрите на следующую картинку - это пример матрицы, которую можно составить по параметрам Последствия/Вероятность того, что это случится.
Мы не в силах предусмотреть все, и даже при грамотной оценке рисков все равно что-то может пойти не так. Поэтому не пытайтесь "закрыть" каждую мелочь, лучше сосредоточьтесь на том, что действительно может нанести вред.
Некоторые ситуации можно предотвратить - например, если вы отрываете какую-то фунуциональность, заранее подумать о пиар-поддержке и миграции пользовательских данных. Некоторые ситуации нам неподвластны - например, болезнь разработчика. Тут мы ничего сделать не можем, но не лишним будет вспомнить про это при планировании и утверждении сроков.
Когда работаешь с одним продуктом на протяжении долгого времени, многие риски можешь оценивать сходу и довольно точно. Поэтому я составляю чеклисты для разных стадий разработки: о чем надо подумать и о чем не забыть. Подробнее про суперсилу чеклистов можно почитать в Checklist Manifesto, но если вкратце - обязательно делайте и составляйте. Экономит кучу времени, спасает от роковых ошибок ;)