Рекрутеру говорят «нам нужен ангулярщик» и он его ищет по ключевым словам
Рекрутеру редко говорят «нам нужен ангулярщик, чтобы он еще чуть-чуть в MySQL мог и питонисту иногда помогал, а еще уборщицу
Странно, что тут противоречие. Если человек ценен для работадателя, то это повышает его ценность на рынке труда. (если работодатель не очень особенный).
Не думаю, что смогу вам объяснить наивность ваших фантазий, постепенно сами столкнётесь с масштабированием процесса разработки на своём реальном опыте.
Как жаль что такой опытный, разносторонний и вежливый профессионал как вы не снизошел до объяснения на конкретном примере своей концепции развития компетенций.
Буду надеяться, что мне встретится кто-то другой, кто снизойдет до новичков моего уровня. Или может быть, вы сможете выделить время на то, чтобы написать мемуары о вашем участии в больших проектах? Я понимаю, у вас мало времени, но человечество в моем лице было бы очень благодарно вам. Тем более что это, наверное, менее затратно, чем объяснять чуть дела каждому остолопу, вроде меня. Спасибо большое, что отвечали на мои вопросы, хотя я и понимаю, что ваше терпение не безгранично. Извините, пожалуйста, еще раз за назойливость и еще раз спасибо.
Общий — это один на всех, а не одинаковый. И там обычно на задачи а вот что:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
То есть например PBI может быть "Добавить обработку бесконтактных карт", которая подразумевает "дизайн, реализация и тестирование". Соответственно команда делает PBI внутри себя распределяя задачи.
Скорее всего, спец по БД, если нет задачи по БД, вполне может, например, выполнить задачу по тестированию PBI если есть такой, а тестеры заняты.
Почему? Мне просто чисто практически непонятно — в ситуации когда есть потребность при добавлении галки подправить условно html, js, sql и java, вроде все подталкивает к тому чтобы чисто практически выучить немножко того и немножко сего, чтобы сделать эту галку полностью самостоятельно, а не просить Васю. А чтобы в дополнении в MS SQL учить Оракл, придется откуда-то выдумывать задачу и держать этот Оракл в голове работая с MS SQL (см кривая забывания).
Т.е. с моей точки зрения в практической работы горизонтальная линейка у T весьма органично растет на соседние слои стека, и для менеджера это более ценно (для простых операций не надо накладных расходов для взаимодействия между членами команды, а для сложных — больше взаимопонимания).
Именно поэтому мне интересен опыт такого разностороннего профессионала как вы, как получается, что выгоднее по другому. Именно на этом простом примере.
Я буду благодарен если вы мне объясните здесь или персональными сообщениями. Спасибо за дискуссию в любом случае.
Я не очень понял — вы в стартапе или наемником? Т.е. например команда отвечает за продукт/подсистему X. Надо в продукт добавить галочку в настройки (UI, логику обработки и поле в СУБД) — как это происходило?
Ну я, честно говоря, больше видел специалистов которые изучали смежные по стеку технологии чем по уровню (трудно на досуге очень хорошо изучить Oracle — так как вся практика на MS SQL — принципы можно, но конкретные глюки/приемы/навыки не очень удобно, так как нужно иметь какой-то рабочий пример) я скорее видел специалистов, которые могли знать соседние элементы стека. Или даже поверхностно весь стек и глубоко предметную область.
А если он ковыряется в ASP.NET? Я вот думаю что может быть несколько направлений смежности можно растить горизонтальную палку в направлении разных СУБД (но тогда получается что эта палка будет не использоваться точно в каждом конкретном месте работы кроме некоторых исключений). Можно расти в смежные вещи по стеку. Например в MS-SQL используются другие технологии MS — .NET и Powershell, зная C# можно выучить ASP.NET и уже просто чтобы добавить галочку в форму не надо будет звать фронтэндщика. Знание C# и PS пригодиться и для администрирования IIS. Зная C# можно на другом месте работы выучить Java и т.д.
Если он начнет играть шрифтами и это ему нравится то почему бы нет? Будет способ отдыха. Возможно, ему легче будет понять, как на мир смотрят дизайнеры и это будет источником метафор.
А скрам именно о такой (утрирую) переносимости знаний, когда каждый специалист является компетентным во всём стеке технологий разрабатываемого продукта.
Не затруднит ли это подтвердить цитатой из скрам гайд?
— Мы думали туман, — ответила Ирма.
— Что?
— Думали туман, — повторила Ирма.
— Про туман, — поправил Виктор. — Или о тумане.
— Зачем это — про туман? — сказала Ирма.
— Думать — непереходный глагол, — объяснил Виктор. — Он требует
предлогов. Вы проходили непереходные глаголы?
— Это когда как, — сказала Ирма. — Думать туман — это одно, а думать
про туман — это совсем другое… и кому это нужно — думать про туман,
неизвестно.
Виктор вытащил сигарету и закурил.
— Погоди, — сказал он. — Думать туман — так не говорят, это
неграмотно. Есть такие глаголы — непереходные: думать, бегать, ходить. Они
всегда требуют предлога. Ходить по улице. Думать про… что-нибудь там…
Я не разбираюсь в этих технологиях, так что не могу прокомментировать детально. Я думаю, что некоторые знания переносимы — т.е. если человек в принципе знает реляционные базы и веб разработку, то он может быстрее приспособиться к конкретной реляционной базе и конкретному фреймворку. Т.е. нельзя знать только MySQL, если узнаешь MySQL ты узнаешь так же про реляционные базы вообще, индексы, SQL латентность и прочее.
Если он на досуге поучит NoSQL он сможет применить знания и в том и в этом стартапе и владеть большим количеством технических решений — т.е. большее чувство собственности.
Потому что размазанные в одном стартапе компетенции в другом уже вряд ли пригодятся (там будут уже другие компетенции «внахлёст» попадать),
Так же как и специализация. Тут скорее наоборот, больше вероятность переместить вертикальную палку от T в другое место, если есть горизонтальная — т.е. приспособиться для других условий если есть общее представление о смежных областях.
Почему не общим? Они могут работать на одним PBI в сотрудничестве с другими членами команды? А то получается что каждый отдельный человек это отдельная команда.
Таким образом мы пришли к одному и тому же: практически всегда действует спектр мотиваций и сведение "добровольно и осознано" к "когда ты совладелец бизнеса" (если принимать это "совладелец" буквально, а не как-то метафорически) — некоторое упрощение реальности.
Если принимать метафорически, то совершенно согласен — хороший профессионал чувствует себя ответственным за конечный результат — в каком-то смысле им владеет.
Команда, любой член которой способен эффективно выполнять любую работу в команде
Между "эту работу может выполнить ровно один человек в команде" и "эту работу одинаково хорошо могут выполнить все люди в команде" есть степени: "эту работу могут выполнить двое" или "эту работу могут выполнить несколько людей но с разной эффективностью"
Если двое специализируются на БД — это sub-team, который явно запрещён.
Во-первых, почему это сабтим? Они не обязаны работать только друг с другом (так же как и все специалисты по БД в компании не образуют "команду БД")
Еще у них могут быть разные горизонтальные палочки в T — один из них БД-и-тестер, а другой БД-и-бекенд.
https://hh.ru/search/vacancy?text=MySQL
Я вижу что там как правило требования на соседние по стеку навыки. Откуда ваши сведения?
Как жаль что такой опытный, разносторонний и вежливый профессионал как вы не снизошел до объяснения на конкретном примере своей концепции развития компетенций.
Буду надеяться, что мне встретится кто-то другой, кто снизойдет до новичков моего уровня. Или может быть, вы сможете выделить время на то, чтобы написать мемуары о вашем участии в больших проектах? Я понимаю, у вас мало времени, но человечество в моем лице было бы очень благодарно вам. Тем более что это, наверное, менее затратно, чем объяснять чуть дела каждому остолопу, вроде меня. Спасибо большое, что отвечали на мои вопросы, хотя я и понимаю, что ваше терпение не безгранично. Извините, пожалуйста, еще раз за назойливость и еще раз спасибо.
Общий — это один на всех, а не одинаковый. И там обычно на задачи а вот что:
То есть например PBI может быть "Добавить обработку бесконтактных карт", которая подразумевает "дизайн, реализация и тестирование". Соответственно команда делает PBI внутри себя распределяя задачи.
Скорее всего, спец по БД, если нет задачи по БД, вполне может, например, выполнить задачу по тестированию PBI если есть такой, а тестеры заняты.
Почему? Мне просто чисто практически непонятно — в ситуации когда есть потребность при добавлении галки подправить условно html, js, sql и java, вроде все подталкивает к тому чтобы чисто практически выучить немножко того и немножко сего, чтобы сделать эту галку полностью самостоятельно, а не просить Васю. А чтобы в дополнении в MS SQL учить Оракл, придется откуда-то выдумывать задачу и держать этот Оракл в голове работая с MS SQL (см кривая забывания).
Т.е. с моей точки зрения в практической работы горизонтальная линейка у T весьма органично растет на соседние слои стека, и для менеджера это более ценно (для простых операций не надо накладных расходов для взаимодействия между членами команды, а для сложных — больше взаимопонимания).
Именно поэтому мне интересен опыт такого разностороннего профессионала как вы, как получается, что выгоднее по другому. Именно на этом простом примере.
Я буду благодарен если вы мне объясните здесь или персональными сообщениями. Спасибо за дискуссию в любом случае.
Ну я, честно говоря, больше видел специалистов которые изучали смежные по стеку технологии чем по уровню (трудно на досуге очень хорошо изучить Oracle — так как вся практика на MS SQL — принципы можно, но конкретные глюки/приемы/навыки не очень удобно, так как нужно иметь какой-то рабочий пример) я скорее видел специалистов, которые могли знать соседние элементы стека. Или даже поверхностно весь стек и глубоко предметную область.
А какой у вас опыт?
А если он ковыряется в ASP.NET? Я вот думаю что может быть несколько направлений смежности можно растить горизонтальную палку в направлении разных СУБД (но тогда получается что эта палка будет не использоваться точно в каждом конкретном месте работы кроме некоторых исключений). Можно расти в смежные вещи по стеку. Например в MS-SQL используются другие технологии MS — .NET и Powershell, зная C# можно выучить ASP.NET и уже просто чтобы добавить галочку в форму не надо будет звать фронтэндщика. Знание C# и PS пригодиться и для администрирования IIS. Зная C# можно на другом месте работы выучить Java и т.д.
Если он начнет играть шрифтами и это ему нравится то почему бы нет? Будет способ отдыха. Возможно, ему легче будет понять, как на мир смотрят дизайнеры и это будет источником метафор.
Не затруднит ли это подтвердить цитатой из скрам гайд?
— Что?
— Думали туман, — повторила Ирма.
— Про туман, — поправил Виктор. — Или о тумане.
— Зачем это — про туман? — сказала Ирма.
— Думать — непереходный глагол, — объяснил Виктор. — Он требует
предлогов. Вы проходили непереходные глаголы?
— Это когда как, — сказала Ирма. — Думать туман — это одно, а думать
про туман — это совсем другое… и кому это нужно — думать про туман,
неизвестно.
Виктор вытащил сигарету и закурил.
— Погоди, — сказал он. — Думать туман — так не говорят, это
неграмотно. Есть такие глаголы — непереходные: думать, бегать, ходить. Они
всегда требуют предлога. Ходить по улице. Думать про… что-нибудь там…
Я не разбираюсь в этих технологиях, так что не могу прокомментировать детально. Я думаю, что некоторые знания переносимы — т.е. если человек в принципе знает реляционные базы и веб разработку, то он может быстрее приспособиться к конкретной реляционной базе и конкретному фреймворку. Т.е. нельзя знать только MySQL, если узнаешь MySQL ты узнаешь так же про реляционные базы вообще, индексы, SQL латентность и прочее.
Если он на досуге поучит NoSQL он сможет применить знания и в том и в этом стартапе и владеть большим количеством технических решений — т.е. большее чувство собственности.
Так же как и специализация. Тут скорее наоборот, больше вероятность переместить вертикальную палку от T в другое место, если есть горизонтальная — т.е. приспособиться для других условий если есть общее представление о смежных областях.
Почему не общим? Они могут работать на одним PBI в сотрудничестве с другими членами команды? А то получается что каждый отдельный человек это отдельная команда.
Таким образом мы пришли к одному и тому же: практически всегда действует спектр мотиваций и сведение "добровольно и осознано" к "когда ты совладелец бизнеса" (если принимать это "совладелец" буквально, а не как-то метафорически) — некоторое упрощение реальности.
Если принимать метафорически, то совершенно согласен — хороший профессионал чувствует себя ответственным за конечный результат — в каком-то смысле им владеет.
Люди любят делать крутые полезные вещи для других людей. Не вся мотивация сводится к баблецу. То, что что-то заканчивается не значит, что это иллюзия.
Между "эту работу может выполнить ровно один человек в команде" и "эту работу одинаково хорошо могут выполнить все люди в команде" есть степени: "эту работу могут выполнить двое" или "эту работу могут выполнить несколько людей но с разной эффективностью"
Еще у них могут быть разные горизонтальные палочки в T — один из них БД-и-тестер, а другой БД-и-бекенд.
То есть у вам нет опыта такой работы, а есть только теоретические рассуждения на основании чисто технических возможностей
Какому именно закону это несоответствует? Вроде есть копирайт — право копирования а не одалживания.
Я не нашел где скачивать.