Comments 127
Но как только я упоминаю, что пишу код, то становлюсь «разработчиком». Полный стоп. Теперь обязательно нужно назначать менеджера проекта, который определит мне задание. Кто-то напишет технические требования, по которым я должен дать оценку времени выполнения. Я больше не говорю с клиентами и должен периодически отчитываться о выполненной работе.
Как определить что статья — перевод. Как из параллельного мира. Мне бы кто написал ТЗ…
Как определить что статья — перевод.
Например, по ошибкам перевода.
Например, "Full stop" — это точка (знак препинания), а не "Полный стоп". Более адекватным вариантом было бы что-то вроде:
Но как только я упоминаю, что пишу код, то становлюсь «разработчиком». Всё, точка.
По-моему, это из корабельного сленга: полный вперед, полный назад, полный стоп. А в "точку" оно превратилось уже позже, в разговорной речи, и ты не обязан переводить это именно так.
Может быть, существуют программисты-неидиоты, не кроющие заказчика матом и сарказмом когда ни попадя?
А что в результате чушь получается и куча денег будет «выкинута на ветер» — ну так это ж не лично твои деньги пропали. Зато управляемоть коллективом была сохранена, что в компаниях где нетехнарей много — важнее. Вот тут же обсуждалось
Выкинем из выборки гениев 1 на миллион, они сильно много стоят для большинства компаний.
Оставшиеся вынуждены тратить значительное время на приобретение ЛЮБЫХ навыков. Есть выбор, потратить время на навык общения с заказчиком, дипломатии, ведения переговоров или на навык написания безошибочного кода, предвидения проблем в коде и так далее.
Потому В СРЕДНЕМ вы получите за те же деньги либо хорошего программиста, либо посредственного, но с навыком дипломатии.
Современный «западный» строй выбирает специализированных работников.
А хороший(даже не замечательный) программист с навыками общения с клиентами — будет работать не на вас, а сам. А если не сам, то за НАМНОГО большие деньги.
интереснее узнать истинную причину появление на свет этой статьи.
с одной стороны есть брэйнштормы и всякое обсуждение от мелких шагов до глобальных направлений,
с другой — каждый должен выполнять свою часть обязанностей, чтобы не занимался каждый всем во избежания хаоса.
группа людей, которые продукт разрабатывают — как единый организм… все от друг друга зависит… и программисты, в нормальных компаниях, не только пишут код, но и могу вставить свои 5 копеек «почему бы сделать не так, а так», внести предложение по UI (где оказывается есть элемент который будет в сотом релизе), и т.д. и т.п.
Люди, понимающие бизнес, довольно далеки от программирования и наоборот.
А как быть с этим?:
Филипп Кан (р. 16 марта 1952 г.) — разработчик инновационных технологий, предприниматель, создатель первого решения для мгновенного обмена фотографиями в сетях общего пользования. Основал три технологические компании: Fullpower Technologies (2003), LightSurf Technologies (1998) и Starfish Software (1994). Он также один из первых сотрудников, а позже владелец Borland.
Впрочем надо отдать ему должное: увидев хорошую вещь он сразу же понял почему про свою собственную версию нужно забыть, а то, что он увидел — нужно продавать.
Мало кто из разработчиков на подобное способен, скорее они склонны до последнего защищать своё детище каким бы кривым и уродливым оно не было.
Инженер с качественно полученным образованием способен если не сразу, то после короткого обучения заменить практически любого специалиста сопровождения проекта (разве что кроме юриста, и то под вопросом), а вот обратное практически невозможно: "профессиональный управленец" скорее всего не в состоянии быть разработчиком от слова вообще и, естественно, чувствует свою уязвимость рядом со спецом.
П.С. и как сказано выше: с заказчиком лучше говорить на его языке, вот там пиджаки могут пригодиться...
ЗЫ Я бы в хирурги пошел. Главное — научиться правильно ножик держать.
Что, инженер с качественным образованием после короткого обучения способен эффективно продавать свой продукт?
Что то мужики сомневаются…
Мне, например, в период когда я занимался своими проектами хватало убедительности, чтобы продавать даже не конечный продукт, а всего лишь его идею и готовность его реализовывать.
И я бы не сказал, что это не нужный инженеру навык. В конце концов мы продаем компаниям свое время и умения, и способность правильно «впарить» их на этапах резюме, собеседования и правильно индексировать их стоимость в зависимости от своего личностного роста — очень пригождается.
Единственное что — обучение тут действительно не короткое. 10 тысяч часов, все дела.
Не каждый, даже с хорошим образованием, все от человека зависит. Знаю нескольких отличных программистов, могут и архитектуру продумать и код отличный написать, коьтрый сопровождать одно удовольствие, но вот с заказчиком общего языка найти не могут, не понимают они друг друга.
Инженер имеет гораздо больше способностей к аналитическому и абстрактному мышлению нежели «профессиональный управленец/экономист/итд» и, как следствие, способен принимать нестандартные решения.
А потом показываешь им матлаб и говоришь, что то что они считают невозможным решается в три строки кода… (это я про динамические модели в экономике)
П.С. Инженер в своем профессиональном развитии (при нормальном его течении, имеется ввиду) может стать великолепным управленцем, но вот не наоборот.
Насколько оправданы претензии технаря на понимание бизнеса? Ну, пока был чистым инженером и архитектором, казалось, что понимал хорошо. Когда столкнулся с бизнесом, понял, что пропасть широченная.
Ну да, не всякий технарь может нагло врать и фантазировать и при этом держать лицо.
И правда как из параллельного мира. У нас ребят, которые не только код писать могут, но и с клиентом пообщаться, и ТЗ критически рассмотреть, и что-то дельное по проекту/работе в целом предложить — да с руками рвут, даже в рамках одной компании у менеджеров грызня за таких ребят! Ведь они фигачат как боги, при чем сразу по всем фронтам! И тут уже приходится следить, чтобы их не перегружали работой, и в какой-то мере да, действительно искусственно ограничивать круг задач, которые им могут поставить решать.
Но это чисто организационные моменты. Никакого клейма нет, боже упаси! И если, например, у "простого менеджера" вдруг обнаруживается технический бэкграунд, то это же колоссальный рост его авторитета в команде + компетентности в глазах клиентов.
В общем, да, согласен, возможно автора и правда кто-то обидел.
можете общаться с технарями на одном с ними языкеда, это само собой…
программистам приятно работать с менеджером, понимающим технологические проблемыНо я не работаю с программистами)) Предприятие не айтишное…
Тут именно некоторое сожаление о том, что карьера программиста не для меня (и вообще не понятно, хорошо или плохо...)
Решение руководства — делать из меня проектного менеджера.
Могло бы быть решением вашем — делать из себя то, что вам хочется, вопреки целям руководства. У нас же не рабство =)
делать из себя то, что вам хочется, вопреки целям руководства.Некогда, задачи нужно был решать…
А уходя, обнаруживаешь, что опыт есть и хороший, и почему-то берут опять не в программисты. А совсем за еду работать как-то уже и не хочется и вот, то какой-нибудь аналитик, то менеджер… Но я не жалуюсь)) Просто рассказываю, что заниматься дают, и иногда даже не спрашивают…
Хватит стесняться, признайте очевидное: мы — лучше. Они по сравнению с нами все равно, что обезьяны.
Возоржал в голос. Сохраню, пожалуй, в мемориз, буду перечитывать в темные времена :)
Инженер должен знать математику пусть не в объеме Корна, но если он инженер ИТ, он должен знать если не теорию кодирования сигналов, то, как минимум, дискретную математику. По крайней мере он не должен выпадать в атсрал при упоминании графов и БПФ.
Обычно, если ты программист/кодер/технарь/разработчик — тебе некогда заниматься менеджерскими "абстракциями". Просто так устроена экономика, что специализация ускоряет процесс. Просто специализация выгоднее. И конечно не надо вдаваться в крайности ;)
Извините, не удержался:
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship,
design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying,
take orders, give orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects.
— Robert A. Heinlein
Во-первых, он таки Лазарь… и, если уж на то пошло, он эту фразу — не произносит.
Во-вторых, я правильно понимаю, что вы на полном серьезе считаете, что в цитате речь про… скажем так, возраст?!
В любом случае, «среднестатистическое» насекомое проживает, таки, много меньше «среднестатистического разработчика». Цитата — ну… мне так кажется,- все-таки, немного не о другом.
Но, если вам угодно, можем отдельно рассмотреть т.с. тезис: «Specialization is for insects… and [software] developers» :-) На reddit, помнится, в свое время, была занимательная ветка про "… and medics" :-)
Видел и такое, как в статье, но чаще сталкивался с обратным, когда разработчиков против их желания ставили на руководящие должности, посылали общаться с заказчиком, требовали разработать ТЗ.
Людям просто наскучивает менеджерская работа, организация митингов и проч. и они внезапно вспоминают, что они вообще-то ещё и разработчики. С этой позиции я считаю, что если компания хочет видеть качественный код, то нужно как-то сокращать либо организационную нагрузку на кодящий менеджмент, либо наоборот отстранять их постепенно от кода.
> С этой позиции я считаю, что если компания хочет видеть качественный код,
Качественный код компании нужен только если он хоть как-то может быть выражен материально. Ну в смысле если мы напишем вот так и так — то это будет стоить $xxx и сохранит нам $yyy, а если по другому то соответственно $zzz и $nnn.
Странно. Я обычно наблюдал движение в противоположную сторону — программисты с удовольствием отходят от общения с клиентами ("ура, у нас есть штатный телепат — пусть он узнает, что эти странные люди хотят, и объяснит по человечески") и прочих не технических задач. И их туда привлекают, только если есть проблема, которую иначе не решить.
Манифест гибкой разработки программного обеспечения (http://agilemanifesto.org) появился более 15 лет назад. О "Agile" стали говорить на конференциях, выбросив из гибкой разработки все ее ценности и принципы кроме одного “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale”. Сейчас слово “Agile” можно встретить в вакансиях практически каждой компании. Эти компании все также продолжают работать по водопаду, сохраняя развесистую иерархию, планируя и проектируя наперед и перебрасывая задачи из одного отдела в другой, но с более короткими итерациями."Agile” организации схватились за инструмент в виде коротких итераций, сохранив привычные процессы, а значит продолжают ценить процессы и инструменты больше, чем людей и их взаимодействие. То есть не принимают первую ценность гибкой разработки “Individuals and interactions over processes and tools”.
Принципы, следующие из первой ценности, которые разделяет автор статьи, но не организации, описанные выше: "Business people and developers must work together daily throughout the project”, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Невозможно совмещать несколько ролей в организации, которая ценит фиксированные роли и четкое разделение обязанностей. Невозможно добиться доверия там, где ценится сокрытие реального положения дел. Невозможно следовать любым принципам, которые основываются на ценностях, отличных от действительных ценностей организации.
В конечном итоге, настоящие ценности — это самое важное, что есть в организации. Все остальное: используемые технологии, процесс принятия решений, способы коммуникации и постановки задачи, организационная структура и прочее, вытекают из ценностей. Автору статьи, видимо, не удавалось понять ценности организации во время собеседований. Мне тоже еще ни разу не удавалось их понять. Хабравчане, есть ли у вас подходы к выяснению настоящих ценностей компании во время собеседований?
Имхо, скрам — не более чем компромиссный механизм, служащий для перехода от проектного управления к чему-то более другому. Что вы по этому поводу думаете?
Agile != (scrum + kanban). Agile в смысле Agile Manifesto — это нечто куда большее.
Именно! Только это большее мало кто понимает, начинают "внедрять Agile", а потом он почему-то "не работает". Extreme Programming Explained: Embrace Change (2nd edition) отлично рассказывает и про ценности, и про принципы эффективной работы, которые важны намного больше, чем конкретные практики.
Scrum, Kanban, XP, etc — это подмножества этого множества — конкретные способы реализовать Agile. Все эти способы, безусловно, ограничивают применимость каждого отдельного способа; но зато вполне четко прописывают все необходимые процедуры.
В качестве аналогии. Мы хотим открыть сеть быстрого питания против мы купили франшизу McDonalds и открываем ресторан.
Agile manifesto — применение Agile подходов для разработки программного обеспечения.
Это ограничение множества Agile в ином, нежели Scrum, Kanban, XP измерении.
Если компания большая — то скорее всего будут ТЗ, код с утра до 6 и до закупок не допустят (это же доступ к бюджету со всеми вытекающими последствиями), на собрания звать не будут (это же доступ к руководству).
Если компания маленькая и не растет, то «ты ж программист» — способ контроля рассходов. Ну и если все отпинывают от себя бюджет и управления ясно почему не растет.
Знаете как оно делается? Люди решают проблему курицы и яйца: пока ты себя позиционируешь как разработчик — к тебе так и будут относиться, но ты так и будешь разработчиком, пока тебе не дадут шанс поуправлять.
Намек: меня перестали звать на вакансии по Windows, когда я убрал оттуда Windows. Вы не хозяин мыслям рекрутера, но вы хозяин своему резюме. Им и рулите.
Часто специалист (не только разработчик) избегает политики, а это значительная часть того, что происходит в бизнесе. У специалиста чаще всего есть однозначные или конкретные ответы на вопросы (можно — нет, делать — не делать), а при работе с клиентом или другими отделами возникают «моменты». Когда однозначного ответа нет.
К сожалению, комплекс проф-деформаций, которым бывают подвержены многие разработчики, делает подобную ситуацию более чем оправданной в общем случае. Мне часто встречались разработчики, которые при том, что вызывали большое уважение и имели авторитет в узких областях, в других вопросах были ну просто полнейшими профанами и при этом экстраполировали чувство собственного непререкаемого профессионализма на другие области. Но с другой стороны, лучшие инженерные решения рождаются на стыке компетенций, и поэтому "широкие" специалисты с инженерным подходом — очень нужны. Можно сказать, что вся наша цивилизация на таких и держится.
насчёт того, почему программистов сразу выделяют из общения — мы мельники ИТ-времени, находимся на границе того мира, шаманы. к нам приходят с проблемами, но если мы знаем-умеем-видим больше, то мы слишком непонятно сильны и как следствие страшны профану. отсюда насильственная аутизация.
традиционное общество выделяет из себя всяких мистиков, кузнецов и мельников.
информационное общество выделяет из себя программистов.
Так что ваше предположение про зарплата/не зарплата неверно.
В России рабовладельческого строя не было. Феодальный был, родоплеменной бвл, капиталистический был, даже социалистический (с оговорками) был. Рабовладельческого не было.
Уточню, наличие в обществе определенных отношений не определяет строй. В тех же США в свое время при официально существующем рабстве строй был вполне себе капиталистическим.
Если же говорить о фактическом рабстае, то оно и сейчас вполне себе процветает даже в западной Европе.
Впрочем, к вопросам наемного труда это уже не имеет отношения.
Разве что можно говорить о весьма вольном и расширенном толковании слова рабство.
Права по закону убивать крестьян у помещика вообще-то не было.
Некоторые помещики даже поплатились за это (другой вопрос, что на это чаще просто закрывали глаза).
Что же до строя, то, повторюсь, рабство было, но общественно-экономический строй при крепостном праве был феодальным с постепенным переходом к капитализму.
И в Европе, включая западную, времен самого махрового крепостничества строй был феодальным, хотя рабство по факту было по полной программе.
Рабоаладельческий строй так называется не потому, что при нем имеет место рабство (закрепленное в законе или нет — неважно), а потому, что основой эеономики являются рабы.
Переход к феодальному строю знаменуется не отменой рабства, а к изменению основы экономики, которой становится земельный надел.
2) Юрфак или фин. фак часто ведут выпускников в никуда. Если среди разрабов тех, кто доходит до планки Sr. Developer и до зарплаты выше среднего — большинство. Среди фин. фака есть звезды, но много девочек остаются домашними хозяйками, бухгалтерами низшего уровня или клерками. Хотя там, безусловно бывают звезды, которые выбиваются в глав бухи а то и дальше.
Затраты на образования даже близко не одинаковые.Бухи не учатся всю жизнь. Им не нужен англиш.
Если среди разрабов тех, кто доходит до планки Sr. DeveloperСеньерство — это ни разу не карьерный рост.
до зарплаты выше среднего — большинствоТо есть большинство получает зарплаты выше среднего?
Среди фин. фака есть звезды, но много девочек остаются домашними хозяйками, бухгалтерами низшего уровня или клерками.Если по вузикам измерять, то программистами становится даже не каждый 10ый из IT-дипломантов. И, да, хватает своих маргиналов, как по окладам, так и по сложности проектов.
Бухи не учатся всю жизнь.Здрасти приехала. Погуглите на тему «переаттестация бухгелтеров» — откроете много нового.
Им не нужен англиш.Зависит от фирмы. Если фирме требуется IFRS или GAAP — то нужно.
То есть большинство получает зарплаты выше среднего?Хороший вопрос для собеседования: как так может быть, что большинство дорастает до зарплат выше среднего, и нет ли тут противоречия (подсказка: противоречия нет и если вы не можете объяснить как так может получиться, то вам ни программистом, ни бухгалтером работать не следует).
Погуглите на тему «переаттестация бухгелтеров»
Переаттестация — это процедура подтверждения квалификации, а не переобучение.
Переаттестация — это процедура подтверждения квалификации, а не переобучение.Переаттестация подтверждает тот факт, что вы можете вести бухгалтерию с учётом всех изменений в законодательстве и налогообложении, которые меняются не один раз в год.
Как вы собираетесь подтверждать ваше знание законов, вышедших месяц назад, ничему «не учась всю жизнь» — для меня загадка.
Понятное дело, что главбуху придется быть в курсе всех нововведений, но согласитесь, выучить новую формулу (несколько их) или освоить новый отчет (несколько их) проще, чем выучить новый комплект технологий (которые меняются в мире веба как перчатки) раз в два года.
Ну и приведенные случаи с английским для бухов — весьма редкие, а программисту не нужен английский совсем только в случае если он 1С-ник)
P.S.: у нас в группе компаний ряд бухов работает с МСФО, но английский знает только финансовый менеджер.
Бухгалтер по каким-нибудь ОС вполне может вбивать 1 формочку, строить 3 отчета и делать 1 списание.«Программист», который на самом деле anykey'щик тоже подобным же багажом знаний обладает. А в трудовой у него может быть реально написано «программист».
Понятное дело, что главбуху придется быть в курсе всех нововведений, но согласитесь, выучить новую формулу (несколько их) или освоить новый отчет (несколько их) проще, чем выучить новый комплект технологий (которые меняются в мире веба как перчатки) раз в два года.Не соглашусь. То есть наверное глобально вы правы: сделать какой-нибудь Colossus или AlphaGo, наверное сложнее, чем свести самый сложный учёт. И платят за такое больше…
Но есть полно вакансий с достаточно механической работой близкой к тем самым формочкам с 3 отчётами и 1 списанием (и соответствующей оплатой).
Не стоит забывать, что хороший технарь стоит дороже хорошего пиджака, и найти его сложнее. Выполняя работу, на которой есть кем его заменить — он тратит время неэффективно. Автор статьи, в виду свои технической направленности, об этом и не думает… И заказчики рвущиеся к технарям, а потом удивляющиеся размеру счета, те ещё фрукты.
Как программистам не дают больше ничем заниматься