Что-то вот всё пишут и пишут про ИИ, про микрокоманды и солоразработчиков, а у кого не спросишь, так везде отделы разработки по куче человек, с разработчиками, аналитиками, тестерами и продуктами, а ИИ максимум модельки и тесты генерит.
Как человек, поработавший и аналитиком, и разработчиком, и руководителем таковых, могу сказать, что это реальность. И вот вам целую статью ещё человек написал для подтверждения.
"вот мы действительно работаем, а они ничего не делают" тут начисто отсутствует. У аналитиков есть своя зона ответственности и ее надо закрывать. Я говорю лишь о том, что порог вхождения, требования к аналитиками и уровень сложности их задач - одни из самых низких в индустрии, но при этом, оплачиваются аналитики +- как разрабы или девопсы, которым для работы требуется гораздо больше вложений в свои навыки.
Я не знаю, хорошо это или плохо, это просто факт. Таков сегодняшний рынок труда.
То, что бывают разработчики, которые в принципе не могут базовые вещи освоить и аналитики, которые прекрасно разбираются в современных технологиях я тоже не отрицаю. Но это скорее исключения из правил.
Вы очень сильно недооцениваете степень понимания разработчиками общей картины. Если у вас разработчик не может перед тем как начать читать документацию к api понять, что конкретно ему надо сделать, чтобы разобраться, сможет ли он это сделать с помощью этого api, и не может объяснить, почему этого сделать нельзя, то это не очень хороший разработчик. А аналитик, который видит картину целиком и может ещё и пояснить за шероховатости при разработке, потому что понимает концепции распределенных систем, особенности работы разных баз данных, или, хотя бы, принципы, которых вы придерживаетесь при разработке вашей системы - это та самая иголка в стоге сена.
Помимо этого, вы не улавливаете основную мысль.
Я не говорю, что аналитики не нужны. У них есть свои задачи, которые тоже надо выполнять. Я говорю, что в своем большинстве, это низкоквалифицированный труд за большие деньги.
Ну, если прям этим заняться то и год перебор, но это, обычно второстепенный вопрос, поэтому его все откладывают. Тут может не очень корректное сравнение привел
Ведь, на самом деле, разработчики у нас не умеют фильтровать откровенный бред, читать документацию с api и проектировать системы, они вообще не понимают, что они делают, они просто пишут этот ваш код так, как им сказано. А вот БА и СА с их упорами на "софт скилы" проектируют такие замечательные интеграции, никогда не приносят полный бред в требованиях и ещё и могут заполнять документацию. Вот только код и не умеют писать, а так вообще были бы золотые люди.
Вы сравниваете фрезеровщиков с программистами, а инженеров с аналитиками, но если уходить в вашу аналогию, то фрезеровщик или токарь - это джуны программисты, а инженер - это опытный и обученный программист или архитектор. Не может человек, который не понимает для чего нужны все станки быть инженером. Зато может инвентаризацию проводить.
В целом, вы говорите о не очень хороших программистах и тех самых иголках в стоге сена аналитиках. Но ситуация на рынке такая, что аналитиков, которые вообще не понимают как ИТ системы работают и непонятно зачем вообще они нужны - 99% всех кандидатов. А программистов, которые могут только код писать по указке и не знают ничего про брокеры, базы данных и паттерны проектирования гораздо меньше.
Да собственно, это и есть существующая реальность. Аналитик, хоть бизнес, хоть системный - это низкоквалифицированных труд за большие деньги.
Вот эти вопросы, что перечислены в статье - это и есть актуальный максимум знаний, который надо иметь. Иногда к ним примешивается предметная область. Ну и сравните, какой уровень знаний вам нужен, чтобы ответить на вопрос "что такое бизнес требования?" и какой при ответе на вопрос "как работает garbage collector в .net/java/go?". Чтобы разобраться во всех используемых аббревиатурах типа BPMN, UML и их аналогах вам понадобится пара дней, чтобы разобраться в основных протоколах стека TCP/IP у некоторых уходят годы.
По факту, 90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают. В лучшем случае, заполняют проектную документацию.
Естественно, бывают исключения, но это как иголка в стороне сена.
Можно спросить, как на основе неоднозначных и субъективных критериев, состав которых тоже неоднозначен и субъективен, оценивать уровень того, для чего даже не существует однозначного определения, а, самое главное, зачем это делать?
Это как тест "кто ты из вселенной властелина колец по нашему мнению", только там хотя бы варианты ответов есть, а тут их ещё и самому придумывать надо.
Я бывал в командах телеком операторов и вы больше похожи на их представителей, говорящих о том, что командам сложно о чем-то договориться из-за большого количества желающих что-то сделать.
По честному, все, что мы делаем сводится к зарабатыванию денег компанией. Естественно, вы можете только с определенной долей вероятности предположить, что и когда надо делать, чтобы принести компании больше денег, дорабатывать функционал, предотвращать риски информационной безопасности или развивать бренд продукта. И, вот, когда вы проанализировали факты и учли риски, вы, как менеджер, которому доверен столь дорогой ресурс как "команда", принимаете решение и выставляете команде приоритеты. За что потом и несете ответственность.
Собственно, а почему вы решили, что закон Хофштадтера надо соблюдать?! Что, никогда не попадали в сроки?!
Обычно, если команда действительно хорошо управляется и действительно компетентна, то проблем с тем, чтобы выполнить конкретную задачу за определенный командой срок не возникает, если только не сыграют какие-либо риски, видеть, прогнозировать и учитывать которые должен господин компетентный эффективный менеджер. Обычно, отсутствие оных и является причиной сорванных сроков, а задачи оценивать мы вроде и так все умеем.
Укрупненно, выберу то, что принесет компании больше денег.
Чуть менее укрупненно, получу ответы на обозначенные выше вопросы и сам решу, что для компании будет полезнее. Или пойду к тому, кто уполномочен для принятия таких решений.
Даже интересно, каким образом количество стейкхолдеров, чем они руководят, сколько задач в бэклоге и какая у вас архитектура влияет на то, как вы принимаете решение?!
Потому что, обычно, это должно влиять на то какие вы принимаете решения.
Нет, руководствуясь интуицией это делали только те, кто не совсем понимал что, зачем и как делает.
Если вы знаете ответы на эти вопросы, и на вопрос "что будет, если вы это не сделаете?" то вашему эффективному менеджеру не составит труда проанализировать эти ответы, сопоставить их с текущим контекстом вашей работы и понять ценность того или иного действия. Собственно, это и есть приоритет. И от сложности проекта или команды это не зависит.
Я не знаю как у вас, по моему опыту, все, кто хоть немного умели руководить и нести ответственность за свое руководство делали это за секунды. Все остальные пользовались методиками с придуманными цифрами и аббревиатурами.
Эх, как же мы жили и расставляли приоритеты до изобретения таких замечательных методик?! Хорошо, что настоящие эффективные менеджеры в айти наконец-то взялись за дело и напридумывали столько всего полезного, простого и понятного, чтобы решать такие невероятно сложные задачи как "расстановка приоритетов".
Я как барабанщик любитель не могу не согласиться со всем, кроме того, что, мне сдается, что максимально достижимый результат - это более-менее приемлимый, т.е., как заметил товарищ экспертный слушатель выше, "сыгранный чисто механически по нотам".
Но, как бэ, суть-то именно в том, что люди не играют "механически". Как раз таки множество технических, ритмических и динамических ньюансов и делает игру живой и слушабельной. И учесть все эти нюансы такие модели, скорее всего, не смогут. Причем, на любом инструменте.
Вы, определенно, не разбираетесь в музыке. То, что вы сейчас говорите, это примерно как заявить, что ИИ уже научился рисовать как живой художник. Или писать код как живой программист.
Да собственно, 90% эффективноменеджерской литературы это вода и истории конкретных людей с конкретными возможностями в конкретных ситуациях. Может, автор считает, что тимлиды любят плавать?!)
Что-то вот всё пишут и пишут про ИИ, про микрокоманды и солоразработчиков, а у кого не спросишь, так везде отделы разработки по куче человек, с разработчиками, аналитиками, тестерами и продуктами, а ИИ максимум модельки и тесты генерит.
А вот чуть выше человек уже ответил на этот вопрос
Конечно же, условия диктует рынок труда и да, он такой, как вы описали. Поэтому товарищи аналитики столько и стоят.
Собственно, я с этим и не спорю. Просто вы говорите о причине, я говорю о следствии.
По большому счету, вся ветка началась потому что человек удивился простоте представленных вопросов на собеседовании)
Как человек, поработавший и аналитиком, и разработчиком, и руководителем таковых, могу сказать, что это реальность. И вот вам целую статью ещё человек написал для подтверждения.
"вот мы действительно работаем, а они ничего не делают" тут начисто отсутствует. У аналитиков есть своя зона ответственности и ее надо закрывать. Я говорю лишь о том, что порог вхождения, требования к аналитиками и уровень сложности их задач - одни из самых низких в индустрии, но при этом, оплачиваются аналитики +- как разрабы или девопсы, которым для работы требуется гораздо больше вложений в свои навыки.
Я не знаю, хорошо это или плохо, это просто факт. Таков сегодняшний рынок труда.
То, что бывают разработчики, которые в принципе не могут базовые вещи освоить и аналитики, которые прекрасно разбираются в современных технологиях я тоже не отрицаю. Но это скорее исключения из правил.
Вы очень сильно недооцениваете степень понимания разработчиками общей картины. Если у вас разработчик не может перед тем как начать читать документацию к api понять, что конкретно ему надо сделать, чтобы разобраться, сможет ли он это сделать с помощью этого api, и не может объяснить, почему этого сделать нельзя, то это не очень хороший разработчик. А аналитик, который видит картину целиком и может ещё и пояснить за шероховатости при разработке, потому что понимает концепции распределенных систем, особенности работы разных баз данных, или, хотя бы, принципы, которых вы придерживаетесь при разработке вашей системы - это та самая иголка в стоге сена.
Помимо этого, вы не улавливаете основную мысль.
Я не говорю, что аналитики не нужны. У них есть свои задачи, которые тоже надо выполнять. Я говорю, что в своем большинстве, это низкоквалифицированный труд за большие деньги.
Ну, если прям этим заняться то и год перебор, но это, обычно второстепенный вопрос, поэтому его все откладывают. Тут может не очень корректное сравнение привел
Да уж, очень поверхностно.
Ведь, на самом деле, разработчики у нас не умеют фильтровать откровенный бред, читать документацию с api и проектировать системы, они вообще не понимают, что они делают, они просто пишут этот ваш код так, как им сказано. А вот БА и СА с их упорами на "софт скилы" проектируют такие замечательные интеграции, никогда не приносят полный бред в требованиях и ещё и могут заполнять документацию. Вот только код и не умеют писать, а так вообще были бы золотые люди.
Вы сравниваете фрезеровщиков с программистами, а инженеров с аналитиками, но если уходить в вашу аналогию, то фрезеровщик или токарь - это джуны программисты, а инженер - это опытный и обученный программист или архитектор. Не может человек, который не понимает для чего нужны все станки быть инженером. Зато может инвентаризацию проводить.
В целом, вы говорите о не очень хороших программистах и тех самых иголках в стоге сена аналитиках. Но ситуация на рынке такая, что аналитиков, которые вообще не понимают как ИТ системы работают и непонятно зачем вообще они нужны - 99% всех кандидатов. А программистов, которые могут только код писать по указке и не знают ничего про брокеры, базы данных и паттерны проектирования гораздо меньше.
Да собственно, это и есть существующая реальность. Аналитик, хоть бизнес, хоть системный - это низкоквалифицированных труд за большие деньги.
Вот эти вопросы, что перечислены в статье - это и есть актуальный максимум знаний, который надо иметь. Иногда к ним примешивается предметная область. Ну и сравните, какой уровень знаний вам нужен, чтобы ответить на вопрос "что такое бизнес требования?" и какой при ответе на вопрос "как работает garbage collector в .net/java/go?". Чтобы разобраться во всех используемых аббревиатурах типа BPMN, UML и их аналогах вам понадобится пара дней, чтобы разобраться в основных протоколах стека TCP/IP у некоторых уходят годы.
По факту, 90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают. В лучшем случае, заполняют проектную документацию.
Естественно, бывают исключения, но это как иголка в стороне сена.
Можно спросить, как на основе неоднозначных и субъективных критериев, состав которых тоже неоднозначен и субъективен, оценивать уровень того, для чего даже не существует однозначного определения, а, самое главное, зачем это делать?
Это как тест "кто ты из вселенной властелина колец по нашему мнению", только там хотя бы варианты ответов есть, а тут их ещё и самому придумывать надо.
Я бывал в командах телеком операторов и вы больше похожи на их представителей, говорящих о том, что командам сложно о чем-то договориться из-за большого количества желающих что-то сделать.
По честному, все, что мы делаем сводится к зарабатыванию денег компанией. Естественно, вы можете только с определенной долей вероятности предположить, что и когда надо делать, чтобы принести компании больше денег, дорабатывать функционал, предотвращать риски информационной безопасности или развивать бренд продукта. И, вот, когда вы проанализировали факты и учли риски, вы, как менеджер, которому доверен столь дорогой ресурс как "команда", принимаете решение и выставляете команде приоритеты. За что потом и несете ответственность.
В народе это называется субординация.
Собственно, а почему вы решили, что закон Хофштадтера надо соблюдать?! Что, никогда не попадали в сроки?!
Обычно, если команда действительно хорошо управляется и действительно компетентна, то проблем с тем, чтобы выполнить конкретную задачу за определенный командой срок не возникает, если только не сыграют какие-либо риски, видеть, прогнозировать и учитывать которые должен господин компетентный эффективный менеджер. Обычно, отсутствие оных и является причиной сорванных сроков, а задачи оценивать мы вроде и так все умеем.
Укрупненно, выберу то, что принесет компании больше денег.
Чуть менее укрупненно, получу ответы на обозначенные выше вопросы и сам решу, что для компании будет полезнее. Или пойду к тому, кто уполномочен для принятия таких решений.
Даже интересно, каким образом количество стейкхолдеров, чем они руководят, сколько задач в бэклоге и какая у вас архитектура влияет на то, как вы принимаете решение?!
Потому что, обычно, это должно влиять на то какие вы принимаете решения.
Нет, руководствуясь интуицией это делали только те, кто не совсем понимал что, зачем и как делает.
Если вы знаете ответы на эти вопросы, и на вопрос "что будет, если вы это не сделаете?" то вашему эффективному менеджеру не составит труда проанализировать эти ответы, сопоставить их с текущим контекстом вашей работы и понять ценность того или иного действия. Собственно, это и есть приоритет. И от сложности проекта или команды это не зависит.
Я не знаю как у вас, по моему опыту, все, кто хоть немного умели руководить и нести ответственность за свое руководство делали это за секунды. Все остальные пользовались методиками с придуманными цифрами и аббревиатурами.
Эх, как же мы жили и расставляли приоритеты до изобретения таких замечательных методик?! Хорошо, что настоящие эффективные менеджеры в айти наконец-то взялись за дело и напридумывали столько всего полезного, простого и понятного, чтобы решать такие невероятно сложные задачи как "расстановка приоритетов".
Можно ещё методику как стикеры на доску клеить?
Кажется, кто-то настроил команду ИИ агентов писать статьи на хабре.
Я как барабанщик любитель не могу не согласиться со всем, кроме того, что, мне сдается, что максимально достижимый результат - это более-менее приемлимый, т.е., как заметил товарищ экспертный слушатель выше, "сыгранный чисто механически по нотам".
Но, как бэ, суть-то именно в том, что люди не играют "механически". Как раз таки множество технических, ритмических и динамических ньюансов и делает игру живой и слушабельной. И учесть все эти нюансы такие модели, скорее всего, не смогут. Причем, на любом инструменте.
Вы, определенно, не разбираетесь в музыке. То, что вы сейчас говорите, это примерно как заявить, что ИИ уже научился рисовать как живой художник. Или писать код как живой программист.
Да собственно, 90% эффективноменеджерской литературы это вода и истории конкретных людей с конкретными возможностями в конкретных ситуациях. Может, автор считает, что тимлиды любят плавать?!)