Pull to refresh

Comments 164

выполнять функции тимлида придётся даже в условиях явной нехватки знаний об управлении, никто не будет ждать, пока ты получишь MBA.

Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства. Ну и некоторые функции исполнять приходилось временно, пока не найдут кого-то, но я делал всё, чтобы как можно сильнее мотивировать руководство найти как можно быстрее :)


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

Сильно тянуть не надо. Можно дождаться что предлагать больше не будут, поскольку найдут другого героя (с меньшей квалификацией). И самое страшное, что он станет вашим начальником. МВА — хорошо, но проблем не решает. Управленческие навыки с опытом приходят. Тут главное понимание, что «сотрудники — это люди».

Предлагают практически на каждом месте работы после года-двух, максимум трех.


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

На моем опыте, что доступа к рычагам нет, для новоиспеченных начальником, это даже плюс. Если ситуация станет значимой, то Вы должны набраться сил, чтобы достучаться до хозяина рычагов (возможно этих рычагов нет и у вашего будущего непосредственного начальника). Вы должны наладить работу не только со своими сотрудниками, но обязательно с руководством, и желательно со своими коллегами из смежных подразделений. Чем эти взаимодействия более проработаны, тем Вам проще работать.

О каких рычагах вы говорите? Вам запрещают уговаривать, убеждать, ругать или спорить? Или вы хотите бюджетом управлять и увольнять по своему желанию?


Если провести аналогию с армией, то вам как младшему офицерскому составу требуется умение раздавать приказы или вы хотите еще и расстреливать тех, кто не нравится и награждать тех кто нравится ни с кем не советуясь?

Младший офицерский состав имеет право расстреливать без суда и следствия за неисполнение приказа подчиненным, имеет право взять под арест, выносить дисциплинарные наказания и поощрения. Я же даже прав доступа к репе лишить не имею прав.

даже прав доступа к репе лишить не имею прав.

А это какой вид рычага: поощрение или наказание? Какой в этом вообще смысл?

Физическое отстранение от работы.

Вот вам еще одна аналогия. Поставили человечка надзирать за рабами, а он взял и убил одного из них. Хозяин будет счастлив?

если он ухайдокал других рабов да еще вытоптал поле и в рояль насрал то имхо будет очень счастлив

Ну вот как раз сделал то, что собирается сделать VolCh

Рабы собственность всё же, имеющий ликвидную ценность. Сотрудник, результат работы которого не принимает никто, или принимает только после глубокой перерабоки, иной раз занимающей больше временами чем реализация с нуля, ценности для компании не имеет, а расходы компания несёт.

Пока у вас будет хотя бы мизерный кусочек сознания, который считает, что сотрудников за ошибки надо жестоко наказывать — вам не дадут тех самых рычагов, потому что это будет как обезьяна с гранатой. Пострадают все.

Не рабы, а мои коллеги.
Не подчинённые, а моя команда.
Не приказывать, а нам совместно находить решения производственных задач. Или даже отойти в сторонку и наблюдать, как это делают без вас. Можно давать советы и делиться опытом, но делать то всё равно им.
Не наказывать, а учиться на ошибках. Ещё и ещё раз. Вместе с ними. Или помогать учиться им.
Не ругать за..., а мотивировать к… Своим примером. Своим идеальным, несокрушимым, честным, прямым примером того, как надо поступать,

Если кто-то в команде откровенно просиживает штаны, а не работает — извините, нам не по пути. Увольнение.

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

А если заранее есть даже малейшее подозрение на зловред в репозиторий от нехорошего сотрудника — зачем такому человеку 2 недели отрабатывать? Я видел, как такого за руки без вещей выводили из офиса два серьёзных человека и он больше не появлялся.

Не про ошибки речь, а про сознательное игнорирование принятых на проекте соглашений указаний.


Не про зловреды речь, а просто про код, написанный в нарушение соглашений.

для этого есть увольнение. Зачем платить зп человеку который не может выполнять свою работу?

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

Младший офицерский состав имеет право расстреливать без суда и следствия за неисполнение
приказа подчиненным

Серьезно? И многих расстреляли уже? В мирное время?


имеет право взять под арест, выносить дисциплинарные наказания и поощрения.

Дисциплинарные наказания — да, в виде наряда вне очереди но никто вам не запрещяет их выносить — заставлять работать в выходной, только учитывайте последствия. Поощрения — возможно только в виде дополнительного отдыха или благодарности перед строем — но и вам никто не мешает то же самое делать.


Я же даже прав доступа к репе лишить не имею прав.

Людей наняли не для того, чтобы вы им работать не давали. Ваша задача не потакать своим комплексам или перфекционизму, а заработать компании денег. Если человек, которому надо платить зарплату сидит без работы, т.к. кто-то умный лишил его прав доступа к репе — то вы разбазариваете деньги, а не зарабатываете.

Насколько я помню. лейтенант может только взыскания и благодарности объявлять, а остальное старший офицерский состав.
И уж тем более расстреливать перед строем он не имеет права и в военное время. Для этого есть трибунал.

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

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


А еще лучше отвлечь его. То же самое и с лейтенантом. Те из лейтенантов, кто слишком увлекаются мантрой "я начальник — ты дурак" переодически просыпаются с дыркой в голове и с отравлением свинцом, особенно в военное время.


Вообще определение лидера:


Лидер — это личность, за которой все остальные члены группы признают право брать на себя наиболее ответственные решения, затрагивающие их интересы и определяющие направление и характер деятельности всей группы.


Т.е. это не функция, а роль в социуме.

Сказать может кто угодно что угодно, но пустые угрозы быстро начинают игнорировать, а пустые обещания "плюшек" начинают раздражать, особенно когда люди слышат не то, что им сказали ("я попрошу, чтоб тебе премию дали"), а что им хочется слышать ("я обеспечу тебе премию").


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

Сказать может кто угодно что угодно, но пустые угрозы быстро начинают игнорировать

А кто говорил об угрозах кроме вас?


а пустые обещания "плюшек" начинают раздражать

А кто говорил о том, что кто-то обещает какие-то плюшки?


а что им хочется слышать ("я обеспечу тебе премию").

И они правы. Не обещайте то, чего не можете выполнить. Вообще деньги не единственный мотиватор.


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

Лидеры не бывают формальными. Бывают формальные управляющие (менеджеры). Задача такого менеджера определить лидера в группе и либо научиться с ним очень хорошо взаимодействовать либо отодвинуть его.


некоторые члены группы могут игнорировать решения формального лидера, понимая
теоретически что к ним могут быть применены формальные меры наказания, но или
рассчитывая на "авось", или относясь к ним равнодушно.

Печально. Судя по тому, что вы написали — у вас отношение к другим людям как к тем, кто не хочет ничего делать в лучшем случае и в худшем вредить. Это не так.

А кто говорил об угрозах кроме вас?

А кто говорил о том, что кто-то обещает какие-то плюшки?

Метод кнута и пряника.


И они правы. Не обещайте то, чего не можете выполнить

Я обещаю попросить и я прошу. Сам премию я могу дать разве что из собственного кармана.


Лидеры не бывают формальными.

Бывают, навскидку http://www.psychologos.ru/articles/view/formalnyy_lider


Судя по тому, что вы написали — у вас отношение к другим людям как к тем, кто не хочет ничего делать в лучшем случае и в худшем вредить. Это не так.

Нет у меня такого отношения по умолчанию. С чего вы взяли? Нормально человек работает — нет претензий. Хорошо — пряник. Плохо — кнут.

Пожалуй я разделяю вашу точку зрения на то, что вам не стоит руководить людьми. Микроменеджмент, самодурство и раздувание из мухи слона. Плохо как со стороны руководства, так и со стороны подчиненных.

Я не говорил, что мне не стоит. Я говорил, что отказываюсь серьезно думать о такой работе, если понимаю, что материально-административные методы мотивации подчиненных мне будут недоступны. И про микроменеджмент ваши фантазии.

И про микроменеджмент ваши фантазии.

Мои фантазии? Зачем мне фантазировать о ваших проблемах? Вы считаете, что это задача тимлида — проверять код за подчиненным, верно?


Я говорил, что отказываюсь серьезно думать о такой работе, если понимаю,
что материально-административные методы мотивации подчиненных мне
будут недоступны.

Вы либо не понимаете о чем говорите, либо не хотите понимать. Материально-административные методы мотивации доступны даже самому простому джуниору, если он знает как ими пользоваться. Вы хотите не методы мотивации — вы хотите устроить диктатуру, чтобы ни с кем не советуясь увольнять людей. Вы хотите единолично решать все, но так не бывает ни на каких уровнях управления. Так бывает только на уровне исполнителей. Исполнитель имеет полный контроль над тем что и как он сделает. Все остальные вынуждены координироваться и идти на компромисы.

Вы считаете, что это задача тимлида — проверять код за подчиненным, верно?

Обычное code review


Материально-административные методы мотивации доступны даже самому простому джуниору, если он знает как ими пользоваться.

Не в рамках рабочих процессов, обычно.


Вы хотите не методы мотивации — вы хотите устроить диктатуру, чтобы ни с кем не советуясь увольнять людей.

Я понимаю, что это не реально. Как минимум из-за трудового законодательства. Но, как минимум, я хочу явных полномочий инициировать формальные процессы взысканий (вплоть до увольнения) и поощрений, а не так что прихожу просить повышения зарплаты, а мне говорят "у него, что, своего языка нет?"

Обычное code review

Сколько Code Review вы можете делать в день? Когда вы собираетесь заниматься своими прямыми обязанностями?


Не в рамках рабочих процессов, обычно.

Распределение бюджета вообще к процессам отношение слабое имеет. Или вы считаете, что выделение определенной суммы каждый месяц прописывается в орг. схеме?


Но, как минимум, я хочу явных полномочий инициировать формальные
процессы взысканий

Так ведь они есть у вас. Как и у любого другого. Вы собираете данные, представляете их на рассмотрение, человеку дают возможность оправдаться или исправиться и если не может — уходит.


а не так что прихожу просить повышения зарплаты, а мне говорят "у него,
что, своего языка нет?"

Справедливо говорят. Либо вы распределяете бюджет и значит сотрудники работают на вас, либо нет. Вы можете сделать то же самое не прося повышения зарплаты, а предлагая поощрить человека. То о чем вы просите — это воопрос вообще не должности, а политики. Вы его хотите решить в стиле слона в посудной лавке. Вас не видят достаточно доверенным или надежным и обижаться в такой ситуации бесполезно.

Code Review входит в мои прямые обязанности.


Вы не понимаете. Я не обижаюсь, я отказываюсь от предложений стать руководителем команды разработки, если мне не дают полномочий для этого. Если на все материально-финансовые вопросы команды я могу отвечать только "идите в кадры-к директору", а на постоянные косяки реагировать только путем самостоятельного переделывания в личное время, но при этом несу полную ответственность за результат.

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

Как вправлять без полномочий? Не поощрить, не наказать.

Вам уже очень популярно Все объяснили. Вы просто не хотите… или не можете услышать. Видимо вы просто хотите, что-бы все «полномочия» вам предоставили на «блюдечке с голубой каемочкой». Такого в реальной жизни не бывает. Все необходимые полномочия у вас, Если вы будете тимлидом- у вас будут. Чего не будет- Аргументированно объясните руководству и появится. Рецепт предельно прост.

Я хочу, по сути, должностную инструкцию, где расписано что я должен делать, что могу, а что не имею права. Но получается всё нужно выяснять методом научного тыка.

Эмм… вы Реально понимаете, что ФСЁ в должностной инструкции «прописано» быть не может? Просто потому, что ВСЕГО предусмотреть невозможно.

Понимаю. Потому "хочу", а не "жду". Но позиция руководства "ты теперь начальник, отвечаешь за всё, а там как хочешь так крутись с теми же полномочиями как у тебя были как у ведущего разработчика" меня демотивирует занимать эту должность.

Вы Снова меня не слышите. Начальство, я Уверен, ценит Грамотных специалистов. Умеющих Обосновать, а не просто «хотеть» чего-то. Вы просто «хотите»? Ну, хотите дальше.
В указанной вами статье "Формальный лидер" есть также описание «неформального лидера». Посмотрите, подумайте — как так получается, что у неформального лидера полномочий нет, но команда преданными глазами смотри на него, слушает его советов, делает то, что он сказал, хотя он не приказывал и поощрить за выполнение не может. Но они делают.
Управляет без кнута и пряника. Нонсенс, не правда ли?
Вам такой встречался? Попробуйте проанализировать, как он это делает. Меняйте своё сознание, чтобы было как у него. Приобретайте новые навыки, такие как у него. Копируйте его. Тренируйтесь.

Как минимум, неформальный лидер не несёт ответственности. Кстати, я в роли такового тоже бывал, обычно после неё и предлагают стать формальным лидером со всей ответственностью.

Командой управляют не только материально-административными методами. Если в ход пускаются эти методы, значит в команде нездоровый климат.

По книге "Лидер и племя" — признаки второго или даже первого уровня мышления («моя жизнь дерьмо — я буду страдать, жаловаться и саботировать» и «вся жизнь дерьмо — я буду выживать») — и практические советы по работе с сотрудниками.

По книге "Как пасти котов" — главы про «Как руководить собой», «Как вести за собой стаю» и практические советы.

Спасибо, почитаю.

А я вот вам скажу, что не стоит.
Вам бы с этим военным подходом идти руководить в армию, но никак не в IT. Читаю комменты и любуюсь просто – должностная инструкция, формальные права. Упаси боже с таким работать, видно, что вы вообще не чувствуете людей и их потребности. Кнут, пряник – вы можете эту бинарную логику оставить для разработки, в менеджменте и общении с людьми все сильно сложнее и по-другому.
Формальный лидер как сущность опять же работает в армии, но не в разработке – если с вами плохо, люди просто уйдут, слишком много хороших мест и слишком мало разработчиков.
Серьезно? И многих расстреляли уже? В мирное время?

Право имеет применять оружие для подчинения в мирное время, например, неисполнение приказа "сдать оружие! или если неисполнение приказа содержит признаки госизмены. А расстреляли или нет кого — дело десятое. Такие права даны прежде всего для предупреждения нарушений, а не как наказание, чтоб даже не думали не выполнять приказ.


но никто вам не запрещяет их выносить — заставлять работать в выходной

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


Если человек, которому надо платить зарплату сидит без работы, т.к. кто-то умный лишил его прав доступа к репе — то вы разбазариваете деньги, а не зарабатываете.

Если человек портит репу, то закрытие доступа к ней означает сокращение убытков.

Если человек портит репу, то закрытие доступа к ней означает сокращение убытков.

Честно говоря звучит очень уж максималистски. Вы уверены, что вам действительно предлагали позиции тим. лида и это не было жестом отчаяния?


Портит репу — это вообще что значит? Ломает билды? Нарушает консистентность хранилища? Коммитит плохой код?

Предлагали как самому технически компетентному из команды.


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

Предлагали как самому технически компетентному из команды.

Часто это может быть минусом. Хороший тех. спец часто бывает перфекционистом.


Коммитит плохой код

Плохой код — переводится как код, который не нравится вам. Это вообще не повод ни для чего. Тот самый перфекционизм технаря, который, увы, придется оставить, переходя в управление.


в том числе ломающий билды, который потом нужно откатывать.

Ваша задача сделать так, чтобы он мог приносить пользу, а не так, чтобы он не мог не приносить вреда. Поговорить — спросить зачем он так делает. Если не умеет — научить. Если не способен научиться — но тогда как он до вас работал? Если он вам просто не нравится — извиняйте. Это часть работы — находить подход к людям, которые вам не нравятся и даже поддерживать нормальные рабочие отношения.


Ломает билды — пусть чинит. Один раз сломал — ошибся со всяким бывает. Поддержать, обучить, прикрепить к более опытному коллеге, чтобы учился. Если не учится и продолжает ломать билды — подсчитать убытки (кол-во сотрундиков, вынужденых пинать баклуши = x, цена рабочего часа одного сотрудника = y, кол-во потерянного времени z:
x y z = $ потери в деньгах — если эти потери больше чем рассходы на найм нового сотрудника — есть смысл пообщаться с руководством на тему замены человека.

Часто это может быть минусом. Хороший тех. спец часто бывает перфекционистом.

Я считаю, что достаточно понимаю где нужно остановиться по дороге к идеальному коду.


Плохой код — переводится как код, который не нравится вам.

Плохой код — переводится как код, который или сам не работает, или сам работает, но ломает что-то другое, либо и то, и другое

Я считаю, что достаточно понимаю где нужно остановиться по дороге к идеальному
коду.

Вы понимаете, что это субъективно?


Плохой код — переводится как код, который или сам не работает, или сам работает,
но ломает что-то другое, либо и то, и другое

Обучение, контроль, внедрение юнит тестирования, если ваши претензии обоснованы.

Конечно.


Всё это есть в той или иной степени, но если прямые указания как решать задачу игнорируются и втихую решаются по своему, то я не воспитатель, чтобы прививать элементарные понятия трудовой дисциплины.

Это звучит как производственный конфликт. В конфликте всегда есть две стороны. Ваше мнение — другой человек должен измениться и вы, судя по вашим словам, не готовы содействовать. Надеюсь у вас есть толковый руководитель или HR, чтобы конфлит разрешить.


Вы с вашим подходом можете неплохо отравить атмосферу. Неопытного сотрудника можно научить, но упертого и конфликтного — лучше изолировать.

и вы, судя по вашим словам, не готовы содействовать

Почему не готов? Готов потратить кучу времени на объяснение своих ожиданий от сотрудника как организационных, так и технических.

Почему не готов? Готов потратить кучу времени на объяснение своих
ожиданий от сотрудника как организационных, так и технических.

Это не конструктивно. Нужен результат, а вы предлагаете процесс без результата и главное ваше предложение вообще никак ни чему не помогает. Потеря вашего времени — это только ваша проблема.


Ваша задача как управляющего коммандой — сделать так чтобы член комманды был эффективен. Как вы этого добъетесь — ваш выбор. Вы можете его обучить, запугать, подбодрить, перевести на другую задачу, и еще миллион вариантов по вашему усмотрению. Я перечислил 4 способа просто из головы, за все комментарии в этой статье вы предложили только два — дать денег или выгнать. Оба способа, предложенные вами — экстремальные. Уволеный сотрудник — это личный фейл руководителя, за исключением сокращений — тогда это фейл департамента развития бизнеса. Фейлы бывают — ничего не поделаешь, но вы же хотите стать руководителем специально для того чтобы фейлить.

Ну так обучить — объяснить, поощрить — обещать дать денег, запугать — обещать уволить. Но если реально ни денег не могу дать, ни уволить, то это перестанет работать очень быстро.

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

Да не в технологиях и процессах дело. Люди могут, но не хотят.

UFO just landed and posted this here

Зачем мне дженкинс? У нас ютрэк и ревью я занимаюсь.


С кем и о чём договариваться? Договоренность это "ты мне — я тебе". Что я могу дать сотруднику? Разве что в бар его сводить за свой счёт.


Ещё мне в голову приходит дать ему премию, например, или поднять зарплату, если вижу, что он по сайтам вакансий лазит.

Мне кажется вам надо пересмотреть требования к новому коду.
IMHO юнит и интеграционные тесты должны запрещать возможность переноса кода в мастер-ветку.
Так же ревьюверы кода должны недопустить просто некачественный код в репозиторий. Тут можно или ждать 1+ разрешений от любого из сокомандников или как минимум 1 от проверенных разработчиков (архитекторов, сеньоров. лучше, если по каждому из языков будет получаться допуск к ревью, т.е. люди не следующие рекомендациям не смогут протилкивать коммиты друг друга).

Простите, если поднял старую ветку — давно тут не был ^_^

Про мастер-ветку речи даже не идёт, исключительно о дев-ветках. И ревьювер я один.

Т.е. ломаются ветки фич?
Может стоит запретить коммитить в них напрямую — только через pull request?
Я уже долго работаю по принципу отдельная ветка на каждую фичу — никаких проблем со сломанным чужим кодом давно не было.

Или ветки фич, над которыми работают два и более разработчика одновременно (банально фронт и бэк), или общая девелопмент ветка, куда сливаются фичи самими разработчиками.

Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства.

Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!

Главная причина такого завуалированного отказа — понимание того, что я не смогу в плане технического развития достаточно быстро бежать чтобы хотя бы на месте оставаться.

Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)

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

Согласен полностью, без мотивационных инструментов работать намного труднее.
Я нашел для себя баланс в должности principal software developer. Минимальный менеджмент команды за счет менеджера в подчинении и можно сфокусироваться на техническом аспекте :)
предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации

Ну по идее это право и не нужно, нужен человек/люди, способные решать эти вопросы, основываясь на вашем фидбэке.

Люди-то, конечно, есть такие. Но вот мотивировать я их могу только одним способом: "или повышаете/увольняете моего подчиненного, или я увольняюсь/возвращаюсь в разработчики". Они меня в шантаже обвиняют :) Но заводить задачи по требованиям бизнеса в бэклоге и разбрасывать их по членам команды я могу и без "лычек" тимлида (собственно обычно после некоторого периода исполнения этой функции и предлагают тимлида)

ну тогда два варианта:
— у этих людей слабая связь с реальным миром
— у вас недостаточная аргументация

Какой вариант вам ближе? )

ну и в моем мире разбрасывание задач — это лишь малая часть работы тимлида

Я ещё и аргументы должен подыскивать кроме как "не справляется с работой" или "очень хорошо справляется с работой, сильно пожалеем если уйдёт куда-то на бОльшую ЗП"?


Я понимаю, что меньшая. Я часто занимаюсь ею и без "лычек" и поэтому мне хотят их дать и навесить ещё больше работы не по самой разработке, а по управлению её процессом, особо меня на это не мотивируя, видимо по принципу: "раз часть работы тимлида на себя взял добровольно, то и с остальным справится".

Что-то, VolCh, помню, как вы отвечали на какой-то мой пост, имея в виду коммуникационную проблему, что представляли людей как чёрные ящики и не знали, как добиться от них детерминированного поведения. Проблема коммуникационная, а вовсе не в курсах или отсутствии рычагов.

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

Эти меры — это "оружие судного дня". В 99.99% случаев им не пользуются.

>не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа

повезло, в основном работает принцип «кто везет на том и едут»
повезло, в основном работает принцип «кто везет на том и едут»

Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.
повезло работнику (Вам), что в вашей компании это не так. Обратная связь требует вовлечения в процесс тех, кто над вами, а это им сложно и менее интересно, чем другие дела.
Я все же ещё раз хочу сказать, что это не везение, а осознанный выбор такой компании :)

Повезло, что такая компания вообще попалась в процессе поиска :)

С вашего позволения немного встряну.
Думаю, что слово осознанный здесь лишнее, чаще это неосознанный выбор компании как коллективного бессознательного.
Если речь про мой случай, то выбор был именно осознанный :)

Представить вашу работу, если вы хоть немного в управлении — это часть вашей работы. Вы и ваша комманда что-то сделали, вы должны представить результат. Это ваша задача представить результат так, чтобы это привлекло внимание и чтобы это было интересно.

Это очень хороший принцип!
Он дает Вам полное моральное право требовать больше:
— Больше зарплату
— Лучше условия
— Больше подчиненных
— Больше интересных задач
— Больше опыта

А если на такие требования отвечают отказом, то это самый главный сигнал о том. что нужно менять работу.
На сколько %% зп тимлида выше разработчика?
Очень сложно ответить на такой вопрос.

Во многих компаниях зарплаты даже внутри команды разработки могут сильно различаться по множеству причин, что уж говорить о разнице в оплате так сильно различающихся должностей тимлида и разработчика. Иногда может быть вполне нормальным, что тимлид получает меньше одного разработчиков, и сам будет требовать ещё большего повышения зарплаты этого разработчика :)

На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.
Вопрос простой, связан ли ваш переход в тимлидерство с повышением личной материальной составляющей или только из-за желания потребовать для кого-то недооцененного ))
Я перешел в тимлидство потому, что мне нравится и хочется этим заниматься :) Да и после определённого уровня зарплата перестаёт становиться основным мотивирующим фактором, важнее становится уже другие вещи — challenge и рост, например. По крайней мере, для меня так.

Ну а правильный рост оценивается и материально тоже.
Ощущение, что ваши ответы контролирует ваш непосредственный начальник, корпоративный блог, этика и все такое. Главное Вызов! Вперед! Ура!

Вы указали, что ранее ваш день длился 11-14 часов, как сейчас обстоит с этим дело?
Как часто случаются переработки и по каким причинам?
Сколько % времени занимает менеджерская работа, а сколько техническая (с кодом, технологиями)?
Думаю, мой начальник не выдержал бы нагрузки, если бы приходилось контролировать такие мелочи. Не понимаю, почему мотивация на challenge у Вас вызывает какой-то сарказм, честно. У всех разная мотивация же.

Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)

С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.
Личный вопрос, можете не отвечать, если сочтете некорректным: как к вашей 10 часовой работе относится семья?
И еще вопросик. Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании?! Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании

Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.

При этом, на мой взгляд, очевидно, что наращивание всяческого EQ/эмпатии и проч будет сильно более трудным процессом, чем наращивание технических навыков.

Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?

Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
Семья понимает, что для меня работа — очень важная составляющая жизни, далеко не только средство зарабатывания денег, и так было всегда :)
Насчет старта карьерной лестницы. Мне кажется, что тимлид это довольно специфичная ступенька. Тимлид сам разработчик, а выше в иерархию начинают подмешиваться выходцы из всех прочих специальностей (QA, аналитики, PM и т.д.) и совсем другая конкуренция, где технические знания значат гораздо меньше разнообразных business skills.
Тимлид сам разработчик

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

А у нас вообще дизайнер одно время был, а я при нём техлидом, решающим технические вопросы.

Тут уже тонкий вопрос терминологии, но, имхо, дизайнер, поставленный над программерами, — это уже менеджер.

Тогда получается, что меня обманули и сделали тимлидом, а сказали, что техлидом? Других лидов точно не было, но не технических вопросов я не касался, из административных исключительно распределение задач по балансу приоритета и оценки, а также компетентности и загруженности разработчика.


Или мы с "менеджером" взяли обязанности тимлида и чётко поделили на технические и нет?

Воистину. Сейчас норма, что тимлид вообще никогда код не видел(ну может в институте) зато МВА, аналитик который в аналитике вообще не смыслит, а уж куча всяких с приставкой Digital-хсгоры вообще море
Это конечно. Правильнее было сказать — тимлид вышел из разработчиков.
>>На сколько %% зп тимлида выше разработчика?
>Очень сложно ответить на такой вопрос.

И все же, как повлияло взятие на себя обязанностей тимлида на вашу ЗП?
Как вы думаете на сколько должна изменятся ЗП после «навешивания лычек TL»?
UFO just landed and posted this here
С точки зрения мотивации статья хорошая, она говорит что старайся и всё получится, с точки зрения информативности — никакая. Вы что-то делали для того, чтобы стать тимлидом? Как-то развивались? Какие трудности для вас были в этом направлении?

Я не вижу сколько-нибудь значимой информации на эту тему. Статью понимаю так так: если проработать пару лет на одном месте предложат должность. Раствор резюме в воде. Раствор истории успеха в воде с ароматизатором Лондон идентичным натуральному. Раствор общих принципов руководства в воде. Ссылка на вакансии.

Особенно мне понравился это пассаж:
«во всём мире уже давно очевиден тренд роста мобильного потребления контента»
Вы своим подчинённым так же задачи ставите?
а вы точно статью прочитали?.. там про трудности написано в разделе про особенности.

и про проработать пару лет на одном месте: автор очень четко описал, что было достигнуто за _один_ год. Считайте такие достижения шаблоном целей, которые должен ставить перед собой тим лид. Они достаточно универсальны.
А вы точно комментарий читали? Давайте ещё раз, более конкретно выражу свою критику.

Статья называется «Как я был разработчиком, а теперь тимлид». Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом. Никаких сведений на эту тему нет. Зато красной нитью проходит мысль — пара лет и ты тимлид. Не по каким-то причинам, а просто потому, что в далёкой-далёкой галактике вуки ударил ногой в бубен.

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

Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными

Как видите, у меня довольно обширный опыт роста из рядового разработчика в тимлида


Не вижу. Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел. Если они есть, приведите пожалуйста цитату. Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.

Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».

Но это чертовски плохой маркетинг. Посмотрите на статьи о лазерной коррекции зрения. Я вообще не разбираюсь в микрохирургии глаза, тем не менее статьи на эту тему читаю на Хабре с удовольствием и даже задумываюсь об операции. Потому, что пишут не копирайтеры, а врачи, которые описывают СВОЙ опыт, описывают интересно и подробно, а не по конспектам пятичасового выступления бизнес-тренера. Это прекрасно читается между строк и сильно влияет на восприятие компании. Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.

Люто плюсую. Мотивационная статья из разряда «Я уеду жить в Лондон… мне Москва будет сниться ...»
Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом


В этой статье я рассказываю только о себе, а опыт у меня вот такой, вы уж не обессудьте :)

Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел

Абсолютно справедливо для первого опыта — был действительно первым разработчиком и вариантов иных и не было практически. Во второй раз я мог оставаться в одной большой команде фронтенда, но сознательно выбрал отдельное направление мобильного веба, тенденцию роста которого я знал, и предполагал, что направление будет расширяться, и, соответственно, там есть возможность роста.
А вот на последнем месте работы так вышло, что я не был и самым первым и, наверняка и самым лучшим тоже не был.
Мне, если честно, вообще сложно рассуждать о том, почему и как выбирали меня, но могу долго рассказывать о том, как выбираю я.

Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.

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

Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».

Я не знаю, как Вы определяете, какое редактирование проходит статья, если интересна «внутренняя кухня» подготовки статей — все довольно просто: автор пишет статью, корректор исправляет ошибки, заинтересованные коллеги комментируют/проясняют какие-то неочевидные моменты, и статья идет «в тираж». К сожалению, каких-то отдельных специалистов-маркетологов, которые помогали бы статью «адаптировать» к каким-то требованиям, у нас пока нет.

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

Я не знаю, могу ли я себя считать реальным профессионалом своего дела, но уж профессионалом в написании статей я не был никогда точно :) Ну и, конечно же, всем не угодить, кому-то и неинтересно будет, это нормально.
Виталий, спасибо за столь развёрнутый комментарий. Как я уже сказал, с точки зрения мотивировки статья хорошая, и ничего против неё я не имею, а указанные недостатки это моё личное мнение, вполне возможно что и не справедливое.

Язык статьи я критикую за избыточность и «трендовость», не исключаю что вы просто слишком много общались не с теми людьми, однако это язык крайне неприятной мне категории людей, для которых речь является не инструментом общения, а способом траты времени либо повышения стоимости текста путём увеличения его размера.

Если внимательно разобрать вашу статью или просто прогнать через анализатор текстов, то она удивительным образом окажется оптимизированной под восприятие среднего читателя Хабра с точки зрения сложности текста, распространённости слов, длины предложения и прочих аналогичных параметров. Не менее же удивительным образом в ней не будет слов с негативной эмоциональной окраской, будет соблюдаться правильная ритмика предложений и прочие правила написания маркетинговых текстов. Надеюсь всё же, что это редактированная статья, а не ваш естественный язык общения.

В любом случае, спасибо за статью. Истории тех, кто «сперва добился», достаточно важны для профессионального становления.

А что за «тренинг по курсу теории ситуационного управления»?
Мы занимались у Натальи Зверёк http://bc-expert.ru/corporate/trainers/zverok/ и у James Brook http://www.strengthspartnership.com/people/james-brook/

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

Почему так лучше.
Отношение стоимости проектов к оплате труда работников — Бывает и 100 к одному. Сто евро работа — 1000 евро стоимость проекта.

Хрестоматийные примеры.
Шведская компания Crisp управляется без начальства уже 3 года.
Интернет-магазин Zappos с 1,5 тысячами сотрудников.
Ким Ир Сен давно умер и стал вечным президентом. Северной Корее теперь живой президент не нужен.
Директор Фунт с дореволюционных времен — номинальный руководитель фирм.
Из описания к одной из вакансий: «Мы рады за наших коллег, которые становятся родителями: +две недели оплачиваемого отпуска и 30 000 р. на первые погремушки:)»

За это отдельный респект! Продвижение семейных ценностей на любом уровне очень важно в наш «европейский» век.

ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры

Так, будучи тимлидом, я попал сюда:)
Спасибо за статью, почерпал для себя несколько важных тезисов.
из статьи не очень понятно — зачем все это надо?
командуя 12 людьми очень сложно оставаться технически подкованным
UFO just landed and posted this here

Если ты хочешь написать кусочек системы — то незачем. Если ты хочешь создавать всю систему — то тебе нужны помощники.


Если ты хочешь писать код, — то незачем. Если хочешь решать проблемы других людей с помощью программных продуктов — то это способ.


Если ты участвовал в 20 продуктах и не видел разницы между SCRUM-ом и скрабом, или RUP-ом и рупором или Agile-ом и Ajax-ом — то поять же незачем. А если ты видишь, что в каком-то месте разработчики (в том числе и ты) теряют кучу времени и знаешь как исправить — то это способ.

Почему из программиста в тимлиды это "уверенный шаг вперед"? Это смена рода деятельности на смежную, и то что там больше платят, или то что тимлид начальник над прогерами, не говорит о том что это рост программиста.

Это рост. Из-за того, что увеличивается зона ответственности. Но это не единственный карьерный путь.

Там сидит по деревом
Доктор Айболит.
Он фулл стак девелопер
И фулл тайм тимлид!
Сам по себе рост численности команды не является позитивным результатом для бизнеса, зря Вы его поставили на первое место в достижениях. Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).
Сам по себе рост численности команды не является позитивным результатом для бизнеса

Вы абсолютно правы. Рост численности команды — один из вариантов того, как можно справиться с увеличением нагрузки. Упомянул я его исключительно для того, чтобы показать retention.
Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).

Так и делаем :) У нас отчеты перед руководством совершенного иного формата, исключительно о результатах, имеющих измеримый business value.
глядя на окружающих меня менеджеров я подозреваю, что вы — первый и единственный в мире их представитель, который вообще задумывается о подобных вещах :)
К счастью, не первый и не единственный, но раз контент интересный, буду продолжать писать :)
Виталий, какие перспективы карьерного роста у разработчика, который не хочет перекладывать бумажки в jira?
Vearutop, не совсем понимаю про «перекладывание бумажек в jira» :)

Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
Есть довольно прикладной вопрос — а какую литературу вы изучали в рамках освоения на новой должности?
Всего несколько книг:
  • Одноминутный менеджер (мотивационное про делегирование и ответственность)
  • Management Of Organizational Behavior (собственно теория)
  • почти все на HBR https://hbr.org
Спасибо большое. Поинтересуюсь.

Короче, становитесь тимлидом. И у вас будет много личной экспертизы и жидкого стула для статей :/

По поводу четвертого пункта, поработать с людьми может каждый, тут скорей индивидуальные качества человека нужны в плане психологии, а ярко выраженный лидер это скорей для отделов с манагерами.
А мне кажется, что лидерские качества просто помогают легче выстраивать правильную атмосферу в команде, и, соответственно, полезны, наверное, любому управленцу.
У нас руководитель программистов а) сам программист б) кроме раскидывания задач, а также программирования непосредственно, заполняет всякие скучные бумаги, вроде табеля в) не имеет реальных рычагов влияния (зп поднять/уменьшить/передвинуть отпуск/даже стул поменять или компьютер)
Единственная разница между руководителем программистов и другими программистами — если руководитель сказал, что будет такое архитектурное решение, то значит такое и будет. Ему и отвечать потом, если что.

Если без табеля, то это скорее техлид или архитектор. А так был таким номинальным руководителем, который приходил к своему руководству что-то просить финансово-материальное для подчиненных, а в ответ получал "у него, что, своего языка нет? пускай приходит и просит прибавку/отпуск/стул/компьютер". А ответственность за работу всей команды полная, называние причины срыва дедлайна типа "фронендеру не подняли зп и он ушёл, потому пришлось раскидывать его работу между всеми кто хоть немного понимает, откладывая их задачи" — "тыжначальник, надо было замотивировать не уходить хотя бы до делайна".

Если такой руководитель «как сказал, так и будет», не прислушиваясь к аргументированной критике его концепции, не убедившись, что вся команда поняла и приняла его мотивацию, то он м… к, а не руководитель. Ему отвечать, а вся команда в заложниках за его кривые/ошибочные/непродуманные решения.
Имелось ввиду, что последнее слово — и решение — именно за руководителем. А вот учитывается мнение других разрабов или нет — это уже ваш вопрос, но там все от случая к случаю.
Приятно слышать, спасибо вам!
В общем, я веду к тому, что навыки разработчика будут неизбежно теряться.


Считаете ли вы допустимым для тимлида не иметь практики программирования?

Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?
Считаете ли вы допустимым для тимлида не иметь практики программирования?

Допустимо, как мне кажется, вообще что угодно, посредственный художник может захватить значительную часть мира, например. Без навыков и опыта программирования тимлиду будет значительно сложнее, придется выстраивать процессы так, чтобы этот недостаток нивелировать.
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?

Я бы тут отталкивался от требований бизнеса, сложно ответить на такой вопрос абстрактно. Может, Ваша система написана на COBOL'е и поддерживается и дорабатывается пятью семидесятилетними программистами? Вряд ли будет уместно тимлиду в такой ситуации искать и внедрять что-то новое :)
Давно искал подобный материал, за это автору огромное спасибо. Но вот у меня все равно какое то странное представление складывается о професии тимлида. По сути на чистую работу с кодом времени уже нет. Голова забита кучей задачей, половину психологических: как померить сотрудников или замотивировать, другая управленческим: как все распаралелить по сотрудникам, третья как все уладить с руководством и т.п. Но ведь технологии не стоят на месте. Постоянно что-то новое появляется. Получается раз на код уже времени нет, то восприятие этого нового для тимлида происходит условно говоря без практики.

Ну к примеру вы упомянули c#. Два года назад вышла 6 версия. Обычный рядовой разработчик почитал доки, попробовал поюзать, написал пару тестовых проектов, понравилось, стал использовать новые фичи в продакшене. Тимлид наверняка тоже почитал доки, возможно попробовал пару тестовых проектов и на этом все. Т.е. в моем понимании, со временем растет прослойка между понимаем кода тимлида и разработчика. С течением большого времени тимлид уже не сможет проконсультировать какого то разработчика потому что у него не будет просто нужной компетенции. Хотя наверно в действительности такой ситуации возможно и не возникнет, или на ее решение будет послан какой нибудь ведущий разрабочик в команде тимлида.

Из всего этого у меня складывается странное представление о профессии тимлида. Поскольку время наш злейший враг, а с его ростом растут и технологии, появляется куча всего нового, и поскольку тимлид уже за этим всем не следит, то получается растет и различие в понимании происходящего на уровне тимлида и на уровне программистов. Отсюда, как мне кажется, выход только один, дальше рости и стать руководителем тимлидов, постепенно выращивая под собой себе подобных. Обратного пути нет, ибо первоначальные навыки будут уже совсем утрачены. И стоять на месте тоже не получится, потому что опять же время наш злейший враг.

Интересно узнать ваше мнение.
Согласен полностью с вашим выводом — если выбрать карьерой управление и, соответственно, не иметь достаточно времени на программирование, неизбежно квалификация техническая будет теряться. Мне в такой ситуации кажется логичным наращивать квалификацию и знания в управлении и расти именно в этой области.

В любом случае, это выбор другой профессии, отличной от разработки.
И это еще не все. Количество вакансий тимлидов на порядок меньше при этом ожидают уровня лида, лидирующего в плане технических знаний, садишься и правишь косяки подчиненного.
Именно по этой причине не очень хочется торопиться и становиться тимлидом раньше лет 30. Потому что тимлид это не программист, а менеджер с техническим бэкграундом. И этот бэкграунд просто не успевает восполняться до равного с другими разработчиками состояния со временем.
if ($chsv < $wanted_chsv) {
return $habr->writeArticle('some words about Im cool');
}
Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.


Спасибо, лучше вы к нам)
Кое-что в статье я нашёл похожим на свой опыт, только пока не получилось ещё окончательно закрепиться в роли тимлида.
По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.
По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.

Абсолютно согласен, в идеале бы вообще знать все заранее, и лишь потом начинать заниматься. Однако проблема обучения без отрыва от производства стоит перед большинством компаний, о которых я знаю, а вот как её решают успешно — с удовольствием бы почитал сам.
Значит под вашим чутким руководством приложение badoo превратилось в такое дерьмо? Сделали уродский дизайн, пролистывание анкет слизали у тиндера, да еще и на мобильных устройствах не переворачивается в зависимости от положения, поэтому планшет приходится переворачивать, что дико бесит. Чувствуется рука профессионалов!
Тяжелое и грустное чувство остается от прочтения этой статьи
Обалденная статья! Благодарю! Прямо эзотерика в чистом виде. Будем учиться, перенимать и применять.

Как можно найти тренинг по курсу теории ситуационного управления Badoo, который Вы упоминали?
Спасибо!

Наталью Зверёк http://bc-expert.ru/corporate/trainers/zverok/ очень и очень рекомендую, её тренинг за кратчайшее время открывает глаза на очень многое.
На странице нет ссылки на тренинг: где, когда и как она его проводит? Онлайн варианты есть? Благодарю!
К сожалению, не в курсе, ведёт ли Наталья вообще регулярные тренинги. Если правильно помню, она их делает только по запросу, но лучше все же связаться с ней и узнать.
Я думаю, единственный способ поддерживать комфортную атмосферу и мотивацию в подобных ситуациях — сохранять максимальную прозрачность во всём, во всех аспектах управления командой.

Вот это безумно круто! У нас был такой же открытый тимлид, было здорово. Но потом он перевёл нас на scrum-методологию и команда получилась с плоской структурой, а сам он ушел в девопс :) И вот уже более полугода живём без тимлида, вроде ничего. Думаете тимлид так уж нужен? По-идее это единая точка отказа (bus-фактор близок к 1).

все они имеют чёткий план роста и развития внутри команды и компании.

Можете поподробнее рассказать что это за план такой?

раз в две недели индивидуальные встречи с каждым сотрудником

У вас правда есть в этом необходимость? Что это даёт?
И вот уже более полугода живём без тимлида, вроде ничего.

Было бы очень интересно узнать о ваших бизнес-процессах, и как команда живет и развивается в рамках плоской структуры. У Вас нет на эту тему публикаций? Если нет, можете лично рассказать?

Можете поподробнее рассказать что это за план такой?

Подробнее лучше сделаю в рамках отдельной статьи, довольно обширная тема. Если вкратце — по каждому разработчику карта мотиваций + компетенций (и вес инвестиций в развитие каждой) + потенциальных путей развития + общая карта необходимых незакрытых «экспертиз» для команды сообразно требования бизнеса и процессов. У каждого критерия есть свой вес, и согласно этим весам определённые планы роста и составляются, обсуждаются с разработчиком, формализуются в виде планов, результаты оцениваются каждый квартал/полгода, поощряются имеющимися мотивационными инструментами.
У вас правда есть в этом необходимость? Что это даёт?

Да, раз в две недели для нас — оптимально. Одна из этих встреч будет посвящена всегда результатам ежемесячной оценки, вторая — разным другим темам. Реже не получается, чаще не имеет смысла :)
О нашей системе performance review очень хорошо рассказывал Алексей Рыбак на techleads meetup #2: https://youtu.be/f-Uf3TiZV2k (отдельно слайды https://www.slideshare.net/BadooDev/techleads-meetup-badoo?ref=https://habrahabr.ru/company/badoo/blog/323630/ )
В СССР руководитель (отдела, группы, направления), в т.ч и в программировании, был:

а) опытным человеком в своём деле, архитектором,
б) был харизматичен (встречал пару, за которыми реально можно было идти в разведку), авторитетен
в) отвечал за коллектив, причём сначала для него шли его люди, и лишь потом он сам
г) умел работать и сам, демонстрируя незаурядные навыки в своём деле

Сегодня это, скорее (по личному опыту) РП спрофуклоном, человек, приставленный бдить, контролировать сроки, удалять худших, нанимать лучших, винтить винтиков-человеков.

Статья для меня — ни о чём. Личность автора как то абстрагирована, оставлены одни чисто западные функции. На его месте мог быть любой другой. Картинка в заставке очень характерна. Надеюсь, это не автор, а модель для демонстрации трусов и плавок. Ничего личного, но пережить период жизни на приличной зарплате с такой моделью, видимо, можно. И это чаще единственный выход сегодня. Но помнить его, встречаться с ним и через 20 лет? Увольте. Только тимлид, только контрольные меткие выстрелы в высунувшуюся душу подчинённых.

Всё выше изложенное — утрировано, конечно.
"… раз в две недели индивидуальные встречи с каждым сотрудником
… если из команды ушёл разработчик, это вина тимлида..."
— прям как красивый роман читал, в хорошем смысле :) У меня все индивидуальные встречи с начальником были только насчёт увольнения :)
Я полностью согласен с подходом, проповедуемым автором статьи, поскольку сам в своё время был руководителем рабочей группы (10-12 человек). Правда, то была не разработка и даже почти не IT. А вот непосредственно в разработке я видел только такую картину: тимлид или архитектор сидят до посинения пишут код сами, никаких межкомандных вопросов не решают, на известие об уходе сотрудника говорят «ну, пока» и так далее.

А какие межкомандные вопросы должны решать тимлиды/архитекторы?

Ошибся в формулировке, имел ввиду межличностные внутри команды. Хотя и межкомандные иногда тоже
Статья действительно мотивирует! А есть ли какие-то митапы для тимлидов?
У нас есть TechLeads-митап: https://habrahabr.ru/company/badoo/blog/323630/ Ближе к осени сделаем следующий. :)
и мы этот митап будем всесторонне развивать и улучшать :) Так что приходите :)
А почему тим-лид ответственнен за всё?
Может стоит больше делегировать команде?
По идее обсуждение и утверждение функционального дизайна должно проходить с командой.
Кодревью тоже разделяется с командой.
Если у вас DevOps команда — проблемы на продакшене тоже решаются командой.
За всё должна отвечать команда. Тим-лид должен решать вопросы, которые не могут решить члены команды (взаимодействие с другими командами, доп. расходы и прочее)

Делегация ответственности — это внутрикомандное решение, перед заказчиком/руководством отвечают за проект тимлиды и ПМы, коль скоро эти должности есть на проекте. Собственно для этого они и вводятся, по-моему, чтобы обеспечить заказчику/руководства фасад к команде, а не коммуницировать с каждым её членом.


Это с одной стороны, а с другой — нужна ли членам команды дополнительная ответственность, согласны ли они с тем, что она им делегируется? Да и во многих случаях найти ответственного затруднительно, например из-за проблем связанных с недостаточной коммуникацией внутри команды. Банально, кто виноват, что Вася и Петя сделали одну и ту же часть задачи, в то время как вторая часть осталась нетронутая?

Для меня ПМ, тим-лид и девелопер — это больше разделение обязанностей. ПМ — получить требования, распределить, организовать, купить и пр. Тим-лид — ближе к тех. вопросам. Дев. разработывает, тестирует и т.д.
А ответственность должна быть на команде (я бы не хотел работать с теми, кто не хочет быть ответственным за то, что делает). Иначе получается, что это не совсем зрелые люди и профессионалы. Я тут ковыряю, но если что сломается — отвечает ПМ. Это больше на уроки труда похоже. Нужны ли он компании?
Ну и ответственность — это не искать виноватого, а сплотиться и решать проблемы. Смотреть код, предвидеть проблемы, подсказывать решения.

Если сделали одну задачу — создаётся впечатление, что постановка хромает. Может слишком большие задачи и их надо бить на подзадачи и жёстко привязывать в «Jira». Или как-то «разговаривать» их друг с другом: обсуждать функциональный дизайн, устраивать демо внутри команды или соседних команд, обсуждение функционала с разбиением на задачи.

Для меня ПМ и тимлид — роли, которые между собой делят административно-управленческие функции на проекте (ПМ больше по общению с заказчиком, а тимлид — "прослойка" между командой и руководством), а технические делят техлид с архитектором в плане выработки глобальных решений, ну а девелоперы их реализуют.


Я не говорю о том, что у рядовых девелоперов не должно быть ответственности, но эта ответственность редко когда должна выходить за рамки команды. Как рядовой разработчик (пускай и ведущий) я, как минимум, захочу серьёзной прибавки к зарплате, если мне "на берегу" объявят, что я буду лично коммуницировать с топами фирмы не как с заказчиками, а как с руководством в рамках даже простого озвучивания эстимейтов перед ними, которые они понимают как взятие на себя обязательств, причём даже не в рабочих часах, а по календарным.

Sign up to leave a comment.