Кровотечение краю поля против проверенную технологию. Как вы добьетесь равновесия

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

Аргументы в пользу выбора новейшей технологии

  1. это может преодолеть некоторые ограничения существующей технологии (не думайте о SQL vs RDBMS, когда речь заходит о масштабируемости). Иногда новейшие технологии обратно совместимы и только добираются до получить новые функции, не нарушая старой функциональности
  2. это даст лучший пользовательский опыт (может быть HTML 5 для видео, просто мысль)
  3. сократит время разработки/стоимость и сделает обслуживание кодовой базы относительно легким

Аргументы за выбор технологии, проверенной на практике/против выбора технологии с истекающим краем

  1. она не выдержала испытание временем. Могут возникнуть непредвиденные проблемы. запутанные решения могут привести к большему проблемы во время фазы обслуживания, и приложение может стать белым слоном
  2. стандарты, возможно, еще не установлены. Стандарты могут измениться, и может потребоваться значительная доработка, чтобы проект соответствовал стандартам.Выбор технологии, проверенной в полевых условиях, сэкономит эти усилия
  3. новая технология может не поддерживаться организацией. Поддержка новой (или, если уж на то пошло, другой технологии) потребует дополнительных ресурсов
  4. это может быть трудно получить квалифицированные ресурсы с технологией bleeding edge

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

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

TL; DR

Итог. Когда вы считаете технологию достаточно зрелой, чтобы она могла быть принята организацией ?

6 4
project-management project-organization

6 ответов:

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

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

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

  3. Найдите какой-нибудь новый небольшой проект с очень низким риском (например, что-то, что будете использовать только вы или пара человек), примените новую технологию в стиле skunkworks, чтобы увидеть, как она работает.

  4. Постарайтесь найти наиболее зрелых из незрелых. Например, если вы думаете о хранилище данных типа NoSQL. Все NoSQL вещи незрелые, когда вы сравниваете с СУБД, как Oracle, которая имеет существует уже несколько десятилетий, поэтому посмотрите на наиболее зрелое решение для них, которое имеет организации поддержки, либо профессионально, либо через группы поддержки.

  5. Самый простой проект для запуска-это перезапись существующего программного обеспечения. У вас уже есть свои требования: сделайте его таким же, как , что. Просто выберите небольшой фрагмент программного обеспечения для перезаписи в новой технологии, предпочтительно что-то, что вы можете забить с помощью модульного / нагрузочного тестирования, чтобы увидеть, как он стоит. Я не выступаю за то, чтобы перепишите всю заявку, чтобы доказать это, но небольшой измеримый кусок.

5

Несколько эмпирических правил.

Одновременно используйте только одну" новую " технологию. Чем больше новых вещей вы используете, тем больше вероятность возникновения серьезной проблемы.

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

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

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

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

2

Есть разница между" проверено в полевых условиях "и " устарело"."Разработчики (в том числе и я) обычно предпочитают bleeding edge вещи. В какой-то степени вам нужно, чтобы ваши сотрудники по развитию были довольны и заинтересованы в своей работе.

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

Когда я начинаю новый проект, при оценке того, стоит ли мне переходить на новую платформу, на ум приходят два вопроса:

1) Какие преимущества я получаю от перехода на новую платформу. Если это позволит мне значительно сократить время разработки или значительно повысить производительность для пользователей, я рассмотрю технологию semi-bleeding edge.

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

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

1

Это зависит от контекста. Каждая организация должна принимать свои собственные решения. Классической литературой на эту тему является "пересечение пропасти" Джеффри А. Мура.

1

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

Например, я был бы очень рад разработать Rails 3 или Ruby 1.9, так как я совершенно уверен, что они будут в порядке, когда будут завершены.

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

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

0
    Вы должны задать себе только один вопрос ... чувствую ли я себя счастливым ?
  1. Где деньги ?
    • получаете ли вы прибыль достаточно большой и быстрой, даже если tech X-флоп ?
  2. Если нет, то приносит ли новая технология более высокий perf в течение длительного времени?
    • Как 64-битный процессор, шейдерная модель 4, тяжелая многопоточность
  3. видите ли вы вокруг него много идейных труб
    • "сдвиг парадигмы" и т. д. - подождите 2-8 лет, пока он не остынет и не станет заменяет : -)
  4. он громоздкий и требует 2x всего, чтобы просто работать?
    • пусть ваш враг заплатит за это первым : -)
  5. Можете ли вы просто получить некоторое базовое образование и пробный проект, не рискуя ничем?
    • можно попробовать, если только это не выглядит как 400-фунтовая леди, которая не поет : -)
  6. нет общего ответа на такой вопрос-пожалуйста, добрались до #1
0