Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні ...Lviv Startup Club
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні проектами
Website - https://pmday.org/online
Fb Page - https://www.facebook.com/pmdayconference
PMDay Videos -https://www.youtube.com/user/StartupLviv/featured
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Личная эффективность программиста: как сосредоточиться на работе и не забыть ...CUSTIS
Открытый семинар для студентов в компании CUSTIS (10 апреля 2014 года).
Лектор: Вячеслав Муравлев, ведущий Java-разработчик.
Аннотация: Перед разработчиком часто встает непростая задача — полностью сосредоточиться на работе, — но жизнь не стоит на месте: звонки, письма, вопросы коллег тормозят и прерывают рабочий процесс. На этом семинаре мы рассмотрим способы организации поступающей информации и ее эффективного использования (методика GTD), а также методы концентрации на выполняемых задачах, борьбы с прокрастинацией и достижения «состояния потока» (методики AutoFocus, Agile Results). В завершение встречи мы поговорим о необходимом инструментарии и попрактикуемся в применении нескольких из предложенных методов.
Видеозапись семинара: https://vimeo.com/92140248.
КАК УПРАВЛЯТЬ ДИЗАЙН-ПРОЕКТОМ (для заказчиков и исполнителей)MAL Agency
Этот материал для малого бизнеса, заказчиков, которые не понимают, как должна вестись работа дизайнерами над их проектом.
Эта презентация также для начинающих дизайнеров, которым сложно разобраться в том, как самостоятельно выстроить процесс работы над проектами.
Автор:
Макс Николаев. Генеральный директор MAL Agency
facebook.com/max.nikolaev
На примере реального использования Kanban и достигнутых результатов автор расскажет о поиске понимания, что такое эффективность на самом деле и каковы несколько простых принципов, которые ведут к ее значительному увеличению в самое короткое время. Знание этих простых принципов позволит не просто "рисовать доску", а понимать почему Kanban работает и выходить за рамки шаблонного применения.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні ...Lviv Startup Club
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні проектами
Website - https://pmday.org/online
Fb Page - https://www.facebook.com/pmdayconference
PMDay Videos -https://www.youtube.com/user/StartupLviv/featured
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Личная эффективность программиста: как сосредоточиться на работе и не забыть ...CUSTIS
Открытый семинар для студентов в компании CUSTIS (10 апреля 2014 года).
Лектор: Вячеслав Муравлев, ведущий Java-разработчик.
Аннотация: Перед разработчиком часто встает непростая задача — полностью сосредоточиться на работе, — но жизнь не стоит на месте: звонки, письма, вопросы коллег тормозят и прерывают рабочий процесс. На этом семинаре мы рассмотрим способы организации поступающей информации и ее эффективного использования (методика GTD), а также методы концентрации на выполняемых задачах, борьбы с прокрастинацией и достижения «состояния потока» (методики AutoFocus, Agile Results). В завершение встречи мы поговорим о необходимом инструментарии и попрактикуемся в применении нескольких из предложенных методов.
Видеозапись семинара: https://vimeo.com/92140248.
КАК УПРАВЛЯТЬ ДИЗАЙН-ПРОЕКТОМ (для заказчиков и исполнителей)MAL Agency
Этот материал для малого бизнеса, заказчиков, которые не понимают, как должна вестись работа дизайнерами над их проектом.
Эта презентация также для начинающих дизайнеров, которым сложно разобраться в том, как самостоятельно выстроить процесс работы над проектами.
Автор:
Макс Николаев. Генеральный директор MAL Agency
facebook.com/max.nikolaev
На примере реального использования Kanban и достигнутых результатов автор расскажет о поиске понимания, что такое эффективность на самом деле и каковы несколько простых принципов, которые ведут к ее значительному увеличению в самое короткое время. Знание этих простых принципов позволит не просто "рисовать доску", а понимать почему Kanban работает и выходить за рамки шаблонного применения.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Brand Patagonia's business strategy analysis from the begin of Chouinard's climbings till the last initiative of the company. Developed by Fabio Pelliciardi for the "Elective" final exam at EMBA course. Text in Italian.
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
СПИК 2014: Работа менджера проекта со стороны клиента с интернет-агентсвомAlexander Shulman
На основе опыта, накопленного в сотрудничестве с крупными компаниями, руководитель интернет-агентства показывает на чем нужно сосредоточиться руководителям проектов со стороны клиента
Александр Шульман, Менеджер интернет проекта со стороны клиента.SPECIA
Менеджер интернет проекта со стороны клиента
Тезисы:
Кого обычно ставят руководить проектом со стороны клиента и какие задачи перед ним ставят?
Как построить коммуникацию с коллегами?
Масштаб имеет значение, проверяем свою готовность.
Знакомство с агентством: на что смотреть и на что рассчитывать.
Скрытые возможности: что еще можно получить от совместной работы, если построить отношения и работу правильно?
Заставляем проект работать успешно вместе.
Альтернативы работе с агентством.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.Anton Stoliar
1. Цель презентации:
• Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах.
• Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт
2. Какова практическая ценность презентации для аудитории:
• Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline
• Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки.
3. Для кого предназначена:
• QA которые уже работали по Agile (Scrum в частности)
• Начинающие ПМs и QA Team Leads
• Ребята которым скоро придется лидать Agile-проекты
4. Короткий план презентации по шагам:
• Чего могут жать от работы QA команды к зависимости от специфики проекта\компании
• Чего ожидают от QA в Agile
• Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт
o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте
o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы
o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
Продуктовый дизайн в рамках подрядных отношенийArthur Arsyonov
В этой презентации рассматриваются причины явления продуктового дизайна в рамках подрядных организаций. Основные ценности в сравнении с внутренними командами. Правила перехода и ключевые проблемы в этих отношениях.
Об опыте применения jsonb в реальных проектах. Выступление на PgConf.Russia 2016etyumentcev
В докладе описан опыт построения нагруженной отказоустойчивой системы, использующей jsonb для хранения данных. В частности рассказываются механизмы, которые заменили join, транзакции, в том числе распределенные, репликации обычных SQL баз данных.
В докладе описываются основные проблемы, которые возникают при разработке проектов, и демонстрируется, что эти проблемы можно предсказать и решать с помощью математической теории, лежащей в основе языков программирования.
Большие данные: как могут навредить и ка могут помочь?etyumentcev
Большие данные — модная и быстро распространяющаяся концепция, которая позволяет нам извлекать разные полезные факты из окружающей нас информации. На конкретных примерах покажу как можно большие данные использовать, а также к каким проблемам может привести неверная интерпретация полученных результатов.
Дается математическое обоснование S.O.L.I.D принципов с помощью логики Хоара, из которого следует, что S.O.L.I.D верны не только для ООП, но и для статического полиморфизма, но и для императивного программирования вообще.
разработка серверов и серверных приложений лекция №4etyumentcev
В данной лекции рассмотрена минимальная реализация акторной модели, включающая
- отправку сообщений,
- создание новых акторов и смену поведения для приема следующего сообщения.
Исходный код реализации выложен на https://github.com/hwdtech/HWdTech.DS. Код на C#.
При разработке использовались библиотеки: Autofac, NuUnit, Moq
разработка серверов и серверных приложений лекция №3etyumentcev
В третьей главе рассматриваются базовые свойства акторов, описанные в PhD диссертации Gul Agha: каждый актор имеет адрес, большой почтовый ящик, куда доставляются сообщения, адресованные актору и поведение. В ответ на входящее сообщение актор может отправить конечный набор сообщений другим акторам и/или создать конечное число новых акторов и/или поменять свое поведение для обработки следующего сообщения.
В рамках данного курса будет разработана библиотека для разработки параллельных приложений на платформе .NET, построенная по модели акторов.
Исходные коды библиотеки будут выкладываться на GitHub: https://github.com/hwdtech/HWdTech.DS
Код библиотеки будет разработан с использованием следующих принципов, приемов и методик:
S.O.L.I.D. - принципы
Unit-tests
Mock
IoC контейнеры
Для удобства слушателей курса краткий обзор данных практик приведен в Главе 4.
разработка серверов и серверных приложений лекция №2etyumentcev
Причины потерь процессорного времени при организации последовательности вычислений внутри потока: 1. Ожидание ответа на запрос (поток спит). 2. Выполнение дополнительных "лишних" действий. Как способ устранения этих потерь - паттерн Пул потоков. Анализ императивного и функционального подхода к борьбе с "жадными" операциями. Эволюция методов организации параллельных вычислений на основе пула потоков.
высокопроизводиетльные системы без доп затратetyumentcev
Нами был разработана библиотека HWdTech.DS для разработки многопоточных и распределенных приложений на платформе .Net. Эта библиотека использует модель акторов и позволяет существенно снизить требования к квалификации программистов при построении высоконагруженных приложений.
Приводится объяснение, почему для программистов не подходят системы тайм-менеджмента. Презентация шла как сопровождение к устному выступлению, поэтому сама по себе без записи доклада, возможно, будет непонятна.
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. •
•
•
•
•
Работа почасовая – сколько хочу - столько и работаю
Слишком большой объем работы
Недопонимания в чатах
Слишком много чатов одновременно
“Антикомандное” поведение
– Участники проекта могут “подставить” друг друга
– Заказчику будут выданы противоречивые обещания от разных
участников проекта
– Повышение собственной значимости за счет занижения
самооценки других
• Синдром долгосрочного проекта
• Синдром одного заказчика