Как можно убедить команду использовать новую технологию (LinQ, MVC, и т.д.)?
Очевидно, легче сделать с некоторыми разработчиками, но я уверен, что многие из нас находятся в командах, которые предпочитают статус-кво.
Вы знаете тип. Вы видите некоторое преимущество в части новой технологии, и они предпочитают испытанные и истинные методы.
Судите, например, программиста DBA/C# преимущества использования LinQ (не обязательно LinQ к SQL, просто LinQ в целом).
Например, Когда проектное требование состоит в том, чтобы быть межплатформенным... вместо того, чтобы думать о том, как можно запустить Windows на Mac через Машину VM, представив идею использовать относительно новую Silverlight или создать его в Java (как опция изучить).
Я знаю, что большинству людей не нравится быть вне их уровня комфорта, таким образом, требуется немного убеждения, и не ВСЯ новая технология приносит выгоду..., но как Вы убедили свою команду смотреть на новую технологию?
Какие технологии Вы успешно представили своему рабочему месту?
Что делают технологии Вы думаете, являются самыми твердыми представить? (Я думаю смещающие парадигму, как MVC от WebForms... или новых языков),
Какие стратегии Вы используете для создания этих новых технологий обращением?
9 ответов
Хорошо изучите технологию, прежде чем предлагать ее. Вы будете получать вопросы типа «но как мы можем заставить это сделать X?», И вы хотите иметь возможность дать хотя бы общий ответ.
Старайтесь не быть религиозным фанатиком. Признание того, что новая технология несовершенна, что это просто еще один инструмент в наборе инструментов, имеет большое значение для повышения доверия.
Дайте хорошо подготовленную живую демонстрацию, чтобы показать, на что она способна. Например, мой друг создал простой блог на Ruby on Rails за полчаса перед живой аудиторией. Я хочу подчеркнуть слово «хорошо подготовленный»; Если что-то продолжает ломаться, или вы не до конца понимаете, что делаете, или не можете ответить на основные вопросы, вы скорее навредите своему делу, чем поможете ему.
Мне удалось убедить команду, в которой я состою, перейти с CVS на Mercurial. Вы можете поверить, что мы все еще использовали CVS? Я тоже не мог поверить, когда начинал.
Я стал почти что проповедником, королевской занозой в заднице. Каждый раз, когда CVS лажал или причинял какой-то дискомфорт (например, был зверски медленным), я произносил небольшую речь о том, насколько лучше он мог бы быть .
Вскоре они приняли возможность того, что есть альтернативы (никто из них не знал, что есть альтернативы CVS!) и начали говорить что-то вроде "если действительно есть альтернативы, то все должно быть лучше, чем это".
Тогда я сделал свой ход и просто запустил несколько скриптов, преобразующих CVS-репозиторий в Mercurial-репозиторий, и загрузил его на сервер компании. Как только они увидели это в действии, они были проданы.
Не то чтобы я что-то планировал во время этой маленькой миграционной "черной операции", но, оглядываясь назад, я бы дал следующий совет всем, кто пытается сделать что-то подобное:
- Дайте людям знать, что есть (лучшие) альтернативы, что вполне возможно работать за пределами своей зоны комфорта.
- Подавайте пример, если вы хотите, чтобы что-то было сделано, сделайте это сами. Покажите альтернативу в действии. Никто не сделает прыжок, если вы не прыгнете первым, особенно если они уже колеблются.
Лучше всего показывать пример. Завершите успешный проект с использованием нового инструмента и ждите, когда разработчики спросят, как вы это сделали.
Я успешно ввел LINQ в свою компанию, и это очень помогло.
Что сработало для меня? Покажи и расскажи . Нашей предыдущей технологией было программирование баз данных с помощью C, что было настоящей неразберихой. Наш ведущий разработчик сделал около 3000 строк кода для заполнения набора данных, а я сделал это в 10-й части с помощью LINQ / C #.
Как только я сломал то, что делал, и он увидел, насколько это мощно, он был убежден, что пришло время обновляться.
Когда речь заходит о практике кодирования, мне больше всего нравится просто использовать примеры. Я потрачу несколько часов и отредактирую нашу кодовую базу, чтобы использовать новую технику вместо прежнего образца. Затем разошлю полку или список изменений остальным разработчикам, чтобы показать разницу. Или просто проведите собрание, чтобы обсудить разницу.
Демонстрация примеров в реальном производственном коде действительно помогает другим разработчикам увидеть преимущества.
Покажите им, как это решает общую проблему. Выберите проблему, которая возникает у них регулярно, и покажите решение. Обычно это, по крайней мере, заставляет их задуматься об этом.
Поставьте две технологии рядом друг с другом, можно с уверенностью предположить, что были достигнуты успехи и что то, что вы предлагаете, больше подходит для работа под рукой.
Положите перед ними необработанные результаты, и пусть они решат сами!
Я работаю в data beauro, и до недавнего времени компания была привязана к MS Access, который был громоздким и непригодным для работы, после серьезных убедительных доказательств и демонстрации мощи SQL по сравнению с Access, теперь это оружие выбор.
И нужно было поставить двух техников бок о бок и дать возможность ребятам наверху увидеть все своими глазами, сэкономленное время действительно имело смысл!
Вам нужно будет показать, почему эта технология ЛУЧШЕ (или, по крайней мере, в чем-то лучше), чем текущий используемый инструмент / метод, и, вероятно, значительно. Иначе зачем тратить силы на изучение чего-то нового?
В противном случае убедите босса, а затем получите мандат ... (хотя я действительно не рекомендую этого, если вы не можете привлечь хотя бы половину команды. ).
Совет от людей, которые убедили руководство рассмотреть возможность использования F#, звучит примерно так:
Реализуйте самые важные части следующего ключевого проекта компании на F# в свободное время, а затем покажите другим, какие преимущества он дает, как быстро вы смогли его реализовать и как легко адаптировать решение к меняющимся требованиям.
Я думаю, что это довольно эффективный способ - когда люди действительно видят продуктивность (любой новой технологии), гораздо легче убедить их в том, что ее стоит изучить.