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

Preview:

Citation preview

Дерунов Владимир

Artezio

“Проект – это не спринтерская гонка, а марафон: победа

на первом отрезке еще ничего не означает”(Дерунов В.)

Апрель 2015г.

• Выводы для PM:

Ключевая ошибка PM №1: РАБОТА БЕЗ ОБРАТНОЙ СВЯЗИ!

(как с Заказчиком так и со своей командой)1

Профессиональный PM должен регулярно

отрабатывать возможные внештатные ситуации,

постоянный риск-менеджмент и накопление

знаний!

2

Руководитель проектов =

Авиадиспетчер

Руководители проектов должны

регулярно (раз в 0,5г.) проходить

аттестацию на профпригодность!3

Руководители проектов должны

проходить регулярные стажировки,

курсы повышения квалификации

4

• Выводы для компании:

РУКОВОДИТЕЛИ

IT-проектов –

Офицеры автоматизации

ЦЕЛЬ

встречи

1. Разбор реальных

проектных ситуаций

2. «Фишки» программного

инструментария РП

3. Первоклассный РП:компетенции, навыки,

дорожная карта развития

Цель встречи:

Показать, обозначить для начинающих и

напомнить действующим руководителям

IT-проектов

на практических примерах базовые принципы, правила проектной игры

Руководитель IT-проектов

• Базовые правила:

Нельзя выходить на проект с неподготовленной командой!2

Нельзя выводить новичков на прямой контакт с

Заказчиком !3

Том Круз,

«Last Samurai», 2003, Выводы:

Нельзя новичку поручать важные,

сложные, продолжительные участки.

Новичку следует поручать простые

задачи!

4

Нельзя оставлять новичка один на один!

Новичка следует прикрепить

к опытному специалисту на проекте!

5

Проект – не детский сад! Умейте во время

выводить с проекта не эффективных специалистов

«Жалеть виновных, значит предать невинных»

(Айн Рэнд)

1

Ключевая ошибка PM №2:

PM забывает установить сразу

при входе в проект правила игры для своей команды

Иначе, твоя команда будет работать по принципу:

То, что не запрещено = разрешено

Установка правил игры:

В режиме выработки

совместных договоренностей

либо, в отдельных случаях

УЛЬТИМАТИВНО

• Базовые правила:

«Не давай обещаний, которых не сможешь сдержать»(особенно в части озвучивания сроков Заказчику)

«Кто сильнее напоит своих

солдат, чтобы послать их на

бойню, тот и победит»

Цитата из к/ф «Хороший, плохой,

злой» (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)

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

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

Ошибка в диалоге с заказчиком

и с командой происходит порой

не от того, что вы не сумели

донести вашу мысль, а

потому, что вы слышите не

то, что вам говорят

• Базовые правила:

Сумей расположить к себе Заказчика1

Ты должен чувствовать Заказчика, думать как он.2

Внимательно наблюдай за всем

происходящим и слушай.

Умей слушать «между строк».3

Подыгрывай Заказчику: сделай его

«хозяином» ситуации4

Владимир Высоцкий,

«Место встречи изменить нельзя», 1979, Выводы:

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

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

«...Нам, господа, не следует увлекаться

западными образцами, не следует увлекаться

теоретическими выводами западной науки,

так как иногда на совершенно оригинальное

разрешение вопроса нас наталкивает сама

жизнь»

Петр Аркадьевич Столыпин

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

Главный артефакт в управлении проектами

Документ, либо

договоренности, апрув в почте

В диалогах с заказчиком возьмите за правило,

особенно в переписке опираться на

зафиксированные

документы/договоренности, а не фразы в

скайпе или слова

Документ - главный артефакт в разведке.

именно этот неоспоримый артефакт

становился ключевым при принятии

решения.

Аналогично и в управлении проектами

Главный артефакт в управлении проектами

Делегируйте, не держите задачи на себе,

сбрасывайте их с себя как экипаж самолета

при экстренной посадке

У летчиков есть термин: максимальная посадочная масса –

это максимальная масса, которую выдержит шасси при посадке

«Секрет умения разговаривать красиво –

отказаться от лишних слов»

Абу Бакр

Завышенные оценки по CR, новым задачам

в рамках действующего проекта – это плохо

Не стоит делать неоправданно завышенных оценок.

Если по факту будет видно, что вы сделали задачу

быстрее, то отношения с заказчиком будут постепенно

только ухудшаться!

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

Уловки Заказчика

когда заказчик начинает ставить задачи напрямую твоим программистам

и др. членам твоей команды,

в обход тебя.

Это большой минус вам как PM

Это нужно пресекать сразу,

причем в «угол» ставить своих сотрудников

Не работающее правило

в проектном управлении:

Не работающее правило

в проектном управлении:

«Хорошее начало - половина дела»

ПЛАТОН

“Проект – это не спринтерская

гонка, а марафон: победа на

первом отрезке еще ничего не

означает”(Дерунов В.)

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

Не оставляй на завтра то,

что можно сделать сегодня

Очень часто забываем избитое, но

наиважнейшее правило:

Живые коммуникации гораздо

эффективнее удаленных

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

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

Не стоит набрасывать в пул задач

разработчику (другому специалисту

проекта из своей команды) сразу

несколько задач в очередь, а если эти

сотрудники к тому же новые сотрудники в

компании – то это категорически не

эффективно.

Не верь тому, кто говорит, что все под

контролем!

Всегда требуй детализацию

Nullius in verba (с лат. «ничьими словами») –

уже ни одно столетие гласит девиз Британского королевского общества,

основанного в 1662 году для содействия успехам естествознания,

избравшего это выражение своим девизом в знак того, что оно будет полагаться то

лько на свидетельства научных экспериментов, а не на слова авторитетов

Применительно к проектному управлению

утверждение можно интерпретировать как: все нужно

подвергать сомнению.

Лучшая методика разрешения конфликта

- психологическое айкидо:

уступая ты побеждаешь!

Уступая, ты выдерживаешь испытание,

говорят на Востоке

Уступай, чтобы ослабить сопротивление,

учат буддисты

Не борись, ибо ты неизбежно становишься тем, против

чего ты борешься

Слишком много силы приводит к обратному результату

Лучшая методика разрешения конфликта

Вы не следуете сразу в разрез мнения вашего оппонента, а

присоединяетесь к нему, по типу "я тебя понимаю,

принимаю..., теперь и ты меня послушай и пойми...", и уже

после, переходите к своим убедительным доводам,

аргументам

Результат - ваше превосходство в расстановке новых

позиций, приоритетов, уважение, укрепление отношений и

главное - никакого конфликтного, напрягающего,

раздражающего общения...

Лучшая методика разрешения конфликта

• Базовые правила:

Bruce Lee,

«Lost» interview, 1971, Выводы:

Не стоит постоянно придерживаться одного стандарта управления

проектами (PMBok, Agile и т.д.).

Придерживаясь постоянно одного стандарта вы ограничиваете себя:

вы не развиваетесь.

1

Берите лучшее из различных

проектных практик и применяйте!2

«Меняйся с тем, что изменяется»

Брюс Ли3

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

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

Возьмите за правило:

не стоит сразу торопиться и включаться в решение

проблемы, вопроса.

Постарайтесь выдерживать 30 минут ожидания,

и если после этого проблема не разрешена, то

приступайте.

Практика показывает, что определенная

часть всех проблем становятся не актуальной

спустя не продолжительное время

СТАРТОВАЯ ВСТРЕЧА проекта

Правила

СТАРТОВАЯ ВСТРЕЧА проекта

Правила:

СТАРТОВАЯ ВСТРЕЧА проекта

Правила:

«Куан Ча» - взглянуть на противника

и извлечь как можно больше

информации

(одна из техник Ниндзя)

Практическое задание №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. Задача:

Необходимо за отведенное время указать ваши

дальнейшие действия в части выхода из

сложившейся ситуации для возможности дальнейшего

продолжения проекта с минимальными потерями

Решение:

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

СТРАТЕГИЧЕСКАЯ ошибка 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, GoogleDrive или 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

Удачи на проектах!