Должен ли я поднять тему процессов компании, которые нуждаются в улучшении?

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

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

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

Мне кажется, вашей компании нужен менеджер по изменениям. Возможно, вы свободны для позиции? Абсолютно, поднимите. Возможно, с черновиком должностной инструкции, которая станет решением. Особенно, если вы хотите быть тем, кто это исправит. :)
Можете ли вы получить бай-ин от любого члена вашей команды? Наиболее логичным было бы начать с проверки воды. Внесение изменений в организацию чревато политикой. У вас будет гораздо больше шансов на успех в ваших усилиях, если вы сможете показать, как «ваши предложения» помогли вашей команде повысить производительность, снизить количество ошибок или какие-то другие поддающиеся измерению конкретные цифры, подтверждающие вашу позицию. Большинство специалистов по программному обеспечению не поймут вашу оценку, поэтому вы думаете, что поймет тот, кто может внести организационные изменения? Вам нужны цифры. Они будут понимать числа.

Ответы (3)

Все может иметь неприятные последствия. Но ваш подход правильный. Я имею в виду документирование того, что делается в компании, и обеспечение/поддержание обратной совместимости — все это хорошо. Единственное, что я могу вам посоветовать, это начинать медленно и очень тактично. Ваш босс или его близкий друг могли поддерживать эту кодовую базу или могли написать ее когда-то в прошлом, не обращая внимания на поддержку, и она все время хромала. Теперь новичок, «горячий яппи» в их глазах, пытается научить их, как делать свою работу. Если это так, это не будет восприниматься легкомысленно. Даже если они будут знать, что это правильный способ сделать это, они будут сопротивляться и ставить одно препятствие за другим, пытаясь объяснить, что то, что вы сказали, делать не следует.

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

Если компания небольшая и в ней отсутствует иерархия некоторых более крупных компаний: я бы рекомендовал использовать некоторые стратегии, которые могут работать, а не просто быть тем парнем, который знает, что что-то не так, но намеревается раздать работу по исправлению этого. в другом месте.
Совет, который я бы добавил к этому хорошему ответу, заключается в том, что вы должны представить свой совет в виде реальных проблем (например, примеры нарушения кода другими командами из-за удаления кода библиотеки) и предлагаемых решений. Определенно согласен, что вы должны быть тактичны и делать это без осуждения. Слишком часто я вижу программистов, которые не могут описать существующую проблему, не дав ясно понять, что они думают, что проблема существует, потому что все, кроме них самих, являются некомпетентными недоумками. Не будь таким.
Я думаю, если вы можете найти кого-то из одной из команд, кто будет чувствовать боль от всех этих плохих процессов. Сядьте с ними и подумайте, действительно ли вы решаете проблемы за них или понимаете проблемы, и тогда это отличный информационный момент. «Боб» из группы подачи заявок сказал мне, что они потратили X дней в этом месяце на эти проблемы. Я думаю, что возможность говорить о боли в реальных терминах может иметь большее значение для некоторых менеджеров, чем просто на уровне целостного процесса.

Многие из проблем, которые вы обсуждаете, являются существенными недостатками в управлении изменениями и/или процессе SDLC.

Нет четко определенных процессов обслуживания программного обеспечения внутри компании.

  1. Как вы отслеживаете, какие изменения были внесены в программное обеспечение,
    особенно в производственной среде, если она существует в вашей
    компании?

  2. Если журналы изменений не используются, как вы будете отслеживать внесенное изменение и определять, является ли оно авторизованным и не злонамеренным?

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

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

Что процесс SDLC, будь то WaterFall или версия Agile, говорит о том, как обрабатываются изменения кода? Существует ли функция контроля качества, обеспечивающая соблюдение правильных методов разработки?

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

  1. Каковы рабочие роли сотрудников, которые имеют возможность изменять/удалять код из репозитория?
  2. Разделяются ли несовместимые обязанности между разработчиками, имеющими прямой доступ к производству?
  3. Требуется ли тестирование и документирование результатов перед развертыванием кода в рабочей среде?
  4. Насколько надежны процедуры отката/восстановления на случай, если внесенные изменения приведут к сбою системы?

Вы также должны признать, что если ваша компания является публичной компанией на фондовом рынке США, она подпадает под действие Раздела 404 Закона Сарбейнса-Оксли (SOX) , если рассматриваемый процесс каким-либо образом влияет на финансовую отчетность. Сарбейнс Оксли - Раздел 404 обязывает руководство нести личную ответственность за адекватность внутреннего контроля в своей компании. Высшее руководство может попасть в тюрьму, если его признают виновным в мошенничестве и искажении информации о внутреннем контроле.

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

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

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

Посмотрите, что вы сами написали о своем работодателе:

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

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

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

Так что да, есть много способов, которыми ваша инициатива может иметь неприятные последствия.

Должен ли я поднять тему процессов компании, которые нуждаются в улучшении?
СпросиСетьПолитика конфиденциальности1y, 0v