×Закрыть

Scope creep: причини і наслідки

Чи виникало у Вас коли-небудь таке відчуття, що продукт ніколи не вийде в реліз? Щоразу після зустрічі з представниками замовника з’являється потреба у новій функціональності, а обсяг робіт по існуючому функціоналу росте як на дріжджах. Як наслідок, усі початкові бюджети перевищено, а строки завершення робіт протерміновано. Знайомтесь — перед вами розростання обсягів проекту (в англомовній літературі «scope creep»).

Дослідження Ламрі, проведене більш ніж десять років тому (грудень 2003 — січень 2004), виявило, що 71% проектів перевищують запланований бюджет або потребують перегляду початкового обсягу робіт. У 63% випадків саме scope creep був визнаний основною причиною перегляду бюджетів та термінів виконання проектів. Навіть зараз, через багато років активного розвитку методів управління проектами та обсягом робіт в ІТ, scope creep залишається головним болем. За даними дослідження PMI, 44% завершених у 2015 році проектів страждали від цього явища. При цьому scope creep присутній навіть у проектах із фіксованим бюджетом (так звані fix price), де обсяги робіт та бюджет мали би бути чітко визначеними і зафіксованими наперед.

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

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

Чому виникає scope creep?

Scope creep, або розростання обсягів роботи, — це неконтрольовані зміни або безперервне зростання обсягу робіт проекту, що відбувається в основному через наступні причини:

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

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

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

— Відсутність документації з чітко визначеним початковим набором вимог. Навіть якщо є певний процес управління змінами, майбутнє побажання клієнта не може бути ідентифіковане як запит на зміну (change request), не порівнюючи його з початковими вимогами, зафіксованими в документації.

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

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

— Відсутність процесу управління змінами. Кожне бажання клієнта, особливо важливого для компанії-розробника, розглядається як обов’язкова вимога без будь-якого аналізу наслідків та її впливу на загальний графік проекту.

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

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

Як зарадити розростанню обсягів робіт на проекті?

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

Не існує єдиного методу боротьби із scope creep, але деякі прості кроки можуть зменшити ризик його появи до прийнятного рівня:

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

— Розумійте бізнес-потреби клієнта. Деякі розширення об’єму робіт можуть бути продиктовані не бізнес-потребами, а бажанням зробити продукт кращим на вигляд, або просто додати «вау» ефект. Тим не менше, ви не зможете відокремити один тип запитів від іншого, не розуміючи реальні потреби клієнта. Переконайтеся в тому, що вся команда розуміє бізнес-цілі, і ряд запитів на зміну зникне. Іноді навіть замовникам необхідно нагадати про цілі проекту для запобігання появи зайвого функціоналу.

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

— Не скупіться на фазу discovery. Discovery ваша потужна зброя проти scope creep, і якщо ви вирішили використовувати її, переконайтеся, що вона потрапить в ціль. Оцініть, скільки бізнес-аналітиків і часу вам буде потрібно, щоб виявити і проаналізувати потреби. Слід пам’ятати, що розробка програмного забезпечення — це командна гра, і недостатньо просто виділити аналітика для проекту; для ефективного discovery ви також повинні з самого початку планувати час і залучення зацікавлених сторін у проекті.

— Документуйте початкові вимоги. Вимоги, отримані від клієнта, або ті, що виявились під час discovery, з якими ви збираєтеся почати проект, повинні бути зафіксовані в документі. Незалежно від того, як називатиметься цей документ і як він буде виглядати (формальна специфікація SRS або просто пріоритизований список завдань), і ви, і замовник повинні погодитися, що це базовий рівень, відповідно до якого буде оцінюватися будь-який майбутній запит.

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

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

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

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

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


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

LinkedIn

65 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

перед вами розростання обсягів проекту (в англомовній літературі «scope creep»).

Або creeping featurism — я таке бачив раніше і частіше, ніж scope creep.

Пріоритезація

Пріоритизація. Не треба уподібнюватись безграмотним кацапам, які навіть на власному gramota.ru не перевіряють.

Чому виникає scope creep?

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

Зміни законодавства, принципові зміни методів роботи на ринку — це обʼєктивні обставини. І у їх випадку, чим раніше вони зʼяснені і означені, тим ліпше. Зміна завдання у такому випадку — це нормальна ситуація, і слідкувати треба лиш за тим, чи можна взагалі встигнути за такими частими змінами.
До цього Ваші випадки

> Швидкі зміни в бізнес-середовищі клієнта

Субʼєктивні замовника:

> Метушня під час ініціації проекту
> Відсутність процесу управління змінами
> Активний мікроменеджмент зі сторони клієнта

ще не вказано (або нечітко сказано) — просто часті зміни бажань замовника (клієнта), коли він просто не розуміє, чого хоче.

Лікування — нема загального рецепту, але завжди можна спробувати домовитись і переконати. Але якщо не змогли — краще не продовжувати.

Нарешті, коли виконавець не контролює, що діється,

> Нечітка мета і завдання проекту
> Метушня під час ініціації проекту (так, тут може бути винним і замовник, і виконавець)
> Відсутність документації з чітко визначеним початковим набором вимог
> Неправильна інтерпретація вимог
> Використання модних слів (buzzwords) або термінів без належного пояснення
> Відсутність процесу управління змінами
> Навмисне збільшення обсягу без збільшення бюджету зі сторони клієнта

це все провина виконавця, у більшості випадків. І таки да, як виконавцям, нам треба додержуватись власних інтересів.

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

не варто соромитися запропонувати клієнту так звану discovery фазу перед стартом активного кодування

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

З рештою взагалі згоден. І не забути закласти відсотків 20 на несподіванки. :)

Возможно, не совсем верно понял ваш посыл, вот ситуаций, когда вот это


> Нечітка мета і завдання проекту
> Метушня під час ініціації проекту
> Відсутність документації з чітко визначеним початковим набором вимог

возникало именно по вине клиента, видел хоть отбавляй. В стартапах это так и вообще сплошь и рядом.

В стартапах это так и вообще сплошь и рядом.

В стартапе вообще сложно разделить заказчика и исполнителя, обычно они плавно перетекают друг в друга :) С другой стороны, все эти проблемы составляют даже не боль, а суть стартапа: если бы цель была чёткой, метушни не было, документация была бы идеально выписана — то это уже был бы не стартап :)
Поэтому и изначальная проблема приобретает в них другую форму — она неизбежна, но надо суметь её ограничить теми пределами, в которых ещё можно управлять ситуацией и не падать в пропасть.

Выiдзе!
А не Выiдзе запинаем, что Выiдзе.

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

Я завжди впевнений, що розумію бізнес-потреби клієнта, краще ніж він. :)

Чет я не понимаю, почему бы подрядчику бороться с раширением скоупа? Больше работы — больше денег, в чем проблема?

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

Це проблема, якщо оплата по естімейтах.

Ну тогда это не проблема скоупа а проблема договоренностей?

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

Качаешь головой всякий раз, когда требуют что то сделать бесплатно. В чём проблема?

А ты такой кастуешь «мы так не договаривались» и все.

А ты такой кастуешь «мы так не договаривались» и все.
но проект провалил — ты, а не заказчик.

по крайней мере заказчик будет в этом уверен на все 100%.
еще и другим расскажет о неумехе завершать проекты.

Ну так нужно либо четко прописать что надо сделать, либо не браться вовсе

Ну так нужно либо четко прописать что надо сделать
то есть написать программный код :)

или «спеку по ГОСТу», стоимость которой может потянуть до 40% денег-времени всего проекта :)

либо не браться вовсе
это верно, не беритесь :)

и тогда вам советы как завершать успешно проекты — не понадобятся.

то есть написать программный код :)
Нет, приступать к работе после получения подробного технического задания подписанного заказчиком. Если такого задания нет, пишем его сами проведя предпроектные исследования. За деньги заказчика, естественно. Если заказчик говорит:"я ещё сам не знаю, что мне надо" — работаем из учёта почасовки.
или "спеку по Г
 Бывает до 90% занимает, что из того?
