SlideShare a Scribd company logo
Дерунов Владимир
Artezio
“Проект – это не спринтерская гонка, а марафон: победа
на первом отрезке еще ничего не означает”
(Дерунов В.)
Апрель 2015г.
Руководитель IT-проектов: практические стратaгемы для начинающих
• Выводы для PM:
Ключевая ошибка PM №1: РАБОТА БЕЗ ОБРАТНОЙ СВЯЗИ!
(как с Заказчиком так и со своей командой)1
Профессиональный PM должен регулярно
отрабатывать возможные внештатные ситуации,
постоянный риск-менеджмент и накопление
знаний!
2
Руководитель проектов =
Авиадиспетчер
Руководители проектов должны
регулярно (раз в 0,5г.) проходить
аттестацию на профпригодность!
3
Руководители проектов должны
проходить регулярные стажировки,
курсы повышения квалификации
4
• Выводы для компании:
РУКОВОДИТЕЛИ
IT-проектов –
Офицеры автоматизации
ЦЕЛЬ
встречи
1. Разбор реальных
проектных ситуаций
2. «Фишки» программного
инструментария РП
3. Первоклассный РП:
компетенции, навыки,
дорожная карта развития
Цель встречи:
Показать, обозначить для начинающих и
напомнить действующим руководителям
IT-проектов
на практических примерах базовые принципы,
правила проектной игры
Руководитель IT-проектов
Руководитель IT-проектов: практические стратaгемы для начинающих
• Базовые правила:
Нельзя выходить на проект с неподготовленной командой!
2
Нельзя выводить новичков на прямой контакт с
Заказчиком !
3
Том Круз,
«Last Samurai», 2003, Выводы:
Нельзя новичку поручать важные,
сложные, продолжительные участки.
Новичку следует поручать простые
задачи!
4
Нельзя оставлять новичка один на один!
Новичка следует прикрепить
к опытному специалисту на проекте!
5
Проект – не детский сад! Умейте во время
выводить с проекта не эффективных специалистов
«Жалеть виновных, значит предать невинных»
(Айн Рэнд)
1
Ключевая ошибка PM №2:
PM забывает установить сразу
при входе в проект правила
игры для своей команды
Иначе, твоя команда будет работать по принципу:
То, что не запрещено = разрешено
Установка правил игры:
В режиме выработки
совместных
договоренностей
либо, в отдельных
случаях
УЛЬТИМАТИВНО
Руководитель IT-проектов: практические стратaгемы для начинающих
• Базовые правила:
«Не давай обещаний, которых не сможешь сдержать»
(особенно в части озвучивания сроков Заказчику)
«Кто сильнее напоит своих
солдат, чтобы послать их на
бойню, тот и победит»
Цитата из к/ф «Хороший, плохой,
злой» (1966)
Вы обязаны обеспечить
комфортные условия работы для
свое команды
«Говори кратко, проси мало, уходи борзо!»
Петр I
• Базовые правила:
“Мудрый способен взять больше с глупого вопроса,
чем глупец способен взять с мудрого ответа”
(Брюс Ли)
Внимательно слушай и анализируй: что и как
говорит Заказчик и то чего он недоговаривает
“Оптимизм – это отсутствие информации”
(Фаина Раневская).
“Гораздо благороднее сознать свою ошибку, чем довести дело
до неисправимого”
(Лев Толстой).
• Базовые правила:
Помните о лягушке дошедшей до цели (притча)!
Ссылка: http://www.youtube.com/watch?v=HlrzDROlYZo&noredirect=1
Приняв решение не сворачивай!
Статистика (реальная ситуация) :
Успешные
только 36% !
Провальные
16%
Неоднозначные
48%
Статистика успешности IT-проектов
в мире за 2013г.
Источник http://iosrjournals.org/iosr-jce/papers/Vol16-issue2/Version-12/F0162122940.pdf
Статистика (реальная ситуация) :
Статистика (реальная ситуация):
Источник 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млрд. $
Статистика (реальная ситуация):
Источник http://project-management.zis.by/drugoe/vestibulum_iaculis.html
Статистика (реальная ситуация). ВЫВОДЫ:
Успешный проект
Выдержав только
треугольник
ограничений
проекта не означает
успешно завершить
проект!
Успешно
завершить один
цельный
масштабный
проект
практически не
реально !
Попасть в 36%
успешных
проектов
практически не
реально!
Дробите
проект на
подпроекты:
управляйте
Программой
проектов
Не будьте
самонадеянным
школьником:
принимая решение
о старте проекта,
просчитайте выгоды
от проекта и
параметры
эффективности
проекта
Помимо бюджета, сроков и
содержания необходимо учитывать
критерий удовлетворенности
заказчика, место проекта в пуле
всех проектах заказчика, горизонты
получения отдачи от результатов
проекта (период актуальности
результатов и эффекта от проекта)
Воронка
успешности
проекта
Статистика (реальная ситуация). ВЫВОДЫ:
Самые провальные проекты мира за последнее время:
Лас-Вегас:
отель «Harmon»
Здание было разработано в виде 48-
этажной башни с шикарным бутик-
отелем
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
Самые провальные проекты мира за последнее время:
Дубай: «Мировые острова»
в 2003 году чиновники решили
создать 300 небольших островов,
чтобы потом продать каждую
«страну» состоятельному покупателю,
который сможет возвести там
собственный дворец.
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
в 2008 году
строительство
остановлено
Причины:
Финансовый кризис 2008г.
Эрозия.
Потери: £15 мрд
(только за 2009г.)
Самые провальные проекты мира за последнее время:
Брандербург: аэропорт «Берлин-Брандербург»
С открытием нового аэропорта
немецкие чиновники планировали
закрыть последний
функционирующий аэропорт Берлина
Берлин-Тегель, а также
расположенный в Шёнефельде
аэропорт Берлин-Шёнефельд
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
Самые провальные проекты мира за последнее время:
Пекин: парк развлечений
«Wonderland»
«Wonderland» мог стать китайским аналогом Диснейленда –
великолепного тематического парка, который привлекает миллионы
посетителей с разных концов света. Но теперь заброшенный парк
напоминает скорее жуткий город-призрак на окраине Пекина, который
правительство планирует снести после 15-летней катастрофической
истории
в 1998 году
строительство
остановлено
Потери: £80 млн.
Самые неоднозначные проекты мира за последнее время:
в 2008 году
строительство
остановлено
Причина:
обнаружение серьёзных
строительных дефектов
Потери: £261 млн.:
компенсация ущерба + демонтаж
Туннель Big Dig в Бостоне
ПЛАН:
Стоимость: 260 млн. $
Срок:2002г.
ФАКТ:
Стоимость: 14,8 мрд. $
Срок:2007г.
ПОТЕРИ:
Стоимость: 14,4 млрд. $ !
Просрочка: 5 лет
(общий срок строительства 30 лет)
окупится проект только к 2038 году.
Эффект:
это Центральная Артерия (Автомагистраль между штатами) и главное шоссе через центр города.
(Сборные секции туннеля существующих линий метро пролегают ниже пласта мерзлой земли)
Самые неоднозначные проекты мира за последнее время:
ЕвроТоннель под Ла-Маншем
Эффект:
Тоннель обеспечивает отличный грузопоток и
пассажиропоток между Великобританией и Францией
Самые неоднозначные проекты мира за последнее время:
Международная космическая станция
(МКС)
Эффект:
Одной из основных целей при создании МКС являлась возможность проведения на
станции экспериментов, требующих наличия уникальных условий космического
полёта: микрогравитации, вакуума, космических излучений, не ослабленных
земной атмосферой.
Эффективность и успех проекта: ПРАКТИКА
Эффективность и успех проекта: ПРАКТИКА
Практическое задание №111
- Выполнение
- Обсуждение
1Выявление рисков этапа контрактования: навыки
работы с текстом Договора
1. Исходные данные:
Вы только что с поезда,
зашли в офис и Вам как РП
успевают дать на
согласование Контракт с
Заказчиком на создание и
внедрение некой
автоматизированной
системы
(текст Договора из
раздаточных материалов)
2. Задача:
Необходимо за отведенное
время выявить риск-
формулировки: т.е. выявить
формулировки, которые
содержат в себе проектные
риски, а также в целом выявить
риски предложенного Контракта
: 10 мин. на выполнение
: 5 мин. на разбор
Договор. Риски:
1) Чего не хватает:
ПУНКТ ГАРАНТИИ. ЧТО-ТО ВРОДЕ:
1. Гарантийный срок составляет 3 (три) календарных
месяца с даты акта Этапа 3 настоящего Договора.
Гарантия распространяется на реализованную
Исполнителем по настоящему Договору
функциональность Системы в соответствии с
Техническим заданием.
2. В случае внесения изменений в рабочую (продуктивную)
конфигурацию Системы в период действия настоящего
Договора Заказчиком или третьими лицами без
согласования с Исполнителем действие гарантии и
рассмотрение замечаний по Системе Исполнителем
прекращается.
Т.к. идет перекрытие фаз, и один из функц. кусков будет в продакте
запущен ранее завершения проекта, то необходимо закладывать
условие, что гарантия наступает раньше.
4) Не хватает: П. 2.2 : Указанная стоимость не содержит в
себе накладные расходы на выезд на удаленные объекты. В
случае возникновения необходимости выполнения работ за
пределами Москвы и Московской области, Заказчик
оплачивает фактически понесенные накладные расходы
Исполнителя ….
2) По п 4.2:
Жесткие сроки: фактически
через 2-а дня после запроса
Заказчик должен предоставить
информацию и сам запрос
всего за 5-ть дней до старта –
малый срок!
3) П.4.6:
Жесткие и не реальные сроки !
5) Главный риск: к Контракте фигурирует 10-ть
филиалов Заказчика, а по факту у Заказчика их
12-ть, а речь идет о создании
ЦЕНТРАЛИЗОВАННОЙ Автоматизированной
Системы
про ОШИБКИ:
про ОШИБКИ:
«Одна стрела попавшая в цель - это результат ста промахов»
Не бойтесь ошибаться
"Не ошибается тот, кто ничего не делает"
«За признание — прощение, за утайку — нет помилования.
Лучше грех явный, нежели тайный»
ПЕТР 1
Если совершил косяк и откат не
возможен, то ошибку нужно
признавать
Эффект ПЛАЦЕБО:
Эффект ПЛАЦЕБО:
Ложь во спасение - не лучший
вариант
«Ложь — забавная штука, проблема в том, что она не
оставляет выхода, загоняет тебя в угол, а потом
вынуждает сделать какую-то совсем тупую хрень»
Цитата из фильма «Фокус» (2015)
Типовая ошибка общения
Типовая ошибка общения
Ошибка в диалоге с заказчиком
и с командой происходит порой
не от того, что вы не сумели
донести вашу мысль, а
потому, что вы слышите не
то, что вам говорят
Руководитель IT-проектов: практические стратaгемы для начинающих
• Базовые правила:
Сумей расположить к себе Заказчика
1
Ты должен чувствовать Заказчика, думать как он.2
Внимательно наблюдай за всем
происходящим и слушай.
Умей слушать «между строк».
3
Подыгрывай Заказчику: сделай его
«хозяином» ситуации
4
Владимир Высоцкий,
«Место встречи изменить нельзя», 1979, Выводы:
Про стандарты проектного управления
Про стандарты проектного управления
«...Нам, господа, не следует увлекаться
западными образцами, не следует увлекаться
теоретическими выводами западной науки,
так как иногда на совершенно оригинальное
разрешение вопроса нас наталкивает сама
жизнь»
Петр Аркадьевич Столыпин
Главный артефакт
Главный артефакт в управлении проектами
Документ, либо
договоренности, апрув в почте
В диалогах с заказчиком возьмите за правило,
особенно в переписке опираться на
зафиксированные
документы/договоренности, а не фразы в
скайпе или слова
Документ - главный артефакт в разведке.
именно этот неоспоримый артефакт
становился ключевым при принятии
решения.
Аналогично и в управлении проектами
Главный артефакт в управлении проектами
Делегируйте, не держите задачи на себе,
сбрасывайте их с себя как экипаж самолета
при экстренной посадке
У летчиков есть термин: максимальная посадочная масса –
это максимальная масса, которую выдержит шасси при посадке
«Секрет умения разговаривать красиво –
отказаться от лишних слов»
Абу Бакр
Завышенные оценки по CR, новым задачам
в рамках действующего проекта – это плохо
Не стоит делать неоправданно завышенных оценок.
Если по факту будет видно, что вы сделали задачу
быстрее, то отношения с заказчиком будут постепенно
только ухудшаться!
Новый PM проекта – находка для Заказчика
Уловки Заказчика
когда заказчик начинает ставить задачи напрямую твоим программистам
и др. членам твоей команды,
в обход тебя.
Это большой минус вам как PM
Это нужно пресекать сразу,
причем в «угол» ставить своих сотрудников 
Не работающее правило
в проектном управлении:
Не работающее правило
в проектном управлении:
«Хорошее начало - половина дела»
ПЛАТОН
“Проект – это не спринтерская
гонка, а марафон: победа на
первом отрезке еще ничего не
означает”
(Дерунов В.)
Правило ДАРТС
Не оставляй на завтра то,
что можно сделать сегодня
Очень часто забываем избитое, но
наиважнейшее правило:
Живые коммуникации гораздо
эффективнее удаленных
Правило «Мешок яблок»
Правило «Мешок яблок»
Не стоит набрасывать в пул задач
разработчику (другому специалисту
проекта из своей команды) сразу
несколько задач в очередь, а если эти
сотрудники к тому же новые сотрудники в
компании – то это категорически не
эффективно.
Не верь тому, кто говорит, что все под
контролем!
Всегда требуй детализацию
Руководитель IT-проектов: практические стратaгемы для начинающих
Nullius in verba (с лат. «ничьими словами») –
уже ни одно столетие гласит девиз Британского королевского общества,
основанного в 1662 году для содействия успехам естествознания,
избравшего это выражение своим девизом в знак того, что оно будет полагаться то
лько на свидетельства научных экспериментов, а не на слова авторитетов
Применительно к проектному управлению
утверждение можно интерпретировать как: все нужно
подвергать сомнению.
Лучшая методика разрешения конфликта
- психологическое айкидо:
уступая ты побеждаешь!
Уступая, ты выдерживаешь испытание,
говорят на Востоке
Уступай, чтобы ослабить сопротивление,
учат буддисты
Не борись, ибо ты неизбежно становишься тем, против
чего ты борешься
Слишком много силы приводит к обратному результату
Лучшая методика разрешения конфликта
Вы не следуете сразу в разрез мнения вашего оппонента, а
присоединяетесь к нему, по типу "я тебя понимаю,
принимаю..., теперь и ты меня послушай и пойми...", и уже
после, переходите к своим убедительным доводам,
аргументам
Результат - ваше превосходство в расстановке новых
позиций, приоритетов, уважение, укрепление отношений и
главное - никакого конфликтного, напрягающего,
раздражающего общения...
Лучшая методика разрешения конфликта
Руководитель IT-проектов: практические стратaгемы для начинающих
• Базовые правила:
Bruce Lee,
«Lost» interview, 1971, Выводы:
Не стоит постоянно придерживаться одного стандарта управления
проектами (PMBok, Agile и т.д.).
Придерживаясь постоянно одного стандарта вы ограничиваете себя:
вы не развиваетесь.
1
Берите лучшее из различных
проектных практик и применяйте!
2
«Меняйся с тем, что изменяется»
Брюс Ли3
Правило «30 минут»
Правило «30 минут»
Возьмите за правило:
не стоит сразу торопиться и включаться в решение
проблемы, вопроса.
Постарайтесь выдерживать 30 минут ожидания,
и если после этого проблема не разрешена, то
приступайте.
Практика показывает, что определенная
часть всех проблем становятся не актуальной
спустя не продолжительное время
Руководитель IT-проектов: практические стратaгемы для начинающих
СТАРТОВАЯ ВСТРЕЧА проекта
Правила
СТАРТОВАЯ ВСТРЕЧА проекта
Правила:
СТАРТОВАЯ ВСТРЕЧА проекта
Правила:
«Куан Ча» - взглянуть на противника
и извлечь как можно больше
информации
(одна из техник Ниндзя)
Практическое задание №212
- Выполнение
- Обсуждение
2
Действия в случае досрочного завершения проекта
по инициативе Заказчика
1. Исходные данные:
Вы как РП ведете некий проект автоматизации
для Заказчика. Проект изначально
планировался в режиме FIX-задач, но вот уже
3-ью неделю от старта проекта ваши
разработчики выполняют проектные задачи в
режиме T&M разработки, но поступающие
задачи тем не менее в виде общих
формулировок без установки и согласования
каких-либо плановых сроков задачи
фиксируются заказчиком в среде jira. И на этой
3-ей неделе проекта в пятницу PM Заказчика
по тел. сообщает Вам, что задачи для нас
закончились и к сожалению они вынуждены
завершить проект. При этом Заказчик, согласно
условиям Договора извещает нас за неделю до
события (до завершения проекта), т.е.
последний день работ проекта будет – пятница
след. недели. Заказчик в заключении разговора
вас спрашивает: ок?
2. Задача:
Необходимо за отведенное
время указать ваши
дальнейшие действия в
части корректного
завершения проекта и
выявить возможные
ошибочные действия
Корректные
действия PM:
(в хронолог. порядке) 2. Незамедлительно сообщить
новость своему руководству и
параллельно попросить PM
Заказчика продублировать его
уведомление о завершении проекта в
почту с копией на ваше руководство
– зафиксировав тем самым дату и
время офиц. заявления
1. В телефонном разговоре с
Заказчиком ничего не обещать,
сказать лишь, вам необходимо
проанализировать текущую ситуацию,
сообщить руководству и чуть позже
вы дадите официальный ответ
3. Дождавшись поступления письма
от Заказчика вы должны
незамедлительно пообщаться с
командой на предмет определения
текущего пула задач проекта:
количество и прогноз по срокам их
завершения. Цель: выяснить есть ли
риск того, что выполнение какой-либо
задачи потребует больше времени
чем озвученная дата завершения
проекта
4. Сообщаете итоги анализа своему
руководству. Пишите офиц. ответ Заказчику в
почту с изложением итогов анализа: либо
отвечаете «ок», либо, «ок», но только по
таким-то задачам, указав например, что для
выполнения задачи №х потребуется больше
времени и вы не готовы ее завершить в
указанный срок (далее в таком случае вам
необходимо обязательно определить и
зафиксировать в почте договоренности
касаемо действий по этим риск-задачам)
Ошибочные
действия PM:
1. Вы не добились дублирования Заказчиком
сообщения в почту с копией на ваше
руководство.
Может при этом сложится такая ситуация, что вы
вспомнили и добились получения от заказчика
подтверждения в почту, но оно пришло только в
понедельник днем, к тому времени вы уже даже
провели анализ задач текущего пула с командой
по итогам которого риск-задач не установлено, но
при этом вы не озвучили команде причину вашего
запроса (не озвучив, что заказчик обратился с
инициативой через неделю завершить проект). И
не проведя актуализацию текущего пула в
понедельник вы отвечаете Заказчику «ок», но
позже вяснилось, что в пятницу вечером заказчик
оформил в пул новую задачу, которая потребует
для выполнения времени более чем плановая
дата завершения проекта
2. Вы посчитали, что неделя –
довольно продолжительный срок и в
пятницу под вечер нет необходимости
тревожить и вводить в панику
команду проекта, решив сообщить им
об этом в понедельник-вторник. И при
этом заказчику в тел. либо самое
страшное в почте уже ответили «ок»
• Базовые правила:
Требуя с других - требуй с себя!
Пиши письма кратко!
(правило одного абзаца)
Никогда не суди о том, чего сам не видел
Не нужно сразу начинать подготовку коммерческого предложения на
основании материалов, которые были предоставлены твоим
руководством.
Необходимо в первую очередь добиваться прямого выхода на
заказчика и всех заинтересованных сторон и уточнить постановку
задачи.
Искажение руководителем проекта информации
предоставляемой своему руководству – это одна из форм
проявления не профессионализма.
Если обратиться к мемуарам великих разведчиков, то
искажение информации – это грубейшая, порой
фатальная ошибка как в карьере профессионального
разведчика, так и для самого дела.
ИСКАЖЕНИЕ предоставляемой
информации руководству – грубейшая
ошибка PM
порой фатальная как для проекта так и для
компании
Практическое задание №313
- Выполнение
- Обсуждение
3
Действия в случае конфликтной ситуации на проекте
и возможен останов проекта
1. Исходные данные:
Вы как РП ведете некий проект автоматизации по внедрению некой
программы базирующейся на компонентах внешней (3-ей компании) для
Заказчика. Требования к Системе зафиксированы в ТП (техническом
проекте). Вы прошли фазу реализации и началась опытная
эксплуатация системы на тестовых данных с участием ключевых
функциональных заказчиков. В ходе которой, функц. заказчик одного из
ключевых подразделений компании через PM Заказчика доносит до вас
требование без реализации которого функц. Заказчик отказывается
принимать систему. Требование это по сути доработка, которая никак не
зафиксирована в ТП. В тоже время на проекте возникает другая
ситуация: в ходе опытно экспл. выявлены проблемы
производительности и интерфейсного плана, без устранения которых
Заказчика также не готов принять систему. С большой долей
достоверности установлено, что причина этих проблем – внутри базовых
внешних компонент, устранение которых собственными силами
практически не реально (по крайне мере – весьма затратно),
привлечение 3-ей стороны (разработчика этих компонент) для их
оперативного устранения – дело долгое и не факт, что будет результат.
Проект приостановлен. Заказчик ждет решения сложившейся ситуации и
способа разрешения от нас, либо разрыв – контракта.
2. Задача:
Необходимо за отведенное
время указать ваши
дальнейшие действия в
части выхода из
сложившейся ситуации для
возможности дальнейшего
продолжения проекта с
минимальными потерями
Решение:
БАРТЕР:
вы выполняете для Заказчика новые требования
функц. заказчика, Заказчик – снимает свои
замечания по производительности и интерфейсу
Руководитель IT-проектов: практические стратaгемы для начинающих
СТРАТЕГИЧЕСКАЯ ошибка PM
При принятии решения по своему проекту
ты должен учитывать влияние этого
решения на другие проекты компании
Заказчика!
Компетенции первоклассного IT PM
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
КОМПЕТЕНЦИИ ПЕРВОКЛАССНОГО IT PM В
НАШИ ДНИ
«Гораздо труднее увидеть проблему, чем ее решение.
Для первого нужно воображение, а для второго лишь
умение»
Джон Бернал
(английский физик и социолог науки, общественный деятель )
Умение увидеть проблему на ранних этапах -
одно из ключевых качеств
профессионального PM
Профессиональный PM =
Перфекционист
человек, стремящийся к совершенству
Внутреннее
спокойствие
Предвидение
мер
воздействия на
события
Умение
подходить к
проблеме с
разных точек
зрения
Готовность к
любым
неожиданным
событиям
Умение
понять
других
Умение
извлекать
положительный
опыт из всего
происходящегоВыдержка
Качества PM = Качества Ниндзя
Качества PM = Качества Разведчика
оставаться спокойным и
уверенным в стрессовых
ситуациях
способностью выбирать
необходимую информацию из
большого объема сообщений
уметь анализировать ситуацию
и адаптивно применять
установленные правиладолжен обладать хорошей
оперативной памятью
Качества PM = Качества Авиадиспетчера
быть инициативным и
самостоятельным
уметь прогнозировать
«воздушную» обстановку
Компетенции первоклассного IT PM
пути достижения
1. Привычка замечать: помните, что вы никогда не сможете узнать,
что думают другие!
(не стоит додумывать за заказчика)
2.Умейте быть недвусмысленным, это может вызвать не доверие
3.Умейте быть разным! не нужно придерживаться одного характера,
умейте отказываться от непродуктивных решений, не нужно идти по
шаблону
4.Умейте разбивать сложные задачи на мелкие
5.Используйте с пользой достигнутый опыт, делайте обязательно ревью
6.Умейте четко осознавать потребности: свои, проекта, Заказчика,
команды
7.Необходимо уметь вести диалог. Это искусство, которому нужно учиться
Источники:
Стандарты проектного управления
(PMBok, Agile и др.)
Сертификация PMI
Лучшая адвокатская практика: фильмы, книги
Разведчики: фильмы, книги, мемуары
Читайте книги, статьи из других областей (не IT)
Читайте классику
Детективы (мировая классика жанра, не попса):
фильмы, книги (чем больше тем лучше)
Изучайте материалы по искусству ведения войны
(тактика и стратегия великих сражений)
Способы:
Развивайте навыки дедуктивного и
индуктивного способов рассуждений
Развивайте технику внимания и
запоминания
Способы:
Ходите на собеседования
(даже если вы уже работаете)
Полезные программные
«фишки»:
1. Полезный free JIRA-плагин для автоматизации
контроля согласований задач проекта:
Один из вариантов применения: Сокращение простев (временных
интервалов) в ходе бизнес-процесса согласования задач на оценку
(CR, Tasks) за счет автоматического контроля наступления/не
наступления необходимого события по данной задаче (изменения
некого реквизита, ответственного, статуса и т.п.) через
установленный промежуток времени с автоматическим оповещением
соответствующего сотрудника
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)
2. Полезная free программа для подготовки эффектный
презентаций проекта:
https://prezi.com
3. Полезная free программа для совместной подготовки
Project-плана:
Gantter for Google Drive это:
Как это выглядит:
Возможности продукта
• Удобный, понятный интерфейс
• Оптимальный базовый набор функций MS Project
• Возможность создания неограниченного количества
базовых планов (в MS Project ограничение на 10 базовых
планов): простой в использовании удобный механизм –
позволяет визуально представить все отклонения от
предыдущей версии плана – удобно и востребовано в случаях
например подготовки оценок по задачам – сохранение
версионности + визуализация расхождений
• Наглядное представление объема выполненных работ
как по вложенной задаче так и в целом по корневой:
Возможности продукта
• Удобный визуальный функционал выбора задач-
предшественников:
Возможности продукта
• Возможность прикрепления url-ссылки к задаче
(например можно разместить ссылку на задачу в jira):
Возможности продукта
• Ведение ресурсов по задаче:
Возможности продукта
• Учет рисков по задаче и в целом по проекту:
Возможности продукта
• Возможность фильтрации задач по ресурсу (удобно):
Возможности продукта
• Отображение критических задач:
Возможности продукта
• Возможность скрытия завершенных задач (удобно):
Возможности продукта
• Учет трудозатрат и % завершения:
Возможности продукта
«Фишки» инструмента:
• импорт/экспорт проекта из/в Google Docs, Google
Drive или MS Project
• экспортировать вехи проекта в iCalendar
• печать в PDF, HTML, PNG
Возможности продукта
Gantter имеет простой и доступный для
освоения интерфейс даже для тех, кто
только получил базовые знания по
планированию!
Возможности применения продукта
• Подготовка оценок (внутренних и внешних);
• Roadmap проекта;
• Для внутреннего контроля и планирования работ по
команде (доступность и прозрачность планов работ по
команде для всех участников в on-line);
• При подготовке оценок и контроля, планирования самих
работ по кросс-командным работам (тимлиды разных
команд могут одновременно корректировать планы по
задаче в рамках своей зоны ответственности)
Как установить:
1. Под своей учетной записью
заходим на гугл-диск,
нажимаем «Создать» и
«Подключить другие
приложения»
2. Находим и выбираем:
Как установить (далее):
Далее – все просто: нажимаем
«Создать» и выбираем уже
установленное приложение:
Совместный доступ:
Все просто:
Совместный доступ:
Работа других участников с созданным
вами проектом:
1. Получить от вас ссылку на проект;
2. Иметь учетную запись на гугл
3. Единожды создать (зайти) на гугл-диск своей учетной
записи в гугл
4. Чтобы проект по ссылке переданной вам открылся
необходимо до момента ее открытия в браузере иметь
ваш открытый сеанс на гугл
5. В момент открытия ссылки проекта система вас спросит:
«Открыть с помощью или скачать», необходимо выбрать
«Открыть с помощью» и выбрать «Gantter…»!
«1 час планирования
экономит 200 часов
переделок»
Barry Boehm.
Спасибо за внимание
Дерунов Владимир
Artezio
skype: Artezio_vderunov_1
vk: http://vk.com/vaderunoff
e-mail: vaderunoff@yandex.ru
Удачи на проектах!

More Related Content

Viewers also liked

PM competenies-pmcd model
PM competenies-pmcd modelPM competenies-pmcd model
PM competenies-pmcd model
Danil Dintsis, Ph. D., PgMP
 
Organizational Change management 2015 (Управление организационными изменениями)
Organizational Change management 2015 (Управление организационными изменениями)Organizational Change management 2015 (Управление организационными изменениями)
Organizational Change management 2015 (Управление организационными изменениями)
Danil Dintsis, Ph. D., PgMP
 
Презентация интернет - проекта Workle
Презентация интернет - проекта WorkleПрезентация интернет - проекта Workle
Презентация интернет - проекта Workle
Alexander Mityanin
 
Методики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалистаМетодики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалиста
Danil Dintsis, Ph. D., PgMP
 
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
Pavel Cherkashin
 
POPAPP
POPAPPPOPAPP
POPAPP
500 Startups
 
Manpacks
ManpacksManpacks
Manpacks
500 Startups
 

Viewers also liked (8)

PM competenies-pmcd model
PM competenies-pmcd modelPM competenies-pmcd model
PM competenies-pmcd model
 
Organizational Change management 2015 (Управление организационными изменениями)
Organizational Change management 2015 (Управление организационными изменениями)Organizational Change management 2015 (Управление организационными изменениями)
Organizational Change management 2015 (Управление организационными изменениями)
 
Презентация интернет - проекта Workle
Презентация интернет - проекта WorkleПрезентация интернет - проекта Workle
Презентация интернет - проекта Workle
 
Методики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалистаМетодики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалиста
 
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
Пример презентации для защиты ИТ проекта в компании (Sample Business Case)
 
POPAPP
POPAPPPOPAPP
POPAPP
 
Pingbox presentation
Pingbox presentationPingbox presentation
Pingbox presentation
 
Manpacks
ManpacksManpacks
Manpacks
 

Similar to Руководитель IT-проектов: практические стратaгемы для начинающих

gigaGantt презентация развёрнутая
gigaGantt презентация развёрнутаяgigaGantt презентация развёрнутая
gigaGantt презентация развёрнутая
Даниил Ромашов
 
семинар по цтт_v.8.1_ag
семинар по цтт_v.8.1_agсеминар по цтт_v.8.1_ag
семинар по цтт_v.8.1_ag
Alexey Gostomelsky
 
Проектное управление для финансовых профессионалов. Внедрение ERP
Проектное управление для финансовых профессионалов. Внедрение ERPПроектное управление для финансовых профессионалов. Внедрение ERP
Проектное управление для финансовых профессионалов. Внедрение ERP
Tatiana Gavrilyuk, CPA, PMP, ACCA, CertIoD
 
фонд поддержки интернет инициатив
фонд поддержки интернет инициативфонд поддержки интернет инициатив
фонд поддержки интернет инициатив
LAZOVOY
 
Тенденции развития проектного управления в России
Тенденции развития проектного управления в России Тенденции развития проектного управления в России
Тенденции развития проектного управления в России
ProjectPractice2013
 
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІй
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІйХто створює програмне забезпечення? Огляд сучасних ІТ-професІй
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІй
LutskITCluster
 
Цифровая трансформация - без цензуры
Цифровая трансформация - без цензурыЦифровая трансформация - без цензуры
Цифровая трансформация - без цензуры
Natalia Andreeva
 
Как капля здравого смысла может спасти проект внедрения СЭД?
Как капля здравого смысла может спасти проект внедрения СЭД?Как капля здравого смысла может спасти проект внедрения СЭД?
Как капля здравого смысла может спасти проект внедрения СЭД?
DocTrix Product Line
 
14 project-mistakes
14 project-mistakes14 project-mistakes
14 project-mistakes
Максим Неверов
 
Operating through the “eyes” of development: Efficient communications
Operating through the “eyes” of development: Efficient communicationsOperating through the “eyes” of development: Efficient communications
Operating through the “eyes” of development: Efficient communications
DevGAMM Conference
 
