Я в некоторых командах пробовал текстовые отчёты делать. Во-первых на них быстро забивают. Во-вторых они теряются в чате.
Что касается озвучить нейронкой - пока нейронки очень плохо озвучивают, так что кровь из ушей. Лично меня сильно напрягает нейроозвучка.
"Лучше час с выключенной камерой в фоне послушаю, чем за 2 минуты запишу свой видеоотчёт". Если разработчику такое ещё норм, то руководителю, которому нужно понимать что происходит в разработке - послушать в фоне не прокатит. И да, когда я был руководителем я слушал созвоны в фоне, делая более важные задачи. Но потом приходилось заново расспрашивать снова теряя время.
Не обязательно в видеоотчёте своё лицо показывать. Можно показать сделанную задачу. Показ лица - это лишь одна из не обязательных опций. Более того, по опыту МТС (о котором рассказали на интервью) - чаще записывали именно без лица. С лицом записывали экстраверты, которым наоборот нравится себя записывать, а также те кто по своей профессии обязаны показывать лицо, например продажники или менеджеры.
Похоже вы не прочитали моё предыдущее сообщение. Повторю его. Можно оставить викли (общий созвон раз в неделю) - на который все приходят, всё слушают и синхронизируются. А дейлики (ежедневные созвоны), где каждый говорит что сделал сегодня, что планирует завтра - можно перевести в асинхронный формат.
Вопрос в том, сколько сейчас созвонов в компании/команде. Уменьшать их до нуля конечно нет смысла - это ухудшит ситуацию. Но когда созвонов слишком много (и они занимают до 50% времени разработчика) - там точно нужно сокращать. Тут вопрос баланса. Слишком мало - плохо. Слишком много - плохо.
Конечно можно и так сделать. Я же не против. Более того, я именно так и делал там, где рулил созвоном - жёстко его моделировал, не давая растекаться мыслями по древу и уходить в другие темы.
Но так было не везде и не всегда. Например если созвон руководителей - то там я не имею прав модерировать. И могу лишь предложить руководству вариант с асинхронными синками. Такое было в одно компании, которую не буду называть - в которой проводились синки на несколько десятков, а то и сотен человек... Вот там этот инструмент отлично подошёл бы.
Почта да - не плохой инструмент. Пока в переписке не оказывается несколько десятков человек и она разрастается в снежный ком. Да, подобные кейсы можно решить чатами.
Асинхронный дейлик - это лишь один из множества вариантов взаимодействия. Не обязательно его применять везде и даже вредно так делать. Каждый инструмент хорош там, где он приносит больше пользы чем вреда. Если в ваших кейсах он не применим - это нормально.
И да, я не являюсь сотрудником МТС. Я лишь познакомился с инструментом, который мне стал интересен и я буду общаться с руководством о внедрении такого инструмента. И да, у этого инструмента куча других применений помимо замены созвонов.
Так не обязательно заменять именно дейлики. Есть куча других вариантов использования. В каждой команде/компании своё применение. Лично у меня и моих знакомых в некоторых корпорациях была боль именно с дейликами. Потому я и начал именно с этого. Если у вас хорошо с дейликами работает - это же отлично. Значит с ними ничего не нужно менять.
Видимо вам повезло и никогда не было дейликов, в которые просто тратится время команды. И у вас никогда не было в команде интровертов-социофобов. Повторюсь, предлагаемая в статье возможность - это не замена всех живых созвонов. А лишь возможность сократить перевести в асинхронный формат те созваны, которые не требуют всем быть онлайн. Даже сам МТС пишет, что перевёл на асинхронные только 30% созвонов.
Не все люди диджиталы и визуалы. Есть много аудиалов - которым вообще тяжелее с текстом - в итоге шлют тысячи аудиосообщений и кружков... А так получается, что у всех единый формат записи - а как этот формат читать/слушать каждый выбирает сам.
Уже "первый" вариант во всю используется. В итоге джуны с ИИ-инструментами устраиваются на несколько "мидловских" вакансий и на работе почти ничего не делая, но получая за это деньги. А реальных мидлов и синьоров, которым приходится пахать за джунов - отлавливает ещё на входном ИИ-HR-фильтре.
У них там отдельное окошко ада при попытке зарегистрироваться разработчиком и попытке опубликовать своё приложение на Android. Фото паспорта и фото кредитной карты, которое они просят прислать для верификации - это лишь вершина айсберга.
Про 15, 10 и 3 года - действительно не сходится, т.к. не стал писать про опыт до 1С и после Сбера. Добавил в статье, благодарю за то, что обратили внимание.
Рассказывал в 2023 про свой опыт, который был в 2019. Благодарю за ваш комментарий - внёс корректировку в статью. Это действительно было не очевидно, что я описываю прошлый опыт.
Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 9 направлений, перечисленных в начале статьи. Как вариант я мог бы подбрасывать монетку. Но решил не доверять этот выбор случайности, а выбрать сам.
Как описание подхода к проектированию больших приложений - ок.
Как руководство к проектированию любой системы - нет, т.к. оторвано от реальной жизни, где бывают и маленькие проекты, и текучка кадров, и решения по слиянию/разделению приложений и прочее.
Например сейчас я занимаюсь проектом, который сначала сделали сложным (примерно как описано в статье) на миксе архитектур Clean+MVVM, потом другой разработчик пришёл и решил "упростить" переписав часть приложение в что-то вроде MVI. Я уже 3й разработчик и пытаюсь во всём этом разобраться. Мозг взрывается от смеси 2х архитектур. Если бы приложение было на чистом MVP или MVVM - то я мог бы стоящие передо мной задачи сделать за полчаса каждую. Но в итоге уже несколько дней сижу, пытаясь понять, как прогнать данные через несколько "слоёв" или "зон ответственности", чтобы оно корректно отработало. Ладно, я как мидл за недельку-другую разберусь в любой архитектуре и заставлю всё работать как надо. Но джун такой проект точно не потянет.
Я не первый раз вижу, что синьоры переусложняют архитектуру, чтобы соответствовать принципам SOLID, CLEAN и т.д., но забывают что этой архитектурой будут пользоваться джуны, которые могут и не понять как всё это работает. И если для больших приложений (банков, маркетплейсов и т.д.) это оправдано, т.к. разрабу дают обычно ограниченный модуль, в рамках которого он делает свои задачи. То для небольшого и среднего приложения такое усложнение архитектуры считаю избыточным. Для большинства проектов достаточно MVP/MVVM + Repository
В любом случае благодарю за статью - теперь понимаю чем руководствуются синьоры, делая такие сложные архитектуры.
Осталось подождать ещё 120 лет, чтобы во всех лестницах добавили более пологую полосу для качения, а так же во все бордюры добавили частый сьезд, а также чтобы везде рядом с брусчатской/плиткой добавили ровную дорожку для использования колёс.
Пару лет назад помогал колясочнице доехать в Мск от кинотеатра Октябрьский до Гагаринского переулка... Это был не простой квест даже для 2х сопровождающих мужчин.
Ну и периодически приходится с чемоданом ехать от вокзалов на метро с пересадками и многие станции не предназначены для использования чемоданов с колесами (хоть формально там сделаны полозья, которыми невозможно пользоваться), приходится часто нести чемодан на руках.
Я в некоторых командах пробовал текстовые отчёты делать. Во-первых на них быстро забивают. Во-вторых они теряются в чате.
Что касается озвучить нейронкой - пока нейронки очень плохо озвучивают, так что кровь из ушей. Лично меня сильно напрягает нейроозвучка.
"Лучше час с выключенной камерой в фоне послушаю, чем за 2 минуты запишу свой видеоотчёт". Если разработчику такое ещё норм, то руководителю, которому нужно понимать что происходит в разработке - послушать в фоне не прокатит. И да, когда я был руководителем я слушал созвоны в фоне, делая более важные задачи. Но потом приходилось заново расспрашивать снова теряя время.
Не обязательно в видеоотчёте своё лицо показывать. Можно показать сделанную задачу. Показ лица - это лишь одна из не обязательных опций. Более того, по опыту МТС (о котором рассказали на интервью) - чаще записывали именно без лица. С лицом записывали экстраверты, которым наоборот нравится себя записывать, а также те кто по своей профессии обязаны показывать лицо, например продажники или менеджеры.
Согласен. Мир не идеален. Но не на всё мы можем повлиять напрямую.
Похоже вы не прочитали моё предыдущее сообщение. Повторю его. Можно оставить викли (общий созвон раз в неделю) - на который все приходят, всё слушают и синхронизируются. А дейлики (ежедневные созвоны), где каждый говорит что сделал сегодня, что планирует завтра - можно перевести в асинхронный формат.
Вопрос в том, сколько сейчас созвонов в компании/команде. Уменьшать их до нуля конечно нет смысла - это ухудшит ситуацию. Но когда созвонов слишком много (и они занимают до 50% времени разработчика) - там точно нужно сокращать. Тут вопрос баланса. Слишком мало - плохо. Слишком много - плохо.
Конечно можно и так сделать. Я же не против. Более того, я именно так и делал там, где рулил созвоном - жёстко его моделировал, не давая растекаться мыслями по древу и уходить в другие темы.
Но так было не везде и не всегда. Например если созвон руководителей - то там я не имею прав модерировать. И могу лишь предложить руководству вариант с асинхронными синками. Такое было в одно компании, которую не буду называть - в которой проводились синки на несколько десятков, а то и сотен человек... Вот там этот инструмент отлично подошёл бы.
Почта да - не плохой инструмент. Пока в переписке не оказывается несколько десятков человек и она разрастается в снежный ком. Да, подобные кейсы можно решить чатами.
Асинхронный дейлик - это лишь один из множества вариантов взаимодействия. Не обязательно его применять везде и даже вредно так делать. Каждый инструмент хорош там, где он приносит больше пользы чем вреда. Если в ваших кейсах он не применим - это нормально.
И да, я не являюсь сотрудником МТС. Я лишь познакомился с инструментом, который мне стал интересен и я буду общаться с руководством о внедрении такого инструмента. И да, у этого инструмента куча других применений помимо замены созвонов.
Так не обязательно заменять именно дейлики. Есть куча других вариантов использования. В каждой команде/компании своё применение. Лично у меня и моих знакомых в некоторых корпорациях была боль именно с дейликами. Потому я и начал именно с этого. Если у вас хорошо с дейликами работает - это же отлично. Значит с ними ничего не нужно менять.
Уже давно))) Как говорилось: "Никто никогда не вернёт 2007 год..."
И всё новое всегда воспринимается в штыки. А потом удачные решения входят в норму.
Видимо вам повезло и никогда не было дейликов, в которые просто тратится время команды. И у вас никогда не было в команде интровертов-социофобов. Повторюсь, предлагаемая в статье возможность - это не замена всех живых созвонов. А лишь возможность сократить перевести в асинхронный формат те созваны, которые не требуют всем быть онлайн. Даже сам МТС пишет, что перевёл на асинхронные только 30% созвонов.
А в чём проблема - оставить обычное вики? А все дейлики перевести на асинхронные?
А в чём проблема - оставить обычное вики? А все дейлики перевести на асинхронные?
Не обязательно смотреть видео - там есть расшифровка. Как раз об этом и написано в статье.
Не все люди диджиталы и визуалы. Есть много аудиалов - которым вообще тяжелее с текстом - в итоге шлют тысячи аудиосообщений и кружков... А так получается, что у всех единый формат записи - а как этот формат читать/слушать каждый выбирает сам.
Уже "первый" вариант во всю используется. В итоге джуны с ИИ-инструментами устраиваются на несколько "мидловских" вакансий и на работе почти ничего не делая, но получая за это деньги. А реальных мидлов и синьоров, которым приходится пахать за джунов - отлавливает ещё на входном ИИ-HR-фильтре.
У них там отдельное окошко ада при попытке зарегистрироваться разработчиком и попытке опубликовать своё приложение на Android. Фото паспорта и фото кредитной карты, которое они просят прислать для верификации - это лишь вершина айсберга.
Про диаграмму Вена - да, у меня тогда был сложный период в жизни, и я умею в самоиронию)
Про 15, 10 и 3 года - действительно не сходится, т.к. не стал писать про опыт до 1С и после Сбера. Добавил в статье, благодарю за то, что обратили внимание.
Рассказывал в 2023 про свой опыт, который был в 2019. Благодарю за ваш комментарий - внёс корректировку в статью. Это действительно было не очевидно, что я описываю прошлый опыт.
Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 9 направлений, перечисленных в начале статьи. Как вариант я мог бы подбрасывать монетку. Но решил не доверять этот выбор случайности, а выбрать сам.
Как описание подхода к проектированию больших приложений - ок.
Как руководство к проектированию любой системы - нет, т.к. оторвано от реальной жизни, где бывают и маленькие проекты, и текучка кадров, и решения по слиянию/разделению приложений и прочее.
Например сейчас я занимаюсь проектом, который сначала сделали сложным (примерно как описано в статье) на миксе архитектур Clean+MVVM, потом другой разработчик пришёл и решил "упростить" переписав часть приложение в что-то вроде MVI. Я уже 3й разработчик и пытаюсь во всём этом разобраться. Мозг взрывается от смеси 2х архитектур. Если бы приложение было на чистом MVP или MVVM - то я мог бы стоящие передо мной задачи сделать за полчаса каждую. Но в итоге уже несколько дней сижу, пытаясь понять, как прогнать данные через несколько "слоёв" или "зон ответственности", чтобы оно корректно отработало. Ладно, я как мидл за недельку-другую разберусь в любой архитектуре и заставлю всё работать как надо. Но джун такой проект точно не потянет.
Я не первый раз вижу, что синьоры переусложняют архитектуру, чтобы соответствовать принципам SOLID, CLEAN и т.д., но забывают что этой архитектурой будут пользоваться джуны, которые могут и не понять как всё это работает. И если для больших приложений (банков, маркетплейсов и т.д.) это оправдано, т.к. разрабу дают обычно ограниченный модуль, в рамках которого он делает свои задачи. То для небольшого и среднего приложения такое усложнение архитектуры считаю избыточным. Для большинства проектов достаточно MVP/MVVM + Repository
В любом случае благодарю за статью - теперь понимаю чем руководствуются синьоры, делая такие сложные архитектуры.
Осталось подождать ещё 120 лет, чтобы во всех лестницах добавили более пологую полосу для качения, а так же во все бордюры добавили частый сьезд, а также чтобы везде рядом с брусчатской/плиткой добавили ровную дорожку для использования колёс.
Пару лет назад помогал колясочнице доехать в Мск от кинотеатра Октябрьский до Гагаринского переулка... Это был не простой квест даже для 2х сопровождающих мужчин.
Ну и периодически приходится с чемоданом ехать от вокзалов на метро с пересадками и многие станции не предназначены для использования чемоданов с колесами (хоть формально там сделаны полозья, которыми невозможно пользоваться), приходится часто нести чемодан на руках.