5 способов исправить энтропию программного обеспечения для стартапов
Опубликовано: 2019-01-21Стартапы тратят большую часть своих ресурсов, чтобы выйти на рынок как можно скорее
Для достижения хорошего качества требуется много времени и средств, и именно здесь страдает большинство стартапов.
Напишите и перепишите неотъемлемую часть кода и возьмите за привычку делать это по мере продвижения вперед.
«Стартап — это компания, которая не понимает: 1. Какой у нее продукт, 2. Кто ее клиенты, 3. Как зарабатывать деньги». – Дэйв МакКлюр, основатель 500 Startups
На своем пути технологический стартап имеет три рычага успеха: стоимость, скорость и качество.
К сожалению, вы можете выбрать только два одновременно. Таким образом, если вы выбираете скорость и стоимость, вам, возможно, придется пожертвовать качеством. Или, если вы выбрали скорость и качество, это, вероятно, будет стоить вам миллионы. Этот выбор двух вместо трех приводит к программной энтропии, что является случаем «сделанного нельзя отменить», как говорит Леди Макбет, или, говоря техническими терминами, вы бы сказали: «В закрытой системе, такой как технология программного обеспечения, истощающее качество продукта не может быть улучшено за определенный период времени».
Мы обсудим больше об энтропии программного обеспечения, факторах, ведущих к ней, и возможных решениях. Перед этим важно понять, что приводит к энтропии программного обеспечения.
Три рычага стартапов
Скорость
Как только вы погрузитесь в воду стартапов, вы поймете, что время — самый ограниченный ресурс из всех трех вышеупомянутых факторов. Пока стартап не начнет получать прибыль с точки зрения доходов, он никогда не будет называться компанией.
Чтобы наилучшим образом использовать начальную сумму, выпускается быстрый продукт, обычно называемый «бета-версией» и часто «приглушенного качества» (по сравнению с целевым продуктом), чтобы захватить рынок как можно раньше.
Стартапы тратят большую часть своих ресурсов, чтобы выйти на рынок как можно скорее, прилагая все усилия для достижения «скорости», которая в большинстве случаев является наиболее популярным рычагом из трех.
Расходы
Если сравнивать со временем, то стоимость ощутима во всех смыслах. Это сердцебиение стартапа.
«У стартапа есть только два приоритета: завоевать рынок и не остаться без денег». — Бен Горовиц
Чем больше баланс на вашем счету, тем дольше вы продержитесь. На начальном этапе стартапа большая часть ресурсов тратится на организацию важных активов (читай также и обязательств) для вашей организации, таких как оплата офиса, мебели, интернета, зарплаты и многое другое.
Чаще всего стартапы изо всех сил пытаются позволить себе лучших разработчиков из отрасли из-за бюджетных ограничений. Обычно топ-кодеров или старших менеджеров оставляют на потом, с намерением нанять их, когда потекут деньги.
Качественный
Хорошая работа стоит дорого, отличная работа стоит дороже, а качественная работа обходится исключительно дорого. Качество является наиболее труднодостижимым. Для достижения хорошего качества требуется много времени и средств. И именно здесь страдает большинство стартапов.
Большинство стартапов начинают с ограниченных средств и стремятся как можно скорее получить прибыль. Они стремятся быть готовыми к производству и продавать до того, как у них закончатся средства. Пока компания находится на стадии роста, предприниматель стремится быстро производить и проникать на рынок. Это позволяет этим стартапам завоевывать долю рынка и сотрудничать, опираясь на отзывы клиентов.
Большинство компаний начинают с «бета-версии», которая может создать некоторую тягу и финансировать их потребности по мере того, как они продвигаются вверх по лестнице на рынке, характеризующемся жесткой конкуренцией за их продукт.
Стартапы обычно нанимают новых разработчиков и инженеров (у немногих есть бюджет, чтобы нанять старших разработчиков), которые понимают их требования, имеют некоторое представление о развитии и могут создать продукт с наименьшим количеством ресурсов. И, без сомнения, эти разработчики имеют меньшую стоимость. Их легко формовать, и они часто могут работать в нечетные смены.
Рагхав Чандра, соучредитель/технический директор, Urbanclap, говорит
«Качество часто рассматривается как компромисс между скоростью (более длительные спринты, больше написания/тестирования кода и т. д.) и стоимостью (больше инженеров, более качественная инфраструктура и т. д.). Однако на младших этапах хорошее качество значительно повышает скорость и стоимость.
Качество имеет несколько аспектов: его архитектурный дизайн (!= инфра) играет наибольшую роль в первые дни.
Наибольшая потеря времени происходит либо при поиске ошибок (прохождение цепочки вызовов), либо при создании функций на плохо спроектированном коде — как продукты плохой сегрегации, так и обслуживание программного обеспечения».
По мере того, как компания начинает расти и получать прибыль, возникает потребность в создании стабильного продукта. Предыдущая версия созданного продукта нуждается в доработке, а коды — в переработке.
По мере появления клиентов качество вскоре становится приоритетом. Для улучшения этого качества в команду добавляется сотрудник с большим опытом и лучшим пониманием рынка. Старших разработчиков, которые обходятся дороже, нанимают для работы над существующим продуктом. Эти разработчики тратят большую часть своего времени на улучшение старых строк кода, а также быстро разрабатывают новые высококачественные функции.
Исправляя старые строки кода для разработки новых функций, большинство разработчиков изо всех сил пытаются получить желаемый результат. Но по прошествии месяцев и при всех усилиях команд по улучшению продукта качество отказывается улучшаться.
Этот фактор называется программной энтропией .
Что такое программная энтропия?
Согласно определению из Википедии, согласно второму закону термодинамики в закрытой системе (где не осуществляется ввод или вывод) беспорядок не может быть уменьшен за определенный период времени.
Этот закон кажется актуальным даже в случае программных систем; поскольку система модифицируется с течением времени, ее беспорядок имеет тенденцию только увеличиваться, а не уменьшаться при всех усилиях.
По мере того, как новые разработчики пытаются улучшить существующий фрагмент кода для повышения качества, качество продукта все дальше отходит от желаемых результатов. По мере внесения изменений для исправления существующих строк кода «энтропия» продолжает увеличиваться, что приводит к более сложному коду, который трудно исправить. Это часто приводит к разочарованию среди разработчиков и инженеров-программистов. В большинстве случаев растущие стартапы идут по сложному пути написания кода с нуля, чтобы исправить эту энтропию.
Рекомендуется для вас:
В книге «Прагматичный программист: от подмастерья к мастеру» Эндрю Хант и Дэвид Томас пишут:
«Энтропия программного обеспечения заразительна и, если ее не контролировать, становится эпидемией».
Тогда как мы можем решить эту проблему и как лучше всего нанять разработчика, который может выполнять качественную работу с меньшими затратами времени и бюджета?
Итак, должны ли стартапы сосредоточиться на стоимости, скорости или качестве?
Ананд Такер, генеральный директор и основатель Intelliphi, говорит:
«Качество системы должно достигать минимального порога, чтобы не создавать постоянной головной боли с пользовательским опытом»
Есть исключения, когда системы выполняют критические или жизненно важные операции.
На этих ранних стадиях стартапы все еще выясняют соответствие своего продукта рынку. В шумном и высококонкурентном мире, основанном на SaaS, соответствие продукта рынку решает стартап или разрушает его. Кроме того, командная динамика и лидерство в команде также находятся на стадии быстрого развития. По этой причине философия бережливого стартапа «сбой — быстро — дешево» — здравая философия. Считайте это первым вызовом энтропии.
По мере укрепления рынка продуктов стартап либо планирует качественную перестройку отдельных частей, либо полностью всю платформу. На этом этапе, продвигаясь вперед, усилия по обеспечению качества, которые приводят к улучшению качества обслуживания клиентов, влияют на рост. Хороший рост обеспечивает большее финансирование и удержание клиентов.
Лично я предпочитаю стартапы, ориентированные на продукт, и основателей стартапов. Как правило, решения и видение являются надежными, а их подход включает в себя отказоустойчивость… а их выходы и мультипликаторы намного выше (в 3–5 раз больше, чем у других типичных стартапов). Для этих типов стартапов/основателей они, скорее всего, будут уважать энтропию, однако даже их понимание более ранних стадий зависит от скорости и способности набрать критический начальный импульс».
Как стартапы могут уменьшить энтропию программного обеспечения?
Начните с минимальной технологии
Технический директор UrbanClap говорит об использовании минимальных и многоразовых технологий как о «неспособности должным образом разделить проблемы, что приводит к плохому и раздутому дизайну команды и завышенным затратам на инфраструктуру. Чтобы хорошо решить эту проблему, самый большой и главный рычаг — это культура преднамеренного архитектурного дизайна.
- сильная культура анализа дизайна с упором на модульность и преднамеренное проектирование для повторного использования
- рамки вместо руководств — с небольшими командами евангелизация лучших практик — медленный процесс. Лучше «автоматизировать» передовой опыт инженеров, создающих фреймворки и инструменты для стандартизации различных инженерных разработок».
Большинство стартапов начинаются с определенной идеи, и со временем она развивается, добавляя новые идеи, функции, а иногда превращается в совершенно новый продукт. Убедитесь, что технология А, которую вы используете в первые дни существования фонда, совместима с технологией Б, которая может объединиться с технологией С, которую вы, возможно, будете использовать в будущем.
По мере развития видения компании развивается и продукт, и на этом пути внедряются (или разрушаются) различные технологии. Убедитесь, что вы используете минимальные технологии, пока ваш продукт не станет стабильным и готовым к использованию. Оптимизируйте свой код.
Подумайте об оптимизации кода
Пишите и переписывайте неотъемлемую часть кода и возьмите за привычку делать это по мере продвижения вперед. Это поможет вам отслеживать весь код, который запускается в бэкенде глянцевого продукта.
Написание неотъемлемой части кода помогает новому сотруднику пересмотреть важные части перед отправкой нового коммита. Неотъемлемые части помогают отличить хорошую часть кода от плохой.
Перепроверьте коммиты
Вы когда-нибудь совершали код? Если нет, занесите его в свой список желаний.
Это мера усилий и приверженности разработчиков организации. Первый зафиксированный код отмечается в большинстве стартапов. Пришло время перепроверить эти коммиты. Не первый, не последний, а все.
Сделайте обязательным для одноранговых узлов пройти через все коммиты кода, чтобы гарантировать, что ни один камень не останется нетронутым для получения кода наилучшего качества.
Не забывайте об инструментах оценки при приеме на работу
Со временем вы поймете, что не можете оправдывать низкое качество кодов перед своими клиентами, обвиняя в этом время и стоимость.
Использование программного обеспечения для оценки технологий с момента вашего первого найма гарантирует, что вы будете иметь дело с сотрудниками, которые понимают ваши требования и способны добиваться результатов в условиях стресса.
Каждый неправильный найм в стартапе стоит около 18 000 долларов, от зарплаты и льгот до всех процессов, связанных с наймом, — самое главное, собеседование и оценка часов, которые проводит небольшая команда, работающая над важными проектами.
Программное обеспечение для технического найма включает в себя такие функции, как несколько языков программирования, автоматическое создание тестов и подробные отчеты о кандидатах. Обширные функции защиты от плагиата помогают командам избежать обычных хлопот «следить за новостями».
Такие задачи, как «Проект Java» (часть существующего проекта, которая предоставляется в качестве задания) могут быть разделены с кандидатами, которые работают в реальной среде кодирования, выполняя фактические коды, что дает правильное представление о работе, которую необходимо выполнить.
Делай свою домашнюю работу
И последнее, но не менее важное: сделайте домашнее задание. Подписывайтесь на лидеров мнений, читайте книги, общайтесь с людьми из той же области.
Есть много людей, которые усердно работали над улучшением энтропии программного обеспечения в своей организации.
Ананд Такер говорит:
«Знание и общение имеют решающее значение для улучшения энтропии. Мы испытывали энтропию, когда уходил член команды, обладавший глубокими знаниями в части системы.
Другой — когда определенные части программного обеспечения остаются нетронутыми в течение нескольких месяцев или лет. Обеспечьте регулярный пересмотр этих возможностей и лежащего в их основе кода/логики.
Кроме того, подумайте о том, чтобы задать тон/культуру философии развития.
Энтропия всегда будет существовать, однако сдерживать ее рост — это искусство. Как технические или исполнительные руководители, вы, возможно, уже знаете это, но разработка программного обеспечения — это дисциплинированный процесс. Хорошие члены команды гордятся своей работой. Признание этих усилий коллегами имеет большое значение». Поговорите и обсудите, чему люди научились за это время.
Вывод
Должны ли стартапы на начальном этапе сосредоточиться на качестве?
Плохое качество кода было основной причиной провала многих стартапов. Много времени, денег и усилий было потрачено на его улучшение в течение определенного периода времени. Простые комментарии типа «код плохой» для «улучшения этой строки» лучше, чем ничего не делать для улучшения кода.
Стартапы — это экономическое явление, открывающее новые горизонты и меняющее мир.
Предложения Рагхава Чандры для стартапов, страдающих от энтропии, таковы: «Для небольших команд я нашел лучший рычаг в наличии большего количества команд и сохранении организации плоской, где все работают.
Как технические руководители / менеджеры, важно подготовить команду, чтобы она «думала» лучше. Усилия, приложенные к лучшему мышлению, — вот что помогает, это приводит к меньшему количеству времени, исправляя вещи позже.
А мозговой штурм и глубокое обдумывание перед внедрением — это не компромисс по времени или стоимости — это действительно самый дешевый способ построить качество на системном уровне».
Пришло время позаботиться об энтропии и нанять лучших разработчиков, которые помогут снизить ее из продуктов, которые мы создаем.