Введение
В статье рассмотрим вопрос по развитию своего IT продукта. Это может быть сайт, программа, некий сервис.
Важно сразу понять момент, что любой работающий сервис должен развиваться, изменяться под возникающие требования пользователей, окружающей среды и новые бизнес-задачи.
Не бывает успешных программ, которые один раз сделали, и они так живут годами без изменений.
Изменения будут - это аксиома. Здесь мы рассмотрим, как подходить к этим изменениям, как не угодить в капкан нарастающей сложности программы, когда любое новое изменение становится со временем все сложнее внедрить в программу.
Почему возникают сложности при сопровождении программ
Представьте сайт со сложной бизнес-логикой, где владелец продукта не особо заботится о технических моментах и просто добавляет в продукт множество различных функций.
Со временем функции начинают наслаиваться друг на друга, где-то конфликтовать, вызывать системные проблемы.
Это можно сравнить с домом, у которого потом достроили еще 2 этажа, затем решили сделать поглубже цокольный этаж (ну чтобы потолки были чуть выше), затем решили сделать открытую площадку на крыше и так далее. И конечно заказчик не думает о коммуникациях, материалах, сложности демонтажа и т.д. В итоге получится страшный монстр, где проблема может вылезти из любого угла.
Важно последовательно развивать сайт с оглядкой на общую стройность системы.
Есть такое понятие в разработке - костыль. Это плохое решение, но оно удовлетворяет первичным пожеланиям заказчика.
Чем больше костылей, тем выше риски сбоев, и тем сложнее поддерживать систему.
А это значит, что дороже - больше будет ошибок, больше времени разобраться, больше нужно привлекать опытных программистов и т.д.
В общем, заказчик, не думающий об оборотной стороне процесса разработки, ведет свой проект к тяжелому дорогому процессу сопровождения в будущем.
Как упростить процесс сопровождения и развития IT проекта
Во-первых, для любой новой фичи (возможности) необходимо учитывать сложность внедрения и ценность для потребителя. Если ценность невелика, а перепахать нужно полпроекта - эта фича вам не нужна в продукте.
В рамках развития нашей платформы Falcon Space мы исходим из того, что если нет целостного нормального решения для новой фичи, мы ее просто не внедряем. Особенно это касается ключевых компонентов (Таблица, Форма). Любое тяжелое костыльное решение порождает в будущем новые проблемы при внедрении других возможностей. Поэтому лучше вообще отказаться от каких-либо костыльных решений на уровне ядра (насколько это возможно).
В конкретном проекте на базе платформы иногда бывает требуется обойти некоторые ограничения и приходится приспосабливаться к ситуации. Но лучше сделать это в единичном случае, чем ради одного этого случая делать костыль в рамках всей платформы.
Во-вторых, необходимо сдерживать свои аппетиты. Не нужно просто пытаться следовать в ногу со временем непонятно ради чего. Если нет явного обоснования ценности новой возможности в системе, она будет вредна для нее (даже если внедрена бесплатно).
Сложность системы постепенно растет, чем больше возможностей, тем больше кода необходимо обслуживать. Это ведет к удорожанию поддержки системы.
Третье - новые фичи потенциально ослабляют систему в плане безопасности и быстродействия. Если вы подключаете, к примеру, какой-то плагин по генерации PDF - вы не можете точно сказать, есть ли в нем серьезная уязвимость. А как он будет себя вести на очень больших файлах? Мы когда-то использовали внешнюю библиотеку по формированию Excel файлов. Все было хорошо и удобно. Но когда попробовали выгружать очень большие файлы, процессор очень быстро забился.
Крамольная мысль, чем меньше технологий задействовано в решении, тем проще и надежнее это будет работать.В целом в IT индустрии популярно обратное мнение - программы усложняются до невозможности, есть мегатормозные гиганты (типа скайпа).
Если вы делаете фарш-проект, в котором переплетено все, что только можно, у вас будут повышенные риски тормозов и взлома. Очень сложно проверить все внешние компоненты (вы по сути полагаетесь на их внутреннее качество), а также на то, что при интеграции разношерстных проектов все будет работать без сбоев (хотя это совсем не факт).
Пример таких проектов - это Wordpress. Плагины wordpress создает гигантское сообщество. Проблемы начинаются, когда вы поставите много плагинов, например, 50-100. В этом случае есть вероятность, что 1-3 плагина (а на деле может гораздо больше) могут иметь лазейки для хакеров или иметь проблемы быстродействия на больших объемах. Именно поэтому сайты WP имеют повышенный риск быть взломанными.
Если хакер нашел уязвимости в одном из компонентов (а есть базы уязвимостей, так что даже придумывать не придется), то он уже может взломать множество сайтов, имеющих этот компонент в уязвимой версии или ниже.
Четвертое - у продукта должен быть фокус, все внедрения должны учитывать эту направленность IT проекта.
Пришла идея? А как это соотносится с основной идеей продукта? Если противоречит - отложите ее на 1-2 года.
Взять 1С - многие считают систему тормознутой. А ведь 1С - это скорость, любой запрос выдается за 1 секунду. т.е. компания видимо совсем забила на начальное позиционирование и сделала упор на широту возможностей.
Пятое - не торопиться с внедрением новых фич. Если фича простая и нужная - сразу внедряем и используем в реальной работе, не отходя от кассы. Если фича не такая простая, или не факт, что очень нужна - пусть полежит некоторое время.
Фича должна как пазл встать в нужное место. Если этого не получается сделать - не нужно ломать весь пазл.
Возможно фичу надо как-то по-другому представить, реорганизовать и только затем она уже органично впишется в ваш оркестр.
Типичные ошибки при развитии IT продукта
Насаждение воли
В большинстве случаев насаждение воли владельца продукта (или инвестора) без рациональных аргументов - это обычная глупость и безответственное поведение. "Хочу и точка" - такой проект в зоне риска, скорее всего ничего хорошего тут не выйдет.
Наша позиция в подобных случаях такая - сказать свое мнение, привести аргументы в пользу нашего решения, но конечное решение за владельцем продукта. Если он решил угробить проект - это его личное дело. В этом случае, на мой взгляд, правильная идея - не нужно переживать за чужой продукт больше, чем это делает сам владелец.
Бежать за аналогом без понимания
Множество стартаперов думает, что они сейчас сделают аналог какого-то гиганта, но только лучше и удобнее и все будет ок. Не работает это так.
Позаимствовать идеи из чужого проекта - это правильно и хорошо. Т.к. внешний проект уже доказал свою состоятельность. Но полностью копировать чужое нет смысла - у них другая ситуация, другие ресурсы, другая стадия развития, другая целевая аудитория. Что хорошо для крупного - возможно не нужно начинающему.
Также в большинстве случаев вы не знаете, что находится в бек офисе. Какие там возможности, как построены процессы.
Лучше все же сразу думать своей головой и критично подходить к проработке своих процессов, а не слепо копировать чужую обложку или возможности.
Делать все и сразу
В целом, это мы уже рассмотрели - чем сложнее система, тем она дороже в обслуживании, тем дольше будет запуск. Также нужно учитывать ваши ресурсы. Если вы идете с широким забралом, есть риск, что вам не хватит ресурсов на внедрение в эксплуатацию: большие сроки, увеличение бюджета, дополнительные затраты на непредвиденные проблемы по интеграции.
Делать упор на внешнюю составляющую
Обложка важна. Но важнее, чтобы пользователь получил то, что ему нужно, а не просто вызывать у него восторг вашим внешним видом.
Есть такая ERP SAP R\3. Это мировой лидер рынка ERP. Знаете, как она выглядит? Вот так:
Упор должен быть на бизнес-цели пользователя и системы. А дизайн системы - это всего лишь инструмент достижения этих целей.
Думать, что потребитель дурачок, которому нужно просто давать много плюшек, и он купит продукт.
Это подход лендингов 2010-х годов: наобещать кучу всего, давать нереально крутые условия, например, дебильные таймеры обратного отсчета. В этом случае потребитель представляется неким простаком, который во все верит, ведется на любую фигню. Конечно такие пользователи есть. Но у других пользователей такая замануха будет вызывать просто отторжение.
Гораздо лучше сделать упор на реально важные и значимые преимущества вашего продукта с упором на увеличение доверия. Не пытайтесь дешевыми уловками манипулировать покупателем. Это неприятно, сразу настраивает на негативный лад.
Иногда у нас встречаются клиенты с подобным подходом (т.е. постоянно чувствуется легкая манипуляция почти в каждом сообщении). Это все читается на раз и вызывает только желание дистанцироваться от такого общения.
Уважительно относитесь к своему покупателю (да и другим контрагентам) - это гораздо более выгодная позиция в долгосрочной перспективе.
Делать в отрыве от рынка
Именно рынок определяет жить вам или закрывать дело, и идти искать работу на более успешного конкурента. Держите нос по ветру. Есть спрос - надо туда копать.
Если вы делаете продукт чисто на своем чутье - вы увеличиваете риски продукта.
В идеале продукт нужно делать, опираясь на уже существующий реальный спрос.
Мне чужда идея создания продукта с кучей инвестиций без реальной подпитки от рынка. Именно отдача от рынка дает понимание в правильном ли направлении вы двигаетесь или нет. Иначе можно познать судьбу Ван Гога - сделать что-то большое, но так и не добиться при жизни признания (при жизни он продал меньше десяти картин). Думаю, большинство предпринимателей такое положение дел не устроит.
Затягивать с запуском
Чем дольше проект дорабатывается без запуска, тем дольше у вас нет обратной связи от потребителя. А если нет жесткой обратной связи, то можно дальше тешить себя иллюзиями об успешности своего продукта.
Необходимо как можно раньше столкнуть продукт с рынком, собрать реальную обратную связь и шлифовать, шлифовать и еще раз шлифовать.
Также долгий запуск увеличивает риски того, что проект закроется из-за недостаточного финансирования. Деньги не поступают в проект от рынка, проект дотируется либо от инвестора, либо на личные сбережения фаундера. Все это имеет временные границы. Нужно побыстрее переходить к самодостаточности проекта.
Заключение
В статье мы рассмотрели проблематику развития IT проекта, какие сложности можно встретить.
Также мы прошлись по типичным болезням владельцев продукта в плане развития IT продукта:
- Насаждение воли;
- Бежать за аналогом без понимания;
- Делать все и сразу;
- Делать упор на внешнюю составляющую;
- Думать, что потребитель дурачок, которому нужно просто давать много плюшек, и он купит продукт;
- Делать в отрыве от рынка;
- Затягивать с запуском.
Используйте подходы и принципы, указанные в статье, и это уменьшит возможные проблемы развития вашего IT продукта.
Источник: