Казалось бы, сколько раз уже обсудили, что такое требование, какие они бывают и почему важно начинать с требований, а не с решений.
Но я не перестаю удивляться как круг повторяется.
Из любимого:
1.У нас нет системного анализа и он нам не нужен.
2.Нфт фигня и зачем их писать, пустое.
3.Главное в бизнес-анализе процессы.
4.Микросервисы нас спасут (а теперь ещё ИИ спасёт).
5.Предметная область, что это такое? Всем же итак понятно.
Можете дополнить, то с чем вы столкнулись на этой неделе? 🔽
Поймала себя на мысли, что в живой команде, всё не очень, а где-то точно круто и хорошо.
Если у тебя что-то не так, где-то же есть идеал?)
И когда обсуждаешь проблемы команды, компании, кажется, что где-то есть идеал. И мысль идёт дальше, вот бы его найти. Но вспоминая крутые доклады на конференциях того же озона, где все работали на тайм ту маркет, и зрелые процессы, и я сразу понимаю, что мне скучно будет)))
И вот такой когнитивный диссонанс, хочется думать, что где-то есть недостижымый идеал, в котором не хочется работать 😂
Ключевой момент состоит в том, чтобы понять мы делаем "проект или продукт".
Разницу между продуктом и проектом я описывала в статье, которая до сих пор актуальна.
Очень редко я слышу от руководства, что нам ещё нужно набрать экспертизу, у нас мало проектов было на этом теме. И вот когда уже был большой обзор болей заказчика и мы вырастили внутри себя экспертизу, тогда можно говорить - мы делаем продукт.
Да, есть тиражирование, есть своё место на рынке, и сбор сразу нескольких болей заказчика, а в какой-то момент уже экспертиза выше, чем у самого заказчика.
Мне понравилась аналогия, что
стоматолог не может научиться на себе лечить зубы.
Почему я топлю всегда за изменения, настройки под заказчика, потому что хардкод быстро себя изживает, да он может быть хорош, на определённом этапе, и показывать нужные метрики. Но бизнес и ситуация во внешнем мире изменяется быстрее, чем код. Тем более no-code, low-code, и да простят меня разработки ещё и вайбкодинг.
Но так как я любитель всего добротного, качественного и на века) То я за то, чтобы ядро системы было мощным и пусть оно не изменяется, если работает. Что мы часто видим в больших компаниях с историей, что есть сердце айти-ландшафта, которое лучше не трогать, оно работает.
И мы получаем гибридное решение. Там где можно сделать гибкость и быстрое изменение, то это нужно делать (чаще всего фронты), а там где нужны мощности, защищенность и отказоустойчивость, там хоть монолит сделать можно. Не так уж он плох.
И вот, вроде бы я говорила, про продукт и проект, но фактически спустилась на рассуждения архитектуры, потому что стратегия в бизнесе напрямую отражается на стратегию айти-ландшафта.
За и против разработки универсального продукта и кастом под заказчика.
Я практически не видела проекта, где бы мне сказали, что мы делаем чисто под заказчика. Чаще всего мы делаем под заказчика, но стараемся заложить некий универсал, чтобы можно было переиспользовать или перепродавать другим.
Вцелом очень понятная идея руководства/менеджмента потратить один раз, чтобы потом как можно больше окупать.
И вот мы набираем команду профессионалов, чтобы кустарно делать космический корабль. Я тут специально пишу "кустарно", потому что этот переход к универсальному решению чаще всего был ни на чем не основан. А хуже всего, когда даже не было самого заказчика, но мы уже делали что-то абстрактно-универсальное.
Потом началась эпоха микросервисов (она вроде как продолжается), и они нам позволяют добиться гибкости под заказчика, но какой ценой?
И вцелом с этой эпохой всё больше и больше стали говорить про быстрое изменение под заказчика и пользователей. Тут тоже можно сделать универсальную базу/сердце/core с возможностью конфигурирования под заказчика.
И такое тоже было направление, у нашей команды, не совсем до конца взлетело и себя оправдало.
А теперь я снова сталкиваюсь с тем, что давайте делать кастом под заказчика. И теперь есть ИИ, и вайбкодинг. И вообще продакты, и еже с ними, настолько устали спорить с несговорчивыми разработчиками, что с удовольствием вайбкодят то что им нужно. И вот он кастом, и наконец-то получаю, то что хочу.
Так что же лучше универсальное решёние или кастом под заказчика?
Вы на какой стороне?)
⌛С места в карьер - постоянно крутится, эта фраза в имея голове, когда говорят про внедрение ИИ в компаниях, где "голое поле" в плане автоматизации...
Меня удивляет, то как наш бизнес наивно думает, что вот есть ручные операции, и давайте сразу их заменим на ИИ. Для меня ИИ это технология, которая по сути новый этап цифровизации. И до ИИ нужно дорасти.
Есть этапы цифровизации организации, картинку нашла из научной статьи. И вместе с этими этапами происходит зрелость процессов, сотрудников и процессы перестройки.
И вот представьте, есть ручные операции и сразу их меняем на ИИ. Да, вставим шаги контроля, валидацию, будем контролировать ИИ.
Напоминает мне такие штуки, когда на гос проектах делали большую кнопку, чтобы как-то оставить сотрудников и дать им работу, и иллюзию контроля.
При этом вспомним закон конвея, который нам говорит, что ландшафт ИТ отражает коммуникацию в организации. То есть, если все привыкли звонить по любому чиху диспетчеру, то оно также и будет происходить. И мы получаем некий бардак, нужно как-то встроить ИИ, с места в карьер, и сразу на процессах, которые не зрелые и никогда не были автоматизированны, и тем более не проходили этап оптимизации.
Как же я "люблю", громкие слова, наподобие "давайте сразу при автоматизации/цифровизации ещё и оптимизацию процессов проводить".
Это равносильно тому, что вы на антибиотиках и ещё параллельно решили бегать по утрам и сидеть на диете для похудения.
Я за естественное развитие, потому что резкое внедрение, также резкое отторжение вызывает, и сильно ломает и людей, и то что сложилось годами.
Никогда не прыгали с вышки в воду, и полезли сразу на 10 метров.