Доклад Владимира Дерунова на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com

1. Дерунов Владимир
Artezio
“Проект – это не спринтерская гонка, а марафон: победа
на первом отрезке еще ничего не означает”
(Дерунов В.)
Апрель 2015г.

3. • Выводы для PM:
Ключевая ошибка PM №1: РАБОТА БЕЗ ОБРАТНОЙ СВЯЗИ!
(как с Заказчиком так и со своей командой)1
Профессиональный PM должен регулярно
отрабатывать возможные внештатные ситуации,
постоянный риск-менеджмент и накопление
знаний!
2
Руководитель проектов =
Авиадиспетчер
Руководители проектов должны
регулярно (раз в 0,5г.) проходить
аттестацию на профпригодность!
3
Руководители проектов должны
проходить регулярные стажировки,
курсы повышения квалификации
4
• Выводы для компании:

4. РУКОВОДИТЕЛИ
IT-проектов –
Офицеры автоматизации

5. ЦЕЛЬ
встречи
1. Разбор реальных
проектных ситуаций
2. «Фишки» программного
инструментария РП
3. Первоклассный РП:
компетенции, навыки,
дорожная карта развития

6. Цель встречи:
Показать, обозначить для начинающих и
напомнить действующим руководителям
IT-проектов
на практических примерах базовые принципы,
правила проектной игры
Руководитель IT-проектов

8. • Базовые правила:
Нельзя выходить на проект с неподготовленной командой!
2
Нельзя выводить новичков на прямой контакт с
Заказчиком !
3
Том Круз,
«Last Samurai», 2003, Выводы:
Нельзя новичку поручать важные,
сложные, продолжительные участки.
Новичку следует поручать простые
задачи!
4
Нельзя оставлять новичка один на один!
Новичка следует прикрепить
к опытному специалисту на проекте!
5
Проект – не детский сад! Умейте во время
выводить с проекта не эффективных специалистов
«Жалеть виновных, значит предать невинных»
(Айн Рэнд)
1

9. Ключевая ошибка PM №2:
PM забывает установить сразу
при входе в проект правила
игры для своей команды
Иначе, твоя команда будет работать по принципу:
То, что не запрещено = разрешено

10. Установка правил игры:
В режиме выработки
совместных
договоренностей
либо, в отдельных
случаях
УЛЬТИМАТИВНО

12. • Базовые правила:
«Не давай обещаний, которых не сможешь сдержать»
(особенно в части озвучивания сроков Заказчику)
«Кто сильнее напоит своих
солдат, чтобы послать их на
бойню, тот и победит»
Цитата из к/ф «Хороший, плохой,
злой» (1966)
Вы обязаны обеспечить
комфортные условия работы для
свое команды
«Говори кратко, проси мало, уходи борзо!»
Петр I

13. • Базовые правила:
“Мудрый способен взять больше с глупого вопроса,
чем глупец способен взять с мудрого ответа”
(Брюс Ли)
Внимательно слушай и анализируй: что и как
говорит Заказчик и то чего он недоговаривает
“Оптимизм – это отсутствие информации”
(Фаина Раневская).
“Гораздо благороднее сознать свою ошибку, чем довести дело
до неисправимого”
(Лев Толстой).

14. • Базовые правила:
Помните о лягушке дошедшей до цели (притча)!
Ссылка: http://www.youtube.com/watch?v=HlrzDROlYZo&noredirect=1
Приняв решение не сворачивай!

15. Статистика (реальная ситуация) :
Успешные
только 36% !
Провальные
16%
Неоднозначные
48%
Статистика успешности IT-проектов
в мире за 2013г.
Источник http://iosrjournals.org/iosr-jce/papers/Vol16-issue2/Version-12/F0162122940.pdf

16. Статистика (реальная ситуация) :

17. Статистика (реальная ситуация):
Источник http://iosrjournals.org/iosr-jce/papers/Vol16-issue2/Version-12/F0162122940.pdf
0
50
100
150
200
250
300
750 млрд. $
ЗАТРАТЫ НА ИТ-ПРОЕКТЫ ПО
РАЗЛИЧНЫМ СТРАНАМ И КОНТИНЕНТАМ
МИРА ЗА 2013Г.
США ЕВРОПА АЗИЯ Остальная часть мира
США,
300 млрд. $
ЕВРОПА,
200 млрд. $
АЗИЯ,
100 млрд. $
Остальные,
150млрд. $

