.note | GTD – feature overload?

Многие разработчики, которые считают себя необыкновенными гуру своего дела, тем не менее не имеющие практически никакого коммерческого опыта продвижения проектов попадают в стандартную западню «дрожжевого эффекта» (между прочим, жертвами этой западни часто становятся управленцы или, чего хуже, топ менеджеры).

Что это, Берримор? Это, господа, погоня на «фичами». В софт набивают весь функционал, который приходит в голову, притом не замечая что:

  1. Большинство пользователей в нём (функционале) не нуждаются — принцип Парето
  2. С каждой новой фишкой софт подсознательно воспринимается как нечто сложное
  3. Рефакторинг софта становится очень ресурсоёмким процессом
  4. Каждая фишка несёт в себе тучу зависимостей и потенциальных ошибок и уязвимостей

Так что выводы довольно просты — любой функционал будет в большинстве случаев лишним. Это правило, между прочим, применимо как к разработке бесплатного софта и/или сервисов, так и к разработке софта платного (рассматривается, конечно, Shrinkwrap модель, а не OnDemand разработки).

Ну и что же тогда делать? А что, ничего, просто следовать следующим принципам:

  1. Создайте концепт идеи.
  2. Скажите НЕТ.
  3. Соберите достаточно доказательств того, что без этого концепта дальнейшая работа невозможна.
  4. Ещё раз попробуйте сказать “НЕТ”, если всё же при любом раскладе получается «да», то продолжаем…
  5. Предварительная детальная разработка концепта и «обсасывание идеи».
  6. Дизайн интерфейсов
  7. Ура, пишем код.
  8. -33. Тестируем, Рефакторинг, Тестируем, Рефаторинг, Тестируем, Рефакторинг
  9. Документируем
  10. Ищем недовольных и нанимаем киллеров
  11. Планируем новый релиз? Поднимаем цены?
  12. Запускаем!

Ну а кто сказал, что будет легко? Делать удобные и успешные вещи не так-то просто, как может показаться. Главное помнить, что «more is less», и что все вокруг идиоты.

Top

Слова: coding, юзабилити, менеджмент

Комментарии Отключены

artreal

Еще в древние времена была возможность ограничить функциональность софта. Например, RSX-11 можно было перегенерировать, включив только ту функциональность, которая нужна.

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

29.10.2005 // 10:58 [ ссылка ]

Ответ от Автора

это, конечно, так, тем не менее, вот, например, банальный пример FireFox — я в этом лесу плагинов теряюсь, мне отчего-то всё хочется попробовать, а не было бы их — и не было бы в этом броузере некоторых проблем, которые есть сейчас ;)

01.11.2005 // 21:10 [ ссылка ]

cactusinside

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

29.10.2005 // 12:39 [ ссылка ]

Ответ от Автора

это вопрос мастерства маркетологов ;) смотрим на успех iPod shuffle и думаем.

01.11.2005 // 21:10 [ ссылка ]

Boris

У Вас inses.ru не открывается почему-то. Как в wiki зайти? :)

30.10.2005 // 17:56 [ ссылка ]

Ответ от Автора

завтра будет работать, сорри, тех-проблемы

31.10.2005 // 01:26 [ ссылка ]

plandem

Как, кстати, GTD поживает? Помогает? :) А то я еще читаю пока и только начинаю внедрять.

31.10.2005 // 17:28 [ ссылка ]

Ответ от Автора

на маке есть тулзы хорошие

01.11.2005 // 21:11 [ ссылка ]

advertizer

Применимо кстати, не столько к разработке программного обеспечения, а к любому другому начинанию/проекту.

Ждем дальнейших откровений...

01.11.2005 // 19:59 [ ссылка ]

Комментарий Удалён
Комментарий Удалён
Комментарий Удалён