Накопление знаний
Гуманитарно-политические заметки

Создатели "самописки"

иногда читаешь резюме и даёшься "диву" - имею опыт написания собственных 1С конфигураций, что самое интересное - программисты на C#, Python, Java, PHP такое указывают реже чем специалисты по 1С.

но если взглянуть с другой стороны - кто-то ведь заказывал "собственное приложение", кто-то согласовывал "архитектурное решение" (даже банального "давай" тут будет достаточно). И эт люди искренне были уверены в правоте своего решения.

в чем причина создания собственного продукта в конечных (не занятых софтверным бизнесом) организациях ? Навскидку можно предположить, что:

  • есть определенная усталость у людей от навязывания "бест-практиксов" продажниками в розовых рубашках
  • низкая эргономичность крупных решений, а точнее избыточность как интерфейсов для человека, так и доменной модели для "Одной Задачи"
  • высокая савокупная стоимость владения.... причем кажущаяся

Вместе с этим есть несколько факторов про которые не стоит забывать - ИТ специалисты не являются интровертами (это хитрость) - в реальности их ассоциальность проистекает из их идеализма и определённого крушения надежд при общении с людьми.

Компьютеры ведут себя предсказуемо


именно от этого и проистекает "любовь" к ИТ - технологии ведут себя ровно так как написан алгоритм, даже если он вредоносен, это понятно с первого взгляда - а не так как в обычной жизни: ты совершенно не знаешь и до конца не можешь быть уверен что точно понял цели "индивидума". А считать что все руководствуются только личной выгодой - очень неприятно....

в итоге - как мы помним одна из причин возникновения "собственных решений", это тезис "Всё что написал не Я, то плохо". Подтверждение данного тезиса можно увидеть в разных аспектах ИТ технологий:

  • нежелание работать с коллективными средствами редактирования документации - SharePoint, Google Docs, Confluense, Wiki
  • неприятие скриптов по управлению инфраструктурой коллективного характера - каждый инфраструктурщик имеет свою копию скриптов Ansible, Terraform, etc

Ковыряем труп


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

После концептуально работающего решения, рано или поздно автор придет к изучении методологии, и если его "самописаный продукт" будет жить достаточно долго - ему вместо изучения чистоты функций и алгоритма "регистра правил" придется разбираться в предметной области и тут ему придется смотреть куда ? Правильно - в крупные решения. Пример с SalesForce и моделью ART для ритейла очень показателен. Попробуйте на досуге спроектировать домен "Работа с лидами". И первые 5 суток вы будете изучать варианты что такое "лид", точнее не так... Вопрос в другом

Лид - это существительное, глагол или прилагательное ?

В 90% случаев никакой заказчик уже не согласует время на данное RandD - то есть согласовать "написание решения с нуля" он согласует, а вот его "редакцию 2.0" уже нет.

В итоге если предприятие живет "долго" - мы имеем комплекс "мертвых решений", которые концептуально работают, но методически уже "не вытягивают". А так как алгоритмы в нем "точечные" (под задачу) - через год-два жизни такого решения.мы уже не сможем его нормально модернизировать без глобальных затрат в формате "всё взять и переписать". А если ещё и уволился автор.... Будут чудеса.

ModerniZation Driven Development


Собственно отсюда и возникают исходные противоречия

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

Решения на 1С 7.7 и 8.2 даже с примененем 1С++ и других правильных технологий - это "не модернизируемый путь". А что если выбирать решения от будущей "модернизации" - то есть исходить из того как мы будем владеть решением, которого еще нет.

Ответ то просто в этом случае - мы делаем гибриды. То есть что-то по типу:

  • 1C ERP + OData + React.JS
  • 1С УХ + AMQP + PowerBI
  • Bitrix + Kafka + УТ 11
  • etc

При данном подходе у нас получается что "три зайца жрут друг-друга"

  • методическое обеспечение доменной модели (будущее DWH) мы покупаем и тем самым получаем компетенции методологов
  • собственные разработчики создают наши уникальные пользовательские интерфейсы, которые достаточно просто модернизировать
  • возникает "сердце предприятия", в котором и есть наши уникальные "самописные решения" - которые в перспективе можно также заменить на вендорское или создать собственную команду модернизаторов.

В качестве заключение - если играть "в длинную", то кроме гетерогенно-гибридного подхода обеспечивающего непрерывную модернизацию - никакой альтернативы сейчас нет. Он (этот подход) еще и адаптрован к OKR и SAFe - так как позволяет определить ключевые цели и запустить "трайб" паррррррралельный.

Таковы мысли... Кстати - ARTs это https://www.omg.org/retail-depository/arts-odm-73/