Comments 164
выполнять функции тимлида придётся даже в условиях явной нехватки знаний об управлении, никто не будет ждать, пока ты получишь MBA.
Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства. Ну и некоторые функции исполнять приходилось временно, пока не найдут кого-то, но я делал всё, чтобы как можно сильнее мотивировать руководство найти как можно быстрее :)
Главная причина такого завуалированного отказа — понимание того, что я не смогу в плане технического развития достаточно быстро бежать чтобы хотя бы на месте оставаться. Ну и, как правило, предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации.
Предлагают практически на каждом месте работы после года-двух, максимум трех.
Я это как раз понимаю и прошу раз дают людей в полное подчинение, то дать и рычаги воздействия на них, а не так, что ни зарплату не могу поднять отличившимся или просто очень нужным, ни уволить особо отличившихся.
О каких рычагах вы говорите? Вам запрещают уговаривать, убеждать, ругать или спорить? Или вы хотите бюджетом управлять и увольнять по своему желанию?
Если провести аналогию с армией, то вам как младшему офицерскому составу требуется умение раздавать приказы или вы хотите еще и расстреливать тех, кто не нравится и награждать тех кто нравится ни с кем не советуясь?
Младший офицерский состав имеет право расстреливать без суда и следствия за неисполнение приказа подчиненным, имеет право взять под арест, выносить дисциплинарные наказания и поощрения. Я же даже прав доступа к репе лишить не имею прав.
даже прав доступа к репе лишить не имею прав.
А это какой вид рычага: поощрение или наказание? Какой в этом вообще смысл?
Физическое отстранение от работы.
Вот вам еще одна аналогия. Поставили человечка надзирать за рабами, а он взял и убил одного из них. Хозяин будет счастлив?
Рабы собственность всё же, имеющий ликвидную ценность. Сотрудник, результат работы которого не принимает никто, или принимает только после глубокой перерабоки, иной раз занимающей больше временами чем реализация с нуля, ценности для компании не имеет, а расходы компания несёт.
Не рабы, а мои коллеги.
Не подчинённые, а моя команда.
Не приказывать, а нам совместно находить решения производственных задач. Или даже отойти в сторонку и наблюдать, как это делают без вас. Можно давать советы и делиться опытом, но делать то всё равно им.
Не наказывать, а учиться на ошибках. Ещё и ещё раз. Вместе с ними. Или помогать учиться им.
Не ругать за..., а мотивировать к… Своим примером. Своим идеальным, несокрушимым, честным, прямым примером того, как надо поступать,
Если кто-то в команде откровенно просиживает штаны, а не работает — извините, нам не по пути. Увольнение.
Вместо лишения доступа к репозиторию вообще можно ограничить доступ только к одной ветке, в которую он комитит свой код. Этот код позже надо проревьюить, чтобы не было зловредов.
А если заранее есть даже малейшее подозрение на зловред в репозиторий от нехорошего сотрудника — зачем такому человеку 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 способа просто из головы, за все комментарии в этой статье вы предложили только два — дать денег или выгнать. Оба способа, предложенные вами — экстремальные. Уволеный сотрудник — это личный фейл руководителя, за исключением сокращений — тогда это фейл департамента развития бизнеса. Фейлы бывают — ничего не поделаешь, но вы же хотите стать руководителем специально для того чтобы фейлить.
Зачем мне дженкинс? У нас ютрэк и ревью я занимаюсь.
С кем и о чём договариваться? Договоренность это "ты мне — я тебе". Что я могу дать сотруднику? Разве что в бар его сводить за свой счёт.
Ещё мне в голову приходит дать ему премию, например, или поднять зарплату, если вижу, что он по сайтам вакансий лазит.
IMHO юнит и интеграционные тесты должны запрещать возможность переноса кода в мастер-ветку.
Так же ревьюверы кода должны недопустить просто некачественный код в репозиторий. Тут можно или ждать 1+ разрешений от любого из сокомандников или как минимум 1 от проверенных разработчиков (архитекторов, сеньоров. лучше, если по каждому из языков будет получаться допуск к ревью, т.е. люди не следующие рекомендациям не смогут протилкивать коммиты друг друга).
Простите, если поднял старую ветку — давно тут не был ^_^
Про мастер-ветку речи даже не идёт, исключительно о дев-ветках. И ревьювер я один.
Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства.
Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!
Главная причина такого завуалированного отказа — понимание того, что я не смогу в плане технического развития достаточно быстро бежать чтобы хотя бы на месте оставаться.
Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)
Ну и, как правило, предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации.
Согласен полностью, без мотивационных инструментов работать намного труднее.
предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации
Ну по идее это право и не нужно, нужен человек/люди, способные решать эти вопросы, основываясь на вашем фидбэке.
Люди-то, конечно, есть такие. Но вот мотивировать я их могу только одним способом: "или повышаете/увольняете моего подчиненного, или я увольняюсь/возвращаюсь в разработчики". Они меня в шантаже обвиняют :) Но заводить задачи по требованиям бизнеса в бэклоге и разбрасывать их по членам команды я могу и без "лычек" тимлида (собственно обычно после некоторого периода исполнения этой функции и предлагают тимлида)
— у этих людей слабая связь с реальным миром
— у вас недостаточная аргументация
Какой вариант вам ближе? )
ну и в моем мире разбрасывание задач — это лишь малая часть работы тимлида
Я ещё и аргументы должен подыскивать кроме как "не справляется с работой" или "очень хорошо справляется с работой, сильно пожалеем если уйдёт куда-то на бОльшую ЗП"?
Я понимаю, что меньшая. Я часто занимаюсь ею и без "лычек" и поэтому мне хотят их дать и навесить ещё больше работы не по самой разработке, а по управлению её процессом, особо меня на это не мотивируя, видимо по принципу: "раз часть работы тимлида на себя взял добровольно, то и с остальным справится".
Что-то, VolCh, помню, как вы отвечали на какой-то мой пост, имея в виду коммуникационную проблему, что представляли людей как чёрные ящики и не знали, как добиться от них детерминированного поведения. Проблема коммуникационная, а вовсе не в курсах или отсутствии рычагов.
повезло, в основном работает принцип «кто везет на том и едут»
повезло, в основном работает принцип «кто везет на том и едут»
Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.
Представить вашу работу, если вы хоть немного в управлении — это часть вашей работы. Вы и ваша комманда что-то сделали, вы должны представить результат. Это ваша задача представить результат так, чтобы это привлекло внимание и чтобы это было интересно.
Он дает Вам полное моральное право требовать больше:
— Больше зарплату
— Лучше условия
— Больше подчиненных
— Больше интересных задач
— Больше опыта
А если на такие требования отвечают отказом, то это самый главный сигнал о том. что нужно менять работу.
Во многих компаниях зарплаты даже внутри команды разработки могут сильно различаться по множеству причин, что уж говорить о разнице в оплате так сильно различающихся должностей тимлида и разработчика. Иногда может быть вполне нормальным, что тимлид получает меньше одного разработчиков, и сам будет требовать ещё большего повышения зарплаты этого разработчика :)
На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.
Ну а правильный рост оценивается и материально тоже.
Вы указали, что ранее ваш день длился 11-14 часов, как сейчас обстоит с этим дело?
Как часто случаются переработки и по каким причинам?
Сколько % времени занимает менеджерская работа, а сколько техническая (с кодом, технологиями)?
Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)
С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.
Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании
Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.
При этом, на мой взгляд, очевидно, что наращивание всяческого EQ/эмпатии и проч будет сильно более трудным процессом, чем наращивание технических навыков.
Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
Тимлид сам разработчик
Это очень по-разному везде, даже внутри нашей компании есть тимлиды, активно участвующие и в продуктовой разработке, а бывают и такие, которые код в руках не держали достаточно долго.
А у нас вообще дизайнер одно время был, а я при нём техлидом, решающим технические вопросы.
Тогда получается, что меня обманули и сделали тимлидом, а сказали, что техлидом? Других лидов точно не было, но не технических вопросов я не касался, из административных исключительно распределение задач по балансу приоритета и оценки, а также компетентности и загруженности разработчика.
Или мы с "менеджером" взяли обязанности тимлида и чётко поделили на технические и нет?
>Очень сложно ответить на такой вопрос.
И все же, как повлияло взятие на себя обязанностей тимлида на вашу ЗП?
Как вы думаете на сколько должна изменятся ЗП после «навешивания лычек TL»?
Я не вижу сколько-нибудь значимой информации на эту тему. Статью понимаю так так: если проработать пару лет на одном месте предложат должность. Раствор резюме в воде. Раствор истории успеха в воде с ароматизатором Лондон идентичным натуральному. Раствор общих принципов руководства в воде. Ссылка на вакансии.
Особенно мне понравился это пассаж:
«во всём мире уже давно очевиден тренд роста мобильного потребления контента»
Вы своим подчинённым так же задачи ставите?
и про проработать пару лет на одном месте: автор очень четко описал, что было достигнуто за _один_ год. Считайте такие достижения шаблоном целей, которые должен ставить перед собой тим лид. Они достаточно универсальны.
Статья называется «Как я был разработчиком, а теперь тимлид». Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом. Никаких сведений на эту тему нет. Зато красной нитью проходит мысль — пара лет и ты тимлид. Не по каким-то причинам, а просто потому, что в далёкой-далёкой галактике вуки ударил ногой в бубен.
я был первым нанятым в компанию разработчиком, а когда нагрузки стало больше и у меня перестало хватать времени на всё, мы начали нанимать людей, которых я собеседовал и обучал. В результате я стал тимлидом.
Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными
Как видите, у меня довольно обширный опыт роста из рядового разработчика в тимлида
Не вижу. Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел. Если они есть, приведите пожалуйста цитату. Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.
Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».
Но это чертовски плохой маркетинг. Посмотрите на статьи о лазерной коррекции зрения. Я вообще не разбираюсь в микрохирургии глаза, тем не менее статьи на эту тему читаю на Хабре с удовольствием и даже задумываюсь об операции. Потому, что пишут не копирайтеры, а врачи, которые описывают СВОЙ опыт, описывают интересно и подробно, а не по конспектам пятичасового выступления бизнес-тренера. Это прекрасно читается между строк и сильно влияет на восприятие компании. Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.
Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом
В этой статье я рассказываю только о себе, а опыт у меня вот такой, вы уж не обессудьте :)
Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел
Абсолютно справедливо для первого опыта — был действительно первым разработчиком и вариантов иных и не было практически. Во второй раз я мог оставаться в одной большой команде фронтенда, но сознательно выбрал отдельное направление мобильного веба, тенденцию роста которого я знал, и предполагал, что направление будет расширяться, и, соответственно, там есть возможность роста.
А вот на последнем месте работы так вышло, что я не был и самым первым и, наверняка и самым лучшим тоже не был.
Мне, если честно, вообще сложно рассуждать о том, почему и как выбирали меня, но могу долго рассказывать о том, как выбираю я.
Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.
Это далеко не единственный способ вообще, но в рамках моей статьи я не стремился рассказать обо всём, и так вышел лонгрид изрядный. Но способ Ваш — отличный, и если Вы станете уделять время анализу того, что происходит на рынке, и какие отрасли / направления будут развиваться активнее, возможно, Вам удастся его грамотно использовать и стать тимлидом, как Вы и хотите.
Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».
Я не знаю, как Вы определяете, какое редактирование проходит статья, если интересна «внутренняя кухня» подготовки статей — все довольно просто: автор пишет статью, корректор исправляет ошибки, заинтересованные коллеги комментируют/проясняют какие-то неочевидные моменты, и статья идет «в тираж». К сожалению, каких-то отдельных специалистов-маркетологов, которые помогали бы статью «адаптировать» к каким-то требованиям, у нас пока нет.
Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.
Я не знаю, могу ли я себя считать реальным профессионалом своего дела, но уж профессионалом в написании статей я не был никогда точно :) Ну и, конечно же, всем не угодить, кому-то и неинтересно будет, это нормально.
Язык статьи я критикую за избыточность и «трендовость», не исключаю что вы просто слишком много общались не с теми людьми, однако это язык крайне неприятной мне категории людей, для которых речь является не инструментом общения, а способом траты времени либо повышения стоимости текста путём увеличения его размера.
Если внимательно разобрать вашу статью или просто прогнать через анализатор текстов, то она удивительным образом окажется оптимизированной под восприятие среднего читателя Хабра с точки зрения сложности текста, распространённости слов, длины предложения и прочих аналогичных параметров. Не менее же удивительным образом в ней не будет слов с негативной эмоциональной окраской, будет соблюдаться правильная ритмика предложений и прочие правила написания маркетинговых текстов. Надеюсь всё же, что это редактированная статья, а не ваш естественный язык общения.
В любом случае, спасибо за статью. Истории тех, кто «сперва добился», достаточно важны для профессионального становления.
Почему так лучше.
Отношение стоимости проектов к оплате труда работников — Бывает и 100 к одному. Сто евро работа — 1000 евро стоимость проекта.
Хрестоматийные примеры.
Шведская компания Crisp управляется без начальства уже 3 года.
Интернет-магазин Zappos с 1,5 тысячами сотрудников.
Ким Ир Сен давно умер и стал вечным президентом. Северной Корее теперь живой президент не нужен.
Директор Фунт с дореволюционных времен — номинальный руководитель фирм.
За это отдельный респект! Продвижение семейных ценностей на любом уровне очень важно в наш «европейский» век.
ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры
Так, будучи тимлидом, я попал сюда:)
Спасибо за статью, почерпал для себя несколько важных тезисов.
командуя 12 людьми очень сложно оставаться технически подкованным
Если ты хочешь написать кусочек системы — то незачем. Если ты хочешь создавать всю систему — то тебе нужны помощники.
Если ты хочешь писать код, — то незачем. Если хочешь решать проблемы других людей с помощью программных продуктов — то это способ.
Если ты участвовал в 20 продуктах и не видел разницы между SCRUM-ом и скрабом, или RUP-ом и рупором или Agile-ом и Ajax-ом — то поять же незачем. А если ты видишь, что в каком-то месте разработчики (в том числе и ты) теряют кучу времени и знаешь как исправить — то это способ.
Почему из программиста в тимлиды это "уверенный шаг вперед"? Это смена рода деятельности на смежную, и то что там больше платят, или то что тимлид начальник над прогерами, не говорит о том что это рост программиста.
Доктор Айболит.
Он фулл стак девелопер
И фулл тайм тимлид!
Сам по себе рост численности команды не является позитивным результатом для бизнеса
Вы абсолютно правы. Рост численности команды — один из вариантов того, как можно справиться с увеличением нагрузки. Упомянул я его исключительно для того, чтобы показать retention.
Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).
Так и делаем :) У нас отчеты перед руководством совершенного иного формата, исключительно о результатах, имеющих измеримый business value.
Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
- Одноминутный менеджер (мотивационное про делегирование и ответственность)
- Management Of Organizational Behavior (собственно теория)
- почти все на HBR https://hbr.org
Короче, становитесь тимлидом. И у вас будет много личной экспертизы и жидкого стула для статей :/
Единственная разница между руководителем программистов и другими программистами — если руководитель сказал, что будет такое архитектурное решение, то значит такое и будет. Ему и отвечать потом, если что.
Если без табеля, то это скорее техлид или архитектор. А так был таким номинальным руководителем, который приходил к своему руководству что-то просить финансово-материальное для подчиненных, а в ответ получал "у него, что, своего языка нет? пускай приходит и просит прибавку/отпуск/стул/компьютер". А ответственность за работу всей команды полная, называние причины срыва дедлайна типа "фронендеру не подняли зп и он ушёл, потому пришлось раскидывать его работу между всеми кто хоть немного понимает, откладывая их задачи" — "тыжначальник, надо было замотивировать не уходить хотя бы до делайна".
В общем, я веду к тому, что навыки разработчика будут неизбежно теряться.
Считаете ли вы допустимым для тимлида не иметь практики программирования?
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?
Считаете ли вы допустимым для тимлида не иметь практики программирования?
Допустимо, как мне кажется, вообще что угодно, посредственный художник может захватить значительную часть мира, например. Без навыков и опыта программирования тимлиду будет значительно сложнее, придется выстраивать процессы так, чтобы этот недостаток нивелировать.
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?
Я бы тут отталкивался от требований бизнеса, сложно ответить на такой вопрос абстрактно. Может, Ваша система написана на COBOL'е и поддерживается и дорабатывается пятью семидесятилетними программистами? Вряд ли будет уместно тимлиду в такой ситуации искать и внедрять что-то новое :)
Ну к примеру вы упомянули c#. Два года назад вышла 6 версия. Обычный рядовой разработчик почитал доки, попробовал поюзать, написал пару тестовых проектов, понравилось, стал использовать новые фичи в продакшене. Тимлид наверняка тоже почитал доки, возможно попробовал пару тестовых проектов и на этом все. Т.е. в моем понимании, со временем растет прослойка между понимаем кода тимлида и разработчика. С течением большого времени тимлид уже не сможет проконсультировать какого то разработчика потому что у него не будет просто нужной компетенции. Хотя наверно в действительности такой ситуации возможно и не возникнет, или на ее решение будет послан какой нибудь ведущий разрабочик в команде тимлида.
Из всего этого у меня складывается странное представление о профессии тимлида. Поскольку время наш злейший враг, а с его ростом растут и технологии, появляется куча всего нового, и поскольку тимлид уже за этим всем не следит, то получается растет и различие в понимании происходящего на уровне тимлида и на уровне программистов. Отсюда, как мне кажется, выход только один, дальше рости и стать руководителем тимлидов, постепенно выращивая под собой себе подобных. Обратного пути нет, ибо первоначальные навыки будут уже совсем утрачены. И стоять на месте тоже не получится, потому что опять же время наш злейший враг.
Интересно узнать ваше мнение.
В любом случае, это выбор другой профессии, отличной от разработки.
return $habr->writeArticle('some words about Im cool');
}
Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.
Спасибо, лучше вы к нам)
Кое-что в статье я нашёл похожим на свой опыт, только пока не получилось ещё окончательно закрепиться в роли тимлида.
По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.
По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.
Абсолютно согласен, в идеале бы вообще знать все заранее, и лишь потом начинать заниматься. Однако проблема обучения без отрыва от производства стоит перед большинством компаний, о которых я знаю, а вот как её решают успешно — с удовольствием бы почитал сам.
Как можно найти тренинг по курсу теории ситуационного управления Badoo, который Вы упоминали?
Я думаю, единственный способ поддерживать комфортную атмосферу и мотивацию в подобных ситуациях — сохранять максимальную прозрачность во всём, во всех аспектах управления командой.
Вот это безумно круто! У нас был такой же открытый тимлид, было здорово. Но потом он перевёл нас на 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. А вот непосредственно в разработке я видел только такую картину: тимлид или архитектор сидят до посинения пишут код сами, никаких межкомандных вопросов не решают, на известие об уходе сотрудника говорят «ну, пока» и так далее.
Может стоит больше делегировать команде?
По идее обсуждение и утверждение функционального дизайна должно проходить с командой.
Кодревью тоже разделяется с командой.
Если у вас DevOps команда — проблемы на продакшене тоже решаются командой.
За всё должна отвечать команда. Тим-лид должен решать вопросы, которые не могут решить члены команды (взаимодействие с другими командами, доп. расходы и прочее)
Делегация ответственности — это внутрикомандное решение, перед заказчиком/руководством отвечают за проект тимлиды и ПМы, коль скоро эти должности есть на проекте. Собственно для этого они и вводятся, по-моему, чтобы обеспечить заказчику/руководства фасад к команде, а не коммуницировать с каждым её членом.
Это с одной стороны, а с другой — нужна ли членам команды дополнительная ответственность, согласны ли они с тем, что она им делегируется? Да и во многих случаях найти ответственного затруднительно, например из-за проблем связанных с недостаточной коммуникацией внутри команды. Банально, кто виноват, что Вася и Петя сделали одну и ту же часть задачи, в то время как вторая часть осталась нетронутая?
А ответственность должна быть на команде (я бы не хотел работать с теми, кто не хочет быть ответственным за то, что делает). Иначе получается, что это не совсем зрелые люди и профессионалы. Я тут ковыряю, но если что сломается — отвечает ПМ. Это больше на уроки труда похоже. Нужны ли он компании?
Ну и ответственность — это не искать виноватого, а сплотиться и решать проблемы. Смотреть код, предвидеть проблемы, подсказывать решения.
Если сделали одну задачу — создаётся впечатление, что постановка хромает. Может слишком большие задачи и их надо бить на подзадачи и жёстко привязывать в «Jira». Или как-то «разговаривать» их друг с другом: обсуждать функциональный дизайн, устраивать демо внутри команды или соседних команд, обсуждение функционала с разбиением на задачи.
Для меня ПМ и тимлид — роли, которые между собой делят административно-управленческие функции на проекте (ПМ больше по общению с заказчиком, а тимлид — "прослойка" между командой и руководством), а технические делят техлид с архитектором в плане выработки глобальных решений, ну а девелоперы их реализуют.
Я не говорю о том, что у рядовых девелоперов не должно быть ответственности, но эта ответственность редко когда должна выходить за рамки команды. Как рядовой разработчик (пускай и ведущий) я, как минимум, захочу серьёзной прибавки к зарплате, если мне "на берегу" объявят, что я буду лично коммуницировать с топами фирмы не как с заказчиками, а как с руководством в рамках даже простого озвучивания эстимейтов перед ними, которые они понимают как взятие на себя обязательств, причём даже не в рабочих часах, а по календарным.
Как я был разработчиком, а теперь тимлид