ITKaiZenClub: Как защитить интересы проекта, при этом не потеряв заказчика?

Как защитить интересы проекта, при этом не потеряв заказчика?- илиЗаказчик вас использует

Сергей Поволяшко, www.it-tuning.come-5.com.ua

Давайте познакомимся

Сергей Поволяшко

Профессиональные достижения: Лидирующее участие во

внедрении CMMI L3 Project Management Professional

(PMP), PMI. 2007 ISO 27001 Expert. 2013

CTO в Team International, LLC. www.teaminternational.com.

• В IT с 1996 года. Работал по нескольким IT специальностям. С 2001 – управление проектами, процессами, операционной деятельностью

Веду проект ИТ Тюнинг, www.it-tuning.com.Настройка операционной деятельности:• Оптимизация процессов, управление проектами,

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

www.it-tuning.com, e-5.com.ua

http://www.teaminternational.com/





http://www.it-tuning.com/

Правила игры

Активное участие Слышим и уважаем другие мнения Ваш телефон хочет отдохнуть


Содержание 3 кейса от спикера Рекламная пауза Кейсы от слушателей Приз за самый лучший кейс


Кейс 1. Спикер Заказчик предлагает в контракте формулу, по которой рассчитывается премия

или штраф для исполнителя. Модель взаимодействия - out staffing. Суть такова:

за хорошую работу выплачивается стандартное вознаграждение за отличную - премия (на основании коэффициента) за неудовлетворительную - штраф (на основании коэффициента)

На первый взгляд - логично

Но, какие могут быть вопросы Что есть хорошо, отлично и неудовлетворительно? Кто именно определяет этот коэффициент?

В реальной ситуации, на основании которой пишется этот эпизод коэффициент определялся: на основании суждения одного! человека, без использования каких-либо

метрик качества и количества работы человек был представителем заказчика


Кейс 1. Спикер

Что можно порекомендовать? Вариант 1 - убрать вообще такую мотивацию из контракта, т.е.

неявно согласиться на "хорошую" работу :). Как и было сделано. Вариант 2 - очень конкретно определить метрики «хорошести». Как?


Кейс 1. Слушатель 1) Продажа бизнес-анализа / написания технического задания заказчику,

который не понимает, зачем это нужно, поскольку никогда не сталкивался. 2) Аргументы для таких же клиентов для объяснения, почему на разработку ПО

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


Кейс 2. Спикер Наличие команды разработчиков со стороны заказчика, т.е. вы - дополнение к

команде заказчика (staff augmentation). Есть опасность саботажа со стороны команды заказчика.

Почему? соперничество страх быть сокращенными

В чем может проявляться? могут «забыть» сказать о важных изменениях в требованиях, архитектуре и

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

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


Кейс 2. Спикер Каков же выход? Договариваться и фиксировать документально порядок взаимодействия:

все рабочие процессы кто и как управляет проектом как построены коммуникации и эскалации какие кодинг стандарты и что такое хороший код (по сравнению с чем) что такое быстро-медленно и многое другое

Фискировать документально означает: описать КАК вы взаимодействуете с заказчиком нарушения (случайные, «случайные», вынужденные) обсуждаются,

устраняются, эскалируются


Quick and Dirty Development


Хочу быстро поклеить обои на кирпичный

забор в саду

Ок, но, обои в саду?Давайте хоть

поштукатурим...

Я просто хочу чтобы это было сделано!

Ок, подпишите пожалуйста тут

Без штукатуркиВ садуГарантия 1 час

Рекламная пауза


Серия тренингов

Для Project Managers, Sales, Account Managers, Business Analysts, Scrum Masters, Line Managers. Почти все из рассматриваемых дисциплин находятся на стыке их взаимодействия

Существенное расширение профессиональных возможностей и способности к взаимодействию с заказчиком, менеджментом, коллегами

Профессиональные тренера и областей управление проектами и процессами, бизнес анализа, финансов.



Формат

Ориентировочно февраль-апрель 2016, по субботам, через субботу

По субботам Скидки



Модули (по 4 часа):1. Разумное инициирование проекта2. Типы контрактов. Особенности, применимость, выбор3. Обсуждение требований (техники сбора требований) 4. Делегирование, постановка и контроль задач 5. Управление ожиданиями и коммуникациями6. Оценка здоровья проекта 7. Основы финансов. Экономика бизнеса/компаний8. Основы финансов. Бюджетирование для менеджера9. Инструменты работы с командой10. Личная эффективность11. Масштабирование в Agile (LeSS, SAFe, DAD, Nеxus)12. Завершение проектов13. Делаем ВСЕ и ВОВРЕМЯ: Создание WBS, работы по проекту и продукту14. Управление конфигурациями и изменениями15. Управление рисками. Классика и эффективное реагирование16. Управление рисками: agile, бизнес, продажа рисков заказчику


Кейс 2. Слушатель 1. I am leading as offshore Team Lead a T&M project for 1 year 2. We have a conflict w/ customer's Tech Lead (let's call him H) since he 1) wants me

to code as any other dev 2) wants team members to overtime, which demotivates them

3. I was previously working with more privileges - being PM + TL and this was recognized by customer as valid setup, but a project was cut from 9 people in Kyiv to 6, and I was able to stay only if I code as any other Dev and stop being manager and acting as him, I agreed to take this role under emotions

4. Now I regret that 5. Now waiting for budget for 2016 and most likely will leave the project if the it does

not grow to have my desired role included (that's unlikely)


Кейс 3. СпикерШаг №1 Заказчик прислал проект на оценку в виде нескольких документов

Functional Spec 1 v1_1.doc Functional Spec 2 v1_2.doc

Шаг №2 Сделали Estimate в виде

Шаг №3 Заказчик согласился на оценку, подписали контракт, начали проект


• Related Documents• Functional Spec 1 v1_1.doc• Functional Spec 2 v1_2.doc

• Assumed platform/technology overview• Major assumptions and constraints• Approach• Efforts estimate• Schedule

Кейс 3. Спикер

Шаг №4 Вдруг в середине проекта выяснилось, что сроки, обещанные в Estimate и

зафиксированные в контракте выдержать не получается Естественно «подозрение» пало на некачественный Estimate

Шаг №5 В конечном итоге выяснилось что

А) – заказчик в начале работ «подсунул» другие спецификации Б) – ни ПМ ни команда не сверились с Estimate

Очем это все? О дисциплине Управление Конфигурациями. Речь не о версиях кода в

репозитории (хотя к коду это тоже имеет прямое отношение). Речь о дисциплине в целом, которая отвечает за: а) - определение важных рабочих продуктов; б) - правилах их наименования, версионирования, доступа; в) - взаимосвязях между ними; г) - Управление Изменениями.


Приз



Спасибо за внимание!

Контакты: Email: [email protected] Skype: sergiy.povolyashko FB: facebook.com/it.tuning LinkedIn: Sergiy Povolyashko www.it-tuning.com


mailto:[email protected]

Software

ITKaiZenClub: Как защитить интересы проекта, при этом не потеряв заказчика?