Так получилось что пришёл на проект который писали разные люди с разным уровнем. В итоге имеем не очень хорошую архитектуру и разные подходы в проекте. Раньше руководством не занимался. Сейчас планируется нанимать новых людей из за расширения проекта.
Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
Если ресурсы позволяют и/или уровень разработчиков не высокий, то стоит. Еще стоит если разработчики новые, и не знают кучи специфики конкретно этого проекта, через годик отменить за ненадобностью.
Сам работаю на подобном проекте.
Из плохой архитектуры ещё худшую много труда не составит сделать. Ну и реализация может обрасти такими фекалиями, что архитектура будет казать ещё и не плохой .
Здравствуйте, e.thrash, Вы писали:
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Например, он должен уметь задавать правильные вопросы
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
Этот вопрос не имеет смысла. Надо ли проводить ревью или нет зависит не от конкретного состояния архитектуры, а от целей и контекста проекта.
Например, у меня в одном из проектов сейчас с архитектурой тоже не айс, но есть конкретные планы исправить положение, потому что продукт планируется развивать дальше, а проблемы с тех.долгом этому стали конкретно мешать.
Здравствуйте, e.thrash, Вы писали:
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
хороший тимлид умеет как сам делать, так и объяснять людям, что и как надо сделать. и почему так.
плохой тимлид много говорит и мало делает.
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
ревью имеет смысл делать, чтобы удержать код в рамках одной архитектуры, одного дизайна.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, e.thrash, Вы писали:
ET>>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
F>хороший тимлид умеет как сам делать, так и объяснять людям, что и как надо сделать. и почему так.
если новый человек сразу пускается в споры? типа: "я считаю это меньше чем за неделю не сделать", хотя я могу сделать за пару дней. Вещь не специфика проекта.
F>плохой тимлид много говорит и мало делает.
увы, мне часто приходится быть на митингах и т.д. и мало пишу код. 30% времени
ET>>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
F>ревью имеет смысл делать, чтобы удержать код в рамках одной архитектуры, одного дизайна.
а если рамок нет: один писал codefirst, второй database first, то как новому сказать, что ado.net не надо вводить? естественный вопрос может быть: если и так каша, то почему нельзя?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, e.thrash, Вы писали:
ET>>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид? 0>Например, он должен уметь задавать правильные вопросы
Спросил у нового разработчика сколько времени надо на такую рюшечку? сказали мне 2 недели. я сделаю за 3 дня. Говорю почему? ответ: "универсально". Говорю "давай попростому, т.к. нет столько времени". Ответ: "делай сам тогда". Явно что-то не так в общении.
ET>>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой? 0>Этот вопрос не имеет смысла. Надо ли проводить ревью или нет зависит не от конкретного состояния архитектуры, а от целей и контекста проекта.
Цель: спросить у разработчика почему мало кода пишет на простых задачах? Но вопрос нормального разработчика может быть: "зачем ревью на гнилом проекте?". Тупичок.
0>Например, у меня в одном из проектов сейчас с архитектурой тоже не айс, но есть конкретные планы исправить положение, потому что продукт планируется развивать дальше, а проблемы с тех.долгом этому стали конкретно мешать.
Здравствуйте, e.thrash, Вы писали:
ET>если новый человек сразу пускается в споры? типа: "я считаю это меньше чем за неделю не сделать", хотя я могу сделать за пару дней. Вещь не специфика проекта.
я в таких случаях отсматриваю прогресс у этого человека по расписанию. вне зависимости от того, новичок это или нет. помогаю в случае необходимости.
F>>плохой тимлид много говорит и мало делает. ET>увы, мне часто приходится быть на митингах и т.д. и мало пишу код. 30% времени
много болтать вредно для проекта.
на одном таком болтливом проекте мне приходилось брать инициативу в свои руки, быстро всем объяснять, фиксировать результат обсуждения и заканчивать пустую трату времени.
ET>а если рамок нет: один писал codefirst, второй database first, то как новому сказать, что ado.net не надо вводить?
у тимлида помимо обязанностей есть и полномочия. он должен быть способен запретить какие-то вещи.
бывают ситуации, когда сложно объяснить, чем именно плох тот или иной подход. на обдумывание возможных проблем от неприятной реализации тоже нужно время. поэтому тимлиду бывает полезно остановить задачу, пока он всё не выяснит.
ну и нужно уметь признавать свои ошибки.
ET>естественный вопрос может быть: если и так каша, то почему нельзя?
потому что с этого момента надо решать проблемы, а не создавать новые.
Здравствуйте, e.thrash, Вы писали:
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Кэп: тимлидом становятся, а не назначаются.
Тимлид — это человек, который делает выбор и несёт ответственность за всю команду в ситуации "нет хорошего решения". Всё, больше у него никаких полномочий нет, да и то что есть получается только потому, что команда доверяет ему этот выбор сделать.
Если такого лида в команде нет, то команда или распадается, или берётся под ручное управление с назначением менеджера со стороны.
Других вариантов нет.
Вот это
Говорю "давай попростому, т.к. нет столько времени". Ответ: "делай сам тогда". Явно что-то не так в общении.
однозначно говорит, что лида в команде нет + новичка просто перекинули в команду без обязательного испытательного срока. Последнее как бы намекает, что проблемы не только с лидом, но и с менеджментом.
Хорошего решения тут уже нет, надо смотреть по обстоятельствам. Типовые "обсудить ситуацию с глазу на глаз", или "перекидываем на уровень выше" могут сработать не так, как ожидается
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
Нет. Код ревью не создаёт культуру разработки, а помогает её поддержать и передать остальным участникам команды.
Что вы будете ревьюить, если команда не может договориться даже про очевидное "а что мы собственно делаем?".
ET>Спросил у нового разработчика сколько времени надо на такую рюшечку? сказали мне 2 недели. я сделаю за 3 дня. Говорю почему? ответ: "универсально". Говорю "давай попростому, т.к. нет столько времени". Ответ: "делай сам тогда". Явно что-то не так в общении.
Действительно, что-то не так.
ET>Цель: спросить у разработчика почему мало кода пишет на простых задачах? Но вопрос нормального разработчика может быть: "зачем ревью на гнилом проекте?". Тупичок.
Это не цель, это задача. Причём мелкая и неважная. Цель — это бабки заработать
Вот от этой цели надо построить трассировку до таких вещей, как "надо ли делать ревью" и "перехерачивать ли архитектуру"
0>>Например, у меня в одном из проектов сейчас с архитектурой тоже не айс, но есть конкретные планы исправить положение, потому что продукт планируется развивать дальше, а проблемы с тех.долгом этому стали конкретно мешать. ET>аналогиная ситуация. Не поделитесь планами?
Ну, поскольку я — руководитель проектов, то моя информация может не очень релевантна твоей проблеме.
Но если в двух словах — составил с разработчиками список косяков в текущей реализации, составили план исправления, оценили его, потом я пошёл "продавать" его менеджеру продукта.
Он товарищ адекватный, согласился.
Здравствуйте, e.thrash, Вы писали:
ET>Что должно быть у хорошого тимлида из качеств
— Помогать другим участникам команды в организационных и технических вопросах (в пределах разумного времени)
— Отстаивать позицию команды или отдельных разработчиков (если разработчику действительно надо помочь) перед вышестоящим начальством
— Правильно распределять задачи среди членов команды, в зависимости от их способностей и загрузки
— Правильно определять приоритеты задач
— Доверять разработчикам, у которых больше знаний или опыта в каких-то конкретных областях, не давить на них своим тайтлом
— Помнить, что джуниор Вася может оказаться прав
— Быть достаточно активным (иначе, даже если это сильный программист, он может быть не самым лучшим претендентом на позицию тим-лида)
— Не тянуть одеяло на себя, уметь делегировать
— Заботиться о построении нужного окружения (вики, система контроля тасков, build server (если нужно), перейти на новую среду разработки, позаботиться о разных бэкапах, вводить полезные практики (тесты, например, если вдруг их нет) и т.д.)
— Заботиться о передаче знаний. Что если Вася, занимающийся деплойментом новых релизов заболеет? Сможет ли его кто-то заменить? Или, например, Петя первым научился классно генерировать код с помощью шаблонов (например Т4 в .NET) — пусть Петя проведёт презентацию для команды.
— Уметь поощрять, подбадривать разработчиков, а не только "Вася, почему ты блин потратил целых 2 часа на фичу Х?". По возможности стараться задавать позитивную, уважительную атмосферу в команде, сглаживать конфликты.
— Строить такую атмосферу, чтобы разработчики действительно слушали и слышали друг-друга, старались понять другую точку зрения; объяснять, если замечаешь, что Вася не понимает Петю, а Петя — Васю;
— Вести митинги, готовиться к ним, заранее думать, что надо будет обсудить, быть способным помнить или быстро узнать, кто чем занимается, какие основные текущие проблемы надо обсудить. При этом на митинге правильно распределять время, чтобы не потратить все отведенное время, если какой-то разработчик начнет нудно обсуждать какую-то мелкую проблему.
— Понимать, что все люди разные, и если кажется, что задачу можно сделать за день, а Петя просит 2 дня, а в итоге провозился все три, то это может быть нормально. Тем более, обычно кажется, что задачу можно решить быстрее, чем потом получается на практике.
— Спорные вопросы решать командой, если решить не удаётся, — эскалировать выше, если есть такая возможность и смысл.
— И наоборот, иногда не нужно слишком много дискутировать и экскалировать, а твердым решением тим-лида (если он достаточно опытен, уверен и готов взять ответственность) поставить точку в дискуссии.
— Признавать свои ошибки
— Смотреть шире, смотреть в будущее. Какие главные цели проекта через 1-2 месяца? Через полгода? Какие главные проблемы сейчас?
Вообще, раз вы новый человек на проекте, то вначале будьте чуть осторожнее, вы можете многого не понимать; первые пару месяцев больше присматривайтесь, задавайте вопросы.
С код ревью лично я бы пока не спешил — это может быть убийцей времени и пораждателем конфликтов.
Ну вот как бы верно, но слишком формально.
Как минимум половина "что должно быть" написана по принципу "врач должен быть в белом халате" и к прямым обязанностям тимлида не относится. Тимлид не обязательно project manager, это может быть архитектор, биз-аналитик или вообще девелопер без какой-либо формальной должности (в мелких командах чаще всего так и бывает).
Смотреть лучше не на внешние признаки, а на команду, в которой нет фактического тимлида. Разница обычно очевидна.
Здравствуйте, Sinix, Вы писали:
S>Ну вот как бы верно, но слишком формально.
Если что, это я писал на основе опыта работы на не самых маленьких проектах (т.е. проектах где задействовано >10 людей или >10 разработчиков), поэтому может казаться, что много всего..
Но не стоит рассматривать эти пункты, как формальные обязательные требования — это просто пожелания, то к чему можно стремиться, и то, что может быть полезным иметь в виду людям, у которых нет опыта или представления работы тим-лидом.
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Знать бы еще ваше определение "хорошего" и "плохого".
Хороший тимлид, который приносит много дохода компании, может быть довольно плохим для своей команды. И наоборот — кого команда любит, может не особо толковым быть с точки зрения бизнеса.
Здравствуйте, SkyDance, Вы писали:
SD>Хороший тимлид, который приносит много дохода компании, может быть довольно плохим для своей команды. И наоборот — кого команда любит, может не особо толковым быть с точки зрения бизнеса.
Лучше быть богатым, но здоровым, чем больным и бедным.
Здравствуйте, Sinix, Вы писали:
ET>>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид? S>Кэп: тимлидом становятся, а не назначаются.
Назначаются, это фактически одной ногой менеджмент. Когда собирается новый проект, откуда возьмется тимлид ?
S>Тимлид — это человек, который делает выбор и несёт ответственность за всю команду в ситуации "нет хорошего решения". Всё, больше у него никаких полномочий нет, да и то что есть получается только потому, что команда доверяет ему этот выбор сделать.
Тимлид это это менеджер самого низшего звена. Несение ответственности — в чем заключается это несение по твоему ?
Полномочия у него есть — например принятие решений брать не брать, или кого убрать. Промоушны его подчиненных тоже не нем же. И когда ЗП ктото захочет побольше — идет к нему же.
S>Если такого лида в команде нет, то команда или распадается, или берётся под ручное управление с назначением менеджера со стороны. S>Других вариантов нет.
Ты путаешь лидера и руководителя. В команде может быть несколько лидеров, каждый в своей области и один тимлид.
I>Назначаются, это фактически одной ногой менеджмент. Когда собирается новый проект, откуда возьмется тимлид ?
О разных вещах говорим.
Ты о формальном тимлиде, я о фактическом.
Формальный — самое бесполезная и несчастная должность: полномочий 0, зато в любом косяке крайний. Он только деморализует команду и в большинстве проектов нафиг не нужен.
Проще ввести должность лид-девелопера + поддерживать нормальное общение с менеджером проекта. Это если команд несколько. Если одна — он вообще не нужен, т.к. или есть нормальный проект-менеджер, или проект загнётся.
Здравствуйте, Sinix, Вы писали:
S>Ты о формальном тимлиде, я о фактическом. S>Формальный — самое бесполезная и несчастная должность: полномочий 0, зато в любом косяке крайний. Он только деморализует команду и в большинстве проектов нафиг не нужен.
Это возможно твой негативный опыт. Руководитель низшего звена в нормальной конторе обладает определенными полномочиями.
S>Проще ввести должность лид-девелопера + поддерживать нормальное общение с менеджером проекта. Это если команд несколько. Если одна — он вообще не нужен, т.к. или есть нормальный проект-менеджер, или проект загнётся.
Лид-девелопер это в основном тот, кто может выполнять самые разные роли — линейного девелопера, кей-девелопера, тимлида, архитекта, консультанта и тд.
Все эти должности-роли-позиции есть сильно разные вещи в зависимости от конторы, размера и тд.
I>Все эти должности-роли-позиции есть сильно разные вещи в зависимости от конторы, размера и тд.
Ну вот походу у путаница в терминологии Везде, где работал, было примерно так: тим-лид — это фактический лидер в команде, лид-девлопер — человек, отвечающий помимо разработки ещё и за организацию работы, эдакий посол от продакт-менеджера в команде.
Здравствуйте, e.thrash, Вы писали:
ET>Так получилось что пришёл на проект который писали разные люди с разным уровнем. В итоге имеем не очень хорошую архитектуру и разные подходы в проекте. Раньше руководством не занимался. Сейчас планируется нанимать новых людей из за расширения проекта. ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Хороший тимлид мотивирует команду. И является примером.
Если он отвечает за архитектуру то его позиция должна быть понятная всей команде.
В случае если проект с историей, то первое что нужно сделать придя в новую команду это:
1. на вопросы ответить
2. ожидания прояснить
3. опасения снять (например что революции не будет)
Из роли Архитектора и техлида нужно:
1. Определить правила игры. правила кода. правила архитектуры.
2. Сделать реинжиниринг системы и понять что хотел автор когда это писал.
3. Внедрить методологию, ревью кода, и тд.
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
да, смысл есть. но нужна база с которой можно сравниться и сказать что "здесь плохо, потому что противоречит правилам и Идее"
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
1 и абсолютно фундаментальное требование к любому руководителю — способность нанять себе комманду. Поэтому первый вопрос к лиду — сколько времени ему потребуется чтобы нанять 1 разработчика. Сколько это будет стоить и займет времени.
Не знает, жует сопли — не лид.
2е — умение слушать и понимать что ему говорят. Если лид не понял какой цели нужно достигнуть — вся комманда будет страдать непонятно чем. Не слушает, не понимает — не лид.
3е — понимание экономики ПО, сколько тестеров нужно на 1 программиста, сколько тех-писов, как делится тратится время и ресурсы в разбивке дизайн/программирование/тестирование/поддержка. Не понимает, значит не сможет сделать нормальные оценки, не сможет поставить продукт приличного качества в срок — не лид.
4е — тех уровень синьора, разумеется.
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
-код ревью не связан с архитектурой от слова совсем
-это не важно
.
Везде, где работал, было примерно так: тим-лид — это фактический лидер в команде, лид-девлопер — человек, отвечающий помимо разработки ещё и за организацию работы, эдакий посол от продакт-менеджера в команде.
