Як вийти з кола підтримки та почати погашати технічну заборгованість!

Я маю друга". Так, хороший старт Я знаю, але, чесно кажучи, це не я!

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

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

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

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

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

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

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

Змусити когось іншого приймати дзвінки та змінити лінію

Ми одразу дістанемося до цього.

до

Дуже гарна пропозиція. Я створять запит на функцію, щоб якнайшвидше розпочати роботу над ним. Якщо ви хочете слідкувати за ходом вашого запиту, ви можете відстежити його тут: [посилання на кейс-трекер]. Надалі ви також можете надсилати запити на ф'ючерси так само, як і я тут: [посилання на трекер справи]

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

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

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

У моєму випадку рано стало зрозуміло, що в якийсь момент все піде вниз. Бізнес все ще зростав, але конкуренція піднімала голову, ринок виглядав так, ніби він скорочуватиметься, з'явилися ранні ознаки (середина 2006 року), що економічне уповільнення наступає тощо. я вирішив, що продукт згодом загине; чим пізніше, тим краще (як для клієнтів, так і для мене самого).

Зрештою, я, мабуть, прийняв стільки хороших рішень, скільки й поганих, але ось короткий досвід:

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

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

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

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

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

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

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

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

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

Найкраще зробити, це зупинити автобус і озирнутися назад. Ваш друг повинен

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

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