Комментарии 36
И мы наоборот старались распределять задачи таким образом, чтобы не образовывалось экспертов в какой-то области.
В команде нет разделения на специализации, роли и кого-либо кроме разработчиков.
И тут же:
В задачи руководителя команды входит
Т.е. разделения нет, но оно есть.
Но это так, из серии забавных мелочей. По факту же текст можно ужать до следующего — "я полтора года работал с какими-то людьми, разрабатывающими что-то на чём-то, и мне понравилось". А что конкретно вы за это время сделали-то? :) И чисто ради интереса можно было бы попросить оценить трудозатраты на работы по такому же ТЗ некоторому количеству "классических" ПМ-ов. Ну, чтобы было с чем сравнивать эффективность, а то вдруг человечество не зря придумало разделение труда и специализацию.
А что конкретно вы за это время сделали-то? :)
Настроил процессы в команде, чтобы именно так как в статье описано все работало. Следил чтобы процессы не останавливались, люди теряют мотивацию, интерес, это в любом случае.
Т.е. разделения нет, но оно есть.
Это не совсем разделение, это полномочия, которые выходят за рамки команды. Например, уволить кого-то или обсудить зарплату — такое не решается на коллективном митинге.
И чисто ради интереса можно было бы попросить оценить трудозатраты на работы по такому же ТЗ некоторому количеству «классических» ПМ-ов. Ну, чтобы было с чем сравнивать эффективность, а то вдруг человечество не зря придумало разделение труда и специализацию.
Я работаю в продуктовой компании, в команде где нужно и исследовать самому, и работать с командой по машинному обучению, которые тоже в свою очередь исследуют и экспериментируют. Так что в моем случае, не получилось бы. Вот если бы продукт был другим, действительно пилить фичи, можно было бы попробовать. Я на своих ощущениях считаю, что самоорганизующиеся команда лучше, из опыта в в ряде компаний, с абсолютно разными процессами, ролями, менеджментом.
Настроил процессы в команде, чтобы именно так как в статье описано все работало.
Я имел в виду некий измеримый результат работы команды в целом, не ваш лично. Просто в мире достаточно много людей, где-то работающих, но при этом не дающих никакого реального результата. И в таком случае нет никакой разницы, как оно там внутри организовано.
Я работаю в продуктовой компании, в команде где нужно и исследовать самому, и работать с командой по машинному обучению, которые тоже в свою очередь исследуют и экспериментируют. Так что в моем случае, не получилось бы.
Ага, уже понятнее… Если по сути у вас исследовательская работа, а не разработка в классическом понимании, это довольно сильно меняет контекст.
Ага, уже понятнее… Если по сути у вас исследовательская работа, а не разработка в классическом понимании, это довольно сильно меняет контекст.
Ну, мы кодим, и много проектов, разных, на разных языках и технологиях, и они крутятся в продакшине, и этим пользуются. Это, мне кажется, даже сложнее, нежели пилить один понятный продукт. Я оправдывался этим в плане что измерить ПМ-у это не получится легко.
Ну, мы кодим, и много проектов, разных, на разных языках и технологиях, и они крутятся в продакшине, и этим пользуются.
Самое офигенное измерение проекта, что я видел. Зарплату вам тоже "ну платят" и "ну хватает" или какая-то твёрдая сумма?
У нас в компании есть митинги где топ-менеджмент рассказывает о цифрах: клиентах, доходах, расходах, и прочее. И есть фидбек от клиентов (B2B продукт).
Я об этом не упоминал и в статье тоже, не посчитал нужным/возможным.
обсудить зарплату — такое не решается на коллективном митинге
Кстати было бы интересно, а еще интересней, когда сами сотрудники решают поднять себе ЗП или уволить себя.
Hold on, don’t quit. In almost all other organizations you will meet the same idiots, but with different names. They are not evil people, they are just incompetent. They never studied project management, they don’t have any professional education, they only read books like Reinventing Organizations and listen to lectures on leadership and multiculturalism.
Нет разделения на роли, де факто, вырождается в то, что никто ни за что не отвечает (это гипербола, но, тем не менее).
Самоогранизация внедрялась в Sun и Xyratex — миллиардные международные корпорации с собственными производствами. Ни той, ни другой ныне нет. (Первую съела Oracle, вторую Seagate.) Была ли этому единственной причиной эта мода — скорее всего нет, но одной из них — вполне вероятно.
Не было 1-to-1 митингов, хотелось иметь мгновенную обратную связь. О том, что кому-то что-то не нравится или нравится — было правило сообщать сразу
Эм, вы правда думаете, что 121 делается только потому, что в организации запрещают сообщать сразу что кому-то что-то не нравится? А не потому, что частенько если тебе начинают жаловаться открыто — чинить проблему уже гораздо сложнее, а то и просто потерял человека.
Каждый разработчик участвует в каждой итерации цикла разработки программного обеспечения: получение задачи, прояснение требований, написание кода, тестирование, развертывание, мониторинг, поддержка.
Как вы видите работу 50 таких команд над единым продуктом?
Непривычно для менеджмента и бизнес-людей — они привыкли к общению по задачам и прогрессу только с руководителем команды.
А с кем они сейчас общаются когда им нужно пообщаться по эпику делают который 90% разработчиков?
Эм, вы правда думаете, что 121 делается только потому, что в организации запрещают сообщать сразу что кому-то что-то не нравится? А не потому, что частенько если тебе начинают жаловаться открыто — чинить проблему уже гораздо сложнее, а то и просто потерял человека.
Я старался выстроить процесс открытости и раннего фидбека. Если тебе жалуются, и уже поздно — человек хочет уйти, потеряли ресурсы, потеряли нервы, — стоит задуматься над компетенциями тех, кто поздно сказал. Значит, либо им все равно, либо безответственные, либо что угодно. У меня была возможность протестировать это, я много раз говорил «почему не сказал раньше, я же говорил», в итоге это работает — легко протестировать, назначаешь отдельный митинг, спрашиваешь фидбек, если тебе рассказывают что-то, что должны были рассказывать — напоминаешь о процессах, раннем фидбеке.
Как вы видите работу 50 таких команд над единым продуктом?
Это все моей компетенции сейчас, мой максимум — две команды, которые надо интегрировать между друг другом и наладить разработку, но не 50.
А с кем они сейчас общаются когда им нужно пообщаться по эпику делают который 90% разработчиков?
Мне надо понять что именно значит «пообщаться». Эпик, если мы на одной волне, это список задач, связанных одной тематикой (или частью проекта, в таком духе). У нас в компании, так как она продуктовая, и не только, задачи так не ставятся нашей команде, ставится типа — «Плохо работает нахождение похожих объявлений недвижимости», а мы уже сами за все отвечаем (подзадачи, их приоритеты). Бизнес не приходит и не спрашивает за что-то конкретное, могут спросить насколько новое решение эффективнее, либо нет ли блокеров, когда ориентировочно можно ждать.
Я старался выстроить процесс открытости и раннего фидбека. Если тебе жалуются, и уже поздно — человек хочет уйти, потеряли ресурсы, потеряли нервы, — стоит задуматься над компетенциями тех, кто поздно сказал.
Вы компетенции разработчиков меряете их личностными особенностями?
если тебе рассказывают что-то, что должны были рассказывать — напоминаешь о процессах, раннем фидбеке
Вам нравится загонять людей в зону некомфорта? Раз они рассказывают на встрече, но не приходят сами — наверное им так комфортнее?
Бизнес не приходит и не спрашивает за что-то конкретное, могут спросить насколько новое решение эффективнее, либо нет ли блокеров, когда ориентировочно можно ждать.
Так кого он спрашивает, если над решением работает вся команда?
Вы компетенции разработчиков меряете их личностными особенностями?
В моем понимании, seniority так и выражается — если что-то не нравится, и ты сказал/предложил/решил, если что-то не работает, и ты сказал/предложил/решил, а не наоборот — забил до момента пока спросят.
Вам нравится загонять людей в зону некомфорта? Раз они рассказывают на встрече, но не приходят сами — наверное им так комфортнее?
Изначально, мы договариваемся о всех процессах. Если они приняты в команде, значит, либо всем нравятся, либо нравится большинству, либо так просто правильно в определенной ситуации. И если мы приняли правила, значит, мы считаем их эффективным. Если это некомфортно для человека, значит, это команда ему не подходит. Нормально, когда не подходит, и, конечно, в любой адекватной команде/компании пытаются сделать лучше, что-то поменять или перенастроить. Но не всегда же идти на уступки, так будет бардак.
Так кого он спрашивает, если над решением работает вся команда?
В специальный корпоративный чат, тегая всех (в Слаке — here, например) либо отдельно кого-угодно. Вся команда его читает, и ответственный за задачу, либо тот кто в курсе ситуации по задаче, отвечает.
В моем понимании, seniority так и выражается — если что-то не нравится, и ты сказал/предложил/решил, если что-то не работает, и ты сказал/предложил/решил, а не наоборот — забил до момента пока спросят.
Вы точно не путаете решение рабочих задач и именно личные проблемы какие-то? Например, какие-то субъективные несовместимости с коллегой, раздражающая манера продукта?
Изначально, мы договариваемся о всех процессах.
В смысле "изначально"? Пришел новый человек, его поставили перед фактом. Не может человек, как ему что-то не нравится — бежать сразу с жалобой, ну ок, не вписываешься. Не, ну вариант, конечно, вполне себе… если разработчики толпой валят (обычно это не так).
У меня такое ощущение, что вы выросли в этой команде, уже сработавшейся и стабильной. Там можно много что себе позволить ибо не нужно слаживать команду — это уже сделалось само или кем-то до вас.
В специальный корпоративный чат, тегая всех
Круто, вместо одного человека отвлекли 5… или 10 если команд две.
Вы точно не путаете решение рабочих задач и именно личные проблемы какие-то? Например, какие-то субъективные несовместимости с коллегой, раздражающая манера продукта?
Если человеку по личным проблемам некомфортно, это надо постараться решить. Я чуток потерял нить разговора.
В команде был человек, на процессы забивал, его не драйвило, что мы делаем, на обед вместе не ходил, не ходил «на перекур» — не то, что интроверт, но просто остальные члены команды были «не его людьми», мы всячески пытались его привлечь. Ребятам было плохо с ним работать, в итоге его уволили. И это нормально, считай что как будто корпоративная культура, только командная.
В смысле «изначально»? Пришел новый человек, его поставили перед фактом. Не может человек, как ему что-то не нравится — бежать сразу с жалобой, ну ок, не вписываешься. Не, ну вариант, конечно, вполне себе… если разработчики толпой валят (обычно это не так).
У каждого в нашей команде есть возможность изменить любой процесс, неоднократно так делали, отказывались от каких-то практик.
В смысле «изначально»? У меня такое ощущение, что вы выросли в этой команде, уже сработавшейся и стабильной. Там можно много что себе позволить ибо не нужно слаживать команду — это уже сделалось само или кем-то до вас.
Когда я пришел в команду, был один человек, потом в коротком промежутке пришло еще два — я их не нанимал (компания — в Португалии, двоих, включая меня, релоцировали, один перешел из другой команды, так как там ему стало скучно), нанимал СТО. Начали делать свои задач, попутно настраивая практики, выбирая технологии, и так дальше.
В команде был человек, на процессы забивал, его не драйвило, что мы делаем, на обед вместе не ходил, не ходил «на перекур» — не то, что интроверт, но просто остальные члены команды были «не его людьми», мы всячески пытались его привлечь. Ребятам было плохо с ним работать, в итоге его уволили. И это нормально, считай что как будто корпоративная культура, только командная.
Тут не о том, что такие люди бывают или нет, а о том, что таким человеком может стать и вполне себе старый хороший игрок. И задача руководителя 1) увидеть проблему раньше остальных на зачаточной стадии, когда ее можно еще решить, 2) попытаться решить, 3) принять жесткие меры вплоть до увольнения еще до того, как такой человек начнет быть токсичным для команды. если не решается проблема. В идеале — команда должна лишь ощутить легкий ветер этой проблемы и не более того.
И, внезапно, все это — детектирование проблемы и попытка ее решить — есть задача 121. Ибо "со стороны" ты проблему увидишь именно тогда, когда ее увидит вся команда… а это уже поздно.
Это все подходит для маленьких команд где накладные коммуникационные расходы ничтожны, а задачи ненастолько сложны и срочны, чтобы их мог решать средненький фуллстек. По факту, с развитием команды есть риск получить кучу интровертов, каждый из которых сидит на своей груде кода и тогда вам предстоит узнать, что есть bus factor.
о факту, с развитием команды есть риск получить кучу интровертов, каждый из которых сидит на своей груде кода и тогда вам предстоит узнать, что есть bus factor.
Развитие, имеется ввиду, рост, типа не 5 человек, а, например, 15? Я не понимаю почему. Как мне кажется, наоборот, самоорганизующиеся команда предотвращает это, опыта в такой «большой» команде у меня не было. Возможно, это не масштабируется.
ну это) минусом подхода я бы назвал наверное размытие зоны ответственности, если разработчики решают каким будет дизайн) то оно для руководителя удобно, мол команда сама порешает. это сейчас тихий тренд)
Команда сама выбирает технологии
Как конкретно это работает?
К примеру команда поделилась 50/50 в своем выборе и это еще не самый худший вариант.
Кто ставит точку в выборе? На основе чего, и почему остальные должны радостно это принять?
- насколько большой проект,
- как быстро нам надо его сделать,
- хочется ли разнообразия в работе,
- смогут ли его поддерживать в будущем (интерес к языку у коммьюнити, количество специалистов, популярность языка).
Например, мы никуда не спешим, проект на пару запросов, люди устали писать на Python полтора года, давайте на Ruby что-то напишем.
А вот если язык просто не подходит для задачи, Go, для такого же проекта с запросами и базами, то мы не будем его выбирать.
Он изначально на собеседовании будет знать куда идет, о наших процессах и организации работы. Если ему это неинтересно, мне в первую очередь нужно будет это выяснить.
Привет! Мне интересно, а что значит в данном случае составление бэклога и приоритезация? Все ребята предлагают фичи? А как определяли, что же все-таки будем делать, а что нет, и в каком порядке — на основе командной договоренности, или как-то считали деньги/ценность?
Тема мне кажется огонь. У вас в сверх-концентрированной форме раскрылась тема самоорганизации и кроссфункциональности))
Как я уже писал выше в комментариях, у нас по-другому ставятся задачи в компании. Менеджер не приходит с нарезанными тасками и не асайнит людей на них как утилизация ресурсов. Приходит продакт и говорит — «Плохо работает нахождение похожих объявлений недвижимости». Остальное за нами — если проект не похож на остальные, кто-то занимается ресерчем, потом пишет документ, на основе документа обсуждение на митинге где мы формируем пулл задач и выставляем приоритеты. Потом любой человек просто накидает задачи в бэклог и любой человек может взять любую задачу (так и поменять приоритет или изменить ее, или удалить, если это обсудилось).
По описанию у вас была проблема со скоростью разработки и вместо того чтобы отладить процесс коммуникации вам захотелось чтобы каждый был на дуде игрец.
От этого обычно страдает качество и люди выгорают когда им приходится заниматься непрофильными задачами. Интровертов вы заставляете общаться с заказчиком, а экстравертов настривать инфраструктуру — ну ок.
Пользы в статье ноль: нет измеримого результата, мир построен вокруг непонятных розовых пони. Как опыт для начинающего тимлида — может быть и то сомнительно, а как результат всё это скатится в унылое, но тёплое болото. Людей с подобным опытом никто в здравом уме нанимать не будет.
С минусами отмеченными все тоже так и есть, это одна из причин по которой в Agile один из 12 принципов вообще прямо говорит «стройте проекты вокруг заинтересованных людей». Я, кстати, много общался с «трансформаторами», практически единодушное мнение — при переходе от классической command & control модели к agile или DevOps от 30 до 50% штатного состава в итоге меняется. Т.е. «некомфортность» от лишней ответственности и вынужденного кругозора не так уж необычна.
Мой опыт в самоорганизующейся команде