Я работаю оффшорным старшим разработчиком Oracle ERP в компании BPO, и у меня есть оншорный менеджер («MM»). Я работаю здесь уже более двух лет, и с самого начала я заметил одну вещь: отсутствие ИТ-стандартов с точки зрения управления услугами, стандартов кодирования и лучших практик. Это вызывает у нас много вопросов, переделок и конфликтов. Даже М.М., мой непосредственный руководитель, не придерживается правил.
Во время одного из наших сеансов демонстрации экрана он даже модифицировал и скомпилировал код непосредственно в производство. Обычные ИТ-политики гласят, что только администраторы баз данных должны компилировать код в рабочую среду при наличии утвержденного запроса на изменение. Я упомянул ему об этом, но он сказал, что у него есть права доступа к базе данных, и он знает, что делает.
Чтобы привести еще несколько примеров:
Во время другого сеанса совместного использования экрана он хотел, чтобы я поместил COMMIT в свою хранимую процедуру, но это считается плохой практикой. Несмотря на мои протесты и перечисление некоторых случаев, когда это может привести к катастрофическим последствиям, он настоял на том, чтобы поставить COMMIT, и мне ничего не оставалось, как это сделать. Когда процедура запустилась на следующий день, произошел сбой, и обновленные записи не удалось восстановить. Нам пришлось получить данные из резервной копии и заново создать таблицу.
Во время еще одного сеанса демонстрации экрана он хотел, чтобы я исключил определенный идентификатор заработной платы из запроса. Я попытался поместить подзапрос, чтобы избежать жесткого кодирования идентификатора, но он настоял на том, чтобы я просто поместил «Payroll_ID <> 31», потому что он знал, что 31 - это Payroll_ID. Несмотря на мои многочисленные протесты, он настаивал, и мне ничего не оставалось, как в очередной раз сделать то, что он хочет.
Третий сценарий аналогичен второму сценарию выше, но с той лишь разницей, что я сказал ему «Нет»:
Я: «ММ, извините, но я действительно должен с вами не согласиться. Я не буду жестко кодировать идентификатор, поскольку я уже упоминал вам, что это не лучшая практика и может привести к проблемам».
ММ: «Лучшие практики не соответствуют действительности, они основаны на книгах и концепциях. У меня более 30 лет опыта в этой области, так что не говорите мне о лучших практиках».
Так что в очередной раз у меня не осталось выбора, кроме как придерживаться того, чего он хотел.
Я даже давал ему демонстрации и предложения о том, как лучшие практики положительно повлияют на нашу работу, но он закрывает на это глаза.
Должен ли я продолжать настаивать на том, чтобы он придерживался стандартных практик и ИТ-политик, или я должен просто сообщить о нем высшему руководству?
Практически невозможно изменить поведение любого босса.
Более невозможно изменить корпоративную культуру, если вы не занимаете относительно высокое положение и/или не получаете поддержки от других, занимающих относительно высокое положение.
Ваш единственный реальный вариант — искать другую работу в месте, культура которого соответствует вашему мировоззрению, и не высовываться, пока не переедете.
Единственный способ убедить кого-то с бычьим носом — это доказать, что ваш путь лучше, на собственном примере . Я предлагаю использовать заметные производственные инциденты или новые запросы функций, которые трудно реализовать из-за отсутствия стандартов. Бросьте это ему в лицо (вежливо, а не с видом «понимаешь, я же говорил») и позволь ему спорить с холодными неопровержимыми фактами.
Например, если он выполняет развертывание непосредственно в рабочей среде, не нарушает ли это что-то и не злит ли это клиентов/руководителей вашей компании? Вы должны профессионально сообщить об отсутствии стандартов, вызывающих эти проблемы, и предложить свой подход к их устранению. Если у него ничего из этого не будет, я думаю, вы можете просто захотеть пройти через его голову в этом, хотя не удивляйтесь, если это обернется для вас неприятными последствиями.
В крайнем случае вы меняете работу, но на самом деле вы просили не об этом.
Эрик
пользователь62478
Конор Манконе
Толстяк
Диана Тортолини
Пит Б.
Лорен Пехтель