3. 11/18/13
●
●
●
●
Про що буде йти мова
Хто я?
Стаття CIO: 7 найбільших бажань
IT менеджерів проектів
Чому не варто цього бажати і що
робити?
Посилання / Питання та обговорення
4. 11/18/13
Хто я?
15 років досвіду роботи в ІТ
галузі. Працював системним
інженером та розробником у
різних компаніях в Україні,
начальником сектору
розробки програмного
забезпечення у ПАТ
«Укрсоцбанк», системним
архітектором у iKobo Inc.
(США), менеджером проектів
та начальником відділу
6. Стаття у CIO
1. Брати участь з самого початку проекту
2. Ідеальна команда для кожного проекту
3. Мати потужні, але прості у використанні
інструменти управління проектами
4. Мати чітко визначені цілі проекту і
вимог
5. Підтримка та зацікавленість сторін та
кінцевих користувачів
6. Ставлення із повагою
7. Мати можливість коригувати проекти
8. 1. Брати участь з самого початку проекту
Я б не витрачав своє бажання на це
Так має бути. Розгляньте свої процеси
Якщо треба передати проект від PM до
PM, має бути процедура передачі
Розібратись із проектом (влитись)
Якщо PM щоденно займається проектом,
то входження у проект пізніше не має
бути проблемою
10. 2. Ідеальна команда для кожного проекту
Має сенс лишень до певної межі
Неможливо створити ідеальну команду
Люди не машини у ідеальному пулі
“Perfect” is a verb, not an adjective
Команда має вдосконалюватись і рости
Має бути “цілою” і живою
11. 3. Мати потужні, але прості у використанні
інструменти управління проектами
12. 3. Мати потужні, але прості у використанні
інструменти управління проектами
Достатньо “розшареної” таблиці
Багато онлайн та оффлайн інструментів
Кожен має власні “історії успіху”
Багато проектів із різними інструментами
Важливий процес, інструмент вторинний
Пишіть власні інструменти
Немає срібної кулі
14. 4. Мати чітко визначені цілі проекту і вимоги
Доісторичне бажання із часів “big up-front
design”
...який ніколи не працював
Це неможливо у реальному світі
Клієнту треба “помацати” щоб зрозуміти
Треба робити інкрементальний дизайн
Навчитись рухатись маленькими кроками
І йти куди треба клієнту у будь-який час
15. 5. Підтримка та зацікавленість сторін та
кінцевих користувачів
16. 5. Підтримка та зацікавленість сторін та
кінцевих користувачів
Чому немає підтримки та зацікавленості?
Спілкування дуже важливе
РМ має бути здатним вирішувати та
піднімати на вищий рівень проблеми
Задовольняти команду, партнерів та
кінцевих користувачів
Вдосконалюйтесь, вчіться на помилках
18. 6. Ставлення із повагою
Я працюю у IT вже 15 років
Не було випадків відвертої неповаги
Бувають особисті проблеми спілкування
та непорозуміння
Але вони всі вирішуються спілкуванням із
клієнтом
Відкритість і зворотній зв'язок, повага
5 чому Тайчі Оно кажуть що більшість
проблем — в корені проблеми людей і
відносин
20. 7. Мати можливість коригувати проекти по мірі
необхідності
Можу порадити дуже гарну книгу Kent
Beck “Extreme Programming Explained:
Embrace Change."
Похідна практика: контракт із договірним
обсягом
Знову ж, майстерність спілкування та
здатність пояснити чому проект має бути
змінений
Будьте відкриті, працюйте прозоро і вас
не будуть судити заднім числом
22. Висновки
Уявіть що 7 бажань здійснились
Навіщо нам РМ у цій ідеальній ситуації?
Я вірю він не потрібен
І добре що це неможливо :)
Тому у РМів як я є робота
Наша робота працювати над здійсненням
цих 7 бажань