FabMarker for IT Park
FabMarker for IT ParkFabMarker for IT Park
FabMarker for IT Park
Paul Serikov
 
innoperm конкурс НИОКР - предложения Экат
innoperm конкурс НИОКР - предложения Экатinnoperm конкурс НИОКР - предложения Экат
innoperm конкурс НИОКР - предложения Экат
Andrey Mushchinkin
 
Цифрова трансформація при виході на зарубіжні ринки
Цифрова трансформація при виході на зарубіжні ринкиЦифрова трансформація при виході на зарубіжні ринки
Цифрова трансформація при виході на зарубіжні ринки
APPAU_Ukraine
 
Презентация 8bitМechanic
Презентация 8bitМechanicПрезентация 8bitМechanic
Презентация 8bitМechanic
Daniel Abelski
 
Алферов - Роль бизнес заказчика 2012
Алферов - Роль бизнес заказчика 2012Алферов - Роль бизнес заказчика 2012
Алферов - Роль бизнес заказчика 2012
Sergey Polazhenko
 
Коммерциализация инноваций
Коммерциализация инновацийКоммерциализация инноваций
Коммерциализация инноваций
dusmikeev
 
Коммерциализация научных разработок или где есть деньги?
Коммерциализация научных разработок или где есть деньги?Коммерциализация научных разработок или где есть деньги?
Коммерциализация научных разработок или где есть деньги?
Sciencehit.by
 
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
Ministry of Digital Transformation
 