это верно, не беритесь :)
Я наотрез отказываюсь браться за проекты с фиксированной ценой, но не фиксированным объёмом работ. Более того, не приступаю к работе пока не будет чёткого понимания обоими сторонами что надо делать. Тогда на любое возражение мол мне надо совсем не это, или я мол не так это представлял говорю:"дорогой друг, ты подписал техническое задание где подробно описано, что получится в итоге. Если это не то, что ты хотел — проблемы не мои".

к чему вы переписали советы для идеальной из академических книг?

на кой они нужны, в живой разработке :)

Да ну конечно. Придумывал идею заказчик, скоуп формировал заказчик, маркетинг и продажи делал заказчик, а провалил ты. Спокойнее надо. Равнодушнее.

скоуп формировал заказчик
статья как раз о формировании скоупа — совместно.

о контроле над его изменением, которые — неизбежны.

вы похоже не читали статью.

маркетинг и продажи делал заказчик
а вот это — не имеет отношения ни к скоупу, ни вообще к техническому подрядчику.
а провалил ты
провалил тот, кто взял на себя обязательства — и не выполнил их.

Совместно — это так: заказчик пытается объяснить что именно нужно сделать, а подрядчик пытается записать это в виде предсказуемых однозначно трактуемых формулировок, позволяя оценить такой проект, подобрать правильные технологии, собрать команду, вот это все.

Теперь, посреди проекта заказчик пытается раздуть скоуп не меняя бюджет. Подрядчик говорит — нет, это не то, о чем мы договаривались. Ну и кто тут пытается соскочить с взятых на себя обязательств?

Ну и кто тут пытается соскочить с взятых на себя обязательств?
Это его проблемы. В бамажках всё записано, а если не записано, то ... сам понимаешь.
В бамажках всё записано
во-первых в бамажках все — тяжело записать. то есть — дорого и долго.

во-вторых работы только по тому что записано в бамажках и привели к появлению аджайлов, и обвинению waterfall в создании продуктов с ненужным функционалом.

А отсюда, чего нет в бамажках — пиздуйте обсуждать или идите нах.

в бамажках все — тяжело записать. то есть — дорого и долго.
Вот и хорошо: есть полезная и оплачиваемая работа

угу.

но вероятнее будет другое — заказчик пойдет искать другого исполнителя.

который покажет — как он собирается снижать расходы бюджета, а не увеличивать.

потом да, нередко этот заказчик еще и переплатит.

но то его заказчика проблемы :)

а проблемы правильного исполнителя часто — а заказчиков как-то и не очень.

заказчик пытается раздуть скоуп не меняя бюджет.
конечно. всегда.
Подрядчик говорит — нет, это не то, о чем мы договаривались
конечно, всегда.
Ну и кто тут пытается соскочить с взятых на себя обязательств?
ну так и пошлите его нах, а себе запишите проект в проваленный. :)
деньги то успели получить? ну и замечательно :)

если не умеешь доводить до успеха проекты с реальными заказчиками а не какими-то какающими радугой — то вполне подход.

проектному менеджменту поэтому и посвящены горы литературы, годы разнообразных исследований, и все равно, проекты — проваливаются.

но конечно, все это чепуха.

главное — умение договариваться! бла-бла-бла, и проект сделан!

главное — умение договариваться! бла-бла-бла, и проект сделан!
Или закрыт нахрен. Так с рейтером когда-то порешили.

Почему всегда? Я думал мы конкретный пример разбираем.

потому что всегда.

не, может вам всегда другие заказчики попадались.

мне так за 20+ лет в программировании — только такие :) живые, переменчивые.

Я думал мы конкретный пример разбираем.
? я не приводил никакого конкретного примера.

а где вы его привели?

Еще лучше начинаешь понимать заказчика когда сам им становишься) Сразу узнаешь откуда вот те все причуды были «у них»

Не надо становиться заказчиков, чтобы это понять. Вопрос только в обсуждении и согласовании хотелок и возможностей.

ну так и пошлите его нах, а себе запишите проект в проваленный.
Почему в проваленный? Деньги- то я успел получить. И сделал ровно то, о чём договаривались.
если не умеешь доводить до успеха проекты с реальными заказчиками
Такие реальные заказчики могут идти нахуй, стройными рядами.
Деньги- то я успел получить.
да, немало фрилансеров так и живут

получают первые деньги, делают работу на 40%, а когда доходит дело до разгребания собственных говен — смываются.

заказчик потом на фриланс биржах слезно плачут — какие нехорошие программисты.

недавно с одним общался — его с такими критериями успеха как у вас уже дважды кинули.

пришлось просвещать :) в том числе и немножко в области проектного менеджмента.

повторюсь
проект считается проваленным — когда не достигнут результат.

а то что вы бабла срубили на недострое, ну да, жулики тоже капусту рубят.

получают первые деньги, делают работу на 40%, а когда доходит дело до разгребания собственных говен — смываются.
Давай разберёмся. Заказчик написал в техзадании, что ему нужен велосипед, заплатил за велосипед — ну и получите велосипед и распишитесь. Что в процессе работы заказчик понял, что ему надо не велосипед а трактор, или феррари — не мои проблемы. Я считаю, что проект закончен когда я выполнил работу о которой мы договаривались и получил за неё деньги.

Заказчик, который думает что можно получить феррари заплатив как за велосипед мне не нужен.

Заказчик написал в техзадании
заказчик обычно не умеет писать тех задания, точно так же как писать программный код.

если да, речь о заказчике который умеет, то это соооовсем другой разговор.

такие да, бывают.

но уже писал о грёзах программистов в этой теме.

Я считаю,
мало ли что вы там себе считаете.

Цели проекта должны соответствовать требованиям SMART (Specific — Специализированные, Mesurable — Измеримые, Actively Influencible — Актуальные, Realistic — Реалистичные, Time Limited — Ограниченные по времени).

когда проект считается проваленным — тогда он и считается. а критерии провала — не соответствие целям. если цель вашего персонального проекта — срубить бабла, и вы срубили, то да, ваш проект достиг цели.

но обычно цель проекта и для исполнителя — создать работающую систему, с такими то функционалом, и т.д.

и если заказчик посчитает что проект провален — то его мнение будет весомым. даже если он дундук — сам все сделал для того чтобы его проваливать.

Что в процессе работы заказчик ... — не мои проблемы
э-э-э не, после старта разработки — это уже ВАШИ проблемы.

надо было не браться вообще, тогда да, были бы не ваши ;)

мне не нужен
никто и не неволит.

зачем вы вообще взялись обсуждать рецепты решения типичных проблем на проектах, если вы не беретесь за такие проекты, с такими неправильными заказчиками?

это ж не ваши проблемы, а тех кто берется :)

Поясняю популярно: техническое задание это договор между заказчиком и исполнителем. Если то, что записано в договоре выполнено — он считается исполненным.

заказчик обычно не умеет писать тех задания, точно так же как писать программный код.
Ну вот пусть заплатит. Я проведу анализ его потребностей, напишу техзадание которое он подпишет.
когда проект считается проваленным — тогда он и считается
Экономика должна быть экономной©. Смотри выше, техзадание это договор. Договор выполнен — проект удачно закончен. А кто что думает мне до лампады.
э-э-э не, после старта разработки — это уже ВАШИ проблемы.
Моя проблема, это если я не выполнил договор. Если выполнил — не мои.
зачем вы вообще взялись обсуждать рецепты решения типичных проблем
Чтобы некоторые излишне мягкие люди научились говорить «нет»

Договор подписывается обычно ДО создания тех задания. В нем прописываются — требования, а не тех задание.

Тех задание — такая же часть работы как и написание кода. И рефакторинг кода, и изменение тех задания — обычная вещь в живом проекте. Даже требования и те вполне могут измениться.

Насчет излишне мягких людей, это да. Расскажите сейлсам и пиэмам как им надо работать. Как им нагибать заказчика, чтоб ему жизнь малиной не казалась.

требования, а не тех задание.
Нет, требования это и есть часть техзадания.
И рефакторинг кода, и изменение тех задания — обычная вещь в живом проекте. Даже требования и те вполне могут измениться.
Без проблем, если за это платят.
Расскажите сейлсам и пиэмам как им надо работать. Как им нагибать заказчика, чтоб ему жизнь малиной не казалась.
Если человек платит и заказывает ещё раз, значит ПМ и сейлз действуют правильно

Может, на фрилансе модель «успел забрать бабло и соскочить — пацан» проходит, в нормальном бизнесе — нет. Даже на фрилансе есть возможность оставить негативный отзыв, в большом мире с этим ещё проще. Раз соскочил, 2-й, а на 3-й не осталось тех, кто поручит Вашей конторе проект. Кроме того, при данном раскладе Вам, скорее всего, не заплатят. Потому что последний чекпоинт не пройден: проект не готов к дате X. Как минимум пробросят с последней оплатой. Сколько это: 100%, 50% или меньше — зависит от условий контракта и количества чекпоинтов. В нормальных контрактах есть пункт о неустойке за низкое качество продукта, несоблюдение сроков и пр. радости. И, поскольку денег Вам дадут только после акцепта фазы, неустойку Вы оплатите в полной мере: с Вас попросту вычтут её при расчёте.

Ни о каком «соскочил» речи не идет. Договаривались о чем то — вот это самое и получите. Если в процессе работы выяснилось, что надо другое это не мои проблемы и стать моими они могут лишь за дополнительные деньги

Из своего опыта скажу, что тут не бывает чёрно-белых решений. Можно, конечно, пойти на принцип, с почти 100%й вероятностью потерять заказчка и еще и схлопотать себе черный PR.

Более того, иногда это даже допустимо, если заказчик непрофильный, и его потеря ничем особым не грозит.

Но, довольно часто, выгоднее пойти на какие-то взаимные уступки, которые окупятся длительным сотрудничеством в будущем.

Уступки это подвинуть кнопочку. Если полностью переделать, это не уступка а кто то лох

Больше работы — больше денег, в чем проблема?
это если договорились об оплате «жопочасов».
Ну тогда это не проблема скоупа а проблема договоренностей?
договорились что будет сделано одно.

в процессе заказчик понял что вообще-то ему не совсем это нужно, и не так.

но, договоренность же! делаем то о чем договорились, хоть и нафик оно уже не нужно клиенту.

Чет я не понимаю, почему бы подрядчику бороться с раширением скоупа?
потому что у клиента бюджет — всегда ограничен.
и потому что клиенту всегда кажется что все проще.

и потому, если не бороться с расширением скоупа именно подрядчику, проект просто будет — провален, когда у клиента закончатся — деньги.

вы ж не предлагаете подрядчику доделать проект — бесплатно.

это если договорились об оплате «жопочасов».
но, договоренность же! делаем то о чем договорились, хоть и нафик оно уже не нужно клиенту.
если не бороться с расширением скоупа именно подрядчику, проект просто будет — провален, когда у клиента закончатся — деньги
Все это не имеет совершенно никакого отношения к скоупу, а только к умению договариваться.

тогда вообще-то не понятно — а что имеет отношение к скоупу?

оно ж все — про договариваться. не договорился тим лид с джуном — вот и не написал джун код.

или:
скоупа не существует. есть только договоренности и их выполнение.

правда и в этом случае — бюджет не бесконечный.
но да, это неважно. главное договориться что кто будет делать когда проект провалится.

раз есть договоренность про случай исчерпания бюджета, то успех проекта гарантирован!

Правильно, договариваться — первичное умение. Все остальное меркнет по сравнению с ним.

Провалится — это как? Подрядчик получил все деньги в полном объеме за проделанную работу?

Правильно, договариваться — первичное умение
договоренность не конвертируется ни во время, ни в деньги.

как в том анекдоте
продал один другому вагон варенья.
Один пошел искать вагон варенья, чтобы его продать, второй — искать деньги, чтобы его купить.

ну и какова «цена» умению договариваться?

Провалится — это как?
ресурсами проекта являются

деньги, время, люди, сырье-узлы (для материального производства)

успех проекта — это его завершение

провал — это его незавершение.

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

Подрядчик получил все деньги в полном объеме за проделанную работу?
получил. а проект — не завершил. значит проект — провален.

из соотношения завершенных и незавершенных проектов складывается — репутация подрядчика.

Проект провален у заказчика. У подрядчика все ок.

Проект провален
подрядчикОМ.

а что там подрядчик себе за оправдания придумал — заказчика не интересует.

косвенный критерий провала подрядчикОМ:

подрядчик не может включить проект в свое портфолио. «на вору и шапка горит»

Чет я, как ни стараюсь — чего это он провален, если все, о чем договаривались вначале выполнено вовремя и в полном объеме?

перечитайте

у клиента бюджет — всегда ограничен.и потому что клиенту всегда кажется что все проще.

и потому, если не бороться с расширением скоупа именно подрядчику, проект просто будет — провален, когда у клиента закончатся — деньги.

все, о чем договаривались вначале
а заказчик не увеличил, а сменил пункты скоупа.

вы об это не договаривались — вначале. заказчику уже не нужно, то о чем вы договаривались — вначале.

живому заказчику. заказчики в представлении программистов мне неинтересны. как и прочие деды морозы и розовые пони.

Поэтому, конечно, планировать проект в виде замороженного скоупа — глупость (и плакать о том, что он меняется, конечно, тоже). Кто бы на этом ни настаивал. Поэтому agile, T&M, вот это все. Или, может, это не умение договариваться?

Я, кстати, заказчик, если что. Расскажите мне скорей про представление программистов.

Расскажите мне скорей про представление программистов.
главное — техническое задание и техническую спецификацию должны писать ВЫ, заказчик.
Поэтому agile, T&M, вот это все.
это для тех кто не умеет договариваться.

вы как понял умеете, зачем вам эти слова для неумеющих?

Я, кстати, заказчик, если что.
понятно.

читаем еще раз:

и потому что клиенту всегда кажется что все проще.
главное — техническое задание и техническую спецификацию должны писать ВЫ, заказчик.
Вообще пофиг. Можем и написать, если заказчик эту работу оплачивает, а иначе идет лесом к разводящим.

Это я с удовольствием, только о чем речь?

З.Ы. Кратко, говори четко чего хошь, а мы программситы уже скажем можно это сделать или нельзя и в какие сроки (понятно, что все случайности мира не учтем). Но скажем честно, могем или нет.

Один пошел искать вагон варенья, чтобы его продать, второй — искать деньги, чтобы его купить.
ну и какова «цена» умению договариваться?
5% от сделки.

так чтобы получить эти 5% нужно чтобы первый нашел вагон, а второй деньги :)

то есть умение договариваться — это конечно необходимое условие. но соооовсем не достаточное :)

Я воздухом (сахаром) поторговал когда-то в таком режиме. Но это не моё, я больше что-то сделать руками (прогу написать).

Сорри, но я оставлю свое мнение...

scope creep
было придумано теми, кто не мог нормально внедрять проекты. За почти 7 лет опыта в ИТ, я понял, что почти все (90% +) проблем из-за того, что стаф который делает этот проект — совершенно не понимает что надо будет сделтаь на этапе продажи\дискавери.
И так же не понимает в момент внедрения проекта. Другими словами, на нашем рынке все делают все.
Очень мало спецов, которые бы делали однообразные проекты, и еще меньше людей, которые бы имели опыт внедрения проектов от НАЧАЛА до КОНЦА.
Зачасту, люди знают какие-то куски... как начать, как закрыть проект и т.д. Мало людей у которых есть 10+ проектов закрытых полностью с продолжительностью проекта 1 год +
Все что вы написали — это полезно и интересно. Но это не пофиксит фундаментальные проблемы. ИМХО
было придумано теми, кто не мог нормально внедрять проекты. За почти 7 лет опыта в ИТ, я понял, что почти все (90% +) проблем из-за того, что стаф который делает этот проект — совершенно не понимает что надо будет сделтаь на этапе продажи\дискавери.

Так это естественно в отрасли, где любая разработка это исследовательская работа в неведомой доселе области.

Очень мало спецов, которые бы делали однообразные проекты, и еще меньше людей, которые бы имели опыт внедрения проектов от НАЧАЛА до КОНЦА.

Однообразных проектов не будет из-за нулевой стоимости тиражирования данных.

Но это не пофиксит фундаментальные проблемы. ИМХО

Их ничто не пофиксит.

Подписаться на комментарии