Интересно во всем этом то, что эти шторма, героическая борьба, поиски стратегий - как со стороны соискателя так и рекрутера, смена структуры рынка труда и ит-потребностей компаний и прочая, и прочая, вызвано не объективными макроэкономическими факторами, а директивными решениями устанавливающих правила. Которое могло бы быть, ну например, какое то другое. Интересно, сколько это нулевая с точки зрения получения реального результата движуха, стоит для экономики страны.
Систематическую ошибку выжившего вижу я. Проблем у них как у всех, просто у них возможностей ими делиться на интернетных площадках больше, чем у главного технолога производства промышленных стиральных машин с другими главными технологами в стране.
Ну так разработка понятие более широкое, чем кодирование, описанное в статье тоже часть разработки. Другой вопрос,какова реальная эффективность такой толщины менеджерского корпуса, на что направляется масса этой махины. Я понимаю, что есть конторы которые просто могут себе это позволить без особых рефлексий. Но одно дело - развивать многоуровневый ит менеджмент потому что ты получишь с этого прямой мультипликативный эффект на рынке, другое - что тебе по любому с каждой транзакции по квитанции за ЖКХ капает денежка, адские ипотеки при господдержке и т.п., и ты просто можешь развести у себя много модного ит по книжкам (а потом ещё и самому начать их писать). И какой из этих двух вариантов имеет место быть в отдельном случае мне кажется стейкхолдеры знают не всегда)
Условно говоря, ватерфлоу это когда когда спроектировали - построили - сдали, эджейл это когда (спроектировали кусок - построили - посмотрели что получилось -)*n - сдали. С учетом того что проектирование осуществляется парой аналитик-архитектор (бизнес- и системный), то, чем короче участок проектировки, тем меньше величина ошибки, тем меньше требований к аналитику и, соответственно, к его квалификации. С другой стороны, чем меньше итераций, тем меньше полных трудозатрат на проект, при условии правильно спроектированной модели конечно. И самый главный плюс ватерфлоу - понимание реалистичности решения и размеров ресурсов на его достижение. Эджейл в одном пределе может увести в бесконечное проектирование без результата, а в противоположном вырождается в ватерфлоу как "эджейл с одним спринтом"
Т.е. в подходе к реализации проекта нужно выбрать оптимальную степень дезинтеграции проектирования как минимальную, которую может обеспечить ваша проектная группа (аналитик-архитектор) исходя из ее компетенций. Чем меньше итоговых спринтов при сохранении качества проекта, тем выше уровень группы проектирования и меньше стоимость проекта.
К чему вся эта банальщина. Выбор подхода к проектированию это не вопрос предпочтений ПМа и тем более аналитика. Это вопрос возможностей проектной группы относительно сложности стоящей задачи. Я вообще подозреваю, что эджейл был создан как ответ на необходимость закрывать проекты, сложность которых превосходила возможности проектировщика решить их методами ватерфлоу, в котором удорожание разработки за счет последовательного проектирования и непрозрачности бюджета это своего рода страховка от краша проекта в середине из-за ошибок проектирования методами ватерфлоу. Перекладывая, таким образом, риски ошибок проектирования на перманентную проверку решений в полевых условиях, исправлением на ходу.
Таким образом, принципиальность в вопросах "за" или "против" эджейл или ватерфлоу это либо вопрос религии, либо личный интерес. Но, в любом случае, на одинаковой сложности проекта, если аналитик умеет в ватерфлоу он сможет и в эджейл, а наоборот не всегда. Другими словами, принципиальность против эджейл среди аналитиков несколько натянута. Вот наоборот может быть, т.к. предъявляет больше требований.
Отличный сценарий к блокбастеру "как ничего не понять и стать старшим системным аналитиком в Х5".
Шутка ) Под впечатлением некоторых этапов в вашей эпопее. Особенно, почему-то, поразил до глубины души круг обязанностей аналитика как "в 1С планировала, сколько одежды нужно привезти в магазины со склада.". Я, конечно, всякого видал, но жизнь всегда найдет повод удивить.
О, спасибо что предупредили. Я как раз после статьи ставлю серию, подумывал достать руль с педалями из загашника и сколько это гимора (в НФС играл когда руля еще не было).. Ну значит не надо, ок
Похожие чувства с автором. После этой игры для меня автомобили на десяток лет делились на две одинаковые группы "Порше" и все остальное.
И еще хотелось бы добавить, не смотря на древнюю графику, фантастические пейзажи как отдельное качество игры. Которые, что характерно, не приедались от прохождения к прохождению, и куда хотелось вернуться.
У проектов есть одна особенность - они, блин, очень разные. Точнее, разнотипные. Бывает проект можно описать одной задачей, бывает надо разбивать на кучу задач, бывает надо бить на этапы, бывает вообще бесконечные проекты по сопровождению с отсечкой по месяцам. И это все проекты. В одних проектах задачи надо представлять по ганту, в других по канбану, а в третьих нужно и одно и другое представление. Бывает задачи в рамках проекта группируются по законченной части проекта, бывает по группе исполнителей, а бывает и так и эдак. А еще бывает необходимость оценить рентабельность проекта, отслеживать платежный календарь по проекту, задолженность по проекту. А еще бывает необходимо отслеживать эффективность трудозатрат и качество менеджмента проекта - что напланировали, что получилось.
Разные системы ориентируются на разные решения, поэтому наверное и находят свои ниши. Кусочки закрывают.
HR это как автоматизированная система управления производством. Нужная вещь которая позволяет работать производству на совсем другом уровне. Но если она неадекватно настроена, то производству кранты.
Так и есть, и в этом проблема. Программистов выпускается много, олимпиоников среди них единицы (в этом и смысл олимпиады, побеждает меньшинство). Всем нужны лучшие, но з/п по рынку как для средних. Конечно лучше взять джуна и заточить его под собственный стек технологий. И тут начинаются приколы, т.к. компании далеко не все железобетонные команды, работающие вечно и одним составом. Компании разоряются, кадры текут. А стеки у всех слишком разные. Вот и получается что большинство разработчиков как старые китайские автомобили, на вторичном рынке цены не имеют. Что толку идти в ИТ, если через 3-5-8 лет ты окажешься не нужен в своей компании а всем остальным ты не подходишь? Конечно есть звезды, как без них. Но чтобы звезды могли работать, им нужна покрывающая массовка рядовых кодеров. Т.е. система заранее выстроена так, что большинству гарантировано ничего.
А рынок труда это как раз большинство. И что характерно, большинству рядовых кодеров противостоит такое же большинство рядовых компаний. Которые почему-то считают себя уникальными (впрочем как и большинство рядовых кодеров). И тут случается взаимное несоответствие ожиданий реальности. Которое в текущей ситуации парализует рынок при наличии как спроса, так и предложения.
я один раз так сделал, когда директор по hr ушла в отпуск - взял кандидата, толкового инженера, которого она упорно отшивала как не имеющего опыта по профильной должности. Ничего, и кандидат себя оправдал и директор понял, простил и поощрил.
Просто тимлидировать и рекрутировать это две разные компетенции, не всегда сосуществующие в одном человеке. Поэтому что для компании важнее, той компетенции она и должна (в идеале) отдавать предпочтение. И не спрашивать по другой как по само собой разумеющейся.
Позвольте дополнить ваш тезис, коллега, подсократив множество не попадающих в вашу экстраполяцию вариантов: не могу припомнить специалиста по дорочильным вопросам, который хорошо решал бы прикладные задачи. Более того, я совершенно точно не встречал ни одного дрочилу, который решал бы такие задачи однозначно лучше или хотя бы сопоставимо относительно прикладных специалистов.
Если сэкстраполировать данный тезис консолидированно с вашим, то, боюсь, у нас вовсе не останется иного варианта, кроме как сделать статистически обоснованный вывод о том, что степень задрачивания базой В БОЛЬШИНСТВЕ СВОЕМ обратно пропорциональна прикладной полезности специалиста.
Который в общем то можно вывести аналитически, а не статистически: направление умственного ресурса на прикладные задачи освобождает эти ресурсы с поддержки "базы", ненужной для решения этих задач, и чем больше ресурсов будет выделено, тем лучше будут решаться эти задачи и, следовательно, тем меньше будет владение базой (по крайней мере, оперативное). И наоборот.
А уже отсюда, позвольте в силу профдеформации позанудствовать, можно сделать уже следующий вывод: наблюдаемый систематический рост такого подхода в найме свидетельствует как о наблюдаемой общей деградации ИТ-индустрии, как минимум, в стране, так и о неизбежном ускорении этой деградации в ближайшем будущем. Причина такого вывода очевидна: поскольку результат такого подхода в виде перебоев в разработке не приводит к его смене, значит топменеджмент такой подход и, следовательно, перебои, устраивает. Причем систематически, массово. А причиной этого, в свою очередь, может являться только одно: падает востребованность продукта индустрии в экономике. Высокие темы держатся на инерции но привод уже отключился. Далее инерция приведет к переизбытку предложения и случится кризис, если ситуация в идустрии не изменится.
Моя личная гипотеза причин подобного в том, что индустрия начала поедать сама себя, продукт начал создаваться ради продукта, цели начали выдумываться за неимением объективно стоящих, и под этим самокопирующемся шлаком хоронятся немногочисленные (на общем фоне) действительно востребованные решения. Так что, коллега, опасаюсь что эпоха когда программисты будут как бухгалтеры в начале 2000-х, уже не за горами.
Чтобы ответить на вопрос, нужна ли экранизация или нет, нужно сначала ответить на вопрос, какую цель преследует экранизация. Судя по содержанию статьи, цель - донести идеи, заложенные в книге, до широкого зрителя. А не, например, коммерция или творческий зуд. Есть нюанс. Даже здесь, в комментариях, видно, что идеи книги совершенно по разному воспринимаются в разных головах. Одни видят в ней решение выхода из цивилизационного тупика. Другие обличение социалистического строя. Третьи утопический бред. И это все с одного материала, поданного гениальным писателем. Понятно что многое в восприятии зависит от собственных тараканов, однако убедительность формы подачи материала определяет силу влияния продукта на этих тараканов. А вы, если я правильно догадываюсь, хотите не только идею книги транслировать, а еще и свое восприятие этой идеи. Причем современному жителю, воспитанному обществом потребления. Причем, как я подозреваю, молодому поколению. И, вероятно, его неглупому сегменту, которые вдобавок неудовлетворены окружающей действительностью и формирование мировоззрения которых еще в процессе. В таком случае боюсь шансов испортить дело больше, чем сделать. Потому что, в отличие от фанатов ЧБ, которым доказывать и показывать ничего не надо, у этих ребят есть огромный спектр информационных потоков разных форматов, от тиктока до лекций Семина в ютубе, в котором ваше произведение будет лишь одним из. И чтобы достичь цели и показать что именно эта идея, а не какая другая, сработает, вам надо, во первых, математически знать это самим. Во вторых, быстро и ярко, на фоне остального, ее показать. А в третьих, уже, собственно, ее рассказать. Для этого сюжет должен быть максимально сжатым, логичным, непротиворечивым, динамичным и насколько возможно простым, а выводы из него - очевидны, чтобы зритель сам увидел идею, а не с ваших слов. И вот только после выполнения этих условий уже собственно формат продукта: 2Д мульт, 3Д-мульт, рисованный мульт, кино. Причем форма передачи материала, желательно, не должна отставать по качеству содержанию. Причем это не обязательно должно быть сложно, дорого и спецэффектно, может чтонибудь простое, условные симпсоны или южный парк, главное чтобы гармонировало с содержанием и темпом. Ну и чтобы темп с содержанием тоже гармонироал конечно. Соответственно, вам нужно всего лишь найти гениального сценариста, гениального режиссера и дизайнера. Под такой результат экранизировать нужно. Под другой - нельзя.
Я собственными глазами видел, как заказы покупателей и заказы на производство немаленького завода велись в редмайне а-ля ERP, причем на одном учетном уровне а иногда как одно целое, так что закупки через жиру не самое удивительное что бывает.
Ну раз специализированного софта нет, то оно и к лучшему. У большинства подобных изделий к сожалению либо функционал урезан, либо интерфейс чудовищен. Запилить под себя, тем более когда все первичные данные для построения уже есть и оперативно вводятся кодерами и проектменеджерами, не великая проблема.
Интересно во всем этом то, что эти шторма, героическая борьба, поиски стратегий - как со стороны соискателя так и рекрутера, смена структуры рынка труда и ит-потребностей компаний и прочая, и прочая, вызвано не объективными макроэкономическими факторами, а директивными решениями устанавливающих правила. Которое могло бы быть, ну например, какое то другое. Интересно, сколько это нулевая с точки зрения получения реального результата движуха, стоит для экономики страны.
Систематическую ошибку выжившего вижу я. Проблем у них как у всех, просто у них возможностей ими делиться на интернетных площадках больше, чем у главного технолога производства промышленных стиральных машин с другими главными технологами в стране.
Ну так разработка понятие более широкое, чем кодирование, описанное в статье тоже часть разработки. Другой вопрос,какова реальная эффективность такой толщины менеджерского корпуса, на что направляется масса этой махины. Я понимаю, что есть конторы которые просто могут себе это позволить без особых рефлексий. Но одно дело - развивать многоуровневый ит менеджмент потому что ты получишь с этого прямой мультипликативный эффект на рынке, другое - что тебе по любому с каждой транзакции по квитанции за ЖКХ капает денежка, адские ипотеки при господдержке и т.п., и ты просто можешь развести у себя много модного ит по книжкам (а потом ещё и самому начать их писать). И какой из этих двух вариантов имеет место быть в отдельном случае мне кажется стейкхолдеры знают не всегда)
Ни то ни другое.
В ИЛ-2 для стрельбы из под капота не пригодится.
Я бы не рисковал сейчас в Тинькофф
Условно говоря, ватерфлоу это когда когда спроектировали - построили - сдали, эджейл это когда (спроектировали кусок - построили - посмотрели что получилось -)*n - сдали. С учетом того что проектирование осуществляется парой аналитик-архитектор (бизнес- и системный), то, чем короче участок проектировки, тем меньше величина ошибки, тем меньше требований к аналитику и, соответственно, к его квалификации. С другой стороны, чем меньше итераций, тем меньше полных трудозатрат на проект, при условии правильно спроектированной модели конечно. И самый главный плюс ватерфлоу - понимание реалистичности решения и размеров ресурсов на его достижение. Эджейл в одном пределе может увести в бесконечное проектирование без результата, а в противоположном вырождается в ватерфлоу как "эджейл с одним спринтом"
Т.е. в подходе к реализации проекта нужно выбрать оптимальную степень дезинтеграции проектирования как минимальную, которую может обеспечить ваша проектная группа (аналитик-архитектор) исходя из ее компетенций. Чем меньше итоговых спринтов при сохранении качества проекта, тем выше уровень группы проектирования и меньше стоимость проекта.
К чему вся эта банальщина. Выбор подхода к проектированию это не вопрос предпочтений ПМа и тем более аналитика. Это вопрос возможностей проектной группы относительно сложности стоящей задачи. Я вообще подозреваю, что эджейл был создан как ответ на необходимость закрывать проекты, сложность которых превосходила возможности проектировщика решить их методами ватерфлоу, в котором удорожание разработки за счет последовательного проектирования и непрозрачности бюджета это своего рода страховка от краша проекта в середине из-за ошибок проектирования методами ватерфлоу. Перекладывая, таким образом, риски ошибок проектирования на перманентную проверку решений в полевых условиях, исправлением на ходу.
Таким образом, принципиальность в вопросах "за" или "против" эджейл или ватерфлоу это либо вопрос религии, либо личный интерес. Но, в любом случае, на одинаковой сложности проекта, если аналитик умеет в ватерфлоу он сможет и в эджейл, а наоборот не всегда. Другими словами, принципиальность против эджейл среди аналитиков несколько натянута. Вот наоборот может быть, т.к. предъявляет больше требований.
Отличный сценарий к блокбастеру "как ничего не понять и стать старшим системным аналитиком в Х5".
Шутка ) Под впечатлением некоторых этапов в вашей эпопее. Особенно, почему-то, поразил до глубины души круг обязанностей аналитика как "в 1С планировала, сколько одежды нужно привезти в магазины со склада.". Я, конечно, всякого видал, но жизнь всегда найдет повод удивить.
надо было из принципа, после того как все благополучно закончилось. Столько мучений и все зря?! Чтоб хоть было, по итогу, за что.
О, спасибо что предупредили. Я как раз после статьи ставлю серию, подумывал достать руль с педалями из загашника и сколько это гимора (в НФС играл когда руля еще не было).. Ну значит не надо, ок
Похожие чувства с автором. После этой игры для меня автомобили на десяток лет делились на две одинаковые группы "Порше" и все остальное.
И еще хотелось бы добавить, не смотря на древнюю графику, фантастические пейзажи как отдельное качество игры. Которые, что характерно, не приедались от прохождения к прохождению, и куда хотелось вернуться.
У проектов есть одна особенность - они, блин, очень разные. Точнее, разнотипные. Бывает проект можно описать одной задачей, бывает надо разбивать на кучу задач, бывает надо бить на этапы, бывает вообще бесконечные проекты по сопровождению с отсечкой по месяцам. И это все проекты. В одних проектах задачи надо представлять по ганту, в других по канбану, а в третьих нужно и одно и другое представление. Бывает задачи в рамках проекта группируются по законченной части проекта, бывает по группе исполнителей, а бывает и так и эдак. А еще бывает необходимость оценить рентабельность проекта, отслеживать платежный календарь по проекту, задолженность по проекту. А еще бывает необходимо отслеживать эффективность трудозатрат и качество менеджмента проекта - что напланировали, что получилось.
Разные системы ориентируются на разные решения, поэтому наверное и находят свои ниши. Кусочки закрывают.
А так интересно конечно, спасибо за статью.
HR это как автоматизированная система управления производством. Нужная вещь которая позволяет работать производству на совсем другом уровне. Но если она неадекватно настроена, то производству кранты.
Так и есть, и в этом проблема. Программистов выпускается много, олимпиоников среди них единицы (в этом и смысл олимпиады, побеждает меньшинство). Всем нужны лучшие, но з/п по рынку как для средних. Конечно лучше взять джуна и заточить его под собственный стек технологий. И тут начинаются приколы, т.к. компании далеко не все железобетонные команды, работающие вечно и одним составом. Компании разоряются, кадры текут. А стеки у всех слишком разные. Вот и получается что большинство разработчиков как старые китайские автомобили, на вторичном рынке цены не имеют. Что толку идти в ИТ, если через 3-5-8 лет ты окажешься не нужен в своей компании а всем остальным ты не подходишь? Конечно есть звезды, как без них. Но чтобы звезды могли работать, им нужна покрывающая массовка рядовых кодеров. Т.е. система заранее выстроена так, что большинству гарантировано ничего.
А рынок труда это как раз большинство. И что характерно, большинству рядовых кодеров противостоит такое же большинство рядовых компаний. Которые почему-то считают себя уникальными (впрочем как и большинство рядовых кодеров). И тут случается взаимное несоответствие ожиданий реальности. Которое в текущей ситуации парализует рынок при наличии как спроса, так и предложения.
Надо понимать что иногда нужно найти кандидата, а иногда нужно искать кандидата.
я один раз так сделал, когда директор по hr ушла в отпуск - взял кандидата, толкового инженера, которого она упорно отшивала как не имеющего опыта по профильной должности. Ничего, и кандидат себя оправдал и директор понял, простил и поощрил.
Просто тимлидировать и рекрутировать это две разные компетенции, не всегда сосуществующие в одном человеке. Поэтому что для компании важнее, той компетенции она и должна (в идеале) отдавать предпочтение. И не спрашивать по другой как по само собой разумеющейся.
Позвольте дополнить ваш тезис, коллега, подсократив множество не попадающих в вашу экстраполяцию вариантов: не могу припомнить специалиста по дорочильным вопросам, который хорошо решал бы прикладные задачи. Более того, я совершенно точно не встречал ни одного дрочилу, который решал бы такие задачи однозначно лучше или хотя бы сопоставимо относительно прикладных специалистов.
Если сэкстраполировать данный тезис консолидированно с вашим, то, боюсь, у нас вовсе не останется иного варианта, кроме как сделать статистически обоснованный вывод о том, что степень задрачивания базой В БОЛЬШИНСТВЕ СВОЕМ обратно пропорциональна прикладной полезности специалиста.
Который в общем то можно вывести аналитически, а не статистически: направление умственного ресурса на прикладные задачи освобождает эти ресурсы с поддержки "базы", ненужной для решения этих задач, и чем больше ресурсов будет выделено, тем лучше будут решаться эти задачи и, следовательно, тем меньше будет владение базой (по крайней мере, оперативное). И наоборот.
А уже отсюда, позвольте в силу профдеформации позанудствовать, можно сделать уже следующий вывод: наблюдаемый систематический рост такого подхода в найме свидетельствует как о наблюдаемой общей деградации ИТ-индустрии, как минимум, в стране, так и о неизбежном ускорении этой деградации в ближайшем будущем. Причина такого вывода очевидна: поскольку результат такого подхода в виде перебоев в разработке не приводит к его смене, значит топменеджмент такой подход и, следовательно, перебои, устраивает. Причем систематически, массово. А причиной этого, в свою очередь, может являться только одно: падает востребованность продукта индустрии в экономике. Высокие темы держатся на инерции но привод уже отключился. Далее инерция приведет к переизбытку предложения и случится кризис, если ситуация в идустрии не изменится.
Моя личная гипотеза причин подобного в том, что индустрия начала поедать сама себя, продукт начал создаваться ради продукта, цели начали выдумываться за неимением объективно стоящих, и под этим самокопирующемся шлаком хоронятся немногочисленные (на общем фоне) действительно востребованные решения. Так что, коллега, опасаюсь что эпоха когда программисты будут как бухгалтеры в начале 2000-х, уже не за горами.
Чтобы ответить на вопрос, нужна ли экранизация или нет, нужно сначала ответить на вопрос, какую цель преследует экранизация. Судя по содержанию статьи, цель - донести идеи, заложенные в книге, до широкого зрителя. А не, например, коммерция или творческий зуд.
Есть нюанс. Даже здесь, в комментариях, видно, что идеи книги совершенно по разному воспринимаются в разных головах. Одни видят в ней решение выхода из цивилизационного тупика. Другие обличение социалистического строя. Третьи утопический бред. И это все с одного материала, поданного гениальным писателем. Понятно что многое в восприятии зависит от собственных тараканов, однако убедительность формы подачи материала определяет силу влияния продукта на этих тараканов. А вы, если я правильно догадываюсь, хотите не только идею книги транслировать, а еще и свое восприятие этой идеи. Причем современному жителю, воспитанному обществом потребления. Причем, как я подозреваю, молодому поколению. И, вероятно, его неглупому сегменту, которые вдобавок неудовлетворены окружающей действительностью и формирование мировоззрения которых еще в процессе.
В таком случае боюсь шансов испортить дело больше, чем сделать. Потому что, в отличие от фанатов ЧБ, которым доказывать и показывать ничего не надо, у этих ребят есть огромный спектр информационных потоков разных форматов, от тиктока до лекций Семина в ютубе, в котором ваше произведение будет лишь одним из. И чтобы достичь цели и показать что именно эта идея, а не какая другая, сработает, вам надо, во первых, математически знать это самим. Во вторых, быстро и ярко, на фоне остального, ее показать. А в третьих, уже, собственно, ее рассказать. Для этого сюжет должен быть максимально сжатым, логичным, непротиворечивым, динамичным и насколько возможно простым, а выводы из него - очевидны, чтобы зритель сам увидел идею, а не с ваших слов. И вот только после выполнения этих условий уже собственно формат продукта: 2Д мульт, 3Д-мульт, рисованный мульт, кино. Причем форма передачи материала, желательно, не должна отставать по качеству содержанию. Причем это не обязательно должно быть сложно, дорого и спецэффектно, может чтонибудь простое, условные симпсоны или южный парк, главное чтобы гармонировало с содержанием и темпом. Ну и чтобы темп с содержанием тоже гармонироал конечно.
Соответственно, вам нужно всего лишь найти гениального сценариста, гениального режиссера и дизайнера.
Под такой результат экранизировать нужно. Под другой - нельзя.
Я собственными глазами видел, как заказы покупателей и заказы на производство немаленького завода велись в редмайне а-ля ERP, причем на одном учетном уровне а иногда как одно целое, так что закупки через жиру не самое удивительное что бывает.
Ну раз специализированного софта нет, то оно и к лучшему. У большинства подобных изделий к сожалению либо функционал урезан, либо интерфейс чудовищен. Запилить под себя, тем более когда все первичные данные для построения уже есть и оперативно вводятся кодерами и проектменеджерами, не великая проблема.