«Хорошие» идеи, которые могут плохо закончиться

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

Они способны запросто «убить» ваш проект, причем «смерть» будет медленной и мучительной. Давайте рассмотрим на примере. Предположим на секунду, что в вашем проекте все протекает без проблем: вы успеваете завершить все задачи в срок, уровень качества кода на высоте, демонстрации в конце итерации приводят заказчика в восторг. Довольно смелое предположение, не правда ли? И тут у кого-то из членов команды появляется она, «хорошая» идея:

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

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