Багато компаній передають розробку свого програмного забезпечення на аутсорс, часто офшорним виконавцям. Інші замінюють розробку індивідуальних Greenfield-рішень на комерційні пакетні рішення, які вони або виконавець повинні налаштувати, розширити та інтегрувати у своє середовище додатків. Провалені аутсорсингові чи комплексні проєкти іноді призводять до програшних для обох сторін судових розглядів. Позови часто свідчать про те, що замовник не реагував на ранні попереджувальні сигнали, а просто сподівався на краще.
Ось кілька практик, які можуть уберегти вас і вашого замовника від зали суду. Я використаю вигадану компанію-набувача Unfortunato Ltd., щоб проілюструвати досвід, який я спостерігав на реальних контрактних та комплексних проєктах з розробки програмного забезпечення.
Визначте очікування
Отож, як уникнути розчарування та судових розглядів в аутсорсингових проєктах? Секрет — у чітких очікуваннях. Адже саме нереалізовані очікування часто стають головною причиною провалу проєкту.
Замовник очікує певного функціоналу та якості рішення, дотримування бюджету та графіку проєкту. Виконавець сподівається отримати всю необхідну інформацію та матеріали від замовника. Обидві сторони також мають певні уявлення щодо своєї співпраці.
Проблема в тому, що невисловлені очікування часто призводять до хибних припущень, невиконаних залежностей, непередбачених ризиків і розчарованих клієнтів.
Тому, щоб закласти міцний фундамент для успішного аутсорсингу, ретельно та точно задокументуйте всі вимоги. Ідеальним варіантом є особисте спілкування в режимі реального часу, але це буває важко реалізувати, коли між замовником та виконавцем велика різниця в часових поясах.
Вимоги неминуче змінюватимуться в міру поглиблення вашого взаєморозуміння, тому письмова специфікація не може замінити регулярного спілкування. Проте, багато проєктів зупиняються через туманні та неповні вимоги, а також витрачають цінний час на усунення неясностей та заповнення прогалин. Щоб зробити спілкування максимально ефективним, залучайте як команду замовника, так і команду виконавця до визначення та перегляду вимог.
Намагайтеся уникати непрямих чи передбачуваних вимог, які покладаються на телепатію та ясновидіння — не надто надійний фундамент для інженерії вимог. Пам’ятайте, що в аутсорсингу, якщо певна функція не зазначена в погоджених вимогах, не варто очікувати її наявності в кінцевому продукті.
Неоднозначність – основне джерело проблем із вимогами. Неоднозначність означає, що читач може по-різному інтерпретувати текст. Не використовуйте розмиті та суб’єктивні слова у вимогах. В одному реальному проєкті наша вигадана компанія Unfortunato Ltd. створила специфікацію програмних вимог (SRS) на 307 сторінок, яка включала такі нечіткі терміни:
-
переважно
-
за потреби
-
може
-
мати сенс
-
доречний
-
плавний
-
як мінімум
-
повільно
-
може бути корисним
-
включаючи, але не обмежуючись
-
та/або
-
різні
-
кілька
-
чистий та стабільний інтерфейс
Таке розмите формулювання призводить до невиправданих очікувань. Як протестувати “кілька”, оцінити “включаючи, але не обмежуючись” або довести, що у вас “чистий та стабільний інтерфейс”?
SRS Unfortunato також був усіяний словом “підтримка”, як-от “система повинна підтримувати Microsoft Word”. Як виконавець дізнається, що саме мається на увазі під “підтримкою” в кожному конкретному випадку? Я не люблю бачити слово “підтримка” в документі з вимогами, якщо ви не будуєте якусь фізичну структуру.
Крім опису бажаної функціональності системи, обов’язково вкажіть атрибути якості, обмеження, зовнішні інтерфейси та цілі продуктивності, які разом називаються нефункціональними вимогами. Атрибути якості включають такі характеристики, як надійність, зручність використання, осблуговуваність, цілісність, безпека, тестування, можливість встановлення та адаптивність. Якщо ви чітко не визначите свої цілі в цих категоріях, виконавець може прийняти неправильні компромісні рішення щодо дизайну.
Недоліки у продуктивності, безпеці або надійності іноді вимагають серйозного редизайну архітектури, хоча, звичайно, ніхто не планує час або гроші на ці додаткові зусилля. Невиконання нефункціональних вимог може зробити розроблену систему непридатною для її цільового використання.
Деякі суперечки виникають через питання обсягу, тому важливо визначити обсяг проєкту, межі між тим, що входить у нього, а що ні. Один конфлікт виник, коли в процесі активної розробки проєкту компанія Unfortunato наполягала на необхідності шести додаткових змін даних. Виконавець проєкту заявив, що контракт не покриває ці зміни, тому вони вимагатимуть додаткової оплати. Юристи продовжили дебати, отримуючи сотні доларів на годину.
Практично неможливо знати всі вимоги до початку розробки, тому очікуйте зростання вимог на кожному проєкті. Ви можете очікувати більшого розширення обсягу, якщо вимоги розробляються поспіхом, недосвідченими аналітиками, з недостатнім залученням замовника або з погано сформульованим початковим баченням продукту. Швидко змінювані або нові бізнес-потреби призводять до ще більшої зміни та зростання вимог; такі проєкти можуть бути не найкращими кандидатами для аутсорсингу.
Оскільки зміни неминучі, важливо встановити взаємоприйнятний процес контролю змін. Зміни завжди мають свою ціну, тому ваш контракт повинен чітко вказувати, хто оплачуватиме різні типи змін, до прикладу таких як: додатковий функціонал за запитом замовника, виправлення помилок у початкових вимогах, перероблення через неточності у вимогах.
Відповідальність за оплату залежатиме від типу контракту – фіксована ціна, оплата за матеріали та час або роялті.
Розклад невдалого проєкту Unfortunato з комплексним рішенням включав однотижневе завдання під назвою “Провести семінари з визначення вимог для розширень”. За цим завданням одразу слідувала низка завдань з реалізації окремих розширень до основного пакета. Виконавець забув закласти час на документування, перегляд та доопрацювання вимог, отриманих під час семінарів. Ітеративний та комунікативно-інтенсивний характер розробки вимог вимагає обов’язкового планування часу для численних повторень та переглядів вимог.
Команди замовника та виконавця у цьому проєкті перебували на різних континентах. Вони відчували затримки з відповідями на численні питання, що виникали під час обміну вимогами. Несвоєчасне вирішення проблем із вимогами негайно вибило проєкт з графіку та зрештою призвело до його провалу. Альтернативною стратегією є послідовний та покроковий підхід до процесу розробки, який використовує проміжні релізи для уточнення вимог, збирання відгуків клієнтів та внесення необхідних коректив.
Створіть канали комунікації
Ефективні відносини між замовником та виконавцем — це спільна співпраця, де обидві сторони добросовісно працюють над досягненням спільної цілі. Як і в будь-яких відносинах, для досягнення успіху обом сторонам потрібні чесність та відкрита комунікація. Замовники повинні бути чесними щодо своїх очікувань та потреб. Виконавці повинні бути чесними щодо статусу проєкту. Кожна сторона має право — і відповідальність — визначити, яку інформацію, матеріали, умови та рішення вона потребує від іншої сторони, щоб їхня спільна робота була успішною.
Для того, щоб відкрити ефективні канали комунікації, визначте чіткі контактні особи з обох сторін. Замовник повинен призначити одну людину для управління відносинами з виконавцем. Аналогічно, виконавець повинен визначити одну особу для координації стосунків. Виконавець повинен був зазначити це у своїй відповіді на ваш запит на пропозицію (RFP). Таким чином, основним каналом комунікації є ці два менеджери субконтрактів.
За потреби визначте додаткові контактні особи для конкретних цілей. Звичайно, вам знадобляться інші контактні особи для переговорів за контрактом, технічних питань тощо. Якщо географія та бюджет дозволяють, призначте людину від замовника в офісі виконавця, і навпаки. Це значно покращує комунікацію, особливо якщо обидві особи мають повноваження приймати відповідні рішення.
Затримка проєкту Unfortunato сталася через те, що співробітники виконавця не могли завжди знайти потрібних людей в Unfortunato для отримання необхідної інформації або вирішення проблеми. Unfortunato визначила для різних функцій кілька контактних осіб, які іноді перекидали питання виконавця один одному, не даючи відповідей. Ця плутанина щодо того, кому дзвонити, і подальші затримки не дозволили виконавцю дотримуватися графіку.
Окреме питання полягає у визначенні осіб, котрі прийматимуть рішення на проєкті, та їхнього процесу прийняття рішень. У кожному проєкті виникає безліч питань та проблем. Наприклад, розробник з боку виконавця може запропонувати корисну функцію, якої замовник не вимагав. Виконавець може запропонувати компроміси щодо визначених цілей продуктивності або інших атрибутів якості. Нові фактори ризику можуть виникнути на активній стадії розробки проєкту. Відповідні особи повинні швидко вирішувати такі проблеми, тому визначте на початку, хто прийматиме ці рішення. Особи, які приймають рішення, також повинні визначити відповідне правило прийняття рішення, чи то одноголосність, голосування більшості, консенсус, делегування одній особі чи щось інше.
Забезпечення міцної основи для спільної роботи дозволить вам вирішувати більшість проблем дружньо та професійно. Тим не менш, передбачте, як ви будете справлятися із суперечками та проблемами, які не так легко вирішити. Ваш контракт повинен встановлювати процес управління проблемами та їх ескалації. Коли ви стикаєтеся з конфліктом, наприклад, суперечкою щодо обсягу проєкту, спочатку задокументуйте проблему та дозвольте менеджерам субконтрактів спробувати вирішити її самостійно. Лише якщо це не вдасться, слід винести проблему на вищий рівень управління.
Ескалація невирішених проблем підвищує рівень конфлікту, не кажучи вже про тиск. Я читав серію електронних листів та факсів між Unfortunato та їхнім виконавцем, які поступово переросли з “Ви ще не надали мені інформації X, тому я не можу продовжувати” до “О так? Ну, мій адвокат може побити вашого адвоката!” Спробуйте запобігти конфліктам та їх вирішенню, перш ніж просити “старшого брата” втрутитися, але визначте, як і коли “старший брат” візьме на себе обов’язки, коли це необхідно.
Як у бізнесі, так і в особистому житті я намагаюся вирішити проблему до того, як вона стане кризою. Маленькі невирішені проблеми можуть перерости у серйозні інфекції та напружити стосунки. Набагато легше виправити проблему, коли її вперше виявили, ніж дозволити їй затягнутися та перерости. Як зазначає консультант і автор Джеральд Вайнберг у своїй книзі “The Secrets of Consulting”, “це може виглядати як криза, але це лише кінець ілюзії”, ілюзії, що все йде просто чудово.
Будьте пильними
Для досягнення успіху вам необхідно постійно стежити за прогресом виконавця. Це дозволить вам оперативно вносити корективи у разі, якщо реальність не відповідає очікуванням чи домовленостям. Щоб забезпечити ефективне відстеження прогресу, домовитесь про ключові етапи проєкту. Оскільки будь-які оцінки містять певну невизначеність, виконавець може не завжди точно дотримуватися всіх етапів. Включіть кілька ранніх етапів, щоб отримати уявлення про роботу виконавця. Розклад проєкту Unfortunato не мав жодних важливих етапів протягом кількох місяців після запуску, що призвело до інформаційної порожнечі. Проблеми з початковими етапами роботи не виявилися до пізнього часу, коли їх вирішення стало значно дорожчим і складнішим.
Кожен проєкт має послідовність задач, яка визначає найпізніший можливий термін завершення. Графік виконавця повинен визначати критичний шлях проєкту, щоб можна було побачити, які завдання завдадуть найбільшої шкоди, якщо їх термін виконання буде пропущено. Критичний шлях для багатомільйонного аутсорсингового проєкту Unfortunato не був чітко визначений. Багато залежностей за часом між завданнями не було визначено. Це унеможливило побачити реальний вплив затримки з виконанням важливого раннього завдання.
Крім того, переглянутий план, який виконавець підготував після пропуску деяких ранніх етапів, нереалістично зобразив нову, пізнішу дату завершення проєкту. Якимось чином проєкт мав би надолужити втрачений час у якийсь магічний спосіб. Звичайно, цього не сталося.
Управління ризиками є важливою практикою управління проєктами, тому активно керуйте ризиками. Як замовник, так і виконавець повинні брати участь в ідентифікації та аналізі ризиків. Позиції у вашому списку десяти найважливіших ризиків повинні зменшуватися, оскільки ви активно пом’якшуєте відомі ризики протягом проєкту. Значними ризиками для контрактних та аутсорсингових програмного забезпечення є:
-
Високі витрати на обслуговування
-
Негаразди між персоналом підрядника та клієнта
-
Постійне розширення вимог користувачів
-
Непередбачені критерії прийняття
-
Право власності на програмне забезпечення та інші матеріали
Ваш аутсорсинговий проєкт може мати додаткові або інші ризики, тому проведіть власний аналіз. У проєкті Unfortunato звіти про стан справ виконавця місяць за місяцем показували лише ті самі два пункти ризиків з низькою ймовірністю виникнення, в той час як проєкт занурювався в судові процеси. Хтось не звернув уваги на те, як виникали нові ризики та завдавали шкоди.
Щоб тримати тримати руку на пульсі та бути пильними, необхідно точно та часто відстежувати стан речей. У контракті слід вказати періодичність звітів про стан справ виконавця та визначити будь-які показники безперервного відстеження. Зміст звітів може включати:
-
Індикатори стану (зелений, жовтий, червоний) та резюме ключових показників ефективності проєкту, таких як стан вимог, зміни, графік, бюджет, ресурси та персонал
-
Таблицю основних етапів із зазначенням вихідних запланованих дат, поточних запланованих дат та фактичних дат завершення
-
Резюме прогресу та відхилень від плану
-
Поточний список ризиків, із виділенням основних змін порівняно з попереднім звітом
-
Поточні проблеми та пункти дій із зазначенням їхнього стану, хто відповідає за кожен із них та кінцевий термін вирішення
Уважно вивчайте звіти про стан справ, щоб виявити тривожні сигнали та безпідставний оптимізм. Проєкт Unfortunato включав важливий етап із розробки архітектурної специфікації, який спочатку планувався на 26 березня. У звіті про стан справ від 1 квітня від постачальника Unfortunato все ще вказувалося 26 березня як запланована дата доставки завершеної архітектурної специфікації, хоча ця дата вже минула! Такі логічні невідповідності не вселяють у замовника великої впевненості у здатності виконавця виконувати свої зобов’язання.
Однією з причин затримки архітектурної специфікації було те, що Unfortunato не надала виконавцю критичну інформацію про вимоги вчасно, про що виконавець повинен був зазначити у звіті стосовно стану справ. Замовники повинні виконувати власні зобов’язання.
Чи варто очікувати, що виконавець реалістично перепланує роботу, коли етапи пропущено? Виконавець Unfortunato представив переглянутий графік проєкту в середині проєкту, але він був абсолютно неправдоподібним. Їм слід було перенести дату релізу, що було б реалістично, але призвело б до договірного фінансового штрафу. Натомість виконавець втискав дедалі більше роботи в короткий проміжок часу наприкінці проєкту, призначаючи паралельні завдання багатьом ресурсам, які чарівним чином з’явилися вперше. Unfortunato відхилив цей переглянутий, але неможливий графік, а потім скасував контракт, що врешті призвело до судового позову.
Звичайно, ваша мета полягає не просто в тому, щоб виконати план. А в тому, щоб успішно доставити правильне рішення. План являє собою найкраще розуміння виконавцем того, як досягти цієї мети. Плани будуть змінюватися в міру того, як відбуватиметься реальність, але вам потрібна хороша видимість прогресу на цьому шляху.
Пробуйте, перш ніж подавати
Однією з причин документування вимог є те, що ви можете оцінити, чи є результати роботи виконавця прийнятними. Тому визначайте критерії приймання продукту під час розробки вимог, щоб оцінити проміжні або внутрішні релізи на прийнятність. Критерії приймання визначають умови, продуктивність і функції, яким повинен відповідати продукт, перш ніж замовник вважатиме його прийнятним. Якщо ви замовник, включіть першу версію критеріїв приймання у ваш запит на пропозицію (RFP), щоб потенційні виконавці знали, як ви плануєте оцінювати їхню роботу. Нечіткі, суб’єктивні або не задокументовані критерії приймання залишають можливість для суперечок щодо того, чи відповідає продукт очікуванням чи ні.
Сигнали, що попереджають про потенційні проблеми з аутсорсним проєктом
Використовуйте цей контрольний список, щоб виявити можливі проблеми в проєкті з аутсорсингом розробки або впровадження комплексного рішення. Якщо ви відзначите більше кількох пунктів, вважайте, що вам світить високий ризик виникнення проблем з аутсорсинговим проєктом, невдача проєкту або навіть судовий розгляд.
Ознаки, на які слід звернути увагу:
-
Звіти про стан справ, що регулярно плануються, не доставляються вчасно, не містять очікуваної інформації або не відповідають видимим ознакам прогресу, таким як завершені результати.
-
Незавершені пункти дій, невирішені проблеми, невиконані залежності, конфлікти, які не вирішуються ефективно, або інші невиконані зобов’язання.
-
Некваліфікований персонал виконавця або замовника, що призначається, або заміна ключового персоналу виконавця або замовника іншими особами.
-
Замовник не бере активної участі в управлінні та моніторингу відносин з виконавцем.
-
Виконання вимог без запиту або виключення вимог зі запитом без переговорів та узгодження.
-
Планові перегляди, які не відбулися, або перегляди, які мали бути заплановані, але не були.
-
Рішення, які не приймаються своєчасно потрібними людьми, або рішення, які не повідомляються оперативно зацікавленим особам.
-
Отримані неповні результати або відсутні результати, що вимагаються за договором.
-
Отримання документів, але без доставки працюючого програмного забезпечення.
-
Процеси, які працюють погано або неналежним чином ігноруються.
-
Діаграми тенденцій відстеження проєкту, які не показують ознак майбутнього завершення.
-
Фактичні результати витрат, термінів або зусиль, які суттєво відрізняються від оцінок без пояснення.
-
Пропущені ранні етапи, що не віщує нічого доброго для завершення майбутніх етапів.
Як уникнути суду
Консультанти Том ДеМарко та Тім Лістер зазначають, що коли справа доходить до судових розглядів щодо програмних контрактів, обидві сторони завжди програють. Не можна просто відправити специфікацію вимог виконавцю та чекати, що він доставить вам ідеальний продукт. Надійна практика розробки вимог та управління проєктами, поєднана з постійним спілкуванням та співпрацею, допоможе запобігти тому, щоб юристи висмоктали ваш банківський рахунок, борючись із адвокатом вашого виконавця через порушений контракт.
Оригінальна стаття – 15 Tips for Outsourced Software Development Success, переклад – Марина Котельницька, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Зображення зі статті автора.