Як "власні програмні компанії" мають справу з технічним боргом?

Що таке "власні програми програмного забезпечення"?

Під "компаніями на замовлення програмного забезпечення" я маю на увазі компанії, які заробляють свої гроші в основному за допомогою побудови індивідуальних, разових, шматочків програмного забезпечення. Прикладом можуть бути агенції або компанії середнього виробництва, або підрядники / консультанти, такі як Redify .

Що протилежне "компаніям на замовлення програмного забезпечення"?

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

Надійний спосіб пожежі наростити технічну заборгованість:

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

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

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

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

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

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

Якщо ви припините функцію, обов'язково повідомте про це своїм клієнтам (або принаймні тим, кого це стосується) заздалегідь, де-небудь між півроку та три роки розумним. Насправді, якщо ви погоджуєтесь створювати функції, орієнтовані на користувачів, ви можете спробувати змусити своїх торгових працівників створити термін придатності з самого початку. Назвіть це "термін служби підтримки" і дайте зрозуміти, що чим довше вони хочуть, тим більше грошей це буде коштувати. Постарайтеся надати обхідні шляхи для своїх клієнтів, щоб вони не лишилися на дисплеї, коли з'явиться функція, наприклад, сценарій, який перетворює експортовані XML-файли у формат доступу MS або трохи поради щодо вибору кращої RDBMS.

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

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

Коли я стикаюся зі спеціальними запитами на розробку, я фільтрую їх через класний фільтр, який розбиває запити на 3 палі:

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

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

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

(цей досвід був у компанії ISV)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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