Нужна ли новая фича в проекте или нет?
Введение
"А давайте внедрим эту крутую штуку?", "Нам еще много что нужно внедрить чтобы было как у Битрикс..". За каждой хотелкой стоят затраты времени, денег, человеческих ресурсов. Мы можем внедрять что-то очень важное для пользователей, а можем менять цвет кнопок и долго обсуждать иконки.
Хотите быстро и много заработать? Есть очень простой способ - откажитесь от всех ненужных (а иногда и вредных для проекта) новых возможностей в продукте. И сразу можно считать, что вы заработали некую сумму. Ведь сэкономленный рубль = заработанный рубль.
В статье мы разберем вопросы, которые надо себе задать перед тем, как давать одобрение на внедрение очередной фичи в проект.
Здесь я исхожу, что вам нужно реально сделать хороший востребованный веб-проект, а не отчитаться перед руководством/инвесторами и пустить пыль в глаза количеством новых фич в проекте.
Она улучшает жизнь пользователя?
Есть ли хотя бы одна категория пользователей, которым станет лучше после внедрения новой возможности? Это реальный сдвиг для них или они даже не заметят этого улучшения?
Ориентация на пользователя решает, т.к. в конечном счете именно пользовательский опыт определяет успех веб-проекта.
Можно ли оценить сколько денег принесет внедрение новой возможности?
Это не всегда возможно связать напрямую каждую новую возможность с деньгами. Но если ваша фича напрямую влияет на выручку - тут двух мнений быть не может.
Если же совсем сложно построить убедительную логическую цепочку от фичи к деньгами, то вероятно надо отложить это внедрение до лучших времен.
Насколько это соотносится с существующими возможностями?
У проекта должен быть свой фокус, свое видение. Если его нет, то он в итоге станет этаким комбайном всего и вся. Необходимо делать так, чтобы все новые возможности как минимум не противоречили существующему функционалу в системе.
Каждое новое внедрение должно укладываться в стратегическую канву.
Насколько сложно внедрить дополнительную возможность программы?
Вопрос затраты ресурсов. Если это очень сложно будет внедрить, то стоимость внедрения и последующей поддержки может быть очень большой.
Подводные камни - это костыли, т.е. внедрить можно, но через кривые решения. Костыли приводят к усложнению поддержки проекта. Это как небольшой камень в ботинке - вроде бы идти можно, но ногу натирает. В идеале взять как принцип вопрос - никаких костылей. Если фича требует костылей - значит ее время не пришло и следует это отложить до лучших времен.
Далеко не каждый заказчик это понимает и принимает. "Прорвемся", "ну как-нибудь сделайте, а там видно будет" + все эти истории про Сталина, и как он из ученых выжимал чудо военной техники и т.д. А программисты в основной своей массе - неконфликтные люди. Им проще поставить костыль в системе, нежели доказывать заказчику альфа-самцу, что это путь не туда.
И все бы ничего, но костыль - стадное животное. Если у вас появляется 2-3 костыля в проекте, это приводит к 2 эффектам:
- Последующие решения будут приниматься уже на основе этого неоптимального костыльного решения (т.е. его просто надо будет объективно учитывать)
- Снижается внутренняя чистота проекта. А если в одном месте бардак, то почему в другом будет чисто? Снижается планка что приемлемо, а что нет для проекта.
В итоге кардинально ухудшается качество проекта:
- Сложнее поддерживать проекта из-за нюансов костылей.
- Сложнее разбираться с проектом для новичков.
- Неожиданные эффекты при правках (поправили в одном месте, и это неожиданно сказалось на другом).
Общий вывод - избегайте сложных решений, которые требуют костылей.
Какие горизонты открывает эта возможность?
В идеале в проекте в первую очередь надо развивать такие возможности, которые открывают новые горизонты.
К примеру, внедрили технологию PWA - и вот у вас уже есть практически готовое мобильное приложение (аналог). И можно дальше углубить удобство под мобильные.
Или пример в нашей платформе - проработали свой механизм лендингов, и практически теперь любые фронт страницы мы делаем на базе этого механизма. Далее мы дорабатываем этот механизм для упрощения редактирования разметки, создали большой набор типовых блоков, внедрили новые элементы навигации по ленду и т.д. Новая фича кардинально повлияла на развитие функционала проекта.
Может просто отложить внедрение?
Большинство возможностей системы потом не нужно будет. Сейчас это кажется хорошей идеей, а завтра возможно вы об этой идее и не вспомните. Мысль отложить особенно хороша, когда поджимают ресурсы. Чем больше вы отложили несущественных моментов, тем больше ресурсов вы можете направить на существенные возможности вашего проекта.
Вторая похожая идея - откладывайте фичу, если нет подходящего сильного решения, которое все ставит на свое место. Если пазл не складывается, возможно просто нужно это отложить до более подходящего момента.
При разработке платформы у меня было множество моментов, когда хочется внедрить возможность, но не встает она идеально. Если такое происходит, то я просто откладываю эту фичу до лучших времен. Обычно рано или поздно приходит понимание, как можно это внедрить в систему без потери целостности. С ростом возможностей платформы какие-то старые, давние идеи вновь становятся актуальными и их мы внедряем уже на базе текущего опыта.
Заключение
Подобный подход к новым фичам позволит пропускать в веб-проект только действительно стоящие идеи. Чем меньше ненужных внедрений будет в проекте, тем лучше будет реализована ключевая часть проекта, создающая реальную ценность для потребителя.
Источник: