Прогресивна розробка для успіху проекту

Прогресивна розробка - крок за кроком будуйте успіх проекту

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

Прогресивна розробка

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

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

• Точність - це не те саме, що деталі.
• Отримати це правильно з першого разу дешевше.
• Нам не потрібно проектувати все це відразу, спереду.

Читайте далі, щоб дізнатись більше.

Точність - це не те саме, що деталізація

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

Щоб зробити це добре, ми повинні бути дуже чіткими: Заява про обсяг високого рівня або дизайн може бути не детальною, але вона все одно повинна бути точною. Це може бути коротко і просто, але воно повинно бути позбавлене будь-якої невизначеності.

Тематичне дослідження: Покращення веб-сайтів для підвищення рівня конверсії

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

Давайте поступово детально розробимо обсяг цього проекту:

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

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

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

Докладніше: Занурення в маркетингові деталі

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

• Менше клацань, щоб закрити. Дослідження показують, що чим більше кліків відбувається між переходом на сторінку та укладанням угоди, тим більше людей відмовляється від сайту. Тож сторінки можна впорядкувати, щоб збільшити коефіцієнт конверсії.
• Створення відчуття актуальності. Якщо товар схожий на те, що він з’явиться пізніше, люди часто відкладають покупку - а потім більше не повертаються. Можливо, команді технічного маркетингу доведеться повернутися до керівників, щоб запитати, чи короткострокові знижки є прийнятним способом збільшення швидкості закриття.
• Усуньте плутанину. Докладні інструкції та велика кількість юридичних мов зменшать швидкість закриття.
• Прямі цільові сторінки. Оголошення повинні переходити безпосередньо на цільові сторінки, які є сторінками продажу рекламованого товару.
• Вітаємо клієнтів назад. Використовуючи файли cookie, логін клієнта або те й інше, ми можемо направити клієнтів, що повертаються, туди, куди вони найбільше хочуть піти. Ми також можемо зв’язатись із виконавчим директором щодо збереження кредитних карток, щоб впорядкувати майбутні покупки.

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

Художники завжди застосовували прогресивну розробку

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

Едгар Дега, Музей Лувру, Париж (Public Domain) через Wikimedia Commons

Тут, у цьому ескізі чорною крейдою, концепція розроблена більш повно як «Етюд для портрета Едуарда Мане». Розробка прогресує.

Едгард Дега, Метрополітен-музей Нью-Йорка (Public Domain) через Wikimedia Commons

Цей повний "Офорт" Портрета Едуарда Мане, Етюд ", сидячи, повернутий ліворуч, є багатим, сильним результатом поступової розробки Дега його теми.

Едгар Дега, Публічна бібліотека Бостона (Public Domain), через Wikimedia Commons

Як правильно це зробити з першого разу, це дешевше

Для будь-якого проекту є лише три варіанти щодо якості та результатів:

• Найменш дорогий вибір - це правильно визначити речі з першого разу.
• Другий варіант - помилитися, а потім виправити під час проекту.
• Третій варіант - помилитися і дати погані результати.

Тож, загалом, на початку краще бути чітким і точним. Наскільки краще? Результати досліджень за останні 40 років показали, що існує співвідношення між ціною запобігання помилки; вартість виправлення помилки під час проекту; та витрати на прибирання безладу після проекту. А мінімальне співвідношення - 1: 10: 100. Отже, помилка, яку можна запобігти додатковою годиною планування на рівні 100 дол.. А співвідношення набагато вищі за 1: 10: 100 було виявлено, якщо ми використовуємо найкращі практики управління якістю для створення бездефектного дизайну з самого початку.

Урок: Поступове вдосконалення - розвиток деталей у міру просування вперед - завжди має сенс. Недбала робота ніколи не має сенсу.

Нам не потрібно робити це відразу

Ми робимо добру, чітку роботу на кожному кроці. У той же час нам не потрібно визначати весь проект одночасно або визначати всі деталі на початку. Натомість ми можемо працювати поетапно. Ми чіткі та точні на кожному етапі, але деталізуємося по ходу. Це називається прогресивною розробкою. Робити це добре включає:

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

Прогресивна розробка проектів, що усувають проблеми

Проекти, що вирішують проблеми, є особливим випадком, коли поступове вдосконалення є особливо корисним.

Проблема полягає в тому, що з’явилося, що зупиняє компанію чи виробничу лінію працювати так, як раніше. Тож мета вже зрозуміла: змусьте цю д ** мн * д справу працювати! Залучення керівників мінімальне, і керівникам мало що робити, крім надання підтримки. Насправді, оскільки менеджери вже знають, що таке "річ" і як вона повинна працювати, "Зробіть цю д ** мн * д річ справною!" є повною та точною заявою високого рівня, виконавчої сфери.

