Убедить компанию добавить новые технологии и методы к своим стандартам?

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

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

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

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

Я нахожусь в довольно отсталом и архаичном магазине. Мы все еще используем CVS (!), Perl был обновлен только с 5.6 до 5.8 на этой неделе, а мы перешли на PHP 5 с 4 только в этом году. Если вы добьетесь успеха, дайте мне знать :), но, основываясь на опыте, я могу сказать вам, что иногда серьезным фактором, препятствующим внедрению новых технологий, является не столько то, что преимущества и превосходство технологии неизвестны или не признаются, но скорее, есть более насущные приоритеты, к которым хочет обратиться руководство.

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

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

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

Несколько советов:

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

Примеры:

• Стандартизация последней версии Java будет означать, что нам не придется продолжать поддерживать XX старых веток кода с затратами на £ YYm в год.
• Внедрение технологии облачной инфраструктуры YY сократит время предоставления новых серверов с 7 до 1 дня, что позволит нам выставлять клиентам счета за дополнительную выручку за шесть дней. Риск невелик, потому что мы уже успешно опробовали эту технологию в Команде А.