Почему-то очень больно и обидно, когда проект, которым ты занимался больше года вдруг начинает обрастать кучей ненужных функций — только потому, что так надо одному гипотетическому заказчику. А ведь изначально продукт планировался как публичный сервис. Больно видеть, как стройное здание буквально разваливается, распираемое аляповатыми надстройками сиюминутных функций.
Понимаю: рынок, конкуренция, сроки, клиенты. Но нет ничего хуже, чем отдавать руководство в руки пользователям и слепо следовать их прихотям. Гонка за функциональностью — это ложная гонка, выигравший ее никакого приза не получит, кроме, пожалуй, рабства перед Заказчиком. Прелесть продукта не в обилии функций, а в правильной их подгонке, сбалансированности, удобности.
Единственный выход в данной ситуации — бранчевать продукт: делать отдельную пользовательскую ветку, и, если такова политика разработки, добавлять в нее требуемые функции. А публичную ветку держать чистой и понятной. Только вот радости такой подход уже не принесет — ни пользователям, ни разработчикам, так как обе ветки постепенно превращаются в функциональных монстров, «танцующих медведей».
Понятны мотивации заказчика — он хочет получить единый продукт и использовать его (хотя требуемая ему функциональность может быть достигнута за счет интеграции с другими продуктами): хочу все и сразу и за те же деньги. Только вот результат больше походит не на пестрое бабушкино одеяло, сотканное из сотни лоскутков но теплое и красивое — а на половую тряпку из этих же лоскутков, об которую все вытирают ноги и нашивают новые лоскутки взамен прорвавшихся. Использовать все равно можно будет — только сложно и неудобно. И не в том качестве.
Источник проблемы — что ж, их минимум два: отсутствие высокоуровнего идеологического проектирования (того, что называется проектированием взаимодействия — не путать с системной архитектурой) и стремление угодить гипотетическому заказчику в данный момент. В отсутствие этих двух вещей можно только смягчить монструозность продукта, распихав функции максимально аккуратно (да-да — юзабилити — тестирование, перепроектирование).
Мораль: а нет ее. Точнее, она очевидна — прописная истина, так сказать. Наряду с системной архитектурой (а даже до нее) должен быть (обязан быть!) этап выяснения, а что же мы конкретно делаем, и какие задачи с помощью нашего продукта можно решать. Но самое главное — донести это до клиентов. Чтобы не было нужды забивать микроскопами гвозди. Ну и не смешивать публичные сервисы с сервисами для конкретного клиента.
Понимаю: рынок, конкуренция, сроки, клиенты. Но нет ничего хуже, чем отдавать руководство в руки пользователям и слепо следовать их прихотям. Гонка за функциональностью — это ложная гонка, выигравший ее никакого приза не получит, кроме, пожалуй, рабства перед Заказчиком. Прелесть продукта не в обилии функций, а в правильной их подгонке, сбалансированности, удобности.
Единственный выход в данной ситуации — бранчевать продукт: делать отдельную пользовательскую ветку, и, если такова политика разработки, добавлять в нее требуемые функции. А публичную ветку держать чистой и понятной. Только вот радости такой подход уже не принесет — ни пользователям, ни разработчикам, так как обе ветки постепенно превращаются в функциональных монстров, «танцующих медведей».
Понятны мотивации заказчика — он хочет получить единый продукт и использовать его (хотя требуемая ему функциональность может быть достигнута за счет интеграции с другими продуктами): хочу все и сразу и за те же деньги. Только вот результат больше походит не на пестрое бабушкино одеяло, сотканное из сотни лоскутков но теплое и красивое — а на половую тряпку из этих же лоскутков, об которую все вытирают ноги и нашивают новые лоскутки взамен прорвавшихся. Использовать все равно можно будет — только сложно и неудобно. И не в том качестве.
Источник проблемы — что ж, их минимум два: отсутствие высокоуровнего идеологического проектирования (того, что называется проектированием взаимодействия — не путать с системной архитектурой) и стремление угодить гипотетическому заказчику в данный момент. В отсутствие этих двух вещей можно только смягчить монструозность продукта, распихав функции максимально аккуратно (да-да — юзабилити — тестирование, перепроектирование).
Мораль: а нет ее. Точнее, она очевидна — прописная истина, так сказать. Наряду с системной архитектурой (а даже до нее) должен быть (обязан быть!) этап выяснения, а что же мы конкретно делаем, и какие задачи с помощью нашего продукта можно решать. Но самое главное — донести это до клиентов. Чтобы не было нужды забивать микроскопами гвозди. Ну и не смешивать публичные сервисы с сервисами для конкретного клиента.
