Существуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!!!
Тем не менее, задача управления творчеством во все времена была актуальна. Инвесторам, менеджерам, государству хотелось бы иметь предсказуемость на счёт того, когда будет выпущен разрабатываемый творческий продукт (будь это книга, самолёт, компьютерная программа или кинофильм).
Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.
Предположим, мы захотели открыть ресторан. По каким критериям Клиент будет оценивать его? Конечно, это кухня, дизайн и обслуживание. Обычно, наибольшее количество «глюков» происходит в процессе обслуживания, т.е. там, где велик человеческий фактор. Красивенькая молоденькая официантка вроде бы привлекает Клиентов. Но у неё испортилось настроение, и вместо доброжелательного отношения, она начинает хамить. В результате, вместо привлечения происходит отваживание Клиентов. В индустрии разработки ПО такое просто недопустимо. Необходимо, чтобы специалисты разных специальностей взаимодействовали друг с другом, а барьеры в коммуникациях и всякие субъективные вещи сводились бы к нулю. Поэтому при работе в большой интернациональной команде неформальные связи между людьми заменяются формализованными бизнес-процессами, а вместо субъективных оценок (хороший, прикольный, клёвый) используются метрики и показатели качества.
В больших проектах выгоднее купить нужного специалиста на рынке, даже если его зарплата кажется чрезмерной. При съёмках кинофильма, продюсер не учит своего сценариста писать диалоги, если тот не умеет этого делать, а просто покупает сценариста для написания диалогов на рынке. Аналогичным образом поступают при разработке приложений. Если возникает недопонимание между командами из разных стран, то одну команду отправляют в длительную командировку. При миллиардной выручке затраты на командировку не имеют значения: главное – выпустить продукт в срок.
Параметры управления
Процесс управления реальным проектом всегда основан на контроле группы параметров. Это только в школе приучают мыслить функцией от одной переменной. К сожалению, некоторые руководители перенимают школьные привычки и пытаются найти универсальное средство от управленческих проблем – этакую таблетку от всех болезней.
Пример. В одной компании, занимающейся разработкой мобильных игр, было принято выписывать задачу на карточку и помещать эту карточку на доску. Доска была разлинована несколькими вертикальными полосами. Каждая полоса соответствовала определённому состоянию задачи. Новые задачи помещались в крайне левую полосу. Затем – по мере выполнения – постепенно перемещались вправо. Главным критерием успеха руководство считало перемещение карточки на доске слева направо. Один из недостатков такого подхода – это отсутствие учёта того, что работа над задачей может быть приостановлена по ряду причин, а исполнитель может временно переключиться на другую задачу. Другой недостаток – это количество задач, над которыми ведётся работа. В нашем проекте в течение 1-го месяца нужно было выполнить 200 задач. Понятно, что разместить на доске такое количество карточек было физически невозможно.
Приведу список параметров, которые должен контролировать менеджер проекта:
1. Сроки.
2. Объём (количество полезных функций).
3. Объём работы.
4. Полезность (ценность для Потребителя).
5. Техническая и технологическая сложность.
6. Внешнее качество (с точки зрения Потребителя).
7. Внутреннее качество (с точки зрения специалиста, инженера, конструктора).
8. Риски.
9. Психологическое состояние команды.
Процессы управления
Для контроля параметров используются процессы, каждый из которых сводится к определённому набору инструментов и процедур их применения. Перечислим некоторые из процессов, которые будут рассмотрены ниже:
1. Управление задачами.
2. Управление сроками.
3. Управление качеством.
4. Управление рисками.
Управление задачами
Назначение
Оценка объёма работы и распределение задач между сотрудниками.
Система контроля задач
Цели
1. Оценить и зафиксировать объём работы.
Примечание. Сотрудники не должны выдумывать себе занятия, а заниматься задачами из заранее утверждённого списка.
Пример. На одной работе у меня был начальник, который на вопрос «К какому сроку нужно выполнить эту задачу?» — всегда давал одинаковый ответ: «Вчера». Позднее, став начальником, я убедился в том, что с программистами происходит зеркальная ситуация. Спросишь кого-нибудь: «Когда ты закончишь эту работу?» — и получаешь ответ: «Завтра к обеду. В худшем случае – к вечеру». Но проходит день, другой, а задача всё ещё не сделана. Чтобы как можно реже попадать в подобные ситуации и нужен инструмент, который подсказывает регулярно оставшийся объём работы.
2. Распределить задачи между работниками. Убедиться, что у каждого работника имеется задача, и ни один из них не простаивает.
Примечание: По данным министра экономического развития России (21.05.2012 – 24.06.2013) Андрея Белоусова производительность труда в нашей стране в 2-3 раз ниже, чем в развитых странах в зависимости от методики подсчёта (http://www.forbes.ru/kompanii/245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii).
Пример. Если вы когда-нибудь наблюдали, как происходит починка аварии на теплотрассе, то наверняка замечали, что копает яму один рабочий, а вокруг него 10 человек стоят и смотрят, как он работает.
Следует также убедиться, что сотрудники не пренебрегают одними задачами в ущерб другим.
Пример. В одном из петербургских гипермаркетов продавцы отдела сантехники предпочитают находиться рядом с итальянскими унитазами и гидромассажными ваннами, потому что премия за продажу дорогого сантехнического оборудования получается выше. Как результат, если Покупатель хочет приобрести муфту или обжим, то ему не с кем проконсультироваться. Вот так продавцы выполняют одни задачи и игнорируют другие. Получается, что сотрудники сами себе ставят или выбирают задачи, которые «вкуснее».
3. Найти зависимости между различными задачами.
Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Задача обязательно должна быть согласована с задачами других сотрудников, всего проекта или его части. Потому что, продолжая пример с рабочим, может оказаться так, что рабочий выкопал яму, получил деньги, все 10 «начальников» отчитались, а на другой день пришёл приказ яму срочно закопать, потому что именно по этой дороге поедет, например, президент. Об этом знали давно, просто «забыли» предупредить. А те, кто «копал», как обычно не уточнили параметры своей задачи… Или рабочий вырыл яму, а надо было оказывается рыть чуть шире или чуть глубже… Т.е. задача, может, и актуальна, но, при этом, не согласована или не точна.
4. Определить, какие задачи заблокированы по тем или иным причинам.
Пример. По стандартам газеты «Коммерсант» одно время материалы журналистов, рисунки художников и фотографии фотокорреспондентов нужно было сдать к 6-ти часам вечера. В редакции также присутствует специальный человек – рерайтер, задача которого заключается в том, чтобы привести все тексты под единую стилистику.
Описание
Система контроля задач может быть представлена в виде электронной таблицы.
Таблица 1. Список задач для мобильной навигационной системы GPS
| Название | Статус | Ответственный | Область | Остаточная трудоемкость (часы) |
| Добавить экран поиска перекрёстков | Новая | Иванов И.И. | Поиск адреса | 24 |
| Добавить парикмахерские в базу данных для карты России | Выполняется | Петров П.П. | Поиск мест | 8 |
| Добавить новые стили оформления карты | Завершена | Сидоров С.С. | Карта | 0 |
| Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге | Заблокирована | Дмитриев Д.Д. | Построение маршрута | 12 |
Параметры
Название описывает в краткой форме суть вносимых изменений. В идеальном случае оно должно содержать проверяемый критерий, по которому можно судить о том, выполнена задача или нет.
Примеры:
- Добавить экран поиска перекрёстков. (Примечание: Проверяемый критерий – экран. Он либо есть, либо его нет.)
- Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге. (Примечание: Проверяемый критерий – построение маршрута через кольцевую дорогу.)
Название задачи может включать в себя и название области программы (подсистемы), к которой относится задача. Это помогает при беглом взгляде на задачу понять, какому специалисту её следует поручить.
Примеры:
- База данных – Поиск мест – Добавить парикмахерские в базу данных для России. (Примечание: Задача относится сразу к двум областям: с технической точки зрения – к базе данных, потому что в неё надо внести изменения; с пользовательской точки зрения – к поиску мест, потому что в этом разделе навигационной системы можно проверить вносимое изменение.)
- Интерфейс – Карты – Добавить новые стили оформления карт. (Примечание: Эту задачу тоже можно отнести сразу к двум разделам навигационной системы: к интерфейсу пользователя, где можно выбирать стиль оформления карт, и к подсистеме визуализации карты.)
Подсистему можно указывать не только в названии задачи, но и в отдельной графе. Это позволит «подбить статистику» и оценить объём работы, относящийся к той или иной части программы.
Если различные подсистемы программы предъявляют разные требования к квалификации, знаниям и опыту работников, то такая статистика позволяет оценить потребность в соответствующих специалистах.
Для визуального представления статистики лучше всего подходит круговая диаграмма:
Рисунок 1. Объём работы над мобильной навигационной системой GPS
Статус задачи позволяет определить, какие задачи уже выполнены, какие – выполняются, и над какими задачами работа ещё не начиналась. Рекомендуется завести специальный статус, который сигнализирует о том, что задача заблокирована. Если работник устанавливает такой статус, то это означает, что выполнение задачи невозможно по тем или иным причинам.
Пример. Задача «Заменить иконки» не может быть выполнена, если художник не успел эти иконки нарисовать.
Остаточная трудоёмкость содержит актуальную оценку задачи – сколько времени ещё осталось до завершении задачи. Она даётся исполнителем в конце каждого рабочего дня. Таким образом, задача регулярно переоценивается. Это позволяет следить за прогрессом и вовремя предпринять определённые меры, если команда не поспевает к заданному сроку.
Использование
Первоначально задачи вносятся в систему контроля задач на этапе планирования проекта. Основная трудность заключается в том, что достаточно сложно предусмотреть все задачи и точно оценить время, которое займёт их выполнение.
Работу над проектом рекомендуется вести итеративно – двухнедельными или недельными итерациями. (Итеративность помогает быстро сделать некоторый законченный кусок работы и оперативно получить обратную связь.) В начале каждой итерации выполняется детальное планирование, в результате которого осуществляется выбор задач на итерацию. Если необходимо, то задачи детализируются, а их формулировки и оценки – уточняются.
ПО
Для управления задачами можно использовать готовые бесплатные или недорогие системы контроля задач:
- Электронные таблицы Excel или Google Docs
- Redmine – http://www.redmine.org
- Jira – https://www.atlassian.com/software/jira
- BugZilla — http://www.bugzilla.org
- DropTask – http://www.droptask.com
- Hansoft – http://www.hansoft.com
Сложная, «навороченная» и дорогая система управления проектом может быть заменена симбиозом Redmine и Excel.
Управление сроками
Назначение
Оценка и контроль сроков реализации проекта.
Диаграмма сгорания задач
Цели
Позволяет:
1. Оценить текущий остаточный объём работы.
Пример. Наиболее распространённый подход к управлению сроками – это контроль на глазок: «Мол, успеешь выполнить задачу к пятнице?» В наиболее яркой форме я столкнулся с таким подходом в одной российско-немецкой компании. В первый мой рабочий день владелец-немец подошёл ко мне и спросил: «У меня день рождения через три месяца. Успеете ли выпустить игру к моему дню рождения?»
2. Определить величину отставания от плана.
3. Оценить прогресс каждого сотрудника и всей команды.
Примечание. В этом случае будет семейство диаграмм.
Диаграмма
Рисунок 2. Прогресс работы сотрудника (реальный и прогнозируемый)
Описание
Для создания кривой строится вспомогательная таблица, в которой в первой графе перечисляются имена сотрудников, а в остальных графах содержится остаточный объём работы сотрудника в часах на конкретную дату.
Вместо одной цифры указываются две – сколько осталось времени реально и сколько должно было остаться по плану.
Таблица 2. Прогресс работы сотрудников
| Ф.И.О. | 31.08.14 | 01.09.14 | 02.09.14 | 03.09.14 | 04.09.14 | 05.09.14 | |
| Иванов И.И. | Реально | 38 | 32 | 28 | 20 | 14 | 8 |
| Петров П.П. | Реально | 40 | 32 | 26 | 18 | 11 | 0 |
Примечание (Антон Яковлев, программист): Описан подход, очевидно, удобный в случае использования Excel. С другими системами подход может быть другой – Hansoft такие диаграммы может генерировать самостоятельно.
Параметры
Диаграмма представляет собой две кривые. Одна из них (нарисованная пунктиром) показывает запланированное уменьшение объёма работы, т.е. то, как должно быть. Вторая кривая (нарисованная сплошной линией) представляет собой реальное изменение объёма работы. Каждая точка на этих кривых – это запланированный либо реальный объём работы, который остался на конец дня.
Использование
Кривые строятся как для каждого работника индивидуально, так и для всей команды в целом.
В конце каждого рабочего дня данные – объём оставшейся работы в часах – заносятся в таблицу. Данные берутся из графы «Остаточная трудоёмкость» таблицы задач.
Причины увеличения сроков задач анализируются и впоследствии заносятся в специальную базу знаний компании.
Управление качеством
Назначение
Обеспечение надлежащего качества продукта.
Пример. В 2013 году в России количество разводов составило 54,5% от числа зарегистрированных браков (http://womanadvice.ru/statistika-razvodov-v-rossii). Такое количество «браков» в индустрии разработки ПО просто недопустимо. Не смотря на то, что государство является заинтересованной стороной, в том, чтобы количество разводов уменьшалось, причины столь печальной статистики государством не собираются и не анализируются. А вот при разработке ПО это делается.
Крупные корпорации планируют качество продукта до начала разработки. Они не только прогнозируют количество дефектов, которое будет найдено в процессе работы над проектом, но и количество дефектов, которое так и не будет исправлено.
Пример. В одном из проектов было найдено 30 тысяч (!) дефектов. Из них 15% так и не было исправлено. Не смотря на то, что это некритические или очень редко встречающиеся ошибки, тем не менее, можно сказать, что приложение было выпущено с 4 500 ошибками.
Прогноз количества дефектов
Цели
- Оценить сложность проекта.
- Оценить ресурсы, необходимые на доводку качества.
Описание
Если приложение выпускается на регулярной основе (например, каждый год – новая версия), то прогноз разумно основывать на исторических данных. Его можно представить в виде таблицы, в которой приводится статистика по предыдущим версиям и прогнозные показатели для новой версии.
Таблица 3. Прогноз количества дефектов для мобильной навигационной системы GPS
| Область | 2013 год (реальность) | 2014 год (прогноз) |
| Пользовательский интерфейс | 243 | 250 |
| Построение маршрута | 113 | 100 |
| Поиск адреса | 53 | 50 |
| Поиск мест | 17 | 20 |
| Карта | 194 | 200 |
| Навигация | 89 | 100 |
| Аудио | 67 | 50 |
| Итого | 776 | 770 |
Параметры
В графе «Область» перечисляются подсистемы программы. Они могут быть получены путём логического деления по разным основаниям. Иногда программа делится на части с точки зрения пользователя (как в приведённой таблице). В других случаях используются технические критерии.
В среднем столбце приводятся реальные исторические данные – количество дефектов, которое было найдено в различных частях программы в предыдущей версии программы.
В последнем столбце указываются прогнозные данные – сколько дефектов будет найдено в той или иной части программы при разработке её следующей версии.
Использование
При старте проекта отдел контроля качества создаёт прогноз по багам. Во внимание принимаются исторические данные, прогнозируемый объём работы, сложность требований к новой версии приложения, а также опытность самой команды.
Прогноз даётся с разбивкой по подсистемам. Для увеличения точности используются две разные модели. Первая модель предусматривает дробление программы на подсистемы на основании различных технических критериев.
Например:
- Пользовательский интерфейс
- База данных
- Аудио
- Алгоритмы
Вторая модель предусматривает деление программы на подсистемы по пользовательским функциям.
Например:
- Рисование карты
- Построение маршрута
- Навигация
- Поиск адреса
Разные модели прогноза дополняют и проверяют друг друга.
Прогноз количества дефектов – не простая формальность, а серьёзный инструмент для планирования работы. Он помогает определить количество инженеров по качеству, которое собираются привлечь на проект. Прогноз также позволяет подсчитать время, необходимое для стабилизации программы.
Прогноз количества дефектов – достаточно консервативный инструмент. Менеджмент пересматривает его очень неохотно, потому что любой его пересмотр в сторону снижения может привести к тому, что трудновоспроизводимые ошибки не будут искаться. Предполагается, что в отсутствии надлежащего эталона, инженеры по качеству просто расслабятся и будут выполнять свою работу хуже, чем могли бы это делать.
Пример. В одном из проектов реальное количество дефектов было ниже прогнозируемого значения. Согласно статистике, инженеры по качеству не справлялись со своей работой, т.к. находили меньше ошибок, чем вытекало из прогноза. Не смотря на то, что отсутствие значительного числа дефектов было объективно обусловлено небольшим количеством реализованных требований, менеджеры опасались, что в программе имеются скрытые ошибки и поэтому долгое время не пересматривали прогноз, а предпочитали устраивать переработки в выходные дни.
План поиска дефектов
Представляет собой детальный прогноз количества дефектов с разбивкой по подсистемам и времени. Как правило, за единицу времени выбирается неделя.
Цели
- Распределить ресурсы, ответственные за контроль качества, во времени.
- Получить механизм контроля за работой инженеров по качеству.
Примечание: План поиска дефектов задаёт нормативы для всех инженеров по качеству. Он основывается на ранее сделанном прогнозе путём распределения общего числа дефектов по неделям проекта. Команда инженеров по качеству получает недельные задания – сколько дефектов в программе она должна найти в течение той или иной недели. Недельные задания можно детализировать дальше – по дням и сотрудникам. В результате, будут получены задания для каждого инженера на каждый день.
Описание
План поиска дефектов представляет собой таблицу, в которую заносят желаемые показатели результативности всей команды инженеров по качеству на каждую неделю проекта.
Таблица 4. Понедельный план поиска дефектов для мобильной навигационной системы GPS
| Область | 01.09.14 | 08.09.14 | 15.09.14 | 22.09.14 |
| Пользовательский интерфейс | 5 | 5 | 10 | 12 |
| Построение маршрута | 3 | 3 | 5 | 7 |
| Поиск адреса | 5 | 5 | 5 | 8 |
| Поиск мест | 0 | 1 | 2 | 3 |
| Карта | 3 | 5 | 7 | 8 |
| Навигация | 8 | 10 | 10 | 12 |
| Аудио | 0 | 1 | 2 | 3 |
| Итого | 24 | 30 | 41 | 53 |
Параметры
В каждой ячейке напротив названия подсистемы указывается
количество дефектов, которое будет найдено в ней в течение определённой недели.
Даты окончания недель задаются в заголовках столбцов.
Диаграмма
На основании плана строится график поиска дефектов, который представляет собой S-образную кривую.
По вертикальной оси откладывается общее количество найденных дефектов «в процентах», а по горизонтальной оси – время.
На графике также откладываются ключевые даты проекта: альфа-версия, бета-версия и финальная версия.
Рисунок 3. Графическое представление плана поиска дефектов за всё время работы над проектом
Использование
Визуально, на кривой можно выделить три этапа.
Первый этап начинается с момента старта проекта и заканчивается выпуском альфа-версии. В это время кривая растёт не так интенсивно, потому что до альфа-версии приоритет отдаётся разработке программы, а не поиску дефектов. Ещё не все требования реализованы, а то, что сделано, может быть реализовано не в полном объёме.
На втором этапе, между альфа и бета-версиями, кривая растёт весьма интенсивно. Это происходит потому, что к этому моменту практически все запланированные требования уже реализованы, и к тестированию программы подключаются дополнительные инженеры по качеству, а программисты переключаются с реализации требований на исправление дефектов.
Незадолго до бета-версии, остаётся не так много дефектов. Наиболее очевидные из них уже найдены и исправлены. Начинают проявляться неочевидные ошибки, которые сложнее находить и исправлять. Кривая замедляет свой рост. А ещё через какое-то время неочевидные ошибки тоже оказываются исправленными, и кривая перестаёт расти. В этот момент выпускается бета-версия программы. А затем – если новых ошибок не обнаруживается – выпускается финальная версия.
К моменту альфа-версии отделом тестирования должно быть найдено 30% всех дефектов. К бета-версии должно быть найдено 98% всех дефектов.
Управление рисками
Назначение
Предусмотреть риски, которые могут осложнить или сорвать проект, разработать план действий на случай срабатывания риска для нейтрализации его последствий.
Примечание: В системной инженерии существует методология «анализ видов и последствий отказов» (англ. – Failure Modes and Effects Analysis, https://ru.wikipedia.org/wiki/FMEA). Согласно стандарту министерства обороны США эта процедура проводит анализ потенциальных ошибок системы, определяет результаты их влияния как на систему в целом, так и на различные подсистемы, производит классификацию ошибок относительно их критичности.
Управление рисками похоже на анализ видов и последствий отказов: выявляются риски, оценивается их негативное влияние на проект, находятся решения для нейтрализации негативных последствий.
Реестр рисков
Цели
1. Описать выявленные риски.
Примечание: Одна из характерных проблем в ряде компаний (которые даже не распределённые, а сотрудники находятся в одном офисе) – люди не делятся опытом. Не происходит обмен информации по поводу типовых ошибок, рисков, решений. Надо вытаскивать всё это на белый свет и делать доступным для всей компании.
Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Тут даже больше: нужно описывать решение сразу (по-возможности, следует находить идеальные решения). Т.е. выявить риск мало – надо сразу думать о том, как его предотвратить. Иначе риски так и остаются «граблями».
Пример (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Перед нашим Клиентом стояла задача – разморозить оборотные средства в размере 25 млн. рублей за 1 месяц. Казалось, мы учли все риски, кроме налогов, потому что финансовый директор был в отпуске, и зная, что эта задача будет решаться, ничего не сказал. Сделали отличный план по размораживанию средств и реализовали его. В результате, налетели на налог на прибыль. Если бы данный риск был учтён, то можно было бы вырученные средства потратить для приобретения недвижимости, и, тем самым, избежать уплаты налога.
2. Оценить важность каждого риска и вероятность его срабатывания.
Пример. Риск того, что проект закроется из-за попадания метеорита в офис компании, обладает высокой важностью. Тем не менее, вероятность его срабатывания настолько низка, что безболезненно позволяет этот риск игнорировать.
Пример. Одна компания, разрабатывающая GPS-навигатор, решила сменить поставщика карт. Причина смены проста – стоимость лицензии в 2 раза ниже, а формат описания карт – тот же. Тем не менее, цена перехода на карты нового поставщика обошлась компании в 2 – 3 человека-года. Именно столько усилий было затрачено на решение возникших технических проблем.
3. Предложить план действия на случай того, если риск сработает.
Пример. При создании одной игры для маленьких девочек был серьёзный риск не уложиться в отведённые сроки. Было несколько причин у этого риска: новая команда, незнакомая платформа, для которой велась разработка, отсутствие отлаженной технологической инфраструктуры. Чтобы снизить риск, было принято решение организовать игру в виде последовательности мини-игр. Каждая такая игра была достаточно простой, не слишком сильно насыщенной графикой и другими персонажами. Кроме того, игрок был лишён свободы передвижения, т.е. мог двигаться только в заранее определённых направлениях. Это настолько упростило процесс разработки, что одна мини-игра в финальном качестве создавалась за 5 человеко-дней (имеется в виду работа инженера без учёта работы художника).
4. Распределить риски между ответственными за их устранение.
Описание
Все выявленные риски заносят в специальную таблицу, как в примере ниже.
Таблица 5. Таблица рисков для мобильной навигационной системы GPS
| Риск | Важность | Вероятность | Вес | Что делать? | Ответственный | Состояние |
| Если программисты не получат новые карты от поставщика до 15 октября, то они не будут включены в релиз | Средняя | Низкая | 2 | Связаться с поставщиком по телефону и послать напоминание по email | Сергеев А.Д. | Нужно напомнить ещё пару раз |
| Если отдел маркетинга не предоставит отзывы покупателей до 1-го сентября, то команда не сможет учесть их в очередном релизе | Высокая | Высокая | 9 | Запросить отдел маркетинга | Владимиров К.П. | Получены, находятся на сервере в папке 'Отзывы' |
Параметры
Каждый риск записывается по формуле:
Если не <будет сделано что-то> до <определённой даты>, то <произойдёт нечто негативное>.
Каждый риск следует оценить с точки зрения его важности, т.е. негативных последствий для проекта при его срабатывании. Обычно ограничиваются шкалой из трёх оценок: низкая, средняя и высокая.
Также следует оценить вероятность срабатывания риска. Для оценки тоже можно ограничиться тремя значениями: низкая, средняя и высокая.
Вес риска рассчитывается автоматически, исходя из его важности и вероятности. Для этого оценочные значения преобразуются в числовые следующим образом: значение «низкая» становится равной 1, «средняя» — 2, а «высокая» — 3. Вес рассчитывается, как произведение двух оценок. Например, если важность риска высокая и вероятность его срабатывания тоже высокая, то риск получает вес равный 9.
Использование
При ограниченных ресурсах в первую очередь следует уделять внимание рискам с наибольшим весом.
При описании риска также следует добавить план действий на случай его срабатывания или для уменьшения вероятности его срабатывания и/или его важности. Для каждого риска назначается ответственный, который отвечает за его нейтрализацию.
Заключение
- Проекты по разработке программного обеспечения бывают как индивидуальными, так и коллективными.
- Коллективные программные проекты требуют координации усилий многих людей. Нередко эти люди обладают разными специальностями, находятся в разных странах и на разных континентах и разговаривают на разных языках.
- Крупные корпорации имеют опыт по управлению достаточно большими (100 – 200 человек), интернациональными и распределёнными творческими коллективами. Этот опыт можно переосмыслить и использовать.
- Процесс управления реальным проектом основан на контроле целой группы параметров. Это только в школе учат мыслить функцией от одной переменной.
- Для контроля параметров управления рекомендуется использовать процессы управления, среди которых есть: управление задачами, управление сроками, управление качеством, управление рисками и т.д.
- Каждый из процессов управления сводится к одному или нескольким инструментам и методикам их применения. Среди инструментов есть такие: система контроля задач, диаграмма сгорания задач, прогноз количества дефектов, план поиска дефектов, реестр рисков.
Автор благодарит Василину Абу-Навас (Объединение "Практик"), И.Л. Викентьева (Система "ТРИЗ-ШАНС"), Эдуарда Галиаскарова и Антона Яковлева за помощь в подготовке статьи.
Автор: Askofen