Dmitry Zavalishin. Successful it-project - where can it fail
Dmitry Zavalishin. Successful it-project - where can it failDmitry Zavalishin. Successful it-project - where can it fail
Dmitry Zavalishin. Successful it-project - where can it fail
Andrew Mayorov
 

Similar to Руководитель IT-проектов: практические стратaгемы для начинающих (20)

gigaGantt презентация развёрнутая
gigaGantt презентация развёрнутаяgigaGantt презентация развёрнутая
gigaGantt презентация развёрнутая
 
семинар по цтт_v.8.1_ag
семинар по цтт_v.8.1_agсеминар по цтт_v.8.1_ag
семинар по цтт_v.8.1_ag
 
Проектное управление для финансовых профессионалов. Внедрение ERP
Проектное управление для финансовых профессионалов. Внедрение ERPПроектное управление для финансовых профессионалов. Внедрение ERP
Проектное управление для финансовых профессионалов. Внедрение ERP
 
фонд поддержки интернет инициатив
фонд поддержки интернет инициативфонд поддержки интернет инициатив
фонд поддержки интернет инициатив
 
Тенденции развития проектного управления в России
Тенденции развития проектного управления в России Тенденции развития проектного управления в России
Тенденции развития проектного управления в России
 
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІй
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІйХто створює програмне забезпечення? Огляд сучасних ІТ-професІй
Хто створює програмне забезпечення? Огляд сучасних ІТ-професІй
 
Цифровая трансформация - без цензуры
Цифровая трансформация - без цензурыЦифровая трансформация - без цензуры
Цифровая трансформация - без цензуры
 
