ОК, поясню, что я имею в виду, чтобы без демагогии :) Если мы пилим бекенд для какого-то фронтенда, то надо бы понимать: - какие пользовательские сценариии в продукте мы реализуем - как в целом устроен наш фронтенд и как он обращается с нашим беком - как работают протоколы, по которым они общаются - как работает аутентификация, авторизация и обработка ошибок т.д. В цвет кнопок можно обычно не вникать.
Это кстати интересная тема для отдельного исследования - как наниматели относяться к опыты на разном стеке.
По моему ощущению у нас на рынке они уделяют излишнее внимание знанию какого-то одного стека нежели инженерным знаниям в разработке в целом. Условно скорее возьмут кого-то 2 годами Java, чем 5 на .NET и хорошими знаниям.
Слабая связанность это про организацию кода и его зависимостей, а не команд и их знаний и навыков. Если у вас автор одного модуля/слоя не в курсе, как и зачем его модулем пользуются другие и какое место он в целом занимает в продукте - у вас проблема.
Не факт что выгодней - таких "единорогов" мало, и они дорогие. Я вижу скорее тренд на большую специализацию в разработке. Доходит до смешного в духе "я бекенд, что там с моими данными на фронтенде мне безразлично".
По правде говоря: в некоторых конкурентных нишах - фичи вполне годятся для того, чтобы выделится среди конкурентов. На какое то время.
О том что работать над пользовательским опытом тоже надо лучше всего знают в екоммерсах - потому что для них оно легко сводится к оптимизации конверсии в продажу. В других областях не так очевидно, но вполне можно также найти прокси-метрики.
Ну да, если не нужно — то можно только посоветовать дать прочитать статью или классическую книгу "Психбольница в руках пациентов", там тоже много про фичеризм было.
Думаю, пример KPI HR в виде только "количества нанятых разработчиков" это все же упрощение. В реальности там еще будет и "% прохождения испытательного срока", и "текучка" и еще что-то.
Так вот у HR это что-то "в людях", у сейлз - что-то "в деньгах", а вот у технарей в чем таком, что можно также "пощупать"? Вроде — нет такого. Вот тут МакКинзи и накинулись пытаться оцифровывать.
Да, тут как раз мысль кажется в том сравнивать и "оцифровывать" Васю и Колю — обычно дурацкая затея, так как надо "оцифровывать" команды, отделы, а не людей. Если надо понять кого уволить или наградить бонусом — это проще руководителя команды спросить.
Хорошее замечание: про то, как смотреть на потенциал сотрудников и работать с ним в статье совсем нет.
Скажу, как стараюсь делать я. Для начала, нужно понять и определить все же функцию, а потом на уже смотреть на потенциал.
Кроме обзора результатов стараюсь регулярно обсуждать такие вопросы: нравиться ли ему текущие задачи, куда хочет двигаться в карьере, какие проектами или задачам интересно было бы заниматься, что хочется изучить. Дальше смотришь на, то что ты можешь дать сотруднику и как его желания накладываются на твои цели компании или команды. Иногда находится что-то интересное и креативное.
ОК, поясню, что я имею в виду, чтобы без демагогии :)
Если мы пилим бекенд для какого-то фронтенда, то надо бы понимать:
- какие пользовательские сценариии в продукте мы реализуем
- как в целом устроен наш фронтенд и как он обращается с нашим беком
- как работают протоколы, по которым они общаются
- как работает аутентификация, авторизация и обработка ошибок т.д.
В цвет кнопок можно обычно не вникать.
Это кстати интересная тема для отдельного исследования - как наниматели относяться к опыты на разном стеке.
По моему ощущению у нас на рынке они уделяют излишнее внимание знанию какого-то одного стека нежели инженерным знаниям в разработке в целом. Условно скорее возьмут кого-то 2 годами Java, чем 5 на .NET и хорошими знаниям.
Слабая связанность это про организацию кода и его зависимостей, а не команд и их знаний и навыков. Если у вас автор одного модуля/слоя не в курсе, как и зачем его модулем пользуются другие и какое место он в целом занимает в продукте - у вас проблема.
К сожалению, установить какой из вариантов имел ввиду автор нам не удалось - сохранили авторское правописание
Не факт что выгодней - таких "единорогов" мало, и они дорогие. Я вижу скорее тренд на большую специализацию в разработке. Доходит до смешного в духе "я бекенд, что там с моими данными на фронтенде мне безразлично".
Согласен, это интересно и нужно было бы добавить такой вариант ответа в опрос — учтем в будущем.
По правде говоря: в некоторых конкурентных нишах - фичи вполне годятся для того, чтобы выделится среди конкурентов. На какое то время.
О том что работать над пользовательским опытом тоже надо лучше всего знают в екоммерсах - потому что для них оно легко сводится к оптимизации конверсии в продажу. В других областях не так очевидно, но вполне можно также найти прокси-метрики.
Ну да, если не нужно — то можно только посоветовать дать прочитать статью или классическую книгу "Психбольница в руках пациентов", там тоже много про фичеризм было.
Собственно легкость придумывания фич и оценке ценности в фичах и приводит к фичеризму со всеми последствиями. А можно по другому.
Как управлять бюджетом — интересный вопрос, попробую узнать по подробнее и может на статью наберётся интересного материала.
Но по общению с техдирами, условно часто так: есть продукты, под них строится оргструктура и бюджеты на год, а дальше корректируется по кварталу.
"Проджекты" тут имеется ввиду "проджект менеджеры", жаргонизм такой ?.
Предыдущий перевод и правда пропустил — буду следующий раз проверять лучше.
Думаю, пример KPI HR в виде только "количества нанятых разработчиков" это все же упрощение. В реальности там еще будет и "% прохождения испытательного срока", и "текучка" и еще что-то.
Так вот у HR это что-то "в людях", у сейлз - что-то "в деньгах", а вот у технарей в чем таком, что можно также "пощупать"? Вроде — нет такого.
Вот тут МакКинзи и накинулись пытаться оцифровывать.
Да, тут как раз мысль кажется в том сравнивать и "оцифровывать" Васю и Колю — обычно дурацкая затея, так как надо "оцифровывать" команды, отделы, а не людей. Если надо понять кого уволить или наградить бонусом — это проще руководителя команды спросить.
Например, у нас в руках была сахарница с синтаксическим сахаром, и мы сахар из нее рассыпали прямо в на наш язык программирования...
А если серьезно: круто было сделать что-то вроде блок-схемы для принятия решения, что использовать ивенты, делегаты или MediatR.
Хорошее замечание: про то, как смотреть на потенциал сотрудников и работать с ним в статье совсем нет.
Скажу, как стараюсь делать я. Для начала, нужно понять и определить все же функцию, а потом на уже смотреть на потенциал.
Кроме обзора результатов стараюсь регулярно обсуждать такие вопросы: нравиться ли ему текущие задачи, куда хочет двигаться в карьере, какие проектами или задачам интересно было бы заниматься, что хочется изучить. Дальше смотришь на, то что ты можешь дать сотруднику и как его желания накладываются на твои цели компании или команды. Иногда находится что-то интересное и креативное.
В последней строке?
Да, запутал с одинаковыми названиям Alg4, сейчас исправил. Добавил верное замечание про CPU — спасибо!
Да — именно это как раз пытался показать в Примере с подвохом.
Спасибо, при верстке кода со скринов наделал ошибок — вроде все исправил