.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», и что все вокруг идиоты.

Oct. 28, 2005 // 19:19 | Комментарии (9)