Разработка приложений Crystal Ball

Разница между пониманием того, что проблемы будут существовать, и знанием того, как их следует решать

Недавно я разговаривал с разработчиком/другом, который напомнил мне о проблеме, которую мы видели у других и сталкивались с собой во время разработки продукта, планирования и дизайна. Я бы назвал это развитием хрустального шара.

Это причудливое название для того, что, по сути, сводится к попыткам решить свои проблемы слишком рано.

Когда мы относимся к этому снисходительно, мы можем назвать это предварительнымфакторингом — просто попыткой настроиться на успех позже в будущем. И, конечно, это имеет смысл — до определенного момента. Я говорю о чрезмерном проектировании или даже о том, что вы слишком рано угадываете свой путь по дорожной карте продукта.

Я хотел бы воспользоваться этой возможностью, чтобы напомнить вам, как легко разработка программного обеспечения может сбиться с пути, особенно на раннем этапе, когда каждый ваш выбор может иметь огромные последствия в течение всего жизненного цикла продукта. На самом деле это сводится к принятию решений, которые вам не нужны, на основе информации, которой у вас еще нет. Плохая идея.

Пример времени

Когда-то я работал в стартапе с продуктом, который включал лишь несколько основных взаимодействий с пользователем. Среди них было абсолютно основное взаимодействие по созданию большого объема контента в приложении. Мы правильно определили это как главный приоритет и создали соответствующие инструменты, чтобы помочь нашим пользователям. Очередь гольф-хлопок.

В те первые дни мы также видели проблему прямо за горизонтом. Наш будущий успешный пользователь должен был иметь огромную библиотеку контента, и в конце концов ему понадобятся мощные инструменты, чтобы со всем этим работать. Это была довольно надежная ставка. Пользователи собирались попросить об этом. Это был просто вопрос времени.

Так что, будучи умными людьми, мы создаем эти инструменты. В течение нескольких посвященных недель мы выпустили лучший кросс-контентный редактор, который только можно было себе представить, который позволял пользователям вносить всевозможные изменения в несколько элементов одновременно. Это было действительно круто, и наверняка решит целую категорию пользовательских проблем в будущем.

Правда, однако, заключалась в том, что мы сильно поторопились и выстрелили себе в ногу, по крайней мере, двумя способами. Итак, скажем, мы прострелили себе полметра. Ой.

Упс 1: нашим пользователям это еще не нужно

Инженеру или дизайнеру очень приятно запускать классную функцию. Что не очень приятно, так это развертывание в рабочей среде, открытие панели показателей, чтобы посмотреть первые цифры и увидеть перекати-поле. Ничего такого. Нада.

В нашем примере наши пользователи наверстали упущенное и в конечном итоге отправились на поиски решения своих проблем с обработкой контента. Когда они это сделали, они нашли инструмент, который мы создали в ожидании момента, и научились использовать то, что мы создали для них. В основном это сработало. Я имею в виду, мы делали это раньше — мы профессионалы и действительно хорошие угадатели.

Но увы, мы упустили некоторые истины о том, что на самом деле нужно клиентам. Мы не проводили реальных исследований пользователей, потому что не могли. Не было ни одного пользователя, столкнувшегося с проблемой, которую мы могли бы задать.

Как только наши пользователи догнали нас, мы услышали о том, что созданные нами инструменты были не совсем правильными. Если бы мы изменили его, немного подправили, он мог бы быть идеальным. Мы уже высказали свое мнение о решении, все, что просили пользователи, было оформлено в этом контексте. Некоторые ключевые допущения теперь были заложены в исходное решение, которое нельзя было отменить без нажатия кнопки сброса для наших пользователей, которые потратили время на изучение созданного нами инструмента.

Упс 2: Мы все построили неправильно

Вторая проблема оказалась более механической, но не менее вредной для продукта и бизнеса. Мы создали нашу функцию с помощью лучших инструментов, которые у нас были на данный момент. Мы все еще только выходили из режима MVP и еще не нашли идеальный долгосрочный технологический стек, который позволил бы управлять программным обеспечением в долгосрочной перспективе.

Таким образом, функции были созданы с помощью кода, который было трудно поддерживать и еще труднее перерабатывать. Если бы мы подождали шесть месяцев, все эти инженерные решения можно было бы принять в лучшем контексте, и возможного рефакторинга можно было бы избежать. Как разработчик, если вы когда-либо нажимали коммит в строке кода, не веря в то, что кому-то понадобится использовать его, как только он будет развернут, что-то пошло не так.

Лекарство, которое убивает

Было бы жестоко сказать, что через шесть месяцев любое решение, которое вы придумаете сегодня, будет почти так же вредно, как и полезно. Это может быть слишком пессимистичным, но это риск и ставки, которые вы делаете. Единственное, что может быть хуже плохой устаревшей системы, — это плохая устаревшая система, которая не должна была существовать, но теперь является основой вашего бизнеса.

Важно помнить, что каждая написанная вами строка кода не только расширяет возможности вашего программного обеспечения, но и укрепляет ваши ограничения. Это постоянный компромисс, о котором всегда стоит помнить при оценке того, стоит ли начинать работу над следующим PR. Если вы откладываете написание кода, когда будете готовы напрямую решить проблему, с которой вы сейчас сталкиваетесь, у вас будет гораздо больше шансов выйти вперед в сделке.

Как ни странно, мы не становимся лучше в этом просто потому, что становимся лучшими разработчиками. Я считаю, что мы можем стать хуже. Это потому, что мы понимаем типы проблем, которые могут возникнуть. Мы были укушены этими предполагаемыми проблемами в прошлых проектах, и боль сохраняется. У нас есть стимул попытаться угадать, какие проблемы будут у нас на этот раз, и принять меры, чтобы обойти ситуацию. Как мы можем сделать нашу жизнь проще в этом случае? Как мы можем сэкономить часы, дни и недели потерянной работы, если мы просто делаем ставки на завтрашний день сегодня? Все это давление, которое нарастает по мере того, как мы продвигаемся в своем ремесле, а не то, которое отступает по мере того, как мы набираемся опыта.

Я не утверждаю, что вам нужно ждать до последнего момента, чтобы сделать выбор, который повлияет на разработку вашего продукта, или что вам нужно в совершенстве знать каждую входящую переменную. Жизнь редко бывает такой простой. Но мы все должны осознавать риски, которые мы вносим, ​​когда берем на себя обязательства, и что мы постоянно спрашиваем себя, нужно ли нам делать тот или иной выбор прямо сейчас, и ошибаться в сторону отказа от решения проблем, которых мы не делаем. на самом деле есть.

Может показаться, что я выступаю против установки «по умолчанию действовать», что я выступаю за культуру прокрастинации. Я не. Я просто говорю следующее: убедитесь, что по умолчанию вы выполняете правильное действие. Частично это означает перестать смотреть в хрустальный шар и оглядеться на то, что происходит прямо сейчас, и отдать приоритет решению тех проблем, к которым вы лучше всего подготовлены сегодня. Эти блестящие проблемы в конце концов придут к вам, готовые для того, чтобы вы могли плести свою магию. Или еще лучше, они не будут.