Ой ну наконец-то, хоть кто-то как по учебнику делает. Жаль что учебников пока на эту тему не пишут. Поэтому торчим на технических секциях по 2,5-4 часа, выходя с которых думаешь "а это они кого ищут и для чего". И напротив - ищешь себе человека с опытом в системном дизайне в продуктовую команду, а идут подготовленные к литкоду и очень смутным пониманием архитектурных принципов, особенно в том как они на практике работают. Беда-беда.
Ой ну такие все нежные прям. Взяли весь рабочий сленг и записали в коллективное "общебесительное". Ну и как теперь работать? Зачитывать по-английски, или дословно переводить, сидя прямо в накрахмаленной рубашке и отпивая эспрессо из маленькой чашечки, оттопырив мизинчик?
Главное помните - средний разраб переходит с айти-суржика на государственный (на работе) только разговаривая с дебилами. Так что если с вами говорят максимально понятно и доступно, то вы очевидно не свой.
Не бывают они плохие и хорошие. По вашим же словам они бывают подходящие и нет. Но это вы в СПГС ударились. Я часто провожу собесы. Приходит чувак и говорит "я SQL руками не пишу" (это кстати не единичный случай). Не конкретно в решении где нужно поддерживать разные диалекты, и не по другим каким-то привязанным к задачам причинам. Просто не пишет. Принцип такой. Или не признает в принципе реляционок. Без привязки к тому что в них лежит и зачем оно там лежит. Просто не признает. Или считает что приложения должны быть 100% онлайн без автономности. Вне зависимости от того зачем они нужны и в каких условиях их эксплуатируют.
Я так-то только за если человек может внятно и связно рассказать где какой инструмент нужен а где не нужен. Это значит что можно не задавать ему глупые вопросы про хеш-таблицу и вызубренные принципы солид, а нормально перетереть за настоящую работу. Но в подавляющем большинстве случаев заявления о неприятии инструмента X - принципиальные и не подкреплены разумными аргументами. Такая вот фигня.
Не может конечно. Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога". Таким людям нужно лечение, а не работа. Без искажений это звучит как "знаю этот инструмент на уровне блаблабла".
Ну тут как сказать. Я однажды искал себе пару мидлов, отсобеседовал за полгода кучу народа, в итоге наняли двух джунов с которыми я увидел что сработаемся. И это было лучшее решение в моей жизни. Один делал быстро и плохо, но позволил здорово сократить сроки, несмотря на то что пришлось потом серьезно рефакторить. Второй делал медленно и вдумчиво, а главное слушал внимательно и в итоге возглавил проект когда я с него уже ушел в другую компанию. Регалии - они такое себе. Надо с людьми работать.
Ну и да, "отличное новое полено" после универа это стажер.
А господин точно лид с 2003-го? Квалифицированный разработчик отличается не скоростью разработки, а скоростью деградации (усложнения поддержки проекта). Она у него ниже чем у неквалифицированного настолько, что может достигать отрицательных значений. Человек усложняющий поддержку не называется сеньором. Нет ну то есть называется, но не является. Джун может работать ооочень быстро, проблема в том что отпущенный в автоном джун разгоняет эту самую деградацию и за ним всегда нужно вдумчивое ревью, жесткая корректировка, или решение прописанное досконально. Так что на любом проекте необходимо n высококвалифицированных сотрудников и n*m сотрудников попроще где m - индивидуально от количества задач которые эти n имеют и главное способны делегировать со всеми отягчающими.
Ну на моей практике надо наваливать про контекст пожирнее, все равно в работе игнорят. Типа три раза сказать, попросить повторить, потом еще раз вернуться и еще раз напомнить.
Да это понятно. Просто подливаю ложку дегтя. Или добавляю акцент. Во внедрении инструментов ключевой же вопрос: "Чтобы что?". Архитектуры, аджайл-практики, различные driven development, воркфлоу, гитфлоу - всегда вяжутся на кадры, особенности продукта, структуру организации, стеки и прочее, в том числе и друг на друга. Этот момент постоянно ускользает из внимания многих даже опытных людей, не то что неофитов.
Скажем даже гитлаб-флоу уже доставляет неудобств при релизах по расписанию. Потому как состав его частенько утверждается после тестирования отдельно по задачам из билдов ci по результатам регресса кандидата с уточнением. И если по итогам всего решили какую-то довольно комплексную задачу не катить, то возникает необходимость хирургического вмешательство в девелоп. А сроки-то первичны. Усугублять это картину еще и тбд нет абсолютно никакого смысла, если оставлять воркфлоу над этим таким же.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо. Вообще малой командой можно очень извращенно приседать, вплоть до хранения веток задач порознь до момента релиза который оформляется как кандидат и отправки в девелоп и мастер исключительно его. Все очень зависит от релиз трейна. В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать. Можно нехило так влететь с ними в сложно диагностируемую неконсистентность.
Вот у вас вроде местами адекватные комментарии (и с огоньком), но статья какая-то как будто натужная и полярно-передернутая. А ведь Акртика и Антактика места весьма негустонаселенные. Вот конкретно это - нормальная и адекватная оценка рисков работника. Но в целом я за двадцать с лишним лет видел все вышеперечисленное и немного больше - не такое оно все и большая проблема. Потому что иногда отыгрывает в обратную сторону. Как и плач предпринимателя о том что он несет риски. Нормально живут с долгами которые им за всю жизнь не выплатить. И продолжают "предпринимать".
Ключевая проблема упомянутых "ждунов-вкатунов" в том что им собственно деньги все заслоняют. И с одной стороны их можно понять - я вырос в неполной семье которая жила на зарплату моей мамы-медсестры и мне понятно её чувство бессилия что-то поменять. Из такого и вылезает поведение "вкатывайся-ври-иди-по-головам". Осуждать я это не вправе. Но сфера-то рисковая, уверенно стоять на ногах вы в ней сможете только имея нехилую базу экспертизы под ногами. И как высоко бы вы не забрались по варианту 2 - если в процессе на экспертизу вы забили (а приобрести ее можно только ненормированным и тяжелым когнитивным трудом) вы будете потом плакать о своих рисках. Будь вы разработчик, техдир, гендир, или владелец компании. На любой позиции, в любой роли. А если она есть - пожмете плечами, скажете что-то типа "придурки" и пойдете дальше. Опять же справедливо для любой роли.
Да все из-за кадровых проблем. Всегда все из-за них. А кадровые проблемы бывают двух типов: кадров мало и кадры фигня. Причем одно другому не мешает.
1) Кадров мало. Часто некому в принципе хоть как-то формализовать все приобретенные компетенции по продукту и каждая новая фича бьет этим по лбу. На моей опыте все эти шесть "ролей" часто ложатся на плечи разраба, то есть меня. Дальше - или с коллегами повезло и они обучаемые, или "ну ее нафиг работу твою", потому что проблемы будут расти до состояния "невывозимо".
2) Кадры фигня. То есть никто не хочет в кросс-функциональность эту вашу: на выходе дизайнера картинка без описания сценариев, на вход у разраба принимается только детализированная задача и никакого аналитического выхода он не дает, на выходе у ПО (на которого навесили функции и СА и БА и ПМ и фонарь на лоб повесили, чтобы он еще на трех проектах по ночам светил) невразумительная двухстрочная лабуда вместо постановки задачи по случайному адресу. Если с наймом в этом варианте проблем нет - такая команда будет пожирать самого ответственного из нанятых ей в "усиление", любого СА и БА или даже разраба который не только задачки в жире умеет двигать, а еще и головой подумать когда надо.
Я вот всячески всегда и всем советую не парить себе голову формализмами, а искать людей с которыми работать приятно. Что по ту что по эту сторону переговорного стола на собесе. Но это и у меня не всегда получается что по ту что по эту ¯\_(ツ)_/¯
Спасибо что повторили мои слова оперируя своими терминами.
Собственно так и выглядит "смена майндсета". Мы используем разные формулировки, сказав по сути одно и то же. Смысл не пострадал. Набор орг-мероприятий и непосредственно рабочих задач необходимых для выполнения работы при внедрении принципов аджайл так же никуда не девается.
Работать все будут абсолютно так же. А вот утренняя разминка под другую музыку.
Это не методики и практики это "методология". То бишь подход к выработке конечных методик. Предлагается принять некоторые постулаты которыми вы будете руководствоваться при построении вашего рабочего процесса. Так же есть некоторый набор ритуалов которые в теории помогут вам в этом процессе. Заметьте, по технологическим процессам у всех аджайл-коучей или скрам-мастеров нет ровно никакой конкретики. Они и не должны обладать технической экспертизой. Управленческой экспертизой они так же не обладают. Это ритуальные услуги в широком смысле. А церковь не государство. Поэтому если у вас есть смутное чувство что вы поели "не шоколада", когда читаете аджайл-манифесты и их производные, то оно вас не подводит.
Ад какой. В 19 и 23 вообще не так было. Хотя и стеки у нас немного разные. Я до десяти приглашений на техсобес не добираюсь без 2-3 офферов, впрочем у меня и история другая - мобилки, внешние железки и любовь к экзотике по части предметной области (финтехи и чистый диджитал скукота) - а тут чаще просто не найти достаточно адекватного персонажа. По полгода собесим 2-3 раза в неделю.
1) Ну так вы по приглашениям на собес конверсию озвучили? Или это я не глазами прочитал? Чисто по ним не может быть 10%. Разве что вы по грейдам скакали слишком спешно, или в другой стек/специальность прыгали. И то через эйчар фильтр такое как правило легко проходит, если они сами решение принимают, а не команду дергают на каждое резюме.
2) Удивительно. Когда ищешь сеньора надо хоть как-то понять что это он. А это возможность самостоятельно затащить полный цикл. Как это еще проверить? Не по задачкам на линкед лист же. Этому и макаку научить можно.
Ой ну наконец-то, хоть кто-то как по учебнику делает. Жаль что учебников пока на эту тему не пишут. Поэтому торчим на технических секциях по 2,5-4 часа, выходя с которых думаешь "а это они кого ищут и для чего". И напротив - ищешь себе человека с опытом в системном дизайне в продуктовую команду, а идут подготовленные к литкоду и очень смутным пониманием архитектурных принципов, особенно в том как они на практике работают. Беда-беда.
Ой ну такие все нежные прям. Взяли весь рабочий сленг и записали в коллективное "общебесительное". Ну и как теперь работать? Зачитывать по-английски, или дословно переводить, сидя прямо в накрахмаленной рубашке и отпивая эспрессо из маленькой чашечки, оттопырив мизинчик?
Главное помните - средний разраб переходит с айти-суржика на государственный (на работе) только разговаривая с дебилами. Так что если с вами говорят максимально понятно и доступно, то вы очевидно не свой.
так ручку ж дергает, и в мыслях не было, трщ прапорщик
кьюеуе ж
Не бывают они плохие и хорошие. По вашим же словам они бывают подходящие и нет. Но это вы в СПГС ударились. Я часто провожу собесы. Приходит чувак и говорит "я SQL руками не пишу" (это кстати не единичный случай). Не конкретно в решении где нужно поддерживать разные диалекты, и не по другим каким-то привязанным к задачам причинам. Просто не пишет. Принцип такой. Или не признает в принципе реляционок. Без привязки к тому что в них лежит и зачем оно там лежит. Просто не признает. Или считает что приложения должны быть 100% онлайн без автономности. Вне зависимости от того зачем они нужны и в каких условиях их эксплуатируют.
Я так-то только за если человек может внятно и связно рассказать где какой инструмент нужен а где не нужен. Это значит что можно не задавать ему глупые вопросы про хеш-таблицу и вызубренные принципы солид, а нормально перетереть за настоящую работу. Но в подавляющем большинстве случаев заявления о неприятии инструмента X - принципиальные и не подкреплены разумными аргументами. Такая вот фигня.
А вот это предлагаю "отлить в граните".
Не может конечно. Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога". Таким людям нужно лечение, а не работа. Без искажений это звучит как "знаю этот инструмент на уровне блаблабла".
Ну тут как сказать. Я однажды искал себе пару мидлов, отсобеседовал за полгода кучу народа, в итоге наняли двух джунов с которыми я увидел что сработаемся. И это было лучшее решение в моей жизни. Один делал быстро и плохо, но позволил здорово сократить сроки, несмотря на то что пришлось потом серьезно рефакторить. Второй делал медленно и вдумчиво, а главное слушал внимательно и в итоге возглавил проект когда я с него уже ушел в другую компанию. Регалии - они такое себе. Надо с людьми работать.
Ну и да, "отличное новое полено" после универа это стажер.
А господин точно лид с 2003-го? Квалифицированный разработчик отличается не скоростью разработки, а скоростью деградации (усложнения поддержки проекта). Она у него ниже чем у неквалифицированного настолько, что может достигать отрицательных значений. Человек усложняющий поддержку не называется сеньором. Нет ну то есть называется, но не является. Джун может работать ооочень быстро, проблема в том что отпущенный в автоном джун разгоняет эту самую деградацию и за ним всегда нужно вдумчивое ревью, жесткая корректировка, или решение прописанное досконально. Так что на любом проекте необходимо n высококвалифицированных сотрудников и n*m сотрудников попроще где m - индивидуально от количества задач которые эти n имеют и главное способны делегировать со всеми отягчающими.
Ну на моей практике надо наваливать про контекст пожирнее, все равно в работе игнорят. Типа три раза сказать, попросить повторить, потом еще раз вернуться и еще раз напомнить.
Да это понятно. Просто подливаю ложку дегтя. Или добавляю акцент. Во внедрении инструментов ключевой же вопрос: "Чтобы что?". Архитектуры, аджайл-практики, различные driven development, воркфлоу, гитфлоу - всегда вяжутся на кадры, особенности продукта, структуру организации, стеки и прочее, в том числе и друг на друга. Этот момент постоянно ускользает из внимания многих даже опытных людей, не то что неофитов.
Скажем даже гитлаб-флоу уже доставляет неудобств при релизах по расписанию. Потому как состав его частенько утверждается после тестирования отдельно по задачам из билдов ci по результатам регресса кандидата с уточнением. И если по итогам всего решили какую-то довольно комплексную задачу не катить, то возникает необходимость хирургического вмешательство в девелоп. А сроки-то первичны. Усугублять это картину еще и тбд нет абсолютно никакого смысла, если оставлять воркфлоу над этим таким же.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо. Вообще малой командой можно очень извращенно приседать, вплоть до хранения веток задач порознь до момента релиза который оформляется как кандидат и отправки в девелоп и мастер исключительно его. Все очень зависит от релиз трейна. В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать. Можно нехило так влететь с ними в сложно диагностируемую неконсистентность.
А как вы определяете методологию
Вот у вас вроде местами адекватные комментарии (и с огоньком), но статья какая-то как будто натужная и полярно-передернутая. А ведь Акртика и Антактика места весьма негустонаселенные. Вот конкретно это - нормальная и адекватная оценка рисков работника. Но в целом я за двадцать с лишним лет видел все вышеперечисленное и немного больше - не такое оно все и большая проблема. Потому что иногда отыгрывает в обратную сторону. Как и плач предпринимателя о том что он несет риски. Нормально живут с долгами которые им за всю жизнь не выплатить. И продолжают "предпринимать".
Ключевая проблема упомянутых "ждунов-вкатунов" в том что им собственно деньги все заслоняют. И с одной стороны их можно понять - я вырос в неполной семье которая жила на зарплату моей мамы-медсестры и мне понятно её чувство бессилия что-то поменять. Из такого и вылезает поведение "вкатывайся-ври-иди-по-головам". Осуждать я это не вправе. Но сфера-то рисковая, уверенно стоять на ногах вы в ней сможете только имея нехилую базу экспертизы под ногами. И как высоко бы вы не забрались по варианту 2 - если в процессе на экспертизу вы забили (а приобрести ее можно только ненормированным и тяжелым когнитивным трудом) вы будете потом плакать о своих рисках. Будь вы разработчик, техдир, гендир, или владелец компании. На любой позиции, в любой роли. А если она есть - пожмете плечами, скажете что-то типа "придурки" и пойдете дальше. Опять же справедливо для любой роли.
завернувшись в простыню и медленно, чтобы не создавать паники*
Да все из-за кадровых проблем. Всегда все из-за них. А кадровые проблемы бывают двух типов: кадров мало и кадры фигня. Причем одно другому не мешает.
1) Кадров мало. Часто некому в принципе хоть как-то формализовать все приобретенные компетенции по продукту и каждая новая фича бьет этим по лбу. На моей опыте все эти шесть "ролей" часто ложатся на плечи разраба, то есть меня. Дальше - или с коллегами повезло и они обучаемые, или "ну ее нафиг работу твою", потому что проблемы будут расти до состояния "невывозимо".
2) Кадры фигня. То есть никто не хочет в кросс-функциональность эту вашу: на выходе дизайнера картинка без описания сценариев, на вход у разраба принимается только детализированная задача и никакого аналитического выхода он не дает, на выходе у ПО (на которого навесили функции и СА и БА и ПМ и фонарь на лоб повесили, чтобы он еще на трех проектах по ночам светил) невразумительная двухстрочная лабуда вместо постановки задачи по случайному адресу. Если с наймом в этом варианте проблем нет - такая команда будет пожирать самого ответственного из нанятых ей в "усиление", любого СА и БА или даже разраба который не только задачки в жире умеет двигать, а еще и головой подумать когда надо.
Я вот всячески всегда и всем советую не парить себе голову формализмами, а искать людей с которыми работать приятно. Что по ту что по эту сторону переговорного стола на собесе. Но это и у меня не всегда получается что по ту что по эту ¯\_(ツ)_/¯
Спасибо что повторили мои слова оперируя своими терминами.
Собственно так и выглядит "смена майндсета". Мы используем разные формулировки, сказав по сути одно и то же. Смысл не пострадал. Набор орг-мероприятий и непосредственно рабочих задач необходимых для выполнения работы при внедрении принципов аджайл так же никуда не девается.
Работать все будут абсолютно так же. А вот утренняя разминка под другую музыку.
Это не методики и практики это "методология". То бишь подход к выработке конечных методик. Предлагается принять некоторые постулаты которыми вы будете руководствоваться при построении вашего рабочего процесса. Так же есть некоторый набор ритуалов которые в теории помогут вам в этом процессе. Заметьте, по технологическим процессам у всех аджайл-коучей или скрам-мастеров нет ровно никакой конкретики. Они и не должны обладать технической экспертизой. Управленческой экспертизой они так же не обладают. Это ритуальные услуги в широком смысле. А церковь не государство. Поэтому если у вас есть смутное чувство что вы поели "не шоколада", когда читаете аджайл-манифесты и их производные, то оно вас не подводит.
Ад какой. В 19 и 23 вообще не так было. Хотя и стеки у нас немного разные. Я до десяти приглашений на техсобес не добираюсь без 2-3 офферов, впрочем у меня и история другая - мобилки, внешние железки и любовь к экзотике по части предметной области (финтехи и чистый диджитал скукота) - а тут чаще просто не найти достаточно адекватного персонажа. По полгода собесим 2-3 раза в неделю.
Мне сложнее найти куда откликнуться.
1) Ну так вы по приглашениям на собес конверсию озвучили? Или это я не глазами прочитал? Чисто по ним не может быть 10%. Разве что вы по грейдам скакали слишком спешно, или в другой стек/специальность прыгали. И то через эйчар фильтр такое как правило легко проходит, если они сами решение принимают, а не команду дергают на каждое резюме.
2) Удивительно. Когда ищешь сеньора надо хоть как-то понять что это он. А это возможность самостоятельно затащить полный цикл. Как это еще проверить? Не по задачкам на линкед лист же. Этому и макаку научить можно.