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

14

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

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

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

  • Чтобы уточнить, разработка программного обеспечения не является основной деятельностью моей компании. Как таковых внутренних протоколов не существует. Кроме того, у проекта вообще нет официальной документации и документов с требованиями. Разработка очень специальная.
Джеймс
источник
6
Я сочувствую вашей проблеме. К сожалению, не существует легкого способа обойти это, и я уверен, что ваш вопрос задавался ранее по-разному. Одна вещь, которую я бы порекомендовал, - это избегать написания отчета с «открытыми» проблемами. Менеджеры (особенно нетехнические) ненавидят то, говорят ли они это прямо или нет. Если вы жалуетесь на что-то, вы должны дать конкретные и практические рекомендации, чтобы сделать это лучше.
Анджело
3
@James, формат документа в вашем контексте совершенно не имеет значения. Важно то, что вы: 1) идентифицируете изменения, которые вам необходимо внести, 2) описываете конкретный план их реализации и 3) убеждаете тех, кто участвует, согласиться с планом. В среде, где вещи являются «специальными», формальная структура документа ничего не значит.
Анджело
7
Если не будет активной системы замены, я бы поспорил, что нынешняя не «на жизнеобеспечении». Особенно, если компания включит это в планы на будущее.
TMN
7
С каких это пор 5-летняя система "наследие"?
Марьян Венема
1
@James - Это не определение устаревшей системы. Наследие определяется наличием (явно) более новой или более эффективной технологии, а не отказом внутренних процессов или удержанием персонала.
Джон Хопкинс

Ответы:

23

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

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

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

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

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

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

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

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

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

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

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

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

Томас Оуэнс
источник
9
I've worked with code that was 10 years old before Как насчет 25 лет :) До сих пор удовлетворял потребности компании и проделал потрясающую работу над тем, для чего она предназначена, несмотря на то, что прикосновение к коду было примерно таким же приятным, как плавание в Арктике.
maple_shaft
@maple_shaft Ничего 25 лет. Я думаю, что самому старому коду, который я когда-либо видел, было около 10-15 лет. Это не приятно, но пользователю нет дела до чистого кода. Они заботятся об использовании программного обеспечения, которое делает то, что им нужно, таким образом, чтобы это помогло их бизнесу.
Томас Оуэнс
1
@ Джеймс Не совсем. Если это усовершенствование программного обеспечения или дефект, который требует некоторых изменений в существующей системе, это отслеживается в трекере дефектов, где он получает приоритеты и назначается. Если это процесс, методология или уведомление для будущего проекта, то это либо фиксируется с помощью технико-экономического обоснования, которое создает прототип решения, либо инженерной записки.
Томас Оуэнс
1
Я работаю над 15-летней системой, и это радость. Да, есть части, которые могут быть улучшены, но это могут быть старые части или части, которые были написаны всего шесть месяцев назад. Как и у людей: возраст невелик. Именно забота, которая была предпринята при разработке программного обеспечения, и сколько технического долга было понесено во время этой разработки, определяет, сколько или как мало радости вы можете получить от него.
Марьян Венема
1
@James SRS техническая. Если вы имеете дело непосредственно с управлением, а разработка программного обеспечения не является их основным бизнесом, то вам придется обойтись в деловом плане. Поскольку не существует проектной документации и т. Д., Я бы начал с бизнес-кейса или плана проекта или анализа вариантов реинжиниринга перед любой SRS. Менеджеры и бизнес понимают одну вещь - это стоимость. Полностью переписан может быть сопряжено с трудностями, так что будьте осторожны.
Джейсон С
7

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

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

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

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

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

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

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

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

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

maple_shaft
источник
Возможно, использование термина «наследие» было неверным. В настоящее время технология управляет системой VBA и классическим ASP. Кодовая база была создана несколькими вращающимися интернами в прошлом. Википедия идентифицирует унаследованную систему как ту, которая больше не понимается, и что такие ситуации возникают, когда система не документирована, и / или первоначальные разработчики ушли. Кроме того, «отступление» заключено в кавычки, потому что у меня есть личный девиз «никогда не быть довольным посредственностью», и поэтому не могу бездействовать и не высказывать опасений. Я чувствую, как будто я не помогаю
Джеймс
@James Хорошо озвучивать проблемы, но сделайте это один раз, сделайте это полностью, представьте жизнеспособную альтернативу, а затем оставьте это при этом. Если вы озвучиваете одну и ту же проблему более одного раза, вы будете восприниматься как нытик, а нытики - бесполезны. Если вы не понимаете этого, и никто в доме действительно не понимает это технически, тогда это действительно наследство, вы правы.
maple_shaft
7
Джеймс, может быть, вы никогда не довольны посредственностью, но из этого обмена у вас создается впечатление, что вы не очень хорошо представляете себе более широкую картину того, как программное обеспечение поддерживает бизнес и как бизнес-приоритеты отличаются от ваших.
Temptar
2
«Википедия идентифицирует унаследованную систему как систему, которую больше не понимают». Ну, если вы понимаете и документируете это, так что это понимаете, то это больше не будет устаревшей системой.
DJClayworth
2
«Никогда не быть довольным посредственностью» - хороший девиз, но он применим только к вещам, которые вы можете контролировать сами. Если вы возьмете посредственную кодовую базу и превратите ее в хорошо документированную, простую в обслуживании кодовую базу, это отличная работа, которой вы должны гордиться.
DJClayworth
5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Майк Челлини
источник
1
Одна из самых важных вещей, которые могут быть выполнены как X, Y или Z - это написать модульные тесты. Наличие тестов делает работу с устаревшим кодом, который может в любой момент сломаться, намного менее стрессовой.
Кевин Вермеер
3

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

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

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

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

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

Идиоты
источник
Другая вещь, для которой хороши стажировки, это определение, хотите ли вы работать в компании, и (для них), хотят ли они, чтобы вы работали для них. Это гораздо лучшая ситуация, чем если бы ОП был нанят в качестве штатного сотрудника и был обеспокоен сохранением первой работы или быстрым уходом.
Кевин Вермеер
3

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

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

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

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

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

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

Dipan.

Дипан Мехта
источник
2

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

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

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

HLGEM
источник
1

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

JeffO
источник