Более 10 лет я наблюдаю за процессом разработки программного обеспечения, как изнутри, так и со стороны. За это время я занимал различные должности, от джуниора до техлида, тимлида и менеджера продукта. Сейчас совмещаю всё понемногу.
Недавно менеджмент обратился ко мне с вопросом о том, как ускорить поставку ценности командой разработки.
По сути, озвученная менеджментом проблема заключалась в следующем: у нас аналитики не успевают писать спеки, а тестировщики не успевают тестировать фичи. Давай заставим программистов писать спеки и тестировать фичи. К моему превеликому сожалению, этот подход я встречал практически на каждом месте своей работы, и не только там.
Сейчас будет немного оффтопа. Я активно занимаюсь спортивным туризмом. При наборе группы в поход нередко возникает следующая ситуация: приходит участник-новичок, у которого личное снаряжение весит 20+ килограммов. Также ему нужно нести 10-12 килограммов общественного снаряжения и еды. Итого выходит уже более 30 кг.
Ещё приходит опытный участник, который потратил много времени, сил и денег на то, чтобы его набор личного снаряжения весил 10-11 килограммов. Физическая и техническая подготовка у него также гораздо лучше, чем у нашего новичка.
Что в такой ситуации сделает наш классический руководитель похода? Снимет с новичка общественную нагрузку и переложит её на опытного. В итоге мы получим двух юнитов с загрузкой 25+ килограммов, из которых ни один не может передвигаться с достаточной скоростью и автономностью.
Что в таком случае сделает опытный руководитель? Ещё на этапе собеседования обозначит новичку требования по подбору и замене снаряжения и подтягиванию физической формы.
Не нужно ослаблять своих сильных участников, перекладывая на них нагрузку слабых. Нужно подтягивать слабых до уровня сильных.
Сегодня вообще сложилась крайне странная ситуация, которая заключается в том, что быть крутым техническим специалистом невыгодно с точки зрения ROI.
Хороший синьор бэкенд разработчик получает 300-400 т.р. в месяц. Для того чтобы этого добиться, он потратил кучу времени на образование, разбирается в тонкостях работы хранилищ данных, сетей, брокеров сообщений, алгоритмах, фундаментальных принципах работы своего языка программирования и других инструментов, которые он применяет, системном дизайне, аналитике, тестировании и нередко в продуктовых вопросах. Он принимает решения, которые влияют на исполнение десятков тысяч запросов в секунду, несёт ответственность за продукт и вообще за всё что с ним происходит. Я не веду речи о синьор ангулар или реакт разработчиках и прочих формошлёпах (уж при всём уважении), а говорю об инженерах-программистах, решающих сколько-нибудь крупные технические задачи.
Миддл тестировщик получает ~100 т.р. в месяц, при этом он знает как отправить запрос постманом (иногда курлом, но это уже 150 т.р.), как написать sql типа select *, и что бывают GET и POST запросы. Ещё есть некая "теория тестирования", которая изучается за месяц. А для всего остального есть разработчики, на которых переложат то, что выходит за рамки.
Как-то так получается, что стоимость айтишника в зависимости от его навыков - это логарифм, и с некоторого момента развиваться в инженерном направлении становится просто невыгодно.
Поэтому хочу обратиться к нашим дорогим руководителям: не пытайтесь навешивать на программистов задачи других людей, которые те не могут выполнять ввиду собственной неквалифицированности. Заставьте их подтянуться до уровня своих программистов. Иначе вы останетесь с толпой дорогих недоучек, и некому будет подхватывать проекты, когда задачи в них выйдут за рамки отправки POST запросов.
Комментарии (21)
saipr
07.01.2024 08:10+2Поэтому хочу обратиться к нашим дорогим руководителям: не пытайтесь навешивать на программистов задачи других людей, которые те не могут выполнять ввиду собственной неквалифицированности.
Не добавить, не убавить.
Breathe_the_pressure
07.01.2024 08:10+3Менеджмент живёт в своей парадигме, к сожалению на некоторых действует только провал. Пока не угробятся об стенку, они думают о совершенно других вещах. Например, повесим задачи на тех кто везёт, так как надо проект сдать, а там трава не расти. Или возьмём работника из общепита задешево в тестеры, потренируется и напишет этот ваш Select *.
Я с таким сталкивался, один раз предупреждаю, но если хотите бардак давайте по-вашему. А потом должен уже у них быть свой естественный отбор? Те люди которые перекладывают свои недальновидные решения на поддержку командой, типа я поджёг, а вы разбирайтесь, должны как-то редуцироваться с рынка.
svz Автор
07.01.2024 08:10Скорее речь о том, что в глазах менедмента не виден провал в квалификации между юнитами разных направлений с одинаковой зп. Как-то так исторически сложилось, что с разработчиков спрос всегда был значительно выше при той же стоимости. Из-за этого и не происходит отбора, а происходит наваливание обязанностей на разработку.
LeetCode_Monkey
07.01.2024 08:10Сегодня вообще сложилась крайне странная ситуация, которая заключается в том, что быть крутым техническим специалистом невыгодно с точки зрения ROI.
Ой, пчёлы кажется начали что-то подозревать! Давно говорил, в айти 300К это за троих, по 100К на "каждого". А с такими переработками, вобщем-то, можно много где заработать, для этого в айти не надо.
Breathe_the_pressure
07.01.2024 08:10+1Ну тогда найдите нормального разработчика на 100к на С++ или Java, я уже не говорю про троих. Или вы как тот на начальник из "ГУП НИИ Теплоцентрали России" c кипятком на кофепоинте? ;)
LeetCode_Monkey
07.01.2024 08:10Ну тогда найдите нормального разработчика на 100к на С++ или Java
А вы не устаивайте алгопридурь на собесах и экзаменационные допросы, сразу обнаружите что людей способных работу работать нынче предостаточно. Тем более C++ и Java, коим сто лет уже. А хотите чтобы ещё и литкод вам отплясывал или 100500 методов сортировки наизусть знал - ну это да, это только за отдельный прайс.
dimaaannn
07.01.2024 08:10-1Очередь за забором не закончилась! Не закончилась, слышите?
Просто у вас слишком высокие требования! Вон Джамшут умеет кнопки нажимать, чем не жава программист?)
Egor3f
07.01.2024 08:10+4На 300к можно спокойно работать без переработок. Если это не так - меняйте компанию.
LeetCode_Monkey
07.01.2024 08:10-1На 300к можно спокойно работать без переработок. Если это не так - меняйте компанию.
Если у вас нет хлеба, кушайте пироженные. (с)
Нынче корову можно меньше кормить, но больше её доить. И за 200К три шкуры сдерут. Я конечно допускаю что где-то ещё остались заповедники из 10ых, где по инерции продолжают платить 300К за узкий спектр задач... Но вот это точно не просто взять и тыкнуть в рандомную компанию и прийти туда с улицы.
olartamonov
07.01.2024 08:10+2Как-то так получается, что стоимость айтишника в зависимости от его навыков - это логарифм, и с некоторого момента развиваться в инженерном направлении становится просто невыгодно.
Я открою вам большую тайну, если сообщу, что любая профессия в этом мире так устроена?
Только не логарифм, а S-образная кривая. Если бы вы были менеджером и разбирались в управлении проектами, вы бы их не путали :)
Farongy
07.01.2024 08:10-1Так пусть программисты просят не 300-400 т.р., а 500-600-700.
Breathe_the_pressure
07.01.2024 08:10+1Так на это и рассчитана вилка на собеседовании. Вот напишут 300-500к. Вы думаете, что вы с прошлого места скакнёте сразу на 500. А работодатель думает, что сейчас чувака за 500 примет на 300. В итоге получается консенсус оппортунизма с некомпетентностью.
Farongy
07.01.2024 08:10+3Вилки сообщают при первом созвоне/обмене сообщениями. И если мой текущий оклад + 30% меньше вилки, дальнейшего общения просто не будет.
pavelsha
07.01.2024 08:10-1Вы тут про Аджайл? Вы помните, что Аджайл - это про командную работу? А как же кросс-функциональность участников?
Ну, хорошо, поняли, что команда несбалансирована. Что будем делать? Сидеть и ждать пока проект закончится (или отменится) и можно будет уйти в другую?
Или будем что-то делать? Может Менять или учить аналитиков?
nolube
07.01.2024 08:10Как руководитель - полностью поддерживаю.
В краткосрочной перспективе безусловно можно попросить программистов потестировать и пописать спеки (хотя с точки зрения качестве результат будет весьма посредственный). Но с точки зрения оптимизации "потока доставки ценности", если в процессе доставки есть ботлнек в тестировании и аналитике - при ограничениях бюджета намного выгоднее перебалансировать процесс - уволить несколько программистов и нанять тестировщиков и аналитиков.
Если велосити разработки условно 100 сторей в неделю, а велосити QA - 80 сторей - очевидно, что нужно сократить бюджет на разработку процентов на 10, и увеличить бюджет на обеспечение качества. В результате весь процесс будет давать в неделю условных 90 сторей, а стоить намного дешевле.
Не понимаю зачем так держаться за сохранение участка процесса, формирующего завалы в других местах.
синьор бэкенд разработчик получает 300-400 т.р. в месяц
Если это аргумент для менеджемента - то стоит аргументировать стоимостью разработчика для компании, а не его зарплатой.
svz Автор
07.01.2024 08:10+3Это скорее аргумент для самого программиста ) Мысль о том, что каждый следующий рубль к зп получается значительно большим приложением усилий. Не то чтобы это было откровением, но в какой-то момент, задумавшись, я испугался этой разницы.
upd: зацепился за "уволить несколько программистов и нанять несколько тестировщиков". Вот в этом и посыл моей заметки: уволив программистов вы рискуете обнаружить, что они покрывали часть задач тестирования, которые сами тестировщики решить не в состоянии ввиду недостатка квалификации. На мой взгляд, правильным шагом тут будет "уволить нескольких тестировщиков и взять более квалифицированных тестировщиков" или же "заставить тестировщиков прокачать навыки и повысить производительность". Вот о чём речь.
nolube
07.01.2024 08:10+1Обнаружить в вымышленном примере можно много чего. Например, что тестировщики вынуждены тестировать по несколько раз из-за "говнокода". Или что из-за отсутствия девопсов они тестируют руками, что можно тестировать автоматом в пайплайне, или что программисты не пишут юнит-тесты, что приводит к постоянной регрессии из-за любой фичи.
Если пример из фантазии - лучше придерживаться первоначальных условий - "программисты такие классные, что за ними никто не успевает". Если речь про реальную жизнь - нужно решать общую задачу по оптимизации cycle time, а не нести пургу о безумных преимуществах интеллектуальных способностей одних над другими.
Любой программист знает, что эффективность любой системы определяется боттлнеком. И совершенно очевидно, что при ограничениях бюджета нет никакого смысла держать условных 10 программистов, если пользы в общее дело они приносят как 8. Все равно что скейлить вверх ненагруженный сервер очередей при нагруженной на 99% БД.
pavelsha
07.01.2024 08:10Давайте честно, мысль о том, что преодолевать новую ступеньку при высокой базе труднее, чем при низкой базе Вы донесли, но немного окружным путём.
Конструктивный совет тут, наверное, такой: кроме вертикального роста квалификации есть горизонтальный. Смотрите смежные области или даже не совсем смежные. Новая Ступенька мастерства в них скорее всего доступее из-за низкой базы. Второй вопрос: Сможете те ли конвертировать эти новые знания в деньги или другие преимущества. Но это тема для ещё одной статьи...
Описание боттлнека в статье такое, что можно почитать смысл "не надо затыкать дырки 'дорогими' программистами, лучше пусть сидят и курят, чем делают работу, требующую более низкой квалификации". Наверное поэтому дискуссия и пошла в сторону, которая Вам не нравится. И поэтому мне и nolube отсыпаться минусов ;-)
Solberger
07.01.2024 08:10уволить нескольких тестировщиков и взять более квалифицированных тестировщиков
Более квалифицированные будут стоить дороже, а задачи могут остаться теми же: "отправить в Postman запрос", "потыкать кнопки на сайте".
Для того, чтобы эти новые "квалифицированные" начали приносить пользу, придётся ещё и схему тестирования поменять, вложиться в автоматизацию, поддержку и прочее по стеку. А на это опять потребуется бюджет и время. Вы уверены, что проекту это надо?
заставить тестировщиков прокачать навыки и повысить производительность
"Заставить тестировщиков" - это поменять шило на мыло с "запрячь разработчиков". Вы ровно так же, как и любой эффективный менеджер, меряете категорией "заставить" вместо "заинтересовать". Результат будет такой же, как и до заставляния - системная проблема никуда не денется и отделы аналитики и тестирования так и будут буксовать (да ещё и текучка кадров усугубит эту ситуацию).
ky0
Подкину ещё релевантного оффтопа:)
В бытность свою рейд-лидером в WoW ловил неплохие такие потоки лучей ненависти, когда раздавал эпичный лут, ставя в приоритет наименее одетых (а значит, хуже хилящих/дамажащих) персонажей. Увещевания, что хорошо одетому чуваку из топа эти шмотки дадут лишь небольшой прирост, доходили далеко не сразу и не всегда. Кем-то такое поведение как раз интерпретировалось как "ослабление сильных участников".