Комментарии 43
Ну и как вы представляете «довериться друг другу» в обществе «конкуренции»? Это у вас «фентези» получается, с рыцарями, драконами и принцессами.
Если продолжать эту идею, то вовлечение болтших компаний в опен-сорс никогда бы не происходило. Да и наш кейс еще более скромный: доверяем мы все же не компании-конкуренту, а бизнес - ИТ, а ИТ - бизнесу.
Как именно МКБ вовлечён в open source?
Здесь имею в виду скорее компании типа Яндекса, Гугла и иже с ними, которые свои коммерческие продукты выводят в опен сорс. Вот тут было недавно интересное видео на этот счет про CatBoost. https://youtube.com/watch?v=G7G286S8ntc&si=EnSIkaIECMiOmarE
МКБ вовлечен скорее как потребитель - мы много чего такого используем и дорабатываем. Хотя тему с комитами на гитхаб тоже, проработать можно.
Вполне ожидаемо. Я только не понимаю, с чего ИТ-комьюнити должно вам довериться.
комитами на гитхаб тоже, проработать можно
Увы, процитированными вами же словами Друкера – культура вашей организации съест это начинание на завтрак. Ребята в галстуках делиться не умеют.
Тут доверие бизнес-бизнес на критическом пути. С разработчиками в этом плане сильно проще.
Доверие и Долженствование - слова из разных вселенных. Тут я с вами полностью согласен.
По поводу культуры в Банке - буду благодарен за фактуру, на которой вы основываетесь, строя столь неутешительные гипотезы. Это помогло бы понять, с чем ещё надо поработать.
Там дедушка Столлман сначала выкручивал руки GPLкой, пока не выяснилось, что обобществлять инфраструктурные проекты выгодно. А внутри трёхлитровой банки с пауками — нет, обобществлять не выгодно.
Очень просто. Пример - два вора идут на дело. Они вынуждены доверять друг другу. Иначе дело погорит. И после дела тоже доверяют. Иначе получится ситуация "кто первый сдаст".
Вы, как и многие сторонники искажённой модели социализма, имевшей место в СССР, упускаете из вида массу деталей, в которых порылся дьявол.
Глобально оптимизировать систему с пятью степенями свободы вполне возможно, но когда степеней свободы будет миллион, или даже миллиард, то вы уже сами понимаете своё полное бессилие.
Примитив, к которому сводится общество сторонниками социализма, коммунизма, марксизма и тому подобного, никогда не позволит обеспечить именно глобальную оптимизацию "для всех". Хотя глобальная оптимизация для царствующих паразитов вполне возможна, хотя и она будет далека от потенциально достижимой эффективности.
Сложные задачи требуют сложных решений. Отойдёте от примитива - найдёте решение. Или не найдёте. Потому что в сравнении со сложностью задачи все мы ничтожны. Но если не отходить от примитива - точно решений не найдёте.
Ну это, блин, сарказм был. Шпилька в сторону поборников «свободной конкуренции».
Сторонники свободной конкуренции точно так же сильно всё упрощают. А сарказм они не понимают, потому что свободная конкуренция "только для меня" выгоднее, чем все остальные предложения, поскольку они "не только для меня". То есть помимо логически порочного подхода здесь присутствует ещё и мотив выгоды (правда многие довольствуются лишь порочной логикой, даже не задумываясь о выгоде).
Да, и это я тоже знаю. И более того, могу вообще лекцию провести на тему «человек хорошо описывается моделью homo-economicus, даже если действует слабоосознанно», просто горизонт планирования у разных людей разный + разное окружение.
Но дайте же поприкаловаться — это же весело, когда вы пишете реплику, а оппоненты действуют совершенно предсказуемо. Это же игра такая.
«Legacy — это всё, что было до того, как я пришёл в проект». Насколько оно верно, предоставлю судить читателю.
Фраза верна на все 100%. Проект становится legacy, когда старая команда уволилась, а новую некому было обучать и вводить в курс дела, поэтому новая команды вешает на проект ярлык legacy и делает новый проект, чтобы заменить текущий, в котором будет разбираться.
Лучший способ разобраться для новой команды это повторить.
На доскональное изучение существующей реализации или переписывание команда потратит примерно одинаковое время. Но во втором случае давление со стороны бизнеса будет меньше (если получится продать конечно).
"Ребята уже третий месяц чего-то пишут" выглядит лучше, чем "ребята уже третий месяц разбираются".
В работающем легаси могут быть зашиты сотни бизнес-процессов, останавливать которые никто не позволит. И для переписывания, нужно будет сначала досконально разобраться как все работает, чтобы просто оценить масштабы.
В частном бизнесе так не очень работает. За это что-то кто-то платит, а бизнес начинает сильно переживать, когда не понимает, куда уходят деньги. Да и по практике отсутствие прозрачности в ИТ - ведёт потом к масштабным сокращениям. А это уж точно не наш метод )
Знаете, какая стратегия борьбы с legacy точно не работает? «Если я буду игнорировать это, возможно, оно исчезнет».
Эта стратегия работает. Причём как у исполнителей, так и у менеджеров.
У исполнителей: Работает — не трогай.
У менеджеров: Я сюда пришёл поработать на 2-3 года, чтобы прокачаться, а потом уйти на другую более высокооплачиваемую работу. Так что эта проблема с legacy будет головной болью того, кто придёт после меня.
А если сюда ещё добавляется обвинительная культура, когда за любую ошибку людей наказывают лишением премии, то желание что либо менять отпадает само собой. Зачем что-то менять в компании с риском стать крайним и сидеть без премии пару кварталов, если можно ничего не менять и стабильно получать свои премии.
Так а в чем все таки работа ИТ Бизнес партнера?
Бизнес отвечает за прибыль.
ИТ отвечает за то чтобы сделать и оно работало на проде.
ИТ бизнес партнер отвечает за... Мир во всем мире и дружбу ?
И действительно ... Бизнес даёт требования, команда аналитиков-разработчиков-тестировщиков их реализует. А не разогнать ли мне всех руководителей проектов и скрам-мастеров ...
Вот вы и ответили на то кто должен делать связку: рук проектов.
Но РП это от бизнеса. Так что Бизнес нанял спец чела для того чтобы вести проект РП.
Скрам мастером может быть любой член команды.
Дак что в итоге делает ИТ бизнес партнер?
Очень странный вопрос. Ваше видение существует только в идеальном мире маленькой компании в вакууме. Между IT и бизнесом всегда существует некоторый разрыв. Наличие связующего звена, понимающего и коммуницирующего обе стороны, сказывается крайне положительно на совместных процессах.
Если не делать рефакторинг то каждое изменение или добавление функционала в дальнейшем будет просить все больше и больше времени ии рисков.
Катастрофа, Аврал, Боль - слова продаж и ярких слоганов.
Многие продукты с красивой архитектурой, поддержка которых проста и требует минимальных вложений, лучше не трогать.
В конце-концов, любой "легаси" был передовым продуктом 10-20 лет назад, и если продукт соответствует текущим требованиям - don't fix it. :)
Refactoring - еще тот капкан.
Если убедили перейти на новый продукт, то переход не предполагает правку/удаление старого, а требует планируемое внедрение/создание параллельного продукта.
По крайней мере, это практика в банковской области разного размера компаний штатов.
Никто в здравом уме не подставится переходом на новый продукт и не даст изменить существующий без возможности отката. Всегда должен существовать PlanB - откат на legacy.
Три способа убедить бизнес
Кстати, есть способ номер ноль. Это озвученное Мартином правило бойскаута: код после тебя должен быть лучше, чем до тебя. Я не прошу у бизнеса время на рефакторинг, а итеративно занимаюсь рефакторингом каждый раз, когда захожу в участок кода по делу. Но очевидно, это неприменимо для высоких уровней архитектуры.
Здесь можно столкнуться с тем, что это "лучше" тоже процесс устаревающий, как и code style, следуя посылу статьи со временем превращается в легаси. В итоге один разработчик зашел в часть кода, сделал "лучше" для части функций, через пару лет второй, потом третий через пять, четвертый просто смотрит на эту мешанину стилей и подходов и матерится. Это все будет легаси, судя по определению, которое дал автор. А раз так, не гуманнее ли по отношению к четвертому разработчику следовать первоначальному стилю кода(окружения) для однообразности логического блока, а рефакторить так уж весь блок скопом?
Отчасти применимо. Обычно называют его как first touch
Думаю, работа ИТ бизнес партнёра предполагает большую эмпатичность.
Ещё один способ - постоянное запугивание и сравнивание с конкурентами :)
Вообще любой успешный проект проходит как минимум 4 стадии легаси, при котором необходимо полное или частичное переписывание:
Когда наспех стряпанный прототип выстрелил, и требуется делать полноценный коммерческий продукт.
Когда выбранный дизайн уже не позволяет эффективно реализовать скопившиеся требования.
Когда одна команда уже не справляется с потоком требований и требуется распределить разработку.
Когда количество клиентов и нагрузка резко возросли, и требуется менять существующую архитектуру решения.
удалено
Мы должны довериться друг другу, чтобы победить legacy