Шість міфів розробки продукту

image

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

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

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

Помилка 1: підвищення утилізації ресурсів підвищить ефективність роботи


Дуже багато компаній намагаються повністю задіяти наявні у них ресурси з розробки. Середній менеджер по продукту тримає показник використання ресурсів на позначці в 98%. Логіка зрозуміла – проекти робляться довше, якщо люди не зайняті на 100%, тому зайнята організація буде працювати швидше і ефективніше, ніж та, яка не так добре використовує всі людські ресурси.

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

Вони не беруть до уваги мінливість роботи розробника

Багато аспектів розробки непередбачувані – коли з'являться проекти, рішення яких завдань вони вимагатимуть, як багато часу займе у тих людей, хто не займався такими речами раніше, на їх завершення. Але компанії найбільше знайомі з повторюваними процесами, типу виробництва або обробки транзакцій, де робота не змінюється, а сюрпризів з'являється мало. Такі процеси працюють за графіком, та утилізація ресурсів підвищується. Щоб виконати на 5% більше, і часу буде потрібно на 5% більше.

Ці процеси ведуть себе зовсім по-іншому. При збільшенні утилізації ресурсів затримки різко зростають. Додайте на 5% більше роботи, і її завершення може зажадати на 100% більше часу. Але мало хто це розуміє. З нашого досвіду з сотнями команд розробників ми знаємо, що більшість з них працює більше, ніж потрібно. Щоб закінчити всі проекти вчасно і вкластися в бюджет, деяким організаціям, з якими ми працювали, треба було б на 50% більше ресурсів.

image
Залежність часу очікування закінчення роботи від відсотка утилізації ресурсів

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

Вони не розуміють, як черзі впливають на економічну ефективність

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

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

При розробці софта те, що знаходиться в процесі розробки, зазвичай можна побачити

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

Дуже важко боротися з проблемою, яку не можна побачити й виміряти. Розглянемо фармацевтичну компанію. Кілька років тому новий директор по розробці ліків зіткнувся з дилемою. Він намагався повернути своїх вчених на інноваційний шлях. Він хотів, щоб вони експериментували з новими хімічними речовинами, які в перспективі могли стати ліками, і при цьому як можна швидше позбувалися від безперспективних кандидатів. При цьому тести на тварин лежали в області відповідальності іншого департаменту, який йому не підкорявся. Цей департамент оцінювали за того, наскільки ефективно він використовував ресурси для тестування, що призводило до необхідності високої утилізації ресурсів. Природно, вчені з відділу розробки ліків очікували за 3-4 місяці результатів тестів, на проведення яких було потрібно всього близько тижня. «Хороше управління» відділом тестування заважало працювати відділу розробки.

Очевидним вирішенням подібних проблем є створення буферних потужностей для непостійних процесів. Деякі компанії давно це зрозуміли. В 3М вже кілька десятків років розробники задіюються на 85% їх потужності. У Google інженерам дозволяють 20% часу (день у тиждень) займатися чим завгодно, що означає, що їм завжди доступно додатковий час у разі затримки проекту. Але таке рішення досить складно організувати. Мало хто уникне спокуси зайняти співробітників на 100%. Менеджери рефлекторно видають нові завдання, коли бачать простої.

Але є й інші рішення.

Змінити систему управління

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

Вибірково збільшувати ресурси

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

Обмежити кількість активних проектів

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

Поліпшити видимість завдань, над якими йде робота

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

image
Типовий вид дошки контролю процесу розробки

Перша колонка – нові завдання, приблизно однакові за складністю. Друга – задачі в роботі. Цифра позначає максимальну кількість одночасно виконуваних завдань. Флажочек завдання означає проблему. Третя – готові до тестування частини. Повернутий листочок означає необхідність втрутитися менеджеру. Четверта – досліджувані завдання. Цифра позначає максимальну кількість одночасно виконуваних завдань сумарно в обох колонках. П'ята – завдання, які пройшли тестування.

Помилка 2: обробка завдань великими партіями покращує економіку процесу розробки


Друга причина появи черг при розробці продукту – розмір партій. Припустимо, новий продукт складається з 200 компонент. Можна вирішити розробити і побудувати всі 200 перед тим, як почати їх тестувати. Але якщо замість цього розробити 20 компонент, то розмір партії буде на 90% менше. Це сильно зменшить час очікування, оскільки в середньому чергу пропорційна розміру партії.

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

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

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

image

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

Розібралися в цьому питанні, компанії починають зменшувати розміри партій, що призводить до дивних результатів. Деякі замість одного тестування великих партій раз в 90 днів переходять до тестувань малих партій кілька разів в день. Один виробник комп'ютерної периферії зменшив час циклу тестування софта на 95% (з 48 місяців до 2,5), збільшив ефективність на 220% і зменшив кількість дефектів на 33%. Економія склала в два рази більше того, чого очікувала компанія.

