Справа з невдалими спринтами та термінами

Багато книг і статей Scrum говорять про те, що невдалий спринт (коли команді не вдалося виконати деякі функції зі списку "Спринту") не є чимось таким поганим, він буває час від часу, і він може бути корисним, якщо команда вчиться на своїх помилках і покращує щось у наступних спринтах. І команду не слід карати за те, що вони не виконали роботу, яку вони взяли на себе.

Це виглядає чудово з точки зору розробника, проте, скажімо, у нас є компанія-виробник програмного забезпечення " Scrum-Addicts LLC ", яка розробляє щось для серйозних клієнтів (" Money-Bags Corporation "):

1. Менеджери Scrum-Addicts пропонують скласти частину програмного забезпечення для Money-Bags
2. Вони домовляються про перелік функцій, і Money-Bags просить надати дату доставки
3. Менеджери Scrum-Addicts проконсультуються зі своєю командою scrum, і команда каже, що для завершення всіх функцій потрібно три тижні спринти.
4. Менеджер Scrum-Addicts додає 1 тиждень, щоб бути в безпеці, обіцяє поставити програмне забезпечення протягом 1 місяця і підпише контракт з Money-Bags
5. Після 4 спринтів (термін доставки) команда Scrum може надати лише 80% функцій (через недосвідченість нової системи, необхідність виправлення критичних помилок у попередніх функціях у виробничому середовищі тощо)
6. Як підкреслює Scrum, на даний момент продукт потенційно постачається, але Money-Bags потребує 100% функцій, як зазначено в контракті. Тож вони розривають договір і нічого не платять.
7. Scrum-Addicts знаходиться на межі банкрутства, оскільки грошей у Money-Bags не отримали, а інвестори були розчаровані результатами та не бажають більше допомагати компанії.

Очевидно, жодна програмна компанія не хоче бути у взутті Scrum-Addicts. Що я не розумію щодо Agile та Scrum - це те, як вони пропонують командам боротися з плануванням та термінами, щоб уникнути описаної вище ситуації. Отже, підводячи підсумок, у мене є 2 питання:

Хто винен?

1. Менеджери, тому що їхня робота - належне планування
2. Команда, бо вони взяли на себе зобов’язання зробити більше роботи, ніж могли
3. Хтось інший

Що робити?

1. Керівники повинні перенести термін в 2 рази (або 3 рази) пізніше, ніж початковий кошторис команди.
2. Членів команди слід заохочувати виконувати всю роботу, яку вони виконували, незважаючи ні на що (видаючи штрафи за невдалі спринти)
3. Команда повинна відмовитися від Scrum, оскільки він не відповідає політиці щодо термінів компанії
4. Усі ми повинні кинути розробку програмного забезпечення та приєднатися до монастиря
5. ???

Я бачу у вашому прикладі кілька основних питань управління:

• якщо менеджер Scrum-Addicts підписує «жорсткий термін» контракту, але додає лише запас міцності в 33% в ситуації, коли «задіяна нова система», це досить необачно.

• наявність доставки принаймні x% функцій через місяць могла бути використана для укладання договору, коли клієнти платять гроші принаймні частково, коли він отримує лише 80% функцій у крайній термін. Договір «майже або нічого» - це ні від чого, ні постачальник програмного забезпечення, ні замовник не матимуть користі - це означає не лише 0 грошей для постачальника, але й 0 функцій для клієнта. І методологія розробки, яка чи ні нічого, як "Водоспад", дозволить вам лише писати такі контракти, спритний підхід пропонує додаткові можливості.

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

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

Одним із вартісних тверджень " Маніфесту для спритного розвитку програмного забезпечення " є:

Співпраця з клієнтами щодо узгодження договорів

Той факт, що ТОВ «Scrum-Addicts» уклало договір замість встановлення співпраці з замовником, змушує мене поставити під сумнів їхню спритність.

Ясно одне: спритність повинна бути прийнята КОЖНИМ. Спритність не тільки для розробників. Менеджери та клієнти також повинні прийняти значення Agile Manifesto. Якщо клієнти не приймають спритність і все-таки вимагають жорстких контрактів і мінімальної співпраці, то або не використовуйте спритних, або шукайте кращих клієнтів.

Виною замовника є те, що вони замикаються у своєму контрактному міхурі з розробленим терміном.

Хто винен?

Менеджери, юридичні працівники, бухгалтери - прийміть свій вибір ...

Я знаю, що приклад дещо надуманий, але той факт, що компанія могла б піти, не платячи ні копійки, якби вони не були на 100% задоволені, повинен був би дзвонити негайними дзвінками тривоги, як слід змішувати водоспад і спритне мислення.

Клієнти хочуть придбати торт і з'їсти його - вони із задоволенням приймають водоспад, міні-водоспад, спритний, ля-ля-земля до тих пір, поки вони отримають продукт X за $ Y за датою Z.

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

ІТ-проекти стосуються невідомих ; деякі з цих невідомих навіть невідомі . Що це означає?

Візьмемо для прикладу іграшковий міст для вашої моделі залізниці. Є всі відомі вам параметри:

• Ви знаєте, яка велика долина

• Ви знаєте матеріал гір, їх висоту, стійкість тощо.

• Ви знаєте, скільки матеріалу вам потрібно

• Ви знаєте з попередніх "проектів", скільки часу вам знадобилося, щоб будувати подібні речі

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

Візьміть приклад на крок далі:

• Скажіть, ви не будуєте міст для власної моделі залізниці, натомість ви будуєте його для абсолютно незнайомця: ваше завдання - побудувати залізничний міст між двома горами

• Скажіть, у вас заздалегідь відсутня інформація про пейзаж моделі

• Інформація про ландшафт - це дві гори, які здаються не надто великими

• Консистенція гори знаходиться між скелею і желе

• Загальна вартість має максимум 10 $

• На робочому місці повністю темно і немає шансів на світло: у вас є лише коробка з 8 сірників

• Кінцевий термін - 3 години

Це була б аналогія ІТ-проекту. У вас є досвід будівництва мостів, і ви можете легко ходити по відомій місцевості. Що робить це важко - це темрява . Є багато речей, які навряд чи можна передбачити: Міри гір відомі лише після того, як тикатимеш деякий час у темряві. Так само і консистенція гір. З цього ви могли б оцінити, скільки часу це займе у вас і скільки це буде коштувати. Тут невідомі речі, про які ви не знаєте на початку проекту, як, наприклад, конкретна місцевість тощо. Ці речі - це невідомі невідомі, які несуть трохи хаосу.

Кожна ІТ-компанія повинна це знати. Вони повинні мати справу з ризиком проекту.

1) Існує кілька способів мінімізувати (фінансовий) ризик: угода може включати в себе, якщо клієнт платить за кожен робочий приріст. Тож після того, як приріст 1 буде доставлений, необхідно сплатити часткову ставку. Поки ТОВ Scrum-Addicts LLC надає мінімальний фінансовий ризик. Чим більше запланованих спринтних цілей планується, тим нижчий загальний ризик кожного спринту. Це означає, що якщо корпорація Money-Bags отримала 80% від контракту, вони повинні принаймні заплатити 80% вартості контракту. Якщо вони відмовилися платити після невдалого спринту, ризик не такий високий, як відмова від сплати 100%.

2) ТОВ «Scrum-Addicts» має проблеми зі своїми розробниками

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

Це говорить про те, що а) розробники не мають досвіду scrum або b) вони роблять scrum неправильно. Чим довше команди працюють з scrum, тим краще їх оцінки. Якщо команди роблять оцінки, а менеджер додає "буфер" як "безпеку", менеджер, здається, знає краще, ніж команда, що є поганою ознакою . Якщо у вас є досвідчена команда, немає необхідності в "менеджері буфера", команда включила це вже в оцінку. Ідея полягає в тому, що чим більше спринтів працює команда, тим більше команда знає свої сильні та слабкі сторони та має певні показники, щоб зробити реалістичні оцінки. Звичайно, є, як уже говорилося, невідомі невідоміякі мають тенденцію робити важкі оцінки; або принаймні неточні. Але в перспективі оцінки повинні стати кращими і кращими.

Хто винен?

1) Управління

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

2) Команда

Навіть якщо керівництво є дурним, команда повинна висловитись проти такого проекту. Хороший керівник повинен знати ризики; але хороший розробник повинен вказувати на ризики. І найбільше: Команда повинна звітувати рано, якщо щось не вдасться.

Що робити?

Тепер: візьміть суди з грошима

На майбутнє: не укладайте таких договорів

Scrum не винен у збоях управління. Scrum був розроблений на основі досвіду багатьох ІТ-проектів, які провалюються. Це не може запобігти невдачі, не може вилікувати некомпетентність команд чи керівництва. Основна ідея:

• структурувати способи спілкування (хто з ким спілкується, коли про що)

• заохочувати розробників повідомляти про помилки рано

• розділити задачі на завдання та підзадачі

• структурувати час та потужності (хто працює, коли на чому)

• розподілити завдання за часовими інтервалами

• зробити непередбачуваним трохи більш передбачуваним (планування покеру)

або загалом: мінімізувати ризик.

Scrum - це інструмент, як і молоток. Чи це гарний інструмент, залежить від ваших знань, як ним користуватися. Але іноді викрутка підходить краще. Тобі вирішувати.

По-перше, "хто винен?" неправильне запитання. Призначення звинувачення - це весело і все, і, мабуть, змусить усіх, крім звинувачених (-ів), почувати себе полегшеним (у сенсі "ей, це не моя вина, бос сказав так!"), Але це не продуктивне використання вашого часу , і насправді може бути контрпродуктивним і спричинити падіння моралі працівників.

Кращий спосіб поглянути на це "Що спричинило затримку?". Чи не вистачало досвіду в галузі технологій? Критичні помилки, які не були виявлені при тестуванні / КЯ? Відсутність тестування / КЯ? Занадто оптимістично в оцінці? Не враховуючи не настільки оптимістичні оцінки команди? Хтось потрапив у автобус? Незалежно від причини, наступне питання - "Як ми можемо переконатися, що це не повториться?". У деяких (сподіваюсь, рідкісних) випадках відповідь може бути "позбутися" і так ", але якщо ви почнете з" Мені потрібно покарати того, хто несе відповідальність ", ви навряд чи побачите більшість справ. де це не правильне рішення.

В рамках проекту ви вже потонули. Кінцевий термін прийшов і пішов, ви попередили замовника, як тільки було очевидно, що він проскочить (адже ви це зробили, правда? Якщо ні, то це частина проблеми), і тепер це потрібно вирішити, однак це було прописано в договорі (це фактично прописано в договорі, правда?). Взагалі, це повинно включати переговори з замовником, як ви збираєтеся доставити те, чого не вистачає. Багато людей люблять думати про договір як про щось, що неможливо змінити, але стикаються з тим, що: а) відмовитися від договору і не мати того, що ви купили; б) подати позов на компанію за порушення договору і витративши багато грошей у суді, і c) домовляючись про те, як отримати свій товар з найменшою можливою проблемою, більшість компаній обирають c.

Дивлячись вперед, перш ніж зазначати клієнту ціну / термін, слід проаналізувати ризики, пов'язані з простроченим терміном або перевищенням витрат (які можливі причини такої речі? Які причини можна якось пом'якшити, а які ви не можете і просто доведеться планувати) і використовувати цю інформацію, щоб допомогти вирішити, що ви збираєтеся обіцяти. Якщо це випадок, коли це 100% або нічого, ви, очевидно, процитуєте більш високі ціни та більш тривалі терміни, оскільки ризик вище.

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

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

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

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

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

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

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

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

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

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

Багато книг і статей Scrum говорять про те, що невдалий спринт (коли команді не вдалося виконати деякі функції зі списку "Спринту") не є чимось таким поганим, він буває час від часу, і він може бути корисним, якщо команда вчиться на своїх помилках і покращує щось у наступних спринтах. І команду не слід карати за те, що вони не виконали роботу, яку вони взяли на себе.

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

Це виглядає чудово з точки зору розробника, проте, скажімо, у нас є компанія-виробник програмного забезпечення "Scrum-Addicts LLC", яка розробляє щось для серйозних клієнтів ("Money-Bags Corporation"):

Менеджери Scrum-Addicts пропонують скласти частину програмного забезпечення для Money-Bags. Вони домовляються про перелік функцій, і Money-Bags просить вказати дату доставки. Менеджери Scrum-Addicts проконсультуються зі своєю командою scrum, і команда каже, що це займе 3 тижні -довгий спринт, щоб виконати всі функції менеджер Scrum-Addicts додає 1 тиждень, щоб бути безпечним, обіцяє поставити програмне забезпечення протягом 1 місяця та підписувати контракт з Money-Bags. Після 4 спринтів (термін доставки) Scrum команда може доставити лише 80% особливостей (через недосвідченість нової системи, необхідність виправляти критичні помилки в попередніх функціях у виробничому середовищі тощо). Як вважає Scrum, на даний момент продукт потенційно можна поставити, але Money-Bags потребує 100% особливостей, зазначених у договорі. Тож вони розривають договір і нічого не платять.

Scrum-Addicts знаходиться на межі банкрутства, оскільки грошей у Money-Bags не отримали, а інвестори були розчаровані результатами та не бажають більше допомагати компанії.

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

Очевидно, жодна програмна компанія не хоче бути у взутті Scrum-Addicts. Що я не розумію щодо Agile та Scrum - це те, як вони пропонують командам боротися з плануванням та термінами, щоб уникнути описаної вище ситуації.

Подумайте, Чому МБ хоче взяти свій бал і піти додому. МВС не вимагав, щоб робота була виконана через місяць з самого початку. SA пообіцяв 100% критичних особливостей за один місяць і не виконав. SA встановив термін не МБ. SA навіть довільно додала тиждень до дедлайну. То чому це термін?

Іноді, коли змагаються за роботу, програмні компанії піддаються спокусі показати і обіцяти місяць. Професіонали ретельно встановлюють, чи потрібен навіть місячний місяць. Яка більш критична потреба у MoneyBags? 100% функцій чи функціонуючого продукту через місяць? Чи вони навіть знають, що є справді критичним? Чи є якась майбутня подія, яка встановить важкий термін?

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

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

Отже, підводячи підсумок, у мене є 2 питання:

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

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

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

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

Що робити?

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

Керівники повинні перенести термін в 2 рази (або 3 рази) пізніше, ніж початковий кошторис команди.

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

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

Членів команди слід заохочувати виконувати всю роботу, яку вони виконували, незважаючи ні на що (видаючи штрафи за невдалі спринти)

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

Даніель Пінк про це говорить TED . Розмова про мотивацію не спритну, але я легко бачив, як відобразити ці моменти до спритного:

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

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

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

Усі ми повинні кинути розробку програмного забезпечення та приєднатися до монастиря

Правильно, як зачинити мене в кімнаті подалі від реального життя, це змусить мене написати менший код.

Я відредагував цю відповідь до розміру. Якщо вам цікаво, прочитайте історію редагування.

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

Ви не можете вказати дату доставки занадто далеко в майбутнє. Ви даєте оцінку.

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

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

Хто знає, на деяких проектах ви можете швидше відправити.

Ви не можете бути спритними, якщо клієнт цього не хоче.

Мета

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

• чи вигідна робота (для клієнта)
• чи працюємо ми якомога ефективніше

Вони цілком універсальні. Звичайно, це стає дуже складним дуже швидко, наприклад, прибуткова робота - це те, що продукт робить правильно, користувач може використовувати продукт, продукт продається правильно тощо. - Для багатьох таких " Scrum-Addicts ТОВ "не несе відповідальності.

Проблема

Договір не зосереджується на цілях, визначених вище. Існує застереження "все або нічого" - все зробити і заплатити, або нічого не робити і не платити. Однак це не стосується безпосередньо створюваної вартості. Ще один недолік, який випливає: зараз нам потрібно витратити час і запевнити гроші та перевірити, чи виконується контракт. Чому на землі ми б хотіли витратити ці гроші? Як гарантування виконання контракту допомагає, коли вимоги тим часом змінилися, і ми з’ясували, що замовлена ​​частина програмного забезпечення не створює ніякої цінності? Просто більше грошей йде на стік! Тепер, звичайно, є причина такої поведінки:

• Культурно ми звикли купувати подібні речі. Ми очікуємо, що магазин програмного забезпечення буде таким же, як і для автомобіля: виберіть конфігурацію, визначте ціну та термін, і будете дуже нещасні, якщо цих двох не дотримаєте.
• ми хочемо зняти ризик та підзвітність
• ми хочемо стабільності, це допомагає планувати і змушує себе почувати себе краще (а також нашого клієнта, що є важливим аспектом!)

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

Ось як це має працювати

• мати контракт на послуги та роботу замість товару
  • має бути закінченим у відносно короткий термін
• тісно співпрацюйте для забезпечення оптимальної ефективності
• залучіть усіх необхідних сторін, як від ТОВ " Скрум-Аддітс ", так і від " Корпорації грошей-мішків " - "єдиної контактної точки", тунелювання всієї інформації тут не працює.

ну я в основному просто сказав "будь спритний". Тепер ось чому:

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