Всем доброго нового года!
Навеяно статьей Бизнес, я люблю тебя коллеги Verovir, а также ее же статьей Уходя — уходи? Ночной разговор об увольнениях (хотя последняя заслуживает отдельного развернутого ответа).
Коллега, вы в статье хорошо выделили ключевые проблемные точки, с которыми можно встретиться в ИТ- (и не только) бизнесе.
А вот объективная оценка и рекомендации по каждой этих точек ("что, собственно, произошло, и что делать") — вопрос ой какой дискуссионный.
// Кстати, то же касается и вашей предыдущей статьи
Например.
Вы рассказали про выпускника ВМК, который легко раскидал ваших тим-лидов и отбыл в Калифорнию, далее следы теряются.
Это же известная история еще с советских времен, когда на заводах не любили горячих выпускников, которые делали несколько норм в единицу времени.
Не любили, потому что "что сегодня подвиг, завтра — план".
Завтра этот выпускник отбудет в Калифорнию, либо обрастет семьей и ипотекой, и превратится в такого же не ловящего мышей тим-лида, которых вы уволили из-за него.
Вы наступили на грабли, а удара по лбу не заметили.
Это безотносительно реального качества тех тим-лидов (в зависимости от, их увольнение было либо вашей ошибкой, либо их нужно было уволить не в связи с выпускником ВМК).
Вы пишите про бизнес, но бизнес это не про ударные подвиги в одиночку в отдельно взятой задаче, с высоким bus factor.
Бизнес это про решение масштабных задач командой, которая движется медленно (да, вот с такими тим-лидами, как у вас, с сотрудниками, думающими как бы отпрысков отвести-забрать в-из детсада, и т.д.), но уверенно, как ледокол, и необратимо сметает все на своем пути и с высокой степенью вероятности достигает запланированных результатов.
По оценке моих коллег, исследовавших этот вопрос, задачу, которую один мотивированный гений-рокстар сделает за N времени, команда из пяти человек сделает за время 3xN.
И мне эта оценка кажется адекватной.
Заметьте, что итоговое удорожание составит порядка 15xN — т.к. нужно не только платить 5 зарплат, а платить их в 3 раза дольше. И это не считая других расходов — бОльший офис, больше компов и других расходов.
Но это команда. При правильном управлении она гарантированно придет к запланированному результату.
И, если мы говорим о бизнесе, команде по плечу задачи по объему и масштабу, с которыми одиночки уже не справятся.
Еще один пример. Коллега OlegGelezcov хорошо заметил, что ваша статья из серии, что "гребцы ничего не стоят" (кстати, ваша предыдущая статья в ту же степь).
Т.е., вы по большей части пишите "как бы с вами ни обошлись, утритесь, сделайте выводы и двигайтесь дальше".
Давайте поговорим о гребцах
Видимо, речь о разработчиках (программистах) и отчасти о QA-инженерах
В последнее время разработчиков модно сравнивать не только с гребцами, но и с рабочими "у станка".
Давайте посмотрим, верно ли это.
Начнем с того, что разработчик — это инженер, а рабочий, пусть самый квалифицированный — это рабочий.
И это принципиальная разница, из которой следует все остальное, вплоть до различий в 180 градусов.
Может ли разработчик заменить тестировщика, аналитика, ПМ'а?
Тестировщика — легко.
Составить тест-кейсы для своего кода, все "прокликать" и написать автотесты.
Тем более, что юнит- и интеграционные тесты разработчик все равно пишет.
Да, будет чуть хуже, т.к. автор будет тестировать свой код замыленным глазом (но можно отдать это другому разработчику).
Аналитика — если не легко, но нетрудно.
Ибо частью курса обучения разработчика как раз и является исследование предметной области, постановка задачи и моделирование. А немодное нынче ООП — так и вовсе именно про "это".
ПМ'а? Ну, если разработчик более-менее умеет смотреть на задачи "сверху", более-менее коммуникабелен и в целом дружит с головой, то, если нет опыта, то с трудом, с меньшим качеством, но сможет.
Возможна ли обратная замена? Особенно, если мы будем честны с собой, и признаем, что в тестировщики, аналитики и ПМ в основном идут выпускники технических вузов, откровенно "не потянувших" программирование (а в последнее время, "войти в айти", так и вовсе идут люди со стороны, и именно на эти позиции; в разработку же заходят единицы-исключения)?
Тестировщик — с трудом, начиная, скорее всего, с джуниорской позиции, с доизучения языков и платформ разработки, паттернов разработки (а не тестирования), Computer Science в целом, смены парадигмы мышления, но сможет.
Другими словами — сможет, но далеко не каждый, и с очень большими трудом и затратами.
Аналитик? Если есть бекграунд в части инженерных образования и работы, вероятно, сможет, но с меньшей вероятностью, чем тестировщик.
Потому что за редким исключением сильных аналитиков (и действительно аналитиков, а не "аналитиков"), в так называемые аналитики идут те, кто вообще не осилил разработку.
И то, что для разработки нужен определенный психологический склад (интроверсия, усидчивость, высокая концентрация; да, сейчас идут попытки переделать индустрию, чтобы, наоборот, была востребованной гиперактивность, но в т.ч. эту проблему мы и обсуждаем), а современные "аналитики" в этом смысле явно дальше от разработчиков, нежели тестировщики.
И вообще, понятие аналитики это вообще не про ту роль, которую назвали "аналитикой" в современных процессах разработки.
Другими, словами — скорее нет, чем да.
ПМ? Как говорится, "некогда объяснять". С высокой степенью вероятности нет, за реально единичными исключениями.
И если мы говорим не о системе, когда в компании целенаправленно выращивают ПМ/линейных менеджеров именно из разработчиков, а не из тестировщиков и аналитиков.
А вот в случае завода и рабочих, ситуация, скорее, зеркальная.
По большому счету, если отправить директора, бухгалтера, маркетолога на 3-месячные курсы, то худо-бедно, они смогут заменить токаря, сварщика, слесаря начальных разрядов.
А вот сможет ли рабочий после 3-месячных курсов заменить эти роли?
Возможно, рабочий высокой квалификации и сможет после курсов заменить бухгалтера (не главного) и сводить дебит с кредитом и перекидывать средства и фонды между счетами (будет ли ему это интересно — другой вопрос).
Директора, маркетолога, etc? Тут явно сложнее, если не говорить о явных исключениях.
Если что, рассуждения выше о различных профессиях и ролях не для того, чтобы кого-то возвысить относительно других, и наоборот.
Это про то, что есть определенные роли в производственном процессе, и про объективную ценность каждой роли, которая определяется в т.ч. (не)заменяемостью представителями других ролей.
Это про про то, что все эти модные в последние годы разговоры о "гребцах", "разработчиков у станка" — вот это как раз системная попытка принизить роль разработчиков.
У тех, кто двигает эту тему, в итоге ничего не получится, ибо есть природа вещей, из которой проистекает все остальное. Разработчик — это инженер, а не гребец или рабочий (при всем уважении к последним).
И рано или поздно все или вернется на круги своя, ибо по-другому это работать и не может, или все сломается, когда все уйдут в QA, аналитики, ПМ'ы, а в разработчики никто не захочет идти (да и некому уже будет).
Комментарии (45)
SirEdvin
02.01.2019 12:59+1Аналитика — если не легко, но нетрудно. Ибо частью курса обучения разработчика как раз и является исследование предметной области, постановка задачи и моделирование.
А немодное нынче ООП — так и вовсе именно про "это".Нормального аналитика — не сможет. Аналитик это все-таки про сведение фактов, непротиворечивость требований, кучу переговоров и все прочее. Очень малая часть программистов владеет такими навыками.
ПМ'а? Ну, если разработчик более-менее умеет смотреть на задачи "сверху", более-менее коммуникабелен и в целом дружит с головой, то, если нет опыта, то с трудом, с меньшим качеством, но сможет.
Так же — не сможет. ПМ это довольно большое количество огранизационных вопросов, в том числе и всякие аджайлы. Посмотрите на топики на хабре, большое количество программистов даже не понимает, чем плох waterflow, потому что они его в целом не застали, но зато готовы во всю хейтить гибкие методологии, хотя тоже нормальной реализации не застали.
Ну и да, я просто оставлю ссылку на свой комментарий. Среди разработчиков софта нет инженеров, потому что научной базы, которая пересекается с прикладной разработкой практически нет.
Sultansoy
02.01.2019 15:06+1Позвольте с вами не согласиться. Работа аналитика скорее покажется слишком рутиной для программиста. Ибо программист и так занимается анализом во время чтения требований и также разработки. Нужно продумывать кучу кейсов, кучу разных сценарией. А логика, она везде одинаковая.
Насчет ПМ тут все таки зависит не от того, программист ты или нет, а скорее от твоих софт скиллов. В большинстве своем программисты не полюбят работу ПМ-ом. Но также встречается куча ситуаций, когда программисты становятся отличными ПМ-ами. Технический бекграунд полезен везде.
Насчет отсутствия научной базы и вашего комментария. Ну, тут я с вами не соглашусь. Я конечно согласен, что сейчас порог входа в программирование снизили до ужаса, и буквально любой человек может накидать свой сайт, но. Давайте взглянем на более сложные ПО, где мало того, что там должна быть продуманна архитектура, так еще и оптимизации, с учетом железа и прочее. А еще, во многих программах используют плавающую арифметику, что само по себе отдельная наука. Также дискретная математика присутствует во всем программировании, куда бы вы от этого не пытались убежать. Опять же, все сильно зависит от ситуции. Если мы говорим про клепание сайтов на вордпрессе или чем еще, либо про написание какой-то банальной нейросети по гайду, не понимая, что это вообще такое с точки зрения математической модели, то да. Но это ведь не программирование виновато, а люди, которые не хотят учиться.SirEdvin
02.01.2019 15:50Насчет ПМ тут все таки зависит не от того, программист ты или нет, а скорее от твоих софт скиллов. В большинстве своем программисты не полюбят работу ПМ-ом. Но также встречается куча ситуаций, когда программисты становятся отличными ПМ-ами. Технический бекграунд полезен везде.
Что собственно говоря означает, что не всякий программист сможет заменить ПМа.
Насчет отсутствия научной базы и вашего комментария. Ну, тут я с вами не соглашусь. Я конечно согласен, что сейчас порог входа в программирование снизили до ужаса, и буквально любой человек может накидать свой сайт, но. Давайте взглянем на более сложные ПО, где мало того, что там должна быть продуманна архитектура, так еще и оптимизации, с учетом железа и прочее. А еще, во многих программах используют плавающую арифметику, что само по себе отдельная наука. Также дискретная математика присутствует во всем программировании, куда бы вы от этого не пытались убежать. Опять же, все сильно зависит от ситуции. Если мы говорим про клепание сайтов на вордпрессе или чем еще, либо про написание какой-то банальной нейросети по гайду, не понимая, что это вообще такое с точки зрения математической модели, то да. Но это ведь не программирование виновато, а люди, которые не хотят учиться.
Назовите, пожалуйста, научные дисциплины, которые вы используете при разрабатывании приложения. Ну и нет так, что бы "используется плавающая арифметика — вот это и наука", а вот именно "я использую математические модели из математического анализа" ну или что-то похожее.
Например, при проектировании зданий, деталей и прочего инженеры используют сопромат. При разрабатывании очередного веб-приложения программист использует в основном свои знания про программирование, а не какой-то computer science, потому что он бесполезен для этого.
Ну и да, оптимизация под железо — звучит закшварно.
nekt
02.01.2019 21:23Из программиста очень сложно сделать аналитика. В небольших проектах, когда требований не так много, программист эту работу худо-бедно делает. Мол нам надо вот так и вот так, потому что заказчик хочет вот этого.
Но если заказчиков не один, или требования полугодовой давности противоречат текущим требованиям. Да еще и исходят от разных людей. Тут для программиста ближе подход — запилим по более новым требованиям, а там посмотрим. Далеко не всегда такой подход допустим.
oleg_go
03.01.2019 23:48Если разработчики не могут заменить вышеназванных — откуда тогда аналитики и PM берутся. Разве у нас достаточно ВУЗов, которые готовят аналитиков и PM? Или они сразу рождаются аналитиками и PM?
Из разработчиков чаще всего приходят такие позиции. Идут туда в силу «взросления» или когда перестают быть разработчиками. У нас вообще мало кто из разработчиков до пенсии дорабатывает, многие уходят в «смежные» профессии.SirEdvin
04.01.2019 09:19Разве у нас достаточно ВУЗов, которые готовят аналитиков и PM?
Разве у нас достаточно вузов, которые готовят программистов? В Украине какого-то нормального вуза прямо с программистким образованием я не знаю, в основном это какая-то похожая профессия с кучей всего подряд. У меня вот специальность называлась системный анализ, а я взял и пошел в программисты.
Ну и да, когда я говорю о том, что разработчики не могут заменить вышеназванных, подразумевается, что далеко не каждый разработчик может заменить вышеназванных. Какие-то ПМ и аналитики вырастают из программистов, какие-то приходят из смежных областей (ПМ то менеджер, а вот менеджеров у нас готовят как пирожки). И кто лучше на позиции ПМ — бывший технарь или бывший обычный менеджер — это пока еще открытый вопрос, к сожалению.
saipr
02.01.2019 16:58-1Это про про то, что все эти модные в последние годы разговоры о "гребцах", "разработчиков у станка" — вот это как раз системная попытка принизить роль разработчиков.
все уйдут в QA, аналитики, ПМ'ы, а в разработчики никто не захочет идти (да и некому уже будет).Именно этим на мой взгляд и объясняется отсутствие до сих пор по настоящему жизнеспособной и по-настоящеме отечественной операционной системы.
qw1
02.01.2019 19:16+1Есть же проще объяснение: за те деньги, сколько стоит разработка полностью новой ОС, она просто никому не нужна. Никто не захочет платить столько.
saipr
02.01.2019 20:15-1Следуя этой логике, то ничего нового не надо. Хотя почему-то еще древние греки поддерживали тауку и технику. И почему обязательно за деньги? Можно за перспективу, вот только бы быть уверенным в перспективе.
qw1
02.01.2019 22:55Почему не надо? Дешёво — надо (что и показывают примеры linux-клонов). С нуля — дорого — платить не готовы.
И почему обязательно за деньги? Можно за перспективу
Бесплатно я и сам могу пилить в месяц по 100 строк. Лет через 20 — сделаю. А может, и не сделаю.saipr
02.01.2019 23:16Конечно не сделаете — у вас нет перспективы! Вы не знаете зачем!
qw1
02.01.2019 23:53Есть отечественная операционка — KolibriOS.
Как вы оцениваете её перспективы?saipr
03.01.2019 13:05Развитие «Колибри» шло довольно быстро вплоть до 2009 года.
Современная «Колибри» — это регулярно обновляемые «ночные сборки» последней официальной версии, вышедшей в конце 2009 годаЭтим все сказано. Это бич всех так называемых отечесивенных ОС — объявятся. я так понимаю поставятся куда-то и на этом их развитие кончается. Если говорить про KalibriOS — замечательная ОС для использования в учебном процессе аналагично ОС Minix.
qw1
04.01.2019 16:22объявятся. я так понимаю поставятся куда-то и на этом их развитие кончается
Логично. Потому что финансирования нет. Энтузиаст может год работать, три, или пять. Но в конце концов ему надоест и он найдёт себе новый проект.
Возможен вариант самоподдержания процесса, когда новые люди приходят взамен ушедших, но чаще они приходят, чтобы переписать как им нравится, а не поддерживать чужой старый код, обросший костылями.saipr
04.01.2019 16:51Но если государство ставить задачу иметь отечественную ОС, то оно должно и задуматься о том как эта ОС будет поддерживаться и развиваться. Это как с критически важными техлогиями. Представьте себе поддержку атомной электростанции.
qw1
04.01.2019 17:27Ну так на атомный авианосец готовы дать миллиард денег, а на ОС, если и готовы, то только при условии 95% распила.
saipr
04.01.2019 17:38Самое печальное, что для управления шатомным авианосцем тоже требуется ОС. И насколько бы он не был отечественным, если ОС не родная, то и ждать можно всего.
qw1
04.01.2019 18:28Да и разговор про ОС общего назначения, которая не нужна авианосцу. Гораздо надёжнее иметь изолированые подсистемы, каждая со своим ПО.
rzerda
02.01.2019 18:56+3системная попытка принизить роль разработчиков
Здравствуйте, я из эксплуатации, и Вы мне этой фразой делаете очень смешно. Именно я Вам буду снизу стучать, когда в процессе принижения роли разработчика будет достигнуто «дно».
Отчего-то сравниваемый разработчик и коммуникабелен, и тесты пишет сам, и даже на разработчика обучался. Может быть, в Вашей эпсилон-окрестности это справедливо для любого разработчика, и коль так, я за Вашу окрестность очень рад. В моей же эпсилон-окрестности разработчики в массе своей средние. По сторонам не смотрят, смежных областей знать не желают, как устроен программируемый ими компьютер — не ведают.
«Мы бизнес-логику пишем, деньги вам всем зарабатываем» — говорят такие разработчики. А мы вашу бизнес-логику потом подпираем энтерпрайз-рестартом раз в день или даже в час, потому что два дня/часа без деградации оно работать не в состоянии.
Посему предлагаю не сравнивать верхние 20% разработчиков со всеми QA/PM/аналитиками, нечестное какое-то сравнение выходит.sand14 Автор
02.01.2019 20:09Ах да, совсем забыл про вас, спасибо, что напомнили.
В кучку QA/PM/аналитиков (в противовес разработчикам в контексте статьи) нужно добавить модное словечко последней пары лет — DevOps ("эксплуатация").
То, что по вашим словам, в вашей эпсилон окрестности разработчики средние, которые пишут приложения, которые вам приходится, по вашим словам, перезапускать раз в сутки или даже раз в час, как раз — уже появившиеся плоды системы, в которой роль разработки принижена (неадекватно сути разработки и тому, какую роль она выполняет (должна выполнять) в общем процессе).
Именно об этом моя статья.
Вы вообще в курсе, что слышат верхние 20% разработчиков, когда говорят "менеджерам", что знают, как писать приложения, чтобы вам не приходилось перезапускать их раз в час?
JC_IIB
02.01.2019 20:18+1DevOps («эксплуатация»)
Девопс и эксплуатация — это разные сущности. Особенно, если это эксплуатация не только и не столько более-менее стандартных linux-серверов, а какого-нибудь вендорского железа или вендорского софта.
rzerda
03.01.2019 08:36+1«Я знаю, как писать хорошо работающие программы, но мне злой менеджер не даёт» and other hilarious jokes to tell yourself.
Я вообще в курсе. Я также в курсе, что вот этот мифический разработчик из статьи, коль скоро он в состоянии заменить ПМа, найдёт способ сделать так, как нужно (лесть, уговоры, угрозы, шантаж; партизанщина тоже неплохо заходит).
Ваша статья, как мне видится, о том, что «как вы посмели вообще покуситься на элиту ИТ», причём элитарность определяется по должности в трудовой книжке, а не по качествам конкретного человека. И тем не менее всех не подходящих под элитарность программистов Вы объявляете некачественными, плодами злобной системы. Ссылаетесь на исследования коллег без ссылок на статьи с описанием этих исследований, занимаетесь шапкозакидательством «за три месяца [любой] бухгалтер разберётся в металлообработке».
«Относитесь к нам с должным почтением, и мы вам построим город-сад». Не построите, к сожалению, хоть контейнеровоз почтения на вас вывали.moonster
03.01.2019 11:36-1Бесполезно лгать, уговаривать и принуждать к добру, когда нужно впихнуть невпихуемое. Приложение либо нужно ещё вчера, либо не нужно вообще. А потом что выросло — то выросло. )))
rahna
02.01.2019 23:48+1Не хотелось бы перетягивать одеяло на себя, с уважением отношусь к достойным dev\pm\ba\devops, но с этим…
Тестировщика — легко.
Составить тест-кейсы для своего кода, все «прокликать» и написать автотесты.
Тем более, что юнит- и интеграционные тесты разработчик все равно пишет.
… категорически не согласен.
По крайней мере, с легко и тем более.
1. Юнит-тесты — это скорее повинность.
2. Интеграционные тесты — это скорее формальность.
3. Все «прокликать» по написанному тест-кейсу (не говоря уже об автотесте) — мягко говоря не самая тривиальная задачао которой известным мне разработчикам ничего неизвестно
Может, я вырос как тестировщик в неблагополучном районе, не познал настоящей жизни и ненарочно умаливаю способности разработчиков…
И если типовой разработчик из вашего сферического вакуума таки может, то это скорее чудо-мальчик, упомянутый гражданочкой-оппонентом. Тогда непонятна суть вашего спора, ведь его можно декомпозировать еще на один уровень и доказывать, что тестировщик — тоже инженер
Aracon
02.01.2019 23:51+1Могу ошибаться, но я боюсь, что вы недооцениваете труд рабочих — токарей, слесарей. Я не знаком с деталями этих профессий, но почему-то кажется, что не стоит вот так запросто говорить, что их легко освоить. Если вы сами детально разбираетесь в этих профессиях и говорите не понаслышке, а из личного опыта — то ок, из статьи просто напрямую это не понятно.
sand14 Автор
03.01.2019 00:01Поверьте, дооцениваю, и кое-что понимаю в этом.
Более того, разработчику полезно и нужно уметь в токаря и слесаря, т.к. это помогает пространственному мышлению (в дополнение к разработческому абстрактному) + мелкая работа руками.
Все это помогает сохранять и развивать интеллект (в т.ч. и «разработческий») и образовывать новые нейронные связи.
В этом смысле это так же актуально, как изучение иностранных языков или языков программирования с принципиально новой парадигмой.EvgeniiR
03.01.2019 12:44Знать все области высшей математики(вдруг пригодится!), знать как устроена каждая деталь компьютера(вдруг под микроконтроллеры придется программировать, front-end разработчику то), уметь программировать на Си и Ассемблере(база ведь), водить машину(шефа подвозить), знать Lisp, Fortran и Ocaml. Английский, Немецкий и Испанский(мозг развивать), научиться дизайну(красиво чтобы делать), уметь изготавливать и ремонтировать мебель(Не мастеру же деньги отдавать), подметать за собой рабочее место, знать Scrum, Agile и Waterfall, бухгалтерию подучивать, тесты писать приёмочные, уметь в аналитику, и ещё 100 вещей которые должен уметь делать «любой программист».
А когда попросят Фронтенд на Реакте/Ангуляре писать, да БЭМ использовать сказать: «Нет, извините, не знаю таких, пока что на чтении про Си, Кернигана и Ритчи остановился»?
lastrix
03.01.2019 10:34+3При всем уважении, токарному делу обучится — надо только прослушать курс (есть теоретическая база), а затем несколько лет тренировать руки под однотипные операции. Тогда да, будешь токарем первой категории, ну или станок купить.
С программистами такого же не замечал, сидит человек годами, а как писал говнокод, так и продолжает. Купить станок не поможет, потому что задачу автоматизации по какой-то причине до сих пор не смогли автоматизировать. Правда не ясно кто будет заниматься автоматизацией автоматизации процессов. Неужели программисты?
К тому же, выточить нужную деталь можно многократно меньшим количеством возможных последовательностей базовых действий. Даже обработка кнопки ОК в диалоге делается разными способами, хотя сама по себе она является базовым действием в рамках UI.
А теперь представьте себе что-то в духе сделай Х, потом Y, иначе Z, где каждое действие выполняется неопределенное количество времени, да еще требует какие-то сторонние результаты. Звучит просто? Когда встретитесь — увидите столько подводных камней.
Про задачи в стиле "обработать много гб данных, быстро и памяти много не требовать" говорить не хочется даже.
Токарь не имеет дел с задачами, требования которой противоречат друг другу, у программиста такое может быть, как раз из-за того, что отношение как к какому-то быдлу, мол можно за 30-70к нанять джуна и он быстро задачу решит нам. А потом во всем оказываются виноваты конечно же программисты. ПМ непогрешим, а тех дир вообще святой.drobzik
03.01.2019 12:31Токарь не имеет дел с задачами, требования которой противоречат друг другу
Если вы про нормальное производство (а не артель «Иванов и собутыльники»), и достаточно сложное изделие (а не про какую-нить втулку или шайбу), то у токаря есть технологическая карта на изделие, разработанная технологом, проверенная (не всегда, шутка про огурцы все так же актуальна;)) и подписанная кучей людей, и которая гарантирует результат (если ее не нарушать).
И вот технолог — это и есть тот человек, который получает/выясняет требования к изделию, убирает противоречия (в частности, с физическим миром и его законами), и планирует, как собственно это изделие должно быть сделано. И чтобы стать технологом, стажа токаря категорически недостаточно — нужно оттрубить несколько лет института (со всеми мозгодробительными предметами типа сопромата и материаловедения), а потом еще неопределенное количество лет — получать практический опыт (желательно в команде с уже состоявшимся технологом).
Возвращаясь в уютный мир ИТ офисов и сложных информационных систем, аналог технолога здесь — это ИТ архитектор. Он может не быть програмистом/админом/… (скорее даже «не должен быть», хотя технический бекграунд и желателен), но именно он занимается превращением набора хотелок в архитектуру («технологическую карту»), которую в дальнейшем програмисты («токари») превращают в конечный продукт («изделие»). К сожалению, в наших институтах ИТ архитекторов не учат (во всяком случае, мне об этом ничего не известно), так что приходится догоняться самостоятельно, ну и практический опыт в команде с другим архитектором — must have.lastrix
04.01.2019 18:25Если вы про нормальное производство (а не артель «Иванов и собутыльники»), и достаточно сложное изделие (а не про какую-нить втулку или шайбу), то у токаря есть технологическая карта на изделие, разработанная технологом, проверенная (не всегда, шутка про огурцы все так же актуальна;)) и подписанная кучей людей, и которая гарантирует результат (если ее не нарушать).
И вот технолог — это и есть тот человек, который получает/выясняет требования к изделию, убирает противоречия (в частности, с физическим миром и его законами), и планирует, как собственно это изделие должно быть сделано. И чтобы стать технологом, стажа токаря категорически недостаточно — нужно оттрубить несколько лет института (со всеми мозгодробительными предметами типа сопромата и материаловедения), а потом еще неопределенное количество лет — получать практический опыт (желательно в команде с уже состоявшимся технологом).Технолог — это не токарь, и разница слишком огромна, примерно как между кандидатом наук и доктором наук.
К сожалению, в наших институтах ИТ архитекторов не учат (во всяком случае, мне об этом ничего не известно), так что приходится догоняться самостоятельно
Потому что вариативность того, с чем новоиспеченный ИТ архитектор может столкнуться так велика, что к тому времени, как он обучится — будет никому не нужен. В случае же отсутствия опыта работы "в поле" он вообще будет нести чушь и ахинею. Требовать невозможное от конкретных, уже существующих технических решений. Любой технолог по крайне мере в теории на 100% осознает как и что будет делать токарь Вася. И он может с гарантией сказать на что тот или иной токарь будет способен — от того и идут категории. Процесс унифицирован и стандартизирован до нельзя.
И как раз отсутствие понимания того, как работает программист у любого архитектора и приводит к появлению новых "чрезвычайно эффективных фреймворков и стандартов". Всякими js фреймворками уже весь инет забит, и выходят они каждый день — подаются как убийца предшественника и вообще единственный тру-фреймворк.
Подход, при котором вы полностью доверяете кодерам продукт на разработку почти всегда заканчивается бойлерплейтом и гавнокодом — что напрямую говорит об отсутствии квалификации. Если ваши архитекторы в упор не видят с чем исполнители будут иметь дело — то продукт будет завален костыльными решениями, гавнокодом другого рода — гавноархитектурой. И если проблему с отдельным кодером решить можно, то с архитектором — слишком дорого. Потому ОС Windows NT как технология — отличная штука, но даже с не особо хорошей реализацией — она реально хороша (говорю как заядлый линуксоид). А какая-нибудь поделка сделанная на коленке для полноценной демонстрации идеи, с самым идеальным кодом — кусок ненужного гуано — потому что архитектура в 100% не продумывается. Хотя за обе программы платят деньги.
И последнее, аналогом технологической карты для кодеров, которую делали бы ИТ архитекторы — это и будет сам код или блок-схема. Но в том-то и дело, архитектор не пишет кода, он программирует программирование других людей в заданном направлении. А вот технолог полностью определяет всю цепочку действий, которые осуществит конкретный токарь.
lotse8
03.01.2019 23:26+1Непродуктивная дискуссия, потому что спор идет о летчиках вообще, а летчики бывают разные и летают они на: кукурузниках, вертолетах, реактивных пассажирских, реактивных сверхзвуковых военных, транспортных и т.д. и т.п. и выполняют совершенно разные задачи. Аналогично и разработчики.
Verovir
Ну здравствуйте, уважаемый оппонент! Во-первых, вы извратили факты (тимлидов мы не увольняли и про гребцов я не писала), во-вторых, ваш пост ещё более субъективен, поскольку эмоционален. В-третьих, я не говорила конкретно про разработчиков и их замену тестировщиком или ПМ-ом. Я говорила о заменяемости разработчика другим разработчиком и т.д. То есть я пишу не о взаимозаменяемости, а об эквивалентной заменимости.
Этим вы отдельно доставили. Realy? Давайте писать в минобр, отменим техникумы. Вы же понимаете, как сегодня работают на заводах? Станки с ЧПУ, автоматизация, характеристики металлов, вот это всё…Что касается гребцов, то да, мы все гребцы, в принципе-то. Абсолютно все: и мы гребём за деньги, которые нам нужны, и приносим деньги тем, на кого гребём. И гребут все: гугловцы, эппловцы и сотрудники Space X.
Но я транслирую мысль о том, что нужно всегда оставаться человеком, находить свои плюсы и тогда будет в разы проще. Потому что сплетники в курилке и бегуны по трудовым инспекциям выглядят невыигрышно по сравнении с уверенными в себе профессионалами. Надо ли менять работу? Надо! Надо ли уходить, если вас унизили? Почти всегда однозначно! Но всегда нужно думать, в чём причина, не в одном лишь ЧСВ. Это если коротко.
sand14 Автор
Коллега, спасибо за ответ.
А вот это что?
В этом комментарии вы написали:
Если я ошибся, и это две разные истории, то ваши рассказы тем более не в вашу пользу:
получается, у вас тиражируется ситуация, когда к вам приходит горячий выпускник, и вы его выделяете на фоне опытных сотрудников за стахановские методы.
То, что в одном случае вы уволили сотрудников, а в другом нет — детали, не меняющие сути.
А суть в том, что, по вашим статьям и комментариям, получается, вы даже не понимаете, чем чреваты аврально-геройские методы работы в одиночку.
Verovir
Это разные истории, т.к.
Verovir
Прекратите заниматься следствием и софистикой, ваши аргументы пока совершенно несостоятельны. Расскажите про прекрасную командную работу, которая реально случилась вне пределов влажных мечтаний.
sand14 Автор
За это отдельное спасибо.
Как говорить "гребцы", "у станка" именно про разработчиков — всегда пожалуйста.
А как обоснованное возмущение в ответ, так сразу "ну что вы, что вы, мы ж все по сути, фигурально выражаясь, гребцы и у станка стоим"..
Verovir
Где было про станок? Вы там в каком состоянии читаете, коллега?
sand14 Автор
Коллега, пожалуйста, придерживайтесь норм корректного общения.
И если моя статья вас как то задела (а, значит, в любом случае, показалось интересной), то прочтите еще раз — это не разгром ваших статей по пунктам, а полемическая статья об актуальных проблемах, навеянная вашими двумя статьями.
Хотя и построенная в форме ответа, т.к. изначально я задумывал написать комментарий-ответ, а получилась статья.
В своей статье я написал о том, что в последнее время про разработчиков принято говорить "гребцы", "стоите у станка", в т.ч. в глаза со стороны "менеджмента"
JC_IIB
Это вы так изящно назвали людей, которые не боятся отстаивать свои права и/или права своих коллег?
Мммм.
То есть, уверенный в себе профессионал — это тот, кто не пойдет в трудовую инспекцию?
Ммммм.
Verovir
JC_IIB
Показательно, что вы ответили только на первый вопрос из двух.
И да, случай с огнетушителем был абсолютно корректным, эта штука предназначена для спасения жизни, а с этим не шутят.
onlinehead
Знаете, думается это был не первый подобный случай, вряд ли бы с первого раза он начал эскалировать этот вопрос. Скорее это такой common practice.
К тому же — он же не водителем не нанимался. Да и рабочий день уже закончился.
С какого перепуга он должен свое личное время тратить?
Он что то с этого получит — финансовую компенсацию, возможность на следующий день придти к обеду, выбор делать или нет в конце концов?
У компании нет денег на такси?
Я вот тоже допустим частенько занимаюсь рабочими делами после окончания официального рабочего дня, так как большая часть моей команды на западном побережье США.
Но во-первых, к меня есть выбор делать это или нет (и никто меня осуждать не будет если меня вдруг не будет в это время на связи, а если я ну очень нужен — все будет запланировано на максимально ранее время и сильно заранее будет задан вопрос "сможешь ли"?), во-вторых если я знаю, что вечером придется задержаться, то я просто могу придти позже и это тоже нормально. Да и в целом отношения здоровые в коллективе, никто не будет тебя как такси использовать, дороговато обходится такой таксист.
Отношения работника и работодателя должны быть партнёрские, причем с обоих сторон. Нужно уметь договариваться и создавать условия устраивающие обоих. И уж точно не надо пытаться повесить на человека задачу, которая к нему не относится ну совершенно никак.