Начинал с того, что пытался использовать для Postgres расширение pgvector, но что-то там не понравилось с ним (уже не помню конкретно что было не так). В конечном счете остановился на qdrant. Альтернатив не так уж и много. Но эти решения +/- оба приличные. Если уже используете postgres, то pgvector отличный вариант для вас.
А это прямо такая глобальная проблема? У нас в офисе есть специальные комнаты для отдыха - тихие, закрытые, с удобными креслами. Есть масса рекомендаций о пользе краткого сна в рабочее время вместо того, чтобы тупить над задачей. В Китае его вроде вполне официально вводят и в школах и на фабриках.
Я считаю, не нормальным, когда человек с жутким перегаром (и запахом соответствующим) приходит на работу и спит на рабочем месте, а другие на это смотрят.
Потом мы порознь идем на хабр и пишем по статье, я - о том, что у меня некомпетентный начальник, он - о том, что я игорь.
Что касается собирательного "Игоря", то с ним как раз было так, что он всю ответственность перекладывал на меня, в том числе это касалось именно его обязанностей.
На мой взгляд, правильная логика должна быть такой (все сильно упрощенно):
Я ставлю бизнес задачу (возможно, настаиваю на какой то технологии)
Разработчик ее берет в работу и готовит план как он ее сделает. Если задача крупная, согласовывает ее конечное решение со мной, если мелкая, то я даже не должен погружаться как она будет сделана (задачки из разряда кнопки вертикально или горизонтально). Ко мне обращаются только для согласования финальных вещей, или краеугольных где не хватает компетенции разработчика, или мы упираемся в вопросы бизнеса, бюджета или подобных. Вопросы упирающиеся в сферу ответственности не разработчика, адресуются мне.
Разработчик выполняет задачу
Получаем результат
Кейс Игоря:
Я ставлю бизнес задачу (возможно, настаиваю на какой то технологии)
Игорь задает миллион вопросов и как-то так получается, что план мы делаем вместе. Работаем над структурой данных и проектируем задачу вместе, думаем над интерфейсом, над сущностями. Хотя я, как руководитель, не должен погружаться в то, как кнопки должны быть расположены. Вся эта работа должна быть выполнена разработчиком
Игорь берет совместный план в работу
У Игоря возникают вопросы технического плана (за что он отвечает), по реализации (за что он отвечает), более сложные вопросы связи с бизнесом (за что я отвечаю) и со всем ними, без разбору, он бежит ко мне и согласовывает. Да. Часть из этих вопросов - это моя сфера ответственности. Но не ВСЕ же!
Это превращается не по вине руководителя в микро менеджмент.
Получаем результат
Улавливаете разницу?
А теперь давайте возьмем чуть дальше. И я задам вопросы по работе Игоря:
Что будет если в согласованном плане (да и в любой задаче) будет ошибка (любая)? Очевидно же, что Игорь подойдет ко мне и скажет, что это я виноват, потому что я там, сказал вот так. Понимаете проблему? При любых вопросах виноват не сотрудник, а руководитель. Даже в тех, где ответственность несет непосредственно разработчик (написание кода).
Внезапный вопрос. А зачем вообще нужен Игорь, если все проходит через меня как через фильтр, благодаря стараниям Игоря? Возможно все эти задачи проще выполнить мне?
Вот это и есть перекладывание ответственности. Игорь, все решения переложил на других, даже те, которые должен решать он.
Теперь о главном. Из моих слов, можно сделать вывод, что я, во что бы то ни стало, пытаюсь сделать крайним Игоря)) Но нет. За конечный результат всегда отвечает руководитель. Мой пост про другое: Игорь - это пример непрофессионального подхода к работе.
Есть что сказать по делу? Не нужно так остро реагировать на мои слова и да, я считаю, что вы не правы и повторю это здесь. Худшее, что можно сделать на собеседовании, говорить "я никогда не ошибался"
Вы абсолютно правы, прием заезженный (это глупо отрицать). Мне хотелось понять, насколько такой опыт уникален и обсудить это. Но за наблюдение - спасибо
Вы описываете совершенно другую проблему - некомпетентного руководителя, который перекладывает свою ответственность на подчиненных. Мой пост - о некомпетентном сотруднике, который избегает ответственности даже за свою работу. Это две стороны одной медали не правильной работы, и одно не оправдывает другое.
У меня нет всей полноты данных, поэтому я прихожу к начальнику с вариантами, а он отфутболивает. Где грань?
Грань очень четкая. Профессионал эскалирует вопрос, когда ему не хватает полномочий или стратегической информации для принятия решения. Мой условный Игорь эскалирует, чтобы не принимать никаких решений вообще, даже в рамках своих прямых обязанностей. Цель первого - лучший результат для бизнеса. Цель второго - нулевая личная ответственность.
А эпических факапов ну правда не было, истребители не переворачивались, ракеты не падали, пара миллионов со счета не пропадала.
Вы не поняли суть вопроса. Нанимателя интересует не масштаб вашего факапа, а ваша способность рефлексировать, учиться и брать на себя ответственность. Ответ "у меня не было значимых ошибок" - это худший из возможных. Он говорит либо о нечестности, либо о профессиональной незрелости. Сильный кандидат расскажет даже о мелкой технической ошибке, но с акцентом на то, какие выводы он из нее сделал для своего дальнейшего развития.
Это первая часть работ, для векторов. Вторая часть - это создание сервиса, который будет осуществлять всю логику. Сейчас работы идут над второй частью, чуть позже появится статья на эту тему. А уже потом можно написать приложение, которое будет работать так, как вы предлагаете.
Хорошее замечание про обучение. Это действительно моя оговорка. Все выглядит так, что мы модель как будто бы обучили, но это не так. Мы просто подсовываем ей нужный контекст в момент вопроса пользователя. Вот и вся магия.
Что касается вашей ситуации, то тут сложно что-то комментировать.
Спасибо за обратную связь, но я не совсем понимаю о чем вы ))) В статье вообще нет упоминания Авито и телефонных звонков. Что же касается финансового вопроса, то специально не считал. Но я думаю не так много 20$ Cursor и модели где то еще на 50. Это я прям с запасом взял, скорее всего меньше.
Микроменеджмент — это когда каждый шаг контролируют. У нас наоборот: команда сама решает, что и как делать. Дейли — это инструмент, чтобы не тратить время на «а что происходит?» в личках или на длинных созвонах. Если формат раздражает — скорее всего, проблема в реализации. Повторю свою мысль: хорошо выстроенный процесс не мешает, а экономит время.
В реальной жизни все по другому)) Вы сейчас говорите как обычный разработчик которому скучно. Я же как руководитель, который актуализирует в этот момент все важные моменты. У нас это в среднем занимает 3-5 минут для команды из 8 человек, иногда чуть дольше. Позволяет держать руку на пульсе и не раздражать коллектив одновременно и это отличный инструмент если его правильно "готовить".
Вообще не общаться в коллективе и просто пилить задачки невозможно. Все равно придется с коллегами пересекаться по каким-то вопросам и дейлики - это отличный способ вести такие взаимодействия.
Если что-то не нравится, возможно у вас в компании что-то делают не так. В идеале, конечно, этот процесс не должен угнетать, но на практике почти всегда не так.
У нас в команде ветка создается на каждый тикет-изменение. Если чтобы реализовать фичу нужно разбить задачу на несколько тикетов, будет делаться для каждого тикета своя ветка. Достаточно удобная схема работы. Коммиты делаем по conventional commits.
Начинал с того, что пытался использовать для Postgres расширение pgvector, но что-то там не понравилось с ним (уже не помню конкретно что было не так). В конечном счете остановился на qdrant. Альтернатив не так уж и много. Но эти решения +/- оба приличные. Если уже используете postgres, то pgvector отличный вариант для вас.
Действительно, в исходном варианте я неверно указал детали о продукте, уже исправил публикацию. Спасибо.
Спасибо за замечание. Действительно, в описании допустил неточность, уже поправил пост.
Простите ребят за некоторые шероховатости в описании инструмента, поправил. Спасибо
Абсолютно верно! Плохо, что такие вещи понимаешь только через свои ошибки. Ну и да. В вузах такому никто не учит.
Я считаю, не нормальным, когда человек с жутким перегаром (и запахом соответствующим) приходит на работу и спит на рабочем месте, а другие на это смотрят.
Что касается собирательного "Игоря", то с ним как раз было так, что он всю ответственность перекладывал на меня, в том числе это касалось именно его обязанностей.
На мой взгляд, правильная логика должна быть такой (все сильно упрощенно):
Я ставлю бизнес задачу (возможно, настаиваю на какой то технологии)
Разработчик ее берет в работу и готовит план как он ее сделает. Если задача крупная, согласовывает ее конечное решение со мной, если мелкая, то я даже не должен погружаться как она будет сделана (задачки из разряда кнопки вертикально или горизонтально). Ко мне обращаются только для согласования финальных вещей, или краеугольных где не хватает компетенции разработчика, или мы упираемся в вопросы бизнеса, бюджета или подобных. Вопросы упирающиеся в сферу ответственности не разработчика, адресуются мне.
Разработчик выполняет задачу
Получаем результат
Кейс Игоря:
Я ставлю бизнес задачу (возможно, настаиваю на какой то технологии)
Игорь задает миллион вопросов и как-то так получается, что план мы делаем вместе. Работаем над структурой данных и проектируем задачу вместе, думаем над интерфейсом, над сущностями. Хотя я, как руководитель, не должен погружаться в то, как кнопки должны быть расположены. Вся эта работа должна быть выполнена разработчиком
Игорь берет совместный план в работу
У Игоря возникают вопросы технического плана (за что он отвечает), по реализации (за что он отвечает), более сложные вопросы связи с бизнесом (за что я отвечаю) и со всем ними, без разбору, он бежит ко мне и согласовывает. Да. Часть из этих вопросов - это моя сфера ответственности. Но не ВСЕ же!
Это превращается не по вине руководителя в микро менеджмент.
Получаем результат
Улавливаете разницу?
А теперь давайте возьмем чуть дальше. И я задам вопросы по работе Игоря:
Что будет если в согласованном плане (да и в любой задаче) будет ошибка (любая)? Очевидно же, что Игорь подойдет ко мне и скажет, что это я виноват, потому что я там, сказал вот так. Понимаете проблему? При любых вопросах виноват не сотрудник, а руководитель. Даже в тех, где ответственность несет непосредственно разработчик (написание кода).
Внезапный вопрос. А зачем вообще нужен Игорь, если все проходит через меня как через фильтр, благодаря стараниям Игоря? Возможно все эти задачи проще выполнить мне?
Вот это и есть перекладывание ответственности. Игорь, все решения переложил на других, даже те, которые должен решать он.
Теперь о главном. Из моих слов, можно сделать вывод, что я, во что бы то ни стало, пытаюсь сделать крайним Игоря)) Но нет. За конечный результат всегда отвечает руководитель. Мой пост про другое: Игорь - это пример непрофессионального подхода к работе.
Есть что сказать по делу? Не нужно так остро реагировать на мои слова и да, я считаю, что вы не правы и повторю это здесь. Худшее, что можно сделать на собеседовании, говорить "я никогда не ошибался"
Вы абсолютно правы, прием заезженный (это глупо отрицать). Мне хотелось понять, насколько такой опыт уникален и обсудить это. Но за наблюдение - спасибо
Вы описываете совершенно другую проблему - некомпетентного руководителя, который перекладывает свою ответственность на подчиненных. Мой пост - о некомпетентном сотруднике, который избегает ответственности даже за свою работу. Это две стороны одной медали не правильной работы, и одно не оправдывает другое.
Грань очень четкая. Профессионал эскалирует вопрос, когда ему не хватает полномочий или стратегической информации для принятия решения. Мой условный Игорь эскалирует, чтобы не принимать никаких решений вообще, даже в рамках своих прямых обязанностей. Цель первого - лучший результат для бизнеса. Цель второго - нулевая личная ответственность.
Вы не поняли суть вопроса. Нанимателя интересует не масштаб вашего факапа, а ваша способность рефлексировать, учиться и брать на себя ответственность. Ответ "у меня не было значимых ошибок" - это худший из возможных. Он говорит либо о нечестности, либо о профессиональной незрелости. Сильный кандидат расскажет даже о мелкой технической ошибке, но с акцентом на то, какие выводы он из нее сделал для своего дальнейшего развития.
Да, я ошибался. И я это признаю)
Это первая часть работ, для векторов. Вторая часть - это создание сервиса, который будет осуществлять всю логику. Сейчас работы идут над второй частью, чуть позже появится статья на эту тему. А уже потом можно написать приложение, которое будет работать так, как вы предлагаете.
Хорошее замечание про обучение. Это действительно моя оговорка. Все выглядит так, что мы модель как будто бы обучили, но это не так. Мы просто подсовываем ей нужный контекст в момент вопроса пользователя. Вот и вся магия.
Что касается вашей ситуации, то тут сложно что-то комментировать.
Спасибо за обратную связь, но я не совсем понимаю о чем вы ))) В статье вообще нет упоминания Авито и телефонных звонков.
Что же касается финансового вопроса, то специально не считал. Но я думаю не так много 20$ Cursor и модели где то еще на 50. Это я прям с запасом взял, скорее всего меньше.
Есть Управление IT-отделом 8
Микроменеджмент — это когда каждый шаг контролируют. У нас наоборот: команда сама решает, что и как делать. Дейли — это инструмент, чтобы не тратить время на «а что происходит?» в личках или на длинных созвонах. Если формат раздражает — скорее всего, проблема в реализации. Повторю свою мысль: хорошо выстроенный процесс не мешает, а экономит время.
В реальной жизни все по другому)) Вы сейчас говорите как обычный разработчик которому скучно. Я же как руководитель, который актуализирует в этот момент все важные моменты. У нас это в среднем занимает 3-5 минут для команды из 8 человек, иногда чуть дольше. Позволяет держать руку на пульсе и не раздражать коллектив одновременно и это отличный инструмент если его правильно "готовить".
Вообще не общаться в коллективе и просто пилить задачки невозможно. Все равно придется с коллегами пересекаться по каким-то вопросам и дейлики - это отличный способ вести такие взаимодействия.
Если что-то не нравится, возможно у вас в компании что-то делают не так. В идеале, конечно, этот процесс не должен угнетать, но на практике почти всегда не так.
Дополнил статью пунктом 4. Спасибо!
У нас в команде ветка создается на каждый тикет-изменение. Если чтобы реализовать фичу нужно разбить задачу на несколько тикетов, будет делаться для каждого тикета своя ветка. Достаточно удобная схема работы. Коммиты делаем по conventional commits.