Каждый программист, зарабатывающий на жизнь созданием программных продуктов, сталкивался или рано или поздно столкнется с разветвлением пути кода. Они могут либо довольствоваться функцией, которую они только что создали, и перейти к следующей задаче, признавая, что эту функцию можно улучшить, либо они могут продолжить разработку, чтобы сделать функцию лучше (и лучше) (и, ох! а если бы можно было...).
Идти на компромисс или не идти на компромисс?
Для меня, человека, который хочет закончить видеоигры на 100% и который вырос, получая удовольствие от того, что доедал до конца, чтобы стать частью Клуба чистой тарелки, мой инстинкт обычно заключается в том, чтобы продолжать что-то, пока оно не будет полностью сделано, до конца. лучшее из моих возможностей. Однако иногда компромиссы могут привести к лучшим результатам. У всех нас есть ограниченное время в нашей жизни (и ограниченное пространство в нашем желудке, за исключением случаев, когда мы подростки), и важно тратить его намеренно. Точно так же клиенты, платящие за создание или обслуживание программного продукта, как правило, имеют ограниченные средства для этой цели, что часто примерно соответствует ограниченному количеству часов, которые они могут заплатить вам за работу над своим проектом, и каждый клиент хочет получить максимальную отдачу от своего проекта. бак. Они захотят максимизировать ценность продукта за счет денег, которые они тратят на ваши усилия по разработке.
Таким образом, как программисты, когда мы доходим до этих стыков, мы должны рассматривать более широкую картину, чем просто эта одна функция и ее качество/надежность/простота использования/гибкость/и т.д. Какие факторы следует учитывать при принятии решения о компромиссе?
- Требования. Прежде всего, есть ли согласованный или договорной набор требований для этой функции? Если это так, вам лучше выполнить эти требования по минимуму (а в некоторых случаях и по максимуму). В разработке программного обеспечения часто рекомендуется получать одобрение клиента (или обратную связь, модификации, а затем утверждение) требований к функции, когда они планируются, до того, как начнется более дорогостоящая работа над этой функцией, чтобы вам не приходилось делать предположения. это может быть неправильно, что может привести к необходимости переделывать что-то, построенное иначе, чем видение клиента. В идеале эти соглашения и планы могут повторяться и повторно утверждаться, чтобы они включали последние поворотные моменты, которые могут потребоваться клиенту или архитектуре. Согласованные документы с требованиями, как правило, согласовывают все взгляды на продукт в письменной форме и гарантируют, что ожидания от продукта не являются постоянно меняющимися целями. В зависимости от размера вашей команды у вас может быть бизнес-аналитик, который будет собирать и документировать требования для утверждения клиентом, но даже если вы этого не сделаете, этот процесс все равно может быть очень полезным.
- Приоритет. Какое место занимает эта функция среди других функций с точки зрения того, насколько она необходима для успеха продукта или компании? Если он находится близко к началу списка, вы должны убедиться, что он очень хорошо выполняет каждую из своих целей, если рассматривать его с каждой соответствующей точки зрения. Если нет, возможно, запишите идеи по улучшению и поместите их в список невыполненных работ, чтобы рассмотреть их в будущем и перейти к реализации или улучшению функций, более важных для успеха.
- Усилия. Как вы думаете, сколько времени потребуется, чтобы добавить продуманные улучшения, и стоит ли это усилий/затрат? У вас может быть три отдельных улучшения, которые вы хотели бы сделать, но только одно или два из них обеспечат достаточную ценность, чтобы затраченные усилия окупились. В случае сомнений свяжитесь с клиентом (при необходимости по соответствующим каналам); просто будьте осторожны, не переусердствуйте и не формулируйте вопросы или утверждения таким образом, чтобы подразумевать, что дополнительные улучшения будут бесплатными, и убедитесь, что все, кому необходимо знать о решениях, проинформированы (запишите все в письменной форме после устных встреч и поделитесь этими решениями). с заинтересованными сторонами). Такого рода недоразумения или разногласия по приоритетам или недопонимание легко испортят в остальном хорошие отношения с клиентами, поэтому убедитесь, что общение осуществляется хорошо во всех отношениях.
- Полезность. Насколько важным будет рассматриваемое вами усовершенствование для успеха или счастья типичных пользователей этой функции? Могут ли они обойтись без этого, или это было бы важно или даже важно для них? Счастливые пользователи часто становятся счастливыми владельцами продукта. Такого рода темы для обсуждения, в которых вы можете выступать в защиту типичных пользователей продукта, должны находить отклик у клиента, когда функция планируется или обсуждается.
- Частота. Если вы вносите изменение, которое позволит выполнять популярную или распространенную задачу пользователей за меньшее время, кому может быть полезно это сэкономленное время? Сэкономленная минута или даже несколько сэкономленных секунд, умноженные на сотни, тысячи и более случаев, могут регулярно иметь огромное значение для людей и компаний, которые выигрывают от сэкономленного времени. С другой стороны, если функция не будет использоваться часто, ценность такого улучшения может быть низкой.
- Перспектива. Рассмотрите все соответствующие точки зрения (различные типы пользователей, различные клиентские объекты, различные партнеры и т. д.) и то, какую ценность улучшение принесет каждому из этих объектов. Ставить себя на место других и смотреть на вещи с их точки зрения — ключевое качество отличных программистов, и оно полезно для принятия подобных решений.
- MVP- Наконец, если вы сомневаетесь, просто ограничьте свою реализацию ключевыми функциональными возможностями функции и задокументируйте или запишите идеи для улучшений, которые будут рассмотрены в будущих итерациях продукта. Довольно часто лучше получить минимально жизнеспособный продукт (MVP) в руки клиента и пользователей, прежде чем создавать дополнительные навороты, особенно когда вы можете применять пользовательскую аналитику и получать отзывы пользователей. Вы можете быть удивлены отзывами пользователей и их использованием; иногда вы или ваш клиент можете считать жизненно важной функцию, которая в конечном итоге почти никогда не используется пользователями, или можете считать функцию незначительной, которую пользователи считают незаменимой. Отзывы пользователей и информация об использовании, особенно на начальном этапе развития продукта, часто являются отличными инструментами для определения того, на чем следует сосредоточить усилия дальше.
Короче говоря, постарайтесь рассмотреть продукт и компанию в целом и то, что наиболее важно для их успеха, а также различные точки зрения и ожидаемую ценность функций / улучшений и необходимые усилия, среди множества других факторов, когда решаете, идти ли на компромисс. на реализацию конкретной функции. Идти на компромисс или не идти на компромисс? Как и во многих других ситуациях в программировании, ответ таков: «это зависит». Надеюсь, теперь вы лучше подготовлены для оценки каждой ситуации, а также для общения и документирования того, что необходимо как для повышения удовлетворенности и успеха клиентов, так и для получения максимальной отдачи от времени, затрачиваемого на программирование.
