Тимофєєв О.М.
Випускник групи ITM-20
Школа IT-менеджменту
РАНХиГС при Президентові РФ
Компанія, в якій в даний час працює автор, протягом уже понад 20 років займається як продажем ліцензій програмних засобів, так і проектною діяльністю зі створення інформаційно-аналітичних систем масштабу підприємства для різних замовників (банки, великі торгові компанії, підприємства енергетики, нафтогазовидобувні компанії , телеком). У більшій частині проекти виконуються з використанням лінійки продуктів SAP Business Objects. Такі проекти, як правило, включають в себе розробку моделей сховищ, вітрин даних, розташованих в різних СУБД і розробку процедур завантаження даних з будь-яких джерел (різні СУБД, Excel, XML, текстові файли зі структурованими даними). Процедури завантаження даних розробляються з використанням професійних ETL-засобів (IBM Data Stage або SAP BusinessObjects Data Services). Розробка звітів виконується в середовищі лінійки продуктів SAP BusinessObjects.
Ми допомагаємо нашим замовникам і клієнтам зібрати і проаналізувати дані, представити їх таким чином, щоб вони могли бути основою будь-якої системи прийняття рішень, вивести найнеобхідніші висновки разом з даними безпосередньо в аналітичний звіт або на інформаційну панель керівника. Все це можна назвати BI-проектами.
ОСОБЛИВОСТІ ПРОЕКТІВ З РОЗРОБКИ BI-ПРОЕКТІВ У консалтинговій компанії
Думати, що намічене буде розвиватися
за заздалегідь визначеним планом, - все одно
що качати дорослої людини в колисці немовля.
Едмунд Берк
Проектні бригади в таких проектах, як правило, невеликі, причому ресурси завжди обмежені. Тому перша особливість BI-проектів полягає в тому, що основна увага при підборі ресурсів в проектну бригаду в компанії приділяється професіоналізму в області проектування БД, розробки процедур завантаження і звітів, знання середовища розробки, досвіду роботи консультанта на аналогічних проектах. Якщо в таку проектну бригаду і входить керівник проекту, то через часту обмеженості бюджету з боку замовника, керівниками проектів призначаються найбільш досвідчені консультанти.
Мета атестаційної роботи по розробці методології і методики ведення BI-проекту - надати допомогу досвідченому розробнику, які володіють усіма необхідними інструментальними засобами, але з яким «раптово» доручили керувати проектом з розробки BI-системи.
Якщо з боку замовника є вимоги, що управління проектом ведеться по будь-якими з відомих методик або на підставі його внутрішніх вимог щодо ведення проектів, то ми, природно приймаємо всі вимоги замовника. Але якщо їх немає, то молодому керівникові проекту треба мати свої «корпоративні рекомендації»: що, в якій послідовності необхідно робити, ролі учасників проекту, які документи в ході проекту необхідно буде підготувати, щоб задовольнити всі вимоги зацікавлених сторін з боку замовника. І видати в кінці проекту гарантований результат, а саме якийсь BI-продукт, який би не тільки задовольняв би всім функціональним і технічним вимогам, але і гарантував високу ступінь задоволеності і лояльності клієнта. Щоб співробітники замовника не тільки сказали «величезне спасибі» розробникам, а й продовжували тісно співпрацювати з компанією ще не один рік. Сама методика ведення BI-проекту представлена в Атестаційної роботі, тут же я хотів би зупинитися на тих моментах, на які в обов'язковому порядку повинен звернути увагу новоспечений керівник BI-проекту.
Проекти в галузі впровадження BI мають свою специфіку. В першу чергу їх відрізняє те, що результати BI-проекту практично завжди відрізняються від тих видінь, які були у самого замовника до початку проекту з огляду на те, що його співробітники не володіють тими BI-інструментами, які ми їм пропонуємо. Після перших результатів з боку користувачів замовника постійно збільшується кількість «хотелок», тобто маса додаткових вимог вноситься вже в процесі розробки. Саме тому в такому проекті постійно змінюються всі плани, і саме тому тут в загальному випадку мало підходять стандартні і всім відомі методології управління проектами від PMI або IPMA, засновані на жорсткому плануванні та контролі виконання планів. Хоча багато областей знань, деякі групи процесів, рекомендації щодо проектної документації, без сумніву, не тільки можна, а й треба сміливо брати на озброєння з відомих стандартів або ГОСТ.
В.І.Ананьін дуже правильно запропонував розділяти все ІТ-проекти на чотири стилю по їх формі організації, які в значній мірі впливають на комерційні та технічні результати проекту: типовий, професійний, інноваційний і політичний [2], [3]. Якщо розглядати проекти з впровадження технологій BI не тільки з позиції керівника проекту, але і з позицій аккаунт-менеджера, спонсора проекту, системного архітектора, проаналізувавши зовнішні умови, в яких зароджуються і протікають такі проекти, можна зробити висновок, що більшість BI-проектів мають політичний стиль. І тільки в деяких випадках такі проекти мають інноваційну складову, і то за умови наявності раніше виконаних і успішних політичних проектів у конкретного замовника.
Основною відмінною рисою політичного проекту є те, що він не зачіпає і не вносить змін в бізнес-процеси компанії. Так, BI-системи щось оптимізують, безумовно щось покращують, зменшують час виконання якихось операцій, зменшують час підготовки даних і їх аналізу, тим самим оптимізуючи і покращуючи системи прийняття рішень, дозволяють швидко сформувати запит і видати дані на стіл керівника. Але такі проекти не змінюють сформовані бізнес-процеси, вони їх тільки покращують, більшою мірою відображають не стільки стратегію бізнесу, скільки внутрішню специфіку відносин між підрозділами замовника. Тобто з точки зору стратегії впровадження - «Натягування розроблюваної системи на існуючий бізнес» [2]. При цьому він завжди супроводжується постійними змінами вимог з боку замовника, які відображають поточні проблеми функціональних бізнес підрозділів і характер відносин між ними. Тому на перше місце в керівництві таким проектом виходить управління вимогами.
Менеджер проекту завжди повинен сказати: «Ми можемо зробити вам« Це »,« Швидко »і« За дешево ». Але ви (замовник) повинні вибрати одне з них »[5]. Не можна приступати до проекту, поки не визначені пріоритети: або це рамки проекту, або вартість, або терміни. І якщо відбулося значне збільшення вимог замовника, відмовитися від них не можна - що робити в цьому випадку менеджеру проекту? Треба домовлятися з замовником або про зміну термінів проекту, або вартості, щоб на додаткові роботи залучити необхідні ресурси. А якщо замовник вимагає зменшити терміни здачі проекту - це або зменшення функціональності, або знову ж, збільшення бюджету, в залежності від того, що для замовника пріоритетною. Якщо пріоритети змінюються в ході проекту, це обов'язково має бути відомо менеджеру проекту, причому вважається, що все, що зроблено до зміни даного рішення, все було зроблено правильно.
В процесі розробки BI-проекту ми завжди стикаємося з «диктатом замовника». Один зі спонсорів пакету проектів великої компанії, де ми впроваджували BI- систему, мені якось сказав фразу: «Ви для нас« гастарбайтери », тому що ми говоримо, то ви і будете робити». Доводиться приймати ці правила гри, адже, по суті, він має рацію. Це теж одна з ознак політичного стилю проекту.
У BI-проект планування, контроль термінів і витрат носить узагальнений характер. При постійній зміні вимог замовника можливі і зміни мети проекту, і постановки завдання, отже і всі плани постійно міняються і коригуються. Головна проблема - утримати кордону і статус управління проектом. І саме тому в частині управління проектом на перший план виходить спонсор проекту з боку замовника. Саме він є тим рушійним ланкою, який гарантує успіх (не без участі, природно, керівників проектів з боку замовника і виконавця), саме він є координатором відносин між обома сторонами. З цього випливає і найголовніший ризик такого проекту - це втрата або зміна спонсора. І прикладів таких досить багато.
Свого часу наша компанія виконувала ряд проектів по створенню аналітичних інформаційних систем в одній енергетичної компанії. Цим рушійним ланкою, спонсором з боку замовника, протягом декількох років був Директор з інформатизації. Його відхід, а разом з ним догляд більшості співробітників Департаменту ІТ, а потім і багатьох ключових зацікавлених фахівців функціональних підрозділів, привів до згортання деяких вже реалізованих та впроваджених проектів. Після того як пішли зацікавлені люди з функціонального підрозділу, ті, які брали участь з нами разом в розробці одного проекту в якості постановників завдання, а потім «пішли» і керівництво Департаменту інформатизації, ми неодноразово пропонували взяти одну розроблену нами систему на супровід і подальший розвиток. По всій видимості, нове керівництво вирішило доцільним розробити нову аналогічну систему, але на іншій платформі і іншим виконавцем, тому наша система була практично забута новим Департаментом ІТ. Я тут наводжу тільки факти, тому що висновки вони на поверхні. Правда, тут є і специфіка самого замовника, тому що скоро і цей новий склад Департамент ІТ змінився, «але вже інша історія».
Ще один зовсім свіжий приклад. Наша компанія розробляла ряд інформаційних панелей для фінансового директора компанії «Фортум» (колишня «ТГК-10»). Після показу пілот-проекту «вітчизняного» фінансового директора змінює німець. Далі на вимогу нового CFO в значній мірі довелося переробляти дизайн. З усіх інформаційних панелей були видалені всі спідометри, перероблені графіки і т.д. Але при цьому проект отримав дуже високий статус, була пророблена неймовірна робота спільно з фахівцями замовника по збору і вивірки даних в SAP BW. В результаті проект був успішно зданий, ми отримали дуже високу оцінку. Як приклад, щоб було зрозуміло про що йде мова, наведу одну з основних інформаційних панелей на Рис.1. Тобто проект вийшов дуже цікавим і нам, як розробникам, було чим пишатися. Завдяки цьому проекту в нашому арсеналі з'явилося багато нових різних ідей і прийомів.
Потім шановний «німець» залишає компанію, разом з ним керівник цього проекту з боку Замовника, інтерес до проекту згасає. Потім наші фахівці визначили, що деякі панелі взагалі перестали працювати після зміни структури джерела даних. Виявилося, що ними вже ніхто не користується і проект згорнуть ...
Рис.1. Інформаційна панель для компанії «Фортум»
Програмісту завжди прикро, коли його праці викидаються в кошик.
І тільки через кілька місяців пролунав дзвінок з Челябінська, обіцяли повернутися до цієї системи. Але поки все чекаємо заявку на доопрацювання проекту від замовника, чекаємо нового спонсора проекту.
Основне завдання аккаунт-менеджера в політичному проекті (з часткою гумору «людини - залізна печінку») є налагодження безпосереднього контакту зі спонсором. Основне завдання керівника такого проекту - підтримка цих відносин.
Уміння керівника проекту зацікавити бізнес в результатах проекту може в значній мірі підвищити як значимість проекту, так і успіх від його впровадження. Тому особливу увагу керівник проекту повинен приділяти етапу впровадження проекту, який не повинен обмежуватися тільки розробкою ІАС і документації, необхідно доводити розроблену систему до бізнес-користувачів, навчати їх працювати в новій системі. Тільки в цьому випадку можна домогтися зацікавленості не тільки спонсора проекту в даній розробці, але і отримати хороший відгук від бізнесу.
При велику зацікавленість з боку замовника виступати з виконавцем в якості партнера, а не диктатора, проект може мати і інноваційний стиль, або, хоча б, якусь інноваційну складову, яка може і повинна забезпечити гарантований успіх BI проекту. Таких прикладів в скарбничці нашої компанії досить багато. У 2008 році нас запросили в ВАТ «Сургутнафтогаз» і запропонували розробити кілька BI-систем за оперативною і аналітичної звітності. Успішно реалізувавши кілька проектів, ми спільно з фахівцями Сургутнефтегаза зараз беремо участь в інноваційних роботах по впровадженню новітньої СУБД SAP HANA. В такому розвитку цього проекту замовник вже виступає не як «диктатор», а як партнер, підвищується статус управління проектом. Але перетікання з політичного стилю в інноваційний можливий тільки при довгостроковому партнерстві замовника і виконавця. Тепер обидві компанії несуть відповідальність і проявляють повну зацікавленість в результатах отриманого продукту, ніяка зміна спонсора проекту не призведе до зриву. Але з'являються інші ризики, пов'язані з малим досвідом впровадження, вірніше, з його повною відсутністю. Навчатися доведеться як нам, так і сургутянам в «бойових умовах».
Окреме питання про управління контрактом, хоча в основному це турбота аккаунт-менеджера, але часто і керівник проекту може внести свою лепту в цей процес. Як правило, в більшості наших проектів по впровадженню BI, з урахуванням того, що вони мають політичний стиль, тип контракту - це фіксована ціна. Ризики для аутсорсера - складність визначення обсягу трудовитрат, отже недооцінка обсягу робіт і вартості, проблеми в роботі інструментальних програмних засобів, постійна зміна вимог. І як наслідок зрив або термінів, або рентабельності. Якщо з некоректною роботою ПО менеджер проекту самостійно навряд чи впорається, це турбота нашої техпідтримки, то оцінка обсягів робіт, термінів і чітке управління змінами вимог - це основні завдання керівника проекту.
Якщо обидві сторони вже давно працюють разом, або проект перетікає в інноваційний, в більшій перевазі виявляється рамкову угоду, тобто контракт Time & Material, в якому для кожної сторони визначаються джерела формування бізнес ефектів і принципи поділу ризиків, а також принципи організації спільної роботи. Оплата здійснюється по так званим TimeSheets - реальному часі роботи консультантів на проекті.
Який висновок напрошується з усього вищесказаного? Якщо в консалтинговій ІТ-компанії основну масу складають політичні проекти, то це самий ризикований бізнес. Але з цього не випливає, що цим не варто займатися. І реальний приклад цьому - компанія, в якій я працюю. Так, складно, але цілком реально, причому дуже цікаво. Про це свідчать і численні відгуки наших клієнтів.
Що беремо на озброєння?
Для того щоб людина могла отримати хоч якусь радість на відведеному йому короткому відрізку шляху, він повинен думати і складати плани, як поліпшити становище не тільки для себе, але і для інших, оскільки радість, яку відчувають їм самим, залежить від того, на скільки він радіє за інших і наскільки інші радіють за нього.
Теодор Драйзер
BI-систему не можна розробляти по каскадної моделі. Цей тип розробки застосуємо за Жванецьким тільки для «орієнтації ракет в безповітряному просторі», коли на випробування необхідно вивести вже повністю готовий і протестований програмний продукт.
Основна ідея спіральної моделі, на відміну від каскадної, полягає в ітераційний процес розробки системи. Головне завдання кожної ітерації - якомога швидше створити працездатний продукт, який можна показати користувачам системи. Після чергового етапу, на якому отримуємо в якомусь вигляді прототип майбутньої моделі, ми показуємо цей ескіз і збираємо по ньому побажання і пропозиції, що значною мірою економить не тільки наші сили і засоби, а й сили і засоби замовника.
Спіральна модель забезпечує більшу гнучкість в управлінні проектом. Адже що таке в підсумку «управління проектом» - це завжди пошук компромісу між «Що?», «Коли?», «За скільки?», «Чим?», «Навіщо?» [5]. Тобто між метою, термінами і вартістю, виконавцем, інструментальними засобами і технологією. І на кожному етапі ітерації це завжди можна обговорити з замовником і за результатами і з внесеними змінами можна внести корективи в будь-який з цих питань. Таким чином, істотно спрощується процес внесення уточнень і доповнень до проекту, що значною мірою зменшує ризики невдачі проекту.
Проект зі создания сховище Даних и звітності в компании «Комстар Об'єднані Телесистеми» (зараз МТС), необходимо Було з'єднати аналітіку по трьом різнім білінговім системам. Люди знайомі з телекомом можуть уявити собі розмір такого ХД. Не буду вдаватися в деталі, хочу відзначити тільки те, що успіх тут, в певному сенсі, дуже залежав від особистості керівника проекту з боку нашої компанії, який зумів переконати керівництво і проектний офіс замовника в тому, що розробку треба вести тільки по спіралі. Виділяти з усього scope проекту на перший етап частину предметної області, її автоматизувати, показувати весь ланцюжок обробки даних від джерел і до аналізу цих даних у звітах, а потім займатися подальшим нарощуванням цієї системи. Але з іншого боку вимагали вести розробку відразу по всій предметної області і повного функціоналу системи. Наші фахівці зуміли переконати Замовника саме в правильності итерационного підходу. Проект в «Комстаре» був визнаний дуже успішним, більш того, компанія «МТС» проявила великий інтерес до нього, хоча має на озброєнні інші інструментальні засоби для розробки подібних систем.
Багаторічний досвід розробки BI-проектів дозволяє беззастережно підписатися під ідеями Agile Manifesto, якими ми, безсумнівно, керуємося у своїй роботі (Manifesto for Agile Software Development) [10]:
- Особистості та співпраця важливіша, ніж процеси і інструментальні засоби;
- Працююче програмне забезпечення важливіше, ніж повнота документації;
- Спільна робота з замовником важливіше, ніж контрактні зобов'язання;
- Реагувати на зміни важливіше, ніж дотримання плану.
Rational Unified Process (RUP) цілком може вмістити agile-цінності та доповнити інші agile-процеси. Тому від Rational Unified Process ми беремо набір кращих практик з розробки систем, вибираємо з них ті, які краще вписується в наші проекти. І далі його можна доповнити рекомендованими проектними документами.
Менеджер проекту - людина, якій спонсор делегує повноваження з управління проектом, тобто прийняття управлінських рішень. Не можна плутати «делегування повноважень» і «роздачу завдань», тому що частіше зустрічається останнім.
Відповідальність - готовність брати на себе повністю або частково наслідки прийнятих рішень. Перш ніж погоджуватися на роль керівника проектом, з будь-якого боку, треба уважно проаналізувати всі відповідальності, які на вас покладає спонсор проекту, намалювати для себе таблицю і поставити відповідні їм повноваження, які, на вашу думку, повинен надати вам спонсор по кожній відповідальності. Найчастіше нам кажуть: «Ти відповідаєш за проект» - це ні про що. Наприклад, якщо керівник проекту бере на себе відповідальність не тільки за результативність, а й за рентабельність, він повинен мати право обговорювати з замовником ціну, мати можливість впливати на собівартість, вибирати ресурси. По кожній відповідальності повинен стояти тезу: «Для того щоб ... треба ...». Як і будь-який менеджер в будь-якій області керівник проекту не може відповідати за те, що він не керує [5].
Успіх будь-якого менеджера проекту цілком і повністю залежить від проектної команди. Саме тому він повинен користуватися заслуженим авторитетом у своїх колег. Заслужений авторитет складається на 50% з професійних якостей, на інші 50% з людських якостей. Швидше за все, тут і пояснювати більше нічого. Тільки якщо у керівника є обидва «50%», тільки в цьому випадку він керівник на все «100%».
- Минцберг Г., «Структура в кулаці. Створення ефективної організації ». - СПб .: Питер, 2001.
- Ананьін В.І., IT-Менеджмент. Навчальний курс. - М .: АНХ, 2011 р
- Ананьін В.І., «До конкурентних переваг - ЧЕРЕЗ ПРОЕКТИ». Журнал «Управління проектами та програмами», 03 (23) 2010 року.
- Леоненков А.В., Раціональний уніфікований процес. Навчальний курс. - М .: АНХ, 2011 р
- Сирота В.Є.., Управління проектами мистецтво досягнення цілей. Навчальний курс. - М .: АНХ, 2012 р
- Якобсон А., Буч Г., Рамбо Дж. «Уніфікований процес розробки програмного забезпечення». - СПб .: Пітер, 2002. - 496 с: ил.
- «A guide to the Project Management Body of Knowledge», 2000. Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
- IPMA Competence Baseline (ICB), Version 2.0b, Bremen, 1999/2001, International Project Management Association.
- Єдина система стандартів автоматизованих систем управління. АВТОМАТИЗОВАНІ СИСТЕМИ. ГОСТ 24.601-86.
- матеріали сайту www.agilemanifesto.org
Рубрика:
управління проектами
І якщо відбулося значне збільшення вимог замовника, відмовитися від них не можна - що робити в цьому випадку менеджеру проекту?Який висновок напрошується з усього вищесказаного?
Що беремо на озброєння?
Адже що таке в підсумку «управління проектом» - це завжди пошук компромісу між «Що?
», «Коли?
», «За скільки?
», «Чим?
», «Навіщо?
