Как выйти из колеи поддержки и начать погашать технический долг!

У меня есть друг". Да, хорошее начало я знаю, но, честно говоря, это не я!

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

Я делал различные предложения, регистрировал все ваше время, создавал тикеты, не отвечал на электронные письма и т. Д. И т. Д. Проблема в том, что это только служит напоминанием о том, что он не делает ничего «полезного».

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

Я хотел бы знать, есть ли у кого-нибудь какие-либо предложения относительно того, как он мог бы выбраться из этой колеи, большая часть которой изменила бы восприятие пользователей, чтобы они не думали, что могут просто позвонить и ожидать чего-то быть сделано тогда и там.

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

Организация вашего друга отчаянно нуждается в ком-то, кто будет управлять изменениями. Этот человек или группа будут принимать запросы на изменение и исправлять ошибки и расставлять приоритеты в соответствии с влиянием бизнеса и необходимыми усилиями. Таким образом, задачи, которые являются более важными для организации в целом, будут выполняться в первую очередь, в отличие от задач, которые более важны для тех, кто беспокоит вашего друга в данный момент.

РЕДАКТИРОВАТЬ: В качестве примера того, как это будет работать, большинство организаций имеют шкалу серьезности. Самый высокий уровень серьезности - это критически важное для бизнеса приложение или функция, которая не работает. Если есть что-то, что бизнес может сделать, чтобы обойти проблему, это снижает серьезность до следующего уровня. Если приложение не критично для бизнеса, серьезность становится еще ниже. Запросы на новые улучшения обычно расставляются по приоритетам отдельно.

Сделайте, чтобы кто-то другой принял вызовы, и измените линию с

Мы вернемся к этому сразу.

в

Очень хорошее предложение. Я создам запрос функции, чтобы начать работу над ним как можно скорее. Если вы хотите следить за ходом выполнения вашего запроса, вы можете отследить его здесь: [ссылка на билет для отслеживания случаев]. В будущем вы также можете отправлять запросы на фьючерсы так же, как я здесь: [ссылка на регистратор дел]

Это, наверное, самый простой и эффективный способ сделать это, на мой взгляд. Последний бит пытается уменьшить нагрузку на этого человека, отвечающего на звонки с течением времени.

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

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

В моем случае рано стало ясно, что в какой-то момент дела пойдут вниз. Бизнес по-прежнему развивался, но конкуренция возрождалась, рынок выглядел так, как будто он собирался сокращаться, были первые признаки (середина 2006 года), что наступал экономический спад, и т. Д. В основном ряд факторов привел мне решить, что продукт умрет в конце концов; чем позже, тем лучше (для клиентов и для меня).

Оглядываясь назад, я, вероятно, принял столько же хороших решений, сколько и плохих, но вот краткий вывод:

1. Персонал это правильно и рано. Получить финансирование, если вам это нужно. (Не искать ничего было моей самой большой ошибкой.) Если вы продаете, вы найдете деньги.

2. Используйте контроль версий / юнит-тесты / все шумихи, связанные с передовой практикой. Они все выглядят глупо / смехотворно / неинтересно, когда преподаются в университете, но обычно они являются лучшими практиками по уважительным причинам.

3. Наймите хотя бы одного менеджера по продажам / маркетингу, особенно если вы ориентированы на технологии. (Потому что если это так, у вас будет естественная тенденция тратить больше времени на технические вопросы, чем на маркетинг, даже если у вас есть партнерская сеть).

4. Толпа-источник вашей поддержки. Создайте форум, чтобы пользователи могли выручить себя. Настройте систему продажи билетов и пригласите своих опытных пользователей (как правило, часто посещающих форум) погружаться в специальный раздел в качестве виртуальных помощников. Пусть они позаботятся о множестве клиентов, которым необходимо выполнить эту / эту небольшую задачу за несколько долларов, чтобы вы могли сосредоточиться на более широкой картине.

5. Сделайте все возможное, чтобы уменьшить объем оказываемой поддержки. Чем меньше у вас поддержки, тем больше времени у вас будет, чтобы делать больше интересных вещей. К тому времени, когда продукт станет фиктивным доказательством, клиенты будут благодарны, равно как и ваши продажи и ваш персонал поддержки.

6. Сделайте так, чтобы настоящие разработчики оказали некоторую поддержку (час или два в день, чтобы они не теряли связь с реальностью), и дайте им свободную руку, чтобы они предложили любой реинжиниринг / изменение продукта (пользовательский интерфейс, функциональность), если они определить все, что заставит их тратить меньше времени на поддержку. Идея состоит в том, что, если пользователи снова и снова терзают их по одним и тем же причинам, они захотят исправить положение как можно скорее, чтобы избавиться от звонков в службу поддержки. А умные действительно так и делают, и это именно то, что вы хотите.

7. Если вы чувствуете, что продукт умирает, решите убить его тут и там и поработайте над следующим шагом. Пусть это умрет, правда. Дойная корова - это дойная корова; когда оно выполнит свою задачу, отправьте его мяснику. Делайте это осторожно (для клиентов), но ни в коем случае не позволяйте его продолжительному выживанию сожрать слишком много вашего времени, если затраты на обслуживание таковы, что ваша конкуренция с преимуществом опозданий и накопления некоторого технического долга , будет реализовывать новые функции быстрее, чем вы можете в любом случае.

Одна строка за раз. Потратьте немного больше времени на каждое исправление, убирая хаки и добавляя автоматические тесты по мере работы. Часто правильные действия оказываются намного быстрее, чем добавление еще одного исправления. Если руководство подталкивает вашего друга к более быстрой работе, как это часто нравится руководству, ему следует увеличить толщину кожи и перейти в режим «когда это будет сделано».

Ключ в том, какую методологию развития он использует, чтобы в какой-то степени защитить его? Например, в Scrum есть идея, что то, что будет сделано, обычно не меняется во время спринта. Таким образом, есть некоторые правила относительно того, что будет сделано, а что не может быть сделано сразу. Другой вопрос, в какой степени руководство поддерживает его желание не быть в колее поддержки? Это также может быть важно, поскольку безразличное управление может быть чем-то вроде смертельного звонка для проекта вашего друга.

Лучше всего остановить автобус и оглянуться назад. Твой друг должен

• Составьте отчет о каждой проблеме в системе и объясните, почему они плохие. Проблемы дизайна должны быть выделены, а количество рефакторинга необходимо.
• Для устранения проблем необходимо указать приблизительные сроки
• Отчет должен быть передан его менеджерам, а затем заинтересованным лицам в системе.
• Все особенности разработки должны быть остановлены в течение периода фиксации.

Многие проекты делают это. Если руководство не может быть убеждено, это проигрышный случай, но если они согласны, система может быть восстановлена ​​в долгосрочной перспективе.