Про те, як якісно написати курсову та дипломну, ми дізналися у студентів, які звикли покладатися лише на свої сили.
Старання не пропадуть задарма
Ілля Михайлов, студент 5-го курсу механіко-технологічного факультету БНТУ:
– Тема мого диплома – «Вплив ультрадисперсних добавок на структуру та властивості сірого чавуну». В основу проекту лягли курсові роботи, які готували під час навчання Одногрупникам пощастило менше – вони пишуть роботу з нуля. Особливих труднощів із підготовкою дипломної не виникає – я завжди намагався робити все самостійно. Більше уваги приділяю практичній частині. Її писати легко. Багато залежить і від наукового керівника. Він дуже допомагає: пропонує потрібну літературу, вказує на помилки і може підказати, як їх виправити. Зараз я трохи зав'язав у кресленнях. Будь-яка неточність – і доводиться все переробляти. Сподіваюся, мої старання не пропадуть, і керівник із рецензентом високо оцінять дипломну роботу.
Диплом із нуля? Легко!
Ірина Куцелай, студентка 4-го курсу факультету банківської справи ПолісДУ:
– Писати самостійно курсові непросто, бо не знаєш, із чого почати. Я йду до бібліотеки, беру книжки на тему, гортаю їх, і тільки тоді в голові вимальовується план. Зате легко на захисті – ти чудово знаєш своє дослідження та не боїшся додаткових питань. Щоразу для себе наголошую, що знань додається, що починаю краще розумітися на темі. На перший курсач витратила місяць, а останній написала за тиждень. Кілька разів засиджувалась уночі. Але сама винна – не треба робити все в останній момент. Не сумнівалася, що й диплом здолаю. Це той самий курсач, тільки більше за обсягом. Моя тема звучить так - Фінансовий аналізяк метод фінансового управліннясуб'єкта господарювання (на матеріалах ВАТ "Слуцький сироробний комбінат)". Взялася за роботу ще у лютому, коли проходила переддипломну практику. А вже у квітні два розділи були готові. З третьої, щоправда, справи були складнішими. Довелося вивчити багато статей різних авторів, зробити висновки та застосувати їх до свого дослідження. На цьому тижні планую віддати результати праці на рецензію.
Потрібен чіткий план
Ілля Лемець, магістрант факультету філософії та соціальних наукБДУ:
– Під час навчання за курсові отримував одні дев'ятки. Диплом оцінили так само високо. Викладачі бачили, що це не плагіат. Часу йшло багато, через роботу та заняття спортом писав усе ночами. Перший курсач забрав багато сил. Самостійно шукав джерела, що постійно засинав питаннями наукового керівника. Ближче до захисту запанікував – з'явилося почуття, що провалюся. Але зібрався, заспокоївся, і все пройшло добре. Потім продовжив писати курсові на близьку тематику, і вони стали частиною мого диплома. Над ним працювати було складніше, але я чітко розумів, що за чим треба зробити: підібрати літературу та прикинути зразкові розділи. Провести практичне дослідження та опрацювати його. Скласти зміст. Написати теоретичну та практичну частини, вступ, висновок та висновки по розділах. Оформити роботу. Ось тільки коли здавав її на кафедру, полетіли всі відступи та шрифти. Викладач поставився з розумінням – дав дві години на виправлення. Я все встиг.
Головне – правильно розподілити час
Яна Шадріна, студентка 4-го курсу факультету економіки та бізнес-управління ВДТУ:
– Замовляти готову курсову чи дипломну роботу не варіант – викладач чудово все бачить. Я писала самотужки. Щоправда, багато часу витрачалося на таблиці. Їх довелося робити десь 25–30 штук. Над кожною треба посидіти, пошукати інформацію, зробити розрахунки та висновки. Це досить копітке заняття. На виконання курсової викладачі давали нам два місяці. Я відразу ж створювала на комп'ютері окрему папку і починала потихеньку писати розділи. Здавала на перевірку науковому керівникувін вказував на неточності. Їх, на жаль, було чимало. Зі сльозами на очах усе переробляла. Завжди намагалася не зволікати зі здаванням, а тому вкладалася у відведені терміни. На четвертому курсі викладач запропонував тему для диплома «Дослідження та обґрунтування напрямів покращення фінансових результатівдіяльності ВАТ «Вітрайпобут». Декілька розділів з останньої курсової увійшли до проекту, що дуже полегшило мені життя. З теоретичною частиною проблем не виникло, з аналітичної допомогло підприємство – видали документи із потрібними даними. Тиждень відводив для написання першого розділу, ще один – для другого. Але обов'язково робила перерву, щоби відпочити. Насправді все не так уже й складно. Мені навіть не довелося сидіти над дипломом ночами. Краще добре висипатися.
Готуйся влітку
Михайло Ребізов, закінчивземлевпоряднийфакультет БДСГА у 2018 році:
- Написання курсових завжди давалося мені легко. Протягом семестру на практичних заняттяхробив розрахунки, систематизував їх у таблицях. Перевіряв усі цифри і лише тоді писав текст. На це витрачався десь тиждень. Курсачі стали в нагоді на випускному курсі, коли настав час взятися за диплом. Його тема звучала так: «Селянське фермерське господарство». Працювати над проектом було цікаво. Господарство, яке я досліджував, займається конярством. У практичній частині розраховував поголів'я, описував, чим годувати, скільки корму потрібно, де його брати, як доглядати тварин. Отримав гарний досвід. Використовував 30 джерел, щоб написати теоретичну частину. З цього року на моїй спеціальності («інженер-землевпорядник») навчаються на шість місяців менше, і розпочинати роботу над дипломом довелося ще влітку під час виробничої практики.
Фото з особистого архіву героїв.
Управління проектами в IT - тема досить давно і добре вивчена, але в "скарбничці" у кожного ІТ-керівника, безсумнівно, є чимало прикладів нестандартних ситуацій, що потребують особливого підходу.
На спеціалізованому бізнес-семінарі “Комплексне управління проектами”, що відбувся цієї весни, своїми знаннями та досвідом у цій галузі поділився начальник відділу контролю ІТ-проектів “ЮніКредит Банку” Олексій Малишкін, який займається проектною діяльністю з 1993 р. Він брав участь у 115 виконаних проектах (в 57 з яких займав позицію менеджера), причому банківські проекти становили близько 70% від загального числа.
За даними одного зі звітів “Chaos Report” компанії Standish Group, які навів пан Малишкін, лише 16% проектів укладаються у встановлені терміни та бюджети, при цьому бюджет у середньому перевищується на 188, а терміни – на 222%. І лише у 61% проектів цілі та зміст залишаються незмінними. Саме звідси й витікає та значимість, яку організації мають приділяти завданням управління проектами.
Головні джерела складнощів
Як розповів Олексій Малишкін, більшість проблем проекту розпочинається зі стадії його ініціації. Найчастіше керівники проекту вважають, що якщо вони склали його план (неважливо, за допомогою яких засобів - Microsoft Project, Primavera або Spider), значить, у них є все, включаючи терміни, ресурси і т.д. Однак як цей проект виконуватиметься, зазвичай не знає ніхто.
Таким чином, управління проектом має починатися не з планування, а з ініціації, коли мають бути поставлені та узгоджені з усіма. зацікавленими особамицілі та зібрана вся інформація, необхідна для грамотного планування. На цьому етапі необхідно вивчити та документувативсі вимоги до ходу та результату проекту, а керівник має стати центром його компетенції. Крім цього, керівнику проекту спільно зі спонсором обов'язково слід підготувати статут проекту, обговорити його. із зацікавленимиособами та затвердити. Далі спонсор повинен підписати цей статут, який наділяє необхідними повноваженнями керівника та містить у собі початкову основну інформацію про проект, яка допоможе скласти його. детальний план.
Ще одним джерелом проблем реалізації проектів пан Малишкін вважає відсутність у керівництва організації інформації на постійній основі про стан (“як є”) та прогноз (“як має бути”) проектної діяльності. Це призводить до розрізненостіреалізації проектів, так що вищий менеджментне має можливості керувати розвитком та досягненням стратегічних цілей компанії, а також безпосередньо впливати на роботу кількох центрів управління проектами (ІТ-служба, бізнес-підрозділи). Результат - недостатня координація проектів лише на рівні бізнес-напрямків підприємства, виконання “пов'язаних” проектів чи робіт у різних підрозділах без належної взаємодії, їх завершення пізніше планового терміну, перевищення планового бюджету і неналежне якість результатів. (Про те, як на практиці відбувається, наприклад, збільшення трудомісткості проекту, можна побачити на малюнку.)
Одним із проявів цієї проблеми, за словами Олексія Малишкіна, є “битви” менеджерів проектів за ключових співробітників та пов'язані з цим перевантаження персоналу. Тому слід по можливості залучати до реалізації проекту сторонні компанії, що мають досвід роботи у цій сфері. Але тут є одна складність: віддаючи вирішення того чи іншого завдання на аутсорсинг, замовник фактично передає свою інформацію у конкурентне середовище. Існує ймовірність, що аутсорсингова компанія, реалізувавши це завдання, трансформує їх у пропозицію, із яким згодом виступить над ринком.
Є простий підхід, щоб уникнути подібної ситуації, вважає пан Малишкін. Суть його полягає в тому, що не слід віддавати на бік завдання у повному обсязі – але не більше ніж 20%. Щоправда, тоді виникає складність з розподіломрешти 80% між іншими компаніями та координацією їх роботи. Відповідно, тут знадобиться проектний менеджер, який має навички взаємодії з аутсорсинговимифірмами.
Наступне джерело складнощів - відсутність у керівників проекту чіткого розуміння, чи все надано для його реалізації, яким способом треба його виконувати, хто що робить, скільки потрібно часу, щоб вирішити всі завдання, скільки потрібно грошей, в якій формі буде отримано результат. Нестача такої інформації ускладнює проведення поточного моніторингу проектів та визначення обґрунтованих потреб їх своєчасноговиконання, що неминуче тягне у себе постійне перенесення узгоджених термінів.
Для конкретних виконавців проектів такий дефіцит інформації означає часті змінипріоритетів, роботу за принципом "затикання дірок" і в режимі "виконання доручень", іноді навіть непрофільних за базовими знаннями. Співробітники часто погано розуміють, наскільки результат їхньої праці пов'язаний з іншими роботами за проектом, як наслідок вони не можуть вести поточний моніторинг своєї діяльності та визначати власні обґрунтовані потреби для своєчасного виконання покладених завдань. Зокрема, у них виникають проблеми з уточненням інформації у своїх колег у конкретний момент та у певному обсязі, з детальним розбивкою робочого процесу на складові завдання за часом, з'ясуванням, хто приймає результати виконаної роботи.
Загалом, на думку Олексія Малишкіна, питанню комунікацій слід приділяти особливу увагу. Мало в якій компанії у проектному статуті детально прописано, з якого питання куди слід звертатися, скільки часу це вимагатиме і який має бути результат цієї комунікації. На жаль, про це часто забувають: як показує практика, 60% усіх комунікацій проходить в усній формі, і лише 40% мають фіксований документ на виході. Хоча якщо результат ніде не зафіксовано,то через якийсь час він просто-напростоможе забути, і тоді виникне непорозуміння між виконавцями проекту та його замовниками. Саме таким чином прості проекти стають складними, зазначив пан Малишкін.
Рішення – корпоративна система управління проектами
Подолати всі ці проблеми, вважає Олексій Малишкін, допоможе впровадження корпоративної системиуправління проектами (КСУП) або її удосконалення.Завдяки тому, що звітність за проектами представлена в системі в онлайновому режимі і може порівнюватися з напрацьованою практикою, керівники підрозділів і компанії в цілому можуть отримувати необхідну та достовірну інформацію про проблеми, ризики, затримки за строками, перевищення витрат, відсутність ресурсів для прийняття рішень щодо ходу робіт. Крім того, КСУП забезпечує оптимізацію та підвищення якості планування за рахунок використання бібліотеки шаблонів та типових структур раніше виконаних. успішних проектів.
Зокрема, у компанії з'являється можливість отримувати актуальну та достовірну картину (наприклад, на два – шість місяців наперед) ходу реалізації окремих проектів та цілого їхнього портфеля, а також завантаження людських та матеріальних ресурсів за підрозділами. Створення ж корпоративної бази знань (документів) з управління проектами для використання кращих практик, корпоративних шаблонів, бібліотек, проектних документів, метрик завдань у нових (наступних) проектах допоможе скоротити трудові витрати та ресурси на проведення заходів щодо підготовки процедури їх ініціації та управління ними відповідно із планами якості.
Для учасників проектів КСУП означає плановий характер роботи в режимі прозорого розкладу з необхідною та узгодженою деталізацією, адекватність знань та виконуваної роботи. Завдяки детально поданому процесу досягнення мети та чіткому розумінню пов'язаності результату своєї роботи з іншими співробітники можуть вести простий контроль виконання своїх завдань за термінами, попередньо повідомляти колег про взаємодіюза спланованими завданнями, проводити поточний моніторинг власної діяльності та визначати потреби в ресурсах для своєчасного виконання проектних завдань. Результатом служить здатність керувати якістю своєї роботи та зменшувати трудомісткість її виконання.
З організаційної точки зору реалізація оновленого проектного підходу має розпочатися зі створення проектного департаменту (управління), підпорядкованого керівництву компанії, зазначив Малишкін. Крім того, протягом перших шести-дев'яти місяців слід виконати низку завдань, спрямованих на розбудову проектного управління.
Насамперед слід забезпечити інформаційну прозорість проектної діяльності. З цією метою необхідно в короткі терміни реалізувати близько 80% обсягу робіт, а на 20%, що залишилися, витратити решту 80% часу (згідно з правилом Парето). При цьому слід виходити з того, що всі стратегічні цілі вже діючих проектів або досягаються з мінімальними відхиленнями за результатом та термінами, або не досягаються зовсім через перенесення терміну, або вже не є. стратегічними цілями.
Особливо ретельно слід підійти до обліку проектних ресурсів компаній - партнерів організації, які слід розглядати як власні. А оскільки компанії-партнеризазвичай мають свої плани робіт, їх необхідно узгодити з планом проекту загалом, взявши до уваги всі наявні компетенції, способи комунікацій тощо.
Підсумком вирішення цих завдань, на думку Олексія Малишкіна, має стати можливість керувати проектами з урахуванням їхнього взаємного впливу як у найближчій, так і у віддаленій перспективі, а також покращення результативності проектної діяльності за допомогою показників KPI.
Система KPI у проектному управлінні
З точки зору пана Малишкіна, систему KPI необхідно розглядати не як важіль управління, а як показник його результативності, який може використовуватися для цільового планування та контролю в організації. Це спосіб взаємної домовленості та виміру ефективності з боку кількох категорій людей, а також спосіб запровадити деяку єдину системукоординат для різних співробітників, які працюють на різних ділянках процесу.
Ключове місце у системі KPI займає контролінг, тобто. систематичне відстеження виконання поставлених завдань із одночасним аналізом та коригуваннямроботи. Здійснюється на основі дотримання встановлених стандартів та нормативів, постійного регулювання та моніторингу як найважливішого завданняуправління.
Завдяки такому контролю керівництво може отримати інформацію про те, наскільки стабільно протікає той чи інший процес та наскільки передбачуваним є його розвиток. А інструментальнийконтроль дозволяє також визначити, як внесені зміни вплинули на покращення процесу шляхом постійного моніторингу його вихідних даних у часі
Загалом контролінг забезпечує інформаційно-аналітичну та методичну підтримку всіх основних функцій менеджменту, таких як планування, облік, контроль, аналіз та прийняття рішень. Або можна вважати, що це планування з цілям для прогнозованого управління окремим проектом чи всієї фірмою.
Для успішного застосування різноманітного інструментарію Управління Проектами, необхідно визначити, до якого класу належить проект, робота над яким Вам належить.
Все різноманіття проектів можна класифікувати за низкою ознак:
за масштабом;
за складністю;
за якістю виконання;
за рівнем учасників;
по відношенню до підприємства-замовника;
щодо інноваційності задуму.
За масштабом виділяють малі, середні та мегапроекти.
Малі проекти невеликі за масштабом, прості та обмежені обсягами. Так, в американській практиці:
капіталовкладення: до 10 млн доларів;
трудомісткості: до 50 тис. людино-годин.
Приклади типових малих проектів,дослідно-промислові установки, невеликі (часто – у блочно-модульному виконанні) промислові підприємства, модернізація діючих виробництв.
Малі проектидопускають низку спрощень у процедурі проектування та реалізації, формуванні команди проекту (можна просто короткочасно перерозподілити інтелектуальні, трудові та матеріальні ресурси). Водночас скрутність виправлення допущених помилок у зв'язку з дефіцитом часу на їх усунення вимагає ретельного визначення об'ємних характеристик проекту, учасників проекту та методів їх роботи, графіка проекту та форм звіту, а також умов контракту.
призначати одного керуючого (координація має здійснюватися однією особою);
гнучку організацію команди проекту, що забезпечує взаємозамінність її членів;
максимально просту формуграфіка проекту;
чітке знання кожним членом команди своїх завдань та обсягів роботи;
пуск об'єкта повинні здійснювати самі інженери, які розпочинали роботу над проектом.
Мегапроекти - це цільові програми, що містять безліч взаємозалежних проектів, об'єднаних спільною метою, виділеними ресурсами та відпущеним на їх виконання часом. Такі програми можуть бути міжнародними, державними, національними, регіональними (наприклад, розвиток вільних економічних зон, республік, малих народностей Півночі тощо), міжгалузеві (зачіпати інтереси кількох галузей економіки), галузеві та змішані.
Як правило, програми формуються, підтримуються та координуються на верхніх рівнях управління: державному (міждержавному), республіканському, обласному, муніципальному тощо. Мегапроектимають ряд відмінних рис:
високою вартістю (близько $1 млрд. і більше);
капіталомісткістю - потреба в фінансових коштаху таких проектах зазвичай потребує нетрадиційних (акціонерних, змішаних) форм фінансування, зазвичай силами консорціуму фірм;
трудомісткістю - 2 і більше млн. чол.-годин на проектування, 20 і більше млн. чол.-годин на будівництво;
тривалістю реалізації: 5 та більше років;
необхідністю участі інших країн;
віддаленістю районів реалізації, отже, додатковими витратами інфраструктуру;
впливом на соціальне та економічне середовища регіону і навіть країни загалом.
Найбільш характерні приклади галузевих мегапроектів -проекти, що виконуються у паливно-енергетичному комплексі, і, зокрема, нафтогазовій галузі. Так, системи магістральних трубопроводів, що зв'язали нафтогазоносні райони Крайньої Півночі з центром країни, західними кордонами та великими промисловими районами, споруджувалися чергами (нитками) протягом 2-3 років кожна. При цьому тривалість такого проекту становила в середньому 5-7 років, а вартість – понад 10-15 млрд.
Особливості мегапроектіввимагають урахування ряду факторів, а саме:
розподіл елементів проекту за різними виконавцями та необхідність координації їх діяльності;
необхідність аналізу соціально-економічного середовища регіону, країни загалом, а можливо, і низки країн - учасниць проекту;
необхідність виділення як самостійної фази розробки концепції проекту;
розробка та постійне оновлення плану проекту;
необхідність виконання фази планування на всіх рівнях планів: від стратегічного до оперативного з урахуванням імовірнісного характеру та ризику проекту;
необхідність моніторингу проекту із постійним оновленням (актуалізацією) всіх елементів плану проекту;
врахування неповторності (унікальності) мегапроекту.
За складністю виділяють прості проекти, організаційно складні, технічно складні, ресурсноскладні та комплексні проекти.
Складні проекти мають на увазі наявність технічних, організаційних чи ресурсних завдань, вирішення яких передбачає нетривіальні підходи та підвищені витрати на їх вирішення. Природно, практично зустрічаються «скошені» варіанти складних проектів з переважаючим впливом якогось із перелічених видів складності - наприклад, використання нетрадиційних технологій будівництва, значну кількість учасників проекту, складні схеми фінансування та інших.- усе це суть прояви складності проектів (рис. 1.4.1.).
Рис.1.4.1. Визначення складності проектів
За якістю виконання виділяють бездефектні проекти, проекти з підвищеною якістю та стандартні проекти.
Стандартні проекти , Здійснюються з дотриманням всіх діючих норм і правил (будівельних, правових та ін).
Проекти з підвищеною якістю здійснюються із наднормативними вимогами до якості виконуваних робіт.
Бездефектні проекти як домінуючий фактор використовують підвищену якість. Зазвичай вартість бездефектних проектівдуже висока і вимірюється сотнями мільйонів і навіть мільярдами доларів, наприклад, атомні електростанції.
Специфічність цього типу проектів зумовлює вимоги щодо нього:
загальний план проекту, що поєднує проектно-кошторисні та будівельно-монтажні роботи;
поєднаний (з пусковими роботами) графік будівництва;
ранній пуск окремими технологічними лініями, що дозволяє завчасно перевірити та забезпечити якість усіх систем проекту;
використання спеціально розробленої програми аналізу проблем, пов'язаних із проектом, що дозволяє своєчасно їх виявити та усунути;
застосування максимально гнучкої системи управління проектом, що дозволяє своєчасно виявляти та усувати проблеми.
За рівнем учасників розрізняють міжнародні та вітчизняні проекти. Вітчизняні проекти , своєю чергою, можна розбити за рівнем учасників проекту: державний, територіальний чи місцевий проект.
Міжнародні проекти зазвичай відрізняються значною складністю та: вартістю. Їх відрізняє також важлива роль економіці та політиці тих країн, для яких вони розробляються.
Специфіка таких проектів полягає у наступному:
обладнання та матеріали для таких проектів зазвичай закуповуються на світовому ринку. Звідси - підвищені вимогидо організації, яка здійснює закупівлю для проекту;
рівень підготовки таких проектів, зазвичай, вищий, ніж аналогічних «внутрішніх» проектів, враховуючи, зокрема, розбіжності у правової та нормативної базах;
тривалість підготовчого періодудля таких проектів зазвичай більше у зв'язку зі складністю організації та управління;
інформаційна підтримка міжнародних проектів завжди ефективніша (і, відповідно, дорога), ніж для «внутрішніх» проектів.
Такі проекти зазвичай ґрунтуються на взаємодоповнюючих відносинах та можливостях партнерів. Нерідко для вирішення завдань таких проектів створюються спільні підприємства, які об'єднують двох або більше учасників для досягнення деяких комерційних цілей під певним спільним контролем. При цьому кожен партнер робить свій внесок і певним чином бере участь у прибутках.
По відношенню до підприємства-замовника можна виділити внутрішні та зовнішні проекти.
Внутрішні проекти включають доручення персоналу, що працює на підприємстві, роботи, що має відношення до проектів. Тут замовники та виконавці належать до однієї і тієї ж організації, і вся робота, що стосується здійснення проекту, включаючи і визначення стандартів якості проекту, виконується виключно інстанціями, що входять до складу цієї організації. Це означає наявність високого ступеня гнучкості щодо елементів отриманого замовлення. Однак у складних випадках це може призвести до того, що зовнішнє здійсненняпроектів буде приречено на невдачу, оскільки така гнучкість не може бути досягнута юридичним шляхом. Можливі, наприклад, такі внутрішні проекти:
Проекти щодо покращення якості;
Проекти щодо логістики;
Заснування високопродуктивної фабрики;
Оновлення організаційної структури;
Розробка продукту;
планування виробництва;
запровадження продукції на нових ринках;
Введення (автоматизованого проектування/автоматизованого виробництва);
Зменшення часу розробки продукту наполовину.
Зовсім іншого роду робота за межами підприємства, що характеризується зовнішнім замовником чи виконавцем. Партнери тут розробляють умови робіт на основі юридично надійного договору, виконання умов якого є обов'язковим. За недостатньо чітко сформульованих юридичних ухвал це може призвести до непорозумінь, що стосуються домовленостей щодо робіт, які підлягають виконанню.
Це може призвести до вимог щодо відшкодування збитків, які загальмують здійснення проекту або інакше негативно впливають на роботи, що проводяться. Важливість, яка надається позовам щодо відшкодування збитків, знаходить своє відображення у так званому claimmanagement, що займається професійним відображенням позовів щодо відшкодування фінансових витрат, що висуваються одним із партнерів по роботі в проекті.
За інноваційністю задуму проекту розрізняють традиційні та нетрадиційні проекти.
Підрозділ проектів на традиційні та нетрадиційні значною мірою залежить від того, наскільки ідея проекту вже відома чи якою мірою вона є новаторською. В якості традиційних,або стандартних, проектів можна розглядати багато заходів з галузі архітектури. Далі слід згадати, наприклад, проекти з будівництва доріг, а також будь-які інші, які близькі до поняття стандартних. При здійсненні всіх цих проектів є можливість спиратися на відому технологію і планування результатів.
До нетрадиційним,тобто нестандартним, проектам можуть бути віднесені заходи, які є співпрацею між підприємствами. Крім того, нетрадиційними слід називати надзвичайно великі проекти в момент їхнього першого випробування. Прикладом може бути «Manhattan Engineering District Project», у якого у США 1941 року створювалася атомна бомба. Сюди можуть бути віднесені і космічні проекти. Для традиційних проектів необхідні також і традиційні методиїх здійснення, тоді як нетрадиційні проекти часто потребують нестандартних підходів. У разі успіху нетрадиційного проекту він перетворюється на розряд традиційних і стає стандартним.
Якщо вже випробувані проекти здійснюються в інших областях, виявляючи при цьому високий ступінь новаторства для здійснюючої сторони, то для виконавця такі проекти також слід розглядати як нестандартні. У цих випадках проекти дуже часто беруть на себе функції «вирішувача завдань»або «піонера»,які вводяться заново, незважаючи на те, що їхня технологія досить широко відома. Спроба отримати інформацію безпосередньо з досвіду попередніх проектів або запозичити її з відповідної літератури практично марна, оскільки саме значна зміна структури потребує часу та довгострокової стратегії виконання на місці здійснення самого проекту. Нетрадиційні проекти можуть мати і екзотичний характер, і відбувається це, коли менеджмент проектів намагається вторгнутися в ті галузі, в яких досі практично не підозрювали його існування. Таке використання менеджменту проектів мистецтво.
слухати вірш
1читати вірш
Проект був складним. Він не вдавався.І архітектор із напруженим лобом
Вважав, курив, зітхав і чортихався,
Схилившись над непокірним кресленням.
Але в двері раптом постукали. І сусідка,
Студентка, що за стінкою жила,
Алея яскравіша, ніж її жакетка,
Сказала швидко: "Здрастуйте". І увійшла.
Зітхнула, сіла в крісло, помовчала,
Потім сказала, жмурячись від вогню:
- Ви старші, ви досвідченіші за мене...
Я за порадою... Я до вас прямо з балу...
У нас був вечір пісні та весни,
І два студенти в цій строкатій завірюсі,
Не знаючи, звичайно, один про одного,
Сказали мені про те, що закохані.
Але для чужої душі рентгена немає,
Я дуже вашою думкою дорожу.
Кому мені вірити? Дайте мені пораду.
Зараз я вам про кожне розповім.
Але, мабуть, він не прийняв розмови:
Відкинув циркуль, перекинув туш
І, дивлячись їй у наївні озера,
Сказав сердито: - Дурниця і нісенітниця!
Ми не на ринку та не в магазині!
Порада вам потрібна? Ось вам моя порада:
Обом завтра відповідайте "ні!",
Тому, що почуття немає тут і близько!
А ось коли полюбите всерйоз,
Зрозумієте самі, якщо проб'є годину.
Душа відповість на будь-яке запитання.
А він усе сам помітить та зрозуміє!
Закінчивши промову впевнено та вагомо,
Він був чимало здивований, коли
Вона, схопившись раптом, випалила різко:
– Все сам помітить? Нісенітниця і нісенітниця!
Злегка злякавшись від цих слів,
Він повернувся був для відсічі,
Але зустрів не наївні озера,
А пару злих, вигострених клинків.
Він сам зрозуміє? Ви так зараз сказали?
А якщо в нього судна кров?
А якщо там, де у людей кохання,
Тут лише проекти, балки та деталі?
Він усе зрозуміє? А якщо він плював,
Що в чиємусь серці то вогонь, то тремтіння?
А якщо він не людина – креслення?!
Сухий пунктир! Бездушний інтеграл?
На мить він завмер, до підлоги прибитий,
Потім, похнюпившись, спалахнув чомусь.
Вона ж, схлипнувши, обернулася круто
І, грюкнувши дверима, вибігла геть.
Весняний вітер у кватирку увірвався
Гудів, кружляв, паперами шарудів...
А біля столу "бездушний інтеграл",
Заплющивши очі, щасливо посміхався...
На практиці ми часто стикаємося з тим, що керівник проекту хоче прискорити процес розробки – його не влаштовує швидкість постачання нового функціоналу. Як правило, такі клієнти потребують складних продуктів на зразок системи управління госпіталем, системи торгівлі на біржі, банківських системах, ДПВ.
У таких випадках можна підключити нову команду фахівців, налагодити процеси вже існуючої або об'єднати і те, і інше. Розглянемо, які плюси та мінуси є у кожного підходу. Відразу зазначимо, що у статті розглядається розробка великих та складних проектів (понад 10 000 годин).
Чому не можна відразу підключати нових спеціалістів
Часто найпростіший і очевидніший варіант збільшення швидкості розробки - підключити нових фахівців чи команду. Керівник проекту здається, що так можна прискорити швидкість доставки business-value до кінцевих користувачів. На практиці таке виходить не завжди, особливо коли процеси у проекті потребують переробки. Наведемо один приклад із нашої практики.Необхідно було підключити дві команди до існуючого проекту, що розвивається. Проект розроблявся понад 4 роки і містить велика кількістьпідсистем (понад 20) зі своїми загальними механізмами та сервісами. Повний регрес вимагав участі 5-7 QA інженерів та близько 4-6 робочих днів. При вході до проекту та виходу команд на необхідний рівень розв'язання задач зіткнулися з такими труднощами:
- Одна частина вихідних кодів системи була під керуванням системи керування версіями svn, інша git. SVN раніше був дуже популярним, проте для великих командних проектів і частих паралельних змін погано підходить. Тому до переходу на git частину часу губилася на Мерджі, виправлення конфліктів та інші операції, пов'язані з розгалуженням у svn.
- Для розгортання оточення була застаріла інструкція, тому команди зібрали всілякі підводні камені цієї системи, а перші завдання змогли розпочати лише через 3-4 дні.
- Ключові аналітики, технічні фахівці були зайняті підготовкою релізу, тому неможливо було оперативно отримувати уточнювальну інформацію щодо нових завдань. Постановка завдань була дуже верхньорівневою. Це суттєво уповільнювало реалізацію завдань.
- Workflow задач був складним, спочатку команди "спотикалися" як чинити із завданням протягом її життєвого циклу.
- Спочатку клієнт хотів обійтися тільки силами своїх QA-інженерів, але у них не виходило повноцінно і в потрібні терміни перевірити новий функціонал підключених команд розробки через велике завантаження. Тому доводилося працювати з овертаймами.
- Code review проводився згідно з усталеними на проекті принципами та критеріями. Критерії були задокументовані. Тому витрачався додатковий час на виправлення зауважень.
- додаткові тимчасові витрати, які можна було спрямувати на вирішення бізнесових завдань
- уповільнення розробки всієї системи
- або овертайми.
Аналіз процесів
Перш ніж підключати нових фахівців, варто розібратися, як влаштована робота команди – необхідно знайти та усунути «вузькі» місця. Зазвичай цим питанням займається PM, оскільки він відповідає за проект, і саме йому хочеться витрачати менше сил на відстеження процесів.Усунення «вузьких» місць рухає проект уперед. Наприклад, скорочується час входження у проект нового спеціаліста чи команди фахівців, підвищується залученість команди до проекту, зменшується вартість години з допомогою правильної реалізації завдань із першого разу. Якщо прибрати всі «вузькі» місця, керівник проекту отримає настільки швидкий приріст до швидкості розробки, наскільки дозволяють поточні практики та контекст проекту. Загалом усім від цього добре.
Аналіз «вузьких місць» можливий із двох сторін: з боку топ-менеджменту/експерта та з боку команди. Розберемо кожен варіант окремо.
Сторонні експерти.У цьому підході процес роботи аналізує або зовнішня команда зовнішніх експертів, або керівник проекту спільно з тимлідом. З останніми не факт, що вийде - важливо, щоб вони могли відкинути всі нюанси проекту, інакше аналіз буде безглуздим.
Важлива умова – підтримка керівництва проекту та готовність до змін.
Відповідно, експерт занурюється в проект і детально аналізує документацію, вихідний код, структуру БД, виробничий процес(Від проведення аналітики до релізу). Поетапно робота виглядає так:
- Розглядається весь ланцюжок робіт на проекті від початку до кінця. Вимірюється час кожного процесу.
- Будується діаграма ганта. Експерт дивиться, які процеси йдуть паралельно, які один за одним.
- Експерт думає як зробити кожен процес продуктивнішим і менш витратним. Як правило, експерт інтуїтивно розуміє у яких місцях виникають найбільші складнощі та починає їх розкручувати на предмет можливої модернізації.
Плюси цього підходу:
- Роботу аналізує людина, яка не бере участі у проекті. У нього незамилений погляд на процеси, отже, він може знайти ті проблеми, які не видно членам команди.
- Експерт, як авторитет, здатний переконати команду прийняти зміни у процесах. Команди, які довго працюють над проектом, не прагнуть нововведень. Для них це великий стрес, тому що доведеться наново переучуватися. Причому така реакція йде навіть на ті зміни, які допоможуть ефективніше працювати.
- Швидке впровадження рішень – від 2-15 днів. Все залежить від глобальності змін та бюрократичності всередині організації.
- Команда проекту переймає досвід сторонніх експертів. Надалі це допоможе самостійно налаштовувати процеси.
- Експертам потрібно витратити багато часу, щоб розібратися у тонкощах. Команда може вивчити історію проекту за день, тоді як експерту потрібно щонайменше півтора тижні.
Що з цим робити: ставити цілі аналізу разом із керівником проекту/тимлідом. Дати експерту всі «вступні» проекти, не приховувати деталі.Якщо клієнт настільки лояльний, що готовий ітераційно аналізувати проект, потрібно скористатися нагодою та погоджуватися на такі умови. Згодом можна буде коригувати напрямок аналізу після кожної ітерації, фокусуючись лише на потрібному.
- Деякі члени команди можуть не згодні з рішенням. Згодом вони можуть саботувати проект, погано виконувати домовленості, а це погано позначається на загальному настрої команди.
Що з цим робити: обговорювати кожне рішення разом із командою, а не ставити їх просто перед фактом
Ідеальний варіант: експерт аналізує процеси самостійно, а потім обговорює їх із ключовими людьми на проекті. Якщо є протиріччя – вони обговорюють їх. Так накопичиться маса лояльних до змін людей, які впливатимуть на інших членів команди. Можна буде переконати найзатятіших скептиків.
- Збирається вся команда проекту
- Один із учасників бере на себе роль фасилітатора (scrum-master). Він стежить, щоб розмова йшла у конструктивному ключі.
- Команда обговорює їхні підходи до роботи. Розглядаються всі аспекти: процеси, написання коду, постановка завдань тощо. Потім виділяються плюси та мінуси.
- На загальному голосуванні домовляються про зміни: плюси слід закріпити, мінуси усунути.
- Через 3-4 тижні процес повторюється. Команда дивиться на результати, і якщо все влаштовує, то робота триває.
Важливі умови:
- Підтримка керівництвом будь-яких змін та нововведень.
- Згуртованість команди та націленість на покращення.
Плюси підходу:
- Залучення кожного учасника до обговорення проекту.
- Можливість виявити все позитивні моментипроекту та за необхідності сформувати їх у якийсь зразок (best practice).
- Учасники команди обмінюються один з одним досвідом.
- Поступове вирішення проблем, починаючи від тих, які найбільше уповільнюють команду та проект, закінчуючи невеликими покращеннями.
- Є ризик, що буде вирішено лише незначні проблеми, а всі ключові так і залишаться недоторканими.
Що з цим робити: PM, тимлід та фасилітатор мають через авторитет впливати своєю думкою на команду Їхнє завдання – привернути увагу до важливих проблем ще на етапі обговорення. - Для серйозних змін, які вимагають великих трудовитрат, потрібен додатковий час на узгодження з керівництвом. При цьому не факт, що керівництво погодиться із нововведеннями.
Що з цим робити: відстоювати свою точку зору перед керівництвом - це єдине рішення - Якщо у команді немає постійного навчання(конференції, обмін досвідом, тренінги), то швидше за все досягнуті рішення будуть застарілими і менш ефективними.
Що з цим робити: постійно обмінюватись досвідом. Брати участь у профільних конференціях, мітапах, внутрішніх тренінгах. Якщо мова йдепро великої компанії, то гарним варіантомбудуть демо-дні. На таких заходах команди показують, яких результатів вони досягли у роботі.
Якщо ж після усунення «вузьких» місць, керівник проекту вважає, що capacity не досягнув потрібного рівня, то можна підключати нові команди.
Підготовка інфраструктури для нових команд
На цьому етапі варто провести підготовчі роботи, які скоротять тривалість та вартість розробки, допоможуть зберегти нервові клітини розробників. Розглянемо якими мають бути умови:- Завдання для нової команди мають бути детально деталізовані. До кожної з них можна приступити без очікування – немає залежності від поточних чи майбутніх завдань. Окреслено зони відповідальності кожної команди.
Якщо цього не буде, то більшість нової команди буде простоювати чи займатися другорядними завданнями, які мають найменший впливом геть цінність товару. - Архітектура проекту «правильна», тобто. розбито на модулі, підсистеми, загальні компоненти.
Якщо цього не буде, Підключити нову команду не вийде. Розробники працюватимуть під управлінням поточного тимліду, але людина може ефективно управляти не більше ніж 7-9 людьми. Тімлід розриватиметься, а деякі учасники команди без діла чекатимуть поки їм дадуть завдання.
Якщо немає можливості виділити відокремлені ділянки коду проекту, але рухатися вперед треба, можна спробувати обійти це обмеження. Слід поділити проект на кілька частин через рефакторинг.
Інший варіант - після занурення в проект двох-трьох осіб віддавати на розробку новій команді дедалі більші бізнес-функції. Так команди розроблятимуть проект ізольовано одна від одної, а за рахунок нового тимліду (людини, яка поринула у тонкощі) скоротить навантаження на основного тимліду.
- Процеси роботи у проекті докладно описані. Наприклад, є workflow завдання, показується виконання завдання в системі управління версіями (практика показує, що не у всіх стандартний GitFlow), описана взаємодія між учасниками проекту.
Якщо цього не буде, то на проекті твориться хаос. При цьому керівник проекту займатиметься лише «ручним» екстреним управлінням. - У загальних компонентів та модулів є актуальна, зрозуміла документація. Є unit та інтеграційні тести основних частин. Існує зрозумілий опис архітектури всього проекту, загальних механізмів, а також інструкція, як їх слід застосовувати. Якщо вищепереліченого поки що немає, необхідно додати подібні завдання до пулу технічного боргу виправлення ситуації.
Якщо цього не буде, підвищується ризик виконання подвійної роботи. Буде написано неякісний або дубльований вихідний код. Надалі це призведе до більш дорогої підтримки проекту. Як правило, підключення нової команди передбачає можливе підключення ще кількох команд. Відповідно тимчасові витрати масштабуватимуться на величину кратну кількості команд.
- Зафіксовано правила написання коду – код конвенції, скриптів оновлення структури БД – міграції, загальні принципиобов'язкового code review. Незважаючи на сильну схожість, напевно, у кожного проекту є свої особливості.
Якщо цього не буде, то складність та вартість подальшої підтримки проекту багаторазово зросте.
Як ми підключали додаткову команду на проект
У нас був кейс, коли в проекті потрібно було терміново прискорити процес розробки. До здачі чергової мажорної версії у промислову експлуатаціюзалишалося 2-3 місяці. Сам проект був складною системою, яка розроблялася однією командою протягом 3-4 років.Насамперед ми занурилися в контекст самого проекту. В результаті вийшла наступна картина найвужчих місць проекту:
- Немає єдиної точної інформації про те, яким чином мають бути реалізовані фічі. Список завдань, багів, покращень застарів.
- Немає continuous Integration, а технологія ведеться у двох гілках.
- Процес тестування продукту не налагоджений. Наприклад, QA-інженери можуть знаходити баги, які вже були виправлені, що призводить до додаткових трудовитрат.
- База тест-кейсів була в зародковому стані. Окремі QA-інженери починали писати кейси собі. Через це ніхто не міг дати певну оцінкуякості продукту та можливим ризикампід час випуску нової версії.
- Процес роботи від постановки до схвалення замовником не документований. Неможливо було спрогнозувати точний склад функцій релізу, як та інші менш значимі пункти.
Після аналізу, ми створили план усунення описаних вище пунктів. Звичайно, колектив не відразу погодився зі змінами, але з підтримкою керівництва та виробленням чітких термінів ми змогли вмовити кожного члена команди.
Узгодили наші дії з ключовими особами проекту: PM, тимлідом, провідним аналітиком. Разом, ці три людини є єдиним центром управління командами на стороні замовника. Вони додатково просувають рішення та контролюють їх впровадження на практиці. Без такої управлінської команди неможливо координувати дії більше трьох команд.
В результаті впровадили оптимізували такі процеси:
- Вибудували комунікації між усіма членами команди продукту – розробники, аналітики, фахівці з тестування.
- Задокументували критичні та складні функції для більш прозорого тестування, усунення дефектів, дозволу спірних ситуацій, подальшого планування робіт
- Оптимізували процеси розробки. Прийнятий WorkFlow та GitFlow проекту. Допомогли налаштувати Continuous Integration та запуск автотестів в автоматичному режимі.
- Збільшили швидкість збирання тестових стендів у два рази.
- Організували процес правильного тестування. Впровадили регресійне тестування після завершення кожної ітерації.
- Впровадили процес планування ітерацій.
- Провели тестування навантаження.
- Введення у промислову експлуатацію через 3 місяці.
- Виправлено 70% багів
- Реалізовано чотири серйозні фічі
- Оптимізована та збільшена у 8 разів швидкість завантаження деяких сторінок
- Отримано точну інформацію про якість всього продукту
- Побудований RoadMap ітерацій
Висновок
Основних способів збільшення швидкості розробки проектів два: усунути «вузькі» місця та збільшити виробничі потужності. У першому випадку можна отримати 30-40% збільшення швидкості розробки, у другому 70-80%. Додаткові команди не дають подвійного приросту продуктивності, оскільки більше часу витрачається взаємодія між кількома командами.Ключовими чинниками успіху розширення розробних команд є:
- проведення підготовчих робіт,
- налагоджені процеси,
- керівник чи учасник проектної команди, який би просував та контролював діяльність команд,
- єдиний центр керування командами.
