Казалось бы абсурдным, что хорошая идея может принести вред. Но это то, что чаще всего случается, когда подобные идеи появляются в вашем проекте. Они способны запросто “убить” ваш проект, причем “смерть” будет медленной и мучительной. Давайте рассмотрим на примере. Предположим на секунду, что в вашем проекте все протекает без проблем: вы успеваете завершить все задачи в срок, уровень качества кода на высоте, демонстрации в конце итерации приводят заказчика в восторг. Довольно смелое предположение, не правда ли? 😉 И тут у кого-то из членов команды появляется она, “хорошая” идея:

• Почему бы нам не перейти на новую версию Hibernate?
• Было бы здорово начать использовать NoSql базу данных для хранения определенной информации?
• А может сделаем показ панели со статистикой на AJAX?
• …

Парадокс в том, что идея то “хорошая”, потому что плохие идеи отсеялись бы командой или менеджером. И вот автор идеи презентует ее команде и просит “пару дней” для ее реализации. Так как на проекте все хорошо, то это время выделяется. И тут начинаются проблемы. Изменения оказываются не так просты, новые версии библиотек отказываются взаимодействовать с существующими, появляются скрытые дефекты, реализация идеи начинает отрицательно влиять на существующую функциональность. И, если вовремя не остановиться, эти проблемы будут приводить к незаконченным итерациям, пропущенным релизам, цунами из дефектов. Как распознать такую идею? Это очень просто – она обычно не несет в себе никакой выгоды с точки зрения требуемой функциональности системы. Легко сказать, но не так легко сделать. Поэтому запомните несколько шаблонов для быстрого определения “хороших” идей:

• “Было бы классно, если бы …”. Вместо слова “классно” можно подставить синонимы наподобие “прикольно”, “здорово”, “клево”. Эти слова заранее намекают нам на опасность всего, сказанного далее.
• “На прошлой неделе библиотека XXX выпустила новую версию. Мне кажется нам нужно на нее перейти!”. Обычно в таких предложениях не указывается конкретная причина перехода, к примеру, исправление важного дефекта или новая удобная функциональность для старых проблем.
• “Так как я буду заниматься рефакторингом модуля XXX, заодно внесу изменения в YYY.”. Такие изменения не вносятся “заодно”, потому что раздувают объем задачи и увеличивают риск ее невыполнения в срок.
• “Технология XXX выглядит просто супер! А в сочетании с новым языком YYY она может нам очень сильно пригодиться!”. Не всегда новые технологии работают так, как это описано в документации или презентации их возможностей. На практике у них почти всегда оказывается множество ограничений и проблем.
• “Я вот тут поразмыслил и пришел к выводу, что нам нужно сделать несколько изменений в архитектуре …”. Изменения в архитектуре могут быть сделаны необдуманно, не видя общей картины происходящего, определенных особенностей системы. Размышляя только в контексте одной проблемы, можно придти к необдуманным решениям.

Опасайтесь “хороших” идей, многие из них способны разрушить ваш проект!