Привет, Хабр! Ежедневно, по роду деятельности, мы общаемся с десятками компаний, в основном средний и малый бизнес, на тему автоматизации процессов техподдержки и выездного сервиса. Еще 5 лет назад, нас не очень удивляло массовое желание “изобрести велосипед”, то есть написать собственную CRM, Helpdesk, систему складского учета и т.д. Но за последние 2,5 года (COVID-19 + события текущего года) ситуация на рынке в общем, да и рынке разработки в частности, кардинально поменялась.
Однако, у многих компаний, в первую очередь средний и малый бизнес, принятие новой реальности так и не произошло. В этой статье мы наглядно, с цифрами и большим пониманием дела (занимаемся разработкой ПО 15+ лет) попробуем протереть запотевшие очки. А еще, чуть позже, обязательно сделаем вторую часть, где представим результаты интереснейшего исследования рынка. Ну и, конечно, в конце есть инсайд про пару helpdesk систем на рынке. Поехали!
Во время общения с лидами (теми, кто зарегистрировался для тестирования нашей helpdesk системы) мы и в 2022-м году слышим возражения как от представителей малого, так и крупного бизнеса, что они приняли решение разработать собственную систему автоматизации. Часто это просто ответ менеджеру, чтобы отвязался, а реальная причина в том, что потенциальный клиент решил оставить все как есть.
Тем не менее многие компании и их руководители действительно до сих пор верят в то, что самостоятельная разработка программы «под себя» сегодня — это наиболее эффективный способ решения бизнес-задач. Почему в 2022-м году всё совсем наоборот? Почему собственная разработка сегодня — самый неэффективный, а в большинстве случаев неосуществимый путь, и почему все-таки стоит выбирать готовое и зарекомендовавшее себя на рынке решение?
Плюсы собственной разработки ПО
Чем чаще всего компания объясняет эффективность самостоятельной разработки?
По нашей статистике (более 20 000 компаний и, как следствие, диалогов за последние годы) это, в первую очередь дешевизна: один раз заплатишь и больше не придется все время платить абонентскую плату (в случае облачной подписки) или за техподдержку ИТ-решения.
Во вторую очередь, довольно часто мы слышим тезис об уникальных бизнес-процессах, для автоматизации которых на рынке попросту нужного программного обеспечения.
И, пожалуй, самое амбициозное, но не такое уж и редкое объяснение “эффективности” самостоятельной разработки заключается в том, что клиент планирует вывести разработанную систему на рынок, тем самым окупив затраты на ее разработку, и даже заработать что-то сверху. Поистине наполеоновские планы!
Иными словами, у желания разрабатывать ПО самостоятельно есть три основных объяснения:
Вера в экономию денег или “самостоятельно - дешевле”.
Вера в уникальность собственных бизнес-процессов.
Вера в простоту создания конкурентоспособного ИТ-решения и вывода его на рынок.
Все они — большие заблуждения и мифы. Почему? Давайте разбираться по порядку!
Миф №1. Самостоятельно — дешевле. Реальный расчет стоимости разработки и поддержки
Для простоты расчетов давайте исходить из того, что для разработки ПО нужен только программист, а сбор и формулирование требований, разработка макетов интерфейсов и тестирование ничего не стоит. В реальной жизни, конечно, все эти активности необходимы и серьезно увеличивают расходную часть бюджета.
По данным Хабра (на основе анализа — 12 000 зарплат айтишников в первом полугодии 2022 года), средняя зарплата разработчика ПО, составляет чуть более 150 000 рублей в месяц. Возьмем эту сумму без отпускных, больничных, накладных расходов на офис и обязательных взносов в фонды. Будем считать, что один программист обходится в 150 000 рублей в месяц.
Сколько времени программисту нужно для разработки первой рабочей версии ПО? Например, для разработки первой минимально продаваемой версии Okdesk в далеком 2015 году у нас ушло около 5,5 человеко-месяцев. За это время мы разработали простой (а с высоты пройденного за семь лет пути можно сказать, что примитивный), удобный реестр клиентов и заявок на обслуживание. Переводя в текущие деньги, более 800 000 рублей потребовалось для создания самой простой версии help desk системы, за которую клиенты были готовы платить хоть какие-то деньги.
Давайте сравним это со стоимостью годовой подписки на SaaS-версию Okdesk для автоматизации работы 20 сервисных инженеров. Годовая стоимость на сегодня (октябрь 2022 года) составит около 300 000 рублей.
При этом речь идет о широкофункциональной и постоянно развивающейся системе, о поддержке и работоспособности которой даже не нужно думать. И это не минимальная версия, а высокофункциональная: за семь лет к моменту написания этих строк на внутреннем трекере стояла отметка в 57 016 человеко-часов (или около 350 человеко-месяцев). Система при этом продолжает активно развиваться: на 2022 год мы забюджетировали более 150 человеко-месяцев на развитие ее функциональности.
Иными словами, вложив разом 800 000 рублей в самостоятельную разработку, компания получит систему с минимальной функциональностью в противовес трем годам использования полнофункционального ИТ-решения, которое все это время будет развивать сторонний разработчик исходя из потребностей бизнеса. Отметим, что за указанную сумму ни о каких мобильных приложениях речи, конечно, не идет.
Конечно, бывают ситуации, когда разработчик все равно простаивает, и хочется загрузить его хоть чем-то. Но, кажется, что сегодня, осенью 2022 года, если в компании есть разработчик, который простаивает несколько человеко-месяцев, то у компании и сотрудника серьезные проблемы с планированием, да и мотивацией в принципе.
Расходы на предоставление ресурсов на сервере и поддержка ПО
Казалось бы, уже достаточно аргументов, чтобы не считать, что самостоятельная разработка дешевле. Но давайте продолжим "обсчитывать" этот миф.
Стоимостью разработки первой версии — расходы не ограничиваются, даже не смотря на все наши допущения.
Во-первых, ПО требует аппаратного обеспечения: сервер, на котором оно будет работать. А значит, нужно заложить регулярные расходы на предоставление ресурсов на сервере. С учетом событий текущего года, стоимость “железа” кратно возросла и его, в принципе приобрести стало несколько более затруднительно. Во-вторых, ПО, установленное на сервере, требует регулярного обслуживания: настройки бэкапов для сохранности данных, обновления системного программного обеспечения сервера и т.д.
Все это требует регулярного привлечения ИТ-специалистов, а значит и денег. Причем даже минимальный расход на обслуживание в четыре часа в месяц выльется в годовом исчислении в 50 000 рублей при наличии штатного специалиста, а если привлекать аутсорсинговую компанию — минимум в два раза больше. При покупке облачного сервиса все это уже заложено в стоимость.
И самое важное — расходы на дальнейшую поддержку и развитие разработанного ПО. Систем без багов, как известно, не бывает (Okdesk — исключение, спросите у 800+ наших клиентов ;)), это нормально. Важно, чтобы найденные ошибки быстро исправлялись. А значит, необходимо тратить деньги и на эту часть: держать постоянный контакт с командой или сотрудником, который разработал первую версию программы. Либо быть готовым искать и привлекать новых людей или одного эксперта, который будет разбираться в чужом программном коде при необходимости исправить ошибку. В этом случае готовьтесь нести доп.расходы.
Представим, что в системе, разработанной под себя, не будет ошибок или они будут некритичными. Однако написать минимально функциональную систему и навсегда закрыть свои потребности в автоматизации нельзя: система должна развиваться. Кто будет разрабатывать новую функциональность, а интеграции с 1С, которую также приходится постоянно адаптировать или дорабатывать после выхода обновлений?
В итоге мы получаем, что минимальная версия системы на 20 человек окупается за три года, но только если не считать расходы на ее поддержку и полностью отказаться от развития, что в реальной жизни невозможно. Если же заложить деньги на поддержку и развитие, то самостоятельная разработка системы уведет в глубокий минус и никогда не окупится.
В лидирующих облачных сервисах (неважно, CRM, Help desk, BI или других) в стоимость включена функциональность, реализованная и доведенная до близкого к идеальному основанная на опыте сотен и тысяч аналогичных компаний, а также поддержка и активное развитие.
Миф №2. “У нас уникальные бизнес-процессы”
Второй аргумент, который хочется разобрать, — это мнение о том, что в компании существуют уникальные бизнес-процессы, поэтому их нельзя автоматизировать существующими на рынке типовыми ИТ-решениями.
Можно согласиться с тем, что у компаний из инновационных отраслей или с уникальными масштабами есть уникальные потребности. Из-за этого они вынуждены разрабатывать собственные ИТ-системы. Именно вынуждены, поскольку они бы никогда не выбрали такой путь, если бы на рынке было готовое решение, которое им подошло. Но в чем уникальность процессов в компаниях с масштабами микро, малого и среднего бизнеса из классических отраслей с типовыми бизнес-моделями? По нашему опыту (напомним, что это общение за 7 лет более чем с 20 000+ компаний), даже ошибки в организации бизнес-процессов у подобных компаний типовые, не говоря о том, что процессы тоже, за исключением мелких деталей, одинаковые..
Типовая компания из малого и среднего бизнеса работает по классической бизнес-модели. А количество конкурентов в стране измеряется хотя бы сотнями. Так, в отрасли обслуживания телематического оборудования и спутникового мониторинга транспорта более 500 компаний, а в отрасли, например, компаний, внедряющих 1С — несколько тысяч. Да, компетенции могут разниться. Да, в последнее время на рынках появляются компании с уникальными предложениями, которые фокусируются на конкретном, узком сегменте или на решении конкретных и узкоспециализированных задач. Но в подавляющем большинстве компании отличаются только названием.
Получается, уникальных и одновременно эффективных бизнес-процессов не может быть ни у конкретной компании, ни у ее конкурентов. Почему? Потому что как только кто-то находит более эффективный вариант организации бизнеса, рано или поздно этот способ распространится по рынку и будет применен другими компаниями. Даже если владелец бизнеса не захочет делиться этими ноу-хау с сообществом, оно распространится через сотрудников, которые очень часто меняют работы и переходят к конкурентам. Хорошее быстро приживается и копируется.
Что может быть уникального у типового бизнеса кроме компетенций? Например, высокое качество техподдержки и соответствующие процессы (большинство их просто не видит смысла выстраивать). А еще могут быть уникальные, но неэффективные бизнес-процессы. Однако стоит ли их сохранять да еще и автоматизировать?
Очевидно, что дешевле взять готовое ИТ-решение от компаний, которые работают с сотнями или тысячами других представителей бизнеса. Такие разработчики уже агрегировали в своем ПО лучшие отраслевые практики сотен и тысяч компаний. В случае системы автоматизации техподдержки, сервиса и выездного обслуживания это, конечно, Okdesk.
Миф №3. Выведем на рынок свой продукт, отобьем все расходы и заработаем сверху
В завершении разберем заблуждение, которое в качестве аргумента к решению о собственной разработке использует перспективу дальнейшей коммерциализации системы на открытом рынке. Простыми словами план выглядит так:
Сейчас вложимся и разработаем решение для себя
-
Выведем решение на рынок и будем продавать его другим компаниям
Опциональный пункт. В идеале — продавать своим конкурентам и получить доступ к их данным.
Затея даже могла бы стать успешной, если бы ИТ-продукт был невероятно востребованным: все бы только и ждали его появления на рынке, при этом конкурентов у него не было. В реальной жизни так не бывает. Как минимум один конкурент уже есть — это разработчик, чье готовое ИТ-решение компания не хочет покупать, планируя разработать свое собственное. Наверняка у этого разработчика тоже есть конкуренты. Скорее всего, в рамках поиска ИТ-решения для своих задач компания уже успела с ними ознакомиться.
Суровая реальность выглядеть несколько сложнее.
Во-первых, продукт для себя и продукт для массового потребителя это совершенно разные даже с архитектурной точки зрения ИТ-решения.
Во-вторых, разработка продукта для массового клиента это соответствующие компетенции и бизнес-процессы. Условно нельзя 10 лет заниматься обслуживанием систем кондиционирования, а завтра сделать достойное ПО, которым будут пользоваться десятки и сотни клиентов.
К тому же просто выложить ИТ-продукт в открытый доступ и повесить ценник — недостаточно для того, чтобы он начал продаваться. Нужно будет вложить деньги в разработку первой версии, потом в маркетинг. Еще вложить время и деньги в получение первых клиентов. При этом они даже близко не окупят затрат на первую версию системы. И все это только для того, чтобы получить первую обратную связь от рынка, сформулировать план развития ИТ-продукта и продолжить вкладывать деньги в бизнес.
Иными словами, самостоятельная разработка ИТ-продукта с последующим выводом на рынок не может быть побочным направлением деятельности, а должна стать полноценным бизнесом. И подходы к этому должны быть соответствующие: компетенции, изучение спроса, формирование маркетинговой стратегии, плана развития продукта и бюджет, который в несколько раз больше, чем израсходованный на разработку первой версии ИТ-продукта, которую компания планировала выводить на рынок. Если сесть и скрупулезно прикинуть все расходы на вывод продукта на рынок, окажется, что затея в рамках «побочных активностей» так себе.
Обещанный инсайд
Сегодня на рынке helpdesk систем (его мы знаем лучше других) есть, как минимум, 3 решения, которые были запущены именно по описанной модели. Разработчики одного из них даже активно вели на Хабре блог. Отметим, что на момент написания статьи по официальным и доступным данным обе компании сильно убыточны и ни о каком “отбили затраты” речи не идет даже в перспективе ближайших 2-3 лет.
Вместо выводов
Самостоятельная разработка ПО под себя — это удел:
Либо крупных по масштабам компаний с соответствующими бюджетами на ошибки.
Либо организаций с уникальной бизнес-моделью.
Либо тех, кто обладает компетенциями по разработке массового продукта.
В первых 2 случаях разработка ИТ-решения для себя самостоятельно выглядит целесообразной, так как на рынке действительно нет продукта, который удовлетворяет их уникальные требования.
Компаниям малого и среднего бизнеса нет никакой нужды в самостоятельной разработке ИТ-решений. А все кажущиеся выгоды на самом деле — самообман или заблуждение.
Мы в Okdesk из квартала в квартал видим нарастающий интерес со стороны среднего и малого бизнеса к цифровизации — системам для автоматизации техподдержки, сервиса и выездного обслуживания. И этому не мешают даже происходящие вокруг события.
Таким компаниям выгоднее выбирать готовые и активно развивающиеся ИТ-решения по цене всего от 6000 руб/мес, которые уже успели помимо прочего заработать репутацию на рынке. В этих системах уже заложена отраслевая специфика и лучшие практики организации бизнеса, а также сотни тысяч часов опыта.
За доступные для малого и среднего бизнеса деньги компания получает готовое ИТ-решение для всех текущих и перспективных задач по автоматизации своего бизнеса. А саму систему разработчик продолжит развивать, исходя из обратной связи со своими клиентами.
Комментарии (25)
ionicman
18.10.2022 14:13+4Не все так однозначно.
Обычно те, кто хотят делать что-то свое (не все), делают это по двум причинам — специфика бизнеса (хочется максимально простой и заточенный инструмент под конкретную деятельность) и вторая — быстрая и динамичная адаптация этого инструмента к реалиям с обучением сотрудников.
В моей практике с CRM я ни разу не встречался с тем, чтобы кто-то из заказчиков считал, что разработать свое дешевле. Ну, может повезло.
А вот то, что конечный инструмент получается четко под деятельность и куда удобней вести процесс обучения и интеграции — это абсолютно точно. Особенно, если уже есть IT-отдел.
Правило простое — если ваша деятельность четенько или практически четенько укладывается в какой-либо коробочный продукт, вы уверены в его дальнейшей поддержке и возможности обучения и хотя-бы минимальной заточки под себя (если это необходимо) — то можно смело брать этот продукт и не париться.
А вот если нет — то есть куча нюансов, зная которые можно и нужно делать свое.
Да, это будет не быстро и не дешево — к этому надо быть готовым.
Но зато Вы будете хозяином своих данных, доработок и продукта — что тоже очень и очень важно. А главное — доделки будут идти в разы быстрее — а это очень важно, например, для растущего бизнеса.
И никто вам не будет руки выкручивать и цены загибать и сроки нереальные ставить.
Параллельно вы отточите свой IT отдел, который потом будет заниматься вашим сайтом, интеграцией с различными системами, используемыми на фирме, с бухгалтерией, внешним API, если он нужен и тд. В конце-концов получив достаточно прозрачную и управляемую систему вашего бизнеса и перешагнете на следующий уровень.
Естественно, надо понимать целесообразность всего этого, ибо если Вы — киоск с фруктами и не мечтаете стать рынком — то смысла всего этого делать — ноль.
Про плюсы универсальных, коробочных продуктов я уже упомянул, а минусы — их там тоже тьма — среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности, как для развертки, так и для обучения, если это не трэнд рынка (как 1С напрмер), поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Есть и третье решение — можно взять бесплатный продукт и его дотачивать командой — например так делают с SugarCRM, Mantis, различными wiki, AmoCRM, различные ITIL и не ITIL хэлпдески и тд. В этом случае существенно сокращается время на разработку, продукт не болеет детскими болезнями, но вы ограничены инфраструктурой и парадигмой продукта.
OkHelpDesk Автор
18.10.2022 15:14+2А вы с компаниями каких масштабов работаете?
Потому что, судя по всему, вы пишите о крупном бизнесе (и я в выводах написал, когда и кому имеет смысл писать свой софт). Ну а если это некрупный бизнес, то, возвращаясь к тексту, нет ничего уникального в процессах, гарантирую с 99% вероятностью. Если, конечно, уникальность бизнес-процесса, не реализуется парой дополнительных атрибутов в софте в части автоматизации. Но тогда тоже - решение для масс-маркета.
среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности
Абсолютно не согласен. О каких конкретно решениях речь? Возможно имеется в виду, что никому не подходит ни одно решение без внедрения? Тогда соглашусь, потому что, конечно, ожидать, что за условные 6000 руб/мес получишь "настроенный" продукт под бизнес процессы - наивно. Все же, минимум, пару дней на настройку потратить придется. Никто лучше вас не знает ваших процессов и как их переложить на конкретные галочки конкретного решения.
Гораздо более частая проблема малого бизнеса как раз в том, что процессы вообще не формализованы. Кажется, что всё очень просто, но как только начинаешь пытаться настроить - осознаешь, что в процессах - куча пробелов и прежде чем автоматизировать, нужно навести в них хотя бы какой-то порядок.поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Ну в 2022 году об этом читать несколько забавно. Нормальные сервисы не пытаются удержать клиента тем, что не отдадут данные. Вообще в оферте это обычно типовое требование. Выгрузить данные можно почти всегда и везде. А если нет -- то, конечно,такие решения рассматривать к использованию категорически нельзя.
Вот тут https://searchinform.ru/research-2018/ отличное исследование про безопасность данных. Давно известно, что гораздо вероятнее ваши данные сольют сотрудники вашей компании, а не SaaS провайдер. Кому вообще нужны ваши данные? Какая в них ценность для успешного разработчика? Хотя в случае 3-го мифа мы выделили пункт, когда ваши данные и правда становятся истиной "наживой" для производителя софта. Отсюда следует всего лишь один вывод -- искать партнёра в этом смысле нужно надежного, а не того, который появился год назад из конкурентного вашему бизнесу
ionicman
18.10.2022 18:33+1Для начала почему вы разделяете внедрение и софт? Одно без другого не существует. Мало того, затраты на второе могут стать выше затрат на первое.
Без формализации вообще ничего работать не будет, если не говорить ну уж про совсем крохотный бизнес.
Ничего уникального в процессах, естественно, нет, есть уникальность в том, как они выстроенны, и как ими управляют. Вот здесь внедрение обычно спотыкается, а внутренний софт - нет.
Насчёт тяжести, давайте для примера1С возьмём. Условную конфигурацию - половина функций там среднему и мелкому бизнесу не нужна, но она будет. Про "офигенный" их универсальный интерфейс я вообще молчу. Как оно ворочается - тоже известно.
Или например Фиделио для отелей - большинство отелей не Хаят - больше половины функционала им не нужно, но отключить это нельзя.
И оно тяжёлое не только из-за софта и фич - ведь надо людей этому всему обучать - ну вот скажите, где будет проще - где 3 понятных пункта или куча еще и со влрженностями.
Насчет SaaS и утечек - когда оно у вас, вы можете контролировать безопасность, когда не у вас - нет. Вероятность утечки от работников будут присутствовать что там, что там.
Я с разными бизнесом работал - от самого мелкого до холдингов.
У крупного как раз все проще, как и у сильно мелкого.
sergeyns
18.10.2022 16:50хочется максимально простой и заточенный инструмент под конкретную деятельность
По моему опыту, через день после старта проекта (даже не выкатки в тест! ,а сразу) начинается (для любой системы! пусть это будет хоть заявки на выдачу пропусков) - а давайте прикрутим согласование, а давайте прикрепим документ, а давайте уведомления на почку.. а давайте график активности..
в общем из любой системы начинают лепить СЭД, ERP, BI и бухгалтерию в одном флаконе )))
И да, почему то все уверены в своей уникальности!
OkHelpDesk Автор
18.10.2022 16:58+1Ну это потому что "программное обеспечение" или "система автоматизации". А значит автоматизировать должна уметь всё! :)
ionicman
18.10.2022 18:37+1Не давать мешать все в одну кучу - это тоже одна из функций айти. Не должен хелпдеск внутри иметь телефонный справочник, а вот интегрирован быть с ним он должен. И как раз имея свою разработку это весьма просто делать и контролировать.
OkHelpDesk Автор
19.10.2022 09:59Ну интеграция с IP АТС (по API или готовая) это вообще, кажется, дефолтная функция любой "уважающей себя" help desk системы
Mikhail1972
18.10.2022 15:14Все зависит от разработчиков. Некоторые самостоятельно ЯП разрабатывают и все работает. Недавно смотрел видео подключение из 1с к http ресурсу , все красиво , но код который описан 3 функциями , реализован на 1с 20ю функциями, ну это перебор. А когда увидел разработку по Oracle, когда люди берут миллионы строк кода и просто лепят поверх свои, вообще не представляя , что многое не нужно. Вообщем все это спорно, миллилны строк кода, не всегда нужны, да и безопасность на небезопасной sql и os тоже большой вопрос кого она защитит.
vagon333
18.10.2022 16:11+1Во-первых, ПО требует аппаратного обеспечения: сервер, на котором оно будет работать. А значит, нужно заложить регулярные расходы на предоставление ресурсов на сервере. С учетом событий текущего года, стоимость “железа” кратно возросла и его, в принципе приобрести стало несколько более затруднительно.
Лукавите (или вводите в заблуждение).
Во время разработки важно использовать облачные ресурсы т.к. требования быстро меняются.
Т.е. покупать свое железо при разработке - плохая практика. Многие это знают.OkHelpDesk Автор
18.10.2022 16:15Ну то есть, покупать облачный софт - дорого, а облачные ресурсы нет? Хм...
vagon333
18.10.2022 16:26Снова лукавите и передергиваете.
Речь не о выборе - облачный софт или облачные ресурсы.
Речь о процессе разработки (когда решение о разработке принято) - во время разработки выгоднее использовать облачные вычислительные ресурсы, вместо покупки железа.OkHelpDesk Автор
18.10.2022 16:34Ах, в этом смысле. Тогда согласен. Другое дело, что математику (читай затраты) это не сильно меняет. Ведь в статье мы заведомо посчитали только по минимальной планке затраты на разработку и не учитывали затраты на "железо" (вне зависимости от модели его использования), на других сотрудников (аналитик, дизайнер, саппортер и т.д.).
vagon333
18.10.2022 16:22Во-вторых, разработка продукта для массового клиента это соответствующие компетенции и бизнес-процессы. Условно нельзя 10 лет заниматься обслуживанием систем кондиционирования, а завтра сделать достойное ПО, которым будут пользоваться десятки и сотни клиентов.
Бывает обратная схема: экспертные знания не требуются, а накапливаются.
Накапливается опыт и понимание процессов, которые не покрываются коробочным софтом. Реализация экспертных знаний упирается в ограничения софта на рынке и компания принимает решение о разработке для себя и продажи на рынке.
Нет иллюзий простоты разработки, но без таких компаний не появится новый софт.
Вместо демотивации на основании вашего 15-летнего опыта, полезней помочь с критерием - при каких обстоятельствах лушче коробка, а когда можно решиться на разработку и что учитывать, как проектировать.OkHelpDesk Автор
18.10.2022 16:41+2А тут мы можем уйти в бесконечный спор про курицу и яйцо. Что важнее при разработке ПО: компетенции собственно в разработке или компетенции в "отраслевой" специфике? У меня есть на этот счет общее мнение (что не отменяет исключений) и оно не в пользу отраслевой специфике в части разработки тех самых массовых продуктов. То есть опять же, с очень глубокой экспертизой в какой-то отрасли/процессах можно разработать очень узкоспециализированный софт, без сомнения. Но и пользоваться им сможет, с большой вероятностью, только сам разработчик. А тогда снова вопросы про ROI и целесообразность.
что учитывать, как проектировать.
ну это, пожалуй, не одна и не 5 статей, а целая книга/курс собственно в которой и будет собран наш опыт. Что точно могу обещать, что в ближайшее время опубликуем пару технических статей про архитектуру и наши процессы "производства" с точки зрения контроля качества. Это от части то, о чем вы пишите. Ну а другие "части" процессов мы пробовали несколько раз описывать в старых статьях тут на Хабре в нашем блоге
gsaw
18.10.2022 16:32+4Приходилось пользоваться всякими Helpdesk системами. За последние 10 лет только в одной компании сменили три системы. Я разработчик, пользуюсь не каждый день, для общения с клиентами. Каждый раз у меня вызывает боль, интерфейс, эти бесконечные выпадающие списки с миллионом вариантов без возможности поиска. Странными зависимости, неочевидным выбором.
Все эти процессы, принять такску, потом закрыть заставляют всплакнуть. Неудивительно, что возникает желание сесть и написать что то свое. Ясно, что дело нелегкое, потом придется людей содержать на непродуктивном проекте. Но вот почему то уже три раза переехали на другую систему?
Я как пользователь не вижу изменений в этих переездах. Только разработчики систем списывают друг у друга и пытаются сделать продукт покрывающий 99.9% рынка, но эти швейцарские ножы просто неповоротливы в обслуживании. Я бы с экселем справился.
Ну и NIH синдром никто не отменял. Ну плюс, если не писать что то свое, не колоться колючками поедаемого кактуса, то ничего не изобретали бы нового.
OkHelpDesk Автор
19.10.2022 10:01+1А что за системы были? Среди наших потенциальных клиентов есть те, кто сменил уже 5 систем. В таких случаях можно констатировать, что проблема на 146% не в ПО.
p.s. интерфейс это вообще притча по языцех при обсуждении любой системы, потому что очень субъективна. Но у нас, в Okdesk, кстати, нареканий к интерфейсу за 7 лет буквально по пальцам пересчитать. При этом сейчас мы все равно запустили большой внутренний проект "реновации" интерфейса
s_f1
18.10.2022 17:51Понятно, что статья рекламная и вряд ли предполагает дискуссию, но есть вопрос. Плюсы собственной разработки худо-бедно описаны. Но везде нивелируются стоимостью. Я правильно понял, что других минусов, помимо стоимости, у собственной разработки нет?
OkHelpDesk Автор
18.10.2022 19:20Ну мы, если и рекламировали, то, пожалуй, всех вендоров ПО :)
В конечном счете все минусы связаны с итоговыми затратами, да. Просто некоторые затраты - прямые, в виде зарплат, стоимости инфраструктуры и т.д., а некоторые - косвенные. Например, время разработки, в течение которого бизнес не получал результата его куда вписать? А зависимость от того, кто внутри это все разработал куда отнести? В случае собственной разработки эта зависимость очевидно кратно выше, чем зависимость от вендора. Если резюмировать, то для малого и среднего бизнеса, по нашему мнению, собственная разработка это один большой минус.
SergeKh
18.10.2022 19:21Я бы сказал, исключительно важное преимущество собственного софта - отсутствие лишних кнопочек в интерфейсе, лишних строк в конфигах, и вообще всего лишнего. Это, очень-очень сильно сокращает расходы рабочего времени сотрудников на использование и освоение софта.
В пересчете на деньги эта экономия перекрывает расходы на разработку именно для небольшого бизнеса, когда нужна относительно простая система.OkHelpDesk Автор
18.10.2022 19:46+1Может быть, у вас есть какая-то оценка сравнения стоимости разработки и "выйгрыша". Без сарказма уточняю. Было бы любопытно хоть какую-то модель увидеть
codecity
18.10.2022 20:12+2Вам не поверят. Подумают что хотите отговорить, чтобы покупали у вас.
Например, для разработки первой минимально продаваемой версии Okdesk в далеком 2015 году у нас ушло около 5,5 человеко-месяцев. За это время мы разработали простой (а с высоты пройденного за семь лет пути можно сказать, что примитивный), удобный реестр клиентов и заявок на обслуживание.
Скажут - ну что там можно делать 5 месяцев, если работы на 2-3 дня :)
Вот серьезно - попробуйте описать что именно заняло 5 месяцев для такого простого функционала. Ведь могут подумать что ваш разработчик просто криворук и не профессионален.
Основная сложность объяснить не профессионалу почему так долго. Вот возьмите соберите требования и закиньте на фриланс, выставьте сумму заказа $500 - и куча желающих будет его сделать. А уже что там по итогу получится - никто не знает. Как можно объективно обосновать что работы на 5 месяцев, если люди соглашаются делать за $500? Вот в чем сложность и неразрешимая проблема.
OkHelpDesk Автор
18.10.2022 20:39+2Ну, конечно, вот "добавьте тут кнопочку - это пара часов" тоже известный подход :)
На самом деле нет никакого желания переубеждать, тех, кто верит, что за 500$ что-то получит. Пусть идут и получают этот свой опыт :)
p.s. дождитесь второй части поста в ноябре про стоимость разработки, там будет аналитика и реальные оценки стоимости реализации под конкретные требования ;)
codecity
18.10.2022 21:48У многих и правда нет представления на что уйдет 5 месяцев. Если бы как-то это суметь доходчиво донести, чтобы развеять иллюзии - было бы здорово. Вот прямо привести требования, потом привести количество задач по требованиям и примерное время. Но и тут возникнут вопросы - а обосновано ли время каждой из задач - тут не знаю как доказать - ведь задачи не выражаются только лишь в написании кода, большая часть процессов в голове - по этому тут даже запись слежки за экраном разработчика не поможет.
Ruslan123
Вы еще сильно занизили стоимость разработки. За 800т.р. разработать можно разве что простой одностаничник со средней логикой.
OkHelpDesk Автор
Спасибо! Мы действительно везде и всё брали по нижней планке. Но даже с этой нижней планкой выводы говорят сами за себя. В ноябре планируем выложить уже реальные стоимости и оценки, полученные от большого количества компаний в рамках разработки некоего MVP hep desk системы. Это, собственно, и будет обещанная вторая часть рассуждений о том, сколько сегодня стоит "самостоятельно разработать ПО"