Комментарии 14
С одной стороны все понятно, но с другой - это такой корпоративный кринж. Часто используется в плохих целях как "мотивация работать больше и лучше за меньшие деньги и в более плохих условиях, потому что у нас есть Цель и Миссия, и мы вообще Семья". Возможно моя позиция выглядит цинично, но уже 16 лет в этой индустрии и насмотрелся всякого...
Спасибо за комментарий.
Да, есть созвучность с корпоративной атрибутикой. Корпоративная культура может и должна влиять на команды, которые в этих компаниях работаю, а мотивы этого влияние – выбор топ-менеджеров.
Есть много примеров компаний, где миссия и цели помогают собрать прекрасные команды и мотивировать их на результат, предлагая хорошие условия труда и оплаты.
Примерно такое же чувство от прочтения. И мне кажется, что есть глобальная ошибка в определении причин и следствий. В моем опыте хорошие команды формировались за счет естественных человеческих процессов. И еще ни разу не видел успешных искусственно сформированных команд на которые накладывают церемонии.
Тема очень близка к обсуждению скрама. Хорошая команда сама того не зная делает скрам. А не очень удачная команда только мешает себе карго культом.
Если всё получается само собой – это прекрасно.
По опыту, Скрам требует много командных усилий и вовлеченности. Сами по себе гибкие методологии работают, когда вся команда так умеет и это определенный уровень зрелости каждого члена команды.
Не согласен с Вами по поводу "естесственности" Scrum-подхода, если это касается "не-стартапов". Для Scrum владелец продукта должен быть полностью в команде, а на моём опыте у большинства "не-стартапов" беда (пока не начинается реорганизация сверху)...
Внесу немного критики, не могу пройти мимо, так как статья очень понравилась и действительно было интересно читать до, цитирую:
Чуть позже производительность падает, а люди в команде начинают ругаться.
Не сумев припомнить, чтобы в какой-то из команд программистов, в которых работал, кто либо когда либо ругался между собой, решил присмотреться подробнее. Охват у меня меньше, думаю 5-6 команд для наблюдения, но правильно ли ровнять все возможные специализации коллективов под одну гребенку? Проще говоря - где больше ругани, в команде сапожников или инженеров? Это шутка, но посмотрим с другой стороны.
Вы отметили, что при подборе кандидата он должен соответствовать команде по духу и внутренним установкам, получается, что есть некоторое множество команд, отличными от конкретно Вас и вашей команды по этим критериям и они получается находятся в некоторой слепой зоне. Вы не могли попасть в эти коллективы, согласно этому же правилу, а я, возможно в наблюдаемое вами множество, так как присутствие ругани между разработчиками для вас считается нормальным. Здесь сильно обобщаю, так как скорее всего на упомянутых вебинарах вам попадались представители отовсюду. Хотел бы даже попасть на такой, но как видите, слишком подозрительный)
Если эта статья "пробник" такого вебинара, то по факту вы не подтверждаете заявление, что имеете конкретные методы и подходы, большинство утверждений заканчиваются противопоставлением с посылом "но вы же понимаете, это частный случай", как, например, цитирую, любой из вариантов может быть правильным.По вашему - это должно стимулировать посещение ваших вебинаров? Вот еще цитата:
Мне кажется, все люди делятся на два типа
Напомню, речь про разум и эмоции, здесь можно добавить интуицию, а это очень важное качество, хотя тоже можно вставить "мне кажется". Ну если продолжить, то и везение - немаловажное свойство лидера коллектива. А вот там где, как заставить поработать в выходные... ну тут не к тимлиду вопросы, а как вообще так получилось, как сделать так, чтобы не повторилось, опять же, сам за все время ни разу не работал в выходные, и не просили, везет может быть просто, интуиция или охват не полный в статье. Хотя почин хороший и графики тоже.
Отличный комментарий, спасибо.
«В сущности, все модели неправильны, но некоторые полезны». Действительно, я считаю, что нет готовых рецептов и серебреных пуль, при этом есть накопленный опыт и вполне удачные попытки систематизировать типовые процессы и ситуации.
То, что вы прочитали и порефлексировали – уже большой успех этой статьи.
Работая тимлидом в текущий момент, не могу не согласиться с большинством пунктов статьи, но хочу от себя дополнить несколькими тезисами, которые для себя сам вывел:
нельзя ставить себя выше команды - тимлид без команды никто, а вот команда без тимлида вполне может существовать; фактически, тимлид подчиняется команде в некоторых смыслах, да, он по-прежнему несет за нее ответственность, но действовать он должен на балансе интересов команды и бизнеса, а не на основе интересов бизнеса и своих собственных
самый удачный вариант тимлида - выбранный командой, поскольку это будет означать, что доверие команды нужно только оправдывать, но не строить его с нуля, как в случае с приглашенным со стороны тимлидом; плюс, тимлид, выбранный из уже существующих участников коллектива, априори более погружен в проблемы продукта, и может принять более взвешенное решение
last, but not least - хорошего тимлида не должно быть видно, как и хорошего сисадмина (в старых терминах); задача тимлида - настроить все так, как удобно команде и бизнесу, а далее лишь держать руку на пульсе, а команда в случае вопросов обратится сама, поскольку доверяет экспертизе и взвешенности решений выбранного тимлида (как вариант, в освободившееся время можно заниматься разработкой или чем-то другим, в зависимости от хард скилов самого тимлида)
Все вышеперечисленное - мое личное мнение, не пытаюсь никому его навязывать :)
Всем хороших команд и тимлидов)
Что касается управления командой, рискну процитировать фразу из мемуаров офицера WW1. Сам читал давно, поэтому не дословно — но (надеюсь) дух соблюден: «Право отдавать приказы не приходит с присвоением звания. Никто в здравом уме не поднимется из окопа под пули ради незнакомого человека. Вы должны есть со своими бойцами, спать с ними — в общем, делить все радости окопной жизни. И когда вы убедите их, что требуете только того, на что вы готовы решиться сами — эти люди пойдут с вами в ад, и обратно! И столько раз — сколько потребуется...».
Примерно эту же мысль можно найти у Хайнлайна в «Космической пехоте»: начиная со слов «Я знаю, что в некоторых подразделениях капелланы не воюют, и я не понимаю как же они в таком случае там живут...», и далее по тексту.
Вы правы, умение писать хороший код – очень ценный навык, даже ключевой. Поэтому всегда фокус на этом и можно забыть про цели, ценности и эмоциональный интеллект.
Умение давать конструктивную критику и обратную связь на код-ревью – еще более ценный навык. Я видел, как резкая критика кода "звезд" выжигала мидлов и вредила команде, поэтому хочется говорить об этом и делать на этом акценты.
Товарищей склонных к спонтанному насилию лучше всего лечить, или хотя бы увольнять.
Но с другой стороны — все зависит опять же от организации. В армии, как мы знаем — матом не ругаются а разговаривают. А в других местах за откровенный косяк с тяжкими последствиями даже морду набить могут — и после этого люди продолжают работать…
Это круто быть лидером в комманде где ты не самый умный. Но немного боязно как мне кажеться.
Как управлять командой разработки