Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!
Для начала несколько слов обо мне
Меня зовут Виталий Шароватов. Сейчас я – тимлид команды из 12 разработчиков в подразделении мобильного веба в Badoo. Уже полтора года я живу в Лондоне. Но на этой должности я оказался в результате довольно долгого пути, историю которого я расскажу далее.
Мне 32 года, общий опыт работы в индустрии — почти 15 лет. Начинал я, как и многие, с фриланса. Много и плодотворно занимался серверным программированием, немного – системным администрированием.
- Программировать начал с PHP 4, потом был PHP 5, писал на C# для ASP.NET MVC и ASP.NET Web Forms, писал на VBScript в ASP.
- Построил несколько систем с IE ActiveX-компонентами, интегрирующих клиентский код с разными устройствами (сканерами паспортов, сканерами штрихкодов, принтерами наклеек и так далее).
- Построил сеть, объединяющую три географически разделённых офиса на D-Link’ах DFL с дублированием канала и VPN.
- Администрировал Exchange, Windows 2003 AD.
Но больше всего я любил клиентскую разработку.
RealRussia. 2007–2012
Впервые я стал тимлидом в RealRussia. Это британская компания, занимающаяся въездным туризмом в Россию. Сначала она занималась только организацией получения российских туристических и бизнес-виз для англичан, но за время моей работы были созданы сервис заказа билетов на поезда, интегрированный с системой «Экспресс-3» и РЖД, сервис заказа отелей, а также полноценные интегрированные Workflow-бэкенды для обслуживания всех процессов.
В плане моего развития происходило всё вполне стандартно: я был первым нанятым в компанию разработчиком, а когда нагрузки стало больше и у меня перестало хватать времени на всё, мы начали нанимать людей, которых я собеседовал и обучал. В результате я стал тимлидом.
Мне повезло, что рынок труда разработчиков на тот момент был наполнен предложениями, и нам удавалось нанимать людей, очень похожих на меня: у них было такое же отношение к работе (ответственность и проактивность), они относились практически к такому же личностному типу (по натуре я довольно энергичный, и с тяжёлыми на подъём коллегами мне было бы трудно сработаться). Работать в таком коллективе было очень просто, я не видел в этом какого-то вызова.
К тому же в то время я ещё не был уверен, что мне хочется заниматься руководством. Я был достаточно юн и хотел сосредоточиться на работе с JavaScript, поэтому через несколько лет работы тимлидом в RealRussia я переехал из города Волжский (Волгоградская область) в Москву и устроился в Mail.Ru Group на должность фронтенд-разработчика.
Mail.Ru Group. 2012–2015
После ухода из RealRussia я хотел найти какой-нибудь highload-проект, в котором было бы достаточно технических и организационных вызовов. В результате я стал фронтенд-разработчиком в проекте «Мой Мир», где занимался обычной продуктовой разработкой, а через некоторое время мне предложили работать над мобильной версией проекта.
Зная, что во всём мире уже давно очевиден тренд роста мобильного потребления контента, я, конечно же, согласился. Мои обязанности заключались во всё той же классической продуктовой разработке. Из интересного технически — в тот период я провёл исследование и реализовал полноценную поддержку работы сайта в Opera Mini.
Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными. Однако дальнейших возможностей роста в проекте я не видел, да и сама атмосфера и стиль управления мне не совсем подходили, времени на технические задачи стало меньше, а заметных результатов в управлении достичь не получалось.
Для меня всегда было важно видеть возможности роста, брать на себя больше ответственности и добиваться результатов. Поэтому, пройдя собеседование в Badoo, я снова решил отказаться от управления и вернуться на шаг назад – к должности разработчика. Я видел, что в этой компании я смогу пойти дальше.
Badoo. 2015–наши дни
В Badoo очень развита культура роста сотрудников внутри компании: Head of product вырос за несколько лет из Paralegal, CTO – из разработчика, большинство Heads of departments тоже выросли из разработчиков. Что уж говорить про тимлидов! Меня, как и многих других приходящих в компанию разработчиков, мотивированных перспективами роста и вызовами, не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа.
Как видите, у меня довольно обширный опыт роста из рядового разработчика в тимлида, а также сознательного отказа от этой роли.
И сейчас я поделюсь с вами теми необычными знаниями, чувствами и опытом, которые я получил и испытал за эти годы. Ведь я не одинок на своём пути: многим разработчикам на определённом этапе своей карьеры приходится отвечать на вопрос: «Стоит ли мне становиться тимлидом?»
Расскажу, что вас ждёт, если вы решитесь. Начинаем с главных особенностей должности тимлида.
Особенности
Особенность №1. Ты и один, и не один
Если ты – рядовой разработчик, то отвечаешь только за собственные действия и их последствия. Но, став тимлидом, ты вдруг перестаёшь быть сам по себе. Ты – больше не отдельная функциональная единица, а составная. Но в то же время только ты один представляешь свою команду перед руководством и другими командами. Ты – ответственное лицо в любых ситуациях, от решения проблем с зарплатой до технических вопросов.
Неожиданно результаты работы всей команды становятся твоими собственными результатами. Я очень странно себя чувствовал первое время, заполняя свой отчёт по результатам месяца и внося в него что-то вроде «сделано столько-то продуктовых фичей», словно всё это сделал лично я.
То же самое относится и к проблемам. Ты уже не можешь сказать: «А, это Саня (Лёха, Андрюха) допустил баг!» Нет, за этот баг теперь отвечаешь именно ты вне зависимости от того, кто писал код.
Это тяжёлая ноша, вызов, или что-то, что у тебя получилось бы принять легко и непринужденно? Можешь ли ты доверять людям, с которыми работаешь?
Особенность №2. Неопределённость
Когда ты – просто разработчик, то привыкаешь к нескольким предсказуемым источникам неопределённости. Например, баги в браузере, странное поведение устройства. Обычно ты знаешь, как с ними работать, или хотя бы можешь как-то спрогнозировать риски. Но, став тимлидом, ты оказываешься лицом к лицу с новым источником неопределённости: с людьми.
Люди — не роботы, они могут болеть, уставать, терять мотивацию, быть счастливыми, злыми, грустными, могут конфликтовать, забывать что-то, могут быть очень продуктивными или наоборот. И раз ты отвечаешь за команду, то должен как минимум поддерживать её производительность. Нужно принять тот факт, что всё контролировать просто невозможно. Техническому специалисту осознать и принять это особенно сложно. Получается, что ты несёшь ответственность за результат и проблемы, но контролировать все факторы не можешь.
Особенность №3. Все разные
В RealRussia все члены моей команды были так на меня похожи, что мне стало казаться, что вообще все должны быть со мной на одной волне с точки зрения подходов, мотивации, психотипа, мироощущения и силы воли. Я работал с каждым разработчиком так, как если бы я работал с самим собой.
Но в условиях современного рынка труда найти разработчиков, которые будут копиями тимлида, невероятно трудно, а взаимодействовать с разными людьми одинаково – непродуктивно.
Банальный пример: можно постоянно довольно жёстко подталкивать к цели одного человека (можно даже поставить перед ним недостижимую цель), он расценит это как вызов и будет демонстрировать максимальную эффективность. Однако применив этот подход к человеку другого психотипа, можно потерять разработчика — он будет серьёзно демотивирован тем, что время идёт, а ему не удаётся даже приблизиться к достижению цели.
В общем, мне пришлось осознать необходимость индивидуального подхода к каждому члену команды в зависимости не только от его психологического типа, но и от ситуации. Ведь в условиях неопределённости люди очень по-разному работают даже в рамках одного проекта. Кстати, эту концепцию нужно донести до каждого члена команды – на горизонтальном уровне общение тоже не должно приносить дискомфорт.
Довольно трудно достигать целей вместе с людьми, сильно отличающимися друг от друга, так как приходится всегда находить баланс между разными мотивациями людей для того, чтобы двигаться вперёд и быть продуктивными.
Ещё один пример в качестве иллюстрации. Программист всегда очень тщательно проводит ревью кода, искренне любит делать ревью «правильно», тратя на анализ кода по несколько часов, чтобы вникнуть во все детали. Но как тимлид ты знаешь, что для многих задач такая тщательность ревью просто избыточна. Станешь ли ты пытаться изменить подход своего сотрудника, попытаешься заставить его прекратить делать любимое дело и нанесёшь тем самым удар по его мотивации? Или лучше будет направить его усилия на ревью тикетов, где его страсть к такой работе принесёт максимальную выгоду?
Особенность №4. Нехватка знаний и опыта
Поработав какое-то время с людьми, осознаёшь, что нужно развивать в себе эмпатию, чтобы понимать их чувства, реакцию на твои слова, на слова других — на то, что происходит в команде и вокруг неё. Как минимум необходимо фильтровать очень многое из происходящего, чтобы замечать вещи, которые могут навредить психологической атмосфере в команде.
Затем нужно научиться формировать эту атмосферу, создавать командный дух.
Прирождённые лидеры, с самого детства собирающие вокруг себя и ведущие за собой людей, часто формируют атмосферу команды интуитивно, на уровне неосознанной компетентности. Такой человек, став тимлидом, практически сразу будет чувствовать себя на своём месте. Остальным же придётся вырабатывать и развивать в себе лидерские качества, что называется, в процессе: выполнять функции тимлида придётся даже в условиях явной нехватки знаний об управлении, никто не будет ждать, пока ты получишь MBA.
Когда начинаешь читать литературу по менеджменту, поражаешься тому, «насколько глубока кроличья нора»: как мало ты знаешь и как остро стоит проблема освоения нужных навыков. И, учитывая огромное количество информации по этой теме, очень трудно понять, с чего начать самообразование.
Мне повезло – в Badoo помогли сориентироваться среди сотен тысяч источников информации о менеджменте и организовали хороший тренинг по курсу теории ситуационного управления. Он простой и предельно практичный, всем рекомендую – в кратчайшие сроки вы получите минимальный набор инструментов, готовых к использованию в хаосе первых месяцев опыта управления.
Особенность №5. Нехватка времени
Нужно быть готовым к тому, что никогда не будет хватать времени, чтобы сделать всё – всегда будет оставаться что-то, что нужно сделать.
А новый уровень неопределённости всегда влечёт за собой множество новых задач, которые необходимо срочно решить. Запросы от других команд, когда что-то идёт не так, эскалация проблем от разработчиков, административные вопросы и так далее.
Одна только поддержка текущих процессов разработки отнимает кучу времени. И чем больше людей в команде — тем больше времени: раз в две недели индивидуальные встречи с каждым сотрудником, kick-off-встречи и VQA, планёрки, ретроспективы, месячные оценки.
У меня в команде сегодня 12 человек, и если бы наши разработчики не были так самодостаточны и ответственны, то я не смог бы поддерживать работу над проектом, есть и спать.
В какой-то момент приходит осознание того, что просто физически невозможно самостоятельно выполнить значительную часть работы, и единственный способ выжить — делегировать задачи. Но с делегированием связаны две особенности:
Доверие. Ты понимаешь, что твоё задание по каким-то причинам может быть не выполнено вовремя (или вообще не выполнено). Все мы — живые люди, разработчики могут болеть, их производительность может снизиться, может случиться что-то ещё. Всегда есть риск.
- Техническая экспертиза. Есть вероятность, что в каком-то вопросе ты сильнее (или имеешь больше опыта), чем разработчик, которому ты ставишь задачу. Но ты не можешь делать всё сам не только по причине отсутствия времени – делегировать разработчикам сложные задачи необходимо для их роста и развития.
Можешь ли ты принять для себя вероятность провала из-за человеческого или технического фактора? И если это случится, будешь ли ты демотивирован, подавлен, потому что кто-то тебя подвёл, или сохранишь позитивный настрой и попытаешься найти способ улучшить ситуацию?
Особенность №6. Отвлекающие факторы
Тимлида отвлекают весь день — мессенджеры, телефон, почта, люди. Постепенно твой мозг привыкает к такому формату работы, когда нужно держать в голове много дел одновременно и при необходимости быстро переключаться между ними. Этот навык развивается точно так же, как и все остальные ежедневно тренируемые навыки — сравнивая планы на день любого дня этой зимы и такого же дня год назад, я поражаюсь разнице: сейчас «тяжеловесных» задач, с которыми удаётся справляться в течение дня, намного больше.
Однако этот навык сам по себе иногда становится проблемой. Привыкнув к частому переключению между делами, мозгу становится очень трудно сосредоточиться на чём-то одном, когда это необходимо. Начинает ощущаться почти физический дискомфорт из-за того, что не нужно переключать внимание, и ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры. Когда мне приходится фокусироваться на чём-то долгое время, я использую технику Pomodoro — какое-то время фокусируюсь полностью, а потом позволяю себе отвлечься на что-нибудь. Таким образом убирается психологический дискомфорт от того, что не удалось удержать внимание, – отвлечение фактически легитимизируется.
Из-за отвлекающих факторов поначалу ещё труднее планировать своё время, что может привести к работе без отдыха и сна. Ты думаешь: «Я только начинаю, поэтому должен быть максимально продуктивен. Поработаю пока по 11–14 часов день, чтобы быстрее достичь цели», работаешь в таком режиме месяц, два, три, «выгораешь», заболеваешь на несколько дней, а затем вновь вступаешь на этот порочный круг. Я через это прошёл и после нескольких циклов «переработка – «выгорание» – восстановление – переработка» заметил, что моя производительность всё больше и больше снижается.
Поэтому нужно осознать, что время — ресурс невосполнимый, но постоянный, здоровье же — ресурс не только невосполнимый, но и постоянно уменьшающийся. Соответственно, приоритет очевиден — здоровье.
Начать использовать время более продуктивно можно с помощью усовершенствования процессов, делегирования, отработки навыков переключения между задачами, повышения качества планирования. Если поставить перед собой задачу работать в течение разумного количества часов в день, то единственным вариантом будет сосредоточиться на грамотном планировании времени и расстановке приоритетов. При этом в результате усовершенствования процессов и продуктивность неизбежно улучшится.
Особенность №7. Компромиссы
Из-за всё той же нехватки времени постоянно приходится идти на компромиссы, выбирать приоритетные задачи и проблемы. Есть известный метод: сортируйте задачи по срочности, важности и по срочности + важности и действуйте в соответствии с получившимися списками. Но что делать, если даже список «срочно + важно» так велик, что не удаётся с ним разобраться в разумный срок?
По мере работы над проектом расстановка приоритетов становится почти интуитивным действием. Но когда только начинаешь, навыки определения паттернов ещё не столь развиты, и ты постоянно советуешься с коллегами насчёт выбора приоритетных задач. На это уходит много времени и сил, а иногда бывает сложно найти человека, способного помочь с приоритизацией процессов.
Прежде чем заработала моя интуиция, я придерживался простого критерия «наименьшего из зол». Выбирая из двух задач, я спрашивал себя: что потеряет компания/ команда, если не будет выполнена одна из них?
Поиск баланса при расстановке приоритетов — сложная задача, подход к которой необходимо постоянно пересматривать. К примеру, есть один час и две задачи: поговорить по душам с разработчиком, который демотивирован из-за какого-то конфликта, либо помочь другому сотруднику исправить баг, возникающий у миллионов пользователей. Что может помочь в определении приоритета? Сразу возникает много вопросов: какая атмосфера в команде? насколько устойчив конкретный разработчик к конфликтным ситуациям? сколько может подождать решение проблемы с мотивацией разработчика? возможно ли за пять минут разговора перенести полноценный разговор по душам на завтра? каков масштаб бага? есть ли эксперт в области подобных проблем, которому можно было бы делегировать оказание помощи разработчику? Ответы помогают сравнить важность совершенно разных по сути задач. А с опытом управления растёт и количество вопросов, и на многие из них ответы получаются практически интуитивно.
При этом очень важно быть морально готовым к неудачам, принять как данность, что на компромиссы придётся идти всегда, и, если что-то пошло не так, нужно всего лишь проанализировать неудачу и извлечь урок, постоянно повышая эффективность своей системы интуитивного распознавания приоритетов: сделав неправильный выбор, просто фиксируйте неудачу как негативный результат. Главное – не впадать в уныние из серии «Ой, я облажался, я плохо справляюсь». Не ошибается тот, кто ничего не делает.
Особенность №8. Политика компании
Главная цель расстановки приоритетов — оставаться как можно более эффективным в любых условиях.
И одно из условий, с которым постоянно сталкивается тимлид, — соблюдение баланса интересов компании в целом и своей команды в частности. Приходится постоянно быть «зонтиком», «фильтром», посредником, находиться под давлением со всех сторон, но действовать при этом исключительно в соответствии с приоритетами.
В моей практике была ситуация: очень квалифицированный и опытный QA-инженер требовал от разработчиков излишне высокого качества кода, а те не спорили с ним, а беспрекословно исправляли все баги, даже те, которые могли бы быть исправлены после развёртывания фичи (или которые вовсе не нужно было трогать). Мне в этом случае нужно было заметить проблему, обсудить и зафиксировать стандарт качества с product-менеджерами и техническими экспертами (разработчиками нашей команды и других отделов), выработать правила приоритезации багов, зафиксировать процесс исправления багов в соответствии с приоритетам в рамках принятого стандарта качества, а дальше следить, чтобы «проявления характера» (QA-инженер был очень настойчив) не мешали функционированию спроектированного процесса.
«В комплекте» с должностью тимлид получает очень высокий уровень ответственности за осуществление контроля над реализацией стратегии, над протеканием процессов и мотивацией. И действуя в соответствии с выбранной стратегией, нужно быть готовым получать обратную связь – как позитивную, так и негативную.
Особенность №9. Ты в ответе за всё
Если из команды ушёл разработчик, это вина тимлида. Если производительность труда в команде оставляет желать лучшего, это вина тимлида. Если один сотрудник груб с другими, это вина тимлида. И если команда добивается успеха и все счастливы, то это успех в том числе тимлида.
Всё это снова приводит нас к вопросу о принятии рисков и работе в условиях неопределённости. Всё время будут возникать трудные вопросы и проблемы. Что делать, если компании нужно сократить расходы? Как поддержать мотивацию и комфортную атмосферу в коллективе, если придётся уволить нескольких человек, которые не сделали ничего плохого, были хорошими членами команды и продуктивными специалистами?
С сокращением расходов я, к счастью, не сталкивался, а вот увольнять людей мне приходилось. И это было тяжело, даже если человек понимал, что он был недостаточно продуктивен и не хотел или не мог научиться тому, что было необходимо.
Я думаю, единственный способ поддерживать комфортную атмосферу и мотивацию в подобных ситуациях — сохранять максимальную прозрачность во всём, во всех аспектах управления командой. Если люди доверяют тимлиду как единственному источнику всей важной информации, если они знают, что проблемы всегда будут решаться, а не замалчиваться, то им будет легче принимать даже плохие новости.
Результаты
Результат №1. Демотивация и мотивация
Я столкнулся с несколькими видами демотивации, и вы тоже можете с ними столкнуться.
Из-за нехватки времени даже на управление командой наверняка будет не хватать времени писать код. Даже если команда совсем небольшая, процессы отлажены, и всё работает как часы, всё равно у тимлида не будет столько времени на программирование, как раньше. Не будет времени и на эксперименты с новыми технологиями. В общем, я веду к тому, что навыки разработчика будут неизбежно теряться.
Для меня ключевым фактором принятия окончательного решения стать тимлидом было чёткое видение того, что в компании нет потолка роста, и мне дадут столько ответственности, сколько я смогу и захочу на себя взять (и обязательно добиться результатов). В таких условиях хочется работать больше и продуктивнее, и демотивационные факторы нисколько не сдвигают чашу весов в свою сторону.
Ещё одна демотивационная вещь, с которой я столкнулся: все процессы идут настолько постепенно, что никогда не удастся всё улучшить в один присест.
Мотивация, доверие и атмосфера в коллективе выстраиваются поэтапно, много времени уходит на получение личной технической экспертизы в условиях быстро меняющихся условий и приоритетов. Развитие процессов, помогающих команде быстрее разрабатывать продукт, тоже требует времени. В моём случае все процессы изменялись параллельно с моим развитием как тимлида. Но даже если бы я заранее чётко представлял процессы, к которым мы пришли спустя год работы, всё равно эти изменения нельзя было бы применить сразу — люди достаточно сложно принимают новое, и поэтапность в подобных перестройках подчас просто необходима.
Когда ты разработчик, твоя продуктивность обычно достаточно легко оценивается в краткосрочной перспективе (даже эпик-проекты разбиваются на оцениваемые достижимые майлстоуны). Но, став тимлидом, приходится гораздо больше думать о стратегии и довольно долго дожидаться каких-то заметных результатов. Это может быть проблемой, если ты привык сразу видеть плоды своего труда.
В работе тимлида достаточно демотивирующих факторов. Но вряд ли люди становились бы тимлидами, если бы не было чего-то хорошего.
Работа тимлида идеально подходит людям, чья основная мотивация — справляться с вызовами (работать над проектами, требующими взаимодействия множества людей, справляться с большой нагрузкой и т. п.). Есть куча вещей, в которых тебе не хватает знаний и опыта, которые невозможно контролировать, но при этом нужно сохранять высокую продуктивность. В общем, эта работа — самый большой вызов, с которым я сталкивался.
Полное принятие вызова, готовность брать на себя всё больше ответственности, меняться самому и помогать меняться подчинённым, желание двигать вперёд большие стратегические проекты. Если вас это привлекает это, то работа тимлида — для вас.
Наконец, последняя мотивация, не имеющая отношения к вызову и развитию, – желание быть образцом для подражания для своих коллег. Развиваясь, ты неизбежно выбираешь для себя образец для подражания — в семье, на работе, где угодно. Если у вас есть дети, вы знаете, какое это удовольствие — побудить кого-то к росту, улучшению, самообразованию. Сложно описать словами удовольствие от того, что удалось помочь кому-то стать лучше и осознать результаты своего роста.
Результат №2. Победы
Несмотря на неопределённость и дефицит всего и вся, благодаря мотивации и её подкреплению обратной связью хочется добиваться всё больших побед в роли тимлида. Для меня главная победа — сделать команду счастливой и вместе с ней достичь хорошего результата.
Иногда тимлиды бывают слишком мягкотелыми – и команда расслабляется: все довольны, но для компании результат почти нулевой. Другая крайность — тоталитарный тимлид, выжимающий из людей все соки и не задумывающийся о том, что такой подход разрушает мотивацию в долгосрочной перспективе и что рано или поздно люди из-за этого начнут покидать команду. На мой взгляд, главная задача тимлида — найти баланс между достижением результатов и сохранением позитивной атмосферы в команде. Помоги людям развиваться, подсказывай, как им добиться лучших результатов в своей работе. Помоги им создать то, чем они будут гордиться. Помоги понять их ценность для компании. Помоги им получать удовольствие от работы и прикрой от всего, от чего, по твоему мнению, нужно прикрыть. Возможно, звучит всё это несколько пафосно, но без искренней заботы о людях не удастся выстроить полноценно доверительные отношения с подчинёнными.
Поверьте, невероятно приятно в ответ на такую заботу получать положительную обратную связь со всех уровней.
Заключение и текущие достижения
Прошло больше года с тех пор, как я стал тимлидом в Badoo. И вот результаты команды мобильного веба.
- Команда выросла с четырёх до 12 разработчиков (лишь один разработчик за это время ушёл от нас по семейным обстоятельствам), все они имеют чёткий план роста и развития внутри команды и компании.
- Год назад мы доставляли в среднем одну фичу в неделю (иногда – меньше), теперь — до десяти фич в неделю. Кроме того, мы фиксим кучу багов, стали релизиться раз в день и чаще (а раньше релизились раз в одну – две недели), нагнали отставание в 200 продуктовых фич, ежедневно релизим что-то без QA (и нет, это не означает плохое качество фич).
- Была достигнута поставленная цель стать экспериментальной платформой — мы быстро проводим важные А/В-тестирования, на основании результатов которых другие команды выбирают, какой вариант идей продуктовых менеджеров стоит реализовать.
Мы сконцентрированы на людях и прозрачности, помогаем друг другу расти и увеличивать производительность. Мы много работаем и много развлекаемся.
Если вы, несмотря на все «но», выбираете управление и начинаете с роли тимлида, я искренне желаю вам удачи! Учитесь, развивайтесь, каждый день спрашивайте себя: что можно было сделать лучше? что идёт не так? Будьте готовы к негативной обратной связи и воспринимайте её как инструмент роста; будьте честны с собой и сотрудниками, помогайте им развиваться и расти; научитесь находить удовольствие в построении островков порядка в море хаоса и неопределённости — и всё получится. Надеюсь, мой опыт будет вам полезен и, конечно, с удовольствием отвечу на любые вопросы.
P. S. Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.
iOS-разработчик: [описание]
Android-разработчик: [описание]
Комментарии (153)
NeverIn
12.04.2017 12:25+1>не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа
повезло, в основном работает принцип «кто везет на том и едут»
vsh
12.04.2017 12:41повезло, в основном работает принцип «кто везет на том и едут»
Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.NeverIn
12.04.2017 13:10повезло работнику (Вам), что в вашей компании это не так. Обратная связь требует вовлечения в процесс тех, кто над вами, а это им сложно и менее интересно, чем другие дела.
vsh
12.04.2017 13:39Я все же ещё раз хочу сказать, что это не везение, а осознанный выбор такой компании :)
Minotaurus
12.04.2017 15:15С вашего позволения немного встряну.
Думаю, что слово осознанный здесь лишнее, чаще это неосознанный выбор компании как коллективного бессознательного.
boblenin
12.04.2017 22:20+1Представить вашу работу, если вы хоть немного в управлении — это часть вашей работы. Вы и ваша комманда что-то сделали, вы должны представить результат. Это ваша задача представить результат так, чтобы это привлекло внимание и чтобы это было интересно.
lilek
12.04.2017 12:56Это очень хороший принцип!
Он дает Вам полное моральное право требовать больше:
— Больше зарплату
— Лучше условия
— Больше подчиненных
— Больше интересных задач
— Больше опыта
А если на такие требования отвечают отказом, то это самый главный сигнал о том. что нужно менять работу.
NeverIn
12.04.2017 12:32На сколько %% зп тимлида выше разработчика?
vsh
12.04.2017 13:38+4Очень сложно ответить на такой вопрос.
Во многих компаниях зарплаты даже внутри команды разработки могут сильно различаться по множеству причин, что уж говорить о разнице в оплате так сильно различающихся должностей тимлида и разработчика. Иногда может быть вполне нормальным, что тимлид получает меньше одного разработчиков, и сам будет требовать ещё большего повышения зарплаты этого разработчика :)
На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.NeverIn
12.04.2017 14:17Вопрос простой, связан ли ваш переход в тимлидерство с повышением личной материальной составляющей или только из-за желания потребовать для кого-то недооцененного ))
vsh
12.04.2017 16:07+1Я перешел в тимлидство потому, что мне нравится и хочется этим заниматься :) Да и после определённого уровня зарплата перестаёт становиться основным мотивирующим фактором, важнее становится уже другие вещи — challenge и рост, например. По крайней мере, для меня так.
Ну а правильный рост оценивается и материально тоже.NeverIn
12.04.2017 17:09+3Ощущение, что ваши ответы контролирует ваш непосредственный начальник, корпоративный блог, этика и все такое. Главное Вызов! Вперед! Ура!
Вы указали, что ранее ваш день длился 11-14 часов, как сейчас обстоит с этим дело?
Как часто случаются переработки и по каким причинам?
Сколько % времени занимает менеджерская работа, а сколько техническая (с кодом, технологиями)?vsh
12.04.2017 17:36+1Думаю, мой начальник не выдержал бы нагрузки, если бы приходилось контролировать такие мелочи. Не понимаю, почему мотивация на challenge у Вас вызывает какой-то сарказм, честно. У всех разная мотивация же.
Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)
С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.pesh1983
12.04.2017 21:16+1Личный вопрос, можете не отвечать, если сочтете некорректным: как к вашей 10 часовой работе относится семья?
NeverIn
12.04.2017 21:36И еще вопросик. Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании?! Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
vsh
13.04.2017 13:08Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании
Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.
При этом, на мой взгляд, очевидно, что наращивание всяческого EQ/эмпатии и проч будет сильно более трудным процессом, чем наращивание технических навыков.
Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
vsh
13.04.2017 12:52Семья понимает, что для меня работа — очень важная составляющая жизни, далеко не только средство зарабатывания денег, и так было всегда :)
OlegMax
12.04.2017 16:25Насчет старта карьерной лестницы. Мне кажется, что тимлид это довольно специфичная ступенька. Тимлид сам разработчик, а выше в иерархию начинают подмешиваться выходцы из всех прочих специальностей (QA, аналитики, PM и т.д.) и совсем другая конкуренция, где технические знания значат гораздо меньше разнообразных business skills.
vsh
12.04.2017 17:37+1Тимлид сам разработчик
Это очень по-разному везде, даже внутри нашей компании есть тимлиды, активно участвующие и в продуктовой разработке, а бывают и такие, которые код в руках не держали достаточно долго.VolCh
12.04.2017 17:50А у нас вообще дизайнер одно время был, а я при нём техлидом, решающим технические вопросы.
OlegMax
12.04.2017 18:26Тут уже тонкий вопрос терминологии, но, имхо, дизайнер, поставленный над программерами, — это уже менеджер.
VolCh
12.04.2017 18:36Тогда получается, что меня обманули и сделали тимлидом, а сказали, что техлидом? Других лидов точно не было, но не технических вопросов я не касался, из административных исключительно распределение задач по балансу приоритета и оценки, а также компетентности и загруженности разработчика.
Или мы с "менеджером" взяли обязанности тимлида и чётко поделили на технические и нет?
Merkat0r
12.04.2017 22:56Воистину. Сейчас норма, что тимлид вообще никогда код не видел(ну может в институте) зато МВА, аналитик который в аналитике вообще не смыслит, а уж куча всяких с приставкой Digital-хсгоры вообще море
Durimar123
12.04.2017 16:57+1>>На сколько %% зп тимлида выше разработчика?
>Очень сложно ответить на такой вопрос.
И все же, как повлияло взятие на себя обязанностей тимлида на вашу ЗП?
Как вы думаете на сколько должна изменятся ЗП после «навешивания лычек TL»?
spaceinvaider
12.04.2017 15:15Все очень зависимо и от условий и от обязанностей, ответственности.
Может вообще не отличатся — команда из 3х синьеров, один выполняет роль лида(связующего звена с клиентом).
А может отличатся на порядок(команда джунов и лид) в Украине зп новичков начинается от 300$, синьеры/лиды — 3-4К$ далеко не редкость.
Electrohedgehog
12.04.2017 14:00-1С точки зрения мотивации статья хорошая, она говорит что старайся и всё получится, с точки зрения информативности — никакая. Вы что-то делали для того, чтобы стать тимлидом? Как-то развивались? Какие трудности для вас были в этом направлении?
Я не вижу сколько-нибудь значимой информации на эту тему. Статью понимаю так так: если проработать пару лет на одном месте предложат должность. Раствор резюме в воде. Раствор истории успеха в воде с ароматизатором Лондон идентичным натуральному. Раствор общих принципов руководства в воде. Ссылка на вакансии.
Особенно мне понравился это пассаж:
«во всём мире уже давно очевиден тренд роста мобильного потребления контента»
Вы своим подчинённым так же задачи ставите?
damat
12.04.2017 14:33+2а вы точно статью прочитали?.. там про трудности написано в разделе про особенности.
и про проработать пару лет на одном месте: автор очень четко описал, что было достигнуто за _один_ год. Считайте такие достижения шаблоном целей, которые должен ставить перед собой тим лид. Они достаточно универсальны.Electrohedgehog
13.04.2017 06:16+7А вы точно комментарий читали? Давайте ещё раз, более конкретно выражу свою критику.
Статья называется «Как я был разработчиком, а теперь тимлид». Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом. Никаких сведений на эту тему нет. Зато красной нитью проходит мысль — пара лет и ты тимлид. Не по каким-то причинам, а просто потому, что в далёкой-далёкой галактике вуки ударил ногой в бубен.
я был первым нанятым в компанию разработчиком, а когда нагрузки стало больше и у меня перестало хватать времени на всё, мы начали нанимать людей, которых я собеседовал и обучал. В результате я стал тимлидом.
Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными
Как видите, у меня довольно обширный опыт роста из рядового разработчика в тимлида
Не вижу. Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел. Если они есть, приведите пожалуйста цитату. Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.
Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».
Но это чертовски плохой маркетинг. Посмотрите на статьи о лазерной коррекции зрения. Я вообще не разбираюсь в микрохирургии глаза, тем не менее статьи на эту тему читаю на Хабре с удовольствием и даже задумываюсь об операции. Потому, что пишут не копирайтеры, а врачи, которые описывают СВОЙ опыт, описывают интересно и подробно, а не по конспектам пятичасового выступления бизнес-тренера. Это прекрасно читается между строк и сильно влияет на восприятие компании. Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.
NeverIn
13.04.2017 09:23Люто плюсую. Мотивационная статья из разряда «Я уеду жить в Лондон… мне Москва будет сниться ...»
vsh
14.04.2017 20:17+1Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом
В этой статье я рассказываю только о себе, а опыт у меня вот такой, вы уж не обессудьте :)
Просто так вышло, что на двух местах работы автор был первым и самым опытным разработчиком. Никаких иных предпосылок роста я не увидел
Абсолютно справедливо для первого опыта — был действительно первым разработчиком и вариантов иных и не было практически. Во второй раз я мог оставаться в одной большой команде фронтенда, но сознательно выбрал отдельное направление мобильного веба, тенденцию роста которого я знал, и предполагал, что направление будет расширяться, и, соответственно, там есть возможность роста.
А вот на последнем месте работы так вышло, что я не был и самым первым и, наверняка и самым лучшим тоже не был.
Мне, если честно, вообще сложно рассуждать о том, почему и как выбирали меня, но могу долго рассказывать о том, как выбираю я.
Я бы тоже хотел стать тимлидом через пару лет, но единственный предлагаемый статьёй способ — устроиться в компанию с новым направлением и ждать пока потребуется больше людей для задачи, а я довольно плох в предсказаниях.
Это далеко не единственный способ вообще, но в рамках моей статьи я не стремился рассказать обо всём, и так вышел лонгрид изрядный. Но способ Ваш — отличный, и если Вы станете уделять время анализу того, что происходит на рынке, и какие отрасли / направления будут развиваться активнее, возможно, Вам удастся его грамотно использовать и стать тимлидом, как Вы и хотите.
Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».
Я не знаю, как Вы определяете, какое редактирование проходит статья, если интересна «внутренняя кухня» подготовки статей — все довольно просто: автор пишет статью, корректор исправляет ошибки, заинтересованные коллеги комментируют/проясняют какие-то неочевидные моменты, и статья идет «в тираж». К сожалению, каких-то отдельных специалистов-маркетологов, которые помогали бы статью «адаптировать» к каким-то требованиям, у нас пока нет.
Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.
Я не знаю, могу ли я себя считать реальным профессионалом своего дела, но уж профессионалом в написании статей я не был никогда точно :) Ну и, конечно же, всем не угодить, кому-то и неинтересно будет, это нормально.Electrohedgehog
17.04.2017 07:56+1Виталий, спасибо за столь развёрнутый комментарий. Как я уже сказал, с точки зрения мотивировки статья хорошая, и ничего против неё я не имею, а указанные недостатки это моё личное мнение, вполне возможно что и не справедливое.
Язык статьи я критикую за избыточность и «трендовость», не исключаю что вы просто слишком много общались не с теми людьми, однако это язык крайне неприятной мне категории людей, для которых речь является не инструментом общения, а способом траты времени либо повышения стоимости текста путём увеличения его размера.
Если внимательно разобрать вашу статью или просто прогнать через анализатор текстов, то она удивительным образом окажется оптимизированной под восприятие среднего читателя Хабра с точки зрения сложности текста, распространённости слов, длины предложения и прочих аналогичных параметров. Не менее же удивительным образом в ней не будет слов с негативной эмоциональной окраской, будет соблюдаться правильная ритмика предложений и прочие правила написания маркетинговых текстов. Надеюсь всё же, что это редактированная статья, а не ваш естественный язык общения.
В любом случае, спасибо за статью. Истории тех, кто «сперва добился», достаточно важны для профессионального становления.
KirillOstrovskiy
12.04.2017 15:15А что за «тренинг по курсу теории ситуационного управления»?
vsh
12.04.2017 16:14+1Мы занимались у Натальи Зверёк http://bc-expert.ru/corporate/trainers/zverok/ и у James Brook http://www.strengthspartnership.com/people/james-brook/
Вот Наталью как тренера очень сильно рекомендую, программу она подберет сообразно бизнес-требованиям и запросам идеально.
frees2
12.04.2017 15:15Ещё до начала кризиса доткомов работал в команде единомышленников. Человек 5-6, каждый был начальником в рамках компетентности.
Почему так лучше.
Отношение стоимости проектов к оплате труда работников — Бывает и 100 к одному. Сто евро работа — 1000 евро стоимость проекта.
Хрестоматийные примеры.
Шведская компания Crisp управляется без начальства уже 3 года.
Интернет-магазин Zappos с 1,5 тысячами сотрудников.
Ким Ир Сен давно умер и стал вечным президентом. Северной Корее теперь живой президент не нужен.
Директор Фунт с дореволюционных времен — номинальный руководитель фирм.
jumkarto
12.04.2017 16:15+3Из описания к одной из вакансий: «Мы рады за наших коллег, которые становятся родителями: +две недели оплачиваемого отпуска и 30 000 р. на первые погремушки:)»
За это отдельный респект! Продвижение семейных ценностей на любом уровне очень важно в наш «европейский» век.
welikoiwanenko
12.04.2017 16:15+2ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры
Так, будучи тимлидом, я попал сюда:)
Спасибо за статью, почерпал для себя несколько важных тезисов.
Don_Eric
12.04.2017 19:51-2из статьи не очень понятно — зачем все это надо?
командуя 12 людьми очень сложно оставаться технически подкованнымboblenin
12.04.2017 22:27+2Если ты хочешь написать кусочек системы — то незачем. Если ты хочешь создавать всю систему — то тебе нужны помощники.
Если ты хочешь писать код, — то незачем. Если хочешь решать проблемы других людей с помощью программных продуктов — то это способ.
Если ты участвовал в 20 продуктах и не видел разницы между SCRUM-ом и скрабом, или RUP-ом и рупором или Agile-ом и Ajax-ом — то поять же незачем. А если ты видишь, что в каком-то месте разработчики (в том числе и ты) теряют кучу времени и знаешь как исправить — то это способ.
xPomaHx
13.04.2017 07:45+1Почему из программиста в тимлиды это "уверенный шаг вперед"? Это смена рода деятельности на смежную, и то что там больше платят, или то что тимлид начальник над прогерами, не говорит о том что это рост программиста.
boblenin
13.04.2017 18:07+2Это рост. Из-за того, что увеличивается зона ответственности. Но это не единственный карьерный путь.
3aicheg
13.04.2017 08:59+5Там сидит по деревом
Доктор Айболит.
Он фулл стак девелопер
И фулл тайм тимлид!
vadimr
13.04.2017 09:09Сам по себе рост численности команды не является позитивным результатом для бизнеса, зря Вы его поставили на первое место в достижениях. Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).
vsh
15.04.2017 20:30Сам по себе рост численности команды не является позитивным результатом для бизнеса
Вы абсолютно правы. Рост численности команды — один из вариантов того, как можно справиться с увеличением нагрузки. Упомянул я его исключительно для того, чтобы показать retention.
Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).
Так и делаем :) У нас отчеты перед руководством совершенного иного формата, исключительно о результатах, имеющих измеримый business value.
vearutop
13.04.2017 11:49Виталий, какие перспективы карьерного роста у разработчика, который не хочет перекладывать бумажки в jira?
vsh
13.04.2017 12:41Vearutop, не совсем понимаю про «перекладывание бумажек в jira» :)
Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
kataus
13.04.2017 12:28Есть довольно прикладной вопрос — а какую литературу вы изучали в рамках освоения на новой должности?
vsh
13.04.2017 13:36Всего несколько книг:
- Одноминутный менеджер (мотивационное про делегирование и ответственность)
- Management Of Organizational Behavior (собственно теория)
- почти все на HBR https://hbr.org
Wan-Derer
13.04.2017 12:28+2Короче, становитесь тимлидом. И у вас будет много личной экспертизы и жидкого стула для статей :/
kapioprok
13.04.2017 12:28По поводу четвертого пункта, поработать с людьми может каждый, тут скорей индивидуальные качества человека нужны в плане психологии, а ярко выраженный лидер это скорей для отделов с манагерами.
vsh
13.04.2017 13:44А мне кажется, что лидерские качества просто помогают легче выстраивать правильную атмосферу в команде, и, соответственно, полезны, наверное, любому управленцу.
Areso
13.04.2017 13:15+1У нас руководитель программистов а) сам программист б) кроме раскидывания задач, а также программирования непосредственно, заполняет всякие скучные бумаги, вроде табеля в) не имеет реальных рычагов влияния (зп поднять/уменьшить/передвинуть отпуск/даже стул поменять или компьютер)
Единственная разница между руководителем программистов и другими программистами — если руководитель сказал, что будет такое архитектурное решение, то значит такое и будет. Ему и отвечать потом, если что.VolCh
13.04.2017 14:31Если без табеля, то это скорее техлид или архитектор. А так был таким номинальным руководителем, который приходил к своему руководству что-то просить финансово-материальное для подчиненных, а в ответ получал "у него, что, своего языка нет? пускай приходит и просит прибавку/отпуск/стул/компьютер". А ответственность за работу всей команды полная, называние причины срыва дедлайна типа "фронендеру не подняли зп и он ушёл, потому пришлось раскидывать его работу между всеми кто хоть немного понимает, откладывая их задачи" — "тыжначальник, надо было замотивировать не уходить хотя бы до делайна".
mike1
14.04.2017 20:29Если такой руководитель «как сказал, так и будет», не прислушиваясь к аргументированной критике его концепции, не убедившись, что вся команда поняла и приняла его мотивацию, то он м… к, а не руководитель. Ему отвечать, а вся команда в заложниках за его кривые/ошибочные/непродуманные решения.
Areso
15.04.2017 06:51Имелось ввиду, что последнее слово — и решение — именно за руководителем. А вот учитывается мнение других разрабов или нет — это уже ваш вопрос, но там все от случая к случаю.
varus
13.04.2017 17:55В общем, я веду к тому, что навыки разработчика будут неизбежно теряться.
Считаете ли вы допустимым для тимлида не иметь практики программирования?
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?vsh
14.04.2017 19:21+1Считаете ли вы допустимым для тимлида не иметь практики программирования?
Допустимо, как мне кажется, вообще что угодно, посредственный художник может захватить значительную часть мира, например. Без навыков и опыта программирования тимлиду будет значительно сложнее, придется выстраивать процессы так, чтобы этот недостаток нивелировать.
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?
Я бы тут отталкивался от требований бизнеса, сложно ответить на такой вопрос абстрактно. Может, Ваша система написана на COBOL'е и поддерживается и дорабатывается пятью семидесятилетними программистами? Вряд ли будет уместно тимлиду в такой ситуации искать и внедрять что-то новое :)
devlev
14.04.2017 01:48+2Давно искал подобный материал, за это автору огромное спасибо. Но вот у меня все равно какое то странное представление складывается о професии тимлида. По сути на чистую работу с кодом времени уже нет. Голова забита кучей задачей, половину психологических: как померить сотрудников или замотивировать, другая управленческим: как все распаралелить по сотрудникам, третья как все уладить с руководством и т.п. Но ведь технологии не стоят на месте. Постоянно что-то новое появляется. Получается раз на код уже времени нет, то восприятие этого нового для тимлида происходит условно говоря без практики.
Ну к примеру вы упомянули c#. Два года назад вышла 6 версия. Обычный рядовой разработчик почитал доки, попробовал поюзать, написал пару тестовых проектов, понравилось, стал использовать новые фичи в продакшене. Тимлид наверняка тоже почитал доки, возможно попробовал пару тестовых проектов и на этом все. Т.е. в моем понимании, со временем растет прослойка между понимаем кода тимлида и разработчика. С течением большого времени тимлид уже не сможет проконсультировать какого то разработчика потому что у него не будет просто нужной компетенции. Хотя наверно в действительности такой ситуации возможно и не возникнет, или на ее решение будет послан какой нибудь ведущий разрабочик в команде тимлида.
Из всего этого у меня складывается странное представление о профессии тимлида. Поскольку время наш злейший враг, а с его ростом растут и технологии, появляется куча всего нового, и поскольку тимлид уже за этим всем не следит, то получается растет и различие в понимании происходящего на уровне тимлида и на уровне программистов. Отсюда, как мне кажется, выход только один, дальше рости и стать руководителем тимлидов, постепенно выращивая под собой себе подобных. Обратного пути нет, ибо первоначальные навыки будут уже совсем утрачены. И стоять на месте тоже не получится, потому что опять же время наш злейший враг.
Интересно узнать ваше мнение.vsh
14.04.2017 19:56Согласен полностью с вашим выводом — если выбрать карьерой управление и, соответственно, не иметь достаточно времени на программирование, неизбежно квалификация техническая будет теряться. Мне в такой ситуации кажется логичным наращивать квалификацию и знания в управлении и расти именно в этой области.
В любом случае, это выбор другой профессии, отличной от разработки.
NeverIn
14.04.2017 21:46+1И это еще не все. Количество вакансий тимлидов на порядок меньше при этом ожидают уровня лида, лидирующего в плане технических знаний, садишься и правишь косяки подчиненного.
summerwind
21.04.2017 19:42Именно по этой причине не очень хочется торопиться и становиться тимлидом раньше лет 30. Потому что тимлид это не программист, а менеджер с техническим бэкграундом. И этот бэкграунд просто не успевает восполняться до равного с другими разработчиками состояния со временем.
tigusigalpa
14.04.2017 20:49-2if ($chsv < $wanted_chsv) {
return $habr->writeArticle('some words about Im cool');
}
akubintsev
15.04.2017 08:14Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.
Спасибо, лучше вы к нам)
Кое-что в статье я нашёл похожим на свой опыт, только пока не получилось ещё окончательно закрепиться в роли тимлида.
По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.vsh
15.04.2017 20:34По поводу открытий на управленческом посту. Стоило посетить изначально тренинг по основам управления. Многие заблуждения сразу бы развеялись.
Абсолютно согласен, в идеале бы вообще знать все заранее, и лишь потом начинать заниматься. Однако проблема обучения без отрыва от производства стоит перед большинством компаний, о которых я знаю, а вот как её решают успешно — с удовольствием бы почитал сам.
Mnrv
15.04.2017 10:30Значит под вашим чутким руководством приложение badoo превратилось в такое дерьмо? Сделали уродский дизайн, пролистывание анкет слизали у тиндера, да еще и на мобильных устройствах не переворачивается в зависимости от положения, поэтому планшет приходится переворачивать, что дико бесит. Чувствуется рука профессионалов!
Tantrido
15.04.2017 12:19+1Обалденная статья! Благодарю! Прямо эзотерика в чистом виде. Будем учиться, перенимать и применять.
Как можно найти тренинг по курсу теории ситуационного управления Badoo, который Вы упоминали?vsh
15.04.2017 12:31Спасибо!
Наталью Зверёк http://bc-expert.ru/corporate/trainers/zverok/ очень и очень рекомендую, её тренинг за кратчайшее время открывает глаза на очень многое.Tantrido
15.04.2017 12:50На странице нет ссылки на тренинг: где, когда и как она его проводит? Онлайн варианты есть? Благодарю!
vsh
15.04.2017 20:35К сожалению, не в курсе, ведёт ли Наталья вообще регулярные тренинги. Если правильно помню, она их делает только по запросу, но лучше все же связаться с ней и узнать.
chiliec
15.04.2017 16:21Я думаю, единственный способ поддерживать комфортную атмосферу и мотивацию в подобных ситуациях — сохранять максимальную прозрачность во всём, во всех аспектах управления командой.
Вот это безумно круто! У нас был такой же открытый тимлид, было здорово. Но потом он перевёл нас на scrum-методологию и команда получилась с плоской структурой, а сам он ушел в девопс :) И вот уже более полугода живём без тимлида, вроде ничего. Думаете тимлид так уж нужен? По-идее это единая точка отказа (bus-фактор близок к 1).
все они имеют чёткий план роста и развития внутри команды и компании.
Можете поподробнее рассказать что это за план такой?
раз в две недели индивидуальные встречи с каждым сотрудником
У вас правда есть в этом необходимость? Что это даёт?vsh
15.04.2017 20:48И вот уже более полугода живём без тимлида, вроде ничего.
Было бы очень интересно узнать о ваших бизнес-процессах, и как команда живет и развивается в рамках плоской структуры. У Вас нет на эту тему публикаций? Если нет, можете лично рассказать?
Можете поподробнее рассказать что это за план такой?
Подробнее лучше сделаю в рамках отдельной статьи, довольно обширная тема. Если вкратце — по каждому разработчику карта мотиваций + компетенций (и вес инвестиций в развитие каждой) + потенциальных путей развития + общая карта необходимых незакрытых «экспертиз» для команды сообразно требования бизнеса и процессов. У каждого критерия есть свой вес, и согласно этим весам определённые планы роста и составляются, обсуждаются с разработчиком, формализуются в виде планов, результаты оцениваются каждый квартал/полгода, поощряются имеющимися мотивационными инструментами.
У вас правда есть в этом необходимость? Что это даёт?
Да, раз в две недели для нас — оптимально. Одна из этих встреч будет посвящена всегда результатам ежемесячной оценки, вторая — разным другим темам. Реже не получается, чаще не имеет смысла :)
О нашей системе 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/ )
odissey_nemo
18.04.2017 04:15-1В СССР руководитель (отдела, группы, направления), в т.ч и в программировании, был:
а) опытным человеком в своём деле, архитектором,
б) был харизматичен (встречал пару, за которыми реально можно было идти в разведку), авторитетен
в) отвечал за коллектив, причём сначала для него шли его люди, и лишь потом он сам
г) умел работать и сам, демонстрируя незаурядные навыки в своём деле
Сегодня это, скорее (по личному опыту) РП спрофуклоном, человек, приставленный бдить, контролировать сроки, удалять худших, нанимать лучших, винтить винтиков-человеков.
Статья для меня — ни о чём. Личность автора как то абстрагирована, оставлены одни чисто западные функции. На его месте мог быть любой другой. Картинка в заставке очень характерна. Надеюсь, это не автор, а модель для демонстрации трусов и плавок. Ничего личного, но пережить период жизни на приличной зарплате с такой моделью, видимо, можно. И это чаще единственный выход сегодня. Но помнить его, встречаться с ним и через 20 лет? Увольте. Только тимлид, только контрольные меткие выстрелы в высунувшуюся душу подчинённых.
Всё выше изложенное — утрировано, конечно.
botyaslonim
18.04.2017 19:43"… раз в две недели индивидуальные встречи с каждым сотрудником
… если из команды ушёл разработчик, это вина тимлида..."
— прям как красивый роман читал, в хорошем смысле :) У меня все индивидуальные встречи с начальником были только насчёт увольнения :)
Я полностью согласен с подходом, проповедуемым автором статьи, поскольку сам в своё время был руководителем рабочей группы (10-12 человек). Правда, то была не разработка и даже почти не IT. А вот непосредственно в разработке я видел только такую картину: тимлид или архитектор сидят до посинения пишут код сами, никаких межкомандных вопросов не решают, на известие об уходе сотрудника говорят «ну, пока» и так далее.VolCh
18.04.2017 20:08А какие межкомандные вопросы должны решать тимлиды/архитекторы?
botyaslonim
18.04.2017 22:56Ошибся в формулировке, имел ввиду межличностные внутри команды. Хотя и межкомандные иногда тоже
VolCh
Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства. Ну и некоторые функции исполнять приходилось временно, пока не найдут кого-то, но я делал всё, чтобы как можно сильнее мотивировать руководство найти как можно быстрее :)
Главная причина такого завуалированного отказа — понимание того, что я не смогу в плане технического развития достаточно быстро бежать чтобы хотя бы на месте оставаться. Ну и, как правило, предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации.
Algoritmist
Сильно тянуть не надо. Можно дождаться что предлагать больше не будут, поскольку найдут другого героя (с меньшей квалификацией). И самое страшное, что он станет вашим начальником. МВА — хорошо, но проблем не решает. Управленческие навыки с опытом приходят. Тут главное понимание, что «сотрудники — это люди».
VolCh
Предлагают практически на каждом месте работы после года-двух, максимум трех.
Я это как раз понимаю и прошу раз дают людей в полное подчинение, то дать и рычаги воздействия на них, а не так, что ни зарплату не могу поднять отличившимся или просто очень нужным, ни уволить особо отличившихся.
Algoritmist
На моем опыте, что доступа к рычагам нет, для новоиспеченных начальником, это даже плюс. Если ситуация станет значимой, то Вы должны набраться сил, чтобы достучаться до хозяина рычагов (возможно этих рычагов нет и у вашего будущего непосредственного начальника). Вы должны наладить работу не только со своими сотрудниками, но обязательно с руководством, и желательно со своими коллегами из смежных подразделений. Чем эти взаимодействия более проработаны, тем Вам проще работать.
boblenin
О каких рычагах вы говорите? Вам запрещают уговаривать, убеждать, ругать или спорить? Или вы хотите бюджетом управлять и увольнять по своему желанию?
Если провести аналогию с армией, то вам как младшему офицерскому составу требуется умение раздавать приказы или вы хотите еще и расстреливать тех, кто не нравится и награждать тех кто нравится ни с кем не советуясь?
VolCh
Младший офицерский состав имеет право расстреливать без суда и следствия за неисполнение приказа подчиненным, имеет право взять под арест, выносить дисциплинарные наказания и поощрения. Я же даже прав доступа к репе лишить не имею прав.
Tsimur_S
А это какой вид рычага: поощрение или наказание? Какой в этом вообще смысл?
VolCh
Физическое отстранение от работы.
boblenin
Вот вам еще одна аналогия. Поставили человечка надзирать за рабами, а он взял и убил одного из них. Хозяин будет счастлив?
Merkat0r
если он ухайдокал других рабов да еще вытоптал поле
и в рояль насралто имхо будет очень счастливboblenin
Ну вот как раз сделал то, что собирается сделать VolCh
VolCh
Рабы собственность всё же, имеющий ликвидную ценность. Сотрудник, результат работы которого не принимает никто, или принимает только после глубокой перерабоки, иной раз занимающей больше временами чем реализация с нуля, ценности для компании не имеет, а расходы компания несёт.
Tsimur_S
для этого есть увольнение. Зачем платить зп человеку который не может выполнять свою работу?
VolCh
Ну, например, решение об увольнение принято, но две недели человеку надо ещё отработать по закону или соглашению сторон, но в рамках проекта ему ничего давать нельзя даже из экономических соображений — лучше потратить деньги только на его зарплату, чем на его зарплату и зарплату тех, кто будет выпиливать то, что он за две недели наворотит.
boblenin
Серьезно? И многих расстреляли уже? В мирное время?
Дисциплинарные наказания — да, в виде наряда вне очереди но никто вам не запрещяет их выносить — заставлять работать в выходной, только учитывайте последствия. Поощрения — возможно только в виде дополнительного отдыха или благодарности перед строем — но и вам никто не мешает то же самое делать.
Людей наняли не для того, чтобы вы им работать не давали. Ваша задача не потакать своим комплексам или перфекционизму, а заработать компании денег. Если человек, которому надо платить зарплату сидит без работы, т.к. кто-то умный лишил его прав доступа к репе — то вы разбазариваете деньги, а не зарабатываете.
Simplevolk
Насколько я помню. лейтенант может только взыскания и благодарности объявлять, а остальное старший офицерский состав.
И уж тем более расстреливать перед строем он не имеет права и в военное время. Для этого есть трибунал.
VolCh
Не перед строем, а для принуждения к исполнению приказа. В мирное время лейтенант, отдавший правомерный приказ, например, пьяному вооруженному караульному сдать оружие, имеет полное право применять оружие на поражение, если караульный отказывается. Затаскают потом, конечно, но право имеет.
boblenin
Я думаю любой разработчик, специалист по контролю качества, дизайнер, секретарша, уборщица, не говоря уж о тим-лиде вполне имеют полномочия сказать пьяному коллеге чтобы тот не коммитил в репу и не писал код.
А еще лучше отвлечь его. То же самое и с лейтенантом. Те из лейтенантов, кто слишком увлекаются мантрой "я начальник — ты дурак" переодически просыпаются с дыркой в голове и с отравлением свинцом, особенно в военное время.
Вообще определение лидера:
Лидер — это личность, за которой все остальные члены группы признают право брать на себя наиболее ответственные решения, затрагивающие их интересы и определяющие направление и характер деятельности всей группы.
Т.е. это не функция, а роль в социуме.
VolCh
Сказать может кто угодно что угодно, но пустые угрозы быстро начинают игнорировать, а пустые обещания "плюшек" начинают раздражать, особенно когда люди слышат не то, что им сказали ("я попрошу, чтоб тебе премию дали"), а что им хочется слышать ("я обеспечу тебе премию").
Лидеры бывают неформальные и формальные. Лично я говорю прежде всего о формальных, назначенных сверху, за которой члены группы формально признают право принимать решения по факту своего участия в группе. Но не смотря на это формальное признание, некоторые члены группы могут игнорировать решения формального лидера, понимая теоретически что к ним могут быть применены формальные меры наказания, но или рассчитывая на "авось", или относясь к ним равнодушно.
boblenin
А кто говорил об угрозах кроме вас?
А кто говорил о том, что кто-то обещает какие-то плюшки?
И они правы. Не обещайте то, чего не можете выполнить. Вообще деньги не единственный мотиватор.
Лидеры не бывают формальными. Бывают формальные управляющие (менеджеры). Задача такого менеджера определить лидера в группе и либо научиться с ним очень хорошо взаимодействовать либо отодвинуть его.
Печально. Судя по тому, что вы написали — у вас отношение к другим людям как к тем, кто не хочет ничего делать в лучшем случае и в худшем вредить. Это не так.
VolCh
Метод кнута и пряника.
Я обещаю попросить и я прошу. Сам премию я могу дать разве что из собственного кармана.
Бывают, навскидку http://www.psychologos.ru/articles/view/formalnyy_lider
Нет у меня такого отношения по умолчанию. С чего вы взяли? Нормально человек работает — нет претензий. Хорошо — пряник. Плохо — кнут.
boblenin
Пожалуй я разделяю вашу точку зрения на то, что вам не стоит руководить людьми. Микроменеджмент, самодурство и раздувание из мухи слона. Плохо как со стороны руководства, так и со стороны подчиненных.
VolCh
Я не говорил, что мне не стоит. Я говорил, что отказываюсь серьезно думать о такой работе, если понимаю, что материально-административные методы мотивации подчиненных мне будут недоступны. И про микроменеджмент ваши фантазии.
boblenin
Мои фантазии? Зачем мне фантазировать о ваших проблемах? Вы считаете, что это задача тимлида — проверять код за подчиненным, верно?
Вы либо не понимаете о чем говорите, либо не хотите понимать. Материально-административные методы мотивации доступны даже самому простому джуниору, если он знает как ими пользоваться. Вы хотите не методы мотивации — вы хотите устроить диктатуру, чтобы ни с кем не советуясь увольнять людей. Вы хотите единолично решать все, но так не бывает ни на каких уровнях управления. Так бывает только на уровне исполнителей. Исполнитель имеет полный контроль над тем что и как он сделает. Все остальные вынуждены координироваться и идти на компромисы.
VolCh
Обычное code review
Не в рамках рабочих процессов, обычно.
Я понимаю, что это не реально. Как минимум из-за трудового законодательства. Но, как минимум, я хочу явных полномочий инициировать формальные процессы взысканий (вплоть до увольнения) и поощрений, а не так что прихожу просить повышения зарплаты, а мне говорят "у него, что, своего языка нет?"
boblenin
Сколько Code Review вы можете делать в день? Когда вы собираетесь заниматься своими прямыми обязанностями?
Распределение бюджета вообще к процессам отношение слабое имеет. Или вы считаете, что выделение определенной суммы каждый месяц прописывается в орг. схеме?
Так ведь они есть у вас. Как и у любого другого. Вы собираете данные, представляете их на рассмотрение, человеку дают возможность оправдаться или исправиться и если не может — уходит.
Справедливо говорят. Либо вы распределяете бюджет и значит сотрудники работают на вас, либо нет. Вы можете сделать то же самое не прося повышения зарплаты, а предлагая поощрить человека. То о чем вы просите — это воопрос вообще не должности, а политики. Вы его хотите решить в стиле слона в посудной лавке. Вас не видят достаточно доверенным или надежным и обижаться в такой ситуации бесполезно.
VolCh
Code Review входит в мои прямые обязанности.
Вы не понимаете. Я не обижаюсь, я отказываюсь от предложений стать руководителем команды разработки, если мне не дают полномочий для этого. Если на все материально-финансовые вопросы команды я могу отвечать только "идите в кадры-к директору", а на постоянные косяки реагировать только путем самостоятельного переделывания в личное время, но при этом несу полную ответственность за результат.
mike1
На постоянные косяки будете вправлять мозг подчиненным, а не переделывать в личное время — глядишь и «отсутствующие» полномочия дадут. Очевидно, что руководство не видит в Вас «биг-босса», а Вы могли бы уже давно стать им.
VolCh
Как вправлять без полномочий? Не поощрить, не наказать.
Andrey_911
Вам уже очень популярно Все объяснили. Вы просто не хотите… или не можете услышать. Видимо вы просто хотите, что-бы все «полномочия» вам предоставили на «блюдечке с голубой каемочкой». Такого в реальной жизни не бывает. Все необходимые полномочия у вас, Если вы будете тимлидом- у вас будут. Чего не будет- Аргументированно объясните руководству и появится. Рецепт предельно прост.
VolCh
Я хочу, по сути, должностную инструкцию, где расписано что я должен делать, что могу, а что не имею права. Но получается всё нужно выяснять методом научного тыка.
Andrey_911
Эмм… вы Реально понимаете, что ФСЁ в должностной инструкции «прописано» быть не может? Просто потому, что ВСЕГО предусмотреть невозможно.
VolCh
Понимаю. Потому "хочу", а не "жду". Но позиция руководства "ты теперь начальник, отвечаешь за всё, а там как хочешь так крутись с теми же полномочиями как у тебя были как у ведущего разработчика" меня демотивирует занимать эту должность.
Andrey_911
Вы Снова меня не слышите. Начальство, я Уверен, ценит Грамотных специалистов. Умеющих Обосновать, а не просто «хотеть» чего-то. Вы просто «хотите»? Ну, хотите дальше.
VolCh
Право имеет применять оружие для подчинения в мирное время, например, неисполнение приказа "сдать оружие! или если неисполнение приказа содержит признаки госизмены. А расстреляли или нет кого — дело десятое. Такие права даны прежде всего для предупреждения нарушений, а не как наказание, чтоб даже не думали не выполнять приказ.
Нет полномочий заставлять работать кого-то в выходной, а из поощрений только устная личная благодарность.
Если человек портит репу, то закрытие доступа к ней означает сокращение убытков.
boblenin
Честно говоря звучит очень уж максималистски. Вы уверены, что вам действительно предлагали позиции тим. лида и это не было жестом отчаяния?
Портит репу — это вообще что значит? Ломает билды? Нарушает консистентность хранилища? Коммитит плохой код?
VolCh
Предлагали как самому технически компетентному из команды.
Коммитит плохой код, в том числе ломающий билды, который потом нужно откатывать. Время на откат — дополнительные прямые убытки.
boblenin
Часто это может быть минусом. Хороший тех. спец часто бывает перфекционистом.
Плохой код — переводится как код, который не нравится вам. Это вообще не повод ни для чего. Тот самый перфекционизм технаря, который, увы, придется оставить, переходя в управление.
Ваша задача сделать так, чтобы он мог приносить пользу, а не так, чтобы он не мог не приносить вреда. Поговорить — спросить зачем он так делает. Если не умеет — научить. Если не способен научиться — но тогда как он до вас работал? Если он вам просто не нравится — извиняйте. Это часть работы — находить подход к людям, которые вам не нравятся и даже поддерживать нормальные рабочие отношения.
Ломает билды — пусть чинит. Один раз сломал — ошибся со всяким бывает. Поддержать, обучить, прикрепить к более опытному коллеге, чтобы учился. Если не учится и продолжает ломать билды — подсчитать убытки (кол-во сотрундиков, вынужденых пинать баклуши = x, цена рабочего часа одного сотрудника = y, кол-во потерянного времени z:
x y z = $ потери в деньгах — если эти потери больше чем рассходы на найм нового сотрудника — есть смысл пообщаться с руководством на тему замены человека.
VolCh
Я считаю, что достаточно понимаю где нужно остановиться по дороге к идеальному коду.
Плохой код — переводится как код, который или сам не работает, или сам работает, но ломает что-то другое, либо и то, и другое
boblenin
Вы понимаете, что это субъективно?
Обучение, контроль, внедрение юнит тестирования, если ваши претензии обоснованы.
VolCh
Конечно.
Всё это есть в той или иной степени, но если прямые указания как решать задачу игнорируются и втихую решаются по своему, то я не воспитатель, чтобы прививать элементарные понятия трудовой дисциплины.
boblenin
Это звучит как производственный конфликт. В конфликте всегда есть две стороны. Ваше мнение — другой человек должен измениться и вы, судя по вашим словам, не готовы содействовать. Надеюсь у вас есть толковый руководитель или HR, чтобы конфлит разрешить.
Вы с вашим подходом можете неплохо отравить атмосферу. Неопытного сотрудника можно научить, но упертого и конфликтного — лучше изолировать.
VolCh
Почему не готов? Готов потратить кучу времени на объяснение своих ожиданий от сотрудника как организационных, так и технических.
boblenin
Это не конструктивно. Нужен результат, а вы предлагаете процесс без результата и главное ваше предложение вообще никак ни чему не помогает. Потеря вашего времени — это только ваша проблема.
Ваша задача как управляющего коммандой — сделать так чтобы член комманды был эффективен. Как вы этого добъетесь — ваш выбор. Вы можете его обучить, запугать, подбодрить, перевести на другую задачу, и еще миллион вариантов по вашему усмотрению. Я перечислил 4 способа просто из головы, за все комментарии в этой статье вы предложили только два — дать денег или выгнать. Оба способа, предложенные вами — экстремальные. Уволеный сотрудник — это личный фейл руководителя, за исключением сокращений — тогда это фейл департамента развития бизнеса. Фейлы бывают — ничего не поделаешь, но вы же хотите стать руководителем специально для того чтобы фейлить.
VolCh
Ну так обучить — объяснить, поощрить — обещать дать денег, запугать — обещать уволить. Но если реально ни денег не могу дать, ни уволить, то это перестанет работать очень быстро.
vadimr
Всё-таки вам надо скорректировать свои ожидания, если они нереализуемы на практике. В данном случае, придумать какой-то другой процесс, учитывающий особенности производственного коллектива. Технология существует для организации работы людей, а не люди для реализации технологии.
VolCh
Да не в технологиях и процессах дело. Люди могут, но не хотят.
balexa
Потому что это надо настраивать дженкинс, надо внедрять ревью, надо менять процесс, надо договариваться, надо уметь аргументировать свою точку зрения. Если тимлид хороший, он этим и занимается.
Если же он стал тимлидом потому что других не нашлось, то ничего кроме права запрещать доступ к репе и махать угрозой увольнения ему в голову не приходит.
VolCh
Зачем мне дженкинс? У нас ютрэк и ревью я занимаюсь.
С кем и о чём договариваться? Договоренность это "ты мне — я тебе". Что я могу дать сотруднику? Разве что в бар его сводить за свой счёт.
Ещё мне в голову приходит дать ему премию, например, или поднять зарплату, если вижу, что он по сайтам вакансий лазит.
vsh
Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!
Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)
Согласен полностью, без мотивационных инструментов работать намного труднее.
Razaz
Я нашел для себя баланс в должности principal software developer. Минимальный менеджмент команды за счет менеджера в подчинении и можно сфокусироваться на техническом аспекте :)
pavlick
Ну по идее это право и не нужно, нужен человек/люди, способные решать эти вопросы, основываясь на вашем фидбэке.
VolCh
Люди-то, конечно, есть такие. Но вот мотивировать я их могу только одним способом: "или повышаете/увольняете моего подчиненного, или я увольняюсь/возвращаюсь в разработчики". Они меня в шантаже обвиняют :) Но заводить задачи по требованиям бизнеса в бэклоге и разбрасывать их по членам команды я могу и без "лычек" тимлида (собственно обычно после некоторого периода исполнения этой функции и предлагают тимлида)
pavlick
ну тогда два варианта:
— у этих людей слабая связь с реальным миром
— у вас недостаточная аргументация
Какой вариант вам ближе? )
ну и в моем мире разбрасывание задач — это лишь малая часть работы тимлида
VolCh
Я ещё и аргументы должен подыскивать кроме как "не справляется с работой" или "очень хорошо справляется с работой, сильно пожалеем если уйдёт куда-то на бОльшую ЗП"?
Я понимаю, что меньшая. Я часто занимаюсь ею и без "лычек" и поэтому мне хотят их дать и навесить ещё больше работы не по самой разработке, а по управлению её процессом, особо меня на это не мотивируя, видимо по принципу: "раз часть работы тимлида на себя взял добровольно, то и с остальным справится".
mike1
Что-то, VolCh, помню, как вы отвечали на какой-то мой пост, имея в виду коммуникационную проблему, что представляли людей как чёрные ящики и не знали, как добиться от них детерминированного поведения. Проблема коммуникационная, а вовсе не в курсах или отсутствии рычагов.
VolCh
Теперь лучше в людях разбираюсь и могу с большой долей вероятности сказать, кто будет (и будет ли) лучше работать на проекте, если повысить зарплату, а кто будет лучше работать, если пригрозить увольнением, а на кого эти меры особо не влияют.
boblenin
Эти меры — это "оружие судного дня". В 99.99% случаев им не пользуются.