18. Статистика (реальная ситуация):
Источник http://project-management.zis.by/drugoe/vestibulum_iaculis.html

19. Статистика (реальная ситуация). ВЫВОДЫ:
Успешный проект
Выдержав только
треугольник
ограничений
проекта не означает
успешно завершить
проект!
Успешно
завершить один
цельный
масштабный
проект
практически не
реально !
Попасть в 36%
успешных
проектов
практически не
реально!
Дробите
проект на
подпроекты:
управляйте
Программой
проектов
Не будьте
самонадеянным
школьником:
принимая решение
о старте проекта,
просчитайте выгоды
от проекта и
параметры
эффективности
проекта
Помимо бюджета, сроков и
содержания необходимо учитывать
критерий удовлетворенности
заказчика, место проекта в пуле
всех проектах заказчика, горизонты
получения отдачи от результатов
проекта (период актуальности
результатов и эффекта от проекта)
Воронка
успешности
проекта

20. Статистика (реальная ситуация). ВЫВОДЫ:

21. Самые провальные проекты мира за последнее время:
Лас-Вегас:
отель «Harmon»
Здание было разработано в виде 48-
этажной башни с шикарным бутик-
отелем
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж

22. Самые провальные проекты мира за последнее время:
Дубай: «Мировые острова»
в 2003 году чиновники решили
создать 300 небольших островов,
чтобы потом продать каждую
«страну» состоятельному покупателю,
который сможет возвести там
собственный дворец.
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
в 2008 году
строительство
остановлено
Причины:
Финансовый кризис 2008г.
Эрозия.
Потери: £15 мрд
(только за 2009г.)

23. Самые провальные проекты мира за последнее время:
Брандербург: аэропорт «Берлин-Брандербург»
С открытием нового аэропорта
немецкие чиновники планировали
закрыть последний
функционирующий аэропорт Берлина
Берлин-Тегель, а также
расположенный в Шёнефельде
аэропорт Берлин-Шёнефельд
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж

24. Самые провальные проекты мира за последнее время:
Пекин: парк развлечений
«Wonderland»
«Wonderland» мог стать китайским аналогом Диснейленда –
великолепного тематического парка, который привлекает миллионы
посетителей с разных концов света. Но теперь заброшенный парк
напоминает скорее жуткий город-призрак на окраине Пекина, который
правительство планирует снести после 15-летней катастрофической
истории
в 1998 году
строительство
остановлено
Потери: £80 млн.

25. Самые неоднозначные проекты мира за последнее время:
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
Туннель Big Dig в Бостоне
ПЛАН:
Стоимость: 260 млн. $
Срок:2002г.
ФАКТ:
Стоимость: 14,8 мрд. $
Срок:2007г.
ПОТЕРИ:
Стоимость: 14,4 млрд. $ !
Просрочка: 5 лет
(общий срок строительства 30 лет)
окупится проект только к 2038 году.
Эффект:
это Центральная Артерия (Автомагистраль между штатами) и главное шоссе через центр города.
(Сборные секции туннеля существующих линий метро пролегают ниже пласта мерзлой земли)

26. Самые неоднозначные проекты мира за последнее время:
ЕвроТоннель под Ла-Маншем
Эффект:
Тоннель обеспечивает отличный грузопоток и
пассажиропоток между Великобританией и Францией

27. Самые неоднозначные проекты мира за последнее время:
Международная космическая станция
(МКС)
Эффект:
Одной из основных целей при создании МКС являлась возможность проведения на
станции экспериментов, требующих наличия уникальных условий космического
полёта: микрогравитации, вакуума, космических излучений, не ослабленных
земной атмосферой.

28. Эффективность и успех проекта: ПРАКТИКА

29. Эффективность и успех проекта: ПРАКТИКА

30. Практическое задание №111
- Выполнение
- Обсуждение

31. 1Выявление рисков этапа контрактования: навыки
работы с текстом Договора
1. Исходные данные:
Вы только что с поезда,
зашли в офис и Вам как РП
успевают дать на
согласование Контракт с
Заказчиком на создание и
внедрение некой
автоматизированной
системы
(текст Договора из
раздаточных материалов)
2. Задача:
Необходимо за отведенное
время выявить риск-
формулировки: т.е. выявить
формулировки, которые
содержат в себе проектные
риски, а также в целом выявить
риски предложенного Контракта
: 10 мин. на выполнение
: 5 мин. на разбор

