Недавно мы приняли новую методологию управления, которая гласит, что в команде нет ролей («многофункциональная» команда, где «все члены команды являются разработчиками»), и каждый должен делать все, поэтому теперь у нас есть дизайнеры UX и инженеры по контролю качества, которые пытаются отправляйте код с копипастом и онлайн-курсами.
Я никогда раньше не был менеджером, и я не являюсь менеджером этих людей, но так как у нас половина команды внезапно становится разработчиками и единственным настоящим разработчиком программного обеспечения (извините за уничижительное, но никто из этих людей раньше не писал код), не просто игнорируя сообщения новичка, я ничего не делаю.
Не помогает то, что у каждого разработчика есть определенное количество баллов, необходимое для каждого спринта, и нет никакой разницы между людьми в зависимости от опыта. Разработчики-новички действительно не должны иметь того же ожидания, что и люди, которые программировали годами.
Я обратился к своему менеджеру, но метод управления проектом был продиктован сверху. Менеджер тоже разработчик и не очень хочет этим заниматься. Его менеджер находит методологию странной, но не хочет идти против людей с сертификатами. По сути, я не думаю, что это действительно можно сильно изменить, поэтому мне нужно научиться работать в рамках.
Каковы мои варианты решения этой проблемы? Как вы управляете армией действительно зеленых людей и получаете от них полезный код?
Идея о том, что «все являются разработчиками» и «все пишут код», не одно и то же. В этом смысле «разработчик» означает не «программист», а «человека или вещь, которая что-то разрабатывает». UX-дизайнеры, программисты, тестировщики, бизнес-аналитики и другие участвуют в разработке продукта.
Иногда идея о том, что «все являются разработчиками», может быть полезна для формирования культуры равенства всех. Что-то, что я видел раньше, это программисты, которые думают, что они лучше, чем тестировщики, или которые не будут сопротивляться UX-дизайнеру в отношении дизайнерских решений. Думая о каждом как о разработчике, вы можете поставить всех в положение равноправных сотрудников.
Нет причин заставлять всех писать код. Вместо этого каждый должен внести свой вклад, используя свои навыки. Могут быть способы перекрестного обучения. Возможно, UX-дизайнеры могут освоить навыки фронтенд-программирования, чтобы получить более глубокое понимание реализации своих проектов. Тестировщики могут изучить программирование, чтобы получить более глубокие навыки тестирования методом белого ящика или автоматизации тестирования. Точно так же программисты могут освоить эти навыки, чтобы снять часть нагрузки с этих ролей и разделить общую рабочую нагрузку.
Проблема в том, что всем нужно набрать одинаковое количество «очков», вероятно, усугубляет ситуацию. Как правило, оценка такой работы выполняется на командном уровне. Команда, как единое целое, планирует и выполняет работу. Каждый использует все свои навыки, чтобы помочь команде завершить работу и предоставить высококачественные продукты и услуги.
Я не верю, что это то, с чем можно работать внутри, по крайней мере, эффективно. Что-то должно измениться, иначе у вас будут люди, выполняющие работу, для которой они не являются квалифицированными или квалифицированными, во имя «получения баллов», а не для того, чтобы поделиться своими знаниями и опытом с целями команды.
в команде нет ролей («кросс-функциональная» команда, где «все члены команды — разработчики»)
Одна вещь, которую я хочу отметить, это то, что именно означает кросс-функциональность :
это не команда, где каждый член может делать все. Скорее, это команда, которая способна на все.
В первую очередь я бы предложил подтвердить, что именно высшее руководство имело в виду под «кросс-функциональным». Возможно, высшее руководство просто сказало: «Сделайте команды кросс-функциональными!» а руководство среднего звена неверно истолковало это как «заставить всех делать все!» и все это огромное недоразумение.
Не помогает то, что у каждого разработчика есть определенное количество баллов, необходимое для каждого спринта, и нет никакой разницы между людьми в зависимости от опыта.
У меня есть два слова для вас.
Чтобы быть хорошими, оценки должны быть основаны на реальности. Упорядочено в терминах «наилучшее, но наименее вероятное, что будет разрешено» и «наихудшее, но наиболее вероятное»:
Обычно оценки делаются командой даже в несамоуправляемых командах. Нереалистичная оценка, навязанная кем-то, не знакомым с произведением, не стоит битов, используемых для ее хранения, и с ней следует обращаться соответствующим образом.
Кроме того, руководство должно осознавать последствия принимаемых решений. Прозрачность является ключевым моментом: руководство, принимающее неверные решения, имея все факты, является некомпетентностью, но принятие неверных решений из-за того, что они не знают, что происходит, является трагедией, которой можно избежать.
Аналогия: «Каждый, кто знает, как занять дом или кто интересуется тем, как выглядит его дом, знает, как его построить, и, следовательно, знает, как каким-то значимым образом внести свой вклад в то, как такая вещь должна работать». быть построенным».
Мой опыт: я не претендую на знание. Пожалуйста, не дарите мне подарочную карту Home Depot на Рождество. Я предпочитаю нанимать профессиональных, лицензированных подрядчиков. Они дают мне стопки визитных карточек, и я послушно и с радостью раздаю их.
Лучшая рекомендация: «Этот корабль тонет. Направляйтесь к спасательным шлюпкам».
Для меня это пахнет очень плохим непониманием Scrum. Намерение никогда не заключалось в том, чтобы сделать всех одинаковыми, чтобы они имели одинаковый набор навыков и выполняли одни и те же задачи, как если бы люди с разным опытом были взаимозаменяемы. Вы могли бы искать некоторую ясность в том, что подразумевается под этими директивами. Если члены команды хотят пройти перекрестное обучение, чтобы понять работу друг друга, это полезно, но если вы не наняли бы кого-то для выполнения работы разработчика с нулевым опытом в этой работе, то не ожидайте, что другой сотрудник с другим набором навыков будет лучше в другой роли. Идея о том, что каждый сотрудник должен набрать некую квоту «баллов», — чепуха. Если это действительно то направление, которое вы получили, то вам, возможно, придется отказаться от определения «точки»,
Богдан