Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают
Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов
Эту работу как раз и организует лид, постоянно создавая команде проблемы. Если конечно в ней не джуны, ничего не понимающие, и не видевшие.
Все бы так, да в скраме так не забалуешь, там быстро все выводится на чистую воду), потому как в скраме открытые обсужения и абсолютная прозрачность, что лидам вообще не в масть (которым надо постоянно позиционировать свое менторство, и не дай бог в команде кто то появится, более сведующий, которой постоянно «дискредитирует лида» своими предложениями, и по-тихому убирается из проекта). Лид не нужен совсем, нет в скраме такой роли. Вот и в таких статьях и постоянно выдумывают чем же заниматься лидам. А аналогия не в тему и не логична, можно все что угодно приплесть и машину и ракету и холодильник и т.п.
Тимлид держится за место на проекте, но не за сам проект, он скорее завалит проект, чем согласится перейти на скрам, и ликвидировать эту роль.
Скрам
1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
менятся как дежурный.
2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
возникновения, а планируются на следующие спринты). При серьезном подходе можно
рассчитать выход продукта и обновлений.
4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
(loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
сущностей. Выявлятся и устраняются причины багов.
7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
находит таск и перечитывает контекст задачи.
8) Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
переход на другой проект или время на обучение.
Тимлид
1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
принимает в разработке активное участие.
2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
(друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
внезапно, может быть несколько активных спринтов, команда не принимает участия в
формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
поддается прогнозированию.
4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
проблемы никого не интересуют.
5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
и тесно взаимосвязано. (tightly coupled).
6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
и затрат времени на это.
7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
8) Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
задачи появляются неожиданно.
9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
без работы.
О это обширная тема, я наверно буду на пенсии писать про это мемуары, начиная о том как «тимлиды» предлагали писать в коде сервера компоненты для фронтенда, и заканчивая тезисами о монолитной разработке вместо модульной (loosely coupled), плюс всякие пулл реквесты висящие днями на рассмотрении в то время как дедлайн и проект горит. А также как предлагая лучшие практики, получаешь ответы лида типа «у нас это не принято». Или о приватных звонках «тимлидов», с просьбами срочно прекратить разработку и тестирование продукта, вместо того чтобы обсудить все в общем чате со всей командой. И о проектах, которые поднимались из руин за полгода-год, которые факапились около трех лет «опытным тимлидом» с командой разработчиков. Ладно если бы это была случайность и один проект, но это разные проекты, и повсеместно особенно на фрилансе.
Фундаментальное различие в том, что в скрам-мастер фокусирует команду на результате (скрам — это жестко прописанные роли, правила и артефакты), тогда как тимлид сам распыляется и не может сфокусировать и четко объяснить свою деятельность, не говоря уже о команде (даже в интернете все пытаются по разному формализавать, и изобретать чем же он занимается).
кто-то играет в скрам без скрам-мастера, в этом проблема, а тимлиды это архаизм, но для небольших проектов годится, немного знает методики управления, немного программирует, способен немного натаскать джунов, но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать
да статистика такая такая есть..., проекты просто факапятся, потому что тимлиды, становятся таковыми на проекте, просто потому, что они первые попадают на проект, и отбор остальных участников команды, идет уже не выше его компетенции, а так как тимлид держит и админские права на проекте гита или таск менеджера, то там даже овнеры сделать ничего не могут и дальше раскручиваются на деньги, пока не выдерживают и не разгоняют всех. Тимлид — ставит галочку в портфолио, что он «качественно там поработал», а проект затянулся и завалился, потому что команда плохая попалась, причем все специалисты сразу. Вот такая правда жизни. Не надо портить перспективного спеца(мидла или сеньера) и наделять его управленческими функциями.
Если за что-то платят — это ещё не значит что оно столько стоит.
Это да, если это частный случай, но не может статистика ошибаться по всем скрам мастерам.
Хочется идти в управление проектами, завязывай с программированием (не мешай другим), обучайся методикам эффективного управления (по мне так это еще сложнее чем программировать), и становись проффеcсионалом в своем деле. Но не надо и программировать, и управлять, и тестировать и админить и кадры искать, хотя для домашнего хоумпейжда, можно все это совмещать и быть «тимлидом».
Если вы что то не видели, это не значит что этого нет. Скрам-мастер входил еще 2017 году в топ самых высокооплачиваемых специалистов в штатах www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha. Для того он и нужен, чтобы заказчик не тратил зря средства, а команда сфокусировалась на результате, и не деградировала и не затачивалась под знания тимлида (который зачастую технически не превосходит, других специалистов в команде), хороший скрам-мастер всегда может объяснить зачем он нужен. Сложность задач не нужно субъективно оценивать ака «тимлидом» (странным мидлом), для этого существует более точные техники типа scrum poker (и совокупное мнение участников команды).
Тимлид — это заблуждающийся мидл, у которого наконец-то, что то начало получатся в программировании, и он решил почему то управлять командой, тестированием, дизайном, кадровыми вопросами и т.п, а пм это допускает, в силу своей некомпетентности. Проектами должны управлять специально обученные люди, пм-ы или скрам-мастера.
ну тут как-бы все, дискуссия вышла за рамки здравого смысла, что то какой-то неадекват полез, приведенный Вами случай не этикет, а клиника, которая тоже документируется врачами.
Ну ну, весь мир работает по договорам и документам, а вы по неким правилам этикета ))))
Был в Англии, зашел в казино. Вижу сидят мужики и в покер играют. Я к ним подсел, играем по малой, и тут один мужик говорит: «У меня очко». Я ему: «Покажи! », а он мне говорит: «У нас здесь все джентльмены, все друг другу на слово верят… ». И тут у меня такая карта поперла!..
Это не серьезно, захотел — сделал, захотел — не сделал, захотел — уведомил, захотел — не уведомил, есть настроение — нету, — это не трудоустройство, а детский сад, правила этикета какие-то непонятные, которые каждая сторона понимает по своему.
да, я согласен на это, потому что уверен в том, что я делаю, а чего боитесь вы? Я всегда готов признать, что я не подошел компании по объективным причинам (например, не подошли или не хватило скилов), и наоборот также всегда готов обосновать неадекватность дающего тестовое задание — если это так. Любую запись в трудовой или в портфолио объективно объяснить всегда можно.
у меня было тестовое задание, сделать типа прототип приложения, добавление и управление новостями, я его сделал, за неделю, мне отказали, с ответом, типа другого взяли, я очень удивился, а потом подумал что может быть это вообще развод был, типа программист не знал как начать приложение грамотно, а тут ему кинули прототип бесплатно, он провел рекрутинг, его научили, он отчитался начальству, что никто не подошел, и теперь сам может сделать. Я за тестовое задание — трудовые отношения однозначно. И то что юристы и государство взялись за эту отрасль — это очень хорошо.
Ну в гайде описаны оптимистические сценарии. А в жизни команда может бесконечно проводить ретроспективы и улучшать свои условия работы за счет заказчика. И не продвигатся в выполнении проекта.
Помоему на практике главная цель ретроспективы, выявить отклонения в разработке проекта, и запаздывания, а улучшение работы команды это дело второе. Если через пару-тройку спринтов выявляется хроническое невыполнение задач, или ничего толком до конца не доделывается (некачественно, с багами, вроде много сделано но ничего толком), то нужно принимать кардинальные меры вплоть до отказа от проекта или замены участников команды. Очень много командных фейловых стартапов, которые тянутся очень долго, люди вангуют, расходуются огромные средства, и в конце концов все лопается. И причем это должны выявлять скрам мастера как можно скорее.
Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
Эту работу как раз и организует лид, постоянно создавая команде проблемы. Если конечно в ней не джуны, ничего не понимающие, и не видевшие.
Все бы так, да в скраме так не забалуешь, там быстро все выводится на чистую воду), потому как в скраме открытые обсужения и абсолютная прозрачность, что лидам вообще не в масть (которым надо постоянно позиционировать свое менторство, и не дай бог в команде кто то появится, более сведующий, которой постоянно «дискредитирует лида» своими предложениями, и по-тихому убирается из проекта). Лид не нужен совсем, нет в скраме такой роли. Вот и в таких статьях и постоянно выдумывают чем же заниматься лидам. А аналогия не в тему и не логична, можно все что угодно приплесть и машину и ракету и холодильник и т.п.
Тимлид держится за место на проекте, но не за сам проект, он скорее завалит проект, чем согласится перейти на скрам, и ликвидировать эту роль.
Скрам
1) Управление: разработка регулируется общепринятыми(в мире) правилами скрама, за которыми
четко следит скрам-мастер. Сам он может не участвовать в разработке. Или скрам мастер может
менятся как дежурный.
2) Селекция: по профессиональным качествам. На проекте здоровая конкуренция.
3) Планирование: планирование выполняется совместно всей командой (планирование спринтов,
спринты одинаковой продолжительности чтобы анализировать велосити команды и устойчивое
развитие продукта, всегда один активный спринт, новые задачи не втыкаются по мере
возникновения, а планируются на следующие спринты). При серьезном подходе можно
рассчитать выход продукта и обновлений.
4) Факапы: в случае факапа, идет детальный разбор ошибок и реальное выяснение проблемы,
предложения по улучшению (рефакторинг, декомпозиция) закладываются в следующие спринты.
5) Скорость разработки и кодовая база. Скорость разработки и кодовая база ограничена
совокупной квалификацией команды. Проект поделен на зоны ответсвенности. Каждый
разработчик отвечает за свой участок, в коде проекта обязательно четкая модульная архитектура
(loosely coupled). Практикуются перекрестные пулл реквесты для улучшения кода.
6) Поддержка: приветвуется рефакторинг, упрощение, разделение и инкапсулирование
сущностей. Выявлятся и устраняются причины багов.
7) Багофиксы: Баг забирает тот кто реализовывал задачу, вспоминает задачу или если надо быстро
находит таск и перечитывает контекст задачи.
8) Атмосфера: спокойная и продуктивная, задачи планируются заранее. В спринте есть время
сделать все качестаенно, подумать, поисследовать проблемы, переделать/улучшить по желанию.
9) Разработчик примерно понимает сроки окончания проекта и может планировать отпуск,
переход на другой проект или время на обучение.
1) Управление: Разработкой управляет тимлид. Правила придумываются им. Обязательно
принимает в разработке активное участие.
2) Селекция: Лидом становится тот, кто первый зашел на проект или сам руководитель проекта
(друг-брат-сын). Конкуренцию в команде выигрывает тот кто безоговорочно поддерживает лида.
3) Планирование: Планирует спринты тимлид, спринтов может не быть, спринты могут быть
разной продолжительности, задачи могут появится внезапно в спринте, спринт может появится
внезапно, может быть несколько активных спринтов, команда не принимает участия в
формировании спинта, просто ставится перед фактом. Дата выхода продукта и обновлений не
поддается прогнозированию.
4) Факапы: в случае факапа выбирается жертва, ничего не решавшая до этого. Например,
выкатили жертве срочные баги перед релизом по чужому коду, не выпутался, не орел, причины
проблемы никого не интересуют.
5) Скорость разработки и кодовая база: скорость разработки и кодовая база ограничена
квалификацией тимлида. Все что тимлид не понимает отвергается или не принимается пока он это
не поймет. Зон ответвености нет, всем внушается что каждый ответственен за весь проект, хотя по
факту никто ничего ни решает, практикуются обязательные пулл реквесты для всей команды,
кроме лида, которые он жестко контролирует. Модульность кода часто отсутствует, все смешано,
и тесно взаимосвязано. (tightly coupled).
6) Поддержка: приветсвуются быстрые костыльные решения без истинного выяснения проблемы
и затрат времени на это.
7) Багофиксы: баги раздаются случайным образом, код фиксится и модифицируется часто не тем
кто его писал, постоянно тратится время на его изучение, дебаг и фикс без контекста задачи.
8) Атмосфера: гнетущая и нервозная. Работа идет в постоянном состоянии дедлайна. Срочные
задачи появляются неожиданно.
9) Работе нет конца и края или она может прекратится внезапно. Разработчик или без отпуска или
без работы.
Знакомые ситуации?
Это да, если это частный случай, но не может статистика ошибаться по всем скрам мастерам.
Хочется идти в управление проектами, завязывай с программированием (не мешай другим), обучайся методикам эффективного управления (по мне так это еще сложнее чем программировать), и становись проффеcсионалом в своем деле. Но не надо и программировать, и управлять, и тестировать и админить и кадры искать, хотя для домашнего хоумпейжда, можно все это совмещать и быть «тимлидом».
medium.com/@analysisparadisis/обзор-книги-scrum-джеффа-сазерленда-38f64706bdfb