.note | GTD – feature overload?
Многие разработчики, которые считают себя необыкновенными гуру своего дела, тем не менее не имеющие практически никакого коммерческого опыта продвижения проектов попадают в стандартную западню «дрожжевого эффекта» (между прочим, жертвами этой западни часто становятся управленцы или, чего хуже, топ менеджеры).
Что это, Берримор? Это, господа, погоня на «фичами». В софт набивают весь функционал, который приходит в голову, притом не замечая что:
- Большинство пользователей в нём (функционале) не нуждаются — принцип Парето
- С каждой новой фишкой софт подсознательно воспринимается как нечто сложное
- Рефакторинг софта становится очень ресурсоёмким процессом
- Каждая фишка несёт в себе тучу зависимостей и потенциальных ошибок и уязвимостей
Так что выводы довольно просты — любой функционал будет в большинстве случаев лишним. Это правило, между прочим, применимо как к разработке бесплатного софта и/или сервисов, так и к разработке софта платного (рассматривается, конечно, Shrinkwrap модель, а не OnDemand разработки).
Ну и что же тогда делать? А что, ничего, просто следовать следующим принципам:
- Создайте концепт идеи.
- Скажите НЕТ.
- Соберите достаточно доказательств того, что без этого концепта дальнейшая работа невозможна.
- Ещё раз попробуйте сказать “НЕТ”, если всё же при любом раскладе получается «да», то продолжаем…
- Предварительная детальная разработка концепта и «обсасывание идеи».
- Дизайн интерфейсов
- Ура, пишем код.
- -33. Тестируем, Рефакторинг, Тестируем, Рефаторинг, Тестируем, Рефакторинг
- Документируем
- Ищем недовольных и нанимаем киллеров
- Планируем новый релиз? Поднимаем цены?
- Запускаем!
Ну а кто сказал, что будет легко? Делать удобные и успешные вещи не так-то просто, как может показаться. Главное помнить, что «more is less», и что все вокруг идиоты.
Oct. 28, 2005 // 19:19 | Комментарии (9)