Способность программировать — один из немногих навыков, который ограничивает вас в глазах окружающих.
Я был менеджером по продукту, менеджером проекта, скрам-мастером и владельцем продукта, инженером по юзабилити и делал кучу других вещей. Я могу проектировать интерфейсы по результатам собеседований с пользователями, могу руководить и обучать команды, распределять работу до дедлайна и запускать проекты. Всё это я делал, и успешно.
Но как только я упоминаю, что пишу код, то становлюсь «разработчиком». Всё, точка. Теперь обязательно нужно назначать менеджера проекта, который определит мне задание. Кто-то напишет техническое задание, по которому я должен дать оценку времени выполнения. Я больше не говорю с клиентами и должен периодически отчитываться о выполненной работе.
Это очень любопытный феномен, который я наблюдал неоднократно, во многих ситуациях и организациях, и не только со мной. Дошло до того, что теперь в некоторых проектах я активно избегаю писать код (или притворяюсь, что не умею), потому что хочу добиться доверия со стороны пользователя или заказчика (например), чтобы он разрешил мне заниматься планированием и составлением технических заданий. Но как только я что-нибудь напишу, то сразу становлюсь в команде «разработчиком». И останусь им навсегда.
В то же время выделенные менеджеры проектов сильно тяготеют к гармоничным разработчикам, которые способны на большее, чем просто писать код. Они исключительно рады работать с инженерами, которые хорошо общаются, способны создать рабочую архитектуру (не только на техническом уровне, но и на уровне проекта/бизнеса) и могут предвидеть сценарии использования продукта. Неудивительно; этих способностей не хватает им самим, они заполняют пустые места. Однако во многих проектах такое разделение обязанностей только добавляет лишний слой коммуникации, без которого гармоничный разработчик часто мог бы лучше выполнить свою работу.
Сначала я думал, что этот феномен в основном связан с возрастом. Если вы относительно юны и соглашаетесь быть программистом, то людям легче смотреть на вас как на типичного разработчика, вдохновлённого духом Кремниевой долины; эдакий живущий в каморке, одетый в балахон антисоциальный парнишка-гик. Но я видел, как то же самое происходит с опытными инженерами более старшего возраста.
Эти инженеры наблюдали, как компании появляются и исчезают, они начинали свои стартапы, работали в компаниях на разных уровнях и в разных ролях, у них всесторонние технические знания, которые делают их настолько ценными во всех ролях. Представим, что рядом будет другой человек (обычно «пиджак») и они отправятся на встречу к клиентам. Если клиентам сказать, что у одного из них всесторонние технические знания — все автоматически примут его за «технаря». По вопросам стратегии, планирования и так далее они будут обращаться к «пиджаку». Хотя инженер мог бы гораздо компетентнее обсудить эти вопросы.
Почему так? Почему такая острая необходимость поставить клеймо на парне с техническим образованием и отстранить его от участия в других областях?
Может быть, потому что люди склонны раскладывать всё по полочкам, относить вещи к разным категориям. В идеале, все вещи в жизни имеют единственную задачу и цель, так что вы можете сказать: «Это топор, им можно рубить» или «Это монитор, он показывает изображение». Так всё становится понятным и предсказуемым. Конечно, именно так мы разрабатываем и хорошее программное обеспечение, посмотрите хотя бы на философию Unix.
Но конечно люди не такие. Мы машины, польза которых постоянно изменяется и совершенствуется. Чем больше человек знает, чем больше он видел и где побывал, тем лучше и гармоничнее он подойдёт для любой данной задачи. Мы признаём это развитие опыта в рамках единственной роли, но почему-то не между разными ролями.
Я считаю, что умение программировать никогда не должно лишать права активнее участвовать в проекте. Наоборот: это делает человека более квалифицированным по сравнению с теми, у кого такой навык отсутствует. Если вы способны вывести стратегические обсуждения напрямую на конкретный технический уровень и пройтись по нему логическим умом разработчика, то это гораздо более ценно, чем пустая болтовня «пиджаков». Вы можете обсудить проблему пользователя и немедленно понять последствия всех возможных решений в системе — и не обязательно потому что вы создали эту систему, а потому что способны вывести технические последствия из опыта. Тогда вы с пользователем примете более информированное решение прямо на месте.
В моей идеальной команде каждый способен выполнять работу любого другого, но просто выбрал специализацию, которая ему больше нравится. Непрерывная смена ролей поощряется, линии связи оптимизируются, а набор ролей часто пересматривается. Такой идеал не совсем реалистичен в специализированных профессиях, но идеал — это не то, что достижимо, а то, к чему нужно стремиться.
Вот почему я думаю, что каждый разработчик должен стремиться к гармоничному развитию, тогда он сможет не только писать код, но и вносить свой вклад на разных уровнях. А для этого важно поощрять, а не запрещать разработчикам расширять свою роль.
Комментарии (101)
Sdima1357
30.11.2017 21:32Заказчики подсознательно боятся показаться некомпетентными.Поэтому выберут для общения «пиджак». Он им ближе
RomanArzumanyan
01.12.2017 13:35Будет более мягок / обтекаем в формулировках, не обидит резким отказом или критикой и т. п.
olegchir
01.12.2017 19:36Может быть, существуют программисты-неидиоты, не кроющие заказчика матом и сарказмом когда ни попадя?
khim
01.12.2017 20:08+1Очень-очень мало. И речь не в мате и в сарказме. Просто компьютеры — по другому устроены. Там функция не может вернуть «нет» и «подмигнуть» чтобы указать на то, что на самом деле имелось в виду «нет для моего начальника, но зайди ко мне позже — и мы договоримся». Все эти ньюансы, которые так важны для человеческого общения, просто некуда засунуть в программу.
А что в результате чушь получается и куча денег будет «выкинута на ветер» — ну так это ж не лично твои деньги пропали. Зато управляемоть коллективом была сохранена, что в компаниях где нетехнарей много — важнее. Вот тут же обсуждалось
arheops
03.12.2017 01:56Мозги у людей устроены +- одинаково.
Выкинем из выборки гениев 1 на миллион, они сильно много стоят для большинства компаний.
Оставшиеся вынуждены тратить значительное время на приобретение ЛЮБЫХ навыков. Есть выбор, потратить время на навык общения с заказчиком, дипломатии, ведения переговоров или на навык написания безошибочного кода, предвидения проблем в коде и так далее.
Потому В СРЕДНЕМ вы получите за те же деньги либо хорошего программиста, либо посредственного, но с навыком дипломатии.
Современный «западный» строй выбирает специализированных работников.
А хороший(даже не замечательный) программист с навыками общения с клиентами — будет работать не на вас, а сам. А если не сам, то за НАМНОГО большие деньги.
KirEv
30.11.2017 21:37похоже, автора оригинала, лично обидели…
интереснее узнать истинную причину появление на свет этой статьи.
фи несогласияпроблемы в команде\проекте начинаются, когда из головы исчезает: «мы в одной лодке»…
с одной стороны есть брэйнштормы и всякое обсуждение от мелких шагов до глобальных направлений,
с другой — каждый должен выполнять свою часть обязанностей, чтобы не занимался каждый всем во избежания хаоса.
группа людей, которые продукт разрабатывают — как единый организм… все от друг друга зависит… и программисты, в нормальных компаниях, не только пишут код, но и могу вставить свои 5 копеек «почему бы сделать не так, а так», внести предложение по UI (где оказывается есть элемент который будет в сотом релизе), и т.д. и т.п.
mmkulikov
03.12.2017 14:03Скорее не обида, а желание автора(естественно оригинала) хоть чем-то, но руководить
sotnikdv
30.11.2017 23:09+1 к статье. Опыт долины. Причина, правда, весьма банальна. Люди, понимающие бизнес, довольно далеки от программирования и наоборот. Поэтому представление тебя, как технического специалиста, сразу ставит на тебе метку «с этим парнем бизнес не обсуждать, он в нем не разбирается».
Насколько оправданы претензии технаря на понимание бизнеса? Ну, пока был чистым инженером и архитектором, казалось, что понимал хорошо. Когда столкнулся с бизнесом, понял, что пропасть широченная.
Поэтому да, факт есть, нет, причина в другом и, ИМХО, оправдана.third112
01.12.2017 03:06Люди, понимающие бизнес, довольно далеки от программирования и наоборот.
А как быть с этим?:
Филипп Кан (р. 16 марта 1952 г.) — разработчик инновационных технологий, предприниматель, создатель первого решения для мгновенного обмена фотографиями в сетях общего пользования. Основал три технологические компании: Fullpower Technologies (2003), LightSurf Technologies (1998) и Starfish Software (1994). Он также один из первых сотрудников, а позже владелец Borland.
khim
01.12.2017 20:12Вы это о человеке, который писал отвратительный код, но был хорошим бизнесменом? По-моему отлчиное подтверждение общего принципа.
third112
01.12.2017 23:35Откуда известно, что Кан писал отвратительный код?
khim
02.12.2017 03:55-1Ну как бы эта, историю Borlandа тут уже забыли, да? Напомню: она началась с того, что Филипп Кан договорился с тремя датчанами о том, что он будет продавать из Turbo Pascal в Америке. Напомню что речь идёт о человеке, научным руководителем которого был некий Никлаус. Под руководством которого он уже тоже написал Pascal…
Впрочем надо отдать ему должное: увидев хорошую вещь он сразу же понял почему про свою собственную версию нужно забыть, а то, что он увидел — нужно продавать.
Мало кто из разработчиков на подобное способен, скорее они склонны до последнего защищать своё детище каким бы кривым и уродливым оно не было.third112
02.12.2017 16:18+1Мало кто из разработчиков на подобное способен, скорее они склонны до последнего защищать своё детище каким бы кривым и уродливым оно не было.
Я знаю многих, кто способен и не раз забывал собственную версию. Просто они умеют работать в команде.
San_tit
01.12.2017 07:19Инженер с качественно полученным образованием способен если не сразу, то после короткого обучения заменить практически любого специалиста сопровождения проекта (разве что кроме юриста, и то под вопросом), а вот обратное практически невозможно: "профессиональный управленец" скорее всего не в состоянии быть разработчиком от слова вообще и, естественно, чувствует свою уязвимость рядом со спецом.
П.С. и как сказано выше: с заказчиком лучше говорить на его языке, вот там пиджаки могут пригодиться...
Free_ze
01.12.2017 09:21Инженерное образование различное — бывают «люди науки», а есть уклоны в управление проектами и всё такое.
ЗЫ Я бы в хирурги пошел. Главное — научиться правильно ножик держать.
grey_kristy
01.12.2017 11:34Я бы не был так самоуверен.
Что, инженер с качественным образованием после короткого обучения способен эффективно продавать свой продукт?
Что то мужики сомневаются…LonelyDeveloper97
01.12.2017 13:35Ну, знаете, я бы не стал так сильно сомневаться.
Мне, например, в период когда я занимался своими проектами хватало убедительности, чтобы продавать даже не конечный продукт, а всего лишь его идею и готовность его реализовывать.
И я бы не сказал, что это не нужный инженеру навык. В конце концов мы продаем компаниям свое время и умения, и способность правильно «впарить» их на этапах резюме, собеседования и правильно индексировать их стоимость в зависимости от своего личностного роста — очень пригождается.
Единственное что — обучение тут действительно не короткое. 10 тысяч часов, все дела.grey_kristy
01.12.2017 18:05+210 тысяч часов это не короткое обучение, это полноценная новая профессия
Sdima1357
01.12.2017 11:47Вообще то я пошутил. Программисты часто и друг друга не понимают. Скилл понимание собеседника доступен не всем инженерам, как впрочем и продажникам, правда вторые могут делать вид что понимают. И в каждой шутке есть только доля шутки.
NickUkolov
01.12.2017 18:33Не каждый, даже с хорошим образованием, все от человека зависит. Знаю нескольких отличных программистов, могут и архитектуру продумать и код отличный написать, коьтрый сопровождать одно удовольствие, но вот с заказчиком общего языка найти не могут, не понимают они друг друга.
sotnikdv
01.12.2017 23:20Ооооо, вы сумели объяснить это гораздо лучше чем я, спасибо. Точнее не объяснить, а продемонстрировать!
Вот именно об этой самоуверенности я и говорил, приводя себя в пример. Все технари почему-то уверены, что они самые умные, самые интеллектуальные и им «после короткого обучения» по плечу все вокруг. И если они смогли выучить язык программирования, то уж стать «профессиональным управленцем», так это вообще легко.
И эта самоуверенность выражается в стремлении лезть в те области, где человек не имеет ни опыта, ни знаний, опираясь ровно на уверенность, что с его то уж могучим интеллектом можно решать любые задачи. Эдакий воинствующий дилетантизм за пределами технических областей. В терминальную стадию входит при обсуждении бизнес вещей (тз еще как-то получается осмысленное обсуждение, общение с клиентом зачастую тоже на технические вещи, если клиент терпеливый).
И это стремление часто и приводит к тому, что на обсуждении бизнес вопросов технарей заботливо маркируют и стараются (вежливо! они зачастую реально круты в своей нише) к обсуждению не допускать.
Только попробовав построить бизнес с нуля, с удивлением понимаешь, насколько это другая и далекая тема и сколько вещей полностью противоречат твоим представлениям и идеализму. В итоге понимаешь, что нужно вдумчиво осваивать новую область и манией величия она не берется.
Я сейчас играю, как чистый технарь, это то, что я хорошо умею. И играл роль ПМ и скрам-мастера в прошлом, это оказалось подъемно. Но сейчас я строю бизнес. Корона с надписями про мой ум и «короткое обучение» уже давно отвалилась.
Попробуйте уловить в моем сообщении не насмешку над Вами, а желание предостеречь Вас от ошибок, которые лично я уже совершил и последствия выгреб.San_tit
02.12.2017 14:26+1Да, вы полностью правы…
Инженер имеет гораздо больше способностей к аналитическому и абстрактному мышлению нежели «профессиональный управленец/экономист/итд» и, как следствие, способен принимать нестандартные решения.
А потом показываешь им матлаб и говоришь, что то что они считают невозможным решается в три строки кода… (это я про динамические модели в экономике)
П.С. Инженер в своем профессиональном развитии (при нормальном его течении, имеется ввиду) может стать великолепным управленцем, но вот не наоборот.
McAaron
02.12.2017 11:34+1Насколько оправданы претензии технаря на понимание бизнеса? Ну, пока был чистым инженером и архитектором, казалось, что понимал хорошо. Когда столкнулся с бизнесом, понял, что пропасть широченная.
Ну да, не всякий технарь может нагло врать и фантазировать и при этом держать лицо.
ASGAlex
01.12.2017 02:08И правда как из параллельного мира. У нас ребят, которые не только код писать могут, но и с клиентом пообщаться, и ТЗ критически рассмотреть, и что-то дельное по проекту/работе в целом предложить — да с руками рвут, даже в рамках одной компании у менеджеров грызня за таких ребят! Ведь они фигачат как боги, при чем сразу по всем фронтам! И тут уже приходится следить, чтобы их не перегружали работой, и в какой-то мере да, действительно искусственно ограничивать круг задач, которые им могут поставить решать.
Но это чисто организационные моменты. Никакого клейма нет, боже упаси! И если, например, у "простого менеджера" вдруг обнаруживается технический бэкграунд, то это же колоссальный рост его авторитета в команде + компетентности в глазах клиентов.
В общем, да, согласен, возможно автора и правда кто-то обидел.
DS28
01.12.2017 05:05У меня наоборот… Никогда не целил в управление, а хотел больше кодить, но не давали. Решение руководства — делать из меня проектного менеджера. Научился многому, но ощущение, что разработчика из меня не вышло остаётся…
Skerrigan
01.12.2017 09:02Если лично вы
отличаете системный блок от ЦПможете общаться с технарями на одном с ними языке, то смело утешьте прямо сейчас теплой мыслью «я помогаю моим коллегам, защищаю их от некоторой степени боли, не являюсь мудаком, я полезный». Ибо это чистая правда — программистам приятно работать с менеджером, понимающим технологические проблемы, «магию» и сопутствующие особенности «под капотом».DS28
01.12.2017 10:18можете общаться с технарями на одном с ними языке
да, это само собой…
программистам приятно работать с менеджером, понимающим технологические проблемы
Но я не работаю с программистами)) Предприятие не айтишное…
Тут именно некоторое сожаление о том, что карьера программиста не для меня (и вообще не понятно, хорошо или плохо...)
Myosotis
01.12.2017 15:39Решение руководства — делать из меня проектного менеджера.
Могло бы быть решением вашем — делать из себя то, что вам хочется, вопреки целям руководства. У нас же не рабство =)
DS28
01.12.2017 17:27делать из себя то, что вам хочется, вопреки целям руководства.
Некогда, задачи нужно был решать…
А уходя, обнаруживаешь, что опыт есть и хороший, и почему-то берут опять не в программисты. А совсем за еду работать как-то уже и не хочется и вот, то какой-нибудь аналитик, то менеджер… Но я не жалуюсь)) Просто рассказываю, что заниматься дают, и иногда даже не спрашивают…
GreenGoblin
01.12.2017 07:33Да просто каждый из этих «предпринимателей», «менеджеров», «маркетологов» и прочих бездарей и тунеядцев понимает, насколько он ничтожен в сравнении со среднестатистическим программистом. Вот и стараются по всякому задвигать. Горнило инженерного образования, абстрактное мышление, незаурядные аналитические способности и широчайший кругозор — все это позволяет инженеру без труда(по сравнению с простыми смертными) разобраться в чем угодно. Мы проникаем своим острым умом в суть вещей, они же — заложники своих бесчисленных заблуждений и когнитивных искажений.
Хватит стесняться, признайте очевидное: мы — лучше. Они по сравнению с нами все равно, что обезьяны.
Amareis
01.12.2017 08:20Возоржал в голос. Сохраню, пожалуй, в мемориз, буду перечитывать в темные времена :)
kozzztik
01.12.2017 21:14так разберитесь уже в управлении, сделайте его как надо и захватите мир. А то управление сплошь и рядом какая то тоска.
sotnikdv
01.12.2017 23:28Это настолько восхитительно, что его нужно распечатать и повесить в палате мер и весов. В двух экземплярах и номинациях! Как художественную квинтэссенцию мышления типажа и как образец лаконичной сатиры.
Хотя я почитал Ваши другие комментарии, возможно с номинацией в разделе «сатира» я поторопился.
McAaron
02.12.2017 12:07Большинство программистов не подпадают под те признаки, котороые Вы описали. Уж настоящих инженеров из них и десяти процентов не наберется. Читал лекции курсантам, которые лет по пять-десять как в софтверной отрасли работают на разных должностях от программистов до руководителей проектов. Чтобы узнать в каком состоянии у них сырок меж ушами, задаю несколько дурацких вопросов, на которые они должны развернуто письменно ответить. Например — «вот розетка, у нее две дырки и два полозка-контакта. Где здесь плюс, а где минус?». Две группы по 15 человек. Только три человека понимают, что там в розетке делается и могут внятно это описать. Все начинали с программирования. При этом только двое из тридцати представляют, как исходный текст превращается в загруженный код. Из тридцати двадцать пять кроме майкрософтовской студии ни с чем более не работали. Никто из них не смог собрать проект из cmd, не запуская студию. Половина не понимает как работает виртуальная память.
Инженер должен знать математику пусть не в объеме Корна, но если он инженер ИТ, он должен знать если не теорию кодирования сигналов, то, как минимум, дискретную математику. По крайней мере он не должен выпадать в атсрал при упоминании графов и БПФ.michael_vostrikov
02.12.2017 14:21+1Вы совершаете распространенную ошибку — подменяете понятия «знать на момент вопроса» и «суметь разобраться».
Также, мне кажется, «большинство программистов» с опытом пять-десять лет не ходит на лекции, тем более на те, где сначала надо квалификацию слушателей выяснить.
NeverIn
02.12.2017 18:02Точно подмечено, разработчик может стать менеджером, но это скучно. А вот менеджеру стать разработчиком тоже можно, но на порядок сложнее. А учитывая текущий ритм изменения технологий практически невозможно.
romanitalian_net
01.12.2017 08:35Обычно, если ты программист/кодер/технарь/разработчик — тебе некогда заниматься менеджерскими "абстракциями". Просто так устроена экономика, что специализация ускоряет процесс. Просто специализация выгоднее. И конечно не надо вдаваться в крайности ;)
gBear
03.12.2017 17:50Извините, не удержался:
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. HeinleinTa_Da
03.12.2017 20:04+1Извините, не удержался: цитата из книги «Жизни Лазаруса Лонга», а не слова самого Хайнлайна, и произносит ее в книге главный герой, который, на минуточку, в момент произнесения фразы прожил 2400+лет. Среднестатистический разработчик проживает чуток меньше.
geher
01.12.2017 08:45Видел и такое, как в статье, но чаще сталкивался с обратным, когда разработчиков против их желания ставили на руководящие должности, посылали общаться с заказчиком, требовали разработать ТЗ.
weiser
01.12.2017 09:34Сталкивался несколько раз, когда, к примеру, тимлиды, уже отставшие от современной разработки лезут что-то править в коде, напирая опытом и тем, что «главное основные принципы программирования, язык и технологии не имеют значения». На выходе получаем потенциально уязвимый, но рабочий код.
Людям просто наскучивает менеджерская работа, организация митингов и проч. и они внезапно вспоминают, что они вообще-то ещё и разработчики. С этой позиции я считаю, что если компания хочет видеть качественный код, то нужно как-то сокращать либо организационную нагрузку на кодящий менеджмент, либо наоборот отстранять их постепенно от кода.boblenin
01.12.2017 17:52Сталкивался и с обратным. Разработчики черезмерно увлекаясь современными фреймворками не замечают наличия простого решения. Хотя и то о чем вы пишете видеть доводилось.
> С этой позиции я считаю, что если компания хочет видеть качественный код,
Качественный код компании нужен только если он хоть как-то может быть выражен материально. Ну в смысле если мы напишем вот так и так — то это будет стоить $xxx и сохранит нам $yyy, а если по другому то соответственно $zzz и $nnn.
aamonster
01.12.2017 10:32Странно. Я обычно наблюдал движение в противоположную сторону — программисты с удовольствием отходят от общения с клиентами ("ура, у нас есть штатный телепат — пусть он узнает, что эти странные люди хотят, и объяснит по человечески") и прочих не технических задач. И их туда привлекают, только если есть проблема, которую иначе не решить.
vga23
01.12.2017 10:37Да, на самом деле раньше всё зависело от этапа развития компании, т.е. где она (компания) находится на своем жизненном цикле развития (по И. Адизису), уровень зрелости компании, а также. Для каждого этапа, отношения между ЛПР и разработчиками имели четкие границы. Но сейчас, проблема в том, что стирается граница зоны должностных обязанностей, в виду интеграции в компании soft skills, перестройки функциональной структуры в отдельные межфункциональные команды, где обязанности распределяются наподобие малого стартапа. Делаешь лучше это, чем он — делал тогда ты. По Адисису — стартап это «лодка», где все члены команды работают сообща и на единое благо. Поэтому не стоит удивляться тому, что разработчиками не дают «управлять» бизнесом, в лучшем случае, его туда просто не допустят. Вывод — менять работу на управленца и больше не НИ В КОЕМ СЛУЧАЕ не упоминать, что ты кодишь или кодил в прошлом.
bopoh13
01.12.2017 10:49Какого хрена сегодня утром я пьян? Правильно. Я отвечаю сам за себя. Человека нельзя заставить делать что-либо.
pborodin
01.12.2017 11:58В моей практике, как правило, все было наоборот. Заказчик был счастлив пообщаться с техническим специалистом. И уровень доверия к технарям всегда был на порядок выше. Потому что даже если заказчик сам не разбирался в вопросе, он каким-то чудом понимал, что технарь сориентируется и решит проблему быстрее чем «эффективный менеджер».
vlsinitsyn
01.12.2017 13:21Дык в том то и проблема, что как только тебя определят как «разработчика», с заказчиком напрямую общение утрачивается. Для этого ведь есть бизнес аналисты, прожект менеджеры…
Конечно, замечательно, когда в вашей компани по-другому. Но я сталкивался и с тем, о чем пишет автор.
Telichkin
01.12.2017 13:24Манифест гибкой разработки программного обеспечения (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”. Невозможно совмещать несколько ролей в организации, которая ценит фиксированные роли и четкое разделение обязанностей. Невозможно добиться доверия там, где ценится сокрытие реального положения дел. Невозможно следовать любым принципам, которые основываются на ценностях, отличных от действительных ценностей организации.
В конечном итоге, настоящие ценности — это самое важное, что есть в организации. Все остальное: используемые технологии, процесс принятия решений, способы коммуникации и постановки задачи, организационная структура и прочее, вытекают из ценностей. Автору статьи, видимо, не удавалось понять ценности организации во время собеседований. Мне тоже еще ни разу не удавалось их понять. Хабравчане, есть ли у вас подходы к выяснению настоящих ценностей компании во время собеседований?
boblenin
01.12.2017 17:56Agile не противопоставляется иерархии. Мало того общаясь с одним из авторов скрама (Jeff Sutherland) — спрашивал у него как они используют скрам в его компании, если они не пишут софт. Он обрисовал структуру. На проектах отдельные скрам комманды (проекты не софтверные), а на стратегическом уровне все управление представляет из себя скрам комманду. Ну во всяком случае я так понял.
olegchir
01.12.2017 20:06+1Agile != (scrum + kanban). Agile в смысле Agile Manifesto — это нечто куда большее.
Имхо, скрам — не более чем компромиссный механизм, служащий для перехода от проектного управления к чему-то более другому. Что вы по этому поводу думаете?Telichkin
01.12.2017 20:44Agile != (scrum + kanban). Agile в смысле Agile Manifesto — это нечто куда большее.
Именно! Только это большее мало кто понимает, начинают "внедрять Agile", а потом он почему-то "не работает". Extreme Programming Explained: Embrace Change (2nd edition) отлично рассказывает и про ценности, и про принципы эффективной работы, которые важны намного больше, чем конкретные практики.
Kirill80
02.12.2017 00:24Агил это квинтэссенция иерарахии. Не даёшь «бекона» — заткнись и слушай. Исправно гони Титаник на айсберг, коль за это «уплочено».
sotnikdv
01.12.2017 23:32+1Есть большая разница, работать напрямую, что бы разработчики понимали бизнес-видение проекта и могли получить ответ непосредственно от лица, имеющего право принимать решение (решали вполне конкретную проблему, когда куча слоев не имела authority и это тормозило согласование) и обсуждать с ними бизнес вопросы (то, как это начали некоторые трактовать).
Kirill80
02.12.2017 00:33Есть три главные ценности в любой организации: бабло гена, толщина члена гена; и, главное, краснота зада гена. О какой из них вы тут распространяетесь?
KarlKarl
01.12.2017 15:15Неоднократно наблюдал в успешных проектах когда заказчик выходит на технаря-исполнителя. И отказывается наотрез разговаривать с «пиджаком». Дабы не устраивать испорченный телефон.
Amomum
01.12.2017 15:17Натурально, параллельный мир. У нас если «ты ж программист», то и закупками позанимаешься, и попроектируешь, и ТЗ напишешь, и документацию оформишь, и на совещаниях посидишь, и еще и код писать должен.
boblenin
01.12.2017 18:01Это зависит от размера компании. Если компания маленькая и растет, то «ты ж программист» при определенных характеристиках личности может стать главой отдела разработки.
Если компания большая — то скорее всего будут ТЗ, код с утра до 6 и до закупок не допустят (это же доступ к бюджету со всеми вытекающими последствиями), на собрания звать не будут (это же доступ к руководству).
Если компания маленькая и не растет, то «ты ж программист» — способ контроля рассходов. Ну и если все отпинывают от себя бюджет и управления ясно почему не растет.
Kirill80
02.12.2017 19:20И вам только кажется, что вы всё это делаете. А заплатят за всё это совсем не вам. Типичная ситуация: разраб лепит какую-нибудь итоговую отчётность, от фуна ему только в общих чертах высказанные потребности прилетают (в духе «нужна отчётность»--«а какая?»--«ты же не тупой, вот сам и думай»). В результате фун огребает бонус за хорошую отчётность (ведь это он её несёт в совет или гену), которая позволила вовремя вскрыть проблемы проекта, а разраб потом только головняка огребает по обслуживанию созданной отчётности. Что имеем? Фун чаще всего не имеет ни малейшего представления о фун. процессе, но за успех получает бонусы, а неудачу всегда может свалить на разраба.
Singaporian
01.12.2017 17:13Я не понимаю, в чем разница между врачом, который хочет стать начальником отделения и разработчиком, который хочет стать начальником тоже там чего-то. И тот и другой не имеет на момент появления своего желания никаких нужных навыков (принцип Питера). Но и там и там эти люди появляются. И почти каждый из этих людей когда-то был ниже по иерархии.
Знаете как оно делается? Люди решают проблему курицы и яйца: пока ты себя позиционируешь как разработчик — к тебе так и будут относиться, но ты так и будешь разработчиком, пока тебе не дадут шанс поуправлять.
Намек: меня перестали звать на вакансии по Windows, когда я убрал оттуда Windows. Вы не хозяин мыслям рекрутера, но вы хозяин своему резюме. Им и рулите.
boblenin
01.12.2017 17:43+2Конечно не дают. Если ты пишешь код, то 8 часов собраний без перерывов всю неделю — не для тебя. Либо ты будешь чисто номинально присутствовать на собраниях, либо код будет так себе.
Часто специалист (не только разработчик) избегает политики, а это значительная часть того, что происходит в бизнесе. У специалиста чаще всего есть однозначные или конкретные ответы на вопросы (можно — нет, делать — не делать), а при работе с клиентом или другими отделами возникают «моменты». Когда однозначного ответа нет.
SbWereWolf
01.12.2017 22:07да, есть такая проблема. Ты видишь что в заданных условиях — точно нет, но все менеджеры знают что условия можно поменять и при необходимости условия будут изменены, поэтому они говорят — да — потому что понимают что у заказчика хватит мотивации что бы изменить условия.
i360u
01.12.2017 18:19К сожалению, комплекс проф-деформаций, которым бывают подвержены многие разработчики, делает подобную ситуацию более чем оправданной в общем случае. Мне часто встречались разработчики, которые при том, что вызывали большое уважение и имели авторитет в узких областях, в других вопросах были ну просто полнейшими профанами и при этом экстраполировали чувство собственного непререкаемого профессионализма на другие области. Но с другой стороны, лучшие инженерные решения рождаются на стыке компетенций, и поэтому "широкие" специалисты с инженерным подходом — очень нужны. Можно сказать, что вся наша цивилизация на таких и держится.
tuvastamata
01.12.2017 18:32-1Наконец то пришло подтверждение — я не одинок во вселенной.
насчёт того, почему программистов сразу выделяют из общения — мы мельники ИТ-времени, находимся на границе того мира, шаманы. к нам приходят с проблемами, но если мы знаем-умеем-видим больше, то мы слишком непонятно сильны и как следствие страшны профану. отсюда насильственная аутизация.
традиционное общество выделяет из себя всяких мистиков, кузнецов и мельников.
информационное общество выделяет из себя программистов.
Kirill80
01.12.2017 18:32-3Каждой касте свойственно защищать свою кормовую базу. Разраб это наёмный работник, а коль так — то, будь добр, примеряй хомут «зарплатного рабства» и «отчуждения продукта». Это теперь твой премар. На этот счёт есть замечательная книжка «Как управлять рабами».
Kirill80
01.12.2017 23:31Розовый… единорог яростно минусует.
Areso
02.12.2017 13:55Вас минусуют за другое. Все эти менеджеры проектов, продуктов, айти-директора и даже многие директора в целом — тоже наемные работники. Да, чем выше должность тем выше шанс получать не только зарплату (оклад), но и премии, зависящие от успеха бизнеса (а не твоего личного/твоих подчиненных), но в целом — они тоже на зарплате.
Так что ваше предположение про зарплата/не зарплата неверно.Kirill80
02.12.2017 17:09Ой ли? Вы где-то в моём исходном сообщении видите противопоставление наёмного труда разраба любому другому виду наёмного труда? Нет. Исходный посыл статьи — почему программистам не дают работать менеждерами, поварами, водителями троллейбусов и т. п. просто в силу того, что программист хочет. Вот эту тему я и развиваю: у раба не спрашивают чего он хочет — рабу приказывают. И чтобы раб исполнял нужен внутрекастовый консенсус в поведении: иначе бунт и утрата активов.
Areso
02.12.2017 18:03Если вы не в курсе, то рабовладельческий строй официальной кончился в 1861 году. В остальном, программист, прошедший какое-нибудь MBA вполне справится с менеджерской позицией, если у него есть на то соответствующие задатки, особенно, если речь идет о позиции с управлением IT-проектами или IT-персоналом.
Kirill80
02.12.2017 18:25Ну так, вперёд и с песнями. Кто ж мешает-то? Автор же влезает в инфантильный спор с той реальностью, где каждый стейкхолдер пытается выстроить вокруг своей делянки разной степени надёжности барьер: будь-то высокий забор с овчарками или непосильный большинству взнос за обучение.
Рабство нельзя отменить. Как нельзя отменить зиму или плохую погоду.
geher
04.12.2017 10:33В России рабовладельческого строя не было. Феодальный был, родоплеменной бвл, капиталистический был, даже социалистический (с оговорками) был. Рабовладельческого не было.
Уточню, наличие в обществе определенных отношений не определяет строй. В тех же США в свое время при официально существующем рабстве строй был вполне себе капиталистическим.
Если же говорить о фактическом рабстае, то оно и сейчас вполне себе процветает даже в западной Европе.
Впрочем, к вопросам наемного труда это уже не имеет отношения.
Разве что можно говорить о весьма вольном и расширенном толковании слова рабство.Areso
04.12.2017 13:50Крепостное право, отмененное манифестом Александром II в 1861 году, вы за рабовладельческий строй не считаете? Когда крестьян можно было продавать, обменивать, убивать?
Kirill80
02.12.2017 17:14Но, думаю, вы не станете спорить, что у выпускника юрфака или финансиста куда выше шансы выйти на долю, чем у любого разраба. При одинаковых затратах на образование. Хотя эту тему поднял не я, а вы.
Andrei_ra
01.12.2017 20:35Неоднократно замечал, что выполняя длительное время определенную работу — сложно переключиться на другую. Например проектируешь в деталях какую-то фичу пару дней, а потом бац и пришло время тесно заняться решением организационных вопросов. Чтобы начать их решать в хорошем ритме и не чувствовать дискомфорта — может уйти 1-2 дня. Если так переключаться по десятку раз за день — это сильно выматывает. Так что спорный момент.
Не стоит забывать, что хороший технарь стоит дороже хорошего пиджака, и найти его сложнее. Выполняя работу, на которой есть кем его заменить — он тратит время неэффективно. Автор статьи, в виду свои технической направленности, об этом и не думает… И заказчики рвущиеся к технарям, а потом удивляющиеся размеру счета, те ещё фрукты.Kirill80
02.12.2017 00:04Пиджак за единицу времени «насимулякрирует» несоизмеримо больше, чем самый инженерный инженер за десять своих никчёмных жизней сможет не то что реализовать — об этом даже речи нет, — а, хотя бы, осознать. Воображение и булшит куда дороже любой реализации.
Andrei_ra
02.12.2017 00:26А вы попробуйте для начала найти инженеров, которые способны и хотят взять на себя помимо прямых обязанностей разработчика — обязанности пиджака. Если все таки найдете — попробуйте заманить их в свою контору, будет ли она «достойна» их?.. И если вам повезет — попробуйте не разориться от их пожеланий по ЗП.
Kirill80
02.12.2017 00:40-1Ой, да только свистни. Ведь каждый суслик — агроном.
P.S: Ресурсы? Гос- капитализм rules.
P.P.S: Да, потом всё со стопроцентной вариацией накроется… женским половым органом. Ну и что? Жизнь-то человеческая коротка и полна страданий: хватай до чего только можешь дотянуться — потом шанс вряд ли повториться. «Сдохни ты сегодня, а я — завтра» (неизвестный автор)
Kirill80
02.12.2017 00:48Я, практически по любой тематике, найду на просторах планеты Земля любого тех. спеца, который вполне сможет изображать деятельность на приемлемом для заказчика уровне, в 10- 100- 1000-раз дешевле рынка. И разницы для хода проекта, статистически, не будет никакой. Более того, тот техраб, который работает лучше на реальный результат будет в результате этого результата только, в лучшем случае, недооценён, а типично — выкинут с рынка. Всё, ребята, прошла эпоха пота и скорби — играйте в лотерею: толку будет гарантированно больше.
Singaporian
02.12.2017 11:53Kirill80, пожалуйста более тщательно прорабатывайте структуирование ваших мыслей. Ничего не понятно, что вы хотели сказать. Какой-то фейерверк несвязных аллегорий.
evgenWebm
01.12.2017 21:26Вообще не согласен.
Ошибка главная втом, что когда ты пишешь код, ты смотришь внутрь проблемы, а когда ты продукт продаешь, ты смотришь вширь. То есть, кардинально разные точки обозрения.
И правильно делают, что если пишешь код, то тебя ставят разрабом, а не менеджером
Каждый должен заниматься своей работой. А многостаночники не особо и нужны.
Caravus
Как определить что статья — перевод. Как из параллельного мира. Мне бы кто написал ТЗ…
Free_ze
Ну да, кстати, даже западные заказчики с удовольствием отстраняются от составления детальных ТЗ.
zag2art
а чем западные принципиально отличаются от наших? мой опыт показывает, что и там и там бывает дикий бордак
Free_ze
Менталитетом, например. Честно говоря, делить на «наших» и «не наших» некорректно, ибо представители каждой нации имеют свои «фишечки». Но в желании свалить ответственность на других все едины (=
RomanArzumanyan
Из личного опыта: приветствуют разделение ролей и спокойнее относятся к «чёрным ящикам». Больше думают о том, как предоставить какие-то услуги, и рассматривают ИТ как средство реализации хотелок.
McAaron
«бордак» — что это?
Chamie
Это когда не можешь решиться — бардак или, скорее, бордель.
VovanZ
Например, по ошибкам перевода.
Например, "Full stop" — это точка (знак препинания), а не "Полный стоп". Более адекватным вариантом было бы что-то вроде:
m1rko Автор
И действительно! Спасибо!
andyudol
А мне «полный стоп» понравился. Как-то это очень по-русски — полный… эээ… стоп.
olegchir
По-моему, это из корабельного сленга: полный вперед, полный назад, полный стоп. А в "точку" оно превратилось уже позже, в разговорной речи, и ты не обязан переводить это именно так.
Chamie
Вряд ли, «полный вперёд», «полный назад» — это как минимум с пароходов началось, а вот тут в обсуждении цитируют фразы с выражением “full stop” из текстов аж от 1628 года. (первый паровой корабль поплыл только в 1783 году).