Skip to main content
LibreTexts - Ukrayinska

1.1: Основи управління проектами - принципи та практики

  1. Last updated
  2. Save as PDF
  • Page ID
    104541

    • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Нічого не терпить, крім змін.
    Геракліт, 535 — 475 рр. До н.е.

    Цілі

    Прочитавши цю главу, ви зможете

    • Визначте терміни, пов'язані з управлінням проектами
    • Обговоріть дві основні якості хороших менеджерів проектів
    • Поясніть різницю між геометричним і живим порядком
    • Визначте «результат проекту», «успіх проекту» та «стійкість» в контексті повного життєвого циклу проекту
    • Визначте чотири ролі менеджера проекту
    • Надайте базовий вступ до Lean, включаючи шість принципів Lean
    • Поясніть основи розробки програмного забезпечення Agile, включаючи спринти та історії продуктів

    Великі ідеї в цьому уроці

    • Живий порядок мислення визнає, що система речей завжди перебуває в процесі переробки себе, і що система завжди - на якомусь рівні - в стані невизначеності. В управлінні проектами це говорить про те, що проекти відбуваються в динамічних середовищах, і що несподівані події слід вважати частиною життєвого циклу проекту. Вона принципово адаптивна.
    • Менеджери проектів традиційно ідеалізують більш нормативний геометричний порядок, в якому один етап обов'язково веде до наступного етапу. Це важлива складова управління проектами, але якщо покладатися виключно на геометричне мислення порядку може призвести до неефективних і неефективних результатів.
    • Бережливе мислення фокусується на усуненні відходів. В управлінні проектами Lean мислення забезпечує спосіб зосередитися на визначенні цінності клієнта, що є єдиним визначенням, яке має значення.

    1.1 Технічне управління проектами в сучасному світі

    Повний підсумок останніх статистичних даних щодо управління проектами див. Щорічний звіт Інституту управління проектами «Пульс професії». Ви можете прочитати версію звіту за 2018 рік тут: PMI Pulse of the Profession 2018

    Проекти за визначенням ефемерні - вони приходять і йдуть, залежно від потреб організації, і врешті-решт наближаються до кінця. Згідно з Кембриджським словником англійської мови, проект - це «частина запланованої роботи або діяльності, яка завершується протягом певного періоду часу і призначена для досягнення певної мети» (2018). Швидкоплинний характер проектів означає, що організації з менш ніж оптимальним рівнем кваліфікації управління проектами часто не в змозі розробити систематичні процеси управління ними. Після завершення проекту всі рухаються далі, готуючись до наступного, ледь зворотним поглядом на те, що робило і не працювало в старому проекті. Іншими словами, цим організаціям бракує узгодженого підходу до управління проектами — «застосування процесів, методів, знань, навичок та досвіду для досягнення цілей проекту» (Асоціація управління проектами н.д.). Така відсутність системного підходу особливо проблематична в технічних сферах, що призводить до надзвичайно високого рівня відмов технічних проектів у багатьох галузях промисловості.

    Швидкий пошук в Інтернеті щодо успішності технічних проектів пропонує деякі вражаючі факти та цифри. Залежно від того, яке дослідження ви читаєте, проекти провалюються зі ставками від 20 до 80 відсотків. І кидати більше грошей на проблему не допомагає. Дійсно, чим вищий бюджет проекту, тим більша ймовірність його невдачі (Mieritz 2012). Одне дослідження показало, що ІТ-проекти з бюджетом понад 15 мільйонів доларів є фіаско управління проектами: «В середньому великі ІТ-проекти працюють на 45 відсотків більше бюджету і 7 відсотків з часом» (Bloch, Blumberg and Laartz 2012). Вердикт ще більш протверезний для промислових мегапроектів, тобто для промислових проектів вартістю понад 1 мільярд доларів. За словами Едварда Мерроу, «сектор видобутку нафти і газу коштує найгірше; 78 відсотків мегапроектів у цьому промисловому секторі класифікуються як невдачі» (2011, 49).

    Як організації можуть знайти вихід з цієї мури? Створюючи культуру систематичного, професійного управління проектами, яка цінує навички, обговорювані протягом цієї книги. Дослідження послідовно показують, що організації, які впроваджують технічні методи та процеси управління проектами, отримують багату винагороду за успіхи проектів. Ця книга зосереджена на розробці підходу до технічного управління проектами, який є гнучким, адаптивним та відкритим для нового навчання. Він надає багато практичних пропозицій, але не детально розглядає конкретні методи. Для вказівки щодо гайок та болтів управління проектами див Управління проектами: Управлінський процес, Ерік Ларсон та Кліффорд Грей.

    Це 2,5-хвилинне відео від Інституту управління проектами описує переваги фінансової установи, яка створила офіційний офіс управління проектами (PMO) для управління всіма своїми ІТ-проектами:

    Елемент YouTube був виключений з цієї версії тексту. Ви можете переглянути його онлайн тут: pb.libretexts.org/web1/? p=40

    Переможець премії PMO року 2015 - Федеральна кредитна спілка ВМС

    1.2 Будьте їжаком і лисицею

    Життєвий порядок, Деяка історія

    Хоча Анрі Бергсон був першим мислителем, який використав термін «живий порядок», ідея про те, що життя - це безперервний процес непередбачуваних змін, має давнє коріння. Фрагменти, які залишилися від роботи досократичного грецького філософа Геракліта, дають глибоке розуміння цієї ідеї. Він хвацько звів постійно мінливу природу Всесвіту до цієї простої приказки: «Жодна людина ніколи не ступає в одну річку двічі». За Гераклітом, природа знаходиться в постійному стані змін. Дійсно, зміни є єдиною константою, на яку може покластися людина. Релігійні мислителі давно визнали, що зміни в нашому житті неминучі і неминучі. Наприклад, ідея мінливості є ключовою складовою буддизму. Біблія в Екклезіасті 9:11 вказує на марність прагнення до неминучого:

    Знову я побачив, що під сонцем раса не для стрімких, ні битва сильним, ні хліб мудрим, ні багатство розумним, ні милість до тих, хто знає, але час і шанс наздоганяють їх усіх.

    Коли наукова революція відбулася в західній думці, це розуміння живого порядку пішло під землю, тільки щоб знову з'явитися в творчості мислителів і художників початку ХХ століття, як Бергсон, у відповідь на Першу світову війну та широко поширений індустріалізм.

    У своїй книзі Оволодіння лідерською роллю в управлінні проектами: практики, які забезпечують чудові результати, Олександр Лауфер пояснює дві основні якості керівника проекту, спираючись на їжака та метафору лисиці, яку прославив філософ Ісая Берлін:

    Лисиця - хитре і творче істота, здатне придумати незліченну кількість складних стратегій для крадькома атак на їжака. Їжак - це болісно повільна істота з дуже простим щоденним порядком дня: пошуком їжі та підтримкою свого будинку. Щодня лисиця чекає їжака, плануючи напасти на нього. Коли їжак відчуває небезпеку, він реагує таким же простим, але потужним способом кожен день: він закочується в ідеальний кульку з кулею гострих шипів, спрямованих назовні на всі боки. Потім лисиця відступає, починаючи планувати свою нову лінію атаки на наступний день. (Серпень 2012, 220)

    Перевага лисиці в тому, що його складне розуміння світу дозволяє йому випробувати безліч можливостей, адаптуючи стратегії і тактики у відповідь на ситуацію, що склалася. Їжаки мають одну грандіозну стратегію, яка дозволяє їм спростити весь досвід у «єдину загальну концепцію, яка об'єднує та керує всім, що вони роблять». Як ви побачите на Уроці 2, де ми обговорюємо організаційну стратегію, підхід «їжак» є кращим, коли мова йде про прийняття довгострокових рішень щодо майбутнього організації. Але коли справа доходить до управління проектами, обидві стратегії є потужними, і обидві можуть бути ефективними, залежно від вашої ситуації. Лауфер стверджує, що успішні менеджери «поводяться і як їжаки, і лисиці, хоча і поміщають їжака на водійське місце».

    Протягом цього курсу ми будемо використовувати підхід, подібний до технічного управління проектами, зберігаючи відкритий розум і вивчаючи багато ліній атак, доступних в конкретному проекті. Але ми також зробимо акцент, подібний до їжака, на кількох основних принципах, зокрема основних принципах Lean управління проектами. У той же час, всі наші обговорення будуть проінформовані про відмінність двох фундаментальних підходів до управління проектами: традиційним, або геометричним підходом, і більш адаптивним підходом, живим порядком.

    1.3 Два типи порядку: живий і геометричний

    У своїй книзі 1907 року «Творча еволюція» французький філософ Анрі Бергсон досліджував природу людської творчості та її ставлення до порядку. На думку Бергсона, під «порядком» ми взагалі маємо на увазі механістичну, заздалегідь визначену, лінійну залежність між речами. Подія A веде до події B; Подія B веде до події C; Подія C веде до події D; і так далі, без можливості зміни або адаптації. Ми також схильні розглядати творчість як щось, що виникає лише у стані розладу - тобто коли жоден тип порядку не очевидний. Вільномисний художник - стереотип, заснований на такому способі мислення. Але Бергсон стверджував, що розлад, який ми пов'язуємо з творчістю, насправді просто інший тип порядку (222-224).

    Знову звернемося до Олександра Лауфера, який намалював деякі потужні ідеї щодо управління проектами з роботи Бергсона, які він підсумовує наступним чином:

    Бергсон стверджував, що немає такого поняття, як безлад, а скоріше два види порядку: геометричний і живий порядок. Хоча в «геометричному порядку» Бергсон пов'язаний з традиційною концепцією порядку, в «живому порядку» він посилався на такі явища, як творчість особистості, витвір мистецтва або безлад у моєму кабінеті. (2012, 214)

    Протягом цієї книги ми розглянемо і порівняємо геометричний порядок з живим порядком, з метою розробки креативного, реалістичного, функціонального підходу до управління проектами.

    Якості живого і геометричного порядку

    В управлінні проектами геометричний порядок узгоджується з традиційним управлінським мисленням. Це поняття порядку пов'язано з передбачуваними взаємозв'язками між етапами розвитку, такими як відносини, показані на малюнку 1-1, причому один етап обов'язково веде до наступного.

    Малюнок 1-1: Геометричний порядок передбачуваний, один етап веде до наступного

    Менеджери проектів традиційно ідеалізують таку впорядковану прогресію проекту. Дійсно, це рушійна сила процесно-орієнтованого підходу до управління проектами, на яку прагнуть зосередитися такі організації, як Інститут управління проектами. Це невід'ємна складова управління проектами, і недосвідчені керівники проектів повинні почати з освоєння геометричного підходу до своєї роботи. Однак, якщо покладатися виключно, геометричне мислення порядку може призвести до неефективних і неефективних результатів.

    Навпаки, мислення живого порядку визнає, що система речей завжди перебуває в процесі переробки себе, і що система завжди - на якомусь рівні - в стані невизначеності. В управлінні проектами це говорить про те, що проекти відбуваються в динамічних середовищах, і що несподівані події слід вважати частиною життєвого циклу складного проекту. Це те, чому досвідчені менеджери проектів навчаються з часом. Але навіть недосвідчені керівники проектів можуть спробувати включити розуміння життєвого порядку в свою роботу.

    Малюнок 1-2 ілюструє характеристики живого і геометричного порядку. Майте на увазі, що проект може мати якості обох.

    Малюнок 1-2: Характеристика порядку життя і геометричного порядку

    Можливо, вас закликають використовувати методи геометричного порядку в одній ситуації та методи живого порядку в іншій. Наприклад, підготовка прогнозу погоди на звичайний день в Сан-Дієго, де погода з дня на день мало змінюється, є завданням геометричного порядку. Навпаки, підготовка прогнозу погоди для узбережжя Флориди з ураганом, який, як очікується, вдарить берег п'ять днів у майбутньому, є проектом життєвого порядку. Часто етап планування відбувається в живому порядку. Потім, у міру того, як ви почнете більше дізнаватися про проект і чого очікувати, виконання протікає в геометричному порядку. Але коли трапиться щось несподіване, вас можуть раптово зануритися назад в живий лад. Ви повинні бути готові рухатися вперед і назад серед геометричних і живих прийомів, адаптуючись до ситуації в міру необхідності.

    Традиційні процеси управління проектами засновані на презумпції, що проект може бути спланований до найдрібніших деталей, і що після завершення етапу планування завдання керівника проекту полягає у виконанні проекту відповідно до цього плану, без сюрпризів. Реальність сучасного світу зовсім інша. У своїй книзі 1991 року «Управління як виконавське мистецтво: нові ідеї для постійного світу хаотичних змін» Пітер Вайлл стверджував, що сьогоднішні організації фактично працюють у стані «постійної білої води». Олександр Лауфер описує аргумент Вайля наступним чином:

    Використовуючи метафору «постійної білої води», Вайлл звертає нашу увагу на те, що зовнішнє середовище сучасних проектів сповнене сюрпризів, має тенденцію до створення нових проблем і є «брудним» і погано структурованим. (2012, 214)

    Протягом цієї книги ми зосередимося на способах управління технічними проектами в постійному світі білої води.

    Передбачення непередбачуваного

    Геометричний порядок, Деяка історія

    Геометричний порядок є продуктом Наукової революції. Починаючи з середини 1500-х років, люди використали силу систематичної думки, щоб досягти гігантських стрибків вперед у математиці, фізиці, біології та багатьох інших областях навчання. Мислителі з численних країн сприяли досягненням, які зробили можливою сучасну науку, але, мабуть, найважливішим був Ісаак Ньютон, який моделював всесвіт, заснований на систематичних, незмінних законам, наслідки яких можна було точно передбачити математичними рівняннями.

    Основні людські досягнення останніх п'яти століть не могли б відбутися без такого типу систематичного мислення. Сучасне життя, як ми знаємо, не існувало б без неї. Однак, як керівники проектів, основною проблемою яких є планування проектів, які відбуваються з часом, ми повинні розуміти межі нашої здатності прогнозувати майбутнє в постійно мінливому світі.

    Все, що включає людей, які роблять що-небудь протягом певного періоду часу, з обмеженими ресурсами, передбачає певну кількість непередбачуваності. Це означає, що проекти неминуче формуються живим порядком. Ви можете подумати, що ви добре впораєтеся з тим, чого очікувати від ваших колег та зацікавлених сторін проекту протягом усього проекту, але часто риси, які ви можете вважати найбільш передбачуваними, виявляються абсолютно ненадійними.

    Не так давно це усвідомлення потрясло галузь економіки, яка була заснована на припущенні, що люди були цілком передбачувані у своїй тенденції робити вибір, який підвищує їхнє фінансове благополуччя. У своїй новаторській роботі в області поведінкової економіки Річард Талер продемонстрував, що нібито незаперечна ідея про те, що люди діють раціонально в своїх власних інтересах, є спірною в кращому випадку і, ймовірно, не відповідає дійсності (Коліно 2015). І все ж економісти послідовно відмовляються брати до уваги ненадійність свого основного заповіді. За словами Талера, «Економісти знижують будь-які фактори, які не впливали б на мислення раціональної людини. Ці речі нібито не мають значення. Але, на жаль, для теорії, багато нібито невідповідних чинників мають значення» (2015).

    Талер продовжує стверджувати, що «якщо ви не Спок», нібито невідповідні речі, такі як те, як ви ставитеся до економії на пенсію, можуть мати набагато більш глибокий вплив на вашу економічну поведінку, ніж просто користі (2015). Успішні керівники проектів досягають успіху, частково тому, що вони ніколи не ігнорують силу нібито невідповідних речей, щоб вплинути на результати проекту. Оскільки ми можемо сміливо припустити, що переважна більшість ваших майбутніх товаришів по команді не будуть вулканами, ви, мабуть, також повинні припустити, що нібито невідповідні речі в кінцевому підсумку матимуть непередбачені наслідки для проектів, якими ви керуєте. Ви ніколи не знаєте, який живий порядок кине ваш шлях, коли проект розгортається.

    Це не означає, що, як керівник проекту, ви можете обійтися без очікувань геометричного порядку. Зовсім навпаки. Оскільки це книга з технічного управління проектами, наше мислення обов'язково буде стосуватися геометричного порядку. Адже технічні проекти передбачають технічні продукти та послуги, ефективність яких регулюється передбачуваними законами. Гравітація завжди працює однаково, тому інженери повинні враховувати це. Останні комп'ютерні процесори можуть працювати тільки так швидко в сучасних умовах, і тому розробники програмного забезпечення також повинні враховувати це.

    Однак потрібно остерігатися тенденції думати, що оскільки технічні продукти та послуги самі по собі передбачувані, проекти, необхідні для їх виробництва, будуть однаково передбачувані. Це просто не так. Оскільки це книга про управління, зусилля, яке включає людей, які виконують завдання з часом, наше мислення буде глибоко вкоріненим у живий порядок.

    1.4 Життєвий цикл проекту та порядок життя

    Коли ви відкриваєте очі на постійно мінливий характер життєвого порядку, ви можете почати оцінювати потенціал змін, притаманний протягом життєвого циклу проекту. Те ж саме стосується результату проекту - будь то будівля, новий смартфон або програмне забезпечення для сільськогосподарської техніки. Продукт або результат проекту створюється, підтримується, адаптований, оновлений та зноси/виведений на пенсію різними проектами протягом його життя. Кожен з цих проектів схильний до невизначеності в живому порядку, що збільшує складність прогнозування того, як буде виглядати результат проекту в майбутньому, і чи дійсно він виявиться придатним за призначенням. Це, в свою чергу, ускладнює етап планування будь-якого проекту, особливо для речей, які в кінцевому підсумку судять про те, наскільки легко його можна демонтувати та утилізувати, або переробляти та використовувати повторно.

    Наприклад, на малюнку 1-3 показаний життєвий цикл будівлі. Перший етап, етап виготовлення - це сфера діяльності керівника проекту, який здійснює нагляд за будівництвом будівлі. Після завершення будівництва керівник проекту переходить до інших робіт, але будівля, звичайно, тільки почала своє функціональне життя. Під час етапів експлуатації/використання/зміни мешканці будівлі або отримують вигоду, або страждають від рішень керівника проекту протягом усього етапу прийняття. Далі настає етап виходу на пенсію/повторне використання, на якому будівля, швидше за все, буде знесено і щось інше побудовано на його місці. У цей момент весь життєвий цикл починається знову. Легкість, з якою розгортаються ці етапи, залежить, принаймні частково, від вибору, зробленого керівником проекту на етапі виготовлення. Тільки розуміючи ці пізніші етапи, ви можете правильно зрозуміти справжню природу проекту і прийняти рішення, які гарантують, що він виробляє щось стійке значення.

    Малюнок 1-3: Продукт або результат проекту створюється, підтримується, адаптований, оновлений та знесен/виведений на пенсію різними проектами протягом його життя

    У розробці програмного забезпечення часові періоди між етапами коротші, ніж у будівництві. Як і в будівництві, операційна стадія на сьогоднішній день є найдорожчою частиною процесу життєвого циклу. Однак, коли програмний продукт продовжує використовуватися понад розрахований термін експлуатації, експлуатаційні витрати можуть зростати з прискореною швидкістю. У будь-якій галузі мислення про життєвий цикл результату проекту змінює те, як ви думаєте про метрики проекту. Як показано на малюнку 1-4, те, що здається хорошим вибором зсередини обмежених обмежень етапу виготовлення, може здатися дурним, якщо розглядати з більш широкої точки зору повного життєвого циклу.

    Малюнок 1-4: Кожен етап життєвого циклу викликає нові питання про успіх початкового проекту, що робить етап

    Результат проекту та успіх проекту

    У найвужчому сенсі термін «результат проекту» відноситься до вимірного результату проекту з точки зору обсягу, вартості, графіка, якості та інших питань, таких як безпека. У більш широкому сенсі цей термін також стосується впливу проекту порівняно з його більшими цілями. У цьому сенсі ми приймаємо перспективу громади, беручи до уваги, наприклад, багаторазовий потенціал проекту та можливу перепланування. Наприклад, у найвужчому сенсі бажаним результатом проекту запропонованої спортивної арени може бути багатофункціональний критий об'єкт, побудований відповідно до запланованого обсягу, вартості, графіка тощо. Однак в більш широкому сенсі бажаним результатом проекту може стати перепланування і ревіталізація прилеглої території.

    Для гумористичного погляду на багато способів, якими зацікавлені сторони проекту можуть визначити успіх проекту, див. «Що хотів клієнт» — Arek Fressadi

    Термін успіх проекту відноситься до ступеня, в якій проект робиться добре, із зацікавленими сторонами, які мають різні визначення успіху з часом, залежно від їх перспектив. Іншими словами, оцінка успіху проекту є суб'єктивним судженням; різні зацікавлені сторони матимуть різні початкові уявлення про загальний успіх проекту на основі власних очікувань та цілей. Щоб ускладнити ситуацію, з часом зацікавлені сторони, швидше за все, переглянуть свої ідеї щодо успіху проекту, щоб врахувати нову інформацію про те, як результат проекту насправді функціонує в реальному світі. Зміна визначення успіху проекту особливо важливо мати на увазі під час руйнівних проектів, таких як реконструкція будинку та реконструкція доріг. Наприклад, пасажири можуть мати надзвичайно низьку думку про будівництво розв'язки, коли вони страждають через розчарування резервних копій руху та об'їздів. Пізніше, коли розв'язка завершена, а трафік тече швидше, ніж будь-коли раніше, вони, швидше за все, оцінять загальний успіх проекту дуже високо. У світі споживчих товарів клієнти, які шукають новий бездротовий пристрій, можуть базувати свою ідею про успіх проекту на простоті використання та надійності, тоді як компанія, яка виробляє пристрій, може оцінити успіх проекту на основі кількості проданих одиниць. Тим часом галузь в цілому може оцінити проект на успіх лише в тому випадку, якщо він встановлює новий технічний стандарт.

    Якщо обмежити свою перспективу етапом створення, легко подумати, що терміни «результат проекту» та «успіх проекту» є синонімами. Наприклад, припустимо, що вас найняли для будівництва енергоефективного будинку відповідно до стандартів лідерства в галузі енергетики та екологічного дизайну (LEED). Якщо в кінці етапу створення ви побачите, що ваша команда завершила структуру вчасно і в рамках бюджету, з усіма зазначеними функціями LEED, то ви, ймовірно, вважаєте, що результат успішним. Але коли будинок переходить на етапі експлуатації/використання/зміни, інформація про використання енергії будинку може змінити ваші уявлення про успіх або невдачу проекту. Якщо насправді функції LEED функціонують не так, як очікувалося, то ви, ймовірно, оціните загальний успіх проекту досить низько. Можливо, що ще важливіше, власник будинку навряд чи вважатиме житло вдалим. І залежно від оцінок довговічності та постійно мінливих зовнішніх факторів, термін служби будинку також може значно відрізнятися від спочатку прогнозованого.

    Простіше кажучи, успіх проекту визначається правильним виконанням проекту та виконанням визначених цілей. Результат проекту також охоплює, чи правильно ви та ваша команда зробили. Важливо враховувати як на декількох рівнях - для окремих завдань, для загального проекту, так і для впливу проекту на його життя. У кожному випадку нам потрібно широко думати про фактори, що сприяють успіху або невдачі проекту. Ми ризикуємо втратити стійку цінність, якщо намалюємо занадто тісний паркан навколо кордонів, які ми враховуємо при плануванні та оцінці успіху проекту.

    Сталий розвиток та життєвий порядок

    Ідеальний менеджер проекту має співпереживання до людей, які будуть використовувати та модифікувати завершений проект у майбутньому, навіть людям, які в кінцевому підсумку знесуть або перероблять його. В ідеалі це означає включення матеріалів, які в кінцевому підсумку можуть бути перероблені. Дійсно, в Європейському Союзі виробники автомобілів зобов'язані за законом зменшити відходи, що не підлягають вторинній переробці, що утворюються транспортним засобом з закінченим терміном експлуатації (ПЗВ), до 5%. Такий спосіб мислення вимагає більш складного уявлення про життєвий цикл продукту, як показано на малюнку 1-5 (Kanari, Pineau and Shallari 2003).

    Малюнок 1-5: Життєвий цикл продукту може в кінцевому підсумку включати переробку частини продукту (Джерело: «Переробка транспортних засобів з закінченням терміну служби в Європейському Союзі», N. Kanari, J.-L. Піно, і С.Шалларі, член журналу мінералів, металів і матеріалів товариства www.tms.org/pubs/journals/jom... nari-0308.html. Авторське право 2003 року Товариством мінералів, металів та матеріалів. Використовується з дозволу.)

    Зусилля щодо сталого розвитку, натхненні визнанням реалій життєвого порядку, тривають у будівельній галузі. Як стверджував Ланс Хозі, вашингтонський архітектор, стійке будівництво означає, серед іншого, створення будівель, які можна легко розібрати, мінімізуючи порушення та забруднення, властиві процесу знесення (2005). Розробники програмного забезпечення теж можуть розробляти стійке програмне забезпечення, наприклад, написавши код, який працює навіть на застарілому обладнанні, тим самим мінімізуючи кількість комп'ютерного обладнання, яке потрапляє на сміттєзвалища (Green Wiki 2015).

    Окрім стійкого проектування, програмне забезпечення також має потенціал для сприяння іншим зусиллям щодо сталого розвитку, про що йдеться у звіті «Програмне забезпечення прискорює сталий розвиток», опублікованому некомерційною організацією «Бізнес за соціальну відповідальність» (2008). Девід Пагенкопф, директор з розробки та інтеграції додатків UW-Madison, говорить про стійкість та дизайн програмного забезпечення:

    Використання методів віртуалізації значною мірою усунуло апаратне забезпечення як матеріальний фактор при розробці програмного забезпечення. Найважливішим питанням стійкості програмного забезпечення є вибір мов програмного забезпечення, інструментів та архітектури дизайну, які гарантують, що програмне забезпечення є придатним для обслуговування протягом якомога більше років. Одним з найкращих прикладів є написання програмного забезпечення, яке повністю працює у веб-браузері, який потім може працювати на декількох платформах. Ще краще написання програмного забезпечення з використанням адаптивного дизайну, який автоматично підлаштовується під кінцевий пристрій користувача (наприклад, мобільний телефон, планшет або ноутбук/робочий стіл), щоб представити кращий можливий інтерфейс для користувача. (чол. комм., 25 серпня 2015 р.)

    Споживчі товари підлягають постійно зростаючому діапазону очікувань щодо сталого розвитку. Як писав Брайан Берро в New York Times, Wal-Mart зменшив «розмір упаковки на своїх виробничих лініях, заощадивши компанії приблизно 3,4 мільярда доларів на рік... одночасно зменшуючи сміття «(Берроу 2011). Понад десятиліття зусиль призвели до ініціатив щодо сталого розвитку, які «мають реальний вплив сьогодні. Компанія стратегічно використовувала свої масштаби на свою користь, щоб запровадити зміни як всередині, так і за межами організації» (Atamian 2017).

    1.5 Чотири ролі менеджера проекту

    Так що ж все це говорить про зміни і непередбачуваність означає, практично кажучи, для реального менеджера проектів? Протягом цієї книги ми будемо досліджувати способи врахування реалій життєвого порядку в повсякденних завданнях, пов'язаних з технічним управлінням проектами. Наприклад, на уроці 6 ми поговоримо про pull-планування, адаптивну, рекурсивну форму планування, яка надає пріоритет регулярному оновленню, щоб відобразити поточні умови. Але поки давайте поговоримо про деякі загальні принципи успішного управління проектами в світі живого порядку.

    У статті для MIT Sloan Management Review Олександр Лауфер, Едвард Хоффман, Джеффрі Рассел та Скотт Камерон показують, як успішні менеджери проектів поєднують традиційні методи управління з новими, більш гнучкими підходами для досягнення кращих результатів (2015). Їх дослідження показують, що успішні керівники проектів беруть на себе ці чотири життєво важливі ролі:

    1. Розвивайте співпрацю між учасниками проекту: «Більшість проектів характеризуються властивою несумісністю: різні сторони проекту вільно пов'язані між собою, тоді як самі завдання тісно пов'язані між собою. Коли несподівані події впливають на одне завдання, багато інших взаємозалежних завдань швидко зачіпаються. І все ж пряма відповідальність за виконання цих завдань розподіляється між різними слабо пов'язаними сторонами, які не в змозі координувати свої дії і забезпечити своєчасне реагування. Успіх проекту, отже, вимагає як взаємозалежності, так і довіри між різними сторонами» (Laufer et al. 2015, 46).
    2. Інтегруйте планування з навчанням: «Менеджери проектів, які зіткнулися з несподіваними подіями, використовують підхід до планування «рухомої хвилі». Визнаючи, що тверді зобов'язання не можуть бути прийняті на основі мінливої інформації, вони розробляють плани хвилями, коли проект розгортається і інформація стає більш надійною. Зі своїми командами вони розробляють детальні короткострокові плани з твердими зобов'язаннями, а також готують орієнтовні довгострокові плани з меншою кількістю деталей» (Laufer et al. 2015, 46).
    3. Запобігання серйозних збоїв: Успішні керівники проектів «ніколи не припиняють чекати сюрпризів, навіть якщо вони можуть вплинути на серйозні зміни виправлення лише кілька разів під час проекту. Вони постійно передбачають збої і підтримують гнучкість реагувати на проактивну реакцію... Коли зміни неминучі, успішний керівник проекту діє якомога раніше, оскільки легше подолати загрозу, перш ніж вона досягне повноцінного стану» (Laufer et al. 2015, 47).
    4. Підтримуйте імпульс вперед: «Коли несподівані події впливають на одне завдання, багато інших взаємозалежних завдань також можуть швидко вплинути. Таким чином, вирішення проблем, як тільки вони з'являються, є життєво важливим для підтримки прогресу в роботі» (Laufer et al. 2015, 48).

    Прийняття цих чотирьох ролей поставить вас на шлях до отримання більшої цінності у ваших проектах, з меншими витратами, що також є метою як Lean управління проектами, так і для управління проектами Agile.

    1.6 Lean: Усунення відходів у живому порядку

    Традиційне, геометричне управління проектами часто є неефективним, що призводить до даремно витраченого часу, грошей, ресурсів та праці. На відміну від цього, Lean - це бізнес-модель та філософія управління проектами, яка пропонує засоби для оптимізації проектів, забезпечуючи при цьому гнучкість, необхідну для боротьби з несподіваними подіями. На основі ідей та практик, розроблених у Toyota після Другої світової війни, він підкреслює створення цінності для замовника, одночасно усуваючи відходи за рахунок ефективного потоку робіт від однієї фази проекту до іншої.

    Більше всього, Lean - це спосіб мислення. У своїй важливій книзі на цю тему Джеймс П. Вомак та Деніел Т. Джонс описують Lean мислення наступним чином:

    Він надає спосіб вказати значення, вирівняти дії, що створюють значення в найкращій послідовності, проводити ці дії без перерви, коли хтось запитує їх, і виконувати їх все ефективніше. Коротше кажучи, Lean мислення є Lean, тому що воно забезпечує спосіб робити все більше і більше з все менше і менше - менше людських зусиль, менше обладнання, менше часу і менше місця - наближаючись і наближаючись до надання клієнтам саме те, що вони хочуть. (2003, 15)

    Ми будемо обговорювати Lean широко протягом цієї книги. Щоб розпочати тут, ми зосередимося на двох фундаментальних ідеях Lean: цінності та відходів.

    Значення

    У звичайній розмові «цінність» - це загальний термін, який позначає загальну цінність або корисність чогось. Але в Lean цінність має значення лише «коли виражається в терміні конкретного товару (товару чи послуги, а часто і відразу обох), який відповідає потребам замовника за певною ціною в певний час» (Womack and Jones, 16). Іншими словами, вартість визначається замовником, а не виробником, підрядником або постачальником послуг, і, безумовно, не інженером, відповідальним за розробку продукту.

    Комплексна доставка проектів

    Читаючи про управління проектами та Lean, ви можете зіткнутися з терміном інтегрована реалізація проектів (IPD). Натхненний Lean мислення, IPD є засобом договірного узгодження зацікавлених сторін у будівельному проекті таким чином, що підкреслює тісну співпрацю, з метою забезпечення цінності, визначеної замовником. Однією з особливостей IPD є тип контракту, відомий як багатостороння угода, яка пояснює роль кожного учасника в проекті.

    Пов'язана методологія, інтегрована доставка продукту, була розроблена як реакція проти силосного підходу до розробки продукту, в якому команда дизайнерів спроектувала продукт, а потім «перекинула його через стіну» виробничій команді, яка повинна була зрозуміти, як побудувати продукт без введення в його дизайн. Комплексний підхід до розробки продуктів покращує час виходу на ринок, одночасно сприяючи інноваціям.

    Це звучить просто, але це може бути складною концепцією для інженерів, з усією їхньою технічною експертизою, прийняти. У своїй книзі Womack і Jones включають главу про Porsche, який зазнав колапсу продажів в середині 1980-х років багато в чому тому, що його інженери світового класу засліпили себе визначенням цінності своїх клієнтів:

    Проекти з більшою складністю, вироблені з все більш складним обладнанням, стверджувалося, що це саме те, що хотів замовник, і саме те, що потрібно виробничому процесу... Часто ставало очевидним, що сильні технічні функції та висококваліфіковані технічні експерти, провідні німецькі фірми, отримали своє почуття цінності - їх переконання, що вони виконують першокласну роботу - просуваючи вперед вдосконалення та складнощі, які мало цікавили нікого, крім експертів. самі... Сумніви щодо пропонованих продуктів часто протиставлялися твердженнями про те, що «клієнт захоче цього, як тільки ми пояснимо це», тоді як останні несправності продукту часто пояснювалися як випадки, коли «клієнти не були достатньо витонченими, щоб зрозуміти переваги продукту». (2003, 17)

    Це лише один із прикладів видів упереджень, які можуть спотворити розуміння компанією цінності, яку вона нібито виробляє на благо замовника. Womack і Jones надають поглиблені тематичні дослідження, деталізуючи сили, які можуть перешкодити компанії зрозуміти, чого насправді хочуть її клієнти:

    Визначення вартості скрізь перекошується силою існуючих організацій, технологій та недооцінених активів, поряд із застарілим мисленням про економію масштабу. Менеджери по всьому світу, як правило, кажуть: «Цей продукт - це те, що ми знаємо, як виробляти, використовуючи активи, які ми вже купили, тому, якщо клієнти не реагують, ми скоригуємо ціну або додамо навороти». Натомість вони повинні робити, це принципово переосмислення цінності з точки зору замовника. (2003, 17-18)

    Щоб зробити стрибок у Lean мислення, вам потрібно повністю зрозуміти природу цінності, саме тому ми повернемося до цієї ідеї протягом усієї цієї книги. Вам також потрібно зрозуміти його протилежність—відходи. Вся мета Lean полягає в тому, щоб максимізувати цінність і усунути відходи.

    Відходи

    Відповідно до Lean Lexicon, відходи [1] - це «Будь-яка діяльність, яка споживає ресурси, але не створює цінності для замовника» (Lean Enterprise Institute 2014). Виявлення відходів може бути таким же складним для нових мислителів Lean, як і визначення цінності.

    Тайічі Оно, виконавчий директор Toyota, який піонером зосередився на відходах та цінності, які ми зараз називаємо Lean, визначив сім форм відходів. Ви можете знайти незліченну кількість пояснень семи відходів у книгах і статтях. Нижче адаптовано з «7 відходів» - Lean Manufacturing Tools :

    • Транспорт: Переміщення людей, машин або матеріалів далі, ніж це дійсно необхідно. Величезна кількість транспортних відходів викликана поганими фабричними плануваннями, великими розмірами партій та віддаленими місцями зберігання, лише щоб назвати кілька причин.
    • Інвентаризація: Нарощування запасів через, наприклад, погане планування або час, необхідний для переходу техніки з одного процесу на інший.
    • Рух: Будь-який рух людей або обладнання, що не збільшує цінність товару чи послуги. Приклади включають згинання та досягнення, необхідні погано спроектованою робочою станцією або погано організованими місцями зберігання.
    • Очікування: Люди або машини, що стоять без діла. Може бути викликано тривалими змінами, погано скоординованими процесами або необхідністю переробки дефектних деталей, серед іншого.
    • Перевиробництво: Створення більше, ніж може бути використано або продано в розумні терміни. Це вважається найгіршою формою відходів, оскільки «це затьмарює всі інші проблеми у ваших процесах» (Lean Manufacturing Tools n.d.). Пізніше в цій книзі ми поговоримо про те, як уникнути цієї форми відходів за допомогою Lean методів, таких як планування тяги.
    • Надмірна обробка: Робити більше, ніж корисно або необхідно з точки зору замовника. Надмірна інженерія в Porsche, описана Womack і Jones, є яскравим прикладом надмірної обробки. Більш приземленим прикладом може бути ресторан, який використовує дорогий імпортний сир на піцах, коли клієнти дійсно віддають перевагу вітчизняній моцареллі.
    • Дефекти: час і зусилля, необхідні для виправлення несправних деталей або погано наданих послуг. Це те, про що думає більшість людей, коли їх просять визначити відходи. Але може бути важко точно оцінити витрати, пов'язані з дефектами, які можуть включати «витрати, пов'язані з вирішенням проблем, матеріалами, переробкою, переплануванням матеріалів, налаштуваннями, транспортом, оформленням документів, збільшенням часу виконання, збоями доставки та потенційно втраченими клієнтами» (Lean Manufacturing Tools).

    Ще один спосіб думати про відходи - зосередитися на тому, наскільки легко їх можна усунути. Якщо дивитися на цей шлях, він ділиться на два типи:

    • Відходи першого типу: Створює «ніякої цінності, але неминучі за допомогою сучасних технологій та виробничих активів» (Lean Enterprise Institute 2014). Цей вид відходів необхідний, але може бути усунений у майбутньому. Прикладом відходів першого типу можуть бути планові перевірки, необхідні для того, щоб певна частина відповідала державним стандартам безпеки. Хоча це необхідно, такі перевірки фактично не забезпечують цінності з точки зору замовника і, можливо, можуть бути усунені, якщо сама деталь була усунена з пристрою або якщо вона була перероблена.
    • Тип два відходи: не створює ніякої цінності і може бути негайно усунена. Наприклад, час і зусилля, необхідні для транспортування новоспеченої мікрохвильової печі до пакувальної машини, - це відходи, які можна усунути, перемістивши пакувальну машину.

    Цей блог містить кілька реальних прикладів семи форм відходів у різних галузях промисловості: «Реальні приклади 7 відходів Lean» — KainExus

    В управлінні проектами прикладом відходів першого типу може бути аудит, необхідний для вимірювання виконання робіт за контрактом або обіцяного продукту проти узгодженого набору вимог. З точки зору замовника, такий аудит не додає цінності, але він необхідний для забезпечення успішного завершення проекту. Відходи типу два, які часто спостерігаються в управлінні проектами, - це постійні запити на оновлення статусу. Нові менеджери проектів, які ще не створили довіру зі своєю командою, іноді піддаються цій формі відходів, намагаючись мікрокерувати всіма завданнями. Регулярно заплановані оновлення та ескалація очікувань щодо несподіваних викликів допомагають усунути цей тип двох відходів в управлінні проектами.

    Шість принципів бережливого

    Шість принципів, що лежать в основі Lean мислення: вказати цінність, визначити потік цінностей, потік, тягнути, досконалість і повагу до людей. Ви дізнаєтеся більше про ці ідеї та про те, як вони пов'язані з технічним управлінням проектами, у цій книзі. Ми коротко пояснимо їх тут, щоб дати вам основу для роботи. Більшість прикладів у цьому уроці взято з виробництва, де Lean отримав свій початок. Але майте на увазі, що Lean мислення широко застосовується в таких різноманітних галузях, як будівництво та охорона здоров'я.

      1. Визначте цінність: Як пояснювалося раніше, вартість може бути визначена лише замовником. Як керівник проекту, ви повинні почати з вивчення того, що таке визначення - в ідеалі, спілкуючись безпосередньо з замовником. Однак ви можете виявити, що клієнти «знають лише, як попросити якийсь варіант того, що вони вже отримують» (Womack and Jones 2003, 31). Це означає, що виявлення цінності часто тягне за собою задавання питань зондування, покликаних отримати визначення цінності від клієнтів, які, можливо, не мали можливості продумати це через себе. Часто найкращі запитання для початку: Яку проблему ви хочете вирішити? Як виглядає успіх?
      2. Відображення потоку цінності: Потік цінності - це «всі дії, як створення вартості, так і не створення вартості, необхідні для виведення продукту з концепції» до доставки (Lean Enterprise Institute 2014). У будь-якій галузі переважна більшість видів діяльності в потоці вартості не створюють ніякої цінності і, отже, є відходами. Фірмам, які намагаються проаналізувати потік вартості для того чи іншого товару, зазвичай доводиться шукати далеко за межі власних приміщень, беручи до уваги все, що бере участь у виведенні товару на ринок. Наприклад, потік цінності для нового виду хліба може починатися з підземних вод, що використовуються для зрошення пшеничних ферм в Небрасці. Розглядаючи потоки цінності з точки зору управління проектами, мета полягає в тому, щоб зрозуміти всі аспекти проекту, включаючи ініціацію, планування, виконання, моніторинг та контроль та закриття.

        Пакетна і черга: протилежність потоку

        Припустимо, ви створили систему партії та черги для випічки, глазурування, прикраси та боксу сто тортів на день народження в пекарні. У міру випікання коржів потрібно придумати хороший розчин для зберігання, щоб вони залишалися свіжими, поки ви не будете готові їх заморозити. Після того, як всі торти матові, і ви переходите на крок прикраси, ви можете виявити, що прикраси не прилипають до глазурі. Якби ви тільки що спекли, замазували і прикрашали один торт, ви б виявили і вирішили цю проблему, перш ніж вона стала дефектом, що зачіпає всі торти. Але так як ви вже спекли і заморозили всі торти, ви тепер в положенні необхідності купувати нові прикраси, які будуть прилипати до глазурі вже на торті. Аналогічна проблема могла виникнути і з коробками. У вас може бути сто тортів, матових і прикрашених, готових до коробки, а потім виявити, що вони не поміщаються в коробках, які ви замовили. Тим часом торти стають черствими, і незабаром можуть стати непродаваними.

      3. Безперервний потік: За словами Womack і Jones, більшість людей схильні думати, що найефективнішим способом завершення будь-якого багатоетапного проекту є розділення його на партії - виконання першого кроку на всіх доступних матеріалах і відкладання результатів убік, поки всі матеріали не будуть оброблені. Після того, як вся партія буде завершена, ви переходите до наступного етапу, обробляючи всю партію і так далі, через всі етапи. Цей підхід, відомий як партія та черга, може бути корисним у багатьох ситуаціях, але він часто дико неефективний і може призвести до дефектів, які не виявляються до багатьох кроків процесу (Womack and Jones 2003, 22). Щоб уникнути проблем, пов'язаних з серійним та черговим виробництвом, Lean підкреслює безперервний потік від одного кроку до іншого, з невеликими партіями, які можуть бути негайно оброблені працівниками на наступному етапі. Справжній безперервний потік, який різко скорочує час виробництва, можливий тільки після того, як ви усунули відходи нецінності створення ступенів, а потім переставили інші кроки так, щоб вони розгорталися одна за одною. Це не реалістична мета у всіх галузях промисловості, але часто можна досягти певних переваг потоку, переміщуючи машини та переміщуючи персонал. В управлінні проектами потік може стати проблемою під час планування. Наприклад, команда проекту може зробити помилку, працюючи над надмірно деталізованим графіком із надмірно дискретними часовими блоками, планування завдань для багаторічного проекту в годинами. Потім, витративши весь цей час на нереальний графік, команда може не переглянути та оновити фактичний прогрес у міру просування проекту. Така відсутність потоку може представляти реальні ризики для загального успіху проекту. На відміну від цього, Lean-мислячі керівники проектів розуміють, що графік є живим документом, і що протягом усього проекту їм потрібно буде вирішувати зміни порядку життя (як позитивні, так і негативні), що забезпечує справжній потік протягом усього життя проекту.
      4. Потягніть: Щоб зрозуміти значення тяги, спочатку потрібно зрозуміти значення поштовху. Традиційними виробничими системами вважаються поштовхові системи, при цьому робота продиктована виробничими графіками, які іноді прив'язані до точних прогнозів попиту споживачів, але часто це не так. Система поштовху легко призводить до відходів надмірного виробництва. Марк Грабан пропонує кілька прикладів:
        • Ресторан швидкого харчування, який готує їжу та зберігає її під нагрівальними лампами (частина її викидається).
        • Автовиробник будує надлишкову кількість автомобілів або вантажних автомобілів і змушує дилерів приймати їх.
        • Монетний двір США виробляє доларові монети, які значно перевищують попит клієнтів.
        • Комп'ютерні виробники будують продукт і відправляють його роздрібним торговцям, щоб сидіти на полицях. (2014)

        На відміну від цього, система витягування будує продукти та використовує матеріали на основі фактичного попиту клієнтів, так як сендвіч-магазин може зробити ваш улюблений сендвіч з індичкою та гуакамоле після того, як ви його замовите. Насправді більшість систем використовують комбінацію виробництва pull і push. Наприклад, складання бутерброда на місці - це тягне заняття, але магазин, ймовірно, практикував би виробництво поштовху, попередньо замовивши індичку та гуакамоле відповідно до прогнозів попиту клієнтів.

        Ці приклади значно спрощують концепцію Lean pull. На практиці, особливо на гігантських заводах або на будівельних майданчиках, це набагато складніше. Але основний принцип зменшення відходів завжди однаковий: «ніхто вище за течією не повинен виробляти товар чи послугу, поки клієнт нижче за течією не попросить про це» (Womack and Jones 2003, 67).

        Цей чудовий пост в блозі використовує приклад концесійного стенду, щоб проілюструвати те, як система витягування уникає відходів запасів та надмірного виробництва, зберігаючи лише невеликі кількості матеріалів під рукою, замінюючи предмети, як вони використовуються:
        Lean Blitz Consulting - «Toyota Way Principle #3: «Pull» Системи»

        Переклад концепції тяги до управління проектами може бути складним, але дає потужні результати. Команда починається з кінцевої точки - кінцевої мети проекту - і тягне діяльність вперед, описуючи, що потрібно робити на кожному кроці шляху. Це сильно відрізняється від стандартного управління проектами, яке починається з самого початку, будуючи графік, який передбачає, що попередні завдання повністю закінчені до того, як команда приступає до виконання наступних завдань. На відміну від цього, у графіку Lean більше завдань перекриваються. У презентації про планування проекту для проектування лінії електропередачі Крістін Енгель пояснює, що в графіку тягнути «пізніші завдання» можуть початися до того, як закінчаться «більш ранні» завдання», і що деякі «завдання з уточнення дизайну можуть перекриватися з процесом трудових ставок або навіть будівництвом, що відображає реальність комунальні проекти». Незважаючи на таку плинність, команда може відстежувати прогрес, порівнюючи виставлені рахунки з бюджетом. Вся система побудована на «регулярному спілкуванні з клієнтом для перегляду короткострокових цілей стосовно повного графіка проекту» (Engel 2017).

      5. Досконалість: Досвідчені практики Lean свідчать, що, коли ви покращуєтесь у визначенні цінності клієнта, ви стаєте більш точними у визначенні кожного кроку потоку вартості. В результаті ви зменшуєте відходи діяльності, що не додає вартості, тим самим покращуючи потік. Набуваючи досвід, ви почнете бачити можливості для вдосконалення Lean скрізь. Це як підняття важких предметів - чим більше ви піднімаєте, тим більше зможете підняти. Чим більше відходів ви усунете, тим більше відходів ви зможете усунути. За словами Джонса та Вомака, це відбувається тому, що

        чотири початкові принципи взаємодіють один з одним в доброчесному колі. Отримання значення для потоку швидше завжди викриває приховані муда [відходи] у потоці цінностей. І чим важче ви тягнете, тим більше перешкод для протікання виявляються, щоб їх можна було усунути. Виділені команди продуктів в прямому діалозі з клієнтами завжди знаходять способи більш точно визначити значення і часто дізнаються про способи підвищення потоку і тяги, а також. (2003, 25)

      6. Повага до людей: Перш за все, Lean вимагає постійного спілкування між усіма зацікавленими сторонами. Реалізація перших п'яти принципів Lean можлива лише тоді, коли всі члени команди поважають і слухають один одного, діляться ідеями, приймають пропозиції та співпрацюють для вирішення проблем та усунення відходів. Повага до людей - це не те, щоб бути приємним - це розуміння того, що ви не можете вирішити проблеми самостійно, і що замість цього вам потрібно щиро та чесно співпрацювати з колегами. Іноді це означає кинути виклик їм і пропонувати критику. Це завжди означає бути готовим визнати, коли ви помиляєтеся.

    Натисніть і потягніть

    Це двохвилинне відео пояснює різницю між виробництвом push і pull:

    Елемент YouTube був виключений з цієї версії тексту. Ви можете переглянути його онлайн тут: pb.libretexts.org/web1/? p=40

    1.7 Agile: Швидкий зворотний зв'язок у живому порядку

    Lean спочатку був розроблений у світі виробництва, але був прийнятий у багатьох галузях промисловості. У світі розробки програмного забезпечення все більшої популярності набуває супутня методологія - Agile. Це, по суті, ІТ-версія Lean. Хоча Agile має своє коріння в розробці програмного забезпечення, компанії також розширили його використання на різні типи проектів, включаючи розробку продуктів, капітальні проекти та сервісні проекти.

    Багато смаків Agile включають:

        • Agile Scrum: Призначений для завершення складних проектів, як описано на ScrumGuides, Scrum є найбільш широко використовуваною формою Agile. Коли люди говорять про Agile, вони зазвичай говорять про Scrum.
        • Екстремальне програмування: Підкреслює короткі цикли розробки з частими випусками програмного забезпечення для оцінки, після чого починається новий цикл розробки. Ви можете прочитати більше про екстремальне програмування на сторінці «Екстремальне програмування: ніжне введення»
        • Швидкий розвиток продукту: Підкреслює «одночасну, скоординовану діяльність багатофункціональних команд, прагнучи до плавних переходів між фазами для найбільш швидкого виходу на ринок» (ORC International: Expert Advisory Services). Ви можете прочитати більше про швидкий розвиток продукту в цьому «Вступ до швидкого розвитку продукту».

  • Інша форма Agile

    Хакатони, ще один тип Agile experience, - це багатоденні події, в яких розробники програмного забезпечення працюють над вирішенням конкретної проблеми з метою генерації ряду інноваційних ідей та/або прототипів. Хакатони схожі на Agile спринти, але зазвичай передбачають більш інтенсивну співпрацю, коли учасники збираються в одному місці і діляться на команди. Походження як спосіб для будь-кого взяти участь у створенні програмного забезпечення з відкритим вихідним кодом, хакатони зараз поширені в університетських кампусах і в корпоративному світі. Інформацію про майбутні хакатони див. на цьому сайті, присвяченому темі: HackerEarth.

    • Усі форми Agile підкреслюють ітеративний підхід до розробки продукту, при цьому специфікації проекту розвиваються разом із уявленням замовника про вимоги до програмного забезпечення. Проект починається з розмови між розробником і власником продукту про те, що клієнт хоче зробити програмне забезпечення. У термінології Scrum клієнт є власником продукту, а функції, які власник продукту хоче використовувати в програмному забезпеченні, називаються історіями продуктів.

    З описом історій продуктів в руці, Agile розробник приступає до роботи, створюючи частини програмного забезпечення, які стосуються окремих історій продуктів. Після одного-двотижневого циклу розробки (відомого в Scrum як спринт) розробник здає нове програмне забезпечення власнику продукту, щоб вона могла спробувати його і внести пропозиції щодо вдосконалення. Потім розробник починає ще один спринт, включивши ці пропозиції в нову ітерацію. Після кожного спринту власник продукту має можливість перенаправити команду на нові історії продуктів або переглянути розуміння команди існуючих історій продукту. Завдяки цим повторюваним взаємодіям, які забезпечують швидкий, цілеспрямований зворотний зв'язок, розробник та власник продукту нуль у програмному додатку, який робить те, що потрібно власнику продукту. Якщо часу і грошей мало, як це часто буває, власник продукту має регулярні можливості зробити вибір про те, які історії продуктів є найважливішими, а від яких можна відмовитися, якщо це необхідно.

    Agile development - це, по суті, навчальний процес, за допомогою якого розробник і власник продукту створюють спільне розуміння того, скільки функцій вони можуть створити, враховуючи відведений час і гроші. Це дуже живий підхід до управління проектами, оскільки ранні етапи включають деяку неоднозначність і багато невідомих. За словами Роберта Меррілла, старшого бізнес-аналітика Університету Вісконсин-Медісон та тренера Agile, «Agile - це спосіб управління проектами в умовах непередбачуваності та обмежень - часто дуже жорстких часових та бюджетних обмежень. Швидкий зворотний зв'язок дозволяє команді створити найкраще програмне забезпечення в межах заданих обмежень» (2017).

    Як і Lean, Agile буде повторюваною темою у цій книзі. Щоб розпочати вивчення Agile самостійно, див. наступне:

    Agile: новий вид інженерії

    У своїй захоплюючій лекції «Реальна програмна інженерія» Гленн Вандербург представляє історію програмної інженерії (2011). Він пояснює, як ранні розробники програмного забезпечення, як правило, думають про інженерію програмного забезпечення з точки зору, які були знайомі їм із структурної інженерії, тому що саме це, на їхню думку, означало термін інженерія. Вандербург виступає за нове, просте визначення інженерії: все, що працює.

    Історія говорить нам, що те, що раніше називалося програмною інженерією, насправді мало стосувалося інженерії, оскільки так звані «проекти програмної інженерії» були пронизані відходами, переробками та невдачами. Іншими словами, це не спрацювало. На думку Вандербурга, Agile є єдиною реальною формою програмної інженерії. Вона принципово відрізняється від інженерії конструкцій, частково тому, що дозволяє миттєве, по суті, безкоштовне тестування - те, що неможливо при будівництві літаків або мостів. Крім того, тоді як інші типи інженерії зазвичай передбачають моделювання чогось протягом тривалого періоду тижнів або місяців, а потім отримання зворотного зв'язку, також протягом тижнів або місяців, розробники Agile отримують зворотний зв'язок у різних часових масштабах. Для окремих блоків коду вони можуть отримати важливий зворотний зв'язок за лічені хвилини або години, просто поділившись ним з іншим розробником або з замовником. Для більших частин проекту, таких як приймальне тестування або випуск нових функцій, отримання зворотного зв'язку дорожче і відбувається протягом тижнів або місяців.

    Основна причина зворотного зв'язку і тестування в Agile настільки відрізняється від інших типів інженерії, полягає в тому, що вихідний код сам по собі є моделлю. Написуючи код, розробники Agile створюють одночасно і тестовану модель, і кінцевий продукт. За словами Вандербурга: «Agile процеси є економічними, економічно налаштованими двигунами зворотного зв'язку».

    ~Практичні поради

        • Будьте готові використовувати як геометричні, так і методи живого порядку: проекти часто задумуються і плануються в геометричному порядку, з наївним припущенням подій, що розгортаються передбачувано. Тоді реальність потрапляє, і вони виконуються серед невизначеності живого порядку. Однак з часом, у міру того, як проекти розгортаються, і ви починаєте дізнаватися, чого очікувати, вони можуть стати більш геометричними. Будьте готові рухатися вперед і назад між техніками геометричного та живого порядку, адаптуючись до ситуації в міру необхідності.
        • При роботі в геометричному порядку орієнтуйтеся на наступне:
          • Визначте успіх проекту.
          • Встановіть часову шкалу проекту.
          • Переконайтеся, що проект забезпечує зазначені результати.
          • Постійно перевіряйте свій прогрес з графіком проекту.
          • Регулярно перевіряйте витрати з бюджетом проекту.
          • Періодично робіть паузу, щоб переконатися, що проект дійсно розгортається в геометричному порядку і не змістився в живий порядок.
        • Працюючи в живому стані, дотримуйтесь хороших геометричних практик, коли це доречно, але також зосередьтеся на наступному:
          • Переконайтеся, що всі зацікавлені сторони розуміють спільну цінність проекту та віддані її досягненню.
          • Включіть всі корисні форми комунікації, щоб переконатися, що зацікавлені сторони проекту розуміють, що відбувається на кожному етапі проекту.
          • Зосередьтеся на заходах, які створюють цінність і усувають марнотратну діяльність.
          • Будьте готові реагувати на мінливі події, залишаючись спритними та адаптивними.
        • Витратьте час, щоб визначити унікальний та мінливий контекст проекту: Контекст проекту - повсякденне середовище та більший організаційний фон, в якому розгортається проект - рідко однаковий від одного проекту до іншого і може змінюватися протягом усього проекту. Визначивши унікальний контекст кожного проекту та багато способів, які він може змінитися, ви зменшите свої шанси зробити припущення, які можуть виявитися неправильними.

    ~Резюме

        • Проекти розгортаються в унікальних і мінливих контекстах, які вимагають гнучкого, адаптивного підходу.
        • Організації часто задумують проекти в непередбачуваному потрясінні життєвого порядку, а потім намагаються виконати їх в більш систематичному геометричному порядку, плануючи кожен крок аж до дрібниць. Успішні менеджери проектів ніколи не втрачають з уваги непередбачуваний, постійний світ whitewater, в якому насправді розгортаються проекти.
        • Розуміння того, що життєвий цикл проекту передбачає більше, ніж просто етап створення, розширить ваше розуміння «успіху проекту».
        • Ощадливе управління проектами зосереджено на максимізації вартості та усуненні відходів.
        • Спритні стратегії управління проектами заохочують гнучкість, необхідну в життєвому порядку.

    ~Глосарій

        • Agile —Методологія управління проектами, яка підкреслює ітеративний підхід до розробки продукту, при цьому специфікації проекту розвиваються разом із уявленням замовника про вимоги до програмного забезпечення. Є багато ароматів Agile, але найбільш широко використовується Scrum.
        • поведінкова економіка —За словами Oxforddictionaries.com, «метод економічного аналізу, який застосовує психологічні уявлення про поведінку людини для пояснення прийняття економічних рішень».
        • геометричний порядок —тип порядку, ідентифікований французьким філософом Анрі Бергсоном, який характеризується лінійним розвитком, чіткими причинами та наслідками та передбачуваними подіями.
        • інтегрована реалізація проекту (IPD) —Засіб договірного узгодження зацікавлених сторін у будівельному проекті таким чином, що підкреслює тісну співпрацю, з метою забезпечення цінності, визначеної замовником. IPD натхненний Lean і спирається на тип контракту, відомий як багатостороння угода, яка пояснює роль кожного учасника в проекті.
        • Lean —Бізнес-модель та філософія управління проектами, які пропонують засоби для оптимізації проектів, забезпечуючи при цьому гнучкість, необхідну для боротьби з несподіваними подіями. Він підкреслює ліквідацію відходів завдяки ефективному перетіканню робіт з однієї фази проекту на іншу.
        • живий порядок —тип порядку, ідентифікований французьким філософом Анрі Бергсоном, який характеризується швидкими змінами та непередбачуваними подіями.
        • проект - «частина запланованої роботи або діяльності, яка завершується протягом певного періоду часу і призначена для досягнення певної мети» (Cambridge English Dictionary 2018).
        • Результат проекту - У найвужчому сенсі вимірюваний результат проекту - будь то будівля, програмне забезпечення або частина винищувача. У більш широкому сенсі вплив проекту порівняно з його більшими цілями.
        • успіх проекту —Ступінь, до якої проект зроблений добре. Оцінка успішності проекту зацікавленими сторонами є суб'єктивним судженням, що змінюється залежно від їх перспективи і, як правило, змінюється з плином часу.
        • управління проектами — «Застосування процесів, методів, знань, навичок та досвіду для досягнення цілей проекту» (Association for Project Management 2018).
        • значення —У звичайній розмові загальний термін, який посилається на загальну цінність або корисність чогось. Але в Lean вартість має сенс лише «коли виражається в терміні конкретного товару (товару чи послуги, а часто і відразу обох), який відповідає потребам замовника за певною ціною в певний час» (Womack and Jones 2003, 16). Іншими словами, вартість визначається замовником.

    ~Додаткові ресурси

        • Посібник з Lean Enablers для управління інженерними програмами, опублікований Спільною спільнотою практик MIT PMI INCOSE з Lean in Program Management (2012).
        • Управління як виконавське мистецтво: нові ідеї для світу хаотичних змін, Пітер Вайлл (1989). У цій книзі Вайлл вводить термін «перманентна біла вода».
        • Мемуари Річарда Талера про його життя та роботу в галузі поведінкової економіки: Неправильне поводження: Створення поведінкової економіки (2015).
        • Класичне вступ до Lean: The Toyota Way: 14 Принципів управління від найбільшого світового виробника, Джеффрі Лікер (2004).

    ~Посилання

    Асоціація з управління проектами. н.д. «Що таке управління проектами?» apm.org. Доступ до 15 червня 2018 року. https://www.apm.org.uk/resources/wha...ct-management/.

    Атаміан, Луна. 2017 рік. «Чому Walmart є лідером сталого розвитку?» Хаффінгтон Пост, 14 грудня. https://www.huffingtonpost.com/entry...b00caf3d59eae8.

    Бергсон, Анрі. 1911 р. «Творча еволюція». Проект Гутенберга. Доступ до 15 червня 2018 року. http://www.gutenberg.org/files/26163... -h/26163-h.htm.

    Блох, Майкл, Свен Блумберг та Юрген Лаарц. 2012 рік. «Реалізація масштабних ІТ-проектів вчасно, за бюджетом та вартістю». Компанія «Маккінсі та компанія». Жовтень. Доступ до 4 серпня 2016 року. http://www.mckinsey.com/business-fun...t-and-on-value.

    Берро, Брайан. 2011 рік. «За озелененням Wal-Mart». Нью-Йорк Таймс, 14 травня. http://www.nytimes.com/2011/05/15/bu...helf.html? _r=0.

    Бізнес за соціальну відповідальність. 2008 рік. «Програмне забезпечення прискорює сталий розвиток». bsr.org. http://www.bsr.org/reports/BSR_Softw...evelopment.pdf.

    Кембриджський словник англійської мови. 2018. «проект». Кембриджський словник. Доступ до 12 травня 2018 р. https://dictionary.cambridge.org/us/...nglish/project.

    Енгель, Крістіна. 2017 рік. «Планування проекту проектування ліній електропередачі». Презентація PowerPoint для заняття з технічного управління проектами, Університет Вісконсин-Медісон, 12 жовтня.

    Грабан, Марк. 2014 рік. «#Lean: Уточнення поштовху, тяги та потоку в лікарні; Пацієнт «тягне». Lean Блог Марка Грабана. 24 лютого. https://www.leanblog.org/2014/02/flo...in-a-hospital/.

    Зелена вікі. 2015 рік. «Розробка сталого кодексу». Зелена Вікі. 9 червня. http://green.wikia.com/wiki/Sustaina...de_development.

    Хозі, Ленс. 2005 рік. «Більш конструктивні шляхи побудови міста». Вашингтон Пост, 9 січня. www.washingtonpost.com/wp-dyn... -2005Jan7.html.

    Канарі, Н., Й.Л. Піно, і С.Шалларі. 2003. «Переробка транспортних засобів із закінченням терміну експлуатації в Європейському Союзі». Журнал товариства мінералів, металів та матеріалів, серпень. Доступ до червня 9, 2015. www.tms.org/паби/журнали/jom... nari-0308.html.

    Коліно, Джонатан А. 2015. «У «Неправильній поведінці» професор економіки не боїться напасти на свою власну». Нью-Йорк Таймс, 5 травня. http://www.nytimes.com/2015/05/06/bu...aler.html? _r=1.

    Ларсон, Ерік В., і Кліффорд Грей. 2011 рік. Управління проектами: Управлінський процес, Шосте видання. Нью-Йорк: Макгроу-Хілл Освіта.Лауфер, Олександр. 2012 р. Оволодіння лідерською роллю в управлінні проектами: практики, які дають чудові результати. Верхня річка Сідла: FT Press.

    Лауфер, Олександр, Едвард Хоффман, Джеффрі Рассел та Скотт Камерон. 2015 рік. «Що роблять успішні менеджери проектів». Огляд управління MIT Слоун, весна: 43-51. http://sloanreview.mit.edu/article/w...t-managers-do/.

    Інститут бережливого підприємства. 2014 рік. Lean Лексикон, п'яте видання. Під редакцією Чета Мархвінського. Кембридж, Массачусетс: Інститут Lean Enterprise.

    Інструменти бережливого виробництва. n.d. «Відходи дефектів; причини, симптоми, приклади та рішення». Інструменти бережливого виробництва. Доступ до 11 листопада 2017 року. http://leanmanufacturingtools.org/12...and-solutions/.

    — н.д. «Відходи перевиробництва; причини, симптоми, приклади та шляхи вирішення». Інструменти бережливого виробництва. Доступ до 11 листопада 2017 року. http://leanmanufacturingtools.org/11...and-solutions/.

    Меррілл, Роберт, інтерв'ю Енн Шаффер. 2017 рік. Старший бізнес-аналітик, Університет Вісконсин-Медісон (2 жовтня).

    Мерроу, Едвард W. 2011. Промислові мегапроекти: концепції, стратегії та практики успіху. Хобокен, Нью-Джерсі: Джон Вілі & Sons, Inc.

    Міріц, Ларс. 2012 рік. «Опитування Gartner показує, чому проекти провалюються». Це те, що добре виглядає. 10 червня. https://thisiswhatgoodlookslike.com/...projects-fail/.

    ORC International: Експертні консультаційні послуги. n.d. Експерти з швидкого розвитку продуктів. Доступ до 9 вересня 2016 року. http://www.orcexperts.com/experts.as...ct+development.

    Пагенкопф, Девід. 2018 рік. «Електронна пошта про сталий розвиток та дизайн програмного забезпечення».

    Талер, Річард Х. 2015. «Якщо ви не Спок, невідповідні речі мають значення в економічній поведінці». Нью-Йорк Таймс, 8 травня. http://www.nytimes.com/2015/05/10/up...abt=0002&abg=0.

    Вандербург, Гленн. 2011 рік. «Самотня зірка Рубі конференції 2010 Реальна інженерія програмного забезпечення Гленна Вандербурга». Опубліковано 24 жовтня 2011 року. Відео на YouTube, 51:56. https://www.youtube.com/watch?v=NP9A...ature=youtu.be

    Вомак, Джеймс П., і Деніел Т. Джонс. 2003 рік. Бережливе мислення: виганяйте відходи та створюйте багатство у вашій корпорації, переглянуті та оновлені. Нью-Йорк: Вільна преса.

    1. У кивку на витоки Lean, японського слова, що означає відходи, муда часто використовується в публікаціях про Lean. ｜