Comments 21
Не нужно ослаблять своих сильных участников, перекладывая на них нагрузку слабых. Нужно подтягивать слабых до уровня сильных.
Подкину ещё релевантного оффтопа:)
В бытность свою рейд-лидером в WoW ловил неплохие такие потоки лучей ненависти, когда раздавал эпичный лут, ставя в приоритет наименее одетых (а значит, хуже хилящих/дамажащих) персонажей. Увещевания, что хорошо одетому чуваку из топа эти шмотки дадут лишь небольшой прирост, доходили далеко не сразу и не всегда. Кем-то такое поведение как раз интерпретировалось как "ослабление сильных участников".
Поэтому хочу обратиться к нашим дорогим руководителям: не пытайтесь навешивать на программистов задачи других людей, которые те не могут выполнять ввиду собственной неквалифицированности.
Не добавить, не убавить.
Менеджмент живёт в своей парадигме, к сожалению на некоторых действует только провал. Пока не угробятся об стенку, они думают о совершенно других вещах. Например, повесим задачи на тех кто везёт, так как надо проект сдать, а там трава не расти. Или возьмём работника из общепита задешево в тестеры, потренируется и напишет этот ваш Select *.
Я с таким сталкивался, один раз предупреждаю, но если хотите бардак давайте по-вашему. А потом должен уже у них быть свой естественный отбор? Те люди которые перекладывают свои недальновидные решения на поддержку командой, типа я поджёг, а вы разбирайтесь, должны как-то редуцироваться с рынка.
Скорее речь о том, что в глазах менедмента не виден провал в квалификации между юнитами разных направлений с одинаковой зп. Как-то так исторически сложилось, что с разработчиков спрос всегда был значительно выше при той же стоимости. Из-за этого и не происходит отбора, а происходит наваливание обязанностей на разработку.
Сегодня вообще сложилась крайне странная ситуация, которая заключается в том, что быть крутым техническим специалистом невыгодно с точки зрения ROI.
Ой, пчёлы кажется начали что-то подозревать! Давно говорил, в айти 300К это за троих, по 100К на "каждого". А с такими переработками, вобщем-то, можно много где заработать, для этого в айти не надо.
Ну тогда найдите нормального разработчика на 100к на С++ или Java, я уже не говорю про троих. Или вы как тот на начальник из "ГУП НИИ Теплоцентрали России" c кипятком на кофепоинте? ;)
Ну тогда найдите нормального разработчика на 100к на С++ или Java
А вы не устаивайте алгопридурь на собесах и экзаменационные допросы, сразу обнаружите что людей способных работу работать нынче предостаточно. Тем более C++ и Java, коим сто лет уже. А хотите чтобы ещё и литкод вам отплясывал или 100500 методов сортировки наизусть знал - ну это да, это только за отдельный прайс.
На 300к можно спокойно работать без переработок. Если это не так - меняйте компанию.
Если у вас нет хлеба, кушайте пироженные. (с)
Нынче корову можно меньше кормить, но больше её доить. И за 200К три шкуры сдерут. Я конечно допускаю что где-то ещё остались заповедники из 10ых, где по инерции продолжают платить 300К за узкий спектр задач... Но вот это точно не просто взять и тыкнуть в рандомную компанию и прийти туда с улицы.
Так и работайте за 100к, кто же вам мешает?
Как-то так получается, что стоимость айтишника в зависимости от его навыков - это логарифм, и с некоторого момента развиваться в инженерном направлении становится просто невыгодно.
Я открою вам большую тайну, если сообщу, что любая профессия в этом мире так устроена?
Только не логарифм, а S-образная кривая. Если бы вы были менеджером и разбирались в управлении проектами, вы бы их не путали :)
Так пусть программисты просят не 300-400 т.р., а 500-600-700.
Вы тут про Аджайл? Вы помните, что Аджайл - это про командную работу? А как же кросс-функциональность участников?
Ну, хорошо, поняли, что команда несбалансирована. Что будем делать? Сидеть и ждать пока проект закончится (или отменится) и можно будет уйти в другую?
Или будем что-то делать? Может Менять или учить аналитиков?
Как руководитель - полностью поддерживаю.
В краткосрочной перспективе безусловно можно попросить программистов потестировать и пописать спеки (хотя с точки зрения качестве результат будет весьма посредственный). Но с точки зрения оптимизации "потока доставки ценности", если в процессе доставки есть ботлнек в тестировании и аналитике - при ограничениях бюджета намного выгоднее перебалансировать процесс - уволить несколько программистов и нанять тестировщиков и аналитиков.
Если велосити разработки условно 100 сторей в неделю, а велосити QA - 80 сторей - очевидно, что нужно сократить бюджет на разработку процентов на 10, и увеличить бюджет на обеспечение качества. В результате весь процесс будет давать в неделю условных 90 сторей, а стоить намного дешевле.
Не понимаю зачем так держаться за сохранение участка процесса, формирующего завалы в других местах.
синьор бэкенд разработчик получает 300-400 т.р. в месяц
Если это аргумент для менеджемента - то стоит аргументировать стоимостью разработчика для компании, а не его зарплатой.
Это скорее аргумент для самого программиста ) Мысль о том, что каждый следующий рубль к зп получается значительно большим приложением усилий. Не то чтобы это было откровением, но в какой-то момент, задумавшись, я испугался этой разницы.
upd: зацепился за "уволить несколько программистов и нанять несколько тестировщиков". Вот в этом и посыл моей заметки: уволив программистов вы рискуете обнаружить, что они покрывали часть задач тестирования, которые сами тестировщики решить не в состоянии ввиду недостатка квалификации. На мой взгляд, правильным шагом тут будет "уволить нескольких тестировщиков и взять более квалифицированных тестировщиков" или же "заставить тестировщиков прокачать навыки и повысить производительность". Вот о чём речь.
Обнаружить в вымышленном примере можно много чего. Например, что тестировщики вынуждены тестировать по несколько раз из-за "говнокода". Или что из-за отсутствия девопсов они тестируют руками, что можно тестировать автоматом в пайплайне, или что программисты не пишут юнит-тесты, что приводит к постоянной регрессии из-за любой фичи.
Если пример из фантазии - лучше придерживаться первоначальных условий - "программисты такие классные, что за ними никто не успевает". Если речь про реальную жизнь - нужно решать общую задачу по оптимизации cycle time, а не нести пургу о безумных преимуществах интеллектуальных способностей одних над другими.
Любой программист знает, что эффективность любой системы определяется боттлнеком. И совершенно очевидно, что при ограничениях бюджета нет никакого смысла держать условных 10 программистов, если пользы в общее дело они приносят как 8. Все равно что скейлить вверх ненагруженный сервер очередей при нагруженной на 99% БД.
Давайте честно, мысль о том, что преодолевать новую ступеньку при высокой базе труднее, чем при низкой базе Вы донесли, но немного окружным путём.
Конструктивный совет тут, наверное, такой: кроме вертикального роста квалификации есть горизонтальный. Смотрите смежные области или даже не совсем смежные. Новая Ступенька мастерства в них скорее всего доступее из-за низкой базы. Второй вопрос: Сможете те ли конвертировать эти новые знания в деньги или другие преимущества. Но это тема для ещё одной статьи...
Описание боттлнека в статье такое, что можно почитать смысл "не надо затыкать дырки 'дорогими' программистами, лучше пусть сидят и курят, чем делают работу, требующую более низкой квалификации". Наверное поэтому дискуссия и пошла в сторону, которая Вам не нравится. И поэтому мне и nolube отсыпаться минусов ;-)
уволить нескольких тестировщиков и взять более квалифицированных тестировщиков
Более квалифицированные будут стоить дороже, а задачи могут остаться теми же: "отправить в Postman запрос", "потыкать кнопки на сайте".
Для того, чтобы эти новые "квалифицированные" начали приносить пользу, придётся ещё и схему тестирования поменять, вложиться в автоматизацию, поддержку и прочее по стеку. А на это опять потребуется бюджет и время. Вы уверены, что проекту это надо?
заставить тестировщиков прокачать навыки и повысить производительность
"Заставить тестировщиков" - это поменять шило на мыло с "запрячь разработчиков". Вы ровно так же, как и любой эффективный менеджер, меряете категорией "заставить" вместо "заинтересовать". Результат будет такой же, как и до заставляния - системная проблема никуда не денется и отделы аналитики и тестирования так и будут буксовать (да ещё и текучка кадров усугубит эту ситуацию).
Заметки о совмещении ролей в командах разработки