3. Делегирование
• Заказчики склонны требовать обещания - по срокам, по
функциональным возможностям ПО, по качеству.
• Когда старший программист выполняет проект самостоятельно, ему в
большинстве случаев легко пообещать что-то, зная что это будет
выполнено, либо внести уточнения в пожелания заказчика.
• Если старший программист делегирует задачи младшему товарищу,
то давать обещания намного сложнее. Даже в случае когда старший
программист знает как нужно выполнить требуемое от начала и до
конца.
• Если старший программист делегирует задачу и при этом в ней есть
исследовательский элемент в котором он сам не уверен, то давать
обещания по срокам и возможности выполнения очень сложно.
• Как научиться оценивать возможности своей команды?
4. Продуктивность
• Для того чтобы начать решать задачу эффективно
человеку нужно 15 минут. Это время уходит на “загрузку”
информации в мозг. Если при этом каждые 30 минут
отвлекаться на разговоры или сообщения в чате, то
эффективного рабочего времени за день получится не 8 а
4 часа.
• Нужно научиться справляться с этим, но при этом работа
не должна превратиться в каторжный труд. Общение с
коллегами приятно и поднимает настроение.
• Как соблюсти баланс?
9. Причем тут риски?
• Дилемма заключенного
• Равновесие Нэша. Тип решений игры двух и более
игроков, в котором ни один участник не может увеличить
выигрыш, изменив своё решение в одностороннем
порядке, когда другие участники не меняют решения.
10. Так все-таки причем тут
риски?
Неопределенность
Сложность
Фактическая
последовательность работ
отличается от модели плана.
Только 30% из 60000
проектов выполняются во
время.
Риски
Паралич
Близорукость
Неумение принимать решение в
Направлять усилия на устранения
условиях полной или частичной
следствий (влияние от наступления
неопределенности, неполноты,
рисков), а не на причины (источники
неточности информации.
возникновения рисков).
11. Пример из жизни программистов
1
2
3
Если проект окончен в срок, то получаем 100%
оплаты
Если проект затянулся по срокам, то
получаем 60% оплаты
Если проект завершен раньше срока,
то получаем 150% оплаты
Проект скорее всего будет провален
12. Почему так?
• Вероятность того, что проект будет закончен в срок – 30%,
а раньше – гораздо меньше.
• Чтобы закончить раньше надо отказаться от каких-то
активностей.
14. Определение риска (PMBOK)
Риск проекта – это неопределенное событие или условие,
которое будет иметь положительное или
отрицательное воздействие как минимум на одну цель
проекта (например, сроки, стоимость, содержание или
качество), если оно произойдет
Негативные риски = угрозы
Позитивные риски = благоприятные возможности
Про позитивные риски часто забывают или пускают на
самотек
15. Цель управления рисками
• Риск может быть вызван одной или несколькими
причинами и в случае возникновения может оказывать
влияние на один или несколько факторов
• Цели управления рисками – повышение вероятности
возникновения и воздействия благоприятных событий и
снижения вероятности возникновения и воздействия
неблагоприятных для проекта событий.
• Управление рисками = управление проектом ???
16. Трудности внедрения
Непрофессионализм.
Убежденность в отсутствии необходимости управлению рисками.
Недостаток времени.
Нежелание брать на себя ответственность.
Неприятие термина риск.
Сопротивление управлению рисками.
17. 5. Неприятие термина риск
• Руководство
– Говорят о рисках – значит пытаются увильнуть от работы и снять с
себя ответственность
– Отход от “Мы это обязательно сделаем”
– Потребуют времени и денег на управление рисками
• PM
– Реализация выявленного риска будет рассматриваться как ошибка
PM
• Исполнители
– Гонца принесшего дурную весть …
– Если риски не реализуются, пропадает необходимость в подвигах
19. Процесс управления рисками
Контроль
Фазы
Процесс управления рисками
начинается с:
• сбор первичной информации,
• выработка подходов к управлению.
Мониторинг
Цикл
управления
Планирование
Анализ
Идентификация
Идентификация - выявление рисков
Анализ – оценка вероятности, степень
влияния
Планирование – планы работы с
рисками
Мониторинг - отслеживание статуса
риска
Контроль – анализ эффективности
мероприятий по управлению рисками
20. Идентификация
Причинно-следственная
модель
Причина – источник риска
Условие – событие, которое уже
произошло или произойдет с
высокой вероятностью
Следствие - связанное с условием
событие, которое может произойти
в будущем
Негативный эффект – результат
влияния следствия на результаты
проекта.
•причин и следствий может быть много,
•каждое следствие может иметь несколько причин
22. Вариант решения
• Придумать какое-либо занятие, которое будет интересно
нескольким людям
• Это занятие будет нерабочим временем
23. Выявление причинноследственной связи
•
•
•
Как правило очевиден только негативный эффект
– Нет прогресса на проекте
– Требования часто меняются
– Срочные задачи
Чаще всего воздействуем на негативный эффект, вместо устранения причины
– Делать любую задачу за 1-2 дня
– Не торопиться что-либо сделать. Все равно скоро отменят.
– Запретить менять требования.
Практика ставить задачи в виде конкретных действий
– Сделать вот эту кнопочку. Завтра будет?
– Надо прописать в договоре: ТЗ менять нельзя.
24. Правило 5 почему?
• Чтобы добраться до первопричины надо задать 5 вопросов Почему?
• Низкая мотивация персонала
– Почему? Нет смысла торопиться что делать.
– Почему? Семь пятниц на неделе. Требования меняются настолько
часто, что мы не успеваем что-то сделать, как это уже никому не
нужно.
– Почему? Все время появляются новые идеи, которые просят
реализовать.
– Почему? Есть какая-то потребность у заказчика, которую он
пытается реализовать посредством разных идей.
– Почему? Потребность не выявлена нами.
25. TOP-10 рисков по Б. Боэуму
•
•
•
•
•
•
•
•
•
•
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и
оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих
окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к
проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
26. Цепочка событий и
последовательность рисков
• В модели “условие-следствие” рассматривается
последовательность из 4-х рисков
• В реальности события выстраиваются в более длинные
цепочки зависимостей
32. Стратегии реагирования на
риски
• Уклонение
Последовательность работ выстроена таким образом, что устраняет
возникновение риска
• Передача
Негативные последствия передаются другой стороне без устранения
самого риска
• Снижение
Планирование действий по снижению вероятности возникновения
самого риска и/или снижению негативного эффекта
• Принятие
– Пассивное принятие – ничего не делаем вообще
– Активное принятие – создается резерв
Бывают неустранимые риски
33. Активное принятие
• Резервы – запасы ресурсов (время, сотрудники, финансы),
добавляемые к плану проекта для эффективной работы с
рисками
• Наличие резервов – необходимое условие для
выполнения планов
• Виды резервов
– Страховой резерв (для известных, главным образом,
неустранимых рисков)
– Резерв управления (для неизвестных рисков
34. Примеры работы с рисками
• План предотвращения
– Перенос сроков обновления ПО на время после сдачи фазы
проекта
– Аналитика
– Прототипирование
• План смягчения
– Автоматизированное тестирование
– Руководство пользователя
– Методологии управления проектами
• План реагирования
– Выделение времени на поддержку проектов
– Коэффициент оптимистичности
36. Вариант решения
• Предложить план решения задачи и объяснить причины
такого решения
• Убедиться, что с предложенным вариантом “подопечный”
согласен
• Расставить контрольные точки (мониторинг + контроль)
• План “Б” (кто-то кто может сделать эту задачу)
37. Как организовать
управление рисками
•
•
•
•
•
•
Принцип ПДД
Пирамида степени автоматизации действий
Общее хранилище рисков
Форма описания (паттерн)
Выявлять риски в произошедших инцидентах
Периодически проводить обучение менеджеров на
предмет новых выявленных рисков
• Общие риски вводить в нормативные документы
39. Риски
• Во время работы над проектом Заказчик был доволен, но
после сдачи проекта он резко меняет свое мнение
• Программист затянул по срокам, потому что не знал как
решить задачу
• Мы не сможем реализовать задачу в принципе
• Неожиданно закончились задачи
• Заказчику не нравится результат нашей работы
• У студентов “неожиданно” началась сессия
• “Отличники”
• Со своим уставом в чужой монастырь
40. •
•
•
•
•
Работа почасовая – сколько хочу - столько и работаю
Слишком большой объем работы
Недопонимания в чатах
Слишком много чатов одновременно
“Антикомандное” поведение
– Участники проекта могут “подставить” друг друга
– Заказчику будут выданы противоречивые обещания от разных
участников проекта
– Повышение собственной значимости за счет занижения
самооценки других
• Синдром долгосрочного проекта
• Синдром одного заказчика
