Поосторожнее с дополнительной функциональностью

27.01.2007

В процессе разработки постоянно появляются небольшие идеи о том, как сделать сайт лучше. Можно проектировать с очень высокой степенью детализации, составлять планы и расписания, но всего не учтешь. Интересные фичи не дают покоя голове. Люди отвлекаются и иногда слишком много времени думают «не о том».

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

Так уж получается, что разработчикам интересно менять предмет размышлений, заниматься какими-то оригинальными технологичными элементами. Это нормально: творческий процесс все-таки. Программистов-роботов не бывает. Но спонтанными процессами можно пытаться управлять.

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

Читал, что при разработке Excel 5 разработчикам до безумия хотелось сделать развитый мастер создания макросов. И естественно еще тысячу «совершенно необходимых» вещей. Потом они взяли себя в руки, отбросили все интересненькие штучки и выпустили продукт вовремя.

А через некоторое время, размышляя над тем, какой должна быть шестая версия, список фич, которые раньше казались такими ценными, удивлял проектировщиков своей бестолковостью. Об этом в тринадцатом пункте статьи Painless Software Schedules.

Нет, не выбрасывайте «маленькие» идеи. Просто не спешите воплощать их в жизнь. Пусть идея поживет в голове. Поищите ей обоснование. Спросите у кого-нибудь, действительно ли фича пригодится, или это только вам так кажется.

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

Не спешите реализовывать незапланированную функциональность. Сделайте пометку и вернитесь к ней через пару дней.

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

20% идей со второго-третьего раза кажутся бессмысленными, еще 10% оказываются уже реализованными (за всем не уследишь, хех). 50% — никогда не воплощаются, хотя и выглядят неплохо. Только 20% проходят проверку временем, и им находится место.

Комментарии

Александр Стекольщиков, 27.01.2007 15:54

Эх! Хорошо минималистам…

Дмитрий Сергеев, 27.01.2007 18:01

Наверное. Никогда не видел минималистов в этом смысле. Все вокруг только и делают, что бросают вызовы. Сплошные амбиции и реки творчества :)

~xXx~, 28.01.2007 00:55

реки творчества aka поток сознания далеко не всегда востребованы кем-либо кроме автора ) суровая правда жизни...

Дмитрий Сергеев, 28.01.2007 03:03

Точно. А часто и у автора после первых восторгов в голове проясняется. Но пара дней уже потрачена на "инновационные разработки", делать нечего. По себе знаю :)

~xXx~, 28.01.2007 00:54

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

Дмитрий Сергеев, 28.01.2007 03:07

Важно, чтобы все в команде это понимали и не преподносили сюрпризов.

Сложнее всего сделать так, чтобы разработчики почувствовали грань между уместным творчеством и откровенными авантюрами.

ARKAN, 30.01.2007 18:56

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

Дмитрий Сергеев, 30.01.2007 20:46

Вот-вот. Удержаться невозможно. А если еще и ТЗ расплывчатое и туманное, вообще караул :)

ARKAN, 31.01.2007 13:34

Честно говоря мне очень редко приходилось видеть НЕ туманно-расплывчатое ТЗ. Правда спасало иногда то что люди были без излишних запросов потому обходилось. Правда не всегда. Но ето уже отдельный разговор.

Дмитрий Сергеев, 31.01.2007 15:46

Мне кажется, за написанием ТЗ должно следовать тщательное проектирование, результатом которого является документ, где всё достаточно хорошо объясняется. Что-то вроде проекта сайта.

Важно не перейти границу, когда отдача от хорошей проектной документации будет положительной.

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

Жаль, что обычно времени нет и нужно нестись вперед :)