Был один опыт, решение было скорее вынужденным + архитектурное требованте заказчика , так как встраивали свои модули (Angular) в легаси приложение (JSF). Использовали iframe.
Из нюансов:
Надо было шарить токен сессии
Был определенный затык с общими страницами для 404, 5xx, но больше связанно с особенностями CI/CD
И явно сразу не продумали навигацию, когда пользователь нажимает "back"
Зачем нужна логика? Вообще странный вопрос. От програмиста помимо знаний требуется их примение. И применение - это часто логика, умение написать псевдо-код и т.д. Знания в какой-то степени вторичны. Человек может багально не знать, как называется тот или иной паттерн, просто потому что он к нему уже давно пришел, но ему в руки не попалась книжка, где кто-то безусловно умный его описал. И то, как кандидат показывает свое мышление, является очень важным. Потому что этому нельзя быстро научить.
В резюме ... на самом деле важно чаще не споавочное знание фреймворка, а понимание его концепции и целей. Так как понимание зачем и как позволит человеку найти то, что там просто должно быть, но он забыл как оно называется. Или даже никто не испольщовал, но точно знает, что оно там есть. А есть такой забавный прикол, что концептуально многое придумано очень давно :) И всегда интересео насколько человек глубоко погрузился в вопрос от уровня могу найти пример в инете и скопировать себе
Про совок. Про "винтики" - это именно оттуда. Тут не с чем спорить :) Про остальное ... надо понимать цель общения. Если "аккаунт" общается с спонсором со стороны заказчика, чтгбы понять возможный бюджет, win- price и другую подноготную, там технарь не нужен :) Особенно если "аккаунт" - SME. Но если дискуссия уже дошла точки, когда есть что предложить потенциальному заказчику, рассказать о преймуществах платформы - то тут вполне может выступить архитектор, и даже было бы неплохо, чтобы он это озвучил и показал на своих слайдах.
Если задача обсудить статус проекта, то тех. лид вполне может быть, чтобы дать экспертный комментарий по техническому вопросу, оценить вариант решения проектной проблемы технически и т.д. Но его может и не быть, если ПМ способен закрыть вопрлс сам, а то что нет - запишет и потом уточнит у команды
Если задача "снять требования", присутствие архитектора очень желательно, а снятие нефункциональных требований - это вообще его хлеб
Что касается "рядовых" технарей? А с кем им общаться? Не, ну правда? Как ты это себе видишь? Разраб будет въезжать в процессы заказчика, собирать представителей разных подразделений, чтобы свести их в одну точку и выработать единое представление, сидеть над планом проекта и потом под него выбивать ресурсы. Каждый на своем месте. И этот прдход с раздедением есть везде, где проекты реализуются командой
Во-первых не ошибается тот, кто ничего не делает :) Я меня куча лаж как личных, так и командный. Есть такая забавная, как забыл открыть один сетевой доступ, что вскрылось при установке системы. Дело было вечером и наверное можно было решить вопрос через "телефон", но тогда в проде не были закрыты ssh-тунели и тем, что было доступно - прокрутил дырку.
Были и связанные с деньгами, к примеру, первая версия системы, написанной внешним подрядчиком был не очень с точки зрения ее конфигурабельности, и сев собместно со всеми участниками, с усетом полученного опыта описали ТЗ к веосии два и согласовали на Правлении ChR на доп. деньги. Короче, было не мало
Но это лирика. Вопрос в том, что пока от тебя "на столе" мнение, что вот ты пойди и почитай, и поймешь как они важны :) Ну этого маловато :) Просто если речь идеть о разговоре двух профессионалов, каждому не сложно найти пример из дичного опыта и на нем показать, что данные книги бы очень помогли и до того этого никто не знал :)
Если же примеров нет, а в сухом остатке "а ты пойди и почитай", то сразу закрадывается подозрение, что кто-то один в дискуссии не очень то и в теме, как практик и теоретик :)
Вот давай я помогу. Упомянут кейс "упал прод". Да, бывает. Вот чего такого есть в этих книгах, чтобы этот риск еще более минимизировать? Я ж готов обсудить. Но давай предметно. Вот прод. Он предмет "простой". Что мне даст книга(и), чтобы он стал падать меньше? И желательно то, чего не было известно или систематизировано до написания книг.
Я могу даже дать свои примеры:
Прод лег на увеличенной нагрузке. Причина проста - узкое место обработки сообщениц в коде. Решилось заплаткой. Хотя тут падения как такого-го небыло, была знаяимая деградация
Упал network core инфраструктуры заказчика. Легко понятно все, и наше решение в том числе.
Система ушла в 100% CPU. Проблема оказалась в кривом коде, который выбирал "последние" три транзакции, помле локалищации и люлей поставшику проблема бвда закрыта заплаткой
Систему подожили установкой обновновлений. Два раза. Главный менеджер проекта посчитал, что люди, которые занимаются релиз менеджментом просто списывают на его бюджет лишние часы и он сам справится. Ну, все в итоге посмотрели. Главный менеджер возможно понял, что релиз менеджмент - это не только красивые слова, но и много работы :) А может и нет, но сам он уже рутить в этой части не пробовал
Чуть-чуть кашеобразная статья, наверное от недостатка опыта.
Ответ на вопрос почему, как мне кажется довольно простой. Народ из HR модет реально помогать на собеседовании опытом. Банально оценивая кандидита как человека, его опыт, компании где работал. Проще говоря, выявляя неадекватов либо потенцальные проблемы в soft-скилах. Но это если есть опыт, так как через HR проходят и увольнения, и другие сложые кейсы. Если опыта у HR нет, а это никогда не понятно - то польза от них сомнительна.
Тех. спецы не проходят курсы по подбору персонала, они часто и менеджерами в прямом смысле не являются, поэтому ожидать от них вменяемого интервью тоже сложно. Поэтому тех. спец оценивает только уровень знаний и умений.
Понятно ращные люди собеседуют по разному и закон больших чисел говорит о том, что любое извращение обязательно где-то происходит, возможно прямо сейчас. Поэтому я продусь по некоторым моментам
"С другой стороны, можно примерно догадываться о том, какие вопросы задают на технических собеседованиях по многочисленным роликам и шпаргалкам." - можно идти от опыта кандидата. Спрашивать не то, что надо тебе (обычно какое-то пересечение уже есть, так как резюме проходят фильтрацию), а то, что кандидат считает, что знает хорошо. Начать с просьбы рассказать об опыте, обязательно "давить" на то, что знаешь лично и вот где-то тут начать "мучить" техникой. Почему сделали так,а что если внесем доп. требование и как вы поменяете решение. Шпаргалка вряд ли поможет, так как больше идет живоц диалог и обмен мнениями.
"На какого лешего, простите мой французский, ему уметь решать задачки из лабораторной по программированию?" - интересно посмотреть на способность решать логические задачи. Иногда на собеседованиях спрашивают просто задачи на логику.
"Вы как будто не понимаете, что так называемые софт скилы куда важнее опыта использования всех известных элементов фреймворков? " - как технарь, я оцениваю техническую сторону в первую очередь. Это то, что не проверят остальные. Поэтому я делаю свою часть работы, а потом интересуюсь тем, где меня могут подстраховать другие. Плюс часто надо понять, человек реально чего-то знает, либо копипастил не парясь.
"Там человек - это ресурс, шестерня, винтик - там реально никого не интересует умеешь ли ты в коммуникации." - на самом деле, "винтик" - это классический совковый подход. На "западе" куда больше смотрят на софт скилы
Почитал. Наверное статья полезна для человека, который делает отчеты. В целом написаны разумные вещи, но они довольно таки банальны и подойдут почти любому человеку, незвисимо от его роли.
Для соответствия статьи заголовку, а именно развития культуры принятия решений, надо идти наверх. Культура компании транслируется сверху вниз и главные решения принимаются наверху. Даже если ваш отчет будет полезен такому же "винтику" в организации, это никак не поможет выйти на уровень правления. Поэтому вряд ли такой подход изменит культуру.
Но он может сделать отчеты более качественными, хотя у меня сложилось ощущение, что большинство отчетов довольно таки примитивны, и базируются, условно, на одном-двух источниках данных. Что вряд ли сильно повышает ценность BI-отдела
По человечеству. Большинство стран закончило индустриализацию 2-3 столетия назад. Т.е. арзитекторы/инженеры в большом количестве появились не 100 лет. Так как это было массовое явление, я не думаю, что наши предки (хотя тут да, индустриализация и пост совок прошли меньше 100 лет назад) были такими тупыми, что каждый раз изобретали велосипед :) Строя очередной завод или корабль (как вершину технологического прогресса)
Прораб и капитан корабля точно сможет :) Не сразу конечно, но по менеджерским скиллам эти люди на голову выше любого тимлида :) Особенно вторые. Все таки надо понимать, что тимлид всегда может пойти домой, а корабль еще туда надо привести.
Я бы был благодарен за конкретику :) Т.е. вот например в части, что не работает из того, что было раньше. И желательно из современного, так как очевидно что некоторые методы мотивации из истории сейчас банально наказуемы.
Просто, как большой практик, хочется обсуждать более предметно. И да, надо понимать, что современная армия и стройка тоже не такие, как к примеру, армия совка. Не очень убедительно выходит, если есть какие-то книжки без которых никак, а все равно как-то получилось и неплохо. И ведь не только у меня. Противоречие.
Просто ... я поясню следующим образом. Человечество давно, я б оценил в несколько тысячелетий, научилось:
Собирать людей в команды и достигать общего результата
Понимать требования заказчика
Вкладываться в бюджет и сроки
Нанимать и увольнять людей
...
Т.е это все изобретено еще до Тьюринга, Геделя, ... и даже до Аристотеля. Эти навыки ничем особенным не являются. Поэтому назвать что либо "классическим", написанное условно вчера про то, что человечество знает тысячелетиями как-то самонадеяно. Даже что-то "новое", что пришло в ИТ (я лет 13 назад застал приход Agile в большую организацию, это было весело), на самом деле оно совсем не новое :). Поэтому в реале все намного проще. Если вы хотите выбрать кого повысить до тим лида - выберите самого "взрослого" и ответственного. И почти не ошибетесь. Если к примеру вы построили дом, нанимая бригады, отдельных людей, закупали строй материалы, ругались, торговались, требовали все исправить и переделать ... то справитесь и с командой :). Потому что разницы нет :)
А книжка - это просто нечто, что может помочь систематизировать знания и опыт, но научить условного ной-лайфера как общаться с клиентом - не :)
Да все проще. Мир многогранен и на любой объект можно посмотреть с многих ракурсов. К примеру, у Java-програмиста все есть обьект, у менеджера проектов - любая активность проект и т.д.
Это интересно, об этом можно порассуждать за пивом.
Но в момент, когда субъект соверщает действие над объектом, все это многобразие схопывается до того единственного восприятия, либо конечного и небольшого списка, который есть в мозгу у субъекта :)
Если мы возьмем в качестве обстрактного субъекта сферического програмиста, а в качестве объекта програмный код - там будет исчезающе малая величина гуманитарной составляющей.
Но людям, далеких от того типа связей, может показаться, что там этого много. Но так как на код обычно смотрят именно програмисты, то взгляд филолога носит исключительно абстрактный характер :)
И я даже могу допустить, что сферическмй филолог думает по другому :)
Это скилл сет, который требуется на позицию. Люди не роботы, и почти всем, кто видиь других людей и как-то общаеься с ними, нужны soft skills. Но это никак не делает архитектора психологом или, ну не знаю, лингвистом. Ну бред. Я говорю/пишу, просто в жизни? Я гуманитарий, потому что использую язык?
Я написал email. Бинго, я гуманитарий, я перенес мои мысли на "бумагу" а другой человек прочитал. Ну маразм же :)
Если я прочитал чужой код - ну я точно гуманитарий так как смог по наскальным письменная предшественника пофиксить его баг
Это навыки коммунакации, котррые человек использует задолго до того, как это стало "наукой" (в глазах некоторых).
К примеру, я делаю презентацию. Я часто это делаю. Я гуманитарий? Чо, правда?
Принимая во внимание популярную оценку стоимости решения, которая говорит, что прибавление одной 9ки приводит к добавлению одного 0 к сумме контракта, хочется заметить, что рекомендации как и чего построить без знания бюджета выглядят не очень корректно
Мне кажется, анкеты и прочее ... этим никто не занимается
Есть полезное упражнение. Ретроспектива. Оно есть в методичках по скраму и т.д. Его можно применять к себе для анализа что и как.
Для адекватного применения:
Надо пытаться слушать, что происходит вокруг и тогда можно узнать, что что-то идет не так
Надо искать причину в себе и пытаться понять, а что я мог слелать, чтобы вышло лучше
Но это никак не связано с описанным эффектом. Он просто констатирует статистически определенные паттерны поведения. Ну и тихонько так говорит "сомневайся и проверяй себя" )
Обычно и на одну компетенуию сложно найти человека, а тут на 5 условно :)
Скорее вы не зрелая компания, и это не обязательно плохо. Скорее хорошо, так как вы растете и вам нужны сейчас "единороги"
Теперь по ролям.
ПМ: по хорошему, этот человек отвечает за бюджет и сроки, а также за то, что результат работы соответствует ожиданиям заказчика/продакта. Да, у него есть много обязанностей и они перечисленны неплохо. Скрам-мастер - я лично считаю, что отдельный человек - это блажь, и возложение этой роли на ПМ - это хорошо. Но по большому счету, так и раньше было, просто многим захотелось попилить денег на консалтинге вокруг модных тогда слов и технологий
Аналитик - странно. Да, бывают ПМ, которые колупаются в требованиях больше необходимого. Это либо от безделья, так как проект и команда небольшие, либо потому что это бывший аналитик, которому забыли напомнить, что он уже не аналитик. ПМ должен в требованиях понимать взаимосвязь, критичность и цену реализации. Первое позволяет планировать и проверять, что все загружены и на ближайший спринт все логично. Второе - выстраивать приоритеты и делать более ценное раньше. Третье - контродировать сроки реализации и иметь аргументы для дискуссии с спонсорами и продуктами
Заниматься постановкой задач команде - да, если реально компания маленькая. Но в таких часто тим лид/архитектор таким занимаются.
Инцедент менеджмент - тут конечно весело. По хорошему, часть этой задачи должна быть унифицирована и централизована в рамках организации, так как это намного дешевле и эффективнее. Плюс все команды будут выравняны по критериям качества и прочему. Читать логи - это уже полный треш. Логи читают разрабы. Они их пишут. Если ему не ясно по логам - тикет на лоб по детализации логов и пендаль :)
На больших курсах - нет. Максимум конкретные тренинги до 5 дней, на конкретную технологию или скилл. Такого было до фига и с горкой
Бвли ли они полезны? Конечно. Они концентрированные, и обычно тебе либо дается хороший толчок, либо систематизация накопленной практики
Более длительные не имеют смысла для компании. Это значит, что изначально взят не тот человек, которого надо просто "вернуть в школу". Т.е. ему надо внести в голову какие-то азы и для этого надо больше времени
Был один опыт, решение было скорее вынужденным + архитектурное требованте заказчика , так как встраивали свои модули (Angular) в легаси приложение (JSF). Использовали iframe.
Из нюансов:
Надо было шарить токен сессии
Был определенный затык с общими страницами для 404, 5xx, но больше связанно с особенностями CI/CD
И явно сразу не продумали навигацию, когда пользователь нажимает "back"
В остальном - нормально
Куратору б еше накинуть процентов 10-20 к за, чтобы был стимул :)
Зачем нужна логика? Вообще странный вопрос. От програмиста помимо знаний требуется их примение. И применение - это часто логика, умение написать псевдо-код и т.д. Знания в какой-то степени вторичны. Человек может багально не знать, как называется тот или иной паттерн, просто потому что он к нему уже давно пришел, но ему в руки не попалась книжка, где кто-то безусловно умный его описал. И то, как кандидат показывает свое мышление, является очень важным. Потому что этому нельзя быстро научить.
В резюме ... на самом деле важно чаще не споавочное знание фреймворка, а понимание его концепции и целей. Так как понимание зачем и как позволит человеку найти то, что там просто должно быть, но он забыл как оно называется. Или даже никто не испольщовал, но точно знает, что оно там есть. А есть такой забавный прикол, что концептуально многое придумано очень давно :) И всегда интересео насколько человек глубоко погрузился в вопрос от уровня могу найти пример в инете и скопировать себе
Про совок. Про "винтики" - это именно оттуда. Тут не с чем спорить :) Про остальное ... надо понимать цель общения. Если "аккаунт" общается с спонсором со стороны заказчика, чтгбы понять возможный бюджет, win- price и другую подноготную, там технарь не нужен :) Особенно если "аккаунт" - SME. Но если дискуссия уже дошла точки, когда есть что предложить потенциальному заказчику, рассказать о преймуществах платформы - то тут вполне может выступить архитектор, и даже было бы неплохо, чтобы он это озвучил и показал на своих слайдах.
Если задача обсудить статус проекта, то тех. лид вполне может быть, чтобы дать экспертный комментарий по техническому вопросу, оценить вариант решения проектной проблемы технически и т.д. Но его может и не быть, если ПМ способен закрыть вопрлс сам, а то что нет - запишет и потом уточнит у команды
Если задача "снять требования", присутствие архитектора очень желательно, а снятие нефункциональных требований - это вообще его хлеб
Что касается "рядовых" технарей? А с кем им общаться? Не, ну правда? Как ты это себе видишь? Разраб будет въезжать в процессы заказчика, собирать представителей разных подразделений, чтобы свести их в одну точку и выработать единое представление, сидеть над планом проекта и потом под него выбивать ресурсы. Каждый на своем месте. И этот прдход с раздедением есть везде, где проекты реализуются командой
Дело в том, что ...
Во-первых не ошибается тот, кто ничего не делает :) Я меня куча лаж как личных, так и командный. Есть такая забавная, как забыл открыть один сетевой доступ, что вскрылось при установке системы. Дело было вечером и наверное можно было решить вопрос через "телефон", но тогда в проде не были закрыты ssh-тунели и тем, что было доступно - прокрутил дырку.
Были и связанные с деньгами, к примеру, первая версия системы, написанной внешним подрядчиком был не очень с точки зрения ее конфигурабельности, и сев собместно со всеми участниками, с усетом полученного опыта описали ТЗ к веосии два и согласовали на Правлении ChR на доп. деньги. Короче, было не мало
Но это лирика. Вопрос в том, что пока от тебя "на столе" мнение, что вот ты пойди и почитай, и поймешь как они важны :) Ну этого маловато :) Просто если речь идеть о разговоре двух профессионалов, каждому не сложно найти пример из дичного опыта и на нем показать, что данные книги бы очень помогли и до того этого никто не знал :)
Если же примеров нет, а в сухом остатке "а ты пойди и почитай", то сразу закрадывается подозрение, что кто-то один в дискуссии не очень то и в теме, как практик и теоретик :)
Вот давай я помогу. Упомянут кейс "упал прод". Да, бывает. Вот чего такого есть в этих книгах, чтобы этот риск еще более минимизировать? Я ж готов обсудить. Но давай предметно. Вот прод. Он предмет "простой". Что мне даст книга(и), чтобы он стал падать меньше? И желательно то, чего не было известно или систематизировано до написания книг.
Я могу даже дать свои примеры:
Прод лег на увеличенной нагрузке. Причина проста - узкое место обработки сообщениц в коде. Решилось заплаткой. Хотя тут падения как такого-го небыло, была знаяимая деградация
Упал network core инфраструктуры заказчика. Легко понятно все, и наше решение в том числе.
Система ушла в 100% CPU. Проблема оказалась в кривом коде, который выбирал "последние" три транзакции, помле локалищации и люлей поставшику проблема бвда закрыта заплаткой
Систему подожили установкой обновновлений. Два раза. Главный менеджер проекта посчитал, что люди, которые занимаются релиз менеджментом просто списывают на его бюджет лишние часы и он сам справится. Ну, все в итоге посмотрели. Главный менеджер возможно понял, что релиз менеджмент - это не только красивые слова, но и много работы :) А может и нет, но сам он уже рутить в этой части не пробовал
Давай?
На самом деле все верно и правда, как в рекламе :)
Чуть-чуть кашеобразная статья, наверное от недостатка опыта.
Ответ на вопрос почему, как мне кажется довольно простой. Народ из HR модет реально помогать на собеседовании опытом. Банально оценивая кандидита как человека, его опыт, компании где работал. Проще говоря, выявляя неадекватов либо потенцальные проблемы в soft-скилах. Но это если есть опыт, так как через HR проходят и увольнения, и другие сложые кейсы. Если опыта у HR нет, а это никогда не понятно - то польза от них сомнительна.
Тех. спецы не проходят курсы по подбору персонала, они часто и менеджерами в прямом смысле не являются, поэтому ожидать от них вменяемого интервью тоже сложно. Поэтому тех. спец оценивает только уровень знаний и умений.
Понятно ращные люди собеседуют по разному и закон больших чисел говорит о том, что любое извращение обязательно где-то происходит, возможно прямо сейчас. Поэтому я продусь по некоторым моментам
"С другой стороны, можно примерно догадываться о том, какие вопросы задают на технических собеседованиях по многочисленным роликам и шпаргалкам." - можно идти от опыта кандидата. Спрашивать не то, что надо тебе (обычно какое-то пересечение уже есть, так как резюме проходят фильтрацию), а то, что кандидат считает, что знает хорошо. Начать с просьбы рассказать об опыте, обязательно "давить" на то, что знаешь лично и вот где-то тут начать "мучить" техникой. Почему сделали так,а что если внесем доп. требование и как вы поменяете решение. Шпаргалка вряд ли поможет, так как больше идет живоц диалог и обмен мнениями.
"На какого лешего, простите мой французский, ему уметь решать задачки из лабораторной по программированию?" - интересно посмотреть на способность решать логические задачи. Иногда на собеседованиях спрашивают просто задачи на логику.
"Вы как будто не понимаете, что так называемые софт скилы куда важнее опыта использования всех известных элементов фреймворков? " - как технарь, я оцениваю техническую сторону в первую очередь. Это то, что не проверят остальные. Поэтому я делаю свою часть работы, а потом интересуюсь тем, где меня могут подстраховать другие. Плюс часто надо понять, человек реально чего-то знает, либо копипастил не парясь.
"Там человек - это ресурс, шестерня, винтик - там реально никого не интересует умеешь ли ты в коммуникации." - на самом деле, "винтик" - это классический совковый подход. На "западе" куда больше смотрят на софт скилы
Почитал. Наверное статья полезна для человека, который делает отчеты. В целом написаны разумные вещи, но они довольно таки банальны и подойдут почти любому человеку, незвисимо от его роли.
Для соответствия статьи заголовку, а именно развития культуры принятия решений, надо идти наверх. Культура компании транслируется сверху вниз и главные решения принимаются наверху. Даже если ваш отчет будет полезен такому же "винтику" в организации, это никак не поможет выйти на уровень правления. Поэтому вряд ли такой подход изменит культуру.
Но он может сделать отчеты более качественными, хотя у меня сложилось ощущение, что большинство отчетов довольно таки примитивны, и базируются, условно, на одном-двух источниках данных. Что вряд ли сильно повышает ценность BI-отдела
По человечеству. Большинство стран закончило индустриализацию 2-3 столетия назад. Т.е. арзитекторы/инженеры в большом количестве появились не 100 лет. Так как это было массовое явление, я не думаю, что наши предки (хотя тут да, индустриализация и пост совок прошли меньше 100 лет назад) были такими тупыми, что каждый раз изобретали велосипед :) Строя очередной завод или корабль (как вершину технологического прогресса)
Прораб и капитан корабля точно сможет :) Не сразу конечно, но по менеджерским скиллам эти люди на голову выше любого тимлида :) Особенно вторые. Все таки надо понимать, что тимлид всегда может пойти домой, а корабль еще туда надо привести.
Я бы был благодарен за конкретику :) Т.е. вот например в части, что не работает из того, что было раньше. И желательно из современного, так как очевидно что некоторые методы мотивации из истории сейчас банально наказуемы.
Просто, как большой практик, хочется обсуждать более предметно. И да, надо понимать, что современная армия и стройка тоже не такие, как к примеру, армия совка. Не очень убедительно выходит, если есть какие-то книжки без которых никак, а все равно как-то получилось и неплохо. И ведь не только у меня. Противоречие.
Возможно :)
Просто ... я поясню следующим образом. Человечество давно, я б оценил в несколько тысячелетий, научилось:
Собирать людей в команды и достигать общего результата
Понимать требования заказчика
Вкладываться в бюджет и сроки
Нанимать и увольнять людей
...
Т.е это все изобретено еще до Тьюринга, Геделя, ... и даже до Аристотеля. Эти навыки ничем особенным не являются. Поэтому назвать что либо "классическим", написанное условно вчера про то, что человечество знает тысячелетиями как-то самонадеяно. Даже что-то "новое", что пришло в ИТ (я лет 13 назад застал приход Agile в большую организацию, это было весело), на самом деле оно совсем не новое :). Поэтому в реале все намного проще. Если вы хотите выбрать кого повысить до тим лида - выберите самого "взрослого" и ответственного. И почти не ошибетесь. Если к примеру вы построили дом, нанимая бригады, отдельных людей, закупали строй материалы, ругались, торговались, требовали все исправить и переделать ... то справитесь и с командой :). Потому что разницы нет :)
А книжка - это просто нечто, что может помочь систематизировать знания и опыт, но научить условного ной-лайфера как общаться с клиентом - не :)
Нет, я не читал :)
Я боюсь, что вас ввели в заблуждение :) Большинство сеньоров/тимлидов/архитекторов эти книги не читало :)
А употребленное словл "классический" ничего кроме улыбки не вызывает
Мне это слово напоминает Кнута и его книги. Это действительно классика :)
Да, но новые роли по прежнему технические :)
QA - чисто техника
DevOps - тож технарь
BA - записывать на чуток в гуманитарии, потому что не прячет нолову в песок при виде клиента? Реально глубоко формализованная работа
PM - тоже, что там гуманитарного? Появление бюджета проекта делает его экономистом?
AR - схемы рисует, в живописцы его?
:)
Можно проще, есть четкие требования к вакансиям. Там нет лингвистов, философов, психологов, ...
Да все проще. Мир многогранен и на любой объект можно посмотреть с многих ракурсов. К примеру, у Java-програмиста все есть обьект, у менеджера проектов - любая активность проект и т.д.
Это интересно, об этом можно порассуждать за пивом.
Но в момент, когда субъект соверщает действие над объектом, все это многобразие схопывается до того единственного восприятия, либо конечного и небольшого списка, который есть в мозгу у субъекта :)
Если мы возьмем в качестве обстрактного субъекта сферического програмиста, а в качестве объекта програмный код - там будет исчезающе малая величина гуманитарной составляющей.
Но людям, далеких от того типа связей, может показаться, что там этого много. Но так как на код обычно смотрят именно програмисты, то взгляд филолога носит исключительно абстрактный характер :)
И я даже могу допустить, что сферическмй филолог думает по другому :)
После chatgpt - уже точно нет :)
Сорян, это уже дно, спрашивать у чат бота
Я чуток знаю ;) Но - это не гуманитарная наука
Это скилл сет, который требуется на позицию. Люди не роботы, и почти всем, кто видиь других людей и как-то общаеься с ними, нужны soft skills. Но это никак не делает архитектора психологом или, ну не знаю, лингвистом. Ну бред. Я говорю/пишу, просто в жизни? Я гуманитарий, потому что использую язык?
Я написал email. Бинго, я гуманитарий, я перенес мои мысли на "бумагу" а другой человек прочитал. Ну маразм же :)
Если я прочитал чужой код - ну я точно гуманитарий так как смог по наскальным письменная предшественника пофиксить его баг
Это навыки коммунакации, котррые человек использует задолго до того, как это стало "наукой" (в глазах некоторых).
К примеру, я делаю презентацию. Я часто это делаю. Я гуманитарий? Чо, правда?
Ну честно, много воды ни о чем :)
Сорри, но либо давая по сути, к примеру берем язык и на примере конкретной задачи ищем гуманитарные корни, либо не натягиваем сову на глобус
Принимая во внимание популярную оценку стоимости решения, которая говорит, что прибавление одной 9ки приводит к добавлению одного 0 к сумме контракта, хочется заметить, что рекомендации как и чего построить без знания бюджета выглядят не очень корректно
Я такого не считаю
Я просто не вижу гуманитарной составляюшей
Давай проще - ты видишь, укажи конкретно :) Слова язык недостаточно, так как это разные семантические смыслы
Мне кажется, анкеты и прочее ... этим никто не занимается
Есть полезное упражнение. Ретроспектива. Оно есть в методичках по скраму и т.д. Его можно применять к себе для анализа что и как.
Для адекватного применения:
Надо пытаться слушать, что происходит вокруг и тогда можно узнать, что что-то идет не так
Надо искать причину в себе и пытаться понять, а что я мог слелать, чтобы вышло лучше
Но это никак не связано с описанным эффектом. Он просто констатирует статистически определенные паттерны поведения. Ну и тихонько так говорит "сомневайся и проверяй себя" )
Обычно и на одну компетенуию сложно найти человека, а тут на 5 условно :)
Скорее вы не зрелая компания, и это не обязательно плохо. Скорее хорошо, так как вы растете и вам нужны сейчас "единороги"
Теперь по ролям.
ПМ: по хорошему, этот человек отвечает за бюджет и сроки, а также за то, что результат работы соответствует ожиданиям заказчика/продакта. Да, у него есть много обязанностей и они перечисленны неплохо. Скрам-мастер - я лично считаю, что отдельный человек - это блажь, и возложение этой роли на ПМ - это хорошо. Но по большому счету, так и раньше было, просто многим захотелось попилить денег на консалтинге вокруг модных тогда слов и технологий
Аналитик - странно. Да, бывают ПМ, которые колупаются в требованиях больше необходимого. Это либо от безделья, так как проект и команда небольшие, либо потому что это бывший аналитик, которому забыли напомнить, что он уже не аналитик. ПМ должен в требованиях понимать взаимосвязь, критичность и цену реализации. Первое позволяет планировать и проверять, что все загружены и на ближайший спринт все логично. Второе - выстраивать приоритеты и делать более ценное раньше. Третье - контродировать сроки реализации и иметь аргументы для дискуссии с спонсорами и продуктами
Заниматься постановкой задач команде - да, если реально компания маленькая. Но в таких часто тим лид/архитектор таким занимаются.
Инцедент менеджмент - тут конечно весело. По хорошему, часть этой задачи должна быть унифицирована и централизована в рамках организации, так как это намного дешевле и эффективнее. Плюс все команды будут выравняны по критериям качества и прочему. Читать логи - это уже полный треш. Логи читают разрабы. Они их пишут. Если ему не ясно по логам - тикет на лоб по детализации логов и пендаль :)
На больших курсах - нет. Максимум конкретные тренинги до 5 дней, на конкретную технологию или скилл. Такого было до фига и с горкой
Бвли ли они полезны? Конечно. Они концентрированные, и обычно тебе либо дается хороший толчок, либо систематизация накопленной практики
Более длительные не имеют смысла для компании. Это значит, что изначально взят не тот человек, которого надо просто "вернуть в школу". Т.е. ему надо внести в голову какие-то азы и для этого надо больше времени