Бывают ситуации, когда необходимо попрощаться с командой разработчиков проекта, чтобы передать его вновь сформированной команде поддержки. Могут возникать различные конфликтные ситуации, когда компания вынуждена сменить опытную команду, которая вложила в проект свои силы и знания, изучила все узкие места проекта, на совершенно новую команду, которая видит проект впервые. Если не подготовиться заранее к работе с командой поддержки, сложности так возникнуть рано или поздно в процессе.
Очень важно делать все необходимое, чтобы ваши пользователи были довольны. Поэтому, если не уделить должное внимание организации процессов поддержки приложения, вы рискуете потерять все, чего вы достигли, включая самых преданных пользователей.
Специалисты нашей компании по разработке приложений готовы поделиться советами, основанными на собственном опыте поддержки ПО. Как минимизировать риски при принятии новой команды, которая займется процессами обслуживания вашего проекта?
Прежде чем нанимать новую команду для процессов обслуживания и поддержки проекта, очень важно произвести так называемый трансфер знаний между двумя командами. Более того, нельзя просто поставить команды поддержки перед фактом - “Итак, ребята, вот тот самый проект, с которым вам придется работать. Вот документация. А теперь приступайте к делу”. Такой подход так или иначе приведет к катастрофическому фиаско.
Всегда должен быть пошаговый план. На наш взгляд, до того, как оставить команду поддержки работать автономно, они обязаны пообщаться с членами команды разработки в первую очередь. Лучшим решением будет позволить им поработать вместе первые пару недель или даже месяцев, таким образом новая команда сможет быстрее ознакомиться со спецификой системы. Тем не менее, если такой вариант невозможен, хотя бы попытайтесь организовать парочку встреч для трансфера знаний между командами. В будущем вы убедитесь, что это было одно из лучших решений, которое повлияло на успех вашего проекта в целом.
Ошибка, которую многие клиенты совершают: они только начинают думать о рекрутинге команды поддержки, когда уже слишком поздно. В корне неверно начинать поиск команды прямо перед релизом приложения в production, или ещё хуже - после. Наиболее оптимальный вариант - начать вовлекать участников команды поддержки ПО уже на стадии разработки, чтобы обеспечить полное понимание системы ещё до непосредственного старта работ по её обслуживанию.
Считайте это своего рода подготовительным периодом. Участники будущей команды поддержки после участия в этапе разработки получат незаменимый практический опыт и знания, а также смогут принять участие в создании необходимой для будущих процессов поддержки документации.
Лучшее время начать подключать команду поддержки в процесс - стадия тестирования накануне релиза.
Когда проект очень большой, его проектная документация может оказаться, мягко говоря, в хаотичном состоянии. Когда новая команда поддержки приступает к работе, им тяжело во всем этом разобраться, приходится полагаться на свой опыт, что конечно же более проблематично и затратно в итоге.
Что вы можете сделать? Когда работы по обслуживанию ПО уже стартовали, мало что можно сделать, поэтому лучше подготовиться заранее. Профессиональная команда поддержки всегда ведет свою собственную Базу знаний, однако, лучшим решением будет попросить команду разработки начать её, вводить в неё ценную информацию и обновлять по ходу процесса разработки.
База знаний - незаменимый инструмент, главная цель которого - обеспечить команду информацией о том, как решать различные возникающие проблемы.
План Перехода представляет из себя набор инструкций о том, как оптимизировать переход от разработки к поддержке ПО. Хороший план содержит четкие пункты о том, кто ответственен за процесс перехода, как инструменты и методологии будут использованы, а также не забудьте о дедлайнах! План Перехода оказывается особенно полезным, когда предполагается, что поддержкой ИТ-проекта будет занимается совершенно новая команда.
План Перехода регламентирует такие моменты, как База знаний, график, техники приоритизации багов, процедура деплоймента, и прочее.
Возможно для вас это окажется сюрпризом, однако успех команды обслуживания во многом зависит от того, насколько четок и понятен этот план. Постарайтесь не пропускать этап создания данного документа, потратьте на это достаточное количество времени, а затем убедитесь, что все, причастные к данному процессу, внимательно ознакомились с документом.
В большинстве случаев единственным разумным первым шагом для новой команды является полное QA тестирование системы, а иногда - полный аудит кода. В результате, команда обслуживания сможет обнаружить все слабые места приложения, сгенерировать идеи о том, как оптимизировать серверную часть (при необходимости и по возможности).
Более того, внешний аудит ИТ-проекта помогает получить свежий взгляд, и, таким образом, новая группа поддержки сможет обнаружить некоторый функционал, который стоило бы улучшить или исправить. Реже команда может столкнуться с чем-то критическим. В этом случае стоит убедиться, что предшествующая команда разработки предоставила гарантию на свою работу. Это очень важный момент, потому что команда обслуживания проекта изначально занимается только поддержкой жизнеспособности приложения, а не реализацией функционала.
_
В Smartym Pro мы прошли через большое количество проектов поддержки в разных доменах. Самый важный урок, который мы усвоили за это время - общение позволяет решить почти любую проблему. Мы советуем вам, как клиенту, быть более внимательным к деталям, планировать активности заранее, создать комфортную рабочую атмосферную для новой команды, обеспечивая их всем необходимым, включая ресурсы, документы и знания. А если у вас есть какие-то дополнительные вопросы о том, как организовать продуктивный процесс поддержки и обслуживания ИТ-проекта, свяжитесь с нами, чтобы получить совет. Удачи!
Все
Технологии
Ликбез
Места
HowTo
Стартапы
Новости
Сервисы
Приложения