Как капля здравого смысла может спасти проект внедрения СЭД?
Как капля здравого смысла может спасти проект внедрения СЭД?Как капля здравого смысла может спасти проект внедрения СЭД?
Как капля здравого смысла может спасти проект внедрения СЭД?
 
14 project-mistakes
14 project-mistakes14 project-mistakes
14 project-mistakes
 
Operating through the “eyes” of development: Efficient communications
Operating through the “eyes” of development: Efficient communicationsOperating through the “eyes” of development: Efficient communications
Operating through the “eyes” of development: Efficient communications
 
FabMarker for IT Park
FabMarker for IT ParkFabMarker for IT Park
FabMarker for IT Park
 
innoperm конкурс НИОКР - предложения Экат
innoperm конкурс НИОКР - предложения Экатinnoperm конкурс НИОКР - предложения Экат
innoperm конкурс НИОКР - предложения Экат
 
Цифрова трансформація при виході на зарубіжні ринки
Цифрова трансформація при виході на зарубіжні ринкиЦифрова трансформація при виході на зарубіжні ринки
Цифрова трансформація при виході на зарубіжні ринки
 
Презентация 8bitМechanic
Презентация 8bitМechanicПрезентация 8bitМechanic
Презентация 8bitМechanic
 
OnlineLot
OnlineLotOnlineLot
OnlineLot
 
Алферов - Роль бизнес заказчика 2012
Алферов - Роль бизнес заказчика 2012Алферов - Роль бизнес заказчика 2012
Алферов - Роль бизнес заказчика 2012
 
Коммерциализация инноваций
Коммерциализация инновацийКоммерциализация инноваций
Коммерциализация инноваций
 
Коммерциализация научных разработок или где есть деньги?
Коммерциализация научных разработок или где есть деньги?Коммерциализация научных разработок или где есть деньги?
Коммерциализация научных разработок или где есть деньги?
 
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
[Ad4Digital] Константин Коптелов "CRM - ключевой фундамент отдела продаж. Как...
 
Dmitry Zavalishin. Successful it-project - where can it fail
Dmitry Zavalishin. Successful it-project - where can it failDmitry Zavalishin. Successful it-project - where can it fail
Dmitry Zavalishin. Successful it-project - where can it fail
 

More from SQALab

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
SQALab
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
SQALab
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
SQALab
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
SQALab
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
SQALab
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
SQALab
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
SQALab
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
SQALab
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
SQALab
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
SQALab
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
SQALab
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
SQALab
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
SQALab
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
SQALab
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
SQALab
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
SQALab
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
SQALab
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
SQALab
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
SQALab
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
SQALab
 

More from SQALab (20)

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 

