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