Звинувачуючи сьогоднішні нещастя в технічній заборгованості вчора


38

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

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

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

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

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

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

Чи вважаєте ви, що існує кращий, можливо, більш м'який спосіб повідомляти керівництву про такі проблеми, не наступаючи на репутацію людини / команди перед вами?


17
Іронічно, що в питанні про те, щоб не грати у вину гру, ви витрачаєте 3 повні абзаци, що складають близько 50% вашого питання, що стосується попередньої команди. І позначив питання [поганий код] та [поганий програміст].
Aaronaught

8
@Aaronaught, Гаразд, я кусаю, я позначив це міткою, bad-codeоскільки код справді викликає помилки та проблеми. Я позначив це bad-programmerтим, що боюся, що я став одним із звинувачень у попередній команді, втомленому та виправданому виправданні, яке ми всі чули раніше. Наскільки перші три абзаци вважаються, мабуть, мені не потрібно було це описово, але я хотів скласти точну картину моєї негайної ситуації і дати історію того, що я зібрав до цих пір.
maple_shaft

2
... Отже, чи є там елемент ранта ? Так, я думаю, але мені боляче бути нянею в додатку, який працює як дитина з СДВГ зі смертним бажанням.
maple_shaft

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

Історія мого життя
Юліан Онофрей

Відповіді:


46

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

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

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


4
+1 за дійсно гарне непорочне пояснення того, як проект міг вибрати (правильно!) Потрапити в технічну заборгованість.
Joris Timmermans

1
@ Nemi: Важливою відмінністю між технічним боргом та фінансовим боргом є те, що його набагато легше кількісно оцінити. Набагато простіше дізнатися, скільки фінансової заборгованості вам залишилось погасити (навіть фактором накопичення відсотків та повторними фінансовими зобов'язаннями), тоді це потрібно зробити з технічною заборгованістю. Я зазначу це лише тому, що це одне, що посилює проблему maple_shaft.
Бен Хокінг

2
@Ben - ти абсолютно прав. Як і у всіх аналогій, і ця руйнується під мікроскопом. Однак порівняння все ще є надійним на високому рівні. Він по суті не обіцяє деталей і розмовляє з керівництвом на їхньому рівні - як бізнес-проблема, а не технічна проблема. По суті, будь-який тривалий проект накопичує певну кількість технічної заборгованості, і, як такий, це означає, що з часом йде додаткові витрати на розвиток. Оскільки це приховано (і навіть не дуже добре зрозуміло), це в інтересах кожного, щоб переконатися, що про нього говорять.
Немі

2
+1 до "це справедливо, навіть якщо ви правильно написали заявку".
Маурісіо Шеффер

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

23

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

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

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


3
+1: звинувачуйте старе керівництво, яке не вдалося поставити якісний товар, тоді (сподіваємось) нове керівництво отримає повідомлення (або позбудеться вас, обидва випадки - це виграш, наскільки ви переймаєтесь)
gbjbaanb

15
@gbjbaanb - нікого не звинувачуйте! Ідіть зі свого шляху НЕ звинувачуючи нікого. Просто встановіть поточну ситуацію та бажану ситуацію та зробіть логічний аргумент того, як і навіщо вам туди потрапити.
Joris Timmermans

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

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

4
@maple_shaft - тож зробіть аргумент, який я висловив у своїй відповіді керівництву, і якщо вони все ще наполягають на "звинуваченні", опублікуйте своє резюме на стільки сайтів, скільки ви зможете знайти, тому що для вас все піде дуже погано, коли вони вирішіть почати звинувачувати вас у відсутності когось іншого, на який би вказували пальцем.
Joris Timmermans

7

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.