Programming + Разработка

Перевод:

«Никогда не спрашивай женщину о её возрасте, мужчину — о его зарплате, а Intel — сколько будет 4195835 разделить на 3145727»

Предыстория такая. В 1994 году в Intel выпускали процессоры Pentium, у которых была проблема с делением в одном из модулей. Если попытаться разделить числа вроде тех, что в примере, процессор выдавал неверные значения. Проблему нашли пользователи и опубликовали об этом статью. По идее, Intel должны были бы отозвать процессоры или как-то исправить проблему, но они молчали.

Когда пиар-скандала было уже не избежать, в Intel решили пойти навстречу пользователям, но странным образом: они были готовы заменить процессор, но только тем, кто написал бы об этом письмо. Дальше лучше расскажет Паша Вавилин, наставник на курсе Python:

«Intel потребовала, чтобы пользователь его процессора Pentium в нотариально заверенном письме обосновал, почему он испытывает страдания от того факта, что процессор считает числа некорректно. Мол, если вам так надо числа считать, используйте калькуляторы. И только с этим письмом в Intel готовы были пойти навстречу пользователю и заменить процессор. Пользователи обиделись, Intel потеряла много денег.

С тех пор и повелось: не спрашивать у Intel, чему будет равно 4195835.0/3145727.0»

Пора открывать рубрику: "Баба Яга не согласна с Forbes" Источник несогласия тут

Forbes (словами автора статьи, конечно) пишет про разработку корпоративного софта через призму «Есть сто банков, им нужны приложения для работы с клиентами, и команды программистов пишут плюс-минус одно и то же под запрос каждого из банков». И автор постулирует, что есть три варианта такой разработки:

– Собственными силами: пишут разработчики компании-заказчика

– Заказная разработка: задачу передают на аутсорс

– Вендер-лок – разработчик ПО продаёт лицензии на него, не отдавая сам код

Автор статьи разбирает эти три варианта с плюсами-минусами-рисками и делает вывод: в большинстве случаев оправдана разработка корпоративного софта на заказ, а крупным компаниям есть смысл растить экспертизу внутри себя (читай, разрабатывай свой софт самим).

Таки мне есть чего сказать по этому поводу

Здрасье, мы из будущего!

Первое: у всех бизнесов разные направления работы, объёмы, обороты, планы на будущее, а главное – внутренние процессы (впрочем, внешние тоже). Их CRM – это не «плюс-минус один и тот же функционал», он разный. Я этих CRM \ ERP\ Биллингов \ личных кабинетов и прочей радости повидала и навнедряла в десятках стран мира

Второе и главное: уже давно никто ( для среднего и крупного бизнеса) в мире не пишет CRM с нуля (находясь в здравом уме и твердой памяти). Ну, кроме разработчиков, которые в ~2000 году прилегли поспать, а вчера проснулись и увидели вокруг себя почётный караул, который попросил написать статью в Форбс.

Для остальных давно существуют платформенные решения, которые обнуляют необходимость нанимать какие-то команды для разработки корпоративного софта с нуля.

Что такое платформенное решение

Упрощенно говоря, это такое ПО, который настраивается под нужды конкретного заказчика. То есть выбираете платформу с гигантским набором возможностей и кастомизируете функционал под свои задачи.

Например, в России есть CRM-платформа Битрикс24, которая поставляется преднастроенной. Есть 1С - в ней конфигурацию пишут под конкретного заказчика. Есть платформы зарубежных разработчиков: скажем, американский облачный Salesforce, Microsoft Dynamics с элементами ИИ – эти поставляются ненастроенными, внедренцы разрабатывают конфигурацию с нуля под задачи конкретного бизнеса.

Кастомизировать тот же Битрикс24 под небольшой бизнес можно самостоятельно, покурив мануалы полдня, порог входа там довольно низкий. Вы наверняка получите что-то типа записной книжки, но почему бы и нет?!  А для компании в 500-1000 сотрудников решение допиливается и интегрируется в существующий IT-ландшафт. Делают это специально обученные люди – интеграторы, их у популярных систем много.

Можно сотрудничать с таким интегратором или нанять в штат людей, которые разберутся с кодом платформы и будут по мере надобности подключать модули и расширять функционал под задачи компании.

Риски платформенных решений

Рассмотрим те же риски, которые упоминает автор статьи в Форбс, но применительно к платформенной разработке – они выше или ниже, чем при создании софта с нуля?

1. Зависимость от поставщика

Это стандартный риск бизнеса, которым нужно управлять. После начала СВО, например, многие российские компании потеряли поддержку западных партнёров и перешли на отечественные решения.

2. Зависимость от разработчика

Вот когда речь идёт о кастомном софте, который только разработчик и видел, то да – куда ты потом от него денешься. С платформенными же решениями проще: выбирая известную платформу, можно выбирать интегратора. Один расстроил – меняете на другого. Да, ему потребуется время, чтобы разобраться в конкретной конфигурации, но он разберётся: все интеграторы знают особенности платформы.

3. Риск ухода команды

Опять же: если платформа известная, то на рынке много людей, которые умеют с ней работать. А вообще увольнение сотрудников – это обычный риск, с которым компании нужно работать. Уволиться может не только разработчик, но и главбух, например.

Резюмируя

Никакая разработка корпоративного софта с нуля сегодня нафиг не нужна. Достаточно подобрать платформу, максимально подходящую конкретному бизнесу, и выбирать имеет смысл среди известных и крупных поставщиков. А то, конечно, неловко будет, если разработчик обанкротится и его продукты перестанут поддерживаться.

Эти и другие новости с полей бизнес-компаний у нас

Поясняет Паша Вавилин, наставник на курсе по Python:

«Удивлён, что человека не взяли на работу. Его стоило бы нанять сразу менеджером.

Задание сводилось к тому, чтобы реализованная программа выводила на экран псевдографику, при этом вводились условия — нужно использовать два цикла для генерации этой псевдографики. Нигде в задании не указывалось, сколько суммарно шагов должны сделать эти два цикла.

По факту человек взял эту псевдографику, положил внутрь одного из циклов и вывел.

Ну и что, что два цикла на двоих по факту делают ровно одну операцию, — два цикла ведь есть! Условие выполнено!

Тут два варианта: его не взяли на работу, потому что он оказался умнее рекрутеров — никто не любит брать на работу людей умнее себя, вдруг начальство поймёт, что ты тогда и не нужен.

Либо всё дело в том, что у него в выводе на экран будет одна лишняя пустая строка».