Jak „firmy produkujące oprogramowanie niestandardowe” radzą sobie z długiem technicznym?

Co to są „firmy produkujące oprogramowanie niestandardowe”?

Przez „firmy produkujące oprogramowanie niestandardowe” rozumiem firmy, które zarabiają przede wszystkim na tworzeniu niestandardowych, jednorazowych części oprogramowania. Przykładem są agencje lub firmy zajmujące się oprogramowaniem średnim lub kontrahenci / konsultanci, tacy jak Redify .

Jakie jest przeciwieństwo „firm produkujących oprogramowanie niestandardowe”?

Przeciwieństwem powyższego modelu biznesowego są firmy, które koncentrują się na produktach długoterminowych, niezależnie od tego, czy są to aplikacje stacjonarne / mobilne, czy oprogramowanie SaaS.

Pewny sposób na zwiększenie długu technicznego:

Pracuję dla firmy, która stara się skupić na pakiecie produktów SaaS. Jednak z powodu pewnych ograniczeń czasami kończymy gięcie zgodnie z wolą niektórych klientów i kończymy tworzenie fragmentów niestandardowego oprogramowania, które może być używane tylko dla tego klienta.

To niezawodny sposób na zaciągnięcie długu technicznego. Teraz mamy trochę oprogramowania do utrzymania, które nie dodaje nic do naszego podstawowego produktu.

Jeśli praca na zamówienie jest niezawodnym sposobem na budowanie długu technicznego, jak agencje sobie z tym radzą?

Więc pomyślałem. Firmy, które nie mają podstawowego produktu jako centrum swojego modelu biznesowego, zawsze wykonują niestandardowe oprogramowanie. Jak radzą sobie z pojęciem długu technicznego? Jak nie doprowadza ich to do bankructwa technicznego ?

Jeśli potrafisz zgiąć specyficzne dla użytkownika wymagania w coś, co będzie przydatne dla wszystkich, to świetnie. Jeśli klient jest gotów zapłacić bieżące koszty wsparcia dla tej funkcji, również świetnie. Ale jeśli jesteś małym zespołem i masz trudności z obsługą wszystkich swoich funkcji, nie ma nic innego, jak podjąć trudne decyzje dotyczące funkcji, których potrzebujesz najmniej, a następnie poświęcić trochę czasu na wykorzenienie ich z bazy kodu.

SaaS zapewnia dobrą pozycję do gromadzenia statystyk użytkowania. Powinieneś przyjrzeć się oprzyrządowaniu swoich funkcji, jeśli jeszcze tego nie zrobiłeś, abyś mógł śledzić, kto z czego korzysta. Z naszego doświadczenia wynika, że ​​najbardziej idiomatyczni klienci są zwykle również najbardziej dysfunkcyjni; ten facet, który tupał nogami i wstrzymywał oddech, dopóki nie dałeś mu przycisku eksportu do MS Access, prawdopodobnie nie używał go od ponad roku. Niektóre funkcje są utrzymywane przy życiu, nawet jeśli korzysta z nich tylko jeden klient, ponieważ ten klient jest głośny i grozi przeniesieniem swojej firmy w inne miejsce za każdym razem, gdy coś nie jest dla niego satysfakcjonujące. Rezygnacja z tej funkcji może teraz kosztować klienta, ale czas poświęcony na obsługę tej funkcji może kosztować dziesiątki klientów na przestrzeni lat. Jest to miara jakości Twojego zespołu zarządzającego,

Kiedy przestaniesz korzystać z funkcji, pamiętaj o tym, aby poinformować o tym klientów (lub przynajmniej tych, których dotyczy problem) z dużym wyprzedzeniem, gdziekolwiek od sześciu miesięcy do trzech lat jest uzasadnione. W rzeczywistości, jeśli zgadzasz się na tworzenie funkcji specyficznych dla użytkownika, możesz spróbować przekonać sprzedawców do ustalenia daty ważności od samego początku. Nazwij to „dożywotnim wsparciem” i wyraźnie zaznacz, że im dłużej tego chcą, tym więcej pieniędzy będzie kosztować. Postaraj się zapewnić obejście dla swoich klientów, aby nie przeszkadzały, gdy funkcja się uruchomi, na przykład skrypt, który konwertuje wyeksportowane pliki XML do formatu MS-access, lub porady dotyczące wyboru lepszego RDBMS.

Coś, co zadziałało dla nas jako środka zapobiegawczego, to comiesięczne otrzymywanie raportu od naszego zespołu sprzedaży do naszego zespołu programistów i kierownictwa. Ten raport obejmuje informacje zwrotne od klientów - jakie funkcje są najbardziej popularne, jakie funkcje są najbardziej pożądane, jakie proponowane funkcje generują najwięcej szumu. Jest to interesujące, jeśli jesteś programistą, ale prawdziwą korzyścią jest zespół sprzedaży, który teraz myśli nieco więcej o każdej funkcji w kontekście szerszego obrazu, zamiast wysyłać niekończący się strumień żądań funkcji i ustalać priorytety na podstawie na którym klient był najgłośniejszy. Efektem jest zwiększenie twardości naszych pracowników sprzedaży, jeśli chodzi o żądania nowych funkcji w trakcie negocjacji, ponieważ są oni bardziej świadomi, gdzie każda funkcja może pasować do ogólnej oferty wartości naszego produktu.

