Комментарии 39
Выбешивающая классификация. 90% тех, кто в ИТ, это подтвердят, IMHO.
Тут и классические развешиватели лапши в сторону "бизнеса" в виде непонятной массы аналитиков, и всякие "скрам-мастера". Для полного комплекта не хватает "фаундеров" и стратап-акселераторов.
Миф, о том, что бизнесу реально нужен некий мифический "продукт", который бесконечно жрёт средства, но никогда не решает его задачи, а не готовый инструмент, с небольшой , но эффективной командой поддержки в чистом виде.
Это идеальное представление от паразитов на ниве ИТ. А не реальная картина от армии настоящих тружеников.
"Архитектор данных" где то рядом с тестировщиками, других архитекторов в этот обзор не завезли. Зато завезли Senior- и Middle+. Спасибо авторам, было повеселили.
Я не смог определиться с тем, куда их отнести в рамках парадигмы "разработка - аналитика".
С одной стороны, они моделируют структуру того, что будет разрабатываться, а с другой - учитывают требования заказчика и истинные потребности бизнеса чуть ли не напрямую.
Буду признателен, если меня поправите и тезисно расскажете об иных архитекторах, которых не хватает, а я все дополню:)
Очевидно, что для того чтобы что-то разработать, надо продумать что и как надо разработать. На вопрос "что" отвечают бизнес аналитики в купе с продукт оунером и остальными стейкхолдерами. На вопрос "как" - архитекторы. Если это не вписывается в вашу парадигму, то наверное не самая удачная парадигма. Рассказать в одном абзаце чем занимаются разные архитекторы врядле возможно. Гуглите
Software Architect
Solution Architect
Enterprise Architect
Infrastructure Architect
и дальше по ссылкам. Есть даже роль Business Architect.
В тюрьме 4 основные касты..))
1.3 Профильность (I-shape, T-shape, M-shape, плоские)
Зависимость знаний от ширины области можно представить в виде пирамиды: вершина это специалист который знает все но ни о чем, а основание - кто знает обо всем но ничего.
По количеству слов в описании профессии работа сисадмина, например, выглядит бледно на фоне столь многих букв в описании работы аналитиков разных мастей. Но все равно не понятно, чем они занимаются 8 часов в день, 5 дней в неделю, и так круглый год.
Ни слова о мобильных разработчиках почему-то
2.1 Product Owner
Владелец продукта несёт ответственность за достижение максимальной ценности продукта как результата работы команды. И добивается он этого при помощи Scrum — фреймворка гибкой разработки программного обеспечения.
Вот по этому пункту несколько вопросов возникло.
1.Кто определяет достижение ценности?
2. По каким критериям определяется, что достигнутая ценность максимальна?
3. И в чем заключается ответственность - материальная, административная или какая-то другая?
Пожалуй, так:
Итоговый потребитель продукта - бизнес-заказчик или другой подразделение компании, потому вердикт о достижении/недостижении поставленной задачи ставят они. PO может оценить это, исходя из удовлетворения требований, которые были получены на старте или в процессе.
Скорее здесь имел в виду не максимум как конечное, пиковое значение, а процесс максимизации, что можно оценить, в случае приложения или сайта, по времени отклика, удержанию аудитории, удобству эксплуатации (аля числовой оценке).
Ответственность, конечно, скорее моральная/корпоративная, так сказать. Ибо защита результатов проделанной работы, отчет о трудозатратах конкретной скрам-команды ложится на его плечи. То есть это его работа, его обязанности, с которыми нужно справляться
Я больше как железячник, могу не до конца понимать особенности разработки софта. Вопросы я задал, потому как мне не ясно отличие Продакт Овнера от Проджект Менеджера. В моей области это всегда один человек - Руководитель проекта. Зачастую, он же и Главный конструктор. Почему при разработке софта это разные люди? Какой в этом смысл?
Если обобщить, то на проекте есть технический руководитель - тот кто отвечает за техническую часть проекта. Есть административный руководитель - тот кто отвечает за выделение материальных ресурсов. То есть например, если не работает железо - спрашивают с технического руководителя. Если не были закуплены комплектующие - спрашивают с административного.
Зачем еще кто-то нужен?
Это не совсем специфика софта, скорее некий элемент теоретический, который по методологии Scrum должен присутствовать. По ссылке - переведенное руководство.
Если кратко, то в идеализированном подходе вместе с командой разработки есть несколько человек - Scrum Master и Product Owner. То есть их наличие обусловленно исключительно форматом разработки, принятом в компании, а в "жизни" это иные названия для более привычных спецов - того же Project Manager.
Соответственно, поскольку это все же западные веяния, такая узкая специализация есть их специфика - под каждое дело должен быть свой профильный специалист, а у нас, насколько я вижу, это не закрепилось, потому функционал этих теоретических ролей у других лиц.
Постарался учесть рекомендации, буду признателен, если пробежитесь и скажете, где соврал, а где стало лучше)
Выглядит как какой-то каталог демонов ада😁
Ох уж эти определения разработчиков😄
А ещё сисадмин это человек, который заставляет работать продукт у потребителя после того как проект завершён и разработчики умыли руки.
Сколько же паразитов развелось вокруг программистов, а ведь все они не создают добавленную стоимость, т.к. не пишут программный код. Я не против чтобы они были, но их труд не должен стоить дорого, т.к. в нем мало пользы (их функции легко сможет выполнить сам программист)
Большинство разработчиков неспособны работать даже на маленьких проектах, не имея чётко поставленной задачи в Jira. Уже не говоря об огромных системах, где считанные люди знают как всё устроено с точки зрения бизнеса.
Это как сказать, что для обеспечения населения автомобилями можно убрать все звенья между клиентом и рабочим на заводе.
В целом и один человек сможет сделать все, дело во времени и специализации. Если разработчику придется вникать в смежные области и тратить на ту же отчетность свое время, то.. что-то случится недоброе:)
Верно
Думвю что с увеличением налога на прибыль с 2025 весь этот "налет" ввиде всех этих непонятных должностей, возникший из-за избытка денег, будет постепенно слетать и в компаниях скоро снова будут работать только программисты, как в нулевых
Три самых бесполезных для страны специализации в топе, а реально нужные в дополнительных. В это все российское ИТ.
Ничего не понятно, но очень интересно
ИТ-шники: разновидности, отличительные черты