Comments 36
А как появляются лидеры в гильдиях QA/Dev? Их кто-то назначает, озвучивая примерный скоуп ответственности, или это самопровозглашённые лидеры с амбициями от природы?
Лидерство и амбиции — это вообще-то несвязанные вещи. В статье:
тащат команду на себе, не потому что им сказали это делать, а оттого, что им самим это нравится — они чувствуют азарт
Лидер — человек, который «в потоке», его прёт, ему интересно. Например, работая в проекте, который социально значим, приносит добро в мир. А деньги или признание это уже вторично.
С другой стороны, один и тот же человек может в одном проекте/организации тупить и быть середнячком, а в другом — быть в разы продуктивнее и ценнее. Нет тут ничего «от природы». Главное чтобы человек оказался в нужном месте и в нужное время.
Это как и среди разработчиков самопровозглашённые лидеры. Дело не в амбициях. Чаще это просто крутые профессионалы, которым интересно работать и получать результат. Они пользуются уважением команды и руководства за их знания и успехи. К ним идут люди за помощью и они сами часто вызываются вести проекты. Например в QA y нас есть инженер, который развивает методологию авто тестинга. Его никто на эту роль не назначал. И он работает в одной из команд, а не выделен не эту задачу. Важная деталь здесь, что руководство принимает и поощряет его инициативу, в том числе позволяя ему выделять на это время.
Тимлид — человек отвечающий за культуру разработки в сочетании с конкретной предметной областью. В статье — просто какое-то феерическое непонимание роли тимлида.
Если отказались от лидов, то какая роль CTO? Он теперь тоже пишет код?
DevOps управляет инцидентами а Скрам-Мастер процессами?
Если члены команды имеют разные мнения — каждый делает по своему?
DevOps управляет инцидентами а Скрам-Мастер процессами?
Если члены команды имеют разные мнения — каждый делает по своему?
Мои роли
1. Участвовать в разработке стратегии компании
2. Доносить стратегию компании до всех и следить, чтобы наш роадмап лучшим образом соответствовал продвижению по этой стратегии.
3. Создание, внедрение и развитие культуры отдела
4. Управление командой функциональных менеджеров
5. Бюджет, ресурсы
6. Создание команд.
7. Помощь командам в лице функциональных менеджеров в найме, увольнении, решении конфликтов
8. Помощь в создании и выполнение технологического роадмапа включая внедрение новых технологий и сокращение technical debt
9. Создание и воплощение индивидуального плана развития для всех членов команды (выполняется функциональными менеджерами).
10. Прямое управление в кризисных ситуациях.
И еще вагон и тележка задач. Не сижу без дела. Код не пишу.
Ответсвенность за инциденты на командах. DevOps, который часть команды, конечно выжнейший человек в этом процессе.
Команда решает разногласия сама. Если у ребят не получается договориться (случается редко, это вопрос культуры взаимодействия) то им помогает функциональные менеджеры.
1. Участвовать в разработке стратегии компании
2. Доносить стратегию компании до всех и следить, чтобы наш роадмап лучшим образом соответствовал продвижению по этой стратегии.
3. Создание, внедрение и развитие культуры отдела
4. Управление командой функциональных менеджеров
5. Бюджет, ресурсы
6. Создание команд.
7. Помощь командам в лице функциональных менеджеров в найме, увольнении, решении конфликтов
8. Помощь в создании и выполнение технологического роадмапа включая внедрение новых технологий и сокращение technical debt
9. Создание и воплощение индивидуального плана развития для всех членов команды (выполняется функциональными менеджерами).
10. Прямое управление в кризисных ситуациях.
И еще вагон и тележка задач. Не сижу без дела. Код не пишу.
Ответсвенность за инциденты на командах. DevOps, который часть команды, конечно выжнейший человек в этом процессе.
Команда решает разногласия сама. Если у ребят не получается договориться (случается редко, это вопрос культуры взаимодействия) то им помогает функциональные менеджеры.
Я правильно понял? Тимлид не нужен? А скрам «я не знаю вообще предметную область, не разбираюсь в бизнес-процессах» мастер нужен?
Тим лид занимается культурой кода. Вырабатывает правила и следит за их выполнением. Общается с разрабами объясняет моменты. Определяет кому лучше какими тасками заниматься и т.д.
Тим лид занимается культурой кода. Вырабатывает правила и следит за их выполнением. Общается с разрабами объясняет моменты. Определяет кому лучше какими тасками заниматься и т.д.
У нас культурой кода занимаются ведущие разработчики. Мы не видим смысла выдавать им для этого официальную роль. Вообще история с важностью «культуры кода» преувеличена. Инженеры (не кодеры) с 5 годами опыта умеют писать код очень хорошо. Это как обучать врача лечить. Думать про какие то общие правила написания кода это одно, а постоянно заниматься этим и еще иметь для этого выделенною роль это как то странно. Ведь у нас не школа, чтобы на каждых 4-5 инженеров иметь по учителю. Возможно, что если в компании преобладают джуны, то их нужно постоянно контролировать и учить писать код. У нас есть одна единственная команда SWAT с тим лидом, которая занимается поддержкой. Мы туда нанимаем исключительно джунов. Тим лид их растит, учит код писать.
Скрам мастера у нас есть. Можно иметь выделенных скрам мастеров, можно чтобы эту роль выполнял кто-то параллельно со своими задачами разработчика или тестировщика (мы так делаем). Можно каждый спринт ротировать скрам мастера (одна наша команда так делает). Можно в очень дружных и эффективных командах вообще без скрам мастера.
Скрам мастера у нас есть. Можно иметь выделенных скрам мастеров, можно чтобы эту роль выполнял кто-то параллельно со своими задачами разработчика или тестировщика (мы так делаем). Можно каждый спринт ротировать скрам мастера (одна наша команда так делает). Можно в очень дружных и эффективных командах вообще без скрам мастера.
Вы заблуждаетесь в большинстве вашего текста.
Начнем с того, что врачи постоянно ходят на повышение квалификации. И даже преподаватели в вузах ходят.
Затем вы ошибаетесь, что инженеры пишут код хорошо. Они пишут код чтобы он работал хорошо (и то не всегда), а о том, чтобы он легко поддерживался и был расширяемым мало кто думает, особенно если в команде есть скрам-мастер.
В третьих, никто не говорит, что роль тим-лида должна быть выделена и отдельной. Ее может совмещать в небольших командах ведущий разраб. А уже на 10-12 человек у него вообще не будет почти времени на кодирование.
Потому что идут десятки коммитов в день и нужно тупо хотя бы пул реквесты проверять.
Начнем с того, что врачи постоянно ходят на повышение квалификации. И даже преподаватели в вузах ходят.
Затем вы ошибаетесь, что инженеры пишут код хорошо. Они пишут код чтобы он работал хорошо (и то не всегда), а о том, чтобы он легко поддерживался и был расширяемым мало кто думает, особенно если в команде есть скрам-мастер.
В третьих, никто не говорит, что роль тим-лида должна быть выделена и отдельной. Ее может совмещать в небольших командах ведущий разраб. А уже на 10-12 человек у него вообще не будет почти времени на кодирование.
Потому что идут десятки коммитов в день и нужно тупо хотя бы пул реквесты проверять.
Я не буду спорить. Я знаю что не ошибаюсь так как под моим руководством 3 компании вышли на исключительно высокий уровень и создали прекрасные продукты, в том числе с технологическом плане. Ревью делают ведущие разработчики. Выделять для этого официальную роль не вижу смысла. Если ваши разработчики не думают про поддерживаемость, расширяемость и так далее, то у вас плохие разработчики. Их нужно менять или растить.
Мы вкладываем огромные ресурсы в рост наших разработчиков. Они ездят на конфы включая международные, выступают там, ходят на курсы. Люди участвуют в коммисиях по тех улучшениям. Но нет выделенных тим или тех лидов.
Мы вкладываем огромные ресурсы в рост наших разработчиков. Они ездят на конфы включая международные, выступают там, ходят на курсы. Люди участвуют в коммисиях по тех улучшениям. Но нет выделенных тим или тех лидов.
Вот вы в прошлом комменте всё написали правильно, только забыли написать про код-ревью. Действительно, если каждый мердж происходит только после код-ревью несколькими другими участниками команды, то код получается и поддерживаемым и расширяемым.
Каким образом ошибка выжившего говорит о проблеме в целом?
Одну конкретную компанию можно построить по любым процессам. Если сложилось, что уровень высокий, процессы отлажены и люди умеют общаться — да, вполне можно обходиться без дополнительной прослойки.
Но так бывает далеко не всегда. Я достаточно проработал в энтерпрайзе чтобы понять, что процессы в маленьких и больших компаниях совершенно разные. Невозможно нанять тысячу хороших программистов. Значит процессы нужно подстраивать под средних. В результате, вы получаете кучу дополнительных людей, чтобы процесс хоть как-то предсказуемо работает.
Вы серьезно считаете, что это хоть как-то помогает?
Одну конкретную компанию можно построить по любым процессам. Если сложилось, что уровень высокий, процессы отлажены и люди умеют общаться — да, вполне можно обходиться без дополнительной прослойки.
Но так бывает далеко не всегда. Я достаточно проработал в энтерпрайзе чтобы понять, что процессы в маленьких и больших компаниях совершенно разные. Невозможно нанять тысячу хороших программистов. Значит процессы нужно подстраивать под средних. В результате, вы получаете кучу дополнительных людей, чтобы процесс хоть как-то предсказуемо работает.
Они ездят на конфы включая международные, выступают там, ходят на курсы.
Вы серьезно считаете, что это хоть как-то помогает?
Я описал свою систему. Она отличается от того что практикуется в России. Я не уговариваю вас ее принять или применять. Для меня работает очень хорошо. Я посоветовал бы просто задуматься над тем, что я написал. Возможно, это будет вам полезно. Если нет, то не берите ничего из этих практик. И конечно, как все на свете, эта система не применима во всех случаях. Эта система точно работает в продуктовых копаниях В2С, с численностью отдела разработки до 200-300 человек. Работает ли она в других случаях я НЕ ЗНАЮ. У Spotify и многих других западных компаний есть подобная система, но я не могу сказать что я очень глубоко изучил их опыт. Я действующий CTO а не консультант и у меня нет времени на глубокие исследования.
Кроме последнего пункта вы больше про техлида говорите, нет?
Описанная ситуация хорошо работает на несложных и типичных задачах.
Опустим работу аналитика. Но как быть в случае дилеммы в выборе технической реализации, когда есть два плохих варианта, которые поддерживаются разными участниками команды? Кто примет это плохое решение?
У нас AdNetwork с 10 миллиардами импрешенами в день. Как можно догадаться у нас мало типичных задач. Команде не нужен «папа» который примет правильное решение. Люди вполне договариваются сами. Культура доверия и уважения очень помогает. Конечно команды ошибаются. Но тим лиды тоже ошибаются и на моем опыте чаще.
Но часто ли вы видели увольняющегося CTO?
Я сам такой )
А чем техлиды у вас занимаются? Как по мне, многие разработчики идут в тимлиды, лишь потому что позиций чистых техлидов мало, а тимлид чаще всего — это техлид+часть обязанностей ПМ в нагрузку. Вот и идут в тимлиды, чтобы хоть часть времени быть техлидом. Сам такой.
У нас нет тех лидов. В каждой команде есть крутые разработчики. Они по сути выполняют роль тех лидов, но без официального бейджика. Им от этого лучше, потому что оплачиваются они как тех лиды, а формальных обязанностей тех лидов у них нет. Такую систему тяжелей организовать. Гораздо легче раздать должности и часто ничего не означающие титлы, такие как Second degree Senior backend developer. Но зато команда состоящая не из руководителей и подчинённых, а из равных друг-другу людей гораздо более сплоченная, ответственная и вовлеченная. Это не отменяет того что джуны и мидлы уважают мнение сеньоров и учатся у них. И это не отменяет роль сеньоров как менторов молодежи и гарантов качества продукта, технологии и кода.
Тут был вопрос — а что же делает CTO. Так вот CTO со своей командой руководителей как раз и выстраивает эту далеко не простую систему.
Тут был вопрос — а что же делает CTO. Так вот CTO со своей командой руководителей как раз и выстраивает эту далеко не простую систему.
Крутая статья, и я рад, что у вас всё работает, но у меня впечатление, что всё определяется адекватностью и квалифицированностью конкретной группы людей, а структура просто подходит для этой конкретной группы. У вас это продуктовые менеджеры, а в другом месте это будут тимлиды, техлиды, кто-то вообще скажет QA или dev-ops и т.п.
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Нет тайтла — нет причин платить им зарплату как тех лидам.
— Мы платим. Никакая система не будет работать если вы говорите одно, а делаете другое
— Сеньеры работают в командах. Они же являются неформальными тех лидами. Мы обходимся без архитекторов. Вместо этого у нас меж-командные рабочие группы по развитию технологии. Архитектор вполне может быть в этой системе. Он будет вне команд. Он же не руководитель, а больше советник. У нас например UX вне команд.
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители.
— конечно ПО неявные лидеры. Как же по другому? Но они ни кем не руководят. Они занимаются бэклогом, общением с клиентами, сбором аналитики так далее.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д
— Задача руководства это добиться чтобы описанных проблем между ПО и разработкой не было. Это культурная и профессиональная составляющая. Этому еще очень помогает то что главная команда ПО это команда разработки.
Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.
— Мы платим. Никакая система не будет работать если вы говорите одно, а делаете другое
— Сеньеры работают в командах. Они же являются неформальными тех лидами. Мы обходимся без архитекторов. Вместо этого у нас меж-командные рабочие группы по развитию технологии. Архитектор вполне может быть в этой системе. Он будет вне команд. Он же не руководитель, а больше советник. У нас например UX вне команд.
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители.
— конечно ПО неявные лидеры. Как же по другому? Но они ни кем не руководят. Они занимаются бэклогом, общением с клиентами, сбором аналитики так далее.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д
— Задача руководства это добиться чтобы описанных проблем между ПО и разработкой не было. Это культурная и профессиональная составляющая. Этому еще очень помогает то что главная команда ПО это команда разработки.
Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.
Ну вот же в карьерных возможностях пишите "можно стать техлидером" — это роль или позиция с бейджиком?
Роль
Ну и тим лид это роль. Вы можете автомобиль назвать кактусом, но он не станет кактусом. Соответственно, вы можуете поручить роль тим/тех лида разрабу, но они не перестанут быть задачами тимлида или техлида.
И да, в некоторых случаях необходим чувак с бейджиком. ПОтому что нужен в иерархии человек, который несет ответственность за бардак. Потому что не дело CTO или продукт оунера заниматься микроменеджментом кто просрал таски или что-то уронил.
И да, в некоторых случаях необходим чувак с бейджиком. ПОтому что нужен в иерархии человек, который несет ответственность за бардак. Потому что не дело CTO или продукт оунера заниматься микроменеджментом кто просрал таски или что-то уронил.
А самовольное занятие какой-то роли — это точно карьерный рост?
хороший разработчик может написать в три раза больше полезного кода, чем middle.— иногда наблюдаю и недостатки этой гипотезы, в частности что хороший разработчик начинает писать супероптимизированный и совершенно нечитаемый джуниорами код, в результате резко увеличиваются последующие затраты на обучение сотрудников и время на погружение в код для решения задачи
Но код-то хороший? После обучения читается?
код хороший ) бывают сценарии что он его написал и уволился или умер (все мы смертны) и тогда единственный источник экспертизы чтобы его разобрать будет гугл
А другого хорошего разработчика нанять, а не только джунов? Вообще проблема кажется организационная, когда хороший код некому без гугла разобрать. Когда брали хорошего разработчика за хорошие деньги, то предполагалось, что опустится до уровня джунов или подтянет их?
Sign up to leave a comment.
Как компании отказаться от роли тимлидов