Тематичне дослідження: затримка запуску космічного човника «Атлантида» у 2006 році

Хороший приклад подібного типу проектів стався в 2006 році, коли проблеми в 10-річному датчику рівня палива, який вимірював кількість водню в паливних баках на космічному кораблі "Атлантида", не зникали. Датчик стає ненадійним, іноді показуючи, що бак був порожнім, коли він був повним, і проблема періодично.

Заява про сферу діяльності керівника була б чіткою: зафіксуйте манометр, щоб ми могли літати на човні!

Однак, досліджуючи проблему рівень за рівнем, використовуючи поступове опрацювання, ми знаходимо чотири технічні проблеми, які ускладнюють вирішення проблеми:

• Рішення керівництва: Якщо ми знаємо, що датчик несправний, чи можемо ми його просто вимкнути, покластися на інші датчики і все одно літати. З цього приводу було багато суперечок. Але нарешті було вирішено, що основна характеристика безпеки, відключення головного двигуна (MECO), не буде надійною без цього датчика. Тож рішення керівництва полягало в тому, що датчик повинен бути фіксованим.
• Технічне питання: проблема була періодичною. Тому будь-яке пройдене випробування не було доказом того, що датчик працює і що човник може безпечно літати. Потрібно було знайти конкретну проблему, щоб переконатися, що вона виправлена.
• Детальне технічне питання: Датчик був не простим пристроєм. У ньому брало участь безліч різних компонентів та електричних роз’ємів між ними. Деякі з них були поховані глибоко в проводці човника. Просто знайти всі компоненти та почистити їхні роз’єми було великою роботою. Не раз інженери думали, що усунули проблему, але датчик не перевіряв чистоту.
• Дуже детальне технічне питання: Плани проекту Космічного човника, можливо, не точно відповідали Атлантиді, оскільки вона була побудована. Деталі були модернізовані та замінені. Один інженер повідомив, що виявити всі частини датчика було дослідницькою місією, що вони все ще з'ясовували, як працює космічний човник!

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

Прогресивна розробка - це не просто сфера застосування

Незважаючи на те, що ця стаття зосереджується на поступовій розробці при розробці визначення сфери застосування та структури розподілу робіт (СРБ), концепція поступової розробки є ширшою, ніж ця. Фактично він може бути застосований до всіх дев'яти областей управління проектом. Ось кілька прикладів:

Поступова розробка плану комунікацій проекту

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

• Визначення всіх зацікавлених сторін проекту та додавання їх до списку
• Вирішення, як спілкуватися з кожною зацікавленою стороною
• Вирішення питання, як включити голос замовника до проекту

Розробка управління ризиками в проекті

Формальні кроки управління ризиками проекту поступово розробляють наше визначення проектного ризику - що може піти не так - і нашу відповідь шляхом:

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

З цих прикладів видно, що поступове вдосконалення є стандартною практикою для всіх дев'яти областей управління проектами.

Прогресивна розробка та життєві цикли проекту

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

Прогресивна розробка в класичному водоспаді

У класичному водоспаді або життєвому циклі розвитку системи (SDLC) все планування передує виконанню. Тому поступове опрацювання обсягу все відбувається на етапах планування.

Прогресивна розробка із швидким відстеженням

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

Одночасне управління проектами

Одночасне управління проектами було розроблено компанією Hewlett-Packard і зараз широко використовується в автомобільній промисловості. Об’єднавши на початку всіх різних фахівців, життєвий цикл проекту (скажімо, для виведення на ринок нового концепт-кар) можна скоротити з п’яти років до 18 місяців! При одночасному управлінні проектами прогресивна розробка виконується на ранній та швидкій основі міжфункціональними групами.

Розробка програмного забезпечення з нульовими дефектами

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

Спіральна модель

Спіральна модель була попередницею Agile Development. Він розміщує функції за розкладом, і, якщо функція запізнюється, вона скидається до наступного циклу по спіралі. кожна функція розробляється в міру розробки для проектування, а потім знову - у наступному циклі, коли вона розробляється.

JAD і RAD

JAD, спільна розробка додатків та RAD, швидка розробка додатків, не є фактичними альтернативами життєвого циклу. Швидше, це техніки визначення вимог, які впливають на життєвий цикл. Розміщення дизайнерів та програмістів у безпосередній близькості від своїх клієнтів та користувачів програми пришвидшує розробку. Часті зустрічі дозволяють швидко і поступово розробляти. І цей підхід є ключовою складовою Agile Development.

Прогресивне вдосконалення у швидкому розвитку

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

Що ви думаєте про прогресивну розробку?

Прогресивна розробка продовжує рух проекту

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