32. Договор. Риски:
1) Чего не хватает:
ПУНКТ ГАРАНТИИ. ЧТО-ТО ВРОДЕ:
1. Гарантийный срок составляет 3 (три) календарных
месяца с даты акта Этапа 3 настоящего Договора.
Гарантия распространяется на реализованную
Исполнителем по настоящему Договору
функциональность Системы в соответствии с
Техническим заданием.
2. В случае внесения изменений в рабочую (продуктивную)
конфигурацию Системы в период действия настоящего
Договора Заказчиком или третьими лицами без
согласования с Исполнителем действие гарантии и
рассмотрение замечаний по Системе Исполнителем
прекращается.
Т.к. идет перекрытие фаз, и один из функц. кусков будет в продакте
запущен ранее завершения проекта, то необходимо закладывать
условие, что гарантия наступает раньше.
4) Не хватает: П. 2.2 : Указанная стоимость не содержит в
себе накладные расходы на выезд на удаленные объекты. В
случае возникновения необходимости выполнения работ за
пределами Москвы и Московской области, Заказчик
оплачивает фактически понесенные накладные расходы
Исполнителя ….
2) По п 4.2:
Жесткие сроки: фактически
через 2-а дня после запроса
Заказчик должен предоставить
информацию и сам запрос
всего за 5-ть дней до старта –
малый срок!
3) П.4.6:
Жесткие и не реальные сроки !
5) Главный риск: к Контракте фигурирует 10-ть
филиалов Заказчика, а по факту у Заказчика их
12-ть, а речь идет о создании
ЦЕНТРАЛИЗОВАННОЙ Автоматизированной
Системы

33. про ОШИБКИ:

34. про ОШИБКИ:
«Одна стрела попавшая в цель - это результат ста промахов»
Не бойтесь ошибаться
"Не ошибается тот, кто ничего не делает"
«За признание — прощение, за утайку — нет помилования.
Лучше грех явный, нежели тайный»
ПЕТР 1
Если совершил косяк и откат не
возможен, то ошибку нужно
признавать

35. Эффект ПЛАЦЕБО:

36. Эффект ПЛАЦЕБО:
Ложь во спасение - не лучший
вариант
«Ложь — забавная штука, проблема в том, что она не
оставляет выхода, загоняет тебя в угол, а потом
вынуждает сделать какую-то совсем тупую хрень»
Цитата из фильма «Фокус» (2015)

37. Типовая ошибка общения

38. Типовая ошибка общения
Ошибка в диалоге с заказчиком
и с командой происходит порой
не от того, что вы не сумели
донести вашу мысль, а
потому, что вы слышите не
то, что вам говорят

40. • Базовые правила:
Сумей расположить к себе Заказчика
1
Ты должен чувствовать Заказчика, думать как он.2
Внимательно наблюдай за всем
происходящим и слушай.
Умей слушать «между строк».
3
Подыгрывай Заказчику: сделай его
«хозяином» ситуации
4
Владимир Высоцкий,
«Место встречи изменить нельзя», 1979, Выводы:

41. Про стандарты проектного управления

42. Про стандарты проектного управления
«...Нам, господа, не следует увлекаться
западными образцами, не следует увлекаться
теоретическими выводами западной науки,
так как иногда на совершенно оригинальное
разрешение вопроса нас наталкивает сама
жизнь»
Петр Аркадьевич Столыпин

43. Главный артефакт

44. Главный артефакт в управлении проектами
Документ, либо
договоренности, апрув в почте
В диалогах с заказчиком возьмите за правило,
особенно в переписке опираться на
зафиксированные
документы/договоренности, а не фразы в
скайпе или слова

45. Документ - главный артефакт в разведке.
именно этот неоспоримый артефакт
становился ключевым при принятии
решения.
Аналогично и в управлении проектами
Главный артефакт в управлении проектами

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

47. «Секрет умения разговаривать красиво –
отказаться от лишних слов»
Абу Бакр

