Балансировка краткосрочных и долгосрочных приоритетов
Во время моего пребывания на посту генерального директора Grooveshark до того, как я научился кодировать, меня безумно разочаровывало видеть, как разработчики придумывают эти гигантские машины Руба Голдберга для решения проблем, которые можно решить за 5 минут ручного труда. Только когда я стал тем, кто разрабатывал эти дьявольские устройства, я понял, как легко поддаться притяжению чрезмерной инженерии.
Как инженеры, мы обучены мыслить как решатели проблем. Даже самые очевидные простые задачи мы пытаемся автоматизировать. Это, в общем-то, хорошо, если бы у нас было неограниченное количество часов, чтобы построить все, что мы хотели построить. Однако в нашей ограниченной по времени реальности мы должны расставлять приоритеты, поскольку даже у самых крупных команд нет времени автоматизировать все. Что еще более важно, может начать развиваться расползание функций, и мы постепенно начинаем разбавлять наш основной продукт. Больше кода редко бывает лучше.
- Стремление быть всем для всех. Какую настоящую проблему пытается решить ваш продукт? Ни одна компания не может решить проблему каждого потребителя. Чем больше у вас продуктов, тем меньше шансов, что вы действительно преуспеете в каком-либо из них. Особенно подвержены этому влиянию крупные компании. Помните неудачную социальную сеть Google? Сосредоточьтесь на одной болевой точке и решите ее безумно хорошо. Примеры: Google Search для поиска, Asana для управления проектами, Medium для ведения блога, Flipboard для агрегации новостей, WhatsApp для международных текстовых сообщений. Вы когда-нибудь пытались понять, чего каждый из них пытается достичь?
- Сопоставление краткосрочных неудобств и долгосрочной выгоды:каждая функция, которую необходимо создать, сводится к тому, насколько болезненной является текущая проблема, и сколько времени требуется на ее автоматизацию. Это касается потребительских функций вплоть до внутренних инструментов для вашей среды разработки. Стоит ли писать сценарий для чего-то, на что у вас уходит всего 10 секунд и что происходит всего 3 раза в год? Как насчет того, что занимает у вас по минуте 5 раз в день? Таким образом, принятие решений лежит в основе разработки программного обеспечения. Обычно я пишу сценарии оболочки для вещей, которые я делаю часто или которые используются в разных проектах. Например, у меня есть скрипт, который автоматизирует команды docker push, stop, pull и up, написание которых заняло очень мало времени, и автоматизировал 5 команд docker, которые я использовал несколько раз в день. То же самое касается добавления ключей ssh на моем Mac. Но как насчет того, чтобы заставить Kubernetes автоматически масштабировать веб-сервер? Что ж, настройка занимает массу времени, и прямо сейчас небольшие ежедневные пользователи Chromatic FM получают до того, как маркетинг не делает его достаточно приоритетным для создания, независимо от того, насколько круто или весело это было бы. Круто/Весело не равно важно. Сделайте это различие, и вы хорошо проведете время.
- Сосредоточьтесь на главном — что действительно важно? Излишняя инженерия такого рода не ограничивается разработчиками. Я был виновен в этом как деловой человек. Генеральному директору очень легко увидеть несколько проблем в пространстве и попытаться решить многие из них. Сколько компаний вы видите, пытаясь стать CRM, инструментом для ведения заметок, лучшим менеджером контактов и т. д. и т. д. Лучшие продукты — это те, которые безумно хорошо выполняют небольшое количество задач. Когда Стив Джобс вернулся в Apple в 1997 году, он упразднил большую часть их продуктовых линеек в пользу всего четырех. Да, это на самом деле Apple.com в 1997 году. Сравните это с четырьмя вариантами всего несколько лет спустя.
- Может ли человек сделать это лучше? — решения, созданные пользователями: компьютеры безумно хороши в автоматизации повторяющихся задач, которые мало отличаются друг от друга. Тем не менее, некоторые вещи лучше делаются людьми. Иногда имеет смысл создавать инструменты для людей, а не пытаться создать полностью автоматизированное решение. Было бы у нас столько видео, картинок, статей или мемов, сколько есть в Интернете, если бы не были созданы инструменты, позволяющие людям выражать свои творческие способности на соответствующих платформах? Революция, созданная пользователями, началась, потому что люди создавали инструменты для других людей. Какими бы привлекательными ни были искусственный интеллект и автоматизация, в конце концов компьютеры — это инструменты, улучшающие человеческую жизнь и выражающие творческие способности человека.
- Помните о денежном потоке! Компании живут или умирают за счет своих денежных потоков. Вы можете создать самое красиво закодированное сложное приложение, но если у вас закончились деньги и вы не можете его запустить, это не имеет значения. Ключом к успешному запуску является подсчет часов разработки, которые у вас остались в вашем денежном потоке, и определение приоритетов элементов разработки на основе этих часов, которые у вас остались. Если у меня осталось 100 000 долларов наличными, а мои разработчики стоят 100 долларов в час, то до запуска у меня есть 1000 часов разработки. Сложная часть — это оценка того, сколько часов займет каждая сборка. Например, докеризация веб-сервера, вероятно, займет у меня пару дней или около 30 часов. Я всегда добавляю это в 2 раза, так как вы никогда не знаете, сколько неизвестных ошибок вы столкнетесь. То же самое с наличными. Вы никогда не хотите, чтобы вас поймали без наличных в день запуска, поэтому, например, в нашем сценарии с наличными в 100 тысяч долларов я бы фактически сказал, что 50 тысяч долларов или 500 часов осталось на часах. В компаниях на ранней стадии это самые важные 500 часов вашей жизни, поэтому расставляйте приоритеты, основываясь только на том, что вам абсолютно необходимо, чтобы пользователь решил свою проблему. Направьте свою внутреннюю Мари Кондо и будьте минималистичны. Приносит ли эта функция радость пользователю? Если не выкинуть!