Кажется, Вы так увлечены разоблачением «бессмысленного набора слов», что пропустили суть самой статьи). Спасибо, что так ярко подтвердили актуальность темы.
Что ж, не всем близка идея переосмысления роли ИТ в бизнесе. Особенно, если проще спрятаться за словесной экзекуцией и обвинениями в «псевдосмыслах», чем попытаться уловить суть. Цель статьи не помочь решить Ваши коммуникативные задачи, а сдвинуть оптику восприятия.
Если стиль мешает восприятию,возможно, стоит задать вопрос не только автору, но и себе.
Удачи Вам в дальнейшем, попробуйте найти свой стиль и стать автором Хабр!
Коллега, не ожидал такого повышенного внимания к статье. Ваш комментарий как отличный пример той самой установки, которую и хотел вскрыть: привычки оценивать текст по форме, а не по навыку оценки содержания. Если для Вас непривычный стиль подачи автоматически равен отсутствию понимания, возможно, именно об этом и стоит задуматься.
Цель текста не коммуникация, а смещение фокуса: переосмысление взаимодействия ИТ - бизнес, обнажение перекосов в восприятии и управлении. Это не попытка всем понравиться. Это попытка сдвинуть мышление. И если после прочтения чувствуете раздражение — может, как раз статья попала в цель.
Профессионализм — это не только излагать мысли, но и уметь распознавать, когда тебе предлагают подумать шире. Удачи в этом пути)
Про заголовок: ИТ и бизнес не слышат друг друга, каждый решает задачи в своей логике, а проблемы между ними не решаются системно, а гаснут локально, до следующего сбоя. Проблема, о которой идёт речь в статье, состоит в разрыве между ИТ и бизнесом, который проявляется в нескольких аспектах, которые расписаны. Речь про изменения подхода и логики работы со стороны ИТ.
Учту обратную связь и в следующих статьях постараюсь раскрывать эти вопросы более структурировано и с других сторон. Спасибо, живое обсуждение помогает делать контент полезнее)
Привет, спасибо за коммент. Удивительно, как одинаковые мысли могут переходить из комментария в комментарий под видом новых инсайтов) Как упомянул выше, текст написан без корпоративного штампа, в стиле, который органичен мне. Если статья вызывает отторжение — это тоже отклик. Хабр, к счастью, даёт выбор для тех, кто предпочитает другой тон, стиль или подачу)
Привет, спасибо за развёрнутый комментарий. Комфортный формат — ключевой фактор продуктивности, и если в команде всё работает, процессы отлажены, а люди довольны — значит, модель подходит. Это и есть зрелость. Мы ни в коем случае не предлагаем универсального рецепта, и мы понимаем, что его просто нет :) Текст статьи — это скорее приглашение к обсуждению, а не директива. Наблюдая за ситуациями, где удалёнка стала причиной разрыва между ИТ и бизнесом (потеря вовлечённости, замкнутость, ухудшение качества сервиса), я и пришел к написанию этого материала. В этих кейсах, наоборот, выход в офис стал способом оживить процессы и запустить диалог. Что касается подачи удалёнки как «бонуса» — согласен, формулировка может звучать неоднозначно, но мысль в другом: удалённый формат — это не обязанность бизнеса, а зона договорённости. И важно, чтобы обе стороны понимали ценность и риски, а не просто следовали тренду. Кстати, по поводу «если команда работает слаженно — не надо мешать» трудно что-то возразить, но если что-то буксует — возможно, стоит задуматься не только о метриках, но и о том, как мы взаимодействуем :) Спасибо за честную позицию.
DDD (domain driven design) — предметно-ориентированная парадигма проектирования и разработки — помогает решить данную проблему с помощью особого подхода к проектированию и коммуникации.
Опять очередной слоган забугорных процессов, которые все с умным видом пытаются внедрить, но забывают:
Найти кто сможет это внедрить, причем правильно и интегрировать в культуру компании;
Адаптировать под менталитет русских людей, которые вместо ответственности думаю о том как «меньше поработать».
Мы уже столкнулись опытом внедрения SAFe в компании и пишем исходя из своего опыта: нужно сначала заложить людям в голову как правильно работать, а потом уже переходить на «умные» практики. Именно поэтому в статье и говорится не про новые аббревиатуры, а про необходимость менять подход к мышлению.
По поводу выхода в офис, я смотрю со стороны опыта ИТ и в данном случае ваш ответ показывает яркий кейс не желания «найти проблему у себя», а переложить на других — «мб стоит набирать заинтересованных бизнес аналитиков» — конечно стоит, поэтому и написан комплексный подход.
Когда мы говорим про «выход в офис», речь не только и не столько про общение с бизнес-заказчиком. Это и вовлечённость в команду, и «быстрая синхронизация» со смежниками, и просто человеческое взаимодействие, которое трудно воспроизвести через Zoom. Особенно в больших компаниях, где личный контакт помогает сократить цепочку недопонимания.
Я уверен, что в Москве каждый разработчик сможет найти своего потребителя и если даже не прямого, то явно заинтересованное лицо, но основной посыл не только в общении со своими потребителями, но и живое общение со своими коллегами внутри команды/смежных поездов.
ЗП ниже рынка :
Смотря с кем сравнивать :)
Как раз за счет этого мы можем предложить сотрудникам удаленку/гибрид при этом в других ТОП-компаниях сотрудники работают в офисе. Я не беру точечные ИТ компании, которые предоставляют сервис, я говорю про компании уровня Страхового Дома ВСК, где ИТ в штате самой компании.
Благодарю за прочтение и содержательный комментарий.
Спасибо за обратную связь. Стиль органичен для меня и соответствует содержанию,наверное, для Вас слишком серьезный. Не всем может зайти, это нормально. На Хабре много разных форматов, найдёте близкий себе. И спасибо за прочтение)
Привет! Точно передали суть — весли нет того самого "прикладного математика", начинается хоровод инициатив, где каждый видит только свой кусок. И да, именно таких "собирателей модели реальности" зачастую не хватает. Как раз и обращаю внимание: пока нет целостного понимания, ответственность и причинность будут размыты. А "пинать" всех по очереди не самая устойчивая архитектура :) По-хорошему, такие специалисты должны не только "пинать", но и строить мосты, даже если нет "математика", можно хотя бы начать с выращивания сервисного мышления — ках умения видеть проблему не в себе/в той системе, а в цепочке процессов. Сама суть — это не найти управленца или ответственного/крайнего, а изменить подход к мышлению начиная от рядового специалиста до конечного управленца. Светлые головы есть везде, но зачастую этого недостаточно, т.к. одна-две головы не смогут пробить барьер культуры компании, который складывался многие годы. Спасибо за комментарий — он точно попадает в нерв темы. Возьмём на вооружение метафору с котом :)
Привет, спасибо за комментарий. Роль IT-бизнес-партнёра или сильного управленца — это важный элемент в построении мостов между ИТ и бизнесом, безусловно.
Но если посмотреть системно, то одной позиции всё же недостаточно. Один человек, даже очень компетентный, не в силах изменить культуру, которая формировалась годами. А именно культура, при которой ИТ воспринимается как "обслуживание", а не как часть бизнес-механизма, и является корневой проблемой.
Смена мышления нужна на всех уровнях, потому что именно рядовые сотрудники ежедневно взаимодействуют с конечным пользователем, а значит, именно через это взаимодействие бизнес формирует представление об ИТ.
Грамотные управленцы могут запустить изменения в процессах и приоритетах. Но устойчивый результат появляется, когда работает вся цепочка, и каждый понимает не только свою зону ответственности, но и зону влияния.
Поэтому мы и говорим не о "поиске героя", а о комплексном подходе: сверху вниз и снизу вверх, от ИТ к бизнесу и обратно.
Спасибо за мысль, здорово дополняет общую картину)
Спасибо за комментарий, даже если вы решили его удалить или сократить) Кейс успел прочитать, возможно, из вашего опыта тоже выйдет отличная статья на Хабр!
Спасибо большое за содержательное дополнение! Вы абсолютно правы в том, что вопросы кибербезопасности заслуживают отдельного внимания при миграции, особенно в сценариях с регуляторными ограничениями или работой с критичными данными. Беру на заметку идею: сделать чек-лист ИБ-контролей как дополнение к основному паспорту системы, чтобы эти вещи не ускользали)
Привет! Наличие NULL-значений усложняет оптимизацию запросов, так как индексы работают с ними неэффективно, а агрегатные функции и фильтры требуют дополнительной обработки. Чтобы упростить работу с данными, рекомендуем минимизировать NULL, используя значения по умолчанию или специальные маркеры. В некоторых типах СУБД NULL значения не индексируются и требуют дополнительных усилий для индексации.
LEFT JOIN самый обычный тип соединения)
О нем нечего писать, его можно всегда смело использовать. Мы писали о потенциальных проблемных типах соединений.
Кажется, Вы так увлечены разоблачением «бессмысленного набора слов», что пропустили суть самой статьи). Спасибо, что так ярко подтвердили актуальность темы.
Что ж, не всем близка идея переосмысления роли ИТ в бизнесе. Особенно, если проще спрятаться за словесной экзекуцией и обвинениями в «псевдосмыслах», чем попытаться уловить суть. Цель статьи не помочь решить Ваши коммуникативные задачи, а сдвинуть оптику восприятия.
Если стиль мешает восприятию,возможно, стоит задать вопрос не только автору, но и себе.
Удачи Вам в дальнейшем, попробуйте найти свой стиль и стать автором Хабр!
Коллега, не ожидал такого повышенного внимания к статье. Ваш комментарий как отличный пример той самой установки, которую и хотел вскрыть: привычки оценивать текст по форме, а не по навыку оценки содержания. Если для Вас непривычный стиль подачи автоматически равен отсутствию понимания, возможно, именно об этом и стоит задуматься.
Цель текста не коммуникация, а смещение фокуса: переосмысление взаимодействия ИТ - бизнес, обнажение перекосов в восприятии и управлении. Это не попытка всем понравиться. Это попытка сдвинуть мышление. И если после прочтения чувствуете раздражение — может, как раз статья попала в цель.
Профессионализм — это не только излагать мысли, но и уметь распознавать, когда тебе предлагают подумать шире. Удачи в этом пути)
Привет! Попробую прояснить.
Про заголовок: ИТ и бизнес не слышат друг друга, каждый решает задачи в своей логике, а проблемы между ними не решаются системно, а гаснут локально, до следующего сбоя.
Проблема, о которой идёт речь в статье, состоит в разрыве между ИТ и бизнесом, который проявляется в нескольких аспектах, которые расписаны. Речь про изменения подхода и логики работы со стороны ИТ.
Учту обратную связь и в следующих статьях постараюсь раскрывать эти вопросы более структурировано и с других сторон. Спасибо, живое обсуждение помогает делать контент полезнее)
Привет, спасибо за коммент. Удивительно, как одинаковые мысли могут переходить из комментария в комментарий под видом новых инсайтов)
Как упомянул выше, текст написан без корпоративного штампа, в стиле, который органичен мне.
Если статья вызывает отторжение — это тоже отклик. Хабр, к счастью, даёт выбор для тех, кто предпочитает другой тон, стиль или подачу)
Привет, спасибо за развёрнутый комментарий.
Комфортный формат — ключевой фактор продуктивности, и если в команде всё работает, процессы отлажены, а люди довольны — значит, модель подходит. Это и есть зрелость. Мы ни в коем случае не предлагаем универсального рецепта, и мы понимаем, что его просто нет :)
Текст статьи — это скорее приглашение к обсуждению, а не директива. Наблюдая за ситуациями, где удалёнка стала причиной разрыва между ИТ и бизнесом (потеря вовлечённости, замкнутость, ухудшение качества сервиса), я и пришел к написанию этого материала. В этих кейсах, наоборот, выход в офис стал способом оживить процессы и запустить диалог.
Что касается подачи удалёнки как «бонуса» — согласен, формулировка может звучать неоднозначно, но мысль в другом: удалённый формат — это не обязанность бизнеса, а зона договорённости. И важно, чтобы обе стороны понимали ценность и риски, а не просто следовали тренду.
Кстати, по поводу «если команда работает слаженно — не надо мешать» трудно что-то возразить, но если что-то буксует — возможно, стоит задуматься не только о метриках, но и о том, как мы взаимодействуем :)
Спасибо за честную позицию.
Привет, постараюсь ответить по порядку.
DDD (domain driven design) — предметно-ориентированная парадигма проектирования и разработки — помогает решить данную проблему с помощью особого подхода к проектированию и коммуникации.
Опять очередной слоган забугорных процессов, которые все с умным видом пытаются внедрить, но забывают:
Найти кто сможет это внедрить, причем правильно и интегрировать в культуру компании;
Адаптировать под менталитет русских людей, которые вместо ответственности думаю о том как «меньше поработать».
Мы уже столкнулись опытом внедрения SAFe в компании и пишем исходя из своего опыта: нужно сначала заложить людям в голову как правильно работать, а потом уже переходить на «умные» практики.
Именно поэтому в статье и говорится не про новые аббревиатуры, а про необходимость менять подход к мышлению.
По поводу выхода в офис, я смотрю со стороны опыта ИТ и в данном случае ваш ответ показывает яркий кейс не желания «найти проблему у себя», а переложить на других — «мб стоит набирать заинтересованных бизнес аналитиков» — конечно стоит, поэтому и написан комплексный подход.
Когда мы говорим про «выход в офис», речь не только и не столько про общение с бизнес-заказчиком. Это и вовлечённость в команду, и «быстрая синхронизация» со смежниками, и просто человеческое взаимодействие, которое трудно воспроизвести через Zoom. Особенно в больших компаниях, где личный контакт помогает сократить цепочку недопонимания.
Я уверен, что в Москве каждый разработчик сможет найти своего потребителя и если даже не прямого, то явно заинтересованное лицо, но основной посыл не только в общении со своими потребителями, но и живое общение со своими коллегами внутри команды/смежных поездов.
ЗП ниже рынка :
Смотря с кем сравнивать :)
Как раз за счет этого мы можем предложить сотрудникам удаленку/гибрид при этом в других ТОП-компаниях сотрудники работают в офисе. Я не беру точечные ИТ компании, которые предоставляют сервис, я говорю про компании уровня Страхового Дома ВСК, где ИТ в штате самой компании.
Благодарю за прочтение и содержательный комментарий.
Спасибо за обратную связь. Стиль органичен для меня и соответствует содержанию,наверное, для Вас слишком серьезный. Не всем может зайти, это нормально. На Хабре много разных форматов, найдёте близкий себе. И спасибо за прочтение)
Привет! Точно передали суть — весли нет того самого "прикладного математика", начинается хоровод инициатив, где каждый видит только свой кусок. И да, именно таких "собирателей модели реальности" зачастую не хватает.
Как раз и обращаю внимание: пока нет целостного понимания, ответственность и причинность будут размыты. А "пинать" всех по очереди не самая устойчивая архитектура :)
По-хорошему, такие специалисты должны не только "пинать", но и строить мосты, даже если нет "математика", можно хотя бы начать с выращивания сервисного мышления — ках умения видеть проблему не в себе/в той системе, а в цепочке процессов. Сама суть — это не найти управленца или ответственного/крайнего, а изменить подход к мышлению начиная от рядового специалиста до конечного управленца. Светлые головы есть везде, но зачастую этого недостаточно, т.к. одна-две головы не смогут пробить барьер культуры компании, который складывался многие годы.
Спасибо за комментарий — он точно попадает в нерв темы. Возьмём на вооружение метафору с котом :)
Привет, спасибо за комментарий. Роль IT-бизнес-партнёра или сильного управленца — это важный элемент в построении мостов между ИТ и бизнесом, безусловно.
Но если посмотреть системно, то одной позиции всё же недостаточно. Один человек, даже очень компетентный, не в силах изменить культуру, которая формировалась годами. А именно культура, при которой ИТ воспринимается как "обслуживание", а не как часть бизнес-механизма, и является корневой проблемой.
Смена мышления нужна на всех уровнях, потому что именно рядовые сотрудники ежедневно взаимодействуют с конечным пользователем, а значит, именно через это взаимодействие бизнес формирует представление об ИТ.
Грамотные управленцы могут запустить изменения в процессах и приоритетах. Но устойчивый результат появляется, когда работает вся цепочка, и каждый понимает не только свою зону ответственности, но и зону влияния.
Поэтому мы и говорим не о "поиске героя", а о комплексном подходе: сверху вниз и снизу вверх, от ИТ к бизнесу и обратно.
Спасибо за мысль, здорово дополняет общую картину)
Спасибо за комментарий, даже если вы решили его удалить или сократить) Кейс успел прочитать, возможно, из вашего опыта тоже выйдет отличная статья на Хабр!
Спасибо большое за содержательное дополнение! Вы абсолютно правы в том, что вопросы кибербезопасности заслуживают отдельного внимания при миграции, особенно в сценариях с регуляторными ограничениями или работой с критичными данными.
Беру на заметку идею: сделать чек-лист ИБ-контролей как дополнение к основному паспорту системы, чтобы эти вещи не ускользали)
Привет! Наличие NULL-значений усложняет оптимизацию запросов, так как индексы работают с ними неэффективно, а агрегатные функции и фильтры требуют дополнительной обработки. Чтобы упростить работу с данными, рекомендуем минимизировать NULL, используя значения по умолчанию или специальные маркеры. В некоторых типах СУБД NULL значения не индексируются и требуют дополнительных усилий для индексации.
LEFT JOIN самый обычный тип соединения)
О нем нечего писать, его можно всегда смело использовать. Мы писали о потенциальных проблемных типах соединений.