Всем доброго нового года!
Навеяно статьей Бизнес, я люблю тебя коллеги Verovir, а также ее же статьей Уходя — уходи? Ночной разговор об увольнениях (хотя последняя заслуживает отдельного развернутого ответа).
Коллега, вы в статье хорошо выделили ключевые проблемные точки, с которыми можно встретиться в ИТ- (и не только) бизнесе.
А вот объективная оценка и рекомендации по каждой этих точек ("что, собственно, произошло, и что делать") — вопрос ой какой дискуссионный.
// Кстати, то же касается и вашей предыдущей статьи
Например.
Вы рассказали про выпускника ВМК, который легко раскидал ваших тим-лидов и отбыл в Калифорнию, далее следы теряются.
Это же известная история еще с советских времен, когда на заводах не любили горячих выпускников, которые делали несколько норм в единицу времени.
Не любили, потому что "что сегодня подвиг, завтра — план".
Завтра этот выпускник отбудет в Калифорнию, либо обрастет семьей и ипотекой, и превратится в такого же не ловящего мышей тим-лида, которых вы уволили из-за него.
Вы наступили на грабли, а удара по лбу не заметили.
Это безотносительно реального качества тех тим-лидов (в зависимости от, их увольнение было либо вашей ошибкой, либо их нужно было уволить не в связи с выпускником ВМК).
Вы пишите про бизнес, но бизнес это не про ударные подвиги в одиночку в отдельно взятой задаче, с высоким bus factor.
Бизнес это про решение масштабных задач командой, которая движется медленно (да, вот с такими тим-лидами, как у вас, с сотрудниками, думающими как бы отпрысков отвести-забрать в-из детсада, и т.д.), но уверенно, как ледокол, и необратимо сметает все на своем пути и с высокой степенью вероятности достигает запланированных результатов.
По оценке моих коллег, исследовавших этот вопрос, задачу, которую один мотивированный гений-рокстар сделает за N времени, команда из пяти человек сделает за время 3xN.
И мне эта оценка кажется адекватной.
Заметьте, что итоговое удорожание составит порядка 15xN — т.к. нужно не только платить 5 зарплат, а платить их в 3 раза дольше. И это не считая других расходов — бОльший офис, больше компов и других расходов.
Но это команда. При правильном управлении она гарантированно придет к запланированному результату.
И, если мы говорим о бизнесе, команде по плечу задачи по объему и масштабу, с которыми одиночки уже не справятся.
Еще один пример. Коллега OlegGelezcov хорошо заметил, что ваша статья из серии, что "гребцы ничего не стоят" (кстати, ваша предыдущая статья в ту же степь).
Т.е., вы по большей части пишите "как бы с вами не обошлись, утритесь, сделайте выводы и двигайтесь дальше".
Давайте поговорим о гребцах.
Видимо, речь о разработчиках (программистах) и отчасти о QA-инженерах.
В последнее время разработчиков модно сравнивать не только с гребцами, но и с рабочими "у станка".
Давайте посмотрим, верно ли это.
Начнем с того, что разработчик — это инженер, а рабочий, пусть самый квалифицированный — это рабочий.
И это принципиальная разница, из которой следует все остальное, вплоть до различий в 180 градусов.
Может ли разработчик заменить тестировщика, аналитика, ПМ'а?
-
Тестировщика — легко.
Составить тест-кейсы для своего кода и все "прокликать" и написать автотесты.
Тем более, что юнит- и интеграционные тесты разработчик все равно пишет.
Да, будет чуть хуже, т.к. автор будет тестировать свой код замыленным глазом (но можно отдать это другому разработчику). -
Аналитика — если не легко, но нетрудно. Ибо частью курса обучения разработчика как раз и является исследование предметной области, постановка задачи и моделирование.
А немодное нынче ООП — так и вовсе именно про "это". -
ПМ'а? Ну, если разработчик более-менее умеет смотреть на задачи "сверху", более-менее коммуникабелен и в целом дружит с головой, то, если нет опыта, то с трудом, с меньшим качеством, но сможет.
Возможна ли обратная замена? Особенно, если мы будет честны с собой, и признаем, что в тестировщики, аналитики и ПМ в основном идут выпускники технических вузов, "не потянувших" программирование (а в последнее время, "войти в айти", так и вовсе идут люди со стороны, и именно на эти позиции; в разработку же заходят единицы-исключения)?
-
Тестировщик — с трудом, начиная, скорее всего, с джуниорской позиции, с доизучения языков и платформ разработки, паттернов разработки (а не тестирования), Computer Science в целом, смены парадигмы , но сможет.
Другими словами — сможет, но далеко не каждый, и с очень большими трудом и затратами. -
Аналитик? Если есть бекграунд в части инженерных образования и работы, вероятно, сможет, но с меньшей вероятностью, чем тестировщик.
Потому что за редким исключением сильных аналитиков (и действительно аналитиков, а не "аналитиков"), а так называемые аналитики идут те, кто вообще не осилил разработку.
И то, что для разработки нужен определенный психологический склад (интроверсия, усидчивость, высокая концентрация; да, сейчас идут попытки переделать индустрию, чтобы, наоборот, была востребованной гиперактивность, но в т.ч. эту проблему мы и обсуждаем), а современные "аналитики" в этом смысле явно дальше от разработчиков, нежели тестировщики.
И вообще, понятие аналитики это вообще не про ту роль, которую назвали "аналитикой" в современных процессах разработки.
Другими, словами — скорее нет, чем да. -
ПМ? Как говорится, "некогда объяснять". С высокой степенью вероятности нет, за реально единичными исключениями.
И если мы говорим не о системе, когда в компании целенаправленно выращивают ПМ/линейных менеджеров именно из разработчиков, а не тестировщиков и аналитиков.
А вот в случае завода и рабочих, ситуация, скорее, зеркальная.
По большому счету, если отправить директора, бухгалтера, маркетолога на 3-месячные курсы, то худо-бедно, они смогут заменить токаря, сварщика, слесаря начальных разрядов.
А вот сможет ли рабочий после 3-месячных курсов заменить эти роли?
Возможно, рабочий высокой квалификации и сможет после курсов заменить бухгалтера (не главного) и сводить дебит с кредитом и перекидывать средства и фонды между счетами (будет ли ему это интересно — другой вопрос).
Директора, маркетолога, etc? Тут явно сложнее, если не говорить о явных исключениях.
Если что, рассуждения выше о различных профессиях и ролях не для того, чтобы кого-то возвысить относительно других, и наоборот.
Это про то, что есть определенные роли в производственном процессе, и про объективную ценность каждой роли, которая определяется в т.ч. (не)заменяемостью представителями других ролей.
Это про про то, что все эти модные в последние годы разговоры о "гребцах", "разработчиков у станка" — вот это как раз системная попытка принизить роль разработчиков.
У тех, кто двигает эту тему, в итоге ничего не получится, ибо есть природа вещей, из которой проистекает все остальное. Разработчик — это инженер, а не гребец или рабочий (при всем уважении к последним).
И рано или поздно все или вернется на круги своя, ибо по-другому это работать и не может, или все сломается, когда все уйдут в QA, аналитики, ПМ'ы, а в разработчики никто не захочет идти (да и некому уже будет).
Автор: sand14