Руководитель IT-проектов: практические стратaгемы для начинающих

  • 1. Дерунов Владимир Artezio “Проект – это не спринтерская гонка, а марафон: победа на первом отрезке еще ничего не означает” (Дерунов В.) Апрель 2015г.
  • 3. • Выводы для PM: Ключевая ошибка PM №1: РАБОТА БЕЗ ОБРАТНОЙ СВЯЗИ! (как с Заказчиком так и со своей командой)1 Профессиональный PM должен регулярно отрабатывать возможные внештатные ситуации, постоянный риск-менеджмент и накопление знаний! 2 Руководитель проектов = Авиадиспетчер Руководители проектов должны регулярно (раз в 0,5г.) проходить аттестацию на профпригодность! 3 Руководители проектов должны проходить регулярные стажировки, курсы повышения квалификации 4 • Выводы для компании:
  • 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
  • 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% успешных проектов практически не реально! Дробите проект на подпроекты: управляйте Программой проектов Не будьте самонадеянным школьником: принимая решение о старте проекта, просчитайте выгоды от проекта и параметры эффективности проекта Помимо бюджета, сроков и содержания необходимо учитывать критерий удовлетворенности заказчика, место проекта в пуле всех проектах заказчика, горизонты получения отдачи от результатов проекта (период актуальности результатов и эффекта от проекта) Воронка успешности проекта
  • 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-ть, а речь идет о создании ЦЕНТРАЛИЗОВАННОЙ Автоматизированной Системы
  • 34. про ОШИБКИ: «Одна стрела попавшая в цель - это результат ста промахов» Не бойтесь ошибаться "Не ошибается тот, кто ничего не делает" «За признание — прощение, за утайку — нет помилования. Лучше грех явный, нежели тайный» ПЕТР 1 Если совершил косяк и откат не возможен, то ошибку нужно признавать
  • 36. Эффект ПЛАЦЕБО: Ложь во спасение - не лучший вариант «Ложь — забавная штука, проблема в том, что она не оставляет выхода, загоняет тебя в угол, а потом вынуждает сделать какую-то совсем тупую хрень» Цитата из фильма «Фокус» (2015)
  • 38. Типовая ошибка общения Ошибка в диалоге с заказчиком и с командой происходит порой не от того, что вы не сумели донести вашу мысль, а потому, что вы слышите не то, что вам говорят
  • 40. • Базовые правила: Сумей расположить к себе Заказчика 1 Ты должен чувствовать Заказчика, думать как он.2 Внимательно наблюдай за всем происходящим и слушай. Умей слушать «между строк». 3 Подыгрывай Заказчику: сделай его «хозяином» ситуации 4 Владимир Высоцкий, «Место встречи изменить нельзя», 1979, Выводы:
  • 42. Про стандарты проектного управления «...Нам, господа, не следует увлекаться западными образцами, не следует увлекаться теоретическими выводами западной науки, так как иногда на совершенно оригинальное разрешение вопроса нас наталкивает сама жизнь» Петр Аркадьевич Столыпин
  • 44. Главный артефакт в управлении проектами Документ, либо договоренности, апрув в почте В диалогах с заказчиком возьмите за правило, особенно в переписке опираться на зафиксированные документы/договоренности, а не фразы в скайпе или слова
  • 45. Документ - главный артефакт в разведке. именно этот неоспоримый артефакт становился ключевым при принятии решения. Аналогично и в управлении проектами Главный артефакт в управлении проектами
  • 46. Делегируйте, не держите задачи на себе, сбрасывайте их с себя как экипаж самолета при экстренной посадке У летчиков есть термин: максимальная посадочная масса – это максимальная масса, которую выдержит шасси при посадке
  • 47. «Секрет умения разговаривать красиво – отказаться от лишних слов» Абу Бакр
  • 48. Завышенные оценки по CR, новым задачам в рамках действующего проекта – это плохо Не стоит делать неоправданно завышенных оценок. Если по факту будет видно, что вы сделали задачу быстрее, то отношения с заказчиком будут постепенно только ухудшаться!
  • 49. Новый PM проекта – находка для Заказчика
  • 50. Уловки Заказчика когда заказчик начинает ставить задачи напрямую твоим программистам и др. членам твоей команды, в обход тебя. Это большой минус вам как PM Это нужно пресекать сразу, причем в «угол» ставить своих сотрудников 
  • 51. Не работающее правило в проектном управлении:
  • 52. Не работающее правило в проектном управлении: «Хорошее начало - половина дела» ПЛАТОН “Проект – это не спринтерская гонка, а марафон: победа на первом отрезке еще ничего не означает” (Дерунов В.)
  • 54. Не оставляй на завтра то, что можно сделать сегодня Очень часто забываем избитое, но наиважнейшее правило:
  • 57. Правило «Мешок яблок» Не стоит набрасывать в пул задач разработчику (другому специалисту проекта из своей команды) сразу несколько задач в очередь, а если эти сотрудники к тому же новые сотрудники в компании – то это категорически не эффективно.
  • 58. Не верь тому, кто говорит, что все под контролем! Всегда требуй детализацию
  • 60. Nullius in verba (с лат. «ничьими словами») – уже ни одно столетие гласит девиз Британского королевского общества, основанного в 1662 году для содействия успехам естествознания, избравшего это выражение своим девизом в знак того, что оно будет полагаться то лько на свидетельства научных экспериментов, а не на слова авторитетов Применительно к проектному управлению утверждение можно интерпретировать как: все нужно подвергать сомнению.
  • 61. Лучшая методика разрешения конфликта - психологическое айкидо: уступая ты побеждаешь!
  • 62. Уступая, ты выдерживаешь испытание, говорят на Востоке Уступай, чтобы ослабить сопротивление, учат буддисты Не борись, ибо ты неизбежно становишься тем, против чего ты борешься Слишком много силы приводит к обратному результату Лучшая методика разрешения конфликта
  • 63. Вы не следуете сразу в разрез мнения вашего оппонента, а присоединяетесь к нему, по типу "я тебя понимаю, принимаю..., теперь и ты меня послушай и пойми...", и уже после, переходите к своим убедительным доводам, аргументам Результат - ваше превосходство в расстановке новых позиций, приоритетов, уважение, укрепление отношений и главное - никакого конфликтного, напрягающего, раздражающего общения... Лучшая методика разрешения конфликта
  • 65. • Базовые правила: Bruce Lee, «Lost» interview, 1971, Выводы: Не стоит постоянно придерживаться одного стандарта управления проектами (PMBok, Agile и т.д.). Придерживаясь постоянно одного стандарта вы ограничиваете себя: вы не развиваетесь. 1 Берите лучшее из различных проектных практик и применяйте! 2 «Меняйся с тем, что изменяется» Брюс Ли3
  • 67. Правило «30 минут» Возьмите за правило: не стоит сразу торопиться и включаться в решение проблемы, вопроса. Постарайтесь выдерживать 30 минут ожидания, и если после этого проблема не разрешена, то приступайте. Практика показывает, что определенная часть всех проблем становятся не актуальной спустя не продолжительное время
  • 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 При принятии решения по своему проекту ты должен учитывать влияние этого решения на другие проекты компании Заказчика!
  • 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. Способы: Развивайте навыки дедуктивного и индуктивного способов рассуждений Развивайте технику внимания и запоминания
  • 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 это:
  • 101. Возможности продукта • Удобный, понятный интерфейс • Оптимальный базовый набор функций MS Project • Возможность создания неограниченного количества базовых планов (в MS Project ограничение на 10 базовых планов): простой в использовании удобный механизм – позволяет визуально представить все отклонения от предыдущей версии плана – удобно и востребовано в случаях например подготовки оценок по задачам – сохранение версионности + визуализация расхождений • Наглядное представление объема выполненных работ как по вложенной задаче так и в целом по корневой:
  • 102. Возможности продукта • Удобный визуальный функционал выбора задач- предшественников:
  • 103. Возможности продукта • Возможность прикрепления url-ссылки к задаче (например можно разместить ссылку на задачу в jira):
  • 104. Возможности продукта • Ведение ресурсов по задаче:
  • 105. Возможности продукта • Учет рисков по задаче и в целом по проекту:
  • 106. Возможности продукта • Возможность фильтрации задач по ресурсу (удобно):
  • 108. Возможности продукта • Возможность скрытия завершенных задач (удобно):
  • 109. Возможности продукта • Учет трудозатрат и % завершения:
  • 110. Возможности продукта «Фишки» инструмента: • импорт/экспорт проекта из/в Google Docs, Google Drive или MS Project • экспортировать вехи проекта в iCalendar • печать в PDF, HTML, PNG
  • 111. Возможности продукта Gantter имеет простой и доступный для освоения интерфейс даже для тех, кто только получил базовые знания по планированию!
  • 112. Возможности применения продукта • Подготовка оценок (внутренних и внешних); • Roadmap проекта; • Для внутреннего контроля и планирования работ по команде (доступность и прозрачность планов работ по команде для всех участников в on-line); • При подготовке оценок и контроля, планирования самих работ по кросс-командным работам (тимлиды разных команд могут одновременно корректировать планы по задаче в рамках своей зоны ответственности)
  • 113. Как установить: 1. Под своей учетной записью заходим на гугл-диск, нажимаем «Создать» и «Подключить другие приложения» 2. Находим и выбираем:
  • 114. Как установить (далее): Далее – все просто: нажимаем «Создать» и выбираем уже установленное приложение:
  • 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 Удачи на проектах!