48. Завышенные оценки по CR, новым задачам
в рамках действующего проекта – это плохо
Не стоит делать неоправданно завышенных оценок.
Если по факту будет видно, что вы сделали задачу
быстрее, то отношения с заказчиком будут постепенно
только ухудшаться!

49. Новый PM проекта – находка для Заказчика

50. Уловки Заказчика
когда заказчик начинает ставить задачи напрямую твоим программистам
и др. членам твоей команды,
в обход тебя.
Это большой минус вам как PM
Это нужно пресекать сразу,
причем в «угол» ставить своих сотрудников 

51. Не работающее правило
в проектном управлении:

52. Не работающее правило
в проектном управлении:
«Хорошее начало - половина дела»
ПЛАТОН
“Проект – это не спринтерская
гонка, а марафон: победа на
первом отрезке еще ничего не
означает”
(Дерунов В.)

53. Правило ДАРТС

54. Не оставляй на завтра то,
что можно сделать сегодня
Очень часто забываем избитое, но
наиважнейшее правило:

55. Живые коммуникации гораздо
эффективнее удаленных

56. Правило «Мешок яблок»

57. Правило «Мешок яблок»
Не стоит набрасывать в пул задач
разработчику (другому специалисту
проекта из своей команды) сразу
несколько задач в очередь, а если эти
сотрудники к тому же новые сотрудники в
компании – то это категорически не
эффективно.

58. Не верь тому, кто говорит, что все под
контролем!
Всегда требуй детализацию

60. Nullius in verba (с лат. «ничьими словами») –
уже ни одно столетие гласит девиз Британского королевского общества,
основанного в 1662 году для содействия успехам естествознания,
избравшего это выражение своим девизом в знак того, что оно будет полагаться то
лько на свидетельства научных экспериментов, а не на слова авторитетов
Применительно к проектному управлению
утверждение можно интерпретировать как: все нужно
подвергать сомнению.

61. Лучшая методика разрешения конфликта
- психологическое айкидо:
уступая ты побеждаешь!

62. Уступая, ты выдерживаешь испытание,
говорят на Востоке
Уступай, чтобы ослабить сопротивление,
учат буддисты
Не борись, ибо ты неизбежно становишься тем, против
чего ты борешься
Слишком много силы приводит к обратному результату
Лучшая методика разрешения конфликта

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

65. • Базовые правила:
Bruce Lee,
«Lost» interview, 1971, Выводы:
Не стоит постоянно придерживаться одного стандарта управления
проектами (PMBok, Agile и т.д.).
Придерживаясь постоянно одного стандарта вы ограничиваете себя:
вы не развиваетесь.
1
Берите лучшее из различных
проектных практик и применяйте!
2
«Меняйся с тем, что изменяется»
Брюс Ли3

66. Правило «30 минут»

67. Правило «30 минут»
Возьмите за правило:
не стоит сразу торопиться и включаться в решение
проблемы, вопроса.
Постарайтесь выдерживать 30 минут ожидания,
и если после этого проблема не разрешена, то
приступайте.
Практика показывает, что определенная
часть всех проблем становятся не актуальной
спустя не продолжительное время

69. СТАРТОВАЯ ВСТРЕЧА проекта
Правила

70. СТАРТОВАЯ ВСТРЕЧА проекта
Правила:

71. СТАРТОВАЯ ВСТРЕЧА проекта
Правила:
«Куан Ча» - взглянуть на противника
и извлечь как можно больше
информации
(одна из техник Ниндзя)

72. Практическое задание №212
- Выполнение
- Обсуждение

73. 2
Действия в случае досрочного завершения проекта
по инициативе Заказчика
1. Исходные данные:
Вы как РП ведете некий проект автоматизации
для Заказчика. Проект изначально
планировался в режиме FIX-задач, но вот уже
3-ью неделю от старта проекта ваши
разработчики выполняют проектные задачи в
режиме T&M разработки, но поступающие
задачи тем не менее в виде общих
формулировок без установки и согласования
каких-либо плановых сроков задачи
фиксируются заказчиком в среде jira. И на этой
3-ей неделе проекта в пятницу PM Заказчика
по тел. сообщает Вам, что задачи для нас
закончились и к сожалению они вынуждены
завершить проект. При этом Заказчик, согласно
условиям Договора извещает нас за неделю до
события (до завершения проекта), т.е.
последний день работ проекта будет – пятница
след. недели. Заказчик в заключении разговора
вас спрашивает: ок?
2. Задача:
Необходимо за отведенное
время указать ваши
дальнейшие действия в
части корректного
завершения проекта и
выявить возможные
ошибочные действия

