Именно так у меня организовано. Я лид у группы в примерно 50 человек среди которых и формируются команды, причем в разных задачах главным в рамках задачи становится тот кто в конкретной задаче, вчерашний главный в другой задаче может стать подчиненным, в том числе синьор у джуна, и никаких проблем
Это вы что то свое придумали. Уж кто не стоит над проектом так это архитектор. Информация 100%, поверьте мне как выпускнику эпам архитект скул и руководителю службы архитекторов в компании с ИТ штатом в примерно 1000 человек (уже нет, но был такой этап карьеры в прошлом).
SAFe это у нас для 700 человек. Для,50 норм 1 тимлид, я,например таким являюсь. Но у нас (конкретно в мой команде) дейли нет ибо бессмысленно. 2 раза в неделю общая встреча с жестким таймингом 30 минут. Естественно, не 50 человек над задачей работает, под конкретные задачи динамически формируются. В них нет выделенных должностей, просто обьединение на одну задачу. А так (почти) все со всеми работают. И да, дел у меня хватает и без кодирования, хотя и умею (не на всех стеках которые есть в команде). Я даже задачи не распределяю, это координатор делает, он же примерную трудоемкость оценивает, за мной только нетиповые случаи. Если бы я и код писал я очень быстро стал одновременно говнокодером и говноменеджером одновременно.
А еще бизнес может никогда не вырости до необходимости всего этого. Несколько лет назад была неплохая статья, типа вы не в google и с вероятностью 99% ваша компания не будет такой. Поэтому тащить все наработки гигантов в любой проект это так себе идея. Думаю как раз Ваш подход правильный
Хороший человек это не профессия. Про научиться можно всему это ерунда. Я как менеджер отвечающий за результат заинтересован в профессионалах которые знают свое дело, если они при этом еще и софт скиллами отлично, нет тоже нормально. К счастью, я всегда находил с HR общий язык, на брифе сразу говорю мне нужны профессионалы а не участники утренника в детском саду, и все ок, приводят на интервью нормальных как мне надо
Про производительность кто интересно ерунду написал, автор или переводчик? А так два этих вида для разных типовых запросов. Аместь еще хранение срезами на даты
Вы в универе сразу квантовую физику учили или сначала школьную повторяли на продвинутом уровне? То то и оно. Имхо для уровня разработчика самое оно, ему нужны базовые вещи там возможно какой то сайд пайплайнчик сделать не для основного проекта, например какой то вспомогательный инструмент может даже не для прода, поправить что то несложное. А на что то серьезное (если оно когда то понадобится) специалисты будут привлечены.
Так что автор все по делу пишет, а вы, извините, ерунду
Тут тоже история неочевидная. Руководитель если он нормальный сам мониторит потенциал своих сотрудников, неявно :-) И условно если приходит условный Вася хороший разработчик но который... тут пропускаем... и говорит я хочу развиваться то итог вряд ли будет хорошим. Скорее я зайду к Пете и Маше и скажу, вижу у вас хорошо и с коммуникациями и с таймменеджментом, хотите попробовать поразвиваться? Из моего опыта 2 из 3 скажут не очень хотим, с теми кто захочет составляем ИПР, причем лидирую я как руководитель, сотрудник может договориться со мной о корректировках.
Выполнение ИПР увеличит мой доход хотя бы на 30%? Именно за счет его выполнения? Ответ нет. Значит это инструмент переливания из пустого в порожнее. Я использую ИПР только для слтрудников которых готовлю на серьезное повышение связаное со сменой профиля деятельности. Это единицы на большой коллектив и не каждый год. И то сомневаюсь в эффективности этого процесса
Мир it тесен, и персонажи (никакого негатива в термине) гуляющие по собеседованиям как по свиданиям попадают на карандаш :-) если конечно речь не о джунских максимум мидловских позициях...
Прочитал бегло но отторжения требования не вызвали. Все это изучается в ВУЗе на профильной специальности, джун аналитик это прежде всего аналитик а во вторую очередь джун. Так что все что описано он делает, на своем уровне естественно. Я не теоретически говорю а вполне практически, да у меня есть в управлении джуны вчерашние студенты которые вполне тянут все вышеперечисленное после трехмесячного натаскивания на исп. сроке. Если это после нормального ВУЗа а не переученые за полгода [все равно кто] схема рабочая
IDE очень хорошая но поезд ушел, я уже год на VS Code на всех проектах. Довольно быстро поивыкаешь, эргономика немного хуже, возможностей не меньше. Брейнсам спасибо но больше нам не по пути, кряков и левых оплат не будет.
Возвращаясь к теме, читал алгоритмические трюки для программистов и от математики к обобщенному программированию, первая как трюки интересна но на кодревью я бы такой код не пропустил в боевой проект. Вторая очень интересная но скорее в академическом плане
Я готов поспорить что и трети этих книг Вы не прочли, это физически невозможно если Вам не 80 лет и 60 из них ушло на чтение. Книжная полка (бумажная) у меня точно не меньше но витались там только определенные темы которые нужны в работе. Уверен, что третий том Кнута разве что открывался, Дейт кижка хорошая (хотя непонятно какой в ней смысл кроме академического последние лет 30) ну а Конкретная математика имхо ее одну год можно читать год (если не по диагонали пробежать). Седжвика и кормена непонятно зачем в них 80% одно и то же (два кирпича по алгоритмам). В общем, не верю, чисто механически невозможно
Писали бы уж "мне лично one to one в практике не встречалось" . One to one (оно же горизонтальное партиционирование) типпичный прием при создании нагруженых систем, я буквально ежедневно вижу то на что "почти никто не решается" в реализации десятков разных систем...
По исходной статье - название действительно не соответствует содержанию
В нерабочее время
Коротко: да
Я не совсем такой (но действую так же). Мне тупо нравится писать код, я это делаю. В нерабочее время. В рабочее делаю как и Вы
Именно так у меня организовано. Я лид у группы в примерно 50 человек среди которых и формируются команды, причем в разных задачах главным в рамках задачи становится тот кто в конкретной задаче, вчерашний главный в другой задаче может стать подчиненным, в том числе синьор у джуна, и никаких проблем
Это вы что то свое придумали. Уж кто не стоит над проектом так это архитектор. Информация 100%, поверьте мне как выпускнику эпам архитект скул и руководителю службы архитекторов в компании с ИТ штатом в примерно 1000 человек (уже нет, но был такой этап карьеры в прошлом).
Зачем группе 5 человек выделеный лид?! Это какой то неправильный подход
SAFe это у нас для 700 человек. Для,50 норм 1 тимлид, я,например таким являюсь. Но у нас (конкретно в мой команде) дейли нет ибо бессмысленно. 2 раза в неделю общая встреча с жестким таймингом 30 минут. Естественно, не 50 человек над задачей работает, под конкретные задачи динамически формируются. В них нет выделенных должностей, просто обьединение на одну задачу. А так (почти) все со всеми работают. И да, дел у меня хватает и без кодирования, хотя и умею (не на всех стеках которые есть в команде). Я даже задачи не распределяю, это координатор делает, он же примерную трудоемкость оценивает, за мной только нетиповые случаи. Если бы я и код писал я очень быстро стал одновременно говнокодером и говноменеджером одновременно.
А еще бизнес может никогда не вырости до необходимости всего этого. Несколько лет назад была неплохая статья, типа вы не в google и с вероятностью 99% ваша компания не будет такой. Поэтому тащить все наработки гигантов в любой проект это так себе идея. Думаю как раз Ваш подход правильный
Хороший человек это не профессия. Про научиться можно всему это ерунда. Я как менеджер отвечающий за результат заинтересован в профессионалах которые знают свое дело, если они при этом еще и софт скиллами отлично, нет тоже нормально. К счастью, я всегда находил с HR общий язык, на брифе сразу говорю мне нужны профессионалы а не участники утренника в детском саду, и все ок, приводят на интервью нормальных как мне надо
Про производительность кто интересно ерунду написал, автор или переводчик? А так два этих вида для разных типовых запросов. Аместь еще хранение срезами на даты
Вы в универе сразу квантовую физику учили или сначала школьную повторяли на продвинутом уровне? То то и оно. Имхо для уровня разработчика самое оно, ему нужны базовые вещи там возможно какой то сайд пайплайнчик сделать не для основного проекта, например какой то вспомогательный инструмент может даже не для прода, поправить что то несложное. А на что то серьезное (если оно когда то понадобится) специалисты будут привлечены.
Так что автор все по делу пишет, а вы, извините, ерунду
Тут тоже история неочевидная. Руководитель если он нормальный сам мониторит потенциал своих сотрудников, неявно :-) И условно если приходит условный Вася хороший разработчик но который... тут пропускаем... и говорит я хочу развиваться то итог вряд ли будет хорошим. Скорее я зайду к Пете и Маше и скажу, вижу у вас хорошо и с коммуникациями и с таймменеджментом, хотите попробовать поразвиваться? Из моего опыта 2 из 3 скажут не очень хотим, с теми кто захочет составляем ИПР, причем лидирую я как руководитель, сотрудник может договориться со мной о корректировках.
Выполнение ИПР увеличит мой доход хотя бы на 30%? Именно за счет его выполнения? Ответ нет. Значит это инструмент переливания из пустого в порожнее. Я использую ИПР только для слтрудников которых готовлю на серьезное повышение связаное со сменой профиля деятельности. Это единицы на большой коллектив и не каждый год. И то сомневаюсь в эффективности этого процесса
Коротко и по делу. Вполне разумные советы
Прочитал бегло но отторжения требования не вызвали. Все это изучается в ВУЗе на профильной специальности, джун аналитик это прежде всего аналитик а во вторую очередь джун. Так что все что описано он делает, на своем уровне естественно. Я не теоретически говорю а вполне практически, да у меня есть в управлении джуны вчерашние студенты которые вполне тянут все вышеперечисленное после трехмесячного натаскивания на исп. сроке. Если это после нормального ВУЗа а не переученые за полгода [все равно кто] схема рабочая
IDE очень хорошая но поезд ушел, я уже год на VS Code на всех проектах. Довольно быстро поивыкаешь, эргономика немного хуже, возможностей не меньше. Брейнсам спасибо но больше нам не по пути, кряков и левых оплат не будет.
Возвращаясь к теме, читал алгоритмические трюки для программистов и от математики к обобщенному программированию, первая как трюки интересна но на кодревью я бы такой код не пропустил в боевой проект. Вторая очень интересная но скорее в академическом плане
Я готов поспорить что и трети этих книг Вы не прочли, это физически невозможно если Вам не 80 лет и 60 из них ушло на чтение. Книжная полка (бумажная) у меня точно не меньше но витались там только определенные темы которые нужны в работе. Уверен, что третий том Кнута разве что открывался, Дейт кижка хорошая (хотя непонятно какой в ней смысл кроме академического последние лет 30) ну а Конкретная математика имхо ее одну год можно читать год (если не по диагонали пробежать). Седжвика и кормена непонятно зачем в них 80% одно и то же (два кирпича по алгоритмам). В общем, не верю, чисто механически невозможно
Писали бы уж "мне лично one to one в практике не встречалось" . One to one (оно же горизонтальное партиционирование) типпичный прием при создании нагруженых систем, я буквально ежедневно вижу то на что "почти никто не решается" в реализации десятков разных систем...
По исходной статье - название действительно не соответствует содержанию