Комментарии 26
Вы еще сильно занизили стоимость разработки. За 800т.р. разработать можно разве что простой одностаничник со средней логикой.
Спасибо! Мы действительно везде и всё брали по нижней планке. Но даже с этой нижней планкой выводы говорят сами за себя. В ноябре планируем выложить уже реальные стоимости и оценки, полученные от большого количества компаний в рамках разработки некоего MVP hep desk системы. Это, собственно, и будет обещанная вторая часть рассуждений о том, сколько сегодня стоит "самостоятельно разработать ПО"
Обычно те, кто хотят делать что-то свое (не все), делают это по двум причинам — специфика бизнеса (хочется максимально простой и заточенный инструмент под конкретную деятельность) и вторая — быстрая и динамичная адаптация этого инструмента к реалиям с обучением сотрудников.
В моей практике с CRM я ни разу не встречался с тем, чтобы кто-то из заказчиков считал, что разработать свое дешевле. Ну, может повезло.
А вот то, что конечный инструмент получается четко под деятельность и куда удобней вести процесс обучения и интеграции — это абсолютно точно. Особенно, если уже есть IT-отдел.
Правило простое — если ваша деятельность четенько или практически четенько укладывается в какой-либо коробочный продукт, вы уверены в его дальнейшей поддержке и возможности обучения и хотя-бы минимальной заточки под себя (если это необходимо) — то можно смело брать этот продукт и не париться.
А вот если нет — то есть куча нюансов, зная которые можно и нужно делать свое.
Да, это будет не быстро и не дешево — к этому надо быть готовым.
Но зато Вы будете хозяином своих данных, доработок и продукта — что тоже очень и очень важно. А главное — доделки будут идти в разы быстрее — а это очень важно, например, для растущего бизнеса.
И никто вам не будет руки выкручивать и цены загибать и сроки нереальные ставить.
Параллельно вы отточите свой IT отдел, который потом будет заниматься вашим сайтом, интеграцией с различными системами, используемыми на фирме, с бухгалтерией, внешним API, если он нужен и тд. В конце-концов получив достаточно прозрачную и управляемую систему вашего бизнеса и перешагнете на следующий уровень.
Естественно, надо понимать целесообразность всего этого, ибо если Вы — киоск с фруктами и не мечтаете стать рынком — то смысла всего этого делать — ноль.
Про плюсы универсальных, коробочных продуктов я уже упомянул, а минусы — их там тоже тьма — среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности, как для развертки, так и для обучения, если это не трэнд рынка (как 1С напрмер), поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Есть и третье решение — можно взять бесплатный продукт и его дотачивать командой — например так делают с SugarCRM, Mantis, различными wiki, AmoCRM, различные ITIL и не ITIL хэлпдески и тд. В этом случае существенно сокращается время на разработку, продукт не болеет детскими болезнями, но вы ограничены инфраструктурой и парадигмой продукта.
А вы с компаниями каких масштабов работаете?
Потому что, судя по всему, вы пишите о крупном бизнесе (и я в выводах написал, когда и кому имеет смысл писать свой софт). Ну а если это некрупный бизнес, то, возвращаясь к тексту, нет ничего уникального в процессах, гарантирую с 99% вероятностью. Если, конечно, уникальность бизнес-процесса, не реализуется парой дополнительных атрибутов в софте в части автоматизации. Но тогда тоже - решение для масс-маркета.
среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности
Абсолютно не согласен. О каких конкретно решениях речь? Возможно имеется в виду, что никому не подходит ни одно решение без внедрения? Тогда соглашусь, потому что, конечно, ожидать, что за условные 6000 руб/мес получишь "настроенный" продукт под бизнес процессы - наивно. Все же, минимум, пару дней на настройку потратить придется. Никто лучше вас не знает ваших процессов и как их переложить на конкретные галочки конкретного решения.
Гораздо более частая проблема малого бизнеса как раз в том, что процессы вообще не формализованы. Кажется, что всё очень просто, но как только начинаешь пытаться настроить - осознаешь, что в процессах - куча пробелов и прежде чем автоматизировать, нужно навести в них хотя бы какой-то порядок.
поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Ну в 2022 году об этом читать несколько забавно. Нормальные сервисы не пытаются удержать клиента тем, что не отдадут данные. Вообще в оферте это обычно типовое требование. Выгрузить данные можно почти всегда и везде. А если нет -- то, конечно,такие решения рассматривать к использованию категорически нельзя.
Вот тут https://searchinform.ru/research-2018/ отличное исследование про безопасность данных. Давно известно, что гораздо вероятнее ваши данные сольют сотрудники вашей компании, а не SaaS провайдер. Кому вообще нужны ваши данные? Какая в них ценность для успешного разработчика? Хотя в случае 3-го мифа мы выделили пункт, когда ваши данные и правда становятся истиной "наживой" для производителя софта. Отсюда следует всего лишь один вывод -- искать партнёра в этом смысле нужно надежного, а не того, который появился год назад из конкурентного вашему бизнесу
Для начала почему вы разделяете внедрение и софт? Одно без другого не существует. Мало того, затраты на второе могут стать выше затрат на первое.
Без формализации вообще ничего работать не будет, если не говорить ну уж про совсем крохотный бизнес.
Ничего уникального в процессах, естественно, нет, есть уникальность в том, как они выстроенны, и как ими управляют. Вот здесь внедрение обычно спотыкается, а внутренний софт - нет.
Насчёт тяжести, давайте для примера1С возьмём. Условную конфигурацию - половина функций там среднему и мелкому бизнесу не нужна, но она будет. Про "офигенный" их универсальный интерфейс я вообще молчу. Как оно ворочается - тоже известно.
Или например Фиделио для отелей - большинство отелей не Хаят - больше половины функционала им не нужно, но отключить это нельзя.
И оно тяжёлое не только из-за софта и фич - ведь надо людей этому всему обучать - ну вот скажите, где будет проще - где 3 понятных пункта или куча еще и со влрженностями.
Насчет SaaS и утечек - когда оно у вас, вы можете контролировать безопасность, когда не у вас - нет. Вероятность утечки от работников будут присутствовать что там, что там.
Я с разными бизнесом работал - от самого мелкого до холдингов.
У крупного как раз все проще, как и у сильно мелкого.
хочется максимально простой и заточенный инструмент под конкретную деятельность
По моему опыту, через день после старта проекта (даже не выкатки в тест! ,а сразу) начинается (для любой системы! пусть это будет хоть заявки на выдачу пропусков) - а давайте прикрутим согласование, а давайте прикрепим документ, а давайте уведомления на почку.. а давайте график активности..
в общем из любой системы начинают лепить СЭД, ERP, BI и бухгалтерию в одном флаконе )))
И да, почему то все уверены в своей уникальности!
Ну это потому что "программное обеспечение" или "система автоматизации". А значит автоматизировать должна уметь всё! :)
Не давать мешать все в одну кучу - это тоже одна из функций айти. Не должен хелпдеск внутри иметь телефонный справочник, а вот интегрирован быть с ним он должен. И как раз имея свою разработку это весьма просто делать и контролировать.
Во-первых, ПО требует аппаратного обеспечения: сервер, на котором оно будет работать. А значит, нужно заложить регулярные расходы на предоставление ресурсов на сервере. С учетом событий текущего года, стоимость “железа” кратно возросла и его, в принципе приобрести стало несколько более затруднительно.
Лукавите (или вводите в заблуждение).
Во время разработки важно использовать облачные ресурсы т.к. требования быстро меняются.
Т.е. покупать свое железо при разработке - плохая практика. Многие это знают.
Ну то есть, покупать облачный софт - дорого, а облачные ресурсы нет? Хм...
Снова лукавите и передергиваете.
Речь не о выборе - облачный софт или облачные ресурсы.
Речь о процессе разработки (когда решение о разработке принято) - во время разработки выгоднее использовать облачные вычислительные ресурсы, вместо покупки железа.
Ах, в этом смысле. Тогда согласен. Другое дело, что математику (читай затраты) это не сильно меняет. Ведь в статье мы заведомо посчитали только по минимальной планке затраты на разработку и не учитывали затраты на "железо" (вне зависимости от модели его использования), на других сотрудников (аналитик, дизайнер, саппортер и т.д.).
Во-вторых, разработка продукта для массового клиента это соответствующие компетенции и бизнес-процессы. Условно нельзя 10 лет заниматься обслуживанием систем кондиционирования, а завтра сделать достойное ПО, которым будут пользоваться десятки и сотни клиентов.
Бывает обратная схема: экспертные знания не требуются, а накапливаются.
Накапливается опыт и понимание процессов, которые не покрываются коробочным софтом. Реализация экспертных знаний упирается в ограничения софта на рынке и компания принимает решение о разработке для себя и продажи на рынке.
Нет иллюзий простоты разработки, но без таких компаний не появится новый софт.
Вместо демотивации на основании вашего 15-летнего опыта, полезней помочь с критерием - при каких обстоятельствах лушче коробка, а когда можно решиться на разработку и что учитывать, как проектировать.
А тут мы можем уйти в бесконечный спор про курицу и яйцо. Что важнее при разработке ПО: компетенции собственно в разработке или компетенции в "отраслевой" специфике? У меня есть на этот счет общее мнение (что не отменяет исключений) и оно не в пользу отраслевой специфике в части разработки тех самых массовых продуктов. То есть опять же, с очень глубокой экспертизой в какой-то отрасли/процессах можно разработать очень узкоспециализированный софт, без сомнения. Но и пользоваться им сможет, с большой вероятностью, только сам разработчик. А тогда снова вопросы про ROI и целесообразность.
что учитывать, как проектировать.
ну это, пожалуй, не одна и не 5 статей, а целая книга/курс собственно в которой и будет собран наш опыт. Что точно могу обещать, что в ближайшее время опубликуем пару технических статей про архитектуру и наши процессы "производства" с точки зрения контроля качества. Это от части то, о чем вы пишите. Ну а другие "части" процессов мы пробовали несколько раз описывать в старых статьях тут на Хабре в нашем блоге
Приходилось пользоваться всякими Helpdesk системами. За последние 10 лет только в одной компании сменили три системы. Я разработчик, пользуюсь не каждый день, для общения с клиентами. Каждый раз у меня вызывает боль, интерфейс, эти бесконечные выпадающие списки с миллионом вариантов без возможности поиска. Странными зависимости, неочевидным выбором.
Все эти процессы, принять такску, потом закрыть заставляют всплакнуть. Неудивительно, что возникает желание сесть и написать что то свое. Ясно, что дело нелегкое, потом придется людей содержать на непродуктивном проекте. Но вот почему то уже три раза переехали на другую систему?
Я как пользователь не вижу изменений в этих переездах. Только разработчики систем списывают друг у друга и пытаются сделать продукт покрывающий 99.9% рынка, но эти швейцарские ножы просто неповоротливы в обслуживании. Я бы с экселем справился.
Ну и NIH синдром никто не отменял. Ну плюс, если не писать что то свое, не колоться колючками поедаемого кактуса, то ничего не изобретали бы нового.
А что за системы были? Среди наших потенциальных клиентов есть те, кто сменил уже 5 систем. В таких случаях можно констатировать, что проблема на 146% не в ПО.
p.s. интерфейс это вообще притча по языцех при обсуждении любой системы, потому что очень субъективна. Но у нас, в Okdesk, кстати, нареканий к интерфейсу за 7 лет буквально по пальцам пересчитать. При этом сейчас мы все равно запустили большой внутренний проект "реновации" интерфейса
Ну мы, если и рекламировали, то, пожалуй, всех вендоров ПО :)
В конечном счете все минусы связаны с итоговыми затратами, да. Просто некоторые затраты - прямые, в виде зарплат, стоимости инфраструктуры и т.д., а некоторые - косвенные. Например, время разработки, в течение которого бизнес не получал результата его куда вписать? А зависимость от того, кто внутри это все разработал куда отнести? В случае собственной разработки эта зависимость очевидно кратно выше, чем зависимость от вендора. Если резюмировать, то для малого и среднего бизнеса, по нашему мнению, собственная разработка это один большой минус.
Я бы сказал, исключительно важное преимущество собственного софта - отсутствие лишних кнопочек в интерфейсе, лишних строк в конфигах, и вообще всего лишнего. Это, очень-очень сильно сокращает расходы рабочего времени сотрудников на использование и освоение софта.
В пересчете на деньги эта экономия перекрывает расходы на разработку именно для небольшого бизнеса, когда нужна относительно простая система.
Вам не поверят. Подумают что хотите отговорить, чтобы покупали у вас.
Например, для разработки первой минимально продаваемой версии Okdesk в далеком 2015 году у нас ушло около 5,5 человеко-месяцев. За это время мы разработали простой (а с высоты пройденного за семь лет пути можно сказать, что примитивный), удобный реестр клиентов и заявок на обслуживание.
Скажут - ну что там можно делать 5 месяцев, если работы на 2-3 дня :)
Вот серьезно - попробуйте описать что именно заняло 5 месяцев для такого простого функционала. Ведь могут подумать что ваш разработчик просто криворук и не профессионален.
Основная сложность объяснить не профессионалу почему так долго. Вот возьмите соберите требования и закиньте на фриланс, выставьте сумму заказа $500 - и куча желающих будет его сделать. А уже что там по итогу получится - никто не знает. Как можно объективно обосновать что работы на 5 месяцев, если люди соглашаются делать за $500? Вот в чем сложность и неразрешимая проблема.
Ну, конечно, вот "добавьте тут кнопочку - это пара часов" тоже известный подход :)
На самом деле нет никакого желания переубеждать, тех, кто верит, что за 500$ что-то получит. Пусть идут и получают этот свой опыт :)
p.s. дождитесь второй части поста в ноябре про стоимость разработки, там будет аналитика и реальные оценки стоимости реализации под конкретные требования ;)
У многих и правда нет представления на что уйдет 5 месяцев. Если бы как-то это суметь доходчиво донести, чтобы развеять иллюзии - было бы здорово. Вот прямо привести требования, потом привести количество задач по требованиям и примерное время. Но и тут возникнут вопросы - а обосновано ли время каждой из задач - тут не знаю как доказать - ведь задачи не выражаются только лишь в написании кода, большая часть процессов в голове - по этому тут даже запись слежки за экраном разработчика не поможет.
С 2005 года средства разработки ушли далеко вперед. Тот же https://nova.laravel.com/ позволит сделать "простую" систему учета заявок под конкрентные задачи...ну скажем за неделю в 2 руки. Не прибегая даже к фронтенду.
Самостоятельная разработка Help Desk системы. Сколько стоит? Кому и зачем это стоит начинать?