74. Корректные
действия PM:
(в хронолог. порядке) 2. Незамедлительно сообщить
новость своему руководству и
параллельно попросить PM
Заказчика продублировать его
уведомление о завершении проекта в
почту с копией на ваше руководство
– зафиксировав тем самым дату и
время офиц. заявления
1. В телефонном разговоре с
Заказчиком ничего не обещать,
сказать лишь, вам необходимо
проанализировать текущую ситуацию,
сообщить руководству и чуть позже
вы дадите официальный ответ
3. Дождавшись поступления письма
от Заказчика вы должны
незамедлительно пообщаться с
командой на предмет определения
текущего пула задач проекта:
количество и прогноз по срокам их
завершения. Цель: выяснить есть ли
риск того, что выполнение какой-либо
задачи потребует больше времени
чем озвученная дата завершения
проекта
4. Сообщаете итоги анализа своему
руководству. Пишите офиц. ответ Заказчику в
почту с изложением итогов анализа: либо
отвечаете «ок», либо, «ок», но только по
таким-то задачам, указав например, что для
выполнения задачи №х потребуется больше
времени и вы не готовы ее завершить в
указанный срок (далее в таком случае вам
необходимо обязательно определить и
зафиксировать в почте договоренности
касаемо действий по этим риск-задачам)

75. Ошибочные
действия PM:
1. Вы не добились дублирования Заказчиком
сообщения в почту с копией на ваше
руководство.
Может при этом сложится такая ситуация, что вы
вспомнили и добились получения от заказчика
подтверждения в почту, но оно пришло только в
понедельник днем, к тому времени вы уже даже
провели анализ задач текущего пула с командой
по итогам которого риск-задач не установлено, но
при этом вы не озвучили команде причину вашего
запроса (не озвучив, что заказчик обратился с
инициативой через неделю завершить проект). И
не проведя актуализацию текущего пула в
понедельник вы отвечаете Заказчику «ок», но
позже вяснилось, что в пятницу вечером заказчик
оформил в пул новую задачу, которая потребует
для выполнения времени более чем плановая
дата завершения проекта
2. Вы посчитали, что неделя –
довольно продолжительный срок и в
пятницу под вечер нет необходимости
тревожить и вводить в панику
команду проекта, решив сообщить им
об этом в понедельник-вторник. И при
этом заказчику в тел. либо самое
страшное в почте уже ответили «ок»

76. • Базовые правила:
Требуя с других - требуй с себя!
Пиши письма кратко!
(правило одного абзаца)
Никогда не суди о том, чего сам не видел
Не нужно сразу начинать подготовку коммерческого предложения на
основании материалов, которые были предоставлены твоим
руководством.
Необходимо в первую очередь добиваться прямого выхода на
заказчика и всех заинтересованных сторон и уточнить постановку
задачи.

77. Искажение руководителем проекта информации
предоставляемой своему руководству – это одна из форм
проявления не профессионализма.
Если обратиться к мемуарам великих разведчиков, то
искажение информации – это грубейшая, порой
фатальная ошибка как в карьере профессионального
разведчика, так и для самого дела.
ИСКАЖЕНИЕ предоставляемой
информации руководству – грубейшая
ошибка PM
порой фатальная как для проекта так и для
компании

78. Практическое задание №313
- Выполнение
- Обсуждение

79. 3
Действия в случае конфликтной ситуации на проекте
и возможен останов проекта
1. Исходные данные:
Вы как РП ведете некий проект автоматизации по внедрению некой
программы базирующейся на компонентах внешней (3-ей компании) для
Заказчика. Требования к Системе зафиксированы в ТП (техническом
проекте). Вы прошли фазу реализации и началась опытная
эксплуатация системы на тестовых данных с участием ключевых
функциональных заказчиков. В ходе которой, функц. заказчик одного из
ключевых подразделений компании через PM Заказчика доносит до вас
требование без реализации которого функц. Заказчик отказывается
принимать систему. Требование это по сути доработка, которая никак не
зафиксирована в ТП. В тоже время на проекте возникает другая
ситуация: в ходе опытно экспл. выявлены проблемы
производительности и интерфейсного плана, без устранения которых
Заказчика также не готов принять систему. С большой долей
достоверности установлено, что причина этих проблем – внутри базовых
внешних компонент, устранение которых собственными силами
практически не реально (по крайне мере – весьма затратно),
привлечение 3-ей стороны (разработчика этих компонент) для их
оперативного устранения – дело долгое и не факт, что будет результат.
Проект приостановлен. Заказчик ждет решения сложившейся ситуации и
способа разрешения от нас, либо разрыв – контракта.
2. Задача:
Необходимо за отведенное
время указать ваши
дальнейшие действия в
части выхода из
сложившейся ситуации для
возможности дальнейшего
продолжения проекта с
минимальными потерями

80. Решение:
БАРТЕР:
вы выполняете для Заказчика новые требования
функц. заказчика, Заказчик – снимает свои
замечания по производительности и интерфейсу

82. СТРАТЕГИЧЕСКАЯ ошибка PM
При принятии решения по своему проекту
ты должен учитывать влияние этого
решения на другие проекты компании
Заказчика!

83. Компетенции первоклассного IT PM

84. 0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
КОМПЕТЕНЦИИ ПЕРВОКЛАССНОГО IT PM В
НАШИ ДНИ

85. «Гораздо труднее увидеть проблему, чем ее решение.
Для первого нужно воображение, а для второго лишь
умение»
Джон Бернал
(английский физик и социолог науки, общественный деятель )
Умение увидеть проблему на ранних этапах -
одно из ключевых качеств
профессионального PM

86. Профессиональный PM =
Перфекционист
человек, стремящийся к совершенству

87. Внутреннее
спокойствие
Предвидение
мер
воздействия на
события
Умение
подходить к
проблеме с
разных точек
зрения
Готовность к
любым
неожиданным
событиям
Умение
понять
других
Умение
извлекать
положительный
опыт из всего
происходящегоВыдержка
Качества PM = Качества Ниндзя
Качества PM = Качества Разведчика

88. оставаться спокойным и
уверенным в стрессовых
ситуациях
способностью выбирать
необходимую информацию из
большого объема сообщений
уметь анализировать ситуацию
и адаптивно применять
установленные правиладолжен обладать хорошей
оперативной памятью
Качества PM = Качества Авиадиспетчера
быть инициативным и
самостоятельным
уметь прогнозировать
«воздушную» обстановку

89. Компетенции первоклассного IT PM
пути достижения

90. 1. Привычка замечать: помните, что вы никогда не сможете узнать,
что думают другие!
(не стоит додумывать за заказчика)
2.Умейте быть недвусмысленным, это может вызвать не доверие
3.Умейте быть разным! не нужно придерживаться одного характера,
умейте отказываться от непродуктивных решений, не нужно идти по
шаблону
4.Умейте разбивать сложные задачи на мелкие
5.Используйте с пользой достигнутый опыт, делайте обязательно ревью
6.Умейте четко осознавать потребности: свои, проекта, Заказчика,
команды
7.Необходимо уметь вести диалог. Это искусство, которому нужно учиться

91. Источники:
Стандарты проектного управления
(PMBok, Agile и др.)
Сертификация PMI
Лучшая адвокатская практика: фильмы, книги
Разведчики: фильмы, книги, мемуары
Читайте книги, статьи из других областей (не IT)
Читайте классику
Детективы (мировая классика жанра, не попса):
фильмы, книги (чем больше тем лучше)
Изучайте материалы по искусству ведения войны
(тактика и стратегия великих сражений)

92. Способы:
Развивайте навыки дедуктивного и
индуктивного способов рассуждений
Развивайте технику внимания и
запоминания

93. Способы:
Ходите на собеседования
(даже если вы уже работаете)

94. Полезные программные
«фишки»:

95. 1. Полезный free JIRA-плагин для автоматизации
контроля согласований задач проекта:
Один из вариантов применения: Сокращение простев (временных
интервалов) в ходе бизнес-процесса согласования задач на оценку
(CR, Tasks) за счет автоматического контроля наступления/не
наступления необходимого события по данной задаче (изменения
некого реквизита, ответственного, статуса и т.п.) через
установленный промежуток времени с автоматическим оповещением
соответствующего сотрудника

96. 1. Полезный free JIRA-плагин для автоматизации
контроля согласований задач проекта:
Плагин доступен по ссылке:
https://marketplace.atlassian.com/plugins/com.atlassian.plugin.aut
omation.jira-automation-plugin;
Это универсальный плагин-планировщик в jira покрывающий
все необходимые задачи автоматического контроля.
2-а основных режима плагина:
Реагирование на некое событие (при изменении некого
поля в задачах по установленному заранее фильтру
система может автоматически присвоить некое значение
другому нужному полю + отправить уведомление).
Режим планировщика: опрос задач по установленному
фильтру через заданный промежуток времени с
реагированием;
(настройки интервала опроса весьма универсальны, help по
ссылкам: http://www.quartz-scheduler.org/documentation/quartz-
1.x/tutorials/crontrigger http://quartz-
scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-06)

97. 2. Полезная free программа для подготовки эффектный
презентаций проекта:
https://prezi.com

98. 3. Полезная free программа для совместной подготовки
Project-плана:

99. Gantter for Google Drive это:

100. Как это выглядит:

101. Возможности продукта
• Удобный, понятный интерфейс
• Оптимальный базовый набор функций MS Project
• Возможность создания неограниченного количества
базовых планов (в MS Project ограничение на 10 базовых
планов): простой в использовании удобный механизм –
позволяет визуально представить все отклонения от
предыдущей версии плана – удобно и востребовано в случаях
например подготовки оценок по задачам – сохранение
версионности + визуализация расхождений
• Наглядное представление объема выполненных работ
как по вложенной задаче так и в целом по корневой:

102. Возможности продукта
• Удобный визуальный функционал выбора задач-
предшественников:

103. Возможности продукта
• Возможность прикрепления url-ссылки к задаче
(например можно разместить ссылку на задачу в jira):

104. Возможности продукта
• Ведение ресурсов по задаче:

105. Возможности продукта
• Учет рисков по задаче и в целом по проекту:

106. Возможности продукта
• Возможность фильтрации задач по ресурсу (удобно):

107. Возможности продукта
• Отображение критических задач:

108. Возможности продукта
• Возможность скрытия завершенных задач (удобно):

109. Возможности продукта
• Учет трудозатрат и % завершения:

110. Возможности продукта
«Фишки» инструмента:
• импорт/экспорт проекта из/в Google Docs, Google
Drive или MS Project
• экспортировать вехи проекта в iCalendar
• печать в PDF, HTML, PNG

111. Возможности продукта
Gantter имеет простой и доступный для
освоения интерфейс даже для тех, кто
только получил базовые знания по
планированию!

112. Возможности применения продукта
• Подготовка оценок (внутренних и внешних);
• Roadmap проекта;
• Для внутреннего контроля и планирования работ по
команде (доступность и прозрачность планов работ по
команде для всех участников в on-line);
• При подготовке оценок и контроля, планирования самих
работ по кросс-командным работам (тимлиды разных
команд могут одновременно корректировать планы по
задаче в рамках своей зоны ответственности)

113. Как установить:
1. Под своей учетной записью
заходим на гугл-диск,
нажимаем «Создать» и
«Подключить другие
приложения»
2. Находим и выбираем:

114. Как установить (далее):
Далее – все просто: нажимаем
«Создать» и выбираем уже
установленное приложение:

115. Совместный доступ:
Все просто:

116. Совместный доступ:

117. Работа других участников с созданным
вами проектом:
1. Получить от вас ссылку на проект;
2. Иметь учетную запись на гугл
3. Единожды создать (зайти) на гугл-диск своей учетной
записи в гугл
4. Чтобы проект по ссылке переданной вам открылся
необходимо до момента ее открытия в браузере иметь
ваш открытый сеанс на гугл
5. В момент открытия ссылки проекта система вас спросит:
«Открыть с помощью или скачать», необходимо выбрать
«Открыть с помощью» и выбрать «Gantter…»!

118. «1 час планирования
экономит 200 часов
переделок»
Barry Boehm.

119. Спасибо за внимание
Дерунов Владимир
Artezio
skype: Artezio_vderunov_1
vk: http://vk.com/vaderunoff
e-mail: vaderunoff@yandex.ru
Удачи на проектах!