Pull to refresh
-20
0

Пользователь

Send message
Вы ничего не понимаете, ведь пальцы они только вперед и назад могут двигаться, никак не по кругу.
То, что происходит в руби и рельсах сейчас, придет в другие языки и фреймворки лет через 5 :)
Просто рубисты- это бета-тестеры от мира программирования.

Если что-то не зайдет — откинут, а если что-то очень зайдет — примут на вооружение.
> НЕ только разработчики.
Ну да — как мы видим, есть там как минимум один самозванец (или самозванка).

Ну а менеджмент в стиле «Ой все» наверно очень эффективен по вашему мнению, как я вижу?
То есть в статье про разработчиков (хотфиксы итд), и команду разработки, но вы руководите не разработчиками. Очень интересно бы послушать, кто они тогда?

вся команда осталась

А записочка пошла плюсиком одному человеку? Где же обьективность тогда этой записочки?

разве специалисты не могут действительно учиться чему-то новому?

Конечно могут. В нерабочее время. В рабочее время они должны совершенствовать свои рабочие навыки. Или вы считаете что middle QA это тоже самое что и Senior dev? Или разница в зп и в обязанностях нивелируется, когда сотрудник хочет узнать что-то новое за счет работодателя?

Ну и про качество продукта — очень весело бегать по Алании в поисках банкомата не Акбанка, потому что Акбанк отказывался выдавать мне лиры с тиньковской карты. А гиды в отелях просят платить сбером, потому что тиньков не работает на терминалах некоторых банков, они даже в курсе каких именно. Да что там Акбанк, сбер иногда отказывается ваши карты принимать в банкомат. Причем иногда принимает, иногда — нет. И началось такое последние пару лет, видимо когда разрабы стали куашить, а куашники — что-то делать в команде разработки с не разработчиками.
> возможно там 40 разработчиков

Значит там минимум 4 лида, как того требует скрам

> который одинаково будет полезен любому тимлиду в любой сфере

Поднимать зп не по 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 человек. Яндекс под эти критерии подходит. Так что это не я взял, это общие критерии для РФ, могли бы и погуглить, а не задавать глупых вопросов.

И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.

В нормальных компаниях за завершенный и работающий проект, даже если он не пошел по каким-то причинам, исполнителей премируют. Не должен исполнитель отвечать за промашки руководства, он наемный работник, а не бизнес партнер.

Крупные компании прощупывают ниши, это нормально. Но сваливать на разрабов проблемы маркетинга это низко, подобное можно ждать от шаражки с взбаломошным директором, но никак от крупной компании.
Все приходит с опытом, автор в этом плане абсолютно прав
> сначала человек учится нормально делать дела, а потом его повышают
Банальненько, конечно, но найдутся те кто не знает этого всего.
Как линукс установишь, дадим тебе покушать еще один миллиардик, дорогой.
3. Все офисы одинаковые.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity