Комментарии 56
Признайте: каждый Tech Lead мечтает о кросс-функциональности внутри своей команды.
Признаюсь: нет. По опыту — любой «универсал» хуже любого «узкого спеца». Наелся, сорри.
PS: да, пост читал.
Но то, что за это меньше платят — неправда. В каких-то местах за это действительно платят. Но задачи от этого интереснее не становятся, и поэтому руки опускаются вообще что-либо делать с душой.
Это определение отражает третий тип личности универсала, описанный в статье, но Вы отчасти правы — в условиях ограниченности ресурсов может трактоваться именно так, но в этом нет ничего предосудительного.
Как раз в статье я попыталась показать сильные и слабые стороны каждого типа, зная которые можно найти подход по эффективному совмещению ролей и выстраиванию процесса работы с человеком.
Универсал — это человек имеющий свою основную узкую специализацию и приобретённые дополнительные специализации в процессе своего опыта работы в компании.
И вовсе не обязательно, что работа универсала будет выполнена плохо.
И каждому узкому специалисту свойственно ошибаться, просто если заниматься работой, не свойственной для себя работой, то какие-то моменты могут быть упущены(под несвойственной подразумевается: писать ТЗ разработчику, который способен сам взаимодействовать с заказчиком, собрать, формализовать и понять требования заказчика ). Однако, при этом может получиться вполне нормальный продукт, но если бы соблюдалось разделение ролей, то с большей вероятностью, можно получить более высокий результат.
«Мозговой штурм» нужен для того, чтобы разобраться в причинах проблем, предложить идеи, как можно этого избежать, закрепить дальнейшие действия и как результат улучшить свою работу, а НЕ найти и наказать виноватых.
Универсалов нужно беречь и помогать им выявить слабые места и попытаться развить их или отказаться от использования такого «универсала». Обычно, истинные универсалы заинтересованы в своём развитии, тк бесспорно ценятся в команде выше.
Простите, но вся статья полна менеджер коих ошибок, а обвиняет вы в них неких "универсалов" которых же сами и выдумали.
Всё кейсы происходят по одному сценарию:
- берём человека, который занят на другими задачами
- запихиваем ему задачу которая ему не интересна, вне его компетенции и т.п.
- не контролируем качество, но давим на сроки
- профит
Собственно а вы чего ожидали в этом сценарии?
Человек делает на отъебись потому что вы его поставили в такую ситуацию.
Если вы реально хотите эту задачу сделанную хорошо, то как минимум должны разгрузить человека от других задач, как-то замотивировать делать то что он не хочет, оказать помощь/обучение если компетенции недостаточно и самое главное контролировать качество.
Т.е. Кто-то должен проверить что документация написана, тест листы составлены и т.п.
А сейчас вы ведёте себя как "эффектный менеджер", где все заслуги (выполнили в срок) ваши, а косяки они от разработчиков.
Сразу оговорюсь, что универсал не может быть новичком, это люди уровня мидл, сеньор, уже зарекомендовавшие себя в роли универсала. К таким специалистам очень высок уровень доверия.
Вероятно, Вы сформировали такое мнение, т.к., для того, чтобы показать недостатки в работе универсалов (о преимуществах итак всем известно), я привела примеры, в которых описала узкие места. О том, кого я понимаю под универсалами, я ответила в предыдущем комментарии.
Также, возможно не хватило вводных, поэтому поясню.
- Безусловно, когда речь идёт о необходимости выполнения новой задачи, тем более срочной, остальные задачи сдвигаются и человек занимается новой задачей ( либо одним либо несколькими последовательными этапами, как универсал)
- Задачи даются человеку только, если он обладает необходимыми компетенциями ( хорошо знаком с направлением, продуктом, ранее писал тз/кодил/тестировал по этому сервису/продукту)
- Контроль качества по этапам присутствует. Но здесь речь идёт о том, что в силу особенностей типа личности, наличия необходимого инструментария, компетенций, может происходить «замалчивание нюансов» в тз, пренебрегание правилами, и т.д. Это может быть и узкого специалиста, но если один и тот же специалист выполняет всю задачу, риск выше.
Вчитываться в каждое тз, проверять чек-листы и ревьювить код не по силам техлиду из команды в 12 человек. Конечно, в серьезных проектах предлагаемое решение выносится на экспертный совет. Но при решении рутинных задач достаточно информации с митинга и репутации члена команды.
Также, отмечу, что успешный результат в двух приведённых примерах, это заслуга именно тех, кто работал над задачей и довёл ее до конца.
не по силам техлиду из команды в 12 человек.
Делегирование ему тоже не под силу?
Проблемы «замалчивания нюансов» это не решает.
Позвольте спросить, а у Вас в команде есть отдельные ставки людей экспертов по аналитике и тестированию, досконально знающие все направления, продукты и сервисы, бизнес процесс в конце концов.
С кодревью все понятно, а остальное очень спорно.
Только по тестированию. Аналитиков в вашем понимании совмещают, наверное, программисты. Они (мы) получают бизнес-задачи на "человеческом" языке, часто с макетами или мокапами интерфейсов, ссылками на документацию к внешним API и т. п., проектируют модели (иногда в UML, но чаще сразу в коде), обращаясь к бизнесу за предметной экспертизой.
, я прошу заполнить унифицированную форму: карту ошибок,
Увольнять...
Таких менеджеров "разработки".
Не — я прошу заполнить
А — я заполняю по факту анализа причин ошибки.
Ибо причины находящиеся вне компетенции исполнителя им не детектируются. А подобная форма требует либо найти их в себе, либо найти того, кого можно обвинить.
И именно менеджер разобравшись в ходе выполнения (привлекая отзывы исполнителей) и связях должен определить причину ошибки.
Если менеджер совсем "деревянный" он может собрать общий "консилиум" для того чтобы совместным обсуждением исполнители сделали работу менеджера.
Но и в этом случае есть необходимость контролировать процесс для того чтобы это была действительно экспертиза, а не поиск крайнего.
Возможно, это было не совсем понятно из текста статьи: но разбор ошибок с командой, анализ и соответствующую интерпретацию проводит менеджер. Но это не происходит отдельно от участников команды. Работает принцип открытости и доверия.
Эта карта заполняется именно теми, кто принимал участие в решении задачи. Она необходима для того, чтобы разобраться на каком этапе произошёл возможный косяк. И при совместном обсуждении перерождается в понимание истинной причины и того, что нужно усовершенствовать в следующий раз тому или иному человеку.
Если ошибка очень значительная и привела к простою ИС, то к обсуждению привлекаются другие эксперты.
универсалами я пользуюсь только в том случае, если не хватает ресурсов, а задача достаточно срочная
треть моей команды – «универсалы»
нафиг так жить.
Кажется, что вы путаете значение выражения "bus factor". В позитивном ключе оно должно звучать как "увеличили bus factor". Проверить легко — чтобы проект "встал" надо сбить автобусом "bus factor" участников.
Не надо затыкать дыры сотрудниками. Если образовалась дыра, это недоработка руководителя. На этапа анализа проекта надо было расчитать все риски и рассмотреть возможность найма дополнительного сотрудника.
А то затыкают дыры, а потом страдают: «Ой, у нас разработчики эмоционально выгорают, что делать?»
К сожалению не все можно предусмотреть, например, нельзя предусмотреть болезнь сотрудника.
Кроме того, наша специфика связана с выполнением задач, связанных с требованиями регулятора, которые очень часто приходят внезапно.
Поэтому универсалами я пользуюсь только в том случае, если не хватает ресурсов, а задача достаточно срочная.
т.е. систематически?
Если образовалась дыра, ее нужно закрыть, а уже потом думать, что можно сделать что бы такого не случилось.
Как обычно делают в области разработки электроники в России: «требуется программист с опытом монтажа плат и разработки софта и прошивок». Часто набирается весь штат таким образом. Порой до сотни человек. Следствия — сроки затягиваются, половина проектов в разы сложнее скетча ардуинки провальные. Но хорошо такой бизнес работет на аутсорс именно без сервиса внедрения и сопровождения. Многие заказчики прямым текстом и пишут что требуется эскизный проект, proof of concept и тд. Всё ок и по честноку. Зарплаты конечно же 40-70тр что правильно — кпд на сотрудника низкое, а ответственности за быдлокод и быдлоконструкции нет.
Но нередко подобный подход и в тех фирмах которые потом продают и поддерживают свои проекты, многие так и живут т.к. часто это спец оборудование мелкими сериями или вообще разовое.
Причины просты: «ты будешь балду пинать пока идут платы, собирают изделия и тд — вот и занимайся всем, сам же паяй чтоб лучше понять что где плохо сделал»
Мы так же работали, как только стала появляться разделение труда на схемотехника, проектного менеджера, разработчика тестовой оснастки (не только юнит тесты, а ещё проверка и регулировка собранного изделия), разработка прошивок, разработка софта для ПК, разработка приложух для смартов, разработка для hightload и тд.
Я заметил интересную особенность:
1. мы перестали переключаться на совершенно разную деятельность, не нужно сегодня паять платы, завтра рисовать корпус в солидворксе, а потом кодить а потом согласовывать перечеть элементов и закупать его и тд. Высвободилось сразу около 30-40% времени. — рост быстродействия сразу 30-40%.
2. Люди начали пересматривать свою деятельности и рефлексировать — поменялись подходы и каждый стал действовать более системно.
3. Даже у тех кто рисует корпуса и платы начали появляться библиотеки, базы готовых решений, и не просто скопировал — вставил, они начали писать проги для того чтоб например лого в bmp сконвертировать в G-code для фрезера и тд. Т.е. во всю начал развиваться инструментарий.
4. Повысилось качество — не получалось так что тот кто делает тесты для кода и тот кто делает реализацию кода один и тот же человек и он заблуждается одинаково в обоих случаях. В реальном мира аналогично — стало невозможно свалить на нерпопай, заряженую частицу и пр. т.к. тест сделанный другим человеком проходит а основная прошивка сбоит и тд.
5. Люди стали использовать наработки друг друга, порой очень эффективно. Например чтоб вынести решение по оценочной стоимости железяки — стало достаточным скачать служебные утилитки железячника, схематехника, за десять минут получить BOMlist уже с импортом цен из веба и спросить программиста что покрывается его либами и наработками а что нет.
6. оказалось что сборка одной платы совсем не одно и то же что 10 плат и совсем иной разговор для сотен и тысяч плат
пунктов много, но результат — рост скорости разработки внедрения в производство минимум раз в 10, очень существенный рост зарплат, выше чем предложения по МСК и Питеру.
Схема не работает при текучке кадров, бессмыслена для зарубежного аутсорса. И лучше всего работает только когда имеется под боком своё производство (свой продукт или свой сервис в случае ИТ).
Вот такие вот контр-аргументы против фулстека и «универсалов» на основе моего опыта.
Спасибо, что поделились своим мнением и привели аргументы. Было очень интересно читать Ваш пост, он описывает насущные проблемы.
У вас для подобных задач отдельный флоу, раз не можете контролировать сроки по этапам? И с бас-фактором непонятно: чем больше универсалов, тем меньше вероятность того, что разработка встанет из-за того, что кто-то перестанет работать.
Хотя вот с потерей информации согласен, когда сам себе постановщик задачи и исполнитель, и даже приемщик, то обычно не тратишь время на документирование нюансов и уж точно не ведёшь с собой диалога в джире :)
А вообще, если вам часто приходится решать срочные задачи, отменяя планы, то, похоже, вы как менеджер, являетесь представителем заказчика в команде, а не членом команды, которому она делегировала управление.
Отдельного флоу нет, все в рамках эджайла.
Я всегда на стороне команды, прежде чем принимать решение о необходимости выполнения срочной задачи (если это не требование регулятора), с бизнесом обсуждается целесообразность, возможные альтернативы.
Но мы все понимаем, какова степень влияния представителей бизнеса на команду разработки. Самое главное мы должны понимать для чего это делаем, если понимания нет, то находим контр аргументы для отказа бизнесу.
Срочность и иногда внезапность задач у нас обусловлена двумя факторами: 1. Требованиями регулятора, 2. Требованиями бизнеса.
Более срочная задача вытесняет менее срочные, происходит переприоритезация бэклога.
Отдельного флоу нет, все в рамках эджайла.
Если задачи у вас разбиваются на этапы, допустим "анализ", "разработка", "тестирование" и при физическом разделении ролей аналитика, разработчика и тестировщика сроки контролируются, то почему это не работает когда физического разделения нет?
Это возникает из-за того, что при проведении оценки по своей неосновной компетенции могут быть заложены неверные сроки, что приводит к переоценке и сдвигу сроков.
Контроль сроков и соблюдение сроков — разные вещи. Ну и вы как менеджер должны учитывать такие риски. Хотя бы грубым умножением на 3. Сказал разработчик, что напишет за 8 часов, а тестами покроет за 4 часа и никогда раньше со сроками разработки не ошибался, а тестами никогда при вас не занимался, но вроде компетентен: разработку не трогайте, а на тесты 12 часов отводите и контролируйте, что, например, через 4 часов хотя бы один тест сделан, а через 6 — половина.
В моей команде 4 аналитика. На тот момент один находился в отпуске, другой заболел, а остальные занимались реализацией стратегических задач. Если бы я выдернула их, это неизбежно сорвало бы сроки реализации. Остался единственный выход: использовать «секретное оружие» – универсала разработчика–аналитика
Сейчас у нас только один тестировщик, поэтому некоторые задачи приходится тестировать аналитикам, в том числе – универсалам
По ходу у вас универсалы как Вася на картинке
И еще вопрос, вдруг я что-то не так понял. Сначала
Что в итоге получилось?
Процесс разработки стал прозрачнее. Уменьшился BUS-фактор
после
Недостатки:
растет BUS-фактор;
так растет или падает? По вашей же схеме ваши фейлы можно спихнуть покорным чувакам которые точно не огрызнутся «это не моя зона ответственности», так что по идее если кто-то из такой команды загрустит и ликвидируется каким-либо способом его работу можно спихнуть на кого угодно, а если не справится — значит он плохой разработчик
Как уже писала выше, акцент был сделан на выявление недостатков и как с ними можно работать (т.к., преимущества универсалов известны), поэтому у Вас могло сложиться обманчивое впечатление.
В разделе «Выводы» подведён итог в части + и — использования универсалов — это Общий вывод, а в разделе «что получилось», результаты конкретных действий по приведённым примерам.
А еще показательный отрывок статьи:
Конечно, он долго пытался объяснить, что у него «полный бэклог своих задач», но моим волевым решением был отправлен на решение срочной задачи
На мнение сотрудника, очевидно, был положен болт.
Собственно, вы так и не ответили на вопрос — растет или падает BUS-фактор? Из ваших ответов я сделал вывод что вообще не влияет, все равно мнение сотрудника учитываться не будет, так что любую, даже непрофильную работу он все равно сделает
- Про bus фактор — если есть универсал, то он повышается. Для его снижения принимаются меры, общими словами описанные в соответствующем разделе статьи.
- Посмотрите пожалуйста прошлые комментарии, кого я понимаю под универсалами, и под непрофильной = несвойственной работой.
- Те цитаты, которые Вы приводите, всего лишь литературный оборот, не более. Повторюсь, что с появлением срочной задачи, другие задачи у сотрудника сдвигаются. Термин «использование универсалов » упоминается в контексте «использование ресурсов».
- Не бывает неинтересных задач- работая над каждой задачей можно почерпнуть что-то новое. Есть отсутствие желания. Человек, желающий развивать свои компетенции может и хочет работать с любой задачей, даже с рутинной ( если Вы вкладываете такое понятие в «неинтересные»). К каждому сотруднику можно найти подход, зная его мотивацию.
Повторюсь, что с появлением срочной задачи, другие задачи у сотрудника сдвигаются
И отрывок статьи
В моей команде 4 аналитика. На тот момент один находился в отпуске, другой заболел, а остальные занимались реализацией стратегических задач. Если бы я выдернула их, это неизбежно сорвало бы сроки реализации. Остался единственный выход: использовать «секретное оружие» – универсала разработчика–аналитика
Т.е. дернуть аналитиков для выполнения их работы в их зоне ответственности нельзя, но на занятого разработчика повесить их работу вполне норм? Шикарно
Термин «использование универсалов » упоминается в контексте «использование ресурсов».
я уже понял что вы их за людей не считаете. могли бы поэлегантнее это назвать, например «распределение задач между специалистами широкого профиля в команде», это больше подходит под смысл статьи
- Бывает. Откуда новое, если одну и ту же задачу делаешь в сотый раз с небольшими изменениями? Ну, банальные CRUD страницы в админке веб-приложения. А менеджер на предложения написать за неделю их генератор и (в идеале) вообще забыть про этот тип задач говорит "у нас нет недели, они вчера нужны были для этой сущности".
От себя могу сказать, что надо бежать от такого «эффективного менеджера», причем быстро.
Это же надо придумать такое:
1. у разработчика есть полный бэклог задач
2. на его мнение и аргументы «положили болт», потому что «волевым решением..»
3. под
4. устраиваем публичную порку «мозговым штурмом», потому что «снижается качество работы»
5.
Заметьте, что повышается не доход разработчика, который из-за ошибки проект-менеджера вынужден делать работу, в которой он не специалист, а повышается его «карма», которая скорее всего оценивается в мифический попугаях того самого «эффективного менеджера».
Ужас одним словом!
Мне кажется, или все это напоминает «галеру»?
Универсалы, это члены команды, занимающие в ней особое место. Вы правы, можно расписать эти типы и про аналитиков, и про разработчиков, и про тестировщиков. Цель данной статьи, попытаться раскрыть понятие универсалов, их категоризировать и показать их слабые и сильные стороны, описать возможные проблемы и предложить к обсуждению возможные варианты решений.
Типичная идея от "универсала" — это идея сервиса, который позволяет лежать перед телевизором на диване, вслух комментировать контент, иногда "угадывать", и очень иногда получать за это шмоньки.
Вот сидит такой Сергей Юрич Беляков в Таганроге с пивом перед телевизором, и тут, как обычно, реклама Лексус: чуть смуглая сексипозитивная азиаточка в белье, и роскошные интерьеры, и машина–огнемёт все дела. И отхлебнув очередной от пивчанского, Сергей Юрич, вспомнив встретившуюся утром спину дворничихи–узбечки, на привычной громкости говорит телевизору:
— Алиса, ты передай там в "говнобанк–говноидей–точкаком", что если в этом вашем сраном суперлюксовом лексусе, в рекламе, автомобиль будет облизывать не потомок тамерлана, а белокурая дочь викингов — богиня снежной красоты, то продажи нах вырастут нах вашпемана, че они тупят, Алис, скажи.
Делает следующий глоток пива. И ну его дальше телевизор смотреть. И проходит джва года. И приходит Белякову письмо:
Уважаемый Сергей Юрич, трали–вали, мы из компании "говнобанк–говноидей–лтд". Лясем–трясем, так карты на стол уложились, вас таких расистов–Беляковых не одна тыща набралась. Да и лексус зачем–то акцентированно перекрасился в рекламе в кипельно–нордическую сторону, через полгода после того, как вы ляпнули что–то такое при её просмотре. И, черт побери, знаете, и продажи потом выросли ого–ого, как вы и говорили. И мы наняли юристов, кстати спасибо за ваши 500₽ доната в прошлом году. И юристы были так хороши, что заставили лексус поделиться дополученной от перекраса рекламы прибылью с говнобанком-говноидей, все дела. Вот ваши стодолларов, селяви, ждём новых прекрасных идей, аривидерчи, чао, бамбино.
Внимание, знатоки, вопрос: А в обратную сторону это аналогично будет работать? Миллион Беляковых посоветует ерунду; на неё поведутся корпораты и перекрасят рекламу, и последняя явно приведёт к убыткам. Смогут ли корпораты отсудить у Беляковых по тридцатке? Спасибо за оффтоп
Для затыкания дыр на короткий срок 3-6 месяцев компании обычно нанимают контракторов за 150-200 USD per hour, иначе начинают страдать текущие проекты.
По своей профессиональной деятельности, я как раз универсал.
Приходилось сталкиваться с веб-программистами, которые не могут себе настроить тестовый веб-сервер! Не могут определить правила по которым он будет работать… Элементарно сделать так, чтобы его приложение как-то работало. Возможно он должен был отдать на откуп неким другим «узким» специалистам настройку своего окружения… А теперь представте, что таких программистов у вас три, а это значит что при них должен быть минимум один человек который и будет только заниматься настройкой их «хотелок». И это не теория — это практика.
Еще пример. Надо как-то написать некую интеграцию ПО и сайта. А разработчик ПО недоступен. Кому отдать? веб-программисту? Он напишет скрипт, который будет запускаться через веб-сервер по крону. А как еще? Он по другому не умеет. Он не знает что есть еще shell («Это чё ваще? Фи, я таким не занимаюсь»).
Если отдать затыкающему дыру «универсалу», то ему надо: 1. Разобраться в коде, 2. Разобраться в модели данных, 3. Это повторить с другой стороны (изучить ПО), 4. Всё это успеть в сжатые строки (вы же в него верите, он быстрый и всё умеет).
А теперь представьте насколько должен быть человек обучаемым новому, понимать чужой код (это вообще фантастика).
Так что настоящий программист должен уметь практически всё с чем сталкивается, просто в одном он более всего умеет. Тогда его можно будет использовать как «узкого».
«Универсал» в команде разработки: польза или вред?