Стратегія для побудови підтримки потрібна. Але вибудовувати її потрібно з інформації про самих проектах.
Кількість користувачів клієнтських систем мають не саме велику вагу при побудові підтримки. Більше впливає кількість звернень, і середній час вирішення запиту.
Відокремлювати підтримку від розробки має сенс якщо дуже багато функціоналу типового (загального для всіх проектів). Якщо доопрацьованого функціоналу багато, співробітникам ДП доведеться тримати в думці всі особливості по кажому проекту. При збільшенні кількості проектів інформації стане дуже багато, що може позначитися на якості поддерку.
У разі сильно доопрацьованих проектів имет зміст виділяти 1 співробітника підтримки на 3-4 проекту. Але тут вже індивідуально потрібно підходити як до проекту так і до співробітника. Залежить від ступеня доопрацювання проекту і навичок співробітника.
І звичайно ж не варто робити з підтримки кур'єрською службою, в цьому випадку вони просто передадуть роботу тим же програмістам, і самі будуть сидіти на попі рівно.
В ідеалі співробітник поддерку повинен вміти розподілити питання по декількох типів (1. консультації по функціоналу, 2. помилки в функціоналі і 3. доопрацювання (забаганки) цього функціоналу). Якщо співробітник цього робити не буде-все ляже на програміста і сенсу в такій підтримці немає.
При цьому на всіх типах питань він повинен розуміти що від нього вимагається.
1. Консультація по функціоналу- це 100% питання підтримки.
2. помилка-% 40-50 це підтримка. Діагностика, відтворення, тестування після виправлення (останній можливо в відділ тестування, це вже залежить від того як побудований процес випуску патчів / релізів).
3. Доопрацювання / хотелкі- 10-20% також потрібні роботи поддерку. З'ясувати бізнес-процес, можливо це можна зробити і поточними засобами без доробок. Якщо вже зовсім нікак- тут ще й ТЗ написати для розробників.
Пардон про яку стратегії може йти мова в таких масштабах? Заявки від 100 користувачів обробить навіть 0,5 мавпи.