Помилка 3: у нас чудові плани розробки, потрібно лише суворо їх дотримуватися


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

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

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

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

Помилка 4: чим раніше почнемо, тим раніше закінчимо


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

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

Важливість зменшення кількості незавершеної роботи очевидна, якщо поглянути на формулу з класичної теорії черг – закон Литла. В середньому час циклу пропорційно розміру черги, поділеній на швидкість обробки. Якщо в Старбаксе перед вами коштує 20 осіб, і бариста обслуговує п'ять осіб на хвилину, то вас обслужать через 4 хвилини. Час циклу можна зменшити, збільшуючи швидкість або зменшуючи кількість робіт. Зазвичай на практиці вдається реалізувати другий варіант.

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

Помилка 5: чим більше можливостей у продукті, тим він популярніше


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

Компанії, які не вважають, що більше – значить краще, випускають елегантний у своїй простоті продукти. Датський виробник аудіотехніки, телевізорів і телефонів Bang & Olufsen розуміє, що клієнтам не завжди подобається гратися з еквалайзером, балансом та іншим, щоб знайти оптимальну комбінацію параметрів для прослуховування музики. Їх колонки класу high-end автоматично підлаштовуються під пісні – все, що залишається клієнту, це вибрати гучність.

Переконувати компанії в тому, що «менше» іноді може означати «більше», важко, оскільки доводиться докладати зусилля у двох областях розробки.

Визначення проблеми

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

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

Визначення того, що можна сховати або від чого можна відмовитися

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

Одна з розуміючих це компаній – Apple. Їх найбільша перевага полягає в можливості дістатися до суті проблеми. Як казав Джобс: «Коли ти починаєш розглядати проблему, і вона здається дуже простий – ти не розумієш її складності, і твої рішення будуть занадто простими. Заглиблюючись у проблему, ти бачиш, що вона складна. І ти приходиш до різних заплутаним рішень – на цьому більшість людей і зупиняються». Але не Apple. «Дійсно велика людина продовжить рух і знайде ключовий принцип в основі проблеми, і прийде до гарного і елегантного рішенням».

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

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

Розробники часто думають, що продукт закінчений, коли більше нічого додати. Їх логіку треба звернути – продукти наближаються до досконалості, коли з них нічого викинути. Як сказав Леонардо да Вінчі: «Простота – краще ускладнення».

Оману 6: ми будемо більш успішні, якщо у нас все вийде з першого разу


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

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

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

Інструкція щодо уникнення типових помилок:
  1. Робіть черги і потоки інформації видимими
  2. Оцінюйте вартість затримок і враховуйте її
  3. Не задійте ресурси на 100%, опустіть утилізацію там, де вона дуже висока
  4. Пересуньте увагу систем контролю ефективності на час відгуку
  5. Зменшіть вартість транзакцій, щоб можна було працювати з меншими партіями і більш швидким відгуком
  6. Експериментуйте з партіями поменше. Завжди можна повернути, як було.
  7. План розробки – це гіпотеза, яка буде еволюціонувати при надходженні нової інформації
  8. Починайте проекти, тільки якщо всі ресурси для них повністю доступні
  9. Налаштуйтеся на простоту. Думайте, що можна видалити, а не тільки про те, що можна додати.
  10. Експериментуйте раніше, швидше і частіше. Використовуйте комп'ютерні моделі і фізичні прототипи.
  11. Накладається і итеративная розробка краще лінійної
  12. Налаштовуйтеся на прискорення відгуків, а не на успіх з першого разу


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

Експерименти з різними ідеями – обов'язкова частина процесу інновацій. Коли експериментуєш часто і швидко, звичайно, доведеться змиритися з крахом багатьох ідей. Але це дозволяє командам швидше відкидати погані рішення і концентруватися на більш перспективних.

Класичний приклад переваг підходу «ошибайся раніше і частіше» – несподівана перемога команди Нової Зеландії на «Кубку Америки» 1995 року по яхтенному спорту. Для покращення дизайну кіля команда використовувала дві однакових човни, одна з яких змінювалася в процесі розробки, а друга залишалася контрольної. Щодня команда симулювала нові гіпотези на комп'ютері, застосовувала кращі з них, а потім влаштовувала змагання з контрольною човном і вивчала результат.

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

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

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

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

Розвиток IT (комп'ютерний дизайн, моделювання, симуляція) вже дозволило зробити кроки на шляху до розробки кращих продуктів за менший час і гроші. Але багато компаній не користуються всім потенціалом цих інструментів, оскільки їх управлінське мислення розвивається повільніше технологій. Вони все ще підходять до розробки інформаційного продукту як до фабричного виробництва. З розвитком інформаційних технологій можливостей щодо поліпшення процесу розробки продукту буде ставати ще більше – тому більшим буде і ризику для тих компаній, які не змогли розгледіти відмінностей між розробкою софта і фабричним виробництвом.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.