То, что происходит в руби и рельсах сейчас, придет в другие языки и фреймворки лет через 5 :)
Просто рубисты- это бета-тестеры от мира программирования.
Если что-то не зайдет — откинут, а если что-то очень зайдет — примут на вооружение.
То есть в статье про разработчиков (хотфиксы итд), и команду разработки, но вы руководите не разработчиками. Очень интересно бы послушать, кто они тогда?
вся команда осталась
А записочка пошла плюсиком одному человеку? Где же обьективность тогда этой записочки?
разве специалисты не могут действительно учиться чему-то новому?
Конечно могут. В нерабочее время. В рабочее время они должны совершенствовать свои рабочие навыки. Или вы считаете что middle QA это тоже самое что и Senior dev? Или разница в зп и в обязанностях нивелируется, когда сотрудник хочет узнать что-то новое за счет работодателя?
Ну и про качество продукта — очень весело бегать по Алании в поисках банкомата не Акбанка, потому что Акбанк отказывался выдавать мне лиры с тиньковской карты. А гиды в отелях просят платить сбером, потому что тиньков не работает на терминалах некоторых банков, они даже в курсе каких именно. Да что там Акбанк, сбер иногда отказывается ваши карты принимать в банкомат. Причем иногда принимает, иногда — нет. И началось такое последние пару лет, видимо когда разрабы стали куашить, а куашники — что-то делать в команде разработки с не разработчиками.
> который одинаково будет полезен любому тимлиду в любой сфере
Поднимать зп не по perfomance review, а по записочкам? Очень эффективно, наверно, но я воздержусь от таких нововведений у себя в команде.
> назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс,
То есть повесила свою ответственность на другого человека? Была бы разработчиком — сама бы контролировала (ведь это ее обязанность, представляете!)
> в разговоре 1:1 человеку куда проще озвучивать своё мнение
Конечно проще, ведь куашница, которая не шарит, не будет пытаться обьяснить где человек не прав, а просто выслушает и сделает еще одну записочку, углубляя проблему вместо ее решения.
> На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Еще как расскажет, если спросить его, почему он завалил спринт.
> Ни в статье, ни в комментах про пропихивание своих людей не упоминалось
Ну конечно, все вам об этом побежали рассказывать. А в реальности поставили управлять левого человека, не имеющего ни авторитета, ни компетенций, не посовещавшись с командой. Что это если не пропихивание своих людей?
Видимо, это бич крупных компаний — появление начальников — самодуров, которые думают что они изобрели что-то новое, нарушая установленные не ими правила игры, а в реальности — просто собирают грабли, очевидные для прочих.
> Предположим Егор Егоров энтузиаст и любит решать новые нетривиальные задачи, а Пётр Петров предпочитает монотонную работу и любые новшества для него стресс.
Очень интересно от вас услышать, как человек, не имеющий отношения к коду, поймет какая задача тривиальна, а какая монотонна?
> Оба стесняются спорить с лидом
Для этого есть ретроспектива, на которой всегда можно обьяснить свою позицию, а не бегать по кабинетикам и собирать слюни, как то предлагает автор статьи
> диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»
Ну конечно, куашница то поймет в чем именно проблема и почему эта часть системы, которая вызвала у человека стресс, так построена.
> также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит.
Верно. А что является объективной оценкой? Perfomance review, который может провести только программист, понимающий разработческий объем, а не девочка, которая просто была на митингах и делала записочки о работе, и для которой куда больше плюсов от того что человек в пятницу вечером фиксил прод, чем от того что человек закрывал все свои задачи по спринту и брал с беклога стабильно еще на 10 сторипоинтов сверху.
Поэтому и есть должности PM, и есть должность тимлида, и поэтому тимлид должен быть разработчиком в любой орг структуре, просто чтобы понимать то, как программисты работают и что именно они делают, только так можно обьяснить члену команды где он не прав, и объективно понять что он делает хорошо, а что делает не так, и на своем ли он месте.
Если вы думаете что я ни разу не был в командах, где пытались в руководство просунуть своего человека, который не шарит, вы ошибаетесь, и всегда это приводило к плачевным результатам. А если считаете иначе — есть сайт «любимое.ит», там через раз такие истории, и в красках описано к чему такое приводит.
Вы не понимаете, просто надо было платить премии Петру за то что он выкатил говнобилд в пятницу, и хвалить Егора за то что он занимается автотестами вместо разработки критической функциональности проекта. А еще вы наверно не вели заметки о резко испортившемся настроении сотрудников и не общались с ними в интимной обстановочке 1 на 1, а решали все как настоящие технари на скрам-митингах.
> тут позиция выше тимлида так же играет роль,
Конечно, ведь лучший способ захватить власть — это поставить своих на правильные места. И пофиг, что компетенции не соответствуют :) Люди подобные Shoom3301 мне уже встречались, и объяснять им что кумовство к качеству продукта не приводит, — бесполезно, лучше просто расслабиться и смотреть как они сами себя закапывают своими решениями, ведь у этих решений, кроме как «есть разные подходы к орг. структуре.» других объяснений просто нет :)
Перечисленное в статье — это задачи HR и PM, а не тимлида. Вы как угодно можете называть должности в тинькове, но когда в резюме пишется строчка «teamlead команды разработки», там подразумевается конкретный спектр обязанностей технического плана, «играющего тренера», а не менеджер по персоналу + немного PM.
А много ли куашница может рассказать программисту, многому ли сможет обучить или подсказать по коду? Или просто все обязанности тимлида свалятся на техлида (как это и происходит судя по всему в тинькове)?
Хорошо получается — сверху поставили кого-то, кто в разработке не шарит и строчит записочки целыми днями, а на техлида всех собак технических по продукту спустили, еще и джунов с процессами повесили. Тут не то что о карьерном росте заикаться тут как бы не выгореть в хлам и не запроситься обратно в программисты.
Даже в статье уже есть намеки на некомпетентность данного специалиста в вопросе повышения зп. Вот, например, Петр Петров хотфиксил в пятницу вечером. Куашнице это говорит что он хороший и готов помочь проекту. Программисту же это говорит что он раздолбай, потому что выложил не до конца проверенную функциональность перед выходными. для куашницы то, что ведущий инженер занимается автотестами — это хорошо, а для программиста — сигнал того, что человек вместо выполнения своих прямых обязанностей занимается прокастинацией в виде «изучения» скалы и автотестов, вместо работы над своими прямыми обязанностями.
И так далее. А потом людей повышают только за то что они громче всех вякали на совещаниях, и вместо качественного продукта мы получаем неподдерживаемое нечто, чьи карточки не видят в упор зарубежные терминалы или чьи платежи висят в авторизации по несколько дней.
То есть для вас тимлид — это не эксперт, который обладает достаточными компетенциями в процессах разработки и проекте, которыми он занимается, и который принимает технические и архитектурные решения, и обладает достаточным авторитетом в команде, а менеджер по персоналу, которого поставили сверху приглядывать за программистами?
Решение ваше, а от себя могу лишь порадовваться, что отсылал ваших рекрутеров, тем кто хочет строить карьеру в IT, в вашей компании делать нечего, ведь каким бы хорошим программистом бы ты не был, ты все равно будешь кандидатом на тимлида хуже, чем блондинка — куашница.
> А как называется должность того, кто оглядывается и занимается подбными назначениями?
Product owner или CTO. Но явно не тот, кто считает что поставить QAшника тимлидом разработчиков — отличная идея. Тимлидом должен быть разработчик, иначе получится то что описано в статье — психологические игры, а не выстраивание разработки.
Это задачи HR, PM, но точно не тимлида (ну кроме собеседований).
Задачи тимлида — организация кода, рабочего процесса и взаимодействий с другими командами.
Пример хорошей организации — когда Петр Перов не хотфиксит ночью в пятницу, а Егоров Егор занимается разработкой на JAVA как ведущий инженер, а не пишет автотесты на SCALA, как middle QA специалист.
Если у вас при такой организации все хорошо работает технически, то оглядитесь — скорее всего у вас уже есть настоящий тимлид, просто вы его еще не назначили.
Хахаха, вот ты не в курсе что гугл делает ARM процессор для консьюмерского рынка. Делать на нем серьезную работу никто не собирается, он для телефончиков. По твоим некомпетентным маразматическим критериям даже гугл — средний бизнес, так что ты так обсратушки, что просто смешно.
Сам себе что-то выдумал, сам доказал обратное. Может тебе хоть немного изучить тему, мальчик, прежде чем лезть в разговоры взрослых людей?
В путаете причину и следствие. То что вы назвали — это следствие укрупнения бизнеса. И яндекс по вашему же определению — крупный.
И если уж говорите «посмотри в учебниках» — то давайте ссылки, где это написано, чтобы я ознакомился с полным текстом, а не вашей интерпретацией, которая в корне не корректна.
И если вас не устраивают рашенские маразматики, то в ЕС критерии крупного бизнеса — более 250 человек, а также более 50 млн евро или общим балансом 43 млн евро.
Может если кругом маразматики, то маразматик — это вы? Особенно мне понравилось «торгующий гавённой третьесортной рикламкой вразнос». Смешно. Сам этот маразм выдумал?
Есть конкретные критерии крупного бизнеса — доход более 2 млрд руб, количество работников — более 251 человек. Яндекс под эти критерии подходит. Так что это не я взял, это общие критерии для РФ, могли бы и погуглить, а не задавать глупых вопросов.
И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.
В нормальных компаниях за завершенный и работающий проект, даже если он не пошел по каким-то причинам, исполнителей премируют. Не должен исполнитель отвечать за промашки руководства, он наемный работник, а не бизнес партнер.
Крупные компании прощупывают ниши, это нормально. Но сваливать на разрабов проблемы маркетинга это низко, подобное можно ждать от шаражки с взбаломошным директором, но никак от крупной компании.
Просто рубисты- это бета-тестеры от мира программирования.
Если что-то не зайдет — откинут, а если что-то очень зайдет — примут на вооружение.
Ну да — как мы видим, есть там как минимум один самозванец (или самозванка).
Ну а менеджмент в стиле «Ой все» наверно очень эффективен по вашему мнению, как я вижу?
А записочка пошла плюсиком одному человеку? Где же обьективность тогда этой записочки?
Конечно могут. В нерабочее время. В рабочее время они должны совершенствовать свои рабочие навыки. Или вы считаете что middle QA это тоже самое что и Senior dev? Или разница в зп и в обязанностях нивелируется, когда сотрудник хочет узнать что-то новое за счет работодателя?
Ну и про качество продукта — очень весело бегать по Алании в поисках банкомата не Акбанка, потому что Акбанк отказывался выдавать мне лиры с тиньковской карты. А гиды в отелях просят платить сбером, потому что тиньков не работает на терминалах некоторых банков, они даже в курсе каких именно. Да что там Акбанк, сбер иногда отказывается ваши карты принимать в банкомат. Причем иногда принимает, иногда — нет. И началось такое последние пару лет, видимо когда разрабы стали куашить, а куашники — что-то делать в команде разработки с не разработчиками.
Значит там минимум 4 лида, как того требует скрам
> который одинаково будет полезен любому тимлиду в любой сфере
Поднимать зп не по perfomance review, а по записочкам? Очень эффективно, наверно, но я воздержусь от таких нововведений у себя в команде.
> назначить мидла/сеньора в помощь плюс периодически контролировать как двигается прогресс,
То есть повесила свою ответственность на другого человека? Была бы разработчиком — сама бы контролировала (ведь это ее обязанность, представляете!)
> в разговоре 1:1 человеку куда проще озвучивать своё мнение
Конечно проще, ведь куашница, которая не шарит, не будет пытаться обьяснить где человек не прав, а просто выслушает и сделает еще одну записочку, углубляя проблему вместо ее решения.
> На ретроспективе Петров не расскажет Вам что он нервный и рассеянный последние две недели из-за того, что у него пожилой родственник заболел ковидом.
Еще как расскажет, если спросить его, почему он завалил спринт.
> Ни в статье, ни в комментах про пропихивание своих людей не упоминалось
Ну конечно, все вам об этом побежали рассказывать. А в реальности поставили управлять левого человека, не имеющего ни авторитета, ни компетенций, не посовещавшись с командой. Что это если не пропихивание своих людей?
Очень интересно от вас услышать, как человек, не имеющий отношения к коду, поймет какая задача тривиальна, а какая монотонна?
> Оба стесняются спорить с лидом
Для этого есть ретроспектива, на которой всегда можно обьяснить свою позицию, а не бегать по кабинетикам и собирать слюни, как то предлагает автор статьи
> диалог должен быть конструктивный, а не на уровне «ты дурак и ничего не умеешь»
Ну конечно, куашница то поймет в чем именно проблема и почему эта часть системы, которая вызвала у человека стресс, так построена.
> также важно иметь объективную оценку сотрудника, иначе получится что сотрудник весь год думал что он молодец и старается, а тимлид весь год думал что он разгильдяй и постоянно косячит.
Верно. А что является объективной оценкой? Perfomance review, который может провести только программист, понимающий разработческий объем, а не девочка, которая просто была на митингах и делала записочки о работе, и для которой куда больше плюсов от того что человек в пятницу вечером фиксил прод, чем от того что человек закрывал все свои задачи по спринту и брал с беклога стабильно еще на 10 сторипоинтов сверху.
Поэтому и есть должности PM, и есть должность тимлида, и поэтому тимлид должен быть разработчиком в любой орг структуре, просто чтобы понимать то, как программисты работают и что именно они делают, только так можно обьяснить члену команды где он не прав, и объективно понять что он делает хорошо, а что делает не так, и на своем ли он месте.
Если вы думаете что я ни разу не был в командах, где пытались в руководство просунуть своего человека, который не шарит, вы ошибаетесь, и всегда это приводило к плачевным результатам. А если считаете иначе — есть сайт «любимое.ит», там через раз такие истории, и в красках описано к чему такое приводит.
> тут позиция выше тимлида так же играет роль,
Конечно, ведь лучший способ захватить власть — это поставить своих на правильные места. И пофиг, что компетенции не соответствуют :) Люди подобные Shoom3301 мне уже встречались, и объяснять им что кумовство к качеству продукта не приводит, — бесполезно, лучше просто расслабиться и смотреть как они сами себя закапывают своими решениями, ведь у этих решений, кроме как «есть разные подходы к орг. структуре.» других объяснений просто нет :)
А много ли куашница может рассказать программисту, многому ли сможет обучить или подсказать по коду? Или просто все обязанности тимлида свалятся на техлида (как это и происходит судя по всему в тинькове)?
Хорошо получается — сверху поставили кого-то, кто в разработке не шарит и строчит записочки целыми днями, а на техлида всех собак технических по продукту спустили, еще и джунов с процессами повесили. Тут не то что о карьерном росте заикаться тут как бы не выгореть в хлам и не запроситься обратно в программисты.
Даже в статье уже есть намеки на некомпетентность данного специалиста в вопросе повышения зп. Вот, например, Петр Петров хотфиксил в пятницу вечером. Куашнице это говорит что он хороший и готов помочь проекту. Программисту же это говорит что он раздолбай, потому что выложил не до конца проверенную функциональность перед выходными. для куашницы то, что ведущий инженер занимается автотестами — это хорошо, а для программиста — сигнал того, что человек вместо выполнения своих прямых обязанностей занимается прокастинацией в виде «изучения» скалы и автотестов, вместо работы над своими прямыми обязанностями.
И так далее. А потом людей повышают только за то что они громче всех вякали на совещаниях, и вместо качественного продукта мы получаем неподдерживаемое нечто, чьи карточки не видят в упор зарубежные терминалы или чьи платежи висят в авторизации по несколько дней.
Решение ваше, а от себя могу лишь порадовваться, что отсылал ваших рекрутеров, тем кто хочет строить карьеру в IT, в вашей компании делать нечего, ведь каким бы хорошим программистом бы ты не был, ты все равно будешь кандидатом на тимлида хуже, чем блондинка — куашница.
Product owner или CTO. Но явно не тот, кто считает что поставить QAшника тимлидом разработчиков — отличная идея. Тимлидом должен быть разработчик, иначе получится то что описано в статье — психологические игры, а не выстраивание разработки.
Задачи тимлида — организация кода, рабочего процесса и взаимодействий с другими командами.
Пример хорошей организации — когда Петр Перов не хотфиксит ночью в пятницу, а Егоров Егор занимается разработкой на JAVA как ведущий инженер, а не пишет автотесты на SCALA, как middle QA специалист.
Если у вас при такой организации все хорошо работает технически, то оглядитесь — скорее всего у вас уже есть настоящий тимлид, просто вы его еще не назначили.
Сам себе что-то выдумал, сам доказал обратное. Может тебе хоть немного изучить тему, мальчик, прежде чем лезть в разговоры взрослых людей?
И если уж говорите «посмотри в учебниках» — то давайте ссылки, где это написано, чтобы я ознакомился с полным текстом, а не вашей интерпретацией, которая в корне не корректна.
И если вас не устраивают рашенские маразматики, то в ЕС критерии крупного бизнеса — более 250 человек, а также более 50 млн евро или общим балансом 43 млн евро.
Может если кругом маразматики, то маразматик — это вы? Особенно мне понравилось «торгующий гавённой третьесортной рикламкой вразнос». Смешно. Сам этот маразм выдумал?
И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.
В нормальных компаниях за завершенный и работающий проект, даже если он не пошел по каким-то причинам, исполнителей премируют. Не должен исполнитель отвечать за промашки руководства, он наемный работник, а не бизнес партнер.
> сначала человек учится нормально делать дела, а потом его повышают