Posiadanie modułowego kodu z dużą ilością zautomatyzowanych testów pomoże ci, gdy włamujesz funkcje do swojego produktu i zhakujesz je ponownie, ale ostatecznie nie jest to pytanie programistyczne, ale zarządzanie. Pisanie kodu w celu sprzedaży jest głupcem.

Kiedy mam do czynienia z niestandardowymi żądaniami programowania, filtruję je przez fajny filtr, który dzieli żądania na 3 stosy:

1. niesamowite rzeczy, które przydadzą się wszystkim i są stosunkowo łatwe do wdrożenia
2. niesamowite rzeczy, które przydadzą się wszystkim i są trudne do wdrożenia
3. głupia rzecz, która jest potrzebna tylko dla tego jednego klienta, który tak naprawdę ich nie potrzebuje

• Kategoria 1 zostanie wdrożona w bieżącym cyklu deweloperskim.
• Kategoria 2 zostanie wdrożona w następnym cyklu deweloperskim.
• Kategoria 3 otrzymuje wycenę 1 osobo miesięcznego czasu twórczego, po którym większość klientów zdaje sobie sprawę, że ich prośba nie jest tego warta.

Szczerze mówiąc, to nigdy nie zawiodło i nie sądzę, że ostatecznie wprowadziliśmy którąś z funkcji kategorii 3. I oczywiście żaden z klientów nie chodził (sprzedaż nie pozwoliłaby mi tego zrobić inaczej :)

(to doświadczenie było w firmie ISV)

z powodu pewnych ograniczeń czasami kończymy gięcie zgodnie z wolą niektórych klientów i kończymy tworzenie fragmentów niestandardowego oprogramowania, które może być używane tylko dla tego klienta.

Problem nie polega na tym, że tworzysz kod, który jest używany tylko dla jednego klienta. Problem polega na tym, że dołączasz kod używany tylko dla jednego klienta do produktu, który sprzedajesz wielu innym klientom, którzy nie potrzebują tej funkcji.

Firmy, które nie mają podstawowego produktu jako centrum swojego modelu biznesowego, zawsze wykonują niestandardowe oprogramowanie. Jak sobie radzą z pojęciem długu technicznego? Jak nie doprowadza ich to do bankructwa technicznego?

Dostarczają produkt. A potem idą dalej. Gdy opracowujesz produkt objęty umową, wszystko, co robisz w tym projekcie, jest przeznaczone dla tego jednego klienta. Wszelkie długi techniczne, które mogły powstać podczas programowania, stają się problemem klienta po zakończeniu umowy, a programista przechodzi do innego projektu dla innego klienta.

To oczywiście nie znaczy, że dobrze jest wykonywać gównianą robotę. Twoim najważniejszym celem jest sprawienie, aby Twój klient chciał nadal z Tobą współpracować, a wykonywanie wysokiej jakości pracy jest drogą do tego. Nie oznacza to również, że dług techniczny nie stanowi problemu dla deweloperów kontraktów. Nawet jeśli konsekwentnie piszesz czysty kod, istnieje szansa, że ​​w pewnym momencie zostaniesz zatrudniony do pracy nad projektem, który już narobił stosu długów. To może być dobre (klient chce zapłacić za posprzątanie bałaganu) lub nie (klient nie ma pojęcia, jak zły jest kod i nie rozumie, dlaczego „tylko” dodanie kilku dodatkowych funkcji zajmie tak długo ).

Nie zgadzam się z założeniem, że praca na zlecenie gwarantuje generowanie długu technicznego. Unikanie długu technicznego nie oznacza unikania pewnych rodzajów funkcjonalności - oznacza to unikanie niepotrzebnej sztywności, problemów związanych z zależnościami oraz rzeczy, które utrudniają (tj. Są drogie) zmiany kodu. Niestandardowa funkcjonalność tego nie implikuje - po prostu implikuje wąską podstawę dla funkcjonalności. Kluczem jest więc uwzględnienie w implementacji jak największej liczby logiki wielokrotnego użytku, pozostawiając niestandardowe, jednorazowe rzeczy jako własny moduł, który można wdrożyć dla żądającego klienta.

Załóżmy na przykład, że masz produkt, który był wewnętrzną aplikacją internetową, którą klienci zainstalowaliby w intranecie. Pewnego dnia pojawia się klient i proponuje kierowanie wywrotką pełną pieniędzy do Twojej firmy, jeśli stworzysz dla niego wersję z aplikacją komputerową „bogatego klienta” zamiast interfejsu przeglądarki. Cóż, jeśli Twój system jest dobrze skonstruowany, a twoje zależności są dobrze zarządzane, jest to tylko kwestia ponownego użycia domeny, dostępu do danych i składników usługi podczas tworzenia nowego składnika prezentacji. Dług techniczny nie jest brany pod uwagę, nawet jeśli masz tylko jednego klienta, który chce wrócić do 1999 r. I ma do tego aplikację komputerową.

Jest to dość złożone pytanie, na które należy odpowiedzieć, ponieważ podobnie jak wiele rzeczy, tak naprawdę zależy to od okoliczności projektu, poziom kontroli, jaki posiada firma, czy oprogramowanie niestandardowe było zarządzane przez firmę przez cały cykl życia, ilość „ingerencji” innych osób w dostęp do bazy kodu, postawy wszystkich zaangażowanych osób, złożoności projektu i zastosowanych metodologii… Naprawdę mógłbym kontynuować.

Wszystkie systemy mają pewien poziom długu technicznego. W niektórych przypadkach może to nie być szczególnie zauważalne ze względu na staranne wysiłki deweloperów, którzy starają się zawsze utrzymywać czystą bazę kodu, jednak żaden system nie jest doskonały, a poważna przeprojektowanie może sprawić, że pozornie niewinny, ale długotrwały problem stanie się oczywisty. Jak więc radzą sobie z tym firmy zakontraktowane?

W wielu przypadkach nie. Często oprogramowanie zostanie napisane przez jedną firmę, a następnie zmodyfikowane przez inną, i nie jest niczym niezwykłym, że baza kodu jest naprawdę pomieszana, ponieważ każda firma na podstawie umowy pracuje w napiętym terminie i nie uzasadnia czasu na utrzymanie kodu w czystości ( a czasem ledwo testowane), jeśli oznacza to, że mogą ryzykować przekroczenie terminu.

W innych przypadkach można znaleźć firmy, które nie tylko dobrze zarządzają zakontraktowanym projektem, ale także w jakiś sposób znajdują czas na pozostawienie istniejącej bazy kodu w lepszym stanie niż ją znaleźli. Robią to często, starannie planując, identyfikując źródła długu technicznego - zwykle te, które będą miały największy wpływ na nową pracę - i opracowują strategie, aby zapewnić przypadki testowe i modyfikacje, które przyczyniają się do zarządzania długiem technicznym i uwzględniają to wszystko w harmonogramie projektu .

Czy bycie niestandardowym oprogramowaniem gwarantuje dług techniczny, a nie pisanie produktu centralnego? Krótka odpowiedź brzmi „nie”, jednak prawdopodobne jest, że dług techniczny powstanie, jeśli nie zostanie aktywnie rozwiązany. Jest to to samo, co w przypadku każdego innego projektu oprogramowania. Jeśli kontrolujesz projekt całkowicie przez cały jego cykl życia, masz lepszą okazję, aby poradzić sobie z długiem technicznym. Jeśli nie, musisz poradzić sobie z długiem technicznym, który mógł powstać na podstawie kodu pozostawionego przez poprzednią firmę.

Z drugiej strony, jeśli twoje pytanie dotyczy pytania, czy pisanie oprogramowania niezależnie od modelu biznesowego jest gwarancją długu technicznego. Odpowiedź byłaby absolutnie. Prawdziwe pytanie brzmi, jak każda firma radzi sobie z długiem technicznym. Pozwolić mu na naliczenie i zajęcie się nim w wyznaczonym czasie, czy też zarządzanie bazą czystego kodu w sposób ciągły, aby jak najszybciej spłacić dług techniczny? Ta odpowiedź sprowadza się do indywidualnych priorytetów spółki i tego, czy zaciągnięty dług techniczny ma znaczenie finansowe.

Niestandardowe oprogramowanie nie jest gwarancją długu technicznego, ale obsługuje dwóch mistrzów.

Firma produkująca oprogramowanie niestandardowe zbuduje oprogramowanie dokładnie dopasowane do danego zadania, dostarczy je i utrzyma w razie potrzeby. Naprawdę niestandardowe oprogramowanie często nie wymaga dodawania nowych funkcji bardzo często.

Problem opisany w tym pytaniu polega na tym, że firmy produkcyjne wbudowują funkcje niestandardowe w produkt ogólny. Gdyby produkt był całkowicie niestandardowy, poruszałby się tylko wtedy, gdy zmieniły się wymagania jednego klienta. Gdyby produkt był całkowicie ogólny, poruszałby się tylko po dodaniu nowych funkcji, aby uczynić go bardziej atrakcyjnym. Ale kiedy masz niestandardową funkcję w ogólnie ogólnym produkcie, masz dwie części kodu, w ścisłym kontakcie, które poruszają się z różnymi prędkościami. Podobnie jak płyty tektoniczne, które powodują trzęsienia ziemi, interfejs między tymi fragmentami kodu jest „gorącym punktem”, dojrzałym do problemów.