Как справиться с управлением, подталкивающим устаревшие системы?

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

Теперь руководство хочет продлить проект еще на один год, и в этом процессе пользовательская база почти утроится.

Как стажер (или любая позиция начального уровня), как мне «оттолкнуть»? Я уже написал отчет о своих проблемах, хотя и в открытом документе. Есть ли протокол или тип документа для предложения изменений? Могу ли я вносить предложения или просто продолжать поддерживать старую систему?

• Чтобы уточнить, разработка программного обеспечения не является основной деятельностью моей компании. Как таковых внутренних протоколов не существует. Кроме того, у проекта вообще нет официальной документации и документов с требованиями. Разработка очень специальная.

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

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

Действительно, 5 лет не так уж и долго. Я работал с кодом, который был 10 лет назад. Если он все еще служит потребностям пользователя, зачем выбрасывать его? Это выбрасывает много денег, потраченных на его разработку. До тех пор, пока обслуживание становится невозможным из-за растущих затрат или радикальных изменений требований, нет никаких бизнес-причин, чтобы выбрасывать их.

Теперь руководство хочет продлить проект еще на один год, и в этом процессе пользовательская база почти утроится.

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

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

Как стажер (или любая позиция начального уровня), как мне «оттолкнуть»? Я уже написал отчет о своих проблемах, хотя и в открытом документе. Есть ли протокол или тип документа для предложения изменений? Могу ли я вносить предложения или просто продолжать поддерживать старую систему?

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

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

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

* Чтобы уточнить, разработка программного обеспечения не является основной деятельностью моей компании. Как таковых внутренних протоколов не существует. Кроме того, проект не имеет никакой формальной документации, не требует документов. Разработка очень специальная.

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

Я уже написал отчет с изложением моих проблем

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

Теперь руководство хочет продлить проект еще на один год, и в результате почти утроить базу пользователей.

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

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

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

На протяжении всего проекта были допущены ошибки, которые привели его к этой точке. Отсутствие надежного пользовательского ввода или требований, отсутствие надлежащего управления продуктом и контроля изменений для управления меняющимися требованиями и потребностями, а также отсутствие достаточных технических ресурсов для реализации вызвали проблемы, которые существуют сегодня. Я не знаю, является ли устаревшее правильное слово, хотя. Является ли базовая технология построенной на поддерживаемых инфраструктурах и технологиях, или это просто не передовые или идеальные технологии?

Как стажер (или любая позиция начального уровня), как мне «оттолкнуть»?

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

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

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

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

Ваша задача - поддерживать работоспособность системы, а не предлагать новую блестящую замену.

Мне кажется, что многие молодые программисты не понимают, что обслуживание старых систем - это большая часть работы по программированию, чем проектирование блестящих новых систем /

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

Во многих случаях у вас могут быть даже самые лучшие намерения заменить текущую систему более совершенной системой, однако вы можете просто ввести новые и другие ошибки ... когда вы выйдете из системы, она быстро снова превратится в унаследованную систему, и компания быть в том же месте, что было раньше. Ничто не устареет, пока не перестанет обслуживать его назначение или не станет полностью несовместимым с современными системами. У моей компании есть система старше 20 лет, которую мы сейчас конвертируем в ASP.NET. Система по-прежнему работает, но поддержка старой технологии сокращается, и работа с современными веб-браузерами отнимает все больше времени.

Что ты можешь сделать:

Оставьте вещи чище

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

Создать документацию

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

Сделать его менее болезненным

Как я уже говорил, вы можете высказать свои опасения, но лучше всего, если вы будете усердно работать над системой и делать так, чтобы она работала для тех, кто за вами. Исправьте ошибки правильно. Документ. Разберитесь с запахами кода. Сделать его лучше. И когда вы сделаете это, сообщите своему начальству. Скажите им, что вы делаете X, Y и Z, чтобы улучшить процесс разработки. Это создает доверие и в конечном итоге поможет вам и вашей компании больше всего на свете.

ВЫ НЕ !!! Это отличная возможность!

Вы стажировка, чтобы учиться! Этот проект настоящий мир, как он есть.

Вам очень повезло с этим. Тот факт, что вы не квалифицированы, не является вашей заботой. (Если \ когда руководство осознает это, вы получите много)

ВЫ будете квалифицированы, как только закончите эту стажировку, и это отличная новость.

PS: Делайте резервные копии религиозно, будьте уверены, что ВСЕ, что вы делаете, можно откатить. Начните с проблем, которые являются «легкими исправлениями», но с большими болевыми точками для пользователей. Сделай шаги ребенка.

Я думаю, в очень теоретическом смысле - не существует такой вещи, как система Legacy . У меня очень старый телефон (устаревшая система), и в наши дни есть хорошие телефоны Android (современные платформы), но мой телефон работает и делает то, что мне нужно. Почему я должен выбросить это?

Все системы, которые вы сегодня называете «наследием», когда-то были самыми современными. Нам нужно только время. Кроме того, когда есть значительная работа, это не значит, что все заново делается на современных платформах, это означает, что она будет автоматически без ошибок (или безболезненно).

Вот что я рекомендую вам сделать:

1. Сначала избавьтесь от своей неприязни к "устаревшей системе". Это сделает вас очень контрпродуктивным.

2. Начните документировать, что вы сейчас делаете и что думаете. Хотя и пошагово. Нет лучшего времени для документирования, чем тот, в котором вы понимаете, что он вам нужен.

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

Dipan.

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

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

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

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