Как стать тимлидом и не взорваться



    Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:


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

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


    Откуда берутся лиды


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


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



    Вторая — иерархическая система управления.



    Есть разработчик, за ним стоит platform lead, за ним CTO, далее CEO. Каждый участник курирует определенный вектор развития. Чем ниже располагается в иерархии человек, тем за более узкоспециализированный участок он отвечает. Разработчик отвечает лишь за код, который он производит. Lead отвечает целиком за платформу и за её развитие. Технический директор отвечает за техническую составляющую в компании. А генеральный директор — за развитие компании.


    Чем больше становится компания, чем больше появляется процессов и участников, тем сложнее становится иерархия. Появляются дополнительные роли, такие как Mobile Lead. У него в подчинении находятся лиды мобильных платформ, которых может быть больше одного на платформе. Это зависит от количества подчиненных на конкретном уровне в компании.


    Оптимальное количество людей, которых может контролировать один человек, сильно варьируется от сферы деятельности и от модели управления. В IT в классической литературе это число колеблется от 5 до 9 человек.



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



    Большее ведет к тому, что контроль, обучение и другие функции становится сложнее выполнять. Необходимо добавлять новые роли.



    Рассмотрим классическую ситуацию карьерного роста в IT-компании. Когда человек достигает определенного уровня квалификации, он может либо перейти на следующий уровень иерархии при наличии определенных личностных качеств, либо сменить род деятельности/область деятельности/компанию и расти дальше в технической стезе. На картинке ниже представлена классическая краткая форма развития. Следующая ступень развития разработчика — team lead либо tech lead. Первая предполагает уход в сторону менеджмента, вторая — глубокий технический рост специалиста. Team lead дальше уходит в platform lead. Из tech lead получаются архитекторы разного калибра.



    Роль лида в компании


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


    Техническая роль


    Говорят, что со временем team lead начинает терять навыки программиста с течением времени. В реальности же большинство основ программирования были сформулированы более 40 лет назад. Порой эти знания более ценные, чем знание конкретного sdk. Но чаще всего наставничество помимо помощи в самых простых программных вопросах сводится к следующему:


    Построение экосистемы. Сейчас в IT бизнесе выигрывает та компания, которая предоставляет не просто продукт, а старается построить экосистему. Которая может решать множество задач бизнеса и позволяет пользоваться различными функциями, которые предоставляет компания. Это касается и Apple, и Google, и Facebook. Со временем любой бизнес начинает превращаться в платформу. Похожая ситуация наблюдается и в разработке. Вам необходимо построить для разработчика экосистему целиком, чтобы вопросов возникало как много меньше. Это касается и процессных вещей, и архитектуры. Нужно сформировать документированную систему гайдов, которые позволят новым разработчикам быстро влиться в процесс, а участникам команды не забывать принятые нормы.


    Построение системы обучения. Адекватный лид должен грамотно выстраивать процесс обучения всех членов команды, правильно соотнося их собственные интересы с бизнес-задачами компании. Если человек хочет изучить сложный кастомный UI, то задача лида придумать, как это можно использовать во благо. Это касается и других направлений, будь то технические знания или менеджерский бэкграунд. Важно следить за выполнением этих задач, обычно разработчики в своей голове ставят более низкий приоритет данным таскам. Старайтесь помочь в развитии даже в тех областях, в которых у вас меньше знаний. Сводите с нужным специалистом или дайте время разобраться самому, а потом пусть расскажет другим. Так человек укрепит свои знания. Ситуация, когда у разработчика или у вас отсутствуют знания в какой-то области, нормальна. Осознание и принятие этого способствует обучению.



    Привитие принципов отношения к коду. Очень важно донести до разработчика мысль, что сам код не стоит ни гроша. Лишь функциональность, которая выполняется этим кодом, имеет смысл. Отсюда и растёт вся экосистема, которую необходимо построить. Важно понимать, что бизнес диктует правила для написания кода, а не наоборот. Если у вас банковская система с крайне высокой надежностью, то TDD вам необходим. Если же вы пишете MVP-приложения, то смысла строить сложную систему и архитектуру на первом этапе попросту нет.


    Психологическая роль


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


    Организуйте ежемесячные встречи с разработчиками. Сценарий таких встреч каждый месяц повторяется. Поначалу разработчик говорит, что всё ок, всё хорошо, проблем нет. Но основная сила психолога в вопросах. В беседе узнается, что и систему оценки на проекте в прошлом месяце можно улучшить, и взаимоотношения между отделами подтянуть, а ещё было придумано оригинальное решение, которое можно вынести как базовое и написать по нему гайд. Ведь на другом проекте возникли такие же проблемы и решали их дольше, чем нужно. Беседу обязательно надо конспектировать, потому что в ней могут быть отличные мысли. Их можно и нужно претворять в жизнь. После таких бесед часть проблем нивелируется. Так как процесс итеративный, он помогает устранять проблемы и не занимает много времени. Такие встречи не нужно превращать в совещания отделов. Это должны быть именно тет-а-тет беседы в спокойной обстановке. Так вы сможете решить даже сложные личностные проблемы.



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



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



    Как сделать, чтобы стул не сгорел раньше


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


    • Начинаете работать намного больше, чтобы успеть и как разработчик, и как team lead. Обычно это ведет к перегоранию.
    • Работаете столько же, сколько и раньше. В итоге не успеете сделать и фичи, и задачи лида.

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


    Именно поэтому нужно четко регламентировать, зачем вам программировать, сколько времени и что это даст отделу и в целом компании. Если речь идет о 30% времени, в течение которых вы будете проектировать архитектуру общих решений, библиотек или стандартов — одно дело. Это поможет не заниматься рутинными задачами, не забыть код и смотреть на него более глобально. Но если вам говорят о 70% или 90% времени, то люди просто не понимают, зачем им нужен team lead. Или заранее планируют, что вы будете работать больше 40 часов. Можете либо аргументированно объяснить, как сделать лучше, либо просто ответить отказом. Лучше всего поговорить об ожиданиях.


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


    • люди не понимают, чем вы занимаетесь;
    • вы и сами не понимаете, чем занимаетесь и что нужно сделать. Находитесь в совершенно неконтролируемом хаосе.


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



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


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


    Автоматизируйте.Плюс различного рода оптимизации в виде CI/CD/статических анализаторов, кодогенераторов, базовых либ и так далее. Всё это экономит нам время в будущем.


    Тайм-менеджмент и делегирование


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


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



    Контролируйте время. Следите за временем, отведенным на задачу. Речь о тактических и стратегических задачах. Говорю не о ежедневной работе, хотя она и будет являться основным фактором успеха. Под тактическими задачами подразумевается выполнение конкретных больших задачах в виде создания базовых библиотек, задокументированных процессов или процесса обучения. Под стратегическими — определения вектора развития. В какой момент уйти с objective-C? Как сформировать экосистему, чтобы она работала эффективнее? Что надо сделать, чтобы эффективность решения задач бизнеса возросла? Это и есть примеры стратегических вопросов. Они наиболее сложные и наиболее длительные, но именно от них зависит ваше завтра.


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



    Ошибки, негатив и минусы


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


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


    Принятие решений. Бывает, что людей в команду спускают сверху. Вам необходимо сразу четко обозначить здесь правила: либо у вас есть право вето на абсолютно все решения по построению команды, либо необходимо объяснить руководству, почему будет работать именно так. В идеале и самое часто встречающееся на практике — когда team lead сам формирует себе команду. Повышается моральная ответственность так как решения принимал сам lead.


    Личностные качества. В команде есть человек, который по каким-то причинам вас не устраивает. При этом абсолютно не важно, наняли его вы, или он уже был, или дали со стороны. Все люди ошибаются и вы не исключение. Особенно на первом этапе, когда всё ваше собеседование строится не на том, чтобы понять насколько человек вообще впишется в команду, а знает ли он, как решить алгоритмическую задачу по поиску элемента в бинарном дереве. Вы должны понимать, что любой алгоритм можно выучить за один день, любой framework при должном усердии от начального применения в первый же день до глубокого погружения в течение месяца. А личностные качества, некое «абстрактное чувство кода» за день-неделю-месяц или год не исправишь. В этом вопросе тем более не нужно ориентироваться на hr и считать, что это их работа. Потому что в итоге человек будет работать большую часть своего времени именно с вами в период работы в компании, а не с hr.


    К минусам можно также отнести то, что со временем ваши технические навыки будут падать. Это и миф, и правда одновременно. Роль лида позволяет более широко взглянуть на некоторые технические аспекты, на мета-принципы программирования. А то, что вы не будете знать как запрограммировать в iOS 10 новый фреймворк CallKit и какие интерфейсные методы в нём есть — это пережить будет тяжело, но в целом можно.


    Coming out


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


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


    Построение масштабируемой схемы. Отход от роли «кольца всевластия»


    Одна из самых частых негативных историй, которые я слышу от разработчиков про lead'ов — все интересные куски лид забирает себе. От лидов же получаю другой фидбэк, что самая частая проблема — есть задача и её ВООБЩЕ НИКАК!!!111 нельзя делегировать.Отсюда вытекает ряд проблем.


    • Время — ресурс ограниченный. Если лид будет делать интересные таски, а не свою работу, то работа будет попросту не сделана.
    • Заключая большинство компетенций внутри одного человека, вы получаете абсолютно немасштабируемую систему. А что самое интересное, получаете фактор автобуса. Конечно, этим можно оперировать при обсуждении зарплаты, но по факту вы не становитесь лучше как лид, а лишь узурпируете власть.
    • Ваша команда не растёт. Никто не понимает установленных процессов, потому что их нет.

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


    Варианты будущего роста


    Раз у вас уже возник вопрос «а что дальше?» в бытность разработчиком, то он у вас возникнет и на этапе team lead. А здесь всё также можно следовать разобранной ранее схеме. Вопрос лишь в том, стоит ли развиваться как менеджер или всё-таки уйти еще глубже в сторону разработки в
    роли архитектора. Попробуйте, и вы сможете четко ответить на этот вопрос. Но как я говорил ранее, не задавайте его себе в первые несколько месяцев. Потому что находясь вне привычной зоны комфорта человек по умолчанию склонен негативно реагировать на любые стимулы. Разберитесь хотя бы в базовых вещах, потом принимайте решение.


    Что делать, если стали лидом


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


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

    Что сработало в моем случае может сработать и в вашем. Главная же доктрина заключается в том, что всё приходит с опытом. Если вы работаете в этом направлении, конечно. Проблемы со временем не исчезнут, вы просто научитесь их решать.


    Помните, что учиться можно не только на своём опыте, но и на чужих ошибках. Teamleadство — это круто.


    Список источников


    С. Макконнелл. Сколько стоит программный проект
    Дж. Ханк Рейнвотер Как пасти котов
    Давид Хейнемейер Ханссон и Джейсон Фрид. Rework

    Touch Instinct 72,28
    Разрабатываем мобильные приложения
    Поделиться публикацией
    Похожие публикации
    Комментарии 24
    • +8
      Хорошая статья. Хотя бы потому, что во время прочтения мне пришла мысль по поводу того как улучшить один из процессов у себя в отделе. Попадись мне что-то подобное несколько месяцев назад, было бы еще круче.
      • +2
        Огромное спасибо за статью!
        • +10
          На мой взгляд, слишком много «воды» и общих фраз, весьма далеких, по крайней мере, от моей реальности. Я понимаю, что «усредненный посетитель хабра» работает как минимум в многотысячном энтерпрайзе, с миллиардными оборотами и доходами, в командах по 100 человек. Весьма возможно, что рассуждения, показавшиеся мне «водянистыми» и далекими от реальной жизни, в подобных компаниях жизненно необходимы и полезны, не буду спорить.

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

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

          Попробую описать типичную ситуацию и роль тим-лидов в ней: крупному заказчику потребовалась абсолютно новая «фича», требующая серьезных изменений как в backend, так и в middleware (по сути, нужно было писать новый сервер, а в клиентских middleware поддержку нового протокола).

          Chairman и CTO собирают совещание тимлидов и архитектора, и дискутируют о возможных реализациях (о сложности, времени и т.п.). Тут есть очень важный момент: реализовать можно так, чтобы клиентская часть была проще (но тогда, естественно, серверная часть становится намного сложнее), либо наоборот. Вот тут начинается борьба тимлидов; чем тимлид победит, тот и круче (с точки зрения его команды). Понятно, что я тут немного утрирую, и все происходит вовсе не так уж просто — тимлиды проводят совещания с командой и ищут правильные аргументы в поддержку своего решения (то бишь, выгодного для команды).

          То есть, главная «внешняя» (по отношению к команде) функция тимлида заключается в разумном отстаивании интересов команды.

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

          Еще в обязанности тимлида у нас входило слежение за правильным выполнением технологий программирования, «утрясание» конфликтов с QA (очень неприятная задача!), «пробивание» нужных команде «фич» в проект, а также «выбивание» дополнительных ресурсов (как человеческих, так и материальных — хотя ими, формально, он не должен был заниматься).

          P.S. Но, вообще-то, с точки зрения ответственности за принимаемые решения хуже приходится PM-у (или, в нашем случае, CTO).
          • +9
            Отстаивание интересов отдела — так себе стратегия. При этом компания превращается в такое подобие Киевской Руси времён Татаро-Монгольского нашествия — куча грызущихся между собой «княжеств», не способных объединиться против общего «врага».

            Да, наверное это идеальная среда для «просто работников», которые приходят просиживать штаны от зарплаты и до обеда. Как говорится «солдат спит — служба идёт», и чем меньше работы — тем лучше.

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

            Продукт при таком управлении превращается в говно. На жалобы пользователей следует ответ «это ответственность не моего отдела» с бесконечными переводами стрелок. Качество продукта никого не волнует, потому что каждый отдел решает не общие задачи, а пилит что-то интересное им, да и в конце концов «есть семьи, хобби и жизнь вне офиса».

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

            Это не моя фантазия, а реальный опыт на некотором этапе (с точки зрения специалиста, не начальника).
            • 0
              dendron, все, вышеизложенное мной — не некий «сферический конь в вакууме», а сокращенное обобщение личного опыта работы в чрезвычайно успешном американском стартапе, основанном одной легендарной (в узких кругах) личностью (если вам так интересно, могу отписать в личку). Я не знаком с вашим опытом (и заранее написал «отмазку» про многобиллионные энтерпрайзы), но, уверяю вас, стартап с продуктом был продан за сумму, за которую в России продаются считанные компании, и принес «отцам-основателям» 500% процентную прибыль.

              Не было никаких «княжеств», да и не могло быть: ведь все employee были заинтересованы в acquisition, и, могу вас заверить, не прогадали (хотя, конечно, целью было не IPO, и это сказалось на результатах для обычных сотрудников — ну, так слишком много никто и не обещал!). Просто в результате хорошего профессионального менеджмента, проводимого CEO, «войны» тимлидов приводили к выработке оптимального по балансу и времени решения, которое удовлетворяло всех.

              Возможно, тут сыграло роль иная, в отличие от российской, пресловутая «ментальность» — ну, не принято у нас «кадык вырывать», «мамой клясться», и испытывать неиллюзорную ненависть к оппоненту!

              Продукт в «говно» никогда не превращался; ответственность команд за showstoppers — это вещь предельно ясная и дискуссий тут быть не может, всегда ясно, чей «косяк».

              А профессионалы, замечу, это далеко не всегда «гики-работоголики»; одним из лучших профессионалов, которых я знал (как раз по этой работе), как ни странно, была мать троих детей из Индии (и, замечу, очень хорошая мать). Да, она не любила overtime, но, благодаря хорошим и профессиональным teamleads у нас их практически и не было! Зато девушка (преимущества моего возраста в том, что я женщин среднего возраста всегда называю девушками :) ) очень быстро (даже, парадоксально быстро) «въезжала в тему», и даже сумела перебороть (под моим чутким руководством) страсть к «индусскому говнокодированию», что вообще не поддается объяснению!
              • 0
                >Продукт в «говно» никогда не превращался; ответственность команд за showstoppers — это вещь предельно ясная и дискуссий тут быть не может, всегда ясно, чей «косяк».

                Ну здорово что у вас всё так ясно было. Но явные косяки (за которые будет бо-бо) люди и так стараются не делать. А чаще бывает что «косяк» находится в зоне ответственности между отделами, вида «один не доделал, второй не додумал». И начинается бесконечный срач, потому что никто не хочет за других работу делать. Или хуже — из-за размытия ответственности и общей атмосферы «моя хата с краю» все предпочитают просто закрыть глаза на проблему (пока не придёт «мотивация» от начальства сверху).

                >ведь все employee были заинтересованы в acquisition
                А вот эта самая загадочная часть. Вроде бы совершенно никакой мотивации нет в успехе общего дела (потому что нет этого общего дела, есть только «я тут сижу, примус починяю»). Возможно это действительно некая ментальность или атмосфера в той конкретной компании. Потому что тут явное противоречие с остальной идеологией.

                >А профессионалы, замечу, это далеко не всегда «гики-работоголики»
                Я этого не утверждал. Есть разница между тем переживает человек за конечный результат своей работы, или просто просиживает офисные часы (занимается саморазвитием/пробует интересные технологии/втайне пишет своё приложение — выберите сами). А перерабатывать или нет — каждый выбирает сам.
                • 0
                  А чаще бывает что «косяк» находится в зоне ответственности между отделами, вида «один не доделал, второй не додумал».

                  Вы говорите об архитектурных ошибках; у нас, благодаря правильной архитектуре и менеджменту, таких ошибок не было. То есть, ошибки практически всегда четко классифицировались, и никакого «срача» не возникало (за 6 лет, лишь пару-тройку раз QA неправильно классифицировал ошибку, но, опять-таки, все разрешалось очень просто, без «срачей»). Никакого «размытия ответственности» не было, да и не могло быть.

                  А вот эта самая загадочная часть. Вроде бы совершенно никакой мотивации нет

                  Ничего загадочного нет, все очень просто! Вы, видимо, не знакомы с западными реалиями, но тут дела обстоят так: обычно, в крупные и известные компании профессионал идет в расчете на карьерный рост, шансов на это в большой компании намного больше, чем в маленькой. Небольшие компании, а в особенности — стартапы, чтобы «заманить» хорошего специалиста, должны использовать всевозможные «пряники», как-то высокие зарплаты и «благие обещания» (обычно «благие обещания» изначально оцениваются дешевле). То бишь «мотивация» обеспечивается договором, в котором employee гарантируется либо определенная часть shares в случае IPO (это, как правило, очень сильная «замануха», сродни «золотой лихорадки», в случае успеха можно действительно получить очень много), либо определенный фиксированный бонус в случае продажи компании.

                  А перерабатывать или нет — каждый выбирает сам.

                  Гмм, вы или очень молоды, или очень неопытны (или и то, и другое вместе). Иным я столь странное утверждение объяснить не могу.
                  • +1
                    >То бишь «мотивация» обеспечивается договором, в котором employee гарантируется либо определенная часть shares в случае IPO
                    Вся ясно, мы с вами в разных мирах вращаемся.

                    >Гмм, вы или очень молоды, или очень неопытны (или и то, и другое вместе). Иным я столь странное утверждение объяснить не могу.

                    Для вас странное, для меня — нет. В любом случае, хамить не следовало бы. За сим разговор с вами прекращаю.
                    • –2
                      Дорогой dendron, не нужно быть Шерлоком Холмсом, чтобы определить молодость и отсутствие жизненного опыта в ваших незрелых суждениях! Но в одном вы ошибаетесь — констатация того факта, что вы молоды и неопытны — это не упрёк, а, скорее, комплимент. И зря вы упрекаете меня в каком-то «хамстве» — ведь я не сказал, что ваши бредовые максималистические высказывания обусловлены банальной глупостью? Я всегда думаю о людях хорошо, вот такой я добряк.

                      Ничего, подрастете, поднакопите опыта, обзаведетесь (дай Бог!) семьей — и, наконец, поймете, как мир устроен :)
                      • +2

                        Ремарки на тему "вы еще молоды и неопытны" в данном случае прозвучали в поучительном тоне. Вот dendron и возмутился.

                    • 0
                      Полностью с вами согласен, что возможность выбора переработок есть только пока нет семьи и детей. И если кому-то не хватает восьми часового рабочего дня для того что бы окончательно вымотаться к вечеру, то ему есть куда расти в плане повышения продуктивности.
                      • 0
                        Уважаемый arcman, я бы сказал даже больше: если у неопытного юноши нет вариантов, «куда податься вечером», кроме как сидеть и «тупить» в офисе над кодом, ему стоит серьёзно задуматься над своей жизнью! Тут не о «продуктивности» нужно думать, а о репродуктивности! (вот такой вот родился каламбур :) )
                • +1
                  каждый отдел решает не общие задачи, а пилит что-то интересное им
                  Идеально.
              • 0

                Да, большое спасибо!

                • 0
                  Статья развернутая, но имхо для человека, которому дали эту роль придется в его конкретных условиях строить свою команду. Я как-то смотрел презентацию, в которой в довольно убедительной манере рассказывалось про процесс эволюции тим лидера. Начинается с получения роли и иногда желания поруководить и заканчивается полным доверием со стороны команды. Это занимает время, приходит с опытом, а иногда не приходит вообще. Процессы… Они могут вызывать отторжение. Неопытный тим лид может попытаться их жестко навязать. Это может стать проблемой. Согласен с автором в том, что бизнес рулит и все хорошо что хорошо для него в итоге. Процессы так процессы. Или их отсутсвие и анархия. Заказчик самый главный. По поводу защиты интересов команды, тут главное не перестараться и объяснить в случае чего заказчику, что мол больше мы делать не можем. Честно объяснить.
                  • –1
                    Как правило, тимлид выбирается из наиболее опытных и уважаемых членов команды (никогда не слышал о позиции тимлида, по крайней мере, на US маркете — обычно из «сопоставимых» величин ищут или PM-а, или архитектора). Из этого следует, что вопрос доверия команды, как правило, просто не возникает.

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

                    Абстрактные советы для «сферического тимлида в вакууме», типа «продумайте систему обучения сотрудников» (зачем их обучать? Вы набрали newbies на проект?!), или «настройте процессы работы в отделе. При этом максимально их задокументируйте» (какие «процессы»??? И зачем «документировать» что-то, лишенное сущности? Кому вы покажете эту бюрократию, когда вас вышвырнут за не исполнение прямых обязанностей?! Адвокату? Ни один адвокат за такое просто не возьмется!).

                    В общем, статья практически ни о чем. Хотите быть хорошим тимлидом — отстаивайте интересы команды, и не подводите менеджмент по срокам. Все!
                  • 0
                    Детская статья с детской логикой, графиками и смешными картинками.
                    • –1
                      Мастер Йода ожидаем тут был, и вот он тут. Лидинг он такой.
                      • +1
                        Я конечно понимаю, что не совсем по теме, но помнит кто, из какой игры красные человечки в самом начале статьи? :3
                        • +1
                          Lines досовская по моему.
                          • 0
                            Ayyy, да, именно она, спасибо! Поностальгирую
                          • 0
                            balda,lines,nine, серия старых досовских игр, вроде бы.
                            • 0
                              http://games-history.ru/games/view/ninerus.htm
                            • 0
                              Настройте процессы работы в отделе. При этом максимально их задокументируйте.
                              Продумайте систему обучения сотрудников.
                              Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
                              Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.

                              Согласно моему опыту этот список это скорее ряд ошибок, а не полезных практик:


                              Настройте процессы работы в отделе. При этом максимально их задокументируйте.

                              Тут возможнвы два случая:


                              • наиболее вероятно вы стали лидом в существующей коменде. Она ведь как-то работает? и работала. не нужно насаждать "процессы всегда и везде" т.к. получите запредельный уровень сопротивления. Работайте как консультант — присматривайтесь, вносите предложения на рассмотрение самой команде, если они отторгают, значит не понимают зачем это надо, что является вашей проблемой, а не команды. Если вы начинаете документировать процесс, то либо у вас большая текучка и это действительно имеет смысл, либо ваши процессы не очевидны и уложить их в голове 3-4 принципами и 2-3 практивкам невозможно, опять же — вы перегибаете палку с формализмом.
                              • менее вероятно, что новичка поставили в новую команду к незнакомым ему людям. тут надо не настраивать процессы, а создать и сполить команду хоть как-то выполняя задачи. Периоды Forming и Storming никто не отменял.

                              Продумайте систему обучения сотрудников.

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


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

                              вот он, тот пункт, над которым можно и нужно работать бесконечно. самый сложный и самый важный для вас как лида. Только делегируя вы начнете использовать ваше время во благо компании, а не попусту. Читайте про "7 уровней делигирования" и тп модели. "Правильная система делегирования" это вода, вы должны ставить куда более четкие цели, например: 40% критических задач, которыми раньше занимался только я теперь должны делать другие люди. Цель "Учитесь искать метрики и измерять ваши результаты" мне в своё время помогла куда больше, чем что либо еще. И самое главное "правильного делегирования" нет и не будет. Есть то, что работает лично у вас с вышей командой.


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

                              Кажется, что очень правильный совет, но дьявол в деталях. Именно с такой идеей я подходил к решению всех возможных не понятных ситуаций и только спустя пару лет осознал, что стал "митинг манагером", проводящий по 3-4 часа в день в митинг румах. Многие проблемы могут решиться и без вас, не реигруйте на все сразу — у вас нет столько времени. Дайте проблемам немного настояться, чтобы появилось четкое понимание их причин. Давайте возможность людям самим решать свои конфликты и подключайтесь только на 2-3 уровене эскалации. Проблема пришла сверху? Не надо звать в митинг рум ваших менеджеров/команду и искать решение. Подумайте, посторайтесь сами принять какое-то решение и поделитесь своим видением с менеджментом тем же емейлом, с подписью "я бы рекомендовал личную/skype встречу для уточнения деталей" на первое время. Помогайте вашему руководству, а не отнимайте у